Re: XT-PIC interrupts blocked by usbserial ? [Was Re: Intel ICH9M bug : sata unusable with usbserial]

[Mark Lord <kernel@teksavvy.com>]

On 11-03-03 09:58 AM, Philippe De Muyter wrote:
> Summary :
> 
> When I started to listen to a USB serial GPS receiver, the interrupts
> of my sata disk were blocked until reboot :(


Blocked until reboot, or until you unplug the GPS/serial thingie from the USB port?


> Switching in the BIOS from 'APIC disabled' to 'APIC enabled' made the problem
> disappear.
> 
> On Wed, Mar 02, 2011 at 08:34:50AM -0500, Mark Lord wrote:
>> On 11-03-01 10:00 AM, Philippe De Muyter wrote:
>>> On Tue, Mar 01, 2011 at 09:16:27AM -0500, Greg KH wrote:
>>>> On Tue, Mar 01, 2011 at 01:34:52PM +0100, Philippe De Muyter wrote:
>>>>> previously we had all but one usb interrupts on the same line as ata_piix :
>>>>>   5:      17183    XT-PIC-XT-PIC    ata_piix, ata_piix, ehci_hcd:usb1, ehci_hcd:usb2, uhci_hcd:usb3, uhci_hcd:usb5, uhci_hcd:usb6, uhci_hcd:usb7, uhci_hcd:usb8
>>>>> while now they are spread on different lines : 16, 18, 19, 21 and 22
>>>>>
>>>>> So I wonder if there is still a bug, but that it is not triggered anymore.
>>>>>
>>>>> Is there a way to tell which interrupt line the USB GPS receiver is connected
>>>>> to ?
>>>>
>>>> See which USB bus the device is on, using lsusb.  It should match up
>>>> with the usbX number in the above list.
>>>
>>> Given that I get :
>>>
>>>   tmp199:~ # lsusb
>>>   ...
>>>   Bus 007 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
>>>   tmp199:~ # cat /proc/interrupts
>>> 	     CPU0       CPU1
>>>   ...
>>>    19:     996143     995511   IO-APIC-fasteoi   ata_piix, ata_piix, uhci_hcd:usb5, uhci_hcd:usb7
>>>   tmp199:~ #
>>>
>>> my USB GPS receiver and my sata disk still share the same interrupt, I assume ?
>>>
>>> What's changed now is that this interrupt line is now IO-APIC-fasteoi instead
>>> of XT-PIC-XT-PIC.  Maybe there's something to look at there ?
>>>
>>>>
>>>> Glad enabling APIC in your BIOS fixed this.
>>>
>>> I am glad too :)
>>
>> Nothing got "fixed" by doing that.
>> Swept under the rug, yes.
>>
>> But the bug is still there.
> 
> If it is a bug (what I also believe) it is not a new one :
> 
> Before installing 2.6.37-20-desktop (opensuse 11.4) on this new hardware,
> I had the same problem with 2.6.31.14-0.6-desktop (opensuse 11.2) and
> with 2.6.22.18-0.2-default (opensuse 10.3)

Mmm.. so an old bug.  Nasty, those.  :)

What is most likely happening here, is that the USB interrupt handler
is returning IRQ_HANDLED under some condition where IRQ_NONE is required.

In other words, USB thought it got an interrupt, but didn't really,
but since it returns IRQ_HANDLED regardless, then other
device drivers sharing that IRQ don't necessarily get called.
If this happens repeatedly, then it could disrupt the other devices.

Now, that's not overly likely, but then again it's probably not
well tested with everyone using APICs nowadays.

Or, perhaps the PL2303 driver leaves an interrupt active/pending
without clearing it in hardware, so the interrupt keeps recurring
over and over.  This (unlikely) is easy to check for, by watching
the /proc/interrupts count for the USB on your APIC-enabled kernel.

If the numbers increase at a phenomenal rate, then there might
be an issue.  With an active GPS, one would expect the numbers to
be incrementing steadily, say a few dozen or a hundred or so per second.

Cheers