Hi everybody,
I noticed a conversation some days ago that also mentioned something
about PLX chips and a certain problem resulting in loss of interrupt
signals.
I'm writing a driver for a PCI-based device (an embedded USB Host
Controller) and it uses a PLX bridge (device ID 5406). Although I've set
up the device correctly and a logical analyzer shows the interrupts
being generated on the USB HC chip, nothing comes past the bridge, thus
nothing reaches the system. I use a typical pci_enable_device() followed
but some request_region() and of course request_irq() on a kernel
2.6.10-rc3 (i386 system, VIA KT133, no APIC...)
Does this have something to do with the discussion about PLX chips
mentioned above? If it does, can anybody make clear what I have to do to
see those interrupts coming?
You can find the mail in question at:
http://seclists.org/lists/linux-kernel/2005/Jan/0792.html
Thanks,
Dimitris
On Thu, 13 Jan 2005, Dimitris Lampridis wrote:
> Hi everybody,
> I noticed a conversation some days ago that also mentioned something
> about PLX chips and a certain problem resulting in loss of interrupt
> signals.
>
> I'm writing a driver for a PCI-based device (an embedded USB Host
> Controller) and it uses a PLX bridge (device ID 5406). Although I've set
> up the device correctly and a logical analyzer shows the interrupts
> being generated on the USB HC chip, nothing comes past the bridge, thus
> nothing reaches the system. I use a typical pci_enable_device() followed
> but some request_region() and of course request_irq() on a kernel
> 2.6.10-rc3 (i386 system, VIA KT133, no APIC...)
> Does this have something to do with the discussion about PLX chips
> mentioned above? If it does, can anybody make clear what I have to do to
> see those interrupts coming?
>
> You can find the mail in question at:
> http://seclists.org/lists/linux-kernel/2005/Jan/0792.html
>
> Thanks,
> Dimitris
Make sure you execute pci_enable_device() __before__ you believe
the IRQ number in the structure.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
On Thu, 2005-01-13 at 13:49, linux-os wrote:
> On Thu, 13 Jan 2005, Dimitris Lampridis wrote:
>
> > Hi everybody,
> > I noticed a conversation some days ago that also mentioned something
> > about PLX chips and a certain problem resulting in loss of interrupt
> > signals.
> >
> > I'm writing a driver for a PCI-based device (an embedded USB Host
> > Controller) and it uses a PLX bridge (device ID 5406). Although I've set
> > up the device correctly and a logical analyzer shows the interrupts
> > being generated on the USB HC chip, nothing comes past the bridge, thus
> > nothing reaches the system. I use a typical pci_enable_device() followed
> > but some request_region() and of course request_irq() on a kernel
> > 2.6.10-rc3 (i386 system, VIA KT133, no APIC...)
> > Does this have something to do with the discussion about PLX chips
> > mentioned above? If it does, can anybody make clear what I have to do to
> > see those interrupts coming?
> >
> > You can find the mail in question at:
> > http://seclists.org/lists/linux-kernel/2005/Jan/0792.html
> >
> > Thanks,
> > Dimitris
>
> Make sure you execute pci_enable_device() __before__ you believe
> the IRQ number in the structure.
I was doing that all the time. I'm calling pci_enable_device(pdev), then
reading pdev->irq, then calling request_irq(pdev->irq,...). But I don't
get interrupts. Is it possible for the compiler to rearrange the order
of execution?
I was talking about that strange phenonomenon you were saying with PLX
and interrupts going mad when initializing the device, ie the trick with
enable->disable->do whatever(this is where I need help if it applies to
me)->reenable.
Thanks,
Dimitris
On Thu, 13 Jan 2005, Dimitris Lampridis wrote:
> On Thu, 2005-01-13 at 13:49, linux-os wrote:
>> On Thu, 13 Jan 2005, Dimitris Lampridis wrote:
>>
>>> Hi everybody,
>>> I noticed a conversation some days ago that also mentioned something
>>> about PLX chips and a certain problem resulting in loss of interrupt
>>> signals.
>>>
>>> I'm writing a driver for a PCI-based device (an embedded USB Host
>>> Controller) and it uses a PLX bridge (device ID 5406). Although I've set
>>> up the device correctly and a logical analyzer shows the interrupts
>>> being generated on the USB HC chip, nothing comes past the bridge, thus
>>> nothing reaches the system. I use a typical pci_enable_device() followed
>>> but some request_region() and of course request_irq() on a kernel
>>> 2.6.10-rc3 (i386 system, VIA KT133, no APIC...)
>>> Does this have something to do with the discussion about PLX chips
>>> mentioned above? If it does, can anybody make clear what I have to do to
>>> see those interrupts coming?
>>>
>>> You can find the mail in question at:
>>> http://seclists.org/lists/linux-kernel/2005/Jan/0792.html
>>>
>>> Thanks,
>>> Dimitris
>>
>> Make sure you execute pci_enable_device() __before__ you believe
>> the IRQ number in the structure.
>
> I was doing that all the time. I'm calling pci_enable_device(pdev), then
> reading pdev->irq, then calling request_irq(pdev->irq,...). But I don't
> get interrupts. Is it possible for the compiler to rearrange the order
> of execution?
No! Not that much! A sequence-point like the ';' after the first call
will guarantee that everything up to that point was executed. Make
sure you requested a level interrupt, i.e. SA_INTERRUPT|SA_SHIRQ.
> I was talking about that strange phenonomenon you were saying with PLX
> and interrupts going mad when initializing the device, ie the trick with
> enable->disable->do whatever(this is where I need help if it applies to
> me)->reenable.
>
You can look at /proc/interrupts to see if your device ever interrupted.
If it did, then got shut off, you probably forgot to return IRQ_HANDLED
in the interrupt-service-routine. The newer code requires a return-value
from the ISR.
If it got a bunch of spurious interrupts that made it impossible
to initialize the device properly, then use some flag to tell
your ISR that the device wasn't enabled yet. If it got an interrupt
before the device was enabled, the ISR writes 0 to the PLX CSR after
reading and throwing away the existing value. That will quiet the
device until it can be properly initialized.
If you never got any interrupts, then you have some other bug.
You can readily force the PLX to generate interrupts for testing
purposes.
> Thanks,
> Dimitris
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
First of all, thanks for your concern.
On Thu, 2005-01-13 at 14:49, linux-os wrote:
> You can look at /proc/interrupts to see if your device ever interrupted.
> If it did, then got shut off, you probably forgot to return IRQ_HANDLED
> in the interrupt-service-routine. The newer code requires a return-value
> from the ISR.
>
No interrupt at /proc/interrupts. The ISR never gets called. If it
would, it returns IRQ_HANDLED.
As I mentioned on the first mail, using a logical analyzer I saw the
device generating interrupts behind the PCI bridge, but I didn't see
them pass through the bridge, so I didn't expect to read something at
/proc/interrupts.
> If it got a bunch of spurious interrupts that made it impossible
> to initialize the device properly, then use some flag to tell
> your ISR that the device wasn't enabled yet. If it got an interrupt
> before the device was enabled, the ISR writes 0 to the PLX CSR after
> reading and throwing away the existing value. That will quiet the
> device until it can be properly initialized.
>
Same here, ISR never gets called.
> If you never got any interrupts, then you have some other bug.
> You can readily force the PLX to generate interrupts for testing
> purposes.
How can I do that? Don't bother explaining everything. Maybe a link
to somewhere on the net where I can learn more?
Thanks,
Dimitris