Ticket #2084 (new bug)

Opened 4 months ago

Last modified 3 months ago

ipro100 driver makes the system crawl

Reported by: heto Owned by: axeld
Priority: normal Milestone: R1
Component: Drivers/Network Version: R1 development
Cc: Blocked By:
Platform: x86 Blocking:

Description

Haiku r24959 runs unusably slow on real hardware on my IBM ThinkPad A30 notebook: running ls in the home directory or opening the leaf menu may take over ten seconds to complete, the default Haiku background image takes over four minutes to load, and the desktop won't show even after running the system for 40 minutes. Top shows that "fxp intr handler" of kernel_team takes most of the cpu time, about 45%, although I suspect the real number is much higher.

Safe mode works fine. After removing /boot/beos/system/add-ons/kernel/drivers/dev/net/ipro100 and moving /boot/beos/system/add-ons/kernel/drivers/bin/ipro100 to home directory normal mode works well, too, although the integrated Ethernet isn't recognized then, of course. This leads me to suspect the bug is in either the ipro100 driver or the FreeBSD network driver compatibility layer.

Revision 24921 seems to run a little bit faster, and the desktop icons show up after about 10 minutes of uptime, but it's still unusable.

I've attached a serial log. A poor-quality video of the slowdown is also available at http://koti.mbnet.fi/hetonnet/misc/Haiku_crawling.3gp . I've commented ProcessController out in Bootscript in that video to avoid any extra slowdown.

Harware details: Intel Pentium III-M 1 GHz ATI Radeon Mobility M6 LY 256 MB RAM Intel 82830 and 82801CAM chipset (ICH3) with integrated Ethernet

Attachments

haiku_serial.txt (69.1 kB) - added by heto 4 months ago.
Serial log of the problem
top.txt (3.1 kB) - added by heto 4 months ago.
output of top -d -n 1 when experiencing the slowdown

Change History

Changed 4 months ago by heto

Serial log of the problem

Changed 4 months ago by heto

output of top -d -n 1 when experiencing the slowdown

Changed 3 months ago by heto

Lowering the priority of fxp intr handler to idle or lowest active makes the system usable, although I'd still say speed is affected by the bug. This can be automated by making a ~/config/boot/UserBootscript file with the following two lines: #!/bin/sh renice -b 1 -f "fxp intr handler"

The weird thing is that after lowering the priority to 1 the thread takes about the same 50% of CPU time it normally takes, leaving about 50% to the idle thread, yet the system is much more usable with this priority.

Note: See TracTickets for help on using tickets.