ipro100 driver makes the system crawl

[heto]

Haiku hrev24959 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

[heto]

Serial log of the problem

[heto]

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

[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.

[RandomInsano]

I have this problem with the ipro100 driver on real hardware as well, but none of the systems have any internal USB devices inherent to the systems and the problem only exists when a USB device is attached or inserted.

The conflict only exists when ipro100 device driver is loaded as well, the USB bus works fairly well without it.

[anevilyak]

Are your USB controller and ethernet controller by any chance sharing interrupts?

[RandomInsano]

In fact they are! IRQ 11 it seems. I can't decipher most of this 'ints' command, so I'll just post a picture. I'm sure this will be the same case as on my Compaq Deskpro that is on my laptop.

[RandomInsano]

Trac was giving me problems, so here's a link: ​http://dl.getdropbox.com/u/128703/DSCN5234.JPG

[RandomInsano]

Copy of my information from duplicate bug #2999:

When I plug in any device into my Compaq Armada M700s USB port the system gets stuck in the fpx interrupt handler during boot (I can see this by getting into the KDL with F12) and the system completely locks up if I do this once the system is booted.

Unplugging the device again doesn't bring the system back into a usable state and it doesn't matter what class of device I use (Several Mass Storage devices, Mouse, Keyboard, Ethernet have been tested).

If I delete the ipro100 device driver the system no longer has this problem, though there are further problems with trying to mount USB mass storage as writable, but that's another story.

The problem also exists on an old Compaq Deskpro. I've tested with many revisions up to 28350 and have never had luck with using USB devices on either system.

[heto]

Using hrev28387 I get behaviour similar to what RandomInsano has: a complete hang if a usb device is plugged but no problems otherwise. Now even lowering the priority of the fxp intr handler thread doesn't help.

In my case interrupt 11 is shared not only by UHCI and ipro100 but also by radeon and auich, yet these two devices don't seem to be causing any trouble. (I can't get any sound output, though, but this problem may be completely unrelated.)

[RandomInsano]

Just an update for those who want to have their cake and eat it too; for the time being using the eepro100 driver from BeOS 5 Max Edition V4 (which may also be in plain BeOS R5) works great under Haiku and will allow you to use your USB port(s) as normal.

[RandomInsano]

Disabling the recently added IO-APIC option in the fail safe screen has no affect on the problem either

[mmlr]

(In #3431) Closing as a duplicate of #2084 then.

[clemens]

Managed to get usb and ipro100 work together. Just always let the net combat interrupt function return B_UNHANDLED_INTERRUPT. When I boot without stick and then insert the stick after a while I can mount the stick and ping a net adress at the same time. When I boot with stick insert I got the old problem. So I think the driver have to tell if it can handle the interupt. Don't see where I can do this in the combat layer... Any ideas?

[anevilyak]

The problem is that prior to FreeBSD7, the ethernet driver interrupt handlers had no way to return whether they handled interrupts or not. Our compat layer has not yet been updated to version 7, so as of right now all of our FreeBSD-based drivers cannot effectively do this. Updating the layer and drivers appropriately would probably fix this issue.

[clemens]

hm the driver is the FreeBSD7 one but I can't figure out where the status is returned... Could somebody clarify it a bit more?

[mmlr]

Please try with a revision >= hrev29242. The specific workaround introduced in hrev29241 and used in hrev29242 should help in this case.

[RandomInsano]

Very much fixed! I can unplug and re-plug USB items with ease! Hurrah! Thanks for patching the compatibility layer guys!

[scottmc]

Can this one be closed? Looks like it's fixed.

[heto]

Unfortunately I don't have the hardware that triggered this bug anymore, so I can't confirm. From my point of view the bug can be closed as RandomInsano has confirmed it to be fixed.