OHCI eats interrupts that are not its own

[datafatmunger]

Networking fails or drops a couple minutes after boot. DHCP seems to work, I do get an IP address, gateway is there, etc... but every request times out.

Looks like vendor is NVIDIA, MCP77 Ethernet

[datafatmunger]

output from listdev

[datafatmunger]

syslog

[datafatmunger]

https://dev.haiku-os.org/ticket/4239 this seems suspiciously relevant … seems: KERN: [net/nforce/0] watchdog timout (missed Tx interrupts) … is sort of where it is going wrong?

[waddlesplash]

Possibly. Can you see if this driver works for you under FreeBSD?

[datafatmunger]

Thanks for the reply. I'm new to Haiku, so I'm not sure how to try the driver. Can you point me to a resource? Or perhaps you mean to install and try FreeBSD? -- would be a blast from the past, the last time I installed FreeBSD was in like 1997.

[diver]

Yes, try installing the latest FreeBSD and see if it works there.

[datafatmunger]

Installed FreeBSD 11.2, seems completely happy.

[waddlesplash]

I wonder if this is related to the usb_disk interrupts; possible something is eating interrupts incorrectly and so they are not making it to the driver, in the case they are on the same IRQ. Can you try booting / not using a USB port, and see if this helps?

[datafatmunger]

Funny thing is I'm not booting from USB at all. I'm booting from Grub2 using the menu suggestion here: ​https://www.haiku-os.org/get-haiku/installation-guide/ ... and sharing the disk with Gentoo and now also FreeBSD.

The only 2 items plugged into USB are a keyboard and a mouse. :-/

[waddlesplash]

Please retest with a recent nightly; there were some interrupt-related fixes to the compat layer.

[datafatmunger]

Re-tested with hrev52502-x86_64 ... same issues in syslog around usb_disk. :-/

[datafatmunger]

Woohoo this seems to be working/fixed on hrev52610. In fact I'm posting from a working installation. Nice work!

[datafatmunger]

Sorry, spoke to soon error is still there ... does seem a bit more stable tho.

KERN: usb_disk: acquire_sem failed while waiting for data transfer: Operation timed out

[waddlesplash]

Can you run the system without USB (i.e. use a PS/2 keyboard/mouse?) If so, please try blacklisting the "ohci" bus controller and see if this makes the network driver work.

[datafatmunger]

Replying to waddlesplash:

Can you run the system without USB (i.e. use a PS/2 keyboard/mouse?) If so, please try blacklisting the "ohci" bus controller and see if this makes the network driver work.

Same issues ... I enabled sshd, and booted with no keyboard/mouse/usb peripherials. Still ended up with:

KERN: usb_disk: acquire_sem failed while waiting for data transfer: Operation timed out
KERN: usb_disk: getting request sense data failed: Operation timed out
KERN: usb_disk: acquire_sem failed while waiting for data transfer: Operation timed out
KERN: [net/nforce/0] watchdog timeout (missed Tx interrupts) -- recovering
KERN: usb_disk: acquire_sem failed while waiting for data transfer: Operation timed out
KERN: [net/nforce/0] watchdog timeout (missed Tx interrupts) -- recovering
Last message repeated 1 time
KERN: usb_disk: acquire_sem failed while waiting for data transfer: Operation timed out
KERN: [net/nforce/0] watchdog timeout (missed Tx interrupts) -- recovering
Last message repeated 1 time
KERN: usb_disk: acquire_sem failed while waiting for data transfer: Operation timed out
KERN: [net/nforce/0] watchdog timeout (missed Tx interrupts) -- recovering
KERN: usb_disk: acquire_sem failed while waiting for data transfer: Operation timed out
KERN: [net/nforce/0] watchdog timeout (missed Tx interrupts) -- recovering

I'm not sure how to "blacklist ohci" ... can you point me in the right direction?

[diver]

This is an option in the ​bootloader "Blacklist entries" which you can use to blacklist add-ons/kernel/busses/usb.

[datafatmunger]

Replying to diver:

This is an option in the ​bootloader "Blacklist entries" which you can use to blacklist add-ons/kernel/busses/usb.

Indeed the usb_disk errors are gone blacklisting the usb bus. This is sort of a strange desktop machine with some built in SD card readers ... perhaps they are connected to the usb bus? Maybe I can open it up and see if I can disconnect them ... ?

[diver]

Have you tried blacklisting oly "ohci" bus controller?

[datafatmunger]

Replying to diver:

Have you tried blacklisting oly "ohci" bus controller?

Seems blacklisting only "ohci" also corrects the issue. Indeed if I disconnect the SD card readers from the board, the issues also go away. So I believe these card readers are the troublesome bits of hardware.

Booting Gentoo, and running running lsusb:

Bus 003 Device 002: ID 04d9:0175 Holtek Semiconductor, Inc. 
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 004: ID 058f:6361 Alcor Micro Corp. Multimedia Card Reader
Bus 003 Device 003: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

So I'm guessing: Bus 001 Device 004: ID 058f:6361 Alcor Micro Corp. Multimedia Card Reader

?

[waddlesplash]

No, the problem is the OHCI bus controller, which is incorrectly eating interrupts that belong to the ethernet controller.