On Tue, 17 Apr 2012, Zbigniew Luszpinski wrote: > I think we can narrow down this to APIC handling. There must be some > generic, tiny incompatibility in Linux when compared to other OS. APIC is > well known evil on Linux when I search the net for interrupts problem on > Linux. If we would be able to isolate and fix the issue we could improve > Linux compatibility as a platform. > I had before nforce2 and nforce430 - ohci worked great. Will try to hammer > Nvidia again for chipset specs and errata of MCP78. > > What I have seen M$ and Solaris (do not know how to check this on FreeBSD) > use in APIC mode level interrupt handler and Linux uses fasteoi. I have > rewritten kernel I have to use level interrupt handler and as far I > remeber it helped a lot. I dropped it because it helped a lot but not > solved problem fully. See attachement. Here is my comment on nvnews.net > when I posted it: > http://www.nvnews.net/vbulletin/showthread.php?t=135022&highlight=OHCI&page=2 > See post #19 > > The most important part of this patch is by default kernel uses for all > APIC ready devices: > set_irq_chip_and_handler_name(irq, &ioapic_chip, > handle_fasteoi_irq, > "fasteoi"); > my patch just changes it to this: > set_irq_chip_and_handler_name(irq, &ioapic_chip, > handle_level_irq, > "level"); > > the rest of code just do commandline parsing. Not important. Until we know the real reason for the problem, there's no good justification for making this change. > > Somewhere in the bug report you mentioned that even though the driver > > freezes, the interrupt count keeps going up. This suggests two > > possibilities: The interrupts aren't getting delivered to ohci-hcd, or > > they are getting delivered but ohci-hcd isn't handling them right. Do > > you know which is the case? > > No. I would be glad to test this if you give me some tips or patches how > to check this. I can build and use vanilla kernel 3.3.2 and 3.4-rc3 for > testing. Which one do you prefer to use as debug platform for this > problem? I can also build other kernel if you have better option. Either kernel version will be okay. > > > Because for many years nobody was able to make a fix for this how > > > about printing warning when 10de:077b, 10de:077d controllers are > > > detected and APIC is active: "This usb 1.1 controller freezes on > > > Linux when APIC is enabled. Use noapic or acpi=noirq kernel boot > > > parameters to workaround or use PCI/PCIe card with usb ports for usb > > > 1.1 devices" > > I'd prefer to try and solve the problem first. > > Me too :) I tried to fix that but I'm not ohci/apic guru and need help > from someone here. I know nothing at all about APIC, but at least I can help with the OHCI side. Try applying the patch below, and enable CONFIG_USB_DEBUG. Let's see what the dmesg log shows after the driver stops working -- there should be a line printed for every OHCI interrupt. Alan Stern Index: usb-3.4/drivers/usb/host/ohci-hcd.c =================================================================== --- usb-3.4.orig/drivers/usb/host/ohci-hcd.c +++ usb-3.4/drivers/usb/host/ohci-hcd.c @@ -755,6 +755,8 @@ static irqreturn_t ohci_irq (struct usb_ * work on all systems (edge triggering for OHCI can be a factor). */ ints = ohci_readl(ohci, ®s->intrstatus); + ohci_dbg(ohci, "ohci_irq: ints %04x enable %04x\n", ints, + ohci_readl(ohci, ®s->intrenable)); /* Check for an all 1's result which is a typical consequence * of dead, unclocked, or unplugged (CardBus...) devices -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
