On Wed, 12 Aug 2009, wixor wrote: > Hello all, > > I am having problems with interrupts on USB line. When in PIC mode, > after enabling wireless card and making it do someting (which has > separate irq), there are 100000 unhandled interrupts on ehci irq, then > kernel disables it and the wireless doesn't work (neither before nor > after disabling irq line). If I boot with irqpoll, usb and wireless > work like a charm. If I boot with irqfixup, both work too, but it > happens sometimes that those interrupts start hitting again later. > When in APIC mode, when using C2 cpu sleep state (and only then), > right after boot i get 200000 wakeups / sec in powertop, but no > unwanted irqs appear. Wireless card is unaffected (and works). After > playing with apic options, i can delay those wakeups by 5 minutes > (pretty much exactly), but they will come anyway. Have you tried removing the wireless card entirely? If that solves the problem then there's probably no point in messing around with ehci-hcd. > The hardware is fujistu-siemens amilo pro v3515 laptop with via > chipset (p4m900) and celeron m cpu, the wireless card is on pci bus. > Testing on kernel version 2.9.29. . > > I have noticed "EHCI: BIOS handoff failed" message dmesg, so I went > investigating. What I have found out is that prior to doing any > handoff, both semaphores are marked as taken (set to 1), and moreover > both Os Semaphore SMI Enable and Os Semaphore SMI Bit are set. Under > such circumstances current handoff code does nothing (or rather: > nothing it does has any result), so I made it sanitize the situation > (clear os semaphore and os semaphore smi bit) before doing handoff. It > turned out, that when requesting handoff the os semaphore smi bit is > set (which is correct), but nothing more happens (it doesn't ever get > cleared, nor does bios relinquish its semaphore). > > Here is the code snippet I wrote (from drivers/usb/host/pci-quirks.c): > and the results are: > > pci 0000:00:10.4: EHCI: BIOS handoff > pci 0000:00:10.4: EHCI: current state: > pci 0000:00:10.4: EHCI: SMI enabled: 1, SMI bit: 1, CTLSTS = e00c2000 > pci 0000:00:10.4: EHCI: OS semaphore: 1, BIOS semaphore: 1, SUP = 01010001 > pci 0000:00:10.4: EHCI: SMI enabled: 1, SMI bit: 1, CTLSTS = e00c2000 > pci 0000:00:10.4: EHCI: clearing SMI bit > pci 0000:00:10.4: EHCI: SMI enabled: 1, SMI bit: 0, CTLSTS = c00c2000 > pci 0000:00:10.4: EHCI: OS semaphore: 1, BIOS semaphore: 1, SUP = 01010001 > pci 0000:00:10.4: EHCI: putting OS semaphore down Maybe you should do these two things in the opposite order, since the SMI bit gets set whenever the OS semaphore changes state. > pci 0000:00:10.4: EHCI: OS semaphore: 0, BIOS semaphore: 1, SUP = 00010001 > pci 0000:00:10.4: EHCI: requesting handoff > pci 0000:00:10.4: EHCI: SMI enabled: 1, SMI bit: 1, CTLSTS = e00c2000 > pci 0000:00:10.4: EHCI: OS semaphore: 1, BIOS semaphore: 1, SUP = 01010001 > Switched to high resolution mode on CPU 0 > pci 0000:00:10.4: EHCI: OS semaphore: 1, BIOS semaphore: 1, SUP = 01010001 > pci 0000:00:10.4: EHCI: SMI enabled: 1, SMI bit: 1, CTLSTS = e00c2000 > pci 0000:00:10.4: EHCI: BIOS handoff failed (BIOS bug?) 01010001 > > Where do I go from here? Thanks for your help and please CC me, as I'm > not subscribed to the list. You could look to see if there are any BIOS updates available for your system. Alan Stern -- 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
