USB mouse can't work when IO-APIC is enabled

[mt]

USB mouse can't work when IO-APIC is enabled.
Tested hrev41579 on real hardware

CPU: Core i5 2400S
M/B: MSI P67A-C43
USB mouse & PS/2 Keyboard

[mt]

Syslog (IO-APIC enabled)

[mt]

Output of listusb (IO-APIC is disabled)

[mt]

Output of listdev (IO-APIC is disabled)

[stargatefan]

is this a american megatrends bios ? I know mmlr is going to read this, these uefi boards should be capable of programming the interupts, just a matter of mapping and reading them.

[mmlr]

Replying to mt:

USB mouse can't work when IO-APIC is enabled.

You're saying that the USB mouse doesn't work, but do you by that mean that only the USB mouse doesn't work? Or does USB not work in general? Have you tried plugging in different devices into different USB ports? You have two EHCI controllers in that system, so maybe only one of them is affected here.

The routing table looks complete, so everything seems to be routed from an OS point of view. It's possible however that the information provided by the BIOS is faulty, i.e. the pins not actually being routed to the inputs that are returned in the routing table. In that case a BIOS update might resolve the problem.

Replying to stargatefan:

I know mmlr is going to read this, these uefi boards should be capable of programming the interupts, just a matter of mapping and reading them.

Your point being?

[mt]

Replying to stargatefan:

is this a american megatrends bios ? I know mmlr is going to read this, these uefi boards should be capable of programming the interupts, just a matter of mapping and reading them.

Hi Stargatefan, It seems AMI bios. (​http://www.msi.com/product/mb/P67A-C43.html#/?div=BIOS)

[mt]

Replying to mmlr:

You're saying that the USB mouse doesn't work, but do you by that mean that only the USB mouse doesn't work? Or does USB not work in general? Have you tried plugging in different devices into different USB ports? You have two EHCI controllers in that system, so maybe only one of them is affected here.

Thanks mmlr, USB mouse works again by plugging in different USB port. Then I tried USB stick. USB stick also works by plugging in different USB port. So It seems USB does not work in general with one of two controller as you say.

The routing table looks complete, so everything seems to be routed from an OS point of view. It's possible however that the information provided by the BIOS is faulty, i.e. the pins not actually being routed to the inputs that are returned in the routing table. In that case a BIOS update might resolve the problem.

BIOS seems latest, I'm waiting for new BIOS...

[mmlr]

Replying to mt:

Replying to mmlr:

You're saying that the USB mouse doesn't work, but do you by that mean that only the USB mouse doesn't work? Or does USB not work in general? Have you tried plugging in different devices into different USB ports? You have two EHCI controllers in that system, so maybe only one of them is affected here.

Thanks mmlr, USB mouse works again by plugging in different USB port. Then I tried USB stick. USB stick also works by plugging in different USB port. So It seems USB does not work in general with one of two controller as you say.

Interesting... Is there a way for you to run linux or *BSD and get the debug output of them booting up (dmesg)? I'd be interested to see if they end up with the same routing table info. Since those are all hardwired lines, our routing table should match up with others.

[mt]

Replying to mmlr:

Interesting... Is there a way for you to run linux or *BSD and get the debug output of them booting up (dmesg)? I'd be interested to see if they end up with the same routing table info. Since those are all hardwired lines, our routing table should match up with others.

Hi, I will add dmesg (Ubuntu 11.04)

[mt]

dmesg by Ubuntu 11.04

[mmlr]

Replying to mt:

Hi, I will add dmesg (Ubuntu 11.04)

Thanks! The routing table info we construct seems fine when cross checked with Linux. The only thing missing is the Matrox card, but I already have a theory what's going on there. In any case, the two USB controllers are the same, one on 16 and the other on 23 which should be fine.

Under Haiku, can you please try plugging in and out the mouse or other devices into the non working ports first. Then enter the kernel debugger (with the kernel_debugger command in Terminal or the Alt-SysRq-D shortcut) and execute the "ints" KDL command. Then exit KDL with the "continue" command, the output of "ints" should now have been written to the syslog. Can you please post such a syslog?

[mmlr]

Looks like the missing Matrox card match could very well be the problem here. The matrox driver will actually install an interrupt handler and enable interrupts. But since it thinks it's on the (unmatched, still BIOS assigned) interrupt line 11, it doesn't get anything there. On the other hand it actually is mapped to interrupt line 16 on the IO-APIC, together with two PCIe ports, a PCI brige, the MEI controller and the one EHCI controller. The EHCI controller is the only one that actually has a handler installed at 16. The interrupt code now sees lots of unhandled interrupts on 16 because the matrox driver enabled them, but attached the interrupt handler to the wrong vector 11 (not knowing any better due to the missing match of the PCI routing table). Since there is only one handler installed for vector 16 (EHCI) the interrupt code now concludes that it is a non-shared vector where the handler is defunct and simply disables the interrupt vector alltogether (this is printed to the syslog, line 2066 in the attached one: Disabling unhandled io interrupt 16). The legitimate EHCI interrupts now don't go through anymore and the devices attached to the ports handled by that controller fail...

If you can, please still provide the "ints" KDL output, to verify that my theory is at work at all. Please also try running Haiku in failsafe video mode so the matrox driver isn't used. That should then result in the interrupt not being disabled and USB devices should continue to work.

[mt]

Replying to mmlr:

Under Haiku, can you please try plugging in and out the mouse or other devices into the non working ports first. Then enter the kernel debugger (with the kernel_debugger command in Terminal or the Alt-SysRq-D shortcut) and execute the "ints" KDL command. Then exit KDL with the "continue" command, the output of "ints" should now have been written to the syslog. Can you please post such a syslog?

Replying to mmlr:

If you can, please still provide the "ints" KDL output, to verify that my theory is at work at all. Please also try running Haiku in failsafe video mode so the matrox driver isn't used. That should then result in the interrupt not being disabled and USB devices should continue to work.

Hi, I will add bellow two outputs.

• Boot with mouse plugged to non working port and then plug to working port. then perform KDL "ints" command.
• Remove Matrox drivers (because fallsafe video mode was not working), then boot with mouse plugged to non working port. then perform KDL "ints" command.

By Removing Matrox drivers, USB mouse & stick works well with non working ports.

[mt]

Syslog with perform KDL "ints" command.

[mt]

Syslog without Matrox drivers

[mmlr]

Can you please retry with hrev41726 from trunk and attach a new syslog? It quite possibly fixes this issue.

[mt]

Replying to mmlr:

Can you please retry with hrev41726 from trunk and attach a new syslog? It quite possibly fixes this issue.

Hi, I tested hrev41736 with USB mouse connected to non-working port, but mouse still does not work.

[mt]

Syslog with mouse connected to non-working port

[mmlr]

Replying to mt:

Replying to mmlr:

Can you please retry with hrev41726 from trunk and attach a new syslog? It quite possibly fixes this issue.

Hi, I tested hrev41736 with USB mouse connected to non-working port, but mouse still does not work.

Just to make sure, this is a build from trunk codebase, not r1alpha3, right? If you compile yourself, can you uncomment the tracing in browser:haiku/trunk/src/system/kernel/arch/x86/irq_routing_table.cpp#L19 making it "#define TRACE_PRT", recompile and attach a new syslog from that? This should yield some output to see what the structure is coming from ACPI here.

[mt]

Replying to mmlr:

Just to make sure, this is a build from trunk codebase, not r1alpha3, right? If you compile yourself, can you uncomment the tracing in browser:haiku/trunk/src/system/kernel/arch/x86/irq_routing_table.cpp#L19 making it "#define TRACE_PRT", recompile and attach a new syslog from that? This should yield some output to see what the structure is coming from ACPI here.

Hi, I will add syslog with enabling TRACE_PRT.

[mt]

Syslog with enabling TRACE_PRT

[mmlr]

Infer PCI irq routing from parent pins.

[mmlr]

I've attached a patch that tries to ensure all PCI devices have a matching IRQ routing entry. It does that by calculating the routing entry based on the parent bridge pins. Can you please apply this patch, try it and post a new syslog?

[mt]

Replying to mmlr:

I've attached a patch that tries to ensure all PCI devices have a matching IRQ routing entry. It does that by calculating the routing entry based on the parent bridge pins. Can you please apply this patch, try it and post a new syslog?

Thanks! mouse works well with hrev41757 + patch, syslog will be added.

[mt]

Syslog (hrev41757 + patch)

[mmlr]

Thanks for checking! The syslog looks perfect (thanks for also including the ints output, it verifies that the graphics card actually works with calculated routing). Commited in hrev41758 (trunk) and applied to alpha3 branch in hrev41759.