Scanning problems - machine lockups
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 7 lines · Stephen Kitchener
The only thing that might be odd is that the scanner's scsi card and the display card are using the same IRQ, but I thought that IRQ sharing was ok in the new kernels. The display card is an AGP type and the scsi card is pci.
As you might have guessed, I am at a loss as to what to do next. Any help appriciated, even suggestions as to how I can track down what I haven't done (yet!)
Sharing interrupts could be the problem. Interrupt sharing is supported in the kernel as far as two different drivers being able to register a handler for the same interrupt, but not much beyond that. From studying the code I don't find any handling of unclaimed or spurious interrupts.
Some drivers (like video cards) do not register a handler for their card's interrupt. So when another driver (like the advansys driver) shares an interrupt with this card's "unregistered" interrupt there is no one left to handle the interrupt. The system will loop taking an interrupt from the card. I've observed this using the frame buffer driver. Note: this problem is unnoticed if the (video) card does not share an interrupt with another driver, because (at least on x86) Linux does not enable the PIC IRQ bit for IRQs that do not have registered interrupted handlers.
For Linux I think the right way to handle this is to have each (SA_SHIRQ) sharing capable interrupt handler return a TRUE or FALSE value indicating whether the interrupt belongs to the driver. In kernel/irq.c:handle_IRQ_event() check the return value. If after one pass through all of the interrupt (action) handlers no one has claimed the inerrupt then log a warning message (spurious interrupt) and clear the interrupt. The difficult/painstaking problem is that all SA_SHIRQ drivers need to be changed to return a return value to make this work.
Anyway the simplest solution for you is probably if you can is to put assign the video card its own interrupt. Putting the two advansys cards on the same interrupt is fine. I have used interrupt sharing between multiple advansys cards and and ethernet cards without a problem.
--
Bob Frey
[email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 7 lines · [email protected] said:
For Linux I think the right way to handle this is to have each (
SA_SHIRQ) sharing capable interrupt handler return a TRUE or FALSE value indicating whether the interrupt belongs to the driver. In kernel/irq.c:handle_IRQ_event() check the return value. If after one pass through all of the interrupt (action) handlers no one has claimed the inerrupt then log a warning message (spurious interrupt) and clear the interrupt.
There exists hardware on which it's impossible to know for sure whether an interrupt was generated or not. Upon receiving what might have been a 'status change' IRQ you check the status register. If it's reading the same as when you last looked at it, you have know way to be sure that it hasn't actually changed twice.
So you'd have to have a YES/NO/MAYBE return code, which means you'd still want to deal with the case of an IRQ storm with the only handler returning MAYBE. And in reality, your first pass through all the drivers would simply be to change the prototype and make them return MAYBE. And many of them would stay that way for a _loooong_ time.
Also, you don't necessarily need to mask the IRQ just because you got a single spurious trigger. It's only really necessary if you're getting inundated with so many IRQs that the system is falling over.
So your heuristic might be something like...
Each jiffy, reset the 'spurious IRQ' count for each IRQ.
Each time an IRQ is triggered, note the 'maximum' return code from the
handlers called (where NO < MAYBE < YES).
If YES, goto out:
If MAYBE, increase the spurious IRQ count for this IRQ by 1
If NO, increase the spurious IRQ count for this IRQ by 100
If the spurious IRQ count for this IRQ has reached <a suitable number>,
then disable the IRQ.
out:
Return from irq.
Perhaps you don't want to touch the whole list of IRQ counts every jiffy. Perhaps you could reset it to zero on each YES response. Or something.
And if you start randomly disabling IRQs because they're triggering too often, then you'll probably need a way for a device driver to force you to turn them back on again, like kick_irq().
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 22 lines · Bob Frey
Quoted 7 lines · Stephen Kitchener
The only thing that might be odd is that the scanner's scsi card and the display card are using the same IRQ, but I thought that IRQ sharing was ok in the new kernels. The display card is an AGP type and the scsi card is pci.
As you might have guessed, I am at a loss as to what to do next. Any help appriciated, even suggestions as to how I can track down what I haven't done (yet!)
Sharing interrupts could be the problem. Interrupt sharing is supported in the kernel as far as two different drivers being able to register a handler for the same interrupt, but not much beyond that. From studying the code I don't find any handling of unclaimed or spurious interrupts.
Some drivers (like video cards) do not register a handler for their card's interrupt. So when another driver (like the advansys driver) shares an interrupt with this card's "unregistered" interrupt there is no one left to handle the interrupt. The system will loop taking an interrupt from the card. I've observed this using the frame buffer driver. Note: this problem is unnoticed if the (video) card does not share an interrupt with another driver, because (at least on x86) Linux does not enable the PIC IRQ bit for IRQs that do not have registered interrupted handlers.
Quoted 8 lines
For Linux I think the right way to handle this is to have each (
SA_SHIRQ) sharing capable interrupt handler return a TRUE or FALSE value indicating whether the interrupt belongs to the driver. In kernel/irq.c:handle_IRQ_event() check the return value. If after one pass through all of the interrupt (action) handlers no one has claimed the inerrupt then log a warning message (spurious interrupt) and clear the interrupt. The difficult/painstaking problem is that allSA_SHIRQdrivers need to be changed to return a return value to make this work.
There is no ordering of interrupts with respect to transactions in PCI. As a result, getting interrupts that does not match a pending interrupt condition as seen by driver can happen, without the interrupt being spurious.
As a result, the 2 following assertions:
- All interrupts in PCI are spurious
- No interrupt is PCI is spurious
Are less wrong than asserting that some interrupts in PCI are relevant and some are spurious. :-)
And btw, some hardwares, notably Intel ones, seems to ensure coherency prior to deliver interrupts. This is a useless work when the IRQ is actually shared and does only make sense for ISA or ISA-like PCI devices and in situations where the IRQ is not actually shared.
Quoted 4 lines
Anyway the simplest solution for you is probably if you can is to put assign the video card its own interrupt. Putting the two advansys cards on the same interrupt is fine. I have used interrupt sharing between multiple advansys cards and and ethernet cards without a problem.
In theory, the O/S should warn _loudly_ if any PCI device hasn't a software driver attached, for the reason there is no generic way to actually quiesce completely a PCI device. As a result, loading drivers after boot or just loading drivers with interrupt enabled at boot is unsafe with PCI devices. This shall be considered, even if the risk of a breakage is generally very low.
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 33 lines · Bob Frey
Quoted 8 lines · Stephen Kitchener
The only thing that might be odd is that the scanner's scsi card and the display card are using the same IRQ, but I thought that IRQ sharing was ok in the new kernels. The display card is an AGP type and the scsi card is pci.
As you might have guessed, I am at a loss as to what to do next. Any help appriciated, even suggestions as to how I can track down what I haven't done (yet!)
Sharing interrupts could be the problem. Interrupt sharing is supported in the kernel as far as two different drivers being able to register a handler for the same interrupt, but not much beyond that. From studying the code I don't find any handling of unclaimed or spurious interrupts.
Some drivers (like video cards) do not register a handler for their card's interrupt. So when another driver (like the advansys driver) shares an interrupt with this card's "unregistered" interrupt there is no one left to handle the interrupt. The system will loop taking an interrupt from the card. I've observed this using the frame buffer driver. Note: this problem is unnoticed if the (video) card does not share an interrupt with another driver, because (at least on x86) Linux does not enable the PIC IRQ bit for IRQs that do not have registered interrupted handlers.
For Linux I think the right way to handle this is to have each (
SA_SHIRQ) sharing capable interrupt handler return a TRUE or FALSE value indicating whether the interrupt belongs to the driver. In kernel/irq.c:handle_IRQ_event() check the return value. If after one pass through all of the interrupt (action) handlers no one has claimed the inerrupt then log a warning message (spurious interrupt) and clear the interrupt. The difficult/painstaking problem is that allSA_SHIRQdrivers need to be changed to return a return value to make this work.
Quoted 4 lines
Anyway the simplest solution for you is probably if you can is to put assign the video card its own interrupt. Putting the two advansys cards on the same interrupt is fine. I have used interrupt sharing between multiple advansys cards and and ethernet cards without a problem.
Hi Bob and the list,
I eventually succeeded in putting the grahics card onto a different IRQ from ether of the SCSI cards. Not without some problems though. The AGP card would follow what ever IRQ I assigned the PCI slot nearest it. The mobo is an ASUS P2BD btw. The only way I could make the change was to swap the ethernet card with the scsi card. The Ethernet card now has the same IRQ as the Graphics card.
I would try a PCI graphics card, but I haven't one. Just in case the AGP card is getting in the way.
Any, I thought that it had cured the problem, but after a few scans, admittedly more than before, the scan head didn't return on the last scan that was successfully started.
Trying to scan again, hoping that it would reset the scanner and carry on, ... nothing, no response from scanner.
So.. could it be the scsi driver (Advansys 3940uw, in the kernel), or a broken scanner itself?. Is there a way I can test this, run tests, switch on debug etc ?
Scsi device is set up as follows...
Device Information for AdvanSys SCSI Host 0:
Target IDs Detected: 1, 7, (7=Host Adapter)
Host: scsi0 Channel: 00 Id: 01 Lun: 00
Vendor: UMAX Model: Astra 2400S Rev: V1.1
Type: Scanner ANSI SCSI revision: 02
EEPROM Settings for AdvanSys SCSI Host 0:
Serial Number: AA48A919D387
Host SCSI ID: 7, Host Queue Size: 253, Device Queue Size: 63
termination: 0 (Automatic), bios_ctrl: ffe7
Target ID: 0 1 2 3 4 5 6 7 8 9 A B C D E F Disconnects: Y N Y Y Y Y Y Y Y Y Y Y Y Y Y Y Command Queuing: Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Start Motor: Y N Y Y Y N Y Y Y Y Y Y Y Y Y Y
Synchronous Transfer: Y N Y Y Y Y Y Y Y Y Y Y Y Y Y Y
Ultra Transfer: Y N Y Y Y Y Y Y Y Y Y Y Y Y Y Y
Wide Transfer: Y N Y Y Y Y Y Y Y Y Y Y Y Y Y Y
Quoted 8 lines
--
Bob Frey
[email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Signature · 5 lines
Stephen Kitchener - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
Quoted 3 lines · Stephen Kitchener
Any, I thought that it had cured the problem, but after a few scans, admittedly more than before, the scan head didn't return on the last scan that was successfully started.
It sounds like you did solve the "lock the machine solid" problem by putting the video card on its own interrupt. Does anyone specifically maintain kernel/irq.c? - please submit some spurious interrupt handling (interrupts generated by devices that don't have a handler) along the lines of what David Woodhouse suggested. I would expect it to deactivate the IRQ and report the problem to the user so they can fix it themselves probably by changing the IRQ configuration - not perfect but better than locking up the machine with no message.
Quoted 2 lines
Trying to scan again, hoping that it would reset the scanner and carry on, ... nothing, no response from scanner.
So now apparently the scanner doesn't respond after a few scans, but the system continues to work OK. This sounds like a problem with either the scanner sw, advansys driver, or the scanner.
1) I'm not familiar with SANE (is that what you're using?), but it probably has some test programs. Please try them if they exist and report the results.
2) Please send the output of /proc/scsi/advansys/1 file after the hang. Also you said you have another advansys card (/proc/scsi/advansys/0) with a lot of devices attached. Do they all work correctly after the scanner hang? If so, the problem is isolated to the second card and it's not a general driver problem.
3) Another experiment is to compile the advansys driver as a module if you can and after the hang, rmmod/insmod it to see if the scanner starts working again. I would expect it to because this will reset the driver, adapter, and SCSI bus.
Signature · 6 lines
Bob Frey [email protected] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/