Opened 8 years ago

Closed 8 years ago

#7520 closed bug (fixed)

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

Reported by: mt Owned by: mmlr
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: yes Platform: x86

Description

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

Attachments (10)

syslog.txt (129.8 KB) - added by mt 8 years ago.
Syslog (IO-APIC enabled)
listusb.txt (5.9 KB) - added by mt 8 years ago.
Output of listusb (IO-APIC is disabled)
listdev.txt (2.7 KB) - added by mt 8 years ago.
Output of listdev (IO-APIC is disabled)
dmesg.txt (52.3 KB) - added by mt 8 years ago.
dmesg by Ubuntu 11.04
syslog2.txt (130.8 KB) - added by mt 8 years ago.
Syslog with perform KDL "ints" command.
syslog3.txt (132.7 KB) - added by mt 8 years ago.
Syslog without Matrox drivers
syslog_r41736.txt (140.3 KB) - added by mt 8 years ago.
Syslog with mouse connected to non-working port
syslog_r41736_TRACE_PRT.txt (146.0 KB) - added by mt 8 years ago.
Syslog with enabling TRACE_PRT
pci_route_fallback.diff (7.9 KB) - added by mmlr 8 years ago.
Infer PCI irq routing from parent pins.
syslog_r41757+patch.txt (138.5 KB) - added by mt 8 years ago.
Syslog (hrev41757 + patch)

Download all attachments as: .zip

Change History (28)

Changed 8 years ago by mt

Attachment: syslog.txt added

Syslog (IO-APIC enabled)

Changed 8 years ago by mt

Attachment: listusb.txt added

Output of listusb (IO-APIC is disabled)

Changed 8 years ago by mt

Attachment: listdev.txt added

Output of listdev (IO-APIC is disabled)

comment:1 Changed 8 years ago by anevilyak

Owner: changed from axeld to mmlr
Status: newassigned
Version: R1/alpha2R1/Development

comment:2 Changed 8 years ago by 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.

Last edited 8 years ago by stargatefan (previous) (diff)

comment:3 in reply to:  description ; Changed 8 years ago by 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?

comment:4 in reply to:  2 Changed 8 years ago by 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)

comment:5 in reply to:  3 ; Changed 8 years ago by 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...

comment:6 in reply to:  5 ; Changed 8 years ago by 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.

comment:7 in reply to:  6 ; Changed 8 years ago by 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)

Changed 8 years ago by mt

Attachment: dmesg.txt added

dmesg by Ubuntu 11.04

comment:8 in reply to:  7 ; Changed 8 years ago by 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?

comment:9 Changed 8 years ago by 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.

comment:10 in reply to:  8 Changed 8 years ago by 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.

Changed 8 years ago by mt

Attachment: syslog2.txt added

Syslog with perform KDL "ints" command.

Changed 8 years ago by mt

Attachment: syslog3.txt added

Syslog without Matrox drivers

comment:11 Changed 8 years ago by mmlr

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

comment:12 in reply to:  11 ; Changed 8 years ago by 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.

Changed 8 years ago by mt

Attachment: syslog_r41736.txt added

Syslog with mouse connected to non-working port

comment:13 in reply to:  12 ; Changed 8 years ago by 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.

comment:14 in reply to:  13 Changed 8 years ago by 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.

Changed 8 years ago by mt

Attachment: syslog_r41736_TRACE_PRT.txt added

Syslog with enabling TRACE_PRT

Changed 8 years ago by mmlr

Attachment: pci_route_fallback.diff added

Infer PCI irq routing from parent pins.

comment:15 Changed 8 years ago by mmlr

Has a Patch: set

comment:16 Changed 8 years ago by 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?

comment:17 in reply to:  16 Changed 8 years ago by 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.

Changed 8 years ago by mt

Attachment: syslog_r41757+patch.txt added

Syslog (hrev41757 + patch)

comment:18 Changed 8 years ago by mmlr

Resolution: fixed
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.