* qstor driver -> irq 193: nobody cared
@ 2006-11-03 18:02 Alberto Alonso
2006-11-03 19:00 ` Sergey Vlasov
2006-11-04 18:39 ` Mark Lord
0 siblings, 2 replies; 20+ messages in thread
From: Alberto Alonso @ 2006-11-03 18:02 UTC (permalink / raw)
To: linux-kernel; +Cc: mlord
I have a Pacific Digital qstor card on irq 193. I am using kernel
2.6.17.13 SMP
The error happens every now and then. I have not been able to
figure out any triggers and I can not reproduce it on demand. Today
it happened 3 times within a 40 minutes period.
All disks connected to the card are disabled and I can't do anything
other than a reboot to get them back.
It is reported as follows:
irq 193: nobody cared (try booting with the "irqpoll" option)
<c013e19a> __report_bad_irq+0x2a/0xa0 <c013d970> handle_IRQ_event
+0x30/0x70
<c013e2b0> note_interrupt+0x80/0xf0 <c013da8c> __do_IRQ+0xdc/0xf0
<c0105799> do_IRQ+0x19/0x30 <c010391a> common_interrupt+0x1a/0x20
<c0100d91> default_idle+0x41/0x70 <c0100e60> cpu_idle+0x80/0x90
<c046699d> start_kernel+0x18d/0x1d0 <c0466330> unknown_bootoption
+0x0/0x1d0
handlers:
[<c0301300>] (qs_intr+0x0/0x220)
Disabling IRQ #193
The PCI info for the card is:
0000:01:03.0 0106: Pacific Digital Corp: Unknown device 2068 (rev 01)
Subsystem: Pacific Digital Corp: Unknown device 2068
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 193
I/O ports at eff0 [size=8]
I/O ports at efe0 [size=8]
I/O ports at efa8 [size=8]
I/O ports at efa0 [size=8]
Memory at febf0000 (64-bit, non-prefetchable) [size=64K]
Expansion ROM at febe0000 [disabled] [size=64K]
Capabilities: [40] Message Signalled Interrupts: 64bit+
Queue=0/0 Enable-
Capabilities: [50] Power Management version 2
Capabilities: [58] PCI-X non-bridge device.
This is really creating problems for me now. If anybody knows
of a dumb (ie. non-raid) PCI SATA card with 8 ports with good
Linux support for a couple hundred backs I would appreciate
it.
If there is any other info that I should provide to help
troubleshoot please let me know.
Thanks,
Alberto
--
Alberto Alonso Global Gate Systems LLC.
(512) 351-7233 http://www.ggsys.net
Hardware, consulting, sysadmin, monitoring and remote backups
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: qstor driver -> irq 193: nobody cared 2006-11-03 18:02 qstor driver -> irq 193: nobody cared Alberto Alonso @ 2006-11-03 19:00 ` Sergey Vlasov 2006-11-03 20:22 ` Alberto Alonso 2006-11-04 18:39 ` Mark Lord 1 sibling, 1 reply; 20+ messages in thread From: Sergey Vlasov @ 2006-11-03 19:00 UTC (permalink / raw) To: Alberto Alonso; +Cc: mlord, linux-kernel [-- Attachment #1: Type: text/plain, Size: 1510 bytes --] On Fri, 03 Nov 2006 12:02:53 -0600 Alberto Alonso wrote: > I have a Pacific Digital qstor card on irq 193. I am using kernel > 2.6.17.13 SMP > > The error happens every now and then. I have not been able to > figure out any triggers and I can not reproduce it on demand. Today > it happened 3 times within a 40 minutes period. > > All disks connected to the card are disabled and I can't do anything > other than a reboot to get them back. > > It is reported as follows: > > irq 193: nobody cared (try booting with the "irqpoll" option) Did you try this option? It may decrease performance, but in some cases IRQ routing is so screwed that only irqpoll helps. [...] > handlers: > [<c0301300>] (qs_intr+0x0/0x220) > Disabling IRQ #193 [..] > If there is any other info that I should provide to help > troubleshoot please let me know. The "nobody cared" error is often caused by some other device which shares the same interrupt, but Linux does not know about it (either due to broken IRQ routing tables in BIOS, or because the driver for that device is not loaded, but the device really is active and asserts its IRQ line - sometimes this also happens due to a broken BIOS). Please post complete /proc/interrupts and lspci -v output, and also information about the motherboard model and BIOS version. If your motherboard has a VIA chipset, you may also try the patch from http://lkml.org/lkml/2006/9/7/235 which attempts to fix IRQ routing on these chipsets. [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: qstor driver -> irq 193: nobody cared 2006-11-03 19:00 ` Sergey Vlasov @ 2006-11-03 20:22 ` Alberto Alonso 2006-11-03 20:52 ` Sergey Vlasov 0 siblings, 1 reply; 20+ messages in thread From: Alberto Alonso @ 2006-11-03 20:22 UTC (permalink / raw) To: Sergey Vlasov; +Cc: linux-kernel On Fri, 2006-11-03 at 22:00 +0300, Sergey Vlasov wrote: > On Fri, 03 Nov 2006 12:02:53 -0600 Alberto Alonso wrote: > > > I have a Pacific Digital qstor card on irq 193. I am using kernel > > 2.6.17.13 SMP > > > > > > irq 193: nobody cared (try booting with the "irqpoll" option) > > Did you try this option? It may decrease performance, but in some cases > IRQ routing is so screwed that only irqpoll helps. I have now switched to using that option. Will kick in after I reboot. > [...] > > handlers: > > [<c0301300>] (qs_intr+0x0/0x220) > > Disabling IRQ #193 > [..] > > If there is any other info that I should provide to help > > troubleshoot please let me know. > > The "nobody cared" error is often caused by some other device which > shares the same interrupt, but Linux does not know about it (either due > to broken IRQ routing tables in BIOS, or because the driver for that > device is not loaded, but the device really is active and asserts its > IRQ line - sometimes this also happens due to a broken BIOS). > > Please post complete /proc/interrupts and lspci -v output, and also > information about the motherboard model and BIOS version. > The system is an old Gateway 6400 server w/ dual P3 1 GHz PCUs. It is my NFS/samba file server. Here is the rest of the requested info: w100:/usr/src/linux-2.6.17.13# cat /proc/interrupts CPU0 CPU1 0: 1398199 1412518 IO-APIC-edge timer 1: 1 8 IO-APIC-edge i8042 2: 0 0 XT-PIC cascade 8: 3 1 IO-APIC-edge rtc 14: 8163 8710 IO-APIC-edge ide0 15: 5 7 IO-APIC-edge ide1 145: 0 0 IO-APIC-level ivtv0 153: 94715 121999 IO-APIC-level ide2, ide3, ide4, ide5 161: 6909 18301 IO-APIC-level ide8, ide9 169: 8323 17288 IO-APIC-level ide6, ide7 185: 1216892 92 IO-APIC-level eth0 193: 2281 1954 IO-APIC-level libata NMI: 0 0 LOC: 2810842 2810841 ERR: 0 MIS: 0 w100:/usr/src/linux-2.6.17.13# lspci -v 0000:00:00.0 Host bridge: ServerWorks CNB20LE Host Bridge (rev 06) Flags: bus master, medium devsel, latency 32 0000:00:00.1 Host bridge: ServerWorks CNB20LE Host Bridge (rev 06) Flags: bus master, medium devsel, latency 16 0000:00:02.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08) Subsystem: Intel Corp. 82559 Fast Ethernet LAN on Motherboard Flags: bus master, medium devsel, latency 64, IRQ 177 Memory at feaff000 (32-bit, non-prefetchable) [size=4K] I/O ports at b000 [size=64] Memory at fe800000 (32-bit, non-prefetchable) [size=1M] Expansion ROM at fe700000 [disabled] [size=1M] Capabilities: [dc] Power Management version 2 0000:00:03.0 Multimedia video controller: Internext Compression Inc iTVC16 (CX23416) MPEG-2 Encoder (rev 01) Subsystem: Hauppauge computer works Inc.: Unknown device 0001 Flags: bus master, medium devsel, latency 64, IRQ 145 Memory at f8000000 (32-bit, prefetchable) [size=64M] Capabilities: [44] Power Management version 2 0000:00:04.0 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07) Subsystem: Triones Technologies, Inc.: Unknown device 0001 Flags: bus master, 66MHz, medium devsel, latency 120, IRQ 153 I/O ports at bf60 [size=8] I/O ports at bf7c [size=4] I/O ports at bf58 [size=8] I/O ports at bf54 [size=4] I/O ports at b400 [size=256] Expansion ROM at fe960000 [disabled] [size=128K] Capabilities: [60] Power Management version 2 0000:00:04.1 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07) Subsystem: Triones Technologies, Inc.: Unknown device 0001 Flags: bus master, 66MHz, medium devsel, latency 120, IRQ 153 I/O ports at bf88 [size=8] I/O ports at bf84 [size=4] I/O ports at bf68 [size=8] I/O ports at bf80 [size=4] I/O ports at b800 [size=256] Capabilities: [60] Power Management version 2 0000:00:05.0 Unknown mass storage controller: Triones Technologies, Inc. HPT366/368/370/370A/372 (rev 03) Subsystem: Triones Technologies, Inc. HPT370 UDMA100 Flags: bus master, medium devsel, latency 120, IRQ 161 I/O ports at bfa0 [size=8] I/O ports at bf9c [size=4] I/O ports at bf90 [size=8] I/O ports at bf98 [size=4] I/O ports at c000 [size=256] Expansion ROM at fe980000 [disabled] [size=128K] 0000:00:06.0 Unknown mass storage controller: Triones Technologies, Inc. HPT366/368/370/370A/372 (rev 03) Subsystem: Triones Technologies, Inc. HPT370 UDMA100 Flags: bus master, medium devsel, latency 120, IRQ 169 I/O ports at bff0 [size=8] I/O ports at bfe4 [size=4] I/O ports at bfa8 [size=8] I/O ports at bfe0 [size=4] I/O ports at c400 [size=256] Expansion ROM at fe9a0000 [disabled] [size=128K] 0000:00:07.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) (prog-if 00 [VGA]) Subsystem: Gateway 2000: Unknown device 6400 Flags: bus master, stepping, medium devsel, latency 64 Memory at fd000000 (32-bit, non-prefetchable) [size=16M] I/O ports at c800 [size=256] Memory at fe9ff000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at fe9c0000 [disabled] [size=128K] Capabilities: [5c] Power Management version 2 0000:00:0f.0 ISA bridge: ServerWorks OSB4 South Bridge (rev 50) Subsystem: ServerWorks OSB4 South Bridge Flags: bus master, medium devsel, latency 0 0000:00:0f.1 IDE interface: ServerWorks OSB4 IDE Controller (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 64 I/O ports at ffa0 [size=16] 0000:00:0f.2 USB Controller: ServerWorks OSB4/CSB5 OHCI USB Controller (rev 04) (prog-if 10 [OHCI]) Subsystem: ServerWorks OSB4/CSB5 OHCI USB Controller Flags: bus master, medium devsel, latency 64, IRQ 10 Memory at fe9fe000 (32-bit, non-prefetchable) [size=4K] 0000:01:02.0 Ethernet controller: Intel Corp. 82543GC Gigabit Ethernet Controller (Copper) (rev 02) Subsystem: Intel Corp. PRO/1000 T Server Adapter Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 185 Memory at febc0000 (32-bit, non-prefetchable) [size=128K] Memory at febb0000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at feba0000 [disabled] [size=64K] Capabilities: [dc] Power Management version 2 0000:01:03.0 0106: Pacific Digital Corp: Unknown device 2068 (rev 01) Subsystem: Pacific Digital Corp: Unknown device 2068 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 193 I/O ports at eff0 [size=8] I/O ports at efe0 [size=8] I/O ports at efa8 [size=8] I/O ports at efa0 [size=8] Memory at febf0000 (64-bit, non-prefetchable) [size=64K] Expansion ROM at febe0000 [disabled] [size=64K] Capabilities: [40] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Capabilities: [50] Power Management version 2 Capabilities: [58] PCI-X non-bridge device. 0000:01:05.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1010 Ultra3 SCSI Adapter (rev 01) Subsystem: Gateway 2000: Unknown device 1040 Flags: medium devsel I/O ports at 1000 [disabled] [size=256] Memory at <ignored> (64-bit, non-prefetchable) [disabled] Memory at <ignored> (64-bit, non-prefetchable) [disabled] Capabilities: [40] Power Management version 2 0000:01:05.1 SCSI storage controller: LSI Logic / Symbios Logic 53c1010 Ultra3 SCSI Adapter (rev 01) Subsystem: Gateway 2000: Unknown device 1040 Flags: medium devsel I/O ports at 1400 [disabled] [size=256] Memory at <ignored> (64-bit, non-prefetchable) [disabled] Memory at <ignored> (64-bit, non-prefetchable) [disabled] Capabilities: [40] Power Management version 2 Thanks, Alberto -- Alberto Alonso Global Gate Systems LLC. (512) 351-7233 http://www.ggsys.net Hardware, consulting, sysadmin, monitoring and remote backups ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: qstor driver -> irq 193: nobody cared 2006-11-03 20:22 ` Alberto Alonso @ 2006-11-03 20:52 ` Sergey Vlasov 2006-11-03 23:21 ` Alberto Alonso 0 siblings, 1 reply; 20+ messages in thread From: Sergey Vlasov @ 2006-11-03 20:52 UTC (permalink / raw) To: Alberto Alonso; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 3005 bytes --] On Fri, Nov 03, 2006 at 02:22:07PM -0600, Alberto Alonso wrote: > On Fri, 2006-11-03 at 22:00 +0300, Sergey Vlasov wrote: > > On Fri, 03 Nov 2006 12:02:53 -0600 Alberto Alonso wrote: > > > > > I have a Pacific Digital qstor card on irq 193. I am using kernel > > > 2.6.17.13 SMP > > > > > > > > > irq 193: nobody cared (try booting with the "irqpoll" option) > > > > Did you try this option? It may decrease performance, but in some cases > > IRQ routing is so screwed that only irqpoll helps. > > I have now switched to using that option. Will kick in after I reboot. Actually, it might be better to wait with this - it is the last resort option, if there is nothing else to try. > 0000:00:0f.2 USB Controller: ServerWorks OSB4/CSB5 OHCI USB Controller (rev 04) (prog-if 10 [OHCI]) > Subsystem: ServerWorks OSB4/CSB5 OHCI USB Controller > Flags: bus master, medium devsel, latency 64, IRQ 10 > Memory at fe9fe000 (32-bit, non-prefetchable) [size=4K] Can you try with ohci-hcd loaded (and without irqpoll)? USB controllers might cause such problems, because BIOSen often do weird things with them for legacy emulation; however, loading a proper driver should make BIOS stop messing with the hardware behind the back of the OS. After loading ohci-hcd look which IRQ does the USB controller use - if it is the same IRQ as the qstor card, you should keep ohci-hcd loaded to avoid problems. (If it is on some other IRQ, loading ohci-hcd might still help - the code for enabling the PCI device calls ACPI BIOS, which might change interrupt routing setup in the chipset.) Also look for something like "USB Keyboard Support" and maybe "USB Mouse Support" in BIOS setup - some BIOS versions have severe problems with this emulation, so it may be better to disable it unless you really need it. Disabling USB in the BIOS setup if you really don't need might be another option. > 0000:01:05.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1010 Ultra3 SCSI Adapter (rev 01) > Subsystem: Gateway 2000: Unknown device 1040 > Flags: medium devsel > I/O ports at 1000 [disabled] [size=256] > Memory at <ignored> (64-bit, non-prefetchable) [disabled] > Memory at <ignored> (64-bit, non-prefetchable) [disabled] > Capabilities: [40] Power Management version 2 > > 0000:01:05.1 SCSI storage controller: LSI Logic / Symbios Logic 53c1010 Ultra3 SCSI Adapter (rev 01) > Subsystem: Gateway 2000: Unknown device 1040 > Flags: medium devsel > I/O ports at 1400 [disabled] [size=256] > Memory at <ignored> (64-bit, non-prefetchable) [disabled] > Memory at <ignored> (64-bit, non-prefetchable) [disabled] > Capabilities: [40] Power Management version 2 These devices seem to be disabled, but if loading ohci-hcd does not help, you can try to load the sym53c8xx driver and look whether it ends up on the same IRQ as qstor. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: qstor driver -> irq 193: nobody cared 2006-11-03 20:52 ` Sergey Vlasov @ 2006-11-03 23:21 ` Alberto Alonso 0 siblings, 0 replies; 20+ messages in thread From: Alberto Alonso @ 2006-11-03 23:21 UTC (permalink / raw) To: Sergey Vlasov; +Cc: linux-kernel On Fri, 2006-11-03 at 23:52 +0300, Sergey Vlasov wrote: > On Fri, Nov 03, 2006 at 02:22:07PM -0600, Alberto Alonso wrote: > > On Fri, 2006-11-03 at 22:00 +0300, Sergey Vlasov wrote: > > > On Fri, 03 Nov 2006 12:02:53 -0600 Alberto Alonso wrote: > > > > > > > I have a Pacific Digital qstor card on irq 193. I am using kernel > > > > 2.6.17.13 SMP > > > > > > > > > > > > irq 193: nobody cared (try booting with the "irqpoll" option) > > > > > > Did you try this option? It may decrease performance, but in some cases > > > IRQ routing is so screwed that only irqpoll helps. > > > > I have now switched to using that option. Will kick in after I reboot. > > Actually, it might be better to wait with this - it is the last resort > option, if there is nothing else to try. I'll wait then. This is a file server with 6 active HD controllers and 14 drives. For what I can figure out reading LKML irqpoll would really have a bad effect. > > > 0000:00:0f.2 USB Controller: ServerWorks OSB4/CSB5 OHCI USB Controller (rev 04) (prog-if 10 [OHCI]) > > Subsystem: ServerWorks OSB4/CSB5 OHCI USB Controller > > Flags: bus master, medium devsel, latency 64, IRQ 10 > > Memory at fe9fe000 (32-bit, non-prefetchable) [size=4K] > > Can you try with ohci-hcd loaded (and without irqpoll)? USB > controllers might cause such problems, because BIOSen often do weird > things with them for legacy emulation; however, loading a proper > driver should make BIOS stop messing with the hardware behind the back > of the OS. > > After loading ohci-hcd look which IRQ does the USB controller use - if > it is the same IRQ as the qstor card, you should keep ohci-hcd loaded > to avoid problems. (If it is on some other IRQ, loading ohci-hcd > might still help - the code for enabling the PCI device calls ACPI > BIOS, which might change interrupt routing setup in the chipset.) I have now compiled and enabled the ohci-hcd module. It ended up in IRQ10 > > Also look for something like "USB Keyboard Support" and maybe "USB > Mouse Support" in BIOS setup - some BIOS versions have severe problems > with this emulation, so it may be better to disable it unless you > really need it. > > Disabling USB in the BIOS setup if you really don't need might be > another option. > > > 0000:01:05.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1010 Ultra3 SCSI Adapter (rev 01) > > Subsystem: Gateway 2000: Unknown device 1040 > > Flags: medium devsel > > I/O ports at 1000 [disabled] [size=256] > > Memory at <ignored> (64-bit, non-prefetchable) [disabled] > > Memory at <ignored> (64-bit, non-prefetchable) [disabled] > > Capabilities: [40] Power Management version 2 > > > > 0000:01:05.1 SCSI storage controller: LSI Logic / Symbios Logic 53c1010 Ultra3 SCSI Adapter (rev 01) > > Subsystem: Gateway 2000: Unknown device 1040 > > Flags: medium devsel > > I/O ports at 1400 [disabled] [size=256] > > Memory at <ignored> (64-bit, non-prefetchable) [disabled] > > Memory at <ignored> (64-bit, non-prefetchable) [disabled] > > Capabilities: [40] Power Management version 2 > > These devices seem to be disabled, but if loading ohci-hcd does not > help, you can try to load the sym53c8xx driver and look whether it > ends up on the same IRQ as qstor. I will go in tonight and disable all USB and symbios SCSI controllers on the MB via the BIOS. I don't use SCSI disks on that server anymore, and I can get by without the USB ports. The really bad thing is that I can't reproduce it on purpose. Some times I've gone for 6 weeks without any problems. This morning got really bad, but it hasn't happened again since. Thanks for all your help, Alberto -- Alberto Alonso Global Gate Systems LLC. (512) 351-7233 http://www.ggsys.net Hardware, consulting, sysadmin, monitoring and remote backups ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: qstor driver -> irq 193: nobody cared 2006-11-03 18:02 qstor driver -> irq 193: nobody cared Alberto Alonso 2006-11-03 19:00 ` Sergey Vlasov @ 2006-11-04 18:39 ` Mark Lord 2006-11-06 4:04 ` Alberto Alonso 2006-11-10 17:36 ` Alberto Alonso 1 sibling, 2 replies; 20+ messages in thread From: Mark Lord @ 2006-11-04 18:39 UTC (permalink / raw) To: Alberto Alonso; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 1281 bytes --] Alberto Alonso wrote: > I have a Pacific Digital qstor card on irq 193. I am using kernel > 2.6.17.13 SMP > > The error happens every now and then. I have not been able to > figure out any triggers and I can not reproduce it on demand. Today > it happened 3 times within a 40 minutes period. > > All disks connected to the card are disabled and I can't do anything > other than a reboot to get them back. > > It is reported as follows: > > irq 193: nobody cared (try booting with the "irqpoll" option) > <c013e19a> __report_bad_irq+0x2a/0xa0 <c013d970> handle_IRQ_event > +0x30/0x70 > <c013e2b0> note_interrupt+0x80/0xf0 <c013da8c> __do_IRQ+0xdc/0xf0 > <c0105799> do_IRQ+0x19/0x30 <c010391a> common_interrupt+0x1a/0x20 > <c0100d91> default_idle+0x41/0x70 <c0100e60> cpu_idle+0x80/0x90 > <c046699d> start_kernel+0x18d/0x1d0 <c0466330> unknown_bootoption > +0x0/0x1d0 > handlers: > [<c0301300>] (qs_intr+0x0/0x220) > Disabling IRQ #193 What other devices are routed to that same interrupt line? The sata_qstor driver is very rigorous in acknowledging *only* it's own interrupts, to prevent other devices sharing the same IRQ from losing theirs. Mmm.. We could apply a bit of fuzzy tolerance for the odd glitch. Try this patch (attached) and report back. Thanks. [-- Attachment #2: qstor_spurious.patch --] [-- Type: text/x-patch, Size: 833 bytes --] --- linux/drivers/scsi/sata_qstor.c.orig 2006-09-19 23:42:06.000000000 -0400 +++ linux/drivers/scsi/sata_qstor.c 2006-11-04 13:35:45.000000000 -0500 @@ -459,6 +459,7 @@ { struct ata_host_set *host_set = dev_instance; unsigned int handled = 0; + static int spurious = 0; VPRINTK("ENTER\n"); @@ -466,6 +467,19 @@ handled = qs_intr_pkt(host_set) | qs_intr_mmio(host_set); spin_unlock(&host_set->lock); + /* There are reports of at least one system with glitchy interrupts, + * and if we return !handled here for those then the kernel may totally + * disable our own IRQ line (duh!). + * So, try and be tolerant, but not *too* tolerant. + */ + if (!handled) { + if (spurious < 10) { + ++spurious; + handled = 1; + } + } else if (spurious) + --spurious; + VPRINTK("EXIT\n"); return IRQ_RETVAL(handled); ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: qstor driver -> irq 193: nobody cared 2006-11-04 18:39 ` Mark Lord @ 2006-11-06 4:04 ` Alberto Alonso 2006-11-06 14:51 ` Mark Lord 2006-11-10 17:36 ` Alberto Alonso 1 sibling, 1 reply; 20+ messages in thread From: Alberto Alonso @ 2006-11-06 4:04 UTC (permalink / raw) To: Mark Lord; +Cc: linux-kernel I have patched the system. I'll let you know if I get the same problem. Since I can't reproduce it on demand I may not see the problem for months. I don't know what happened the other day when it just started to happen repeatedly, I haven't had the issue since. Thanks, Alberto On Sat, 2006-11-04 at 13:39 -0500, Mark Lord wrote: > Alberto Alonso wrote: > > I have a Pacific Digital qstor card on irq 193. I am using kernel > > 2.6.17.13 SMP > > > > The error happens every now and then. I have not been able to > > figure out any triggers and I can not reproduce it on demand. Today > > it happened 3 times within a 40 minutes period. > > > > All disks connected to the card are disabled and I can't do anything > > other than a reboot to get them back. > > > > It is reported as follows: > > > > irq 193: nobody cared (try booting with the "irqpoll" option) > > <c013e19a> __report_bad_irq+0x2a/0xa0 <c013d970> handle_IRQ_event > > +0x30/0x70 > > <c013e2b0> note_interrupt+0x80/0xf0 <c013da8c> __do_IRQ+0xdc/0xf0 > > <c0105799> do_IRQ+0x19/0x30 <c010391a> common_interrupt+0x1a/0x20 > > <c0100d91> default_idle+0x41/0x70 <c0100e60> cpu_idle+0x80/0x90 > > <c046699d> start_kernel+0x18d/0x1d0 <c0466330> unknown_bootoption > > +0x0/0x1d0 > > handlers: > > [<c0301300>] (qs_intr+0x0/0x220) > > Disabling IRQ #193 > > What other devices are routed to that same interrupt line? > > The sata_qstor driver is very rigorous in acknowledging *only* it's own > interrupts, to prevent other devices sharing the same IRQ from losing theirs. > > Mmm.. We could apply a bit of fuzzy tolerance for the odd glitch. > Try this patch (attached) and report back. > > Thanks. > > -- Alberto Alonso Global Gate Systems LLC. (512) 351-7233 http://www.ggsys.net Hardware, consulting, sysadmin, monitoring and remote backups ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: qstor driver -> irq 193: nobody cared 2006-11-06 4:04 ` Alberto Alonso @ 2006-11-06 14:51 ` Mark Lord 0 siblings, 0 replies; 20+ messages in thread From: Mark Lord @ 2006-11-06 14:51 UTC (permalink / raw) To: Alberto Alonso; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 427 bytes --] Alberto Alonso wrote: > I have patched the system. I'll let you know if I get the > same problem. Since I can't reproduce it on demand I may not see > the problem for months. I don't know what happened the other day > when it just started to happen repeatedly, I haven't had the issue > since. Ahh. Well, in that case please add a printk() line so that we'll know if it *ever* does anything! Updated patch attached. Cheers [-- Attachment #2: qstor_spurious2.patch --] [-- Type: text/x-patch, Size: 877 bytes --] --- old/drivers/scsi/sata_qstor.c 2006-09-19 23:42:06.000000000 -0400 +++ linux/drivers/scsi/sata_qstor.c 2006-11-06 09:50:02.000000000 -0500 @@ -459,6 +459,7 @@ { struct ata_host_set *host_set = dev_instance; unsigned int handled = 0; + static int spurious = 0; VPRINTK("ENTER\n"); @@ -466,6 +467,20 @@ handled = qs_intr_pkt(host_set) | qs_intr_mmio(host_set); spin_unlock(&host_set->lock); + /* There are reports of at least one system with glitchy interrupts, + * and if we return !handled here for those then the kernel may totally + * disable our own IRQ line (duh!). + * So, try and be tolerant, but not *too* tolerant. + */ + if (!handled) { + if (spurious < 10) { + printk("sata_qstor: spurious=%d\n", spurious); + ++spurious; + handled = 1; + } + } else if (spurious) + --spurious; + VPRINTK("EXIT\n"); return IRQ_RETVAL(handled); ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: qstor driver -> irq 193: nobody cared 2006-11-04 18:39 ` Mark Lord 2006-11-06 4:04 ` Alberto Alonso @ 2006-11-10 17:36 ` Alberto Alonso 2006-11-12 5:09 ` Mark Lord 1 sibling, 1 reply; 20+ messages in thread From: Alberto Alonso @ 2006-11-10 17:36 UTC (permalink / raw) To: Mark Lord; +Cc: linux-kernel The saga continues. It happened again this morning even with the patch: irq 193: nobody cared (try booting with the "irqpoll" option) <c013e19a> __report_bad_irq+0x2a/0xa0 <c013d970> handle_IRQ_event +0x30/0x70 <c013e2b0> note_interrupt+0x80/0xf0 <c013da8c> __do_IRQ+0xdc/0xf0 <c0105799> do_IRQ+0x19/0x30 <c010391a> common_interrupt+0x1a/0x20 <c0100d91> default_idle+0x41/0x70 <c0100e60> cpu_idle+0x80/0x90 <c046699d> start_kernel+0x18d/0x1d0 <c0466330> unknown_bootoption +0x0/0x1d0 handlers: [<c0301300>] (qs_intr+0x0/0x240) Disabling IRQ #193 ata4: command 0xea timeout, stat 0xff host_stat 0x0 ata1: command 0xea timeout, stat 0xff host_stat 0x0 [...] The drives on this controller went offline. This is my interrupts table: cat /proc/interrupts CPU0 CPU1 0: 48405419 48520371 IO-APIC-edge timer 1: 60 146 IO-APIC-edge i8042 2: 0 0 XT-PIC cascade 8: 1 3 IO-APIC-edge rtc 10: 13 13 IO-APIC-level ohci_hcd:usb1 14: 228219 237351 IO-APIC-edge ide0 15: 3 9 IO-APIC-edge ide1 145: 0 0 IO-APIC-level ivtv0 153: 2272523 2393822 IO-APIC-level ide2, ide3, ide4, ide5 161: 5416 23455 IO-APIC-level ide8, ide9 169: 7148 22129 IO-APIC-level ide6, ide7 185: 3680365 86 IO-APIC-level eth0 193: 337154 162846 IO-APIC-level libata NMI: 0 0 LOC: 96924026 96924027 ERR: 0 MIS: 0 lspci -v shows this for the controller. No other device (at least pci device) is using IRQ 193. 0000:01:03.0 0106: Pacific Digital Corp: Unknown device 2068 (rev 01) Subsystem: Pacific Digital Corp: Unknown device 2068 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 193 I/O ports at eff0 [size=8] I/O ports at efe0 [size=8] I/O ports at efa8 [size=8] I/O ports at efa0 [size=8] Memory at febf0000 (64-bit, non-prefetchable) [size=64K] Expansion ROM at febe0000 [disabled] [size=64K] Capabilities: <available only to root> Any other ideas I can try to look for? Is there any other type of device that may be using the IRQ but not listed with the above commands? Thanks, Alberto On Sat, 2006-11-04 at 13:39 -0500, Mark Lord wrote: > Alberto Alonso wrote: > > I have a Pacific Digital qstor card on irq 193. I am using kernel > > 2.6.17.13 SMP > > > > The error happens every now and then. I have not been able to > > figure out any triggers and I can not reproduce it on demand. Today > > it happened 3 times within a 40 minutes period. > > > > All disks connected to the card are disabled and I can't do anything > > other than a reboot to get them back. > > > > It is reported as follows: > > > > irq 193: nobody cared (try booting with the "irqpoll" option) > > <c013e19a> __report_bad_irq+0x2a/0xa0 <c013d970> handle_IRQ_event > > +0x30/0x70 > > <c013e2b0> note_interrupt+0x80/0xf0 <c013da8c> __do_IRQ+0xdc/0xf0 > > <c0105799> do_IRQ+0x19/0x30 <c010391a> common_interrupt+0x1a/0x20 > > <c0100d91> default_idle+0x41/0x70 <c0100e60> cpu_idle+0x80/0x90 > > <c046699d> start_kernel+0x18d/0x1d0 <c0466330> unknown_bootoption > > +0x0/0x1d0 > > handlers: > > [<c0301300>] (qs_intr+0x0/0x220) > > Disabling IRQ #193 > > What other devices are routed to that same interrupt line? > > The sata_qstor driver is very rigorous in acknowledging *only* it's own > interrupts, to prevent other devices sharing the same IRQ from losing theirs. > > Mmm.. We could apply a bit of fuzzy tolerance for the odd glitch. > Try this patch (attached) and report back. > > Thanks. > > -- Alberto Alonso Global Gate Systems LLC. (512) 351-7233 http://www.ggsys.net Hardware, consulting, sysadmin, monitoring and remote backups ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: qstor driver -> irq 193: nobody cared 2006-11-10 17:36 ` Alberto Alonso @ 2006-11-12 5:09 ` Mark Lord 2006-11-12 5:17 ` Alberto Alonso 2006-11-12 20:31 ` Alberto Alonso 0 siblings, 2 replies; 20+ messages in thread From: Mark Lord @ 2006-11-12 5:09 UTC (permalink / raw) To: Alberto Alonso; +Cc: linux-kernel Alberto Alonso wrote: > The saga continues. It happened again this morning even with the > patch: .. >> Mmm.. We could apply a bit of fuzzy tolerance for the odd glitch. >> Try this patch (attached) and report back. Did you add the printk() to the patch, as suggested? If so, did it log anything ? Thanks ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: qstor driver -> irq 193: nobody cared 2006-11-12 5:09 ` Mark Lord @ 2006-11-12 5:17 ` Alberto Alonso 2006-11-12 20:31 ` Alberto Alonso 1 sibling, 0 replies; 20+ messages in thread From: Alberto Alonso @ 2006-11-12 5:17 UTC (permalink / raw) To: Mark Lord; +Cc: linux-kernel Sorry, I missed that post. I will add the printk line right now. I'll let you know the results as soon as it happens again. Thanks, Alberto On Sun, 2006-11-12 at 00:09 -0500, Mark Lord wrote: > Alberto Alonso wrote: > > The saga continues. It happened again this morning even with the > > patch: > .. > >> Mmm.. We could apply a bit of fuzzy tolerance for the odd glitch. > >> Try this patch (attached) and report back. > > Did you add the printk() to the patch, as suggested? > If so, did it log anything ? > > Thanks -- Alberto Alonso Global Gate Systems LLC. (512) 351-7233 http://www.ggsys.net Hardware, consulting, sysadmin, monitoring and remote backups ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: qstor driver -> irq 193: nobody cared 2006-11-12 5:09 ` Mark Lord 2006-11-12 5:17 ` Alberto Alonso @ 2006-11-12 20:31 ` Alberto Alonso 2006-11-13 14:29 ` Mark Lord 1 sibling, 1 reply; 20+ messages in thread From: Alberto Alonso @ 2006-11-12 20:31 UTC (permalink / raw) To: Mark Lord; +Cc: linux-kernel OK, after adding the printk line I can start seeing results. I guess it has been close to 10 on quite a few occasions. Thanks, Alberto # grep qstor /var/log/messages Nov 12 07:00:53 w100 kernel: sata_qstor: spurious=0 Nov 12 07:00:53 w100 kernel: sata_qstor: spurious=1 Nov 12 07:00:53 w100 kernel: sata_qstor: spurious=0 Nov 12 07:00:56 w100 kernel: sata_qstor: spurious=1 Nov 12 07:00:56 w100 kernel: sata_qstor: spurious=2 Nov 12 07:00:56 w100 kernel: sata_qstor: spurious=0 Nov 12 07:03:35 w100 kernel: sata_qstor: spurious=0 Nov 12 07:34:44 w100 kernel: sata_qstor: spurious=0 Nov 12 07:35:08 w100 kernel: sata_qstor: spurious=1 Nov 12 07:35:08 w100 kernel: sata_qstor: spurious=1 Nov 12 07:35:08 w100 kernel: sata_qstor: spurious=0 Nov 12 09:11:17 w100 kernel: sata_qstor: spurious=0 Nov 12 09:11:17 w100 kernel: sata_qstor: spurious=1 Nov 12 09:11:17 w100 kernel: sata_qstor: spurious=0 Nov 12 09:11:17 w100 kernel: sata_qstor: spurious=1 Nov 12 09:11:18 w100 kernel: sata_qstor: spurious=0 Nov 12 09:36:34 w100 kernel: sata_qstor: spurious=0 Nov 12 09:38:26 w100 kernel: sata_qstor: spurious=0 Nov 12 09:38:26 w100 kernel: sata_qstor: spurious=0 Nov 12 09:53:06 w100 kernel: sata_qstor: spurious=0 Nov 12 09:53:06 w100 kernel: sata_qstor: spurious=1 Nov 12 09:53:06 w100 kernel: sata_qstor: spurious=2 Nov 12 09:53:06 w100 kernel: sata_qstor: spurious=0 Nov 12 09:53:09 w100 kernel: sata_qstor: spurious=1 Nov 12 10:09:03 w100 kernel: sata_qstor: spurious=0 Nov 12 10:09:04 w100 kernel: sata_qstor: spurious=1 Nov 12 10:09:05 w100 kernel: sata_qstor: spurious=0 Nov 12 10:09:05 w100 kernel: sata_qstor: spurious=0 Nov 12 10:11:52 w100 kernel: sata_qstor: spurious=0 Nov 12 10:11:53 w100 kernel: sata_qstor: spurious=1 Nov 12 10:11:53 w100 kernel: sata_qstor: spurious=2 Nov 12 10:11:53 w100 kernel: sata_qstor: spurious=3 Nov 12 10:11:54 w100 kernel: sata_qstor: spurious=0 Nov 12 10:11:55 w100 kernel: sata_qstor: spurious=1 Nov 12 10:11:55 w100 kernel: sata_qstor: spurious=0 Nov 12 10:12:35 w100 kernel: sata_qstor: spurious=1 Nov 12 10:12:37 w100 kernel: sata_qstor: spurious=0 Nov 12 10:12:37 w100 kernel: sata_qstor: spurious=1 Nov 12 10:12:37 w100 kernel: sata_qstor: spurious=0 Nov 12 10:30:51 w100 kernel: sata_qstor: spurious=0 Nov 12 10:30:51 w100 kernel: sata_qstor: spurious=1 Nov 12 10:30:51 w100 kernel: sata_qstor: spurious=2 Nov 12 10:30:52 w100 kernel: sata_qstor: spurious=0 Nov 12 10:30:52 w100 kernel: sata_qstor: spurious=0 Nov 12 10:40:08 w100 kernel: sata_qstor: spurious=0 Nov 12 10:40:08 w100 kernel: sata_qstor: spurious=1 Nov 12 10:57:34 w100 kernel: sata_qstor: spurious=0 Nov 12 10:57:34 w100 kernel: sata_qstor: spurious=1 Nov 12 10:57:34 w100 kernel: sata_qstor: spurious=1 Nov 12 10:57:34 w100 kernel: sata_qstor: spurious=0 Nov 12 10:57:37 w100 kernel: sata_qstor: spurious=0 Nov 12 10:57:37 w100 kernel: sata_qstor: spurious=1 Nov 12 10:57:37 w100 kernel: sata_qstor: spurious=2 Nov 12 10:57:37 w100 kernel: sata_qstor: spurious=3 Nov 12 10:57:37 w100 kernel: sata_qstor: spurious=4 Nov 12 10:57:37 w100 kernel: sata_qstor: spurious=5 Nov 12 10:57:37 w100 kernel: sata_qstor: spurious=3 Nov 12 11:01:18 w100 kernel: sata_qstor: spurious=0 Nov 12 11:01:19 w100 kernel: sata_qstor: spurious=1 Nov 12 11:18:35 w100 kernel: sata_qstor: spurious=0 Nov 12 11:18:39 w100 kernel: sata_qstor: spurious=1 Nov 12 11:18:40 w100 kernel: sata_qstor: spurious=0 Nov 12 11:18:40 w100 kernel: sata_qstor: spurious=0 Nov 12 11:21:42 w100 kernel: sata_qstor: spurious=0 Nov 12 11:35:11 w100 kernel: sata_qstor: spurious=0 Nov 12 11:35:11 w100 kernel: sata_qstor: spurious=1 Nov 12 11:35:11 w100 kernel: sata_qstor: spurious=0 Nov 12 11:35:12 w100 kernel: sata_qstor: spurious=0 Nov 12 11:35:12 w100 kernel: sata_qstor: spurious=1 Nov 12 11:35:12 w100 kernel: sata_qstor: spurious=2 Nov 12 11:35:12 w100 kernel: sata_qstor: spurious=3 Nov 12 11:35:12 w100 kernel: sata_qstor: spurious=4 Nov 12 11:35:12 w100 kernel: sata_qstor: spurious=2 Nov 12 11:38:01 w100 kernel: sata_qstor: spurious=0 Nov 12 11:38:01 w100 kernel: sata_qstor: spurious=1 Nov 12 11:38:01 w100 kernel: sata_qstor: spurious=0 Nov 12 11:42:53 w100 kernel: sata_qstor: spurious=0 Nov 12 11:50:26 w100 kernel: sata_qstor: spurious=0 Nov 12 11:50:26 w100 kernel: sata_qstor: spurious=1 Nov 12 11:50:26 w100 kernel: sata_qstor: spurious=2 Nov 12 11:50:26 w100 kernel: sata_qstor: spurious=0 Nov 12 12:07:03 w100 kernel: sata_qstor: spurious=0 Nov 12 12:07:03 w100 kernel: sata_qstor: spurious=0 Nov 12 12:07:03 w100 kernel: sata_qstor: spurious=1 Nov 12 12:07:03 w100 kernel: sata_qstor: spurious=2 Nov 12 12:07:11 w100 kernel: sata_qstor: spurious=0 Nov 12 12:07:11 w100 kernel: sata_qstor: spurious=1 Nov 12 12:07:11 w100 kernel: sata_qstor: spurious=0 Nov 12 12:15:08 w100 kernel: sata_qstor: spurious=0 Nov 12 12:15:31 w100 kernel: sata_qstor: spurious=1 Nov 12 12:15:31 w100 kernel: sata_qstor: spurious=0 Nov 12 12:15:31 w100 kernel: sata_qstor: spurious=1 Nov 12 12:15:31 w100 kernel: sata_qstor: spurious=2 Nov 12 12:41:11 w100 kernel: sata_qstor: spurious=0 Nov 12 12:41:28 w100 kernel: sata_qstor: spurious=1 Nov 12 12:41:28 w100 kernel: sata_qstor: spurious=2 Nov 12 12:41:28 w100 kernel: sata_qstor: spurious=3 Nov 12 12:41:28 w100 kernel: sata_qstor: spurious=4 Nov 12 12:41:28 w100 kernel: sata_qstor: spurious=5 Nov 12 12:41:28 w100 kernel: sata_qstor: spurious=3 Nov 12 13:05:42 w100 kernel: sata_qstor: spurious=0 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=1 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=2 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=3 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=4 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=5 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=6 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=7 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=8 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=9 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=9 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=8 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=9 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=7 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=8 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=9 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=9 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=8 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=9 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=8 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=7 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=8 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=9 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=8 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=9 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=8 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=7 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=8 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=9 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=8 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=9 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=8 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=7 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=8 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=9 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=6 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=7 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=8 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=9 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=8 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=9 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=7 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=8 Nov 12 13:05:47 w100 kernel: sata_qstor: spurious=9 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=0 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=1 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=2 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=3 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=4 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=5 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=6 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=7 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=8 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=9 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=8 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=9 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=8 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=9 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=8 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=9 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=8 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=9 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=8 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=9 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=8 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=7 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=8 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=9 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=6 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=7 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=8 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=9 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=8 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=7 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=8 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=9 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=8 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=9 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=8 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=7 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=8 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=9 Nov 12 13:05:52 w100 kernel: sata_qstor: spurious=0 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=1 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=2 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=3 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=4 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=5 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=6 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=7 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=8 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=9 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=8 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=9 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=8 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=9 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=8 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=9 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=6 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=0 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=1 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=0 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=1 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=2 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=3 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=4 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=5 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=6 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=7 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=8 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=9 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=9 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=8 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=9 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=8 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=9 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=9 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=7 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=8 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=9 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=4 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=5 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=6 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=7 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=8 Nov 12 13:06:01 w100 kernel: sata_qstor: spurious=9 Nov 12 13:20:15 w100 kernel: sata_qstor: spurious=0 Nov 12 13:20:15 w100 kernel: sata_qstor: spurious=1 Nov 12 13:20:15 w100 kernel: sata_qstor: spurious=2 Nov 12 13:20:17 w100 kernel: sata_qstor: spurious=0 Nov 12 13:20:17 w100 kernel: sata_qstor: spurious=1 Nov 12 13:20:17 w100 kernel: sata_qstor: spurious=0 Nov 12 13:23:30 w100 kernel: sata_qstor: spurious=0 Nov 12 13:23:30 w100 kernel: sata_qstor: spurious=1 Nov 12 13:23:30 w100 kernel: sata_qstor: spurious=2 Nov 12 13:23:30 w100 kernel: sata_qstor: spurious=3 Nov 12 13:23:36 w100 kernel: sata_qstor: spurious=0 Nov 12 13:23:36 w100 kernel: sata_qstor: spurious=0 Nov 12 13:23:36 w100 kernel: sata_qstor: spurious=1 Nov 12 13:23:36 w100 kernel: sata_qstor: spurious=0 Nov 12 13:23:36 w100 kernel: sata_qstor: spurious=0 Nov 12 13:23:36 w100 kernel: sata_qstor: spurious=1 Nov 12 13:23:36 w100 kernel: sata_qstor: spurious=1 Nov 12 13:23:36 w100 kernel: sata_qstor: spurious=2 Nov 12 13:23:36 w100 kernel: sata_qstor: spurious=0 Nov 12 13:23:36 w100 kernel: sata_qstor: spurious=1 Nov 12 13:23:36 w100 kernel: sata_qstor: spurious=2 Nov 12 13:24:08 w100 kernel: sata_qstor: spurious=0 Nov 12 13:24:08 w100 kernel: sata_qstor: spurious=1 Nov 12 13:24:08 w100 kernel: sata_qstor: spurious=1 Nov 12 13:24:08 w100 kernel: sata_qstor: spurious=0 Nov 12 13:26:36 w100 kernel: sata_qstor: spurious=0 Nov 12 13:26:36 w100 kernel: sata_qstor: spurious=0 Nov 12 13:26:36 w100 kernel: sata_qstor: spurious=1 Nov 12 13:26:36 w100 kernel: sata_qstor: spurious=2 Nov 12 13:31:30 w100 kernel: sata_qstor: spurious=0 Nov 12 13:31:33 w100 kernel: sata_qstor: spurious=1 Nov 12 13:31:33 w100 kernel: sata_qstor: spurious=1 Nov 12 13:32:18 w100 kernel: sata_qstor: spurious=0 Nov 12 13:32:43 w100 kernel: sata_qstor: spurious=1 Nov 12 13:32:43 w100 kernel: sata_qstor: spurious=2 Nov 12 13:32:43 w100 kernel: sata_qstor: spurious=3 Nov 12 13:32:43 w100 kernel: sata_qstor: spurious=3 Nov 12 13:33:07 w100 kernel: sata_qstor: spurious=0 Nov 12 13:33:07 w100 kernel: sata_qstor: spurious=1 Nov 12 13:33:07 w100 kernel: sata_qstor: spurious=2 Nov 12 13:33:07 w100 kernel: sata_qstor: spurious=3 Nov 12 13:33:07 w100 kernel: sata_qstor: spurious=4 Nov 12 13:33:07 w100 kernel: sata_qstor: spurious=2 Nov 12 13:33:08 w100 kernel: sata_qstor: spurious=0 Nov 12 13:33:39 w100 kernel: sata_qstor: spurious=0 Nov 12 13:34:53 w100 kernel: sata_qstor: spurious=0 Nov 12 13:34:53 w100 kernel: sata_qstor: spurious=1 Nov 12 13:34:53 w100 kernel: sata_qstor: spurious=0 Nov 12 13:41:15 w100 kernel: sata_qstor: spurious=0 Nov 12 13:41:15 w100 kernel: sata_qstor: spurious=1 Nov 12 13:41:19 w100 kernel: sata_qstor: spurious=0 Nov 12 13:41:19 w100 kernel: sata_qstor: spurious=1 Nov 12 13:41:19 w100 kernel: sata_qstor: spurious=2 Nov 12 13:41:19 w100 kernel: sata_qstor: spurious=3 Nov 12 13:41:19 w100 kernel: sata_qstor: spurious=4 Nov 12 13:41:19 w100 kernel: sata_qstor: spurious=5 Nov 12 13:41:19 w100 kernel: sata_qstor: spurious=3 Nov 12 13:49:43 w100 kernel: sata_qstor: spurious=0 Nov 12 13:49:43 w100 kernel: sata_qstor: spurious=0 Nov 12 13:49:43 w100 kernel: sata_qstor: spurious=1 Nov 12 13:49:43 w100 kernel: sata_qstor: spurious=2 Nov 12 13:49:49 w100 kernel: sata_qstor: spurious=0 Nov 12 13:49:49 w100 kernel: sata_qstor: spurious=0 Nov 12 13:49:49 w100 kernel: sata_qstor: spurious=1 Nov 12 13:49:49 w100 kernel: sata_qstor: spurious=2 Nov 12 13:53:04 w100 kernel: sata_qstor: spurious=0 Nov 12 13:53:32 w100 kernel: sata_qstor: spurious=0 Nov 12 13:53:32 w100 kernel: sata_qstor: spurious=1 Nov 12 13:53:32 w100 kernel: sata_qstor: spurious=0 Nov 12 13:56:11 w100 kernel: sata_qstor: spurious=0 Nov 12 13:56:11 w100 kernel: sata_qstor: spurious=0 Nov 12 13:56:11 w100 kernel: sata_qstor: spurious=1 Nov 12 13:56:11 w100 kernel: sata_qstor: spurious=2 Nov 12 13:56:11 w100 kernel: sata_qstor: spurious=0 Nov 12 13:56:11 w100 kernel: sata_qstor: spurious=0 Nov 12 13:56:11 w100 kernel: sata_qstor: spurious=1 Nov 12 13:56:11 w100 kernel: sata_qstor: spurious=2 Nov 12 13:56:13 w100 kernel: sata_qstor: spurious=0 Nov 12 13:56:13 w100 kernel: sata_qstor: spurious=0 Nov 12 14:10:49 w100 kernel: sata_qstor: spurious=0 Nov 12 14:10:49 w100 kernel: sata_qstor: spurious=1 Nov 12 14:10:49 w100 kernel: sata_qstor: spurious=0 Nov 12 14:10:50 w100 kernel: sata_qstor: spurious=1 Nov 12 14:10:50 w100 kernel: sata_qstor: spurious=1 Nov 12 14:10:50 w100 kernel: sata_qstor: spurious=0 Nov 12 14:11:40 w100 kernel: sata_qstor: spurious=0 Nov 12 14:11:40 w100 kernel: sata_qstor: spurious=1 Nov 12 14:11:40 w100 kernel: sata_qstor: spurious=2 Nov 12 14:11:40 w100 kernel: sata_qstor: spurious=3 Nov 12 14:14:32 w100 kernel: sata_qstor: spurious=0 Nov 12 14:14:32 w100 kernel: sata_qstor: spurious=0 Nov 12 14:14:32 w100 kernel: sata_qstor: spurious=1 Nov 12 14:14:32 w100 kernel: sata_qstor: spurious=1 Nov 12 14:14:32 w100 kernel: sata_qstor: spurious=0 Nov 12 14:22:18 w100 kernel: sata_qstor: spurious=0 Nov 12 14:22:22 w100 kernel: sata_qstor: spurious=1 Nov 12 14:22:22 w100 kernel: sata_qstor: spurious=2 Nov 12 14:22:22 w100 kernel: sata_qstor: spurious=3 Nov 12 14:26:51 w100 kernel: sata_qstor: spurious=0 Nov 12 14:26:51 w100 kernel: sata_qstor: spurious=1 Nov 12 14:26:51 w100 kernel: sata_qstor: spurious=0 On Sun, 2006-11-12 at 00:09 -0500, Mark Lord wrote: > Alberto Alonso wrote: > > The saga continues. It happened again this morning even with the > > patch: > .. > >> Mmm.. We could apply a bit of fuzzy tolerance for the odd glitch. > >> Try this patch (attached) and report back. > > Did you add the printk() to the patch, as suggested? > If so, did it log anything ? > > Thanks -- Alberto Alonso Global Gate Systems LLC. (512) 351-7233 http://www.ggsys.net Hardware, consulting, sysadmin, monitoring and remote backups ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: qstor driver -> irq 193: nobody cared 2006-11-12 20:31 ` Alberto Alonso @ 2006-11-13 14:29 ` Mark Lord 2006-11-14 4:50 ` Alberto Alonso 0 siblings, 1 reply; 20+ messages in thread From: Mark Lord @ 2006-11-13 14:29 UTC (permalink / raw) To: Alberto Alonso; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 1226 bytes --] Alberto Alonso wrote: > OK, after adding the printk line I can start seeing > results. > > I guess it has been close to 10 on quite a few > occasions. .. > # grep qstor /var/log/messages > Nov 12 07:00:53 w100 kernel: sata_qstor: spurious=0 > Nov 12 07:00:53 w100 kernel: sata_qstor: spurious=1 > Nov 12 07:00:53 w100 kernel: sata_qstor: spurious=0 > Nov 12 07:00:56 w100 kernel: sata_qstor: spurious=1 > Nov 12 07:00:56 w100 kernel: sata_qstor: spurious=2 .. > On Sun, 2006-11-12 at 00:09 -0500, Mark Lord wrote: >> Alberto Alonso wrote: >>> The saga continues. It happened again this morning even with the >>> patch: >> .. >>>> Mmm.. We could apply a bit of fuzzy tolerance for the odd glitch. >>>> Try this patch (attached) and report back. >> Did you add the printk() to the patch, as suggested? .. Excellent! So, either we have a very noisy bit of hardware in there, or something is wrong with sata_qstor.c. The device has two methods for dealing with commands. Regular R/W uses the driver's host queue "packet" interface, and all other commands pass through the legacy MMIO mechanism. I'm betting on some bug/interaction with the latter. Try this patch and see what happens, on top of the printk patch. Thanks [-- Attachment #2: qstor_check_status.patch --] [-- Type: text/x-patch, Size: 703 bytes --] --- linux/drivers/scsi/sata_qstor.c.printk 2006-11-06 09:50:02.000000000 -0500 +++ linux/drivers/scsi/sata_qstor.c 2006-11-13 09:25:49.000000000 -0500 @@ -431,6 +431,7 @@ if (ap && !(ap->flags & ATA_FLAG_DISABLED)) { struct ata_queued_cmd *qc; + u8 status = ata_check_status(ap); struct qs_port_priv *pp = ap->private_data; if (!pp || pp->state != qs_state_mmio) continue; @@ -438,7 +439,7 @@ if (qc && (!(qc->tf.flags & ATA_TFLAG_POLLING))) { /* check main status, clearing INTRQ */ - u8 status = ata_check_status(ap); + //u8 status = ata_check_status(ap); if ((status & ATA_BUSY)) continue; DPRINTK("ata%u: protocol %d (dev_stat 0x%X)\n", ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: qstor driver -> irq 193: nobody cared 2006-11-13 14:29 ` Mark Lord @ 2006-11-14 4:50 ` Alberto Alonso 2006-11-14 16:46 ` Mark Lord 0 siblings, 1 reply; 20+ messages in thread From: Alberto Alonso @ 2006-11-14 4:50 UTC (permalink / raw) To: Mark Lord; +Cc: linux-kernel Things are improving, after the latest patch I can still see spurious messages, but the count stays at 0. Sorry for including all the lines, but I think it may help to see if a time pattern is visible. Here is the output: Nov 13 14:01:08 w100 kernel: scsi0 : sata_qstor Nov 13 14:01:08 w100 kernel: scsi1 : sata_qstor Nov 13 14:01:08 w100 kernel: scsi2 : sata_qstor Nov 13 14:01:08 w100 kernel: scsi3 : sata_qstor Nov 13 14:05:15 w100 kernel: sata_qstor: spurious=0 Nov 13 14:08:29 w100 kernel: sata_qstor: spurious=0 Nov 13 14:11:01 w100 kernel: sata_qstor: spurious=0 Nov 13 14:11:06 w100 kernel: sata_qstor: spurious=0 Nov 13 14:15:03 w100 kernel: sata_qstor: spurious=0 Nov 13 14:20:28 w100 kernel: sata_qstor: spurious=0 Nov 13 14:28:44 w100 kernel: sata_qstor: spurious=0 Nov 13 14:40:40 w100 kernel: sata_qstor: spurious=0 Nov 13 14:46:53 w100 kernel: sata_qstor: spurious=0 Nov 13 15:00:15 w100 kernel: sata_qstor: spurious=0 Nov 13 15:01:52 w100 kernel: sata_qstor: spurious=0 Nov 13 15:13:18 w100 kernel: sata_qstor: spurious=0 Nov 13 15:18:25 w100 kernel: sata_qstor: spurious=0 Nov 13 15:19:57 w100 kernel: sata_qstor: spurious=0 Nov 13 15:24:56 w100 kernel: sata_qstor: spurious=0 Nov 13 15:32:52 w100 kernel: sata_qstor: spurious=0 Nov 13 15:32:53 w100 kernel: sata_qstor: spurious=0 Nov 13 15:37:47 w100 kernel: sata_qstor: spurious=0 Nov 13 15:42:30 w100 kernel: sata_qstor: spurious=0 Nov 13 15:42:33 w100 kernel: sata_qstor: spurious=0 Nov 13 15:45:50 w100 kernel: sata_qstor: spurious=0 Nov 13 15:54:53 w100 kernel: sata_qstor: spurious=0 Nov 13 15:59:32 w100 kernel: sata_qstor: spurious=0 Nov 13 16:04:07 w100 kernel: sata_qstor: spurious=0 Nov 13 16:06:01 w100 kernel: sata_qstor: spurious=0 Nov 13 16:07:24 w100 kernel: sata_qstor: spurious=0 Nov 13 16:19:54 w100 kernel: sata_qstor: spurious=0 Nov 13 16:19:55 w100 kernel: sata_qstor: spurious=0 Nov 13 16:27:34 w100 kernel: sata_qstor: spurious=0 Nov 13 16:33:21 w100 kernel: sata_qstor: spurious=0 Nov 13 16:39:57 w100 kernel: sata_qstor: spurious=0 Nov 13 16:42:38 w100 kernel: sata_qstor: spurious=0 Nov 13 16:43:40 w100 kernel: sata_qstor: spurious=0 Nov 13 16:50:36 w100 kernel: sata_qstor: spurious=0 Nov 13 16:52:11 w100 kernel: sata_qstor: spurious=0 Nov 13 16:53:41 w100 kernel: sata_qstor: spurious=0 Nov 13 16:58:30 w100 kernel: sata_qstor: spurious=0 Nov 13 17:18:40 w100 kernel: sata_qstor: spurious=0 Nov 13 17:20:21 w100 kernel: sata_qstor: spurious=0 Nov 13 17:20:46 w100 kernel: sata_qstor: spurious=0 Nov 13 17:24:02 w100 kernel: sata_qstor: spurious=0 Nov 13 17:27:26 w100 kernel: sata_qstor: spurious=0 Nov 13 17:35:40 w100 kernel: sata_qstor: spurious=0 Nov 13 17:39:01 w100 kernel: sata_qstor: spurious=0 Nov 13 17:40:23 w100 kernel: sata_qstor: spurious=0 Nov 13 18:03:57 w100 kernel: sata_qstor: spurious=0 Nov 13 18:08:16 w100 kernel: sata_qstor: spurious=0 Nov 13 18:11:20 w100 kernel: sata_qstor: spurious=0 Nov 13 18:16:32 w100 kernel: sata_qstor: spurious=0 Nov 13 18:16:32 w100 kernel: sata_qstor: spurious=0 Nov 13 18:21:28 w100 kernel: sata_qstor: spurious=0 Nov 13 18:22:57 w100 kernel: sata_qstor: spurious=0 Nov 13 18:26:36 w100 kernel: sata_qstor: spurious=0 Nov 13 18:29:21 w100 kernel: sata_qstor: spurious=0 Nov 13 18:32:34 w100 kernel: sata_qstor: spurious=0 Nov 13 18:34:39 w100 kernel: sata_qstor: spurious=0 Nov 13 18:36:17 w100 kernel: sata_qstor: spurious=0 Nov 13 18:38:07 w100 kernel: sata_qstor: spurious=0 Nov 13 18:42:58 w100 kernel: sata_qstor: spurious=0 Nov 13 18:45:19 w100 kernel: sata_qstor: spurious=0 Nov 13 18:47:14 w100 kernel: sata_qstor: spurious=0 Nov 13 18:49:42 w100 kernel: sata_qstor: spurious=0 Nov 13 18:52:22 w100 kernel: sata_qstor: spurious=0 Nov 13 18:55:28 w100 kernel: sata_qstor: spurious=0 Nov 13 18:55:42 w100 kernel: sata_qstor: spurious=0 Nov 13 19:00:12 w100 kernel: sata_qstor: spurious=0 Nov 13 19:04:15 w100 kernel: sata_qstor: spurious=0 Nov 13 19:10:41 w100 kernel: sata_qstor: spurious=0 Nov 13 19:12:11 w100 kernel: sata_qstor: spurious=0 Nov 13 19:15:51 w100 kernel: sata_qstor: spurious=0 Nov 13 19:20:12 w100 kernel: sata_qstor: spurious=0 Nov 13 19:24:27 w100 kernel: sata_qstor: spurious=0 Nov 13 19:26:40 w100 kernel: sata_qstor: spurious=0 Nov 13 19:30:41 w100 kernel: sata_qstor: spurious=0 Nov 13 19:38:02 w100 kernel: sata_qstor: spurious=0 Nov 13 19:41:07 w100 kernel: sata_qstor: spurious=0 Nov 13 19:42:42 w100 kernel: sata_qstor: spurious=0 Nov 13 19:48:06 w100 kernel: sata_qstor: spurious=0 Nov 13 19:55:05 w100 kernel: sata_qstor: spurious=0 Nov 13 19:55:07 w100 kernel: sata_qstor: spurious=0 Nov 13 19:58:00 w100 kernel: sata_qstor: spurious=0 Nov 13 19:58:07 w100 kernel: sata_qstor: spurious=0 Nov 13 20:05:51 w100 kernel: sata_qstor: spurious=0 Nov 13 20:08:32 w100 kernel: sata_qstor: spurious=0 Nov 13 20:09:39 w100 kernel: sata_qstor: spurious=0 Nov 13 20:11:54 w100 kernel: sata_qstor: spurious=0 Nov 13 20:17:19 w100 kernel: sata_qstor: spurious=0 Nov 13 20:17:57 w100 kernel: sata_qstor: spurious=0 Nov 13 20:23:48 w100 kernel: sata_qstor: spurious=0 Nov 13 20:25:14 w100 kernel: sata_qstor: spurious=0 Nov 13 20:25:16 w100 kernel: sata_qstor: spurious=0 Nov 13 20:28:56 w100 kernel: sata_qstor: spurious=0 Nov 13 20:29:00 w100 kernel: sata_qstor: spurious=0 Nov 13 20:32:39 w100 kernel: sata_qstor: spurious=0 Nov 13 20:35:06 w100 kernel: sata_qstor: spurious=0 Nov 13 20:38:20 w100 kernel: sata_qstor: spurious=0 Nov 13 20:41:30 w100 kernel: sata_qstor: spurious=0 Nov 13 20:41:33 w100 kernel: sata_qstor: spurious=0 Nov 13 20:45:00 w100 kernel: sata_qstor: spurious=0 Nov 13 21:08:22 w100 kernel: sata_qstor: spurious=0 Nov 13 21:10:28 w100 kernel: sata_qstor: spurious=0 Nov 13 21:13:26 w100 kernel: sata_qstor: spurious=0 Nov 13 21:15:22 w100 kernel: sata_qstor: spurious=0 Nov 13 21:23:32 w100 kernel: sata_qstor: spurious=0 Nov 13 21:24:11 w100 kernel: sata_qstor: spurious=0 Nov 13 21:26:40 w100 kernel: sata_qstor: spurious=0 Nov 13 21:33:14 w100 kernel: sata_qstor: spurious=0 Nov 13 21:45:55 w100 kernel: sata_qstor: spurious=0 Nov 13 21:45:57 w100 kernel: sata_qstor: spurious=0 Nov 13 21:56:52 w100 kernel: sata_qstor: spurious=0 Nov 13 21:56:56 w100 kernel: sata_qstor: spurious=0 Nov 13 22:01:53 w100 kernel: sata_qstor: spurious=0 Nov 13 22:22:46 w100 kernel: sata_qstor: spurious=0 Nov 13 22:30:44 w100 kernel: sata_qstor: spurious=0 Nov 13 22:38:52 w100 kernel: sata_qstor: spurious=0 Nov 13 22:41:48 w100 kernel: sata_qstor: spurious=0 Nov 13 22:43:20 w100 kernel: sata_qstor: spurious=0 Nov 13 22:44:58 w100 kernel: sata_qstor: spurious=0 Thanks, Alberto On Mon, 2006-11-13 at 09:29 -0500, Mark Lord wrote: > Alberto Alonso wrote: > > OK, after adding the printk line I can start seeing > > results. > > > > I guess it has been close to 10 on quite a few > > occasions. > .. > > # grep qstor /var/log/messages > > Nov 12 07:00:53 w100 kernel: sata_qstor: spurious=0 > > Nov 12 07:00:53 w100 kernel: sata_qstor: spurious=1 > > Nov 12 07:00:53 w100 kernel: sata_qstor: spurious=0 > > Nov 12 07:00:56 w100 kernel: sata_qstor: spurious=1 > > Nov 12 07:00:56 w100 kernel: sata_qstor: spurious=2 > .. > > On Sun, 2006-11-12 at 00:09 -0500, Mark Lord wrote: > >> Alberto Alonso wrote: > >>> The saga continues. It happened again this morning even with the > >>> patch: > >> .. > >>>> Mmm.. We could apply a bit of fuzzy tolerance for the odd glitch. > >>>> Try this patch (attached) and report back. > >> Did you add the printk() to the patch, as suggested? > .. > > Excellent! > > So, either we have a very noisy bit of hardware in there, > or something is wrong with sata_qstor.c. > > The device has two methods for dealing with commands. > Regular R/W uses the driver's host queue "packet" interface, > and all other commands pass through the legacy MMIO mechanism. > > I'm betting on some bug/interaction with the latter. > > Try this patch and see what happens, on top of the printk patch. > > Thanks > > > -- Alberto Alonso Global Gate Systems LLC. (512) 351-7233 http://www.ggsys.net Hardware, consulting, sysadmin, monitoring and remote backups ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: qstor driver -> irq 193: nobody cared 2006-11-14 4:50 ` Alberto Alonso @ 2006-11-14 16:46 ` Mark Lord 2006-11-14 18:17 ` Alberto Alonso 0 siblings, 1 reply; 20+ messages in thread From: Mark Lord @ 2006-11-14 16:46 UTC (permalink / raw) To: Alberto Alonso; +Cc: linux-kernel Alberto Alonso wrote: > Things are improving, after the latest patch I can still > see spurious messages, but the count stays at 0. Mmm.. Okay, so we have a kludge fix (just get rid of the printk's we added). But I would like to find out more about what is going on. We seem to be getting lots of "leftover interrupts". I'll look through my full qstor block driver (the high-performance queuing driver, out-of-tree), and see if we missed an IRQ-mask bit someplace in the simple sata_qstor.c re-implementation. Cheers ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: qstor driver -> irq 193: nobody cared 2006-11-14 16:46 ` Mark Lord @ 2006-11-14 18:17 ` Alberto Alonso 2006-11-14 18:23 ` Mark Lord 0 siblings, 1 reply; 20+ messages in thread From: Alberto Alonso @ 2006-11-14 18:17 UTC (permalink / raw) To: Mark Lord; +Cc: linux-kernel Sounds good, let me know if you need me to do any testing or help on the programming. I've been wanting to get into kernel drivers, but never did find the right time/place to do it. Thanks, Alberto On Tue, 2006-11-14 at 11:46 -0500, Mark Lord wrote: > Alberto Alonso wrote: > > Things are improving, after the latest patch I can still > > see spurious messages, but the count stays at 0. > > Mmm.. Okay, so we have a kludge fix (just get rid of the printk's we added). > > But I would like to find out more about what is going on. > We seem to be getting lots of "leftover interrupts". > I'll look through my full qstor block driver (the high-performance > queuing driver, out-of-tree), and see if we missed an IRQ-mask bit > someplace in the simple sata_qstor.c re-implementation. > > Cheers -- Alberto Alonso Global Gate Systems LLC. (512) 351-7233 http://www.ggsys.net Hardware, consulting, sysadmin, monitoring and remote backups ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: qstor driver -> irq 193: nobody cared 2006-11-14 18:17 ` Alberto Alonso @ 2006-11-14 18:23 ` Mark Lord 2006-11-16 6:35 ` Alberto Alonso 0 siblings, 1 reply; 20+ messages in thread From: Mark Lord @ 2006-11-14 18:23 UTC (permalink / raw) To: Alberto Alonso; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 289 bytes --] Alberto Alonso wrote: > Sounds good, let me know if you need me to do any > testing or help on the programming. Okay, try this (untested) and see if it cleans things up. I'm also including the old "printk" patch, so that we can tell whether the "fix" is actually working or not. Thanks [-- Attachment #2: qstor_spurious2.patch --] [-- Type: text/x-patch, Size: 877 bytes --] --- old/drivers/scsi/sata_qstor.c 2006-09-19 23:42:06.000000000 -0400 +++ linux/drivers/scsi/sata_qstor.c 2006-11-06 09:50:02.000000000 -0500 @@ -459,6 +459,7 @@ { struct ata_host_set *host_set = dev_instance; unsigned int handled = 0; + static int spurious = 0; VPRINTK("ENTER\n"); @@ -466,6 +467,20 @@ handled = qs_intr_pkt(host_set) | qs_intr_mmio(host_set); spin_unlock(&host_set->lock); + /* There are reports of at least one system with glitchy interrupts, + * and if we return !handled here for those then the kernel may totally + * disable our own IRQ line (duh!). + * So, try and be tolerant, but not *too* tolerant. + */ + if (!handled) { + if (spurious < 10) { + printk("sata_qstor: spurious=%d\n", spurious); + ++spurious; + handled = 1; + } + } else if (spurious) + --spurious; + VPRINTK("EXIT\n"); return IRQ_RETVAL(handled); [-- Attachment #3: qstor_nien_fix.patch --] [-- Type: text/x-patch, Size: 994 bytes --] --- old/drivers/scsi/sata_qstor.c 2006-11-14 11:30:37.000000000 -0500 +++ linux/drivers/scsi/sata_qstor.c 2006-11-14 13:22:05.000000000 -0500 @@ -299,6 +299,19 @@ return nelem; } +static void qs_set_nien (struct ata_port *ap, int new_nien) +{ + struct ata_ioports *ioaddr = &ap->ioaddr; + + if ((ap->ctl & ATA_NIEN) != new_nien) { + ap->ctl = (ap->ctl & ~ATA_NIEN) | new_nien; + ap->last_ctl = ap->ctl; + writeb(ap->ctl, (void __iomem *)ioaddr->ctl_addr); + wmb(); + ata_check_status(ap); + } +} + static void qs_qc_prep(struct ata_queued_cmd *qc) { struct qs_port_priv *pp = qc->ap->private_data; @@ -357,6 +370,8 @@ switch (qc->tf.protocol) { case ATA_PROT_DMA: + /* packet mode requires that the NIEN bit be turned on */ + qs_set_nien(qc->ap, ATA_NIEN); pp->state = qs_state_pkt; qs_packet_start(qc); @@ -370,6 +385,7 @@ break; } + qs_set_nien(qc->ap, 0); // FIXME: is this necessary here? pp->state = qs_state_mmio; return ata_qc_issue_prot(qc); } ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: qstor driver -> irq 193: nobody cared 2006-11-14 18:23 ` Mark Lord @ 2006-11-16 6:35 ` Alberto Alonso 2006-11-16 13:53 ` Mark Lord 0 siblings, 1 reply; 20+ messages in thread From: Alberto Alonso @ 2006-11-16 6:35 UTC (permalink / raw) To: Mark Lord; +Cc: linux-kernel Sorry for the long delay, I've been called on too many issues at work this week. Anyway, the patch basically made the drives not usable. Here is the log from the boot process: libata version 1.20 loaded. sata_qstor 0000:01:03.0: version 0.05 ata1: SATA max UDMA/133 cmd 0xF8820400 ctl 0xF8820440 bmdma 0x0 irq 185 ata2: SATA max UDMA/133 cmd 0xF8824400 ctl 0xF8824440 bmdma 0x0 irq 185 ata3: SATA max UDMA/133 cmd 0xF8828400 ctl 0xF8828440 bmdma 0x0 irq 185 ata4: SATA max UDMA/133 cmd 0xF882C400 ctl 0xF882C440 bmdma 0x0 irq 185 ata1: SATA link up 3.0 Gbps (SStatus 123) ata1: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4023 85:3469 86:3c01 87:4023 88:407f ata1: dev 0 ATA-7, max UDMA/133, 976773168 sectors: LBA48 ata1: dev 0 configured for UDMA/133 scsi0 : sata_qstor ata2: SATA link up 3.0 Gbps (SStatus 123) ata2: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4023 85:3469 86:3c01 87:4023 88:407f ata2: dev 0 ATA-7, max UDMA/133, 976773168 sectors: LBA48 ata2: dev 0 configured for UDMA/133 scsi1 : sata_qstor ata3: SATA link up 3.0 Gbps (SStatus 123) ata3: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4023 85:3469 86:3c01 87:4023 88:407f ata3: dev 0 ATA-7, max UDMA/133, 976771055 sectors: LBA48 ata3: dev 0 configured for UDMA/133 scsi2 : sata_qstor ata4: SATA link up 3.0 Gbps (SStatus 123) ata4: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4023 85:3469 86:3c01 87:4023 88:407f ata4: dev 0 ATA-7, max UDMA/133, 976773168 sectors: LBA48 ata4: dev 0 configured for UDMA/133 scsi3 : sata_qstor Vendor: ATA Model: ST3500641AS Rev: 3.AA Type: Direct-Access ANSI SCSI revision: 05 Vendor: ATA Model: ST3500641AS Rev: 3.AA Type: Direct-Access ANSI SCSI revision: 05 Vendor: ATA Model: ST3500641AS Rev: 3.AA Type: Direct-Access ANSI SCSI revision: 05 Vendor: ATA Model: ST3500641AS Rev: 3.AA Type: Direct-Access ANSI SCSI revision: 05 SCSI device sda: 976773168 512-byte hdwr sectors (500108 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back SCSI device sda: 976773168 512-byte hdwr sectors (500108 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back sda: unknown partition table sd 0:0:0:0: Attached scsi disk sda SCSI device sdb: 976773168 512-byte hdwr sectors (500108 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: drive cache: write back SCSI device sdb: 976773168 512-byte hdwr sectors (500108 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: drive cache: write back sdb: unknown partition table sd 1:0:0:0: Attached scsi disk sdb SCSI device sdc: 976771055 512-byte hdwr sectors (500107 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: drive cache: write back SCSI device sdc: 976771055 512-byte hdwr sectors (500107 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: drive cache: write back sdc: sdc1 sd 2:0:0:0: Attached scsi disk sdc SCSI device sdd: 976773168 512-byte hdwr sectors (500108 MB) sdd: Write Protect is off sdd: Mode Sense: 00 3a 00 00 SCSI device sdd: drive cache: write back SCSI device sdd: 976773168 512-byte hdwr sectors (500108 MB) sdd: Write Protect is off sdd: Mode Sense: 00 3a 00 00 SCSI device sdd: drive cache: write back sdd: sdd1 sd 3:0:0:0: Attached scsi disk sdd sd 0:0:0:0: Attached scsi generic sg0 type 0 sd 1:0:0:0: Attached scsi generic sg1 type 0 sd 2:0:0:0: Attached scsi generic sg2 type 0 sd 3:0:0:0: Attached scsi generic sg3 type 0 [...] md: md3 stopped. ata1: command 0x25 timeout, stat 0xff host_stat 0x0 ata1: translated ATA stat/err 0xff/00 to SCSI SK/ASC/ASCQ 0xb/47/00 ata1: status=0xff { Busy } sd 0:0:0:0: SCSI error: return code = 0x8000002 sda: Current: sense key=0xb ASC=0x47 ASCQ=0x0 end_request: I/O error, dev sda, sector 976772992 Buffer I/O error on device sda, logical block 122096624 ata1: command 0x25 timeout, stat 0xff host_stat 0x0 ata1: translated ATA stat/err 0xff/00 to SCSI SK/ASC/ASCQ 0xb/47/00 ata1: status=0xff { Busy } sd 0:0:0:0: SCSI error: return code = 0x8000002 sda: Current: sense key=0xb ASC=0x47 ASCQ=0x0 end_request: I/O error, dev sda, sector 976772992 Buffer I/O error on device sda, logical block 122096624 ata2: command 0x25 timeout, stat 0xff host_stat 0x0 ata2: translated ATA stat/err 0xff/00 to SCSI SK/ASC/ASCQ 0xb/47/00 ata2: status=0xff { Busy } sd 1:0:0:0: SCSI error: return code = 0x8000002 sdb: Current: sense key=0xb ASC=0x47 ASCQ=0x0 end_request: I/O error, dev sdb, sector 976772992 Buffer I/O error on device sdb, logical block 122096624 ata2: command 0x25 timeout, stat 0xff host_stat 0x0 ata2: translated ATA stat/err 0xff/00 to SCSI SK/ASC/ASCQ 0xb/47/00 ata2: status=0xff { Busy } sd 1:0:0:0: SCSI error: return code = 0x8000002 sdb: Current: sense key=0xb ASC=0x47 ASCQ=0x0 end_request: I/O error, dev sdb, sector 976772992 Buffer I/O error on device sdb, logical block 122096624 ata3: command 0x25 timeout, stat 0xff host_stat 0x0 ata3: translated ATA stat/err 0xff/00 to SCSI SK/ASC/ASCQ 0xb/47/00 ata3: status=0xff { Busy } sd 2:0:0:0: SCSI error: return code = 0x8000002 sdc: Current: sense key=0xb ASC=0x47 ASCQ=0x0 end_request: I/O error, dev sdc, sector 976770816 Buffer I/O error on device sdc, logical block 976770816 ata3: command 0x25 timeout, stat 0xff host_stat 0x0 ata3: translated ATA stat/err 0xff/00 to SCSI SK/ASC/ASCQ 0xb/47/00 ata3: status=0xff { Busy } sd 2:0:0:0: SCSI error: return code = 0x8000002 sdc: Current: sense key=0xb ASC=0x47 ASCQ=0x0 end_request: I/O error, dev sdc, sector 976770817 Buffer I/O error on device sdc, logical block 976770817 ata3: command 0x25 timeout, stat 0xff host_stat 0x0 ata3: translated ATA stat/err 0xff/00 to SCSI SK/ASC/ASCQ 0xb/47/00 ata3: status=0xff { Busy } sd 2:0:0:0: SCSI error: return code = 0x8000002 sdc: Current: sense key=0xb ASC=0x47 ASCQ=0x0 end_request: I/O error, dev sdc, sector 976770818 Buffer I/O error on device sdc, logical block 976770818 ata3: command 0x25 timeout, stat 0xff host_stat 0x0 ata3: translated ATA stat/err 0xff/00 to SCSI SK/ASC/ASCQ 0xb/47/00 ata3: status=0xff { Busy } sd 2:0:0:0: SCSI error: return code = 0x8000002 sdc: Current: sense key=0xb ASC=0x47 ASCQ=0x0 end_request: I/O error, dev sdc, sector 976770819 Buffer I/O error on device sdc, logical block 976770819 ata3: command 0x25 timeout, stat 0xff host_stat 0x0 ata3: translated ATA stat/err 0xff/00 to SCSI SK/ASC/ASCQ 0xb/47/00 ata3: status=0xff { Busy } sd 2:0:0:0: SCSI error: return code = 0x8000002 sdc: Current: sense key=0xb ASC=0x47 ASCQ=0x0 end_request: I/O error, dev sdc, sector 976770820 Buffer I/O error on device sdc, logical block 976770820 ata3: command 0x25 timeout, stat 0xff host_stat 0x0 ata3: translated ATA stat/err 0xff/00 to SCSI SK/ASC/ASCQ 0xb/47/00 ata3: status=0xff { Busy } sd 2:0:0:0: SCSI error: return code = 0x8000002 sdc: Current: sense key=0xb ASC=0x47 ASCQ=0x0 end_request: I/O error, dev sdc, sector 976770821 Buffer I/O error on device sdc, logical block 976770821 ata3: command 0x25 timeout, stat 0xff host_stat 0x0 ata3: translated ATA stat/err 0xff/00 to SCSI SK/ASC/ASCQ 0xb/47/00 ata3: status=0xff { Busy } sd 2:0:0:0: SCSI error: return code = 0x8000002 sdc: Current: sense key=0xb ASC=0x47 ASCQ=0x0 end_request: I/O error, dev sdc, sector 976770822 Buffer I/O error on device sdc, logical block 976770822 ata3: command 0x25 timeout, stat 0xff host_stat 0x0 ata3: translated ATA stat/err 0xff/00 to SCSI SK/ASC/ASCQ 0xb/47/00 ata3: status=0xff { Busy } sd 2:0:0:0: SCSI error: return code = 0x8000002 sdc: Current: sense key=0xb ASC=0x47 ASCQ=0x0 end_request: I/O error, dev sdc, sector 976770823 Buffer I/O error on device sdc, logical block 976770823 ata3: command 0x25 timeout, stat 0xff host_stat 0x0 ata3: translated ATA stat/err 0xff/00 to SCSI SK/ASC/ASCQ 0xb/47/00 ata3: status=0xff { Busy } sd 2:0:0:0: SCSI error: return code = 0x8000002 sdc: Current: sense key=0xb ASC=0x47 ASCQ=0x0 end_request: I/O error, dev sdc, sector 976770816 Buffer I/O error on device sdc, logical block 976770816 ata3: command 0x25 timeout, stat 0xff host_stat 0x0 ata3: translated ATA stat/err 0xff/00 to SCSI SK/ASC/ASCQ 0xb/47/00 ata3: status=0xff { Busy } sd 2:0:0:0: SCSI error: return code = 0x8000002 sdc: Current: sense key=0xb ASC=0x47 ASCQ=0x0 end_request: I/O error, dev sdc, sector 976770817 Buffer I/O error on device sdc, logical block 976770817 ata3: command 0x25 timeout, stat 0xff host_stat 0x0 ata3: translated ATA stat/err 0xff/00 to SCSI SK/ASC/ASCQ 0xb/47/00 ata3: status=0xff { Busy } sd 2:0:0:0: SCSI error: return code = 0x8000002 sdc: Current: sense key=0xb ASC=0x47 ASCQ=0x0 end_request: I/O error, dev sdc, sector 976770818 Buffer I/O error on device sdc, logical block 976770818 ata3: command 0x25 timeout, stat 0xff host_stat 0x0 ata3: translated ATA stat/err 0xff/00 to SCSI SK/ASC/ASCQ 0xb/47/00 ata3: status=0xff { Busy } sd 2:0:0:0: SCSI error: return code = 0x8000002 sdc: Current: sense key=0xb ASC=0x47 ASCQ=0x0 end_request: I/O error, dev sdc, sector 976770819 Buffer I/O error on device sdc, logical block 976770819 ata3: command 0x25 timeout, stat 0xff host_stat 0x0 ata3: translated ATA stat/err 0xff/00 to SCSI SK/ASC/ASCQ 0xb/47/00 ata3: status=0xff { Busy } sd 2:0:0:0: SCSI error: return code = 0x8000002 sdc: Current: sense key=0xb ASC=0x47 ASCQ=0x0 end_request: I/O error, dev sdc, sector 976770820 Buffer I/O error on device sdc, logical block 976770820 ata3: command 0x25 timeout, stat 0xff host_stat 0x0 ata3: translated ATA stat/err 0xff/00 to SCSI SK/ASC/ASCQ 0xb/47/00 ata3: status=0xff { Busy } sd 2:0:0:0: SCSI error: return code = 0x8000002 sdc: Current: sense key=0xb ASC=0x47 ASCQ=0x0 end_request: I/O error, dev sdc, sector 976770821 Buffer I/O error on device sdc, logical block 976770821 ata3: command 0x25 timeout, stat 0xff host_stat 0x0 ata3: translated ATA stat/err 0xff/00 to SCSI SK/ASC/ASCQ 0xb/47/00 ata3: status=0xff { Busy } sd 2:0:0:0: SCSI error: return code = 0x8000002 sdc: Current: sense key=0xb ASC=0x47 ASCQ=0x0 end_request: I/O error, dev sdc, sector 976770822 Buffer I/O error on device sdc, logical block 976770822 ata3: command 0x25 timeout, stat 0xff host_stat 0x0 ata3: translated ATA stat/err 0xff/00 to SCSI SK/ASC/ASCQ 0xb/47/00 ata3: status=0xff { Busy } sd 2:0:0:0: SCSI error: return code = 0x8000002 sdc: Current: sense key=0xb ASC=0x47 ASCQ=0x0 end_request: I/O error, dev sdc, sector 976770823 Buffer I/O error on device sdc, logical block 976770823 ata4: command 0x25 timeout, stat 0xff host_stat 0x0 ata4: translated ATA stat/err 0xff/00 to SCSI SK/ASC/ASCQ 0xb/47/00 ata4: status=0xff { Busy } sd 3:0:0:0: SCSI error: return code = 0x8000002 sdd: Current: sense key=0xb ASC=0x47 ASCQ=0x0 end_request: I/O error, dev sdd, sector 976772992 Buffer I/O error on device sdd, logical block 122096624 ata4: command 0x25 timeout, stat 0xff host_stat 0x0 ata4: translated ATA stat/err 0xff/00 to SCSI SK/ASC/ASCQ 0xb/47/00 ata4: status=0xff { Busy } sd 3:0:0:0: SCSI error: return code = 0x8000002 sdd: Current: sense key=0xb ASC=0x47 ASCQ=0x0 end_request: I/O error, dev sdd, sector 976772992 Buffer I/O error on device sdd, logical block 122096624 [...] md3 is software RAID 5 composed of sda through sdd, which are the disks attached to the qstor. I went back to the old kernel to be able to use this array. Any ideas? Thanks, Alberto On Tue, 2006-11-14 at 13:23 -0500, Mark Lord wrote: > Alberto Alonso wrote: > > Sounds good, let me know if you need me to do any > > testing or help on the programming. > > Okay, try this (untested) and see if it cleans things up. > I'm also including the old "printk" patch, so that we can > tell whether the "fix" is actually working or not. > > Thanks -- Alberto Alonso Global Gate Systems LLC. (512) 351-7233 http://www.ggsys.net Hardware, consulting, sysadmin, monitoring and remote backups ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: qstor driver -> irq 193: nobody cared 2006-11-16 6:35 ` Alberto Alonso @ 2006-11-16 13:53 ` Mark Lord 2006-11-17 21:42 ` Alberto Alonso 0 siblings, 1 reply; 20+ messages in thread From: Mark Lord @ 2006-11-16 13:53 UTC (permalink / raw) To: Alberto Alonso; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 878 bytes --] Alberto Alonso wrote: > Sorry for the long delay, I've been called on too > many issues at work this week. > > Anyway, the patch basically made the drives not usable. Mmm.. Okay, thanks for helping track this down. It appears that this got broken when the ATA_TFLAG_POLLING got introduced into libata, replacing previous checks of ATA_NIEN. Or maybe even before that. Not many of us have qstor cards! Speaking of which, I'll dig my own qstor card out of mothballs soon, and work out a proper fix for it soon-ish. In the meanwhile, could you take a clean kernel, and apply the first attached patch (qstor_spurious_1.patch), and see if it fixes things. If not, then you can instead apply the second patch (qstor_spurious_kludge.patch) and your problems should disappear. But I cannot actually push that rubbish upstream, so a "proper" fix will have to come later. Cheers [-- Attachment #2: qstor_spurious_1.patch --] [-- Type: text/x-patch, Size: 458 bytes --] --- linux/drivers/scsi/sata_qstor.c.orig 2006-09-19 23:42:06.000000000 -0400 +++ linux/drivers/scsi/sata_qstor.c 2006-11-16 08:46:43.000000000 -0500 @@ -399,6 +399,7 @@ if (ap && !(ap->flags & ATA_FLAG_DISABLED)) { struct ata_queued_cmd *qc; struct qs_port_priv *pp = ap->private_data; + ata_check_status(ap); /* kill spurious ints */ if (!pp || pp->state != qs_state_pkt) continue; qc = ata_qc_from_tag(ap, ap->active_tag); [-- Attachment #3: qstor_spurious_kludge.patch --] [-- Type: text/x-patch, Size: 934 bytes --] --- linux/drivers/scsi/sata_qstor.c.orig 2006-09-19 23:42:06.000000000 -0400 +++ linux/drivers/scsi/sata_qstor.c 2006-11-16 08:49:57.000000000 -0500 @@ -423,7 +423,7 @@ static inline unsigned int qs_intr_mmio(struct ata_host_set *host_set) { - unsigned int handled = 0, port_no; + unsigned int handled = 1, port_no; for (port_no = 0; port_no < host_set->n_ports; ++port_no) { struct ata_port *ap; @@ -432,13 +432,13 @@ !(ap->flags & ATA_FLAG_DISABLED)) { struct ata_queued_cmd *qc; struct qs_port_priv *pp = ap->private_data; + u8 status = ata_check_status(ap); if (!pp || pp->state != qs_state_mmio) continue; qc = ata_qc_from_tag(ap, ap->active_tag); if (qc && (!(qc->tf.flags & ATA_TFLAG_POLLING))) { /* check main status, clearing INTRQ */ - u8 status = ata_check_status(ap); if ((status & ATA_BUSY)) continue; DPRINTK("ata%u: protocol %d (dev_stat 0x%X)\n", ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: qstor driver -> irq 193: nobody cared 2006-11-16 13:53 ` Mark Lord @ 2006-11-17 21:42 ` Alberto Alonso 0 siblings, 0 replies; 20+ messages in thread From: Alberto Alonso @ 2006-11-17 21:42 UTC (permalink / raw) To: Mark Lord; +Cc: linux-kernel FYI: trying with just the first patch didn't work. I got the usual: irq 185: nobody cared (try booting with the "irqpoll" option) <c013e19a> __report_bad_irq+0x2a/0xa0 <c013d970> handle_IRQ_event +0x30/0x70 <c013e2b0> note_interrupt+0x80/0xf0 <c013da8c> __do_IRQ+0xdc/0xf0 <c0105799> do_IRQ+0x19/0x30 <c010391a> common_interrupt+0x1a/0x20 <c0100d91> default_idle+0x41/0x70 <c0100e60> cpu_idle+0x80/0x90 handlers: [<c0301300>] (qs_intr+0x0/0x230) Disabling IRQ #185 Interestingly enough this is the first time I see it outside of irq 193, not that it matter though. I am going to try now with the second patch instead. Alberto On Thu, 2006-11-16 at 08:53 -0500, Mark Lord wrote: > Alberto Alonso wrote: > > Sorry for the long delay, I've been called on too > > many issues at work this week. > > > > Anyway, the patch basically made the drives not usable. > > Mmm.. Okay, thanks for helping track this down. > > It appears that this got broken when the ATA_TFLAG_POLLING > got introduced into libata, replacing previous checks of ATA_NIEN. > Or maybe even before that. Not many of us have qstor cards! > > Speaking of which, I'll dig my own qstor card out of mothballs soon, > and work out a proper fix for it soon-ish. > > In the meanwhile, could you take a clean kernel, and apply the first > attached patch (qstor_spurious_1.patch), and see if it fixes things. > > If not, then you can instead apply the second patch (qstor_spurious_kludge.patch) > and your problems should disappear. But I cannot actually push that rubbish > upstream, so a "proper" fix will have to come later. > > Cheers -- Alberto Alonso Global Gate Systems LLC. (512) 351-7233 http://www.ggsys.net Hardware, consulting, sysadmin, monitoring and remote backups ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2006-11-17 21:42 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-11-03 18:02 qstor driver -> irq 193: nobody cared Alberto Alonso 2006-11-03 19:00 ` Sergey Vlasov 2006-11-03 20:22 ` Alberto Alonso 2006-11-03 20:52 ` Sergey Vlasov 2006-11-03 23:21 ` Alberto Alonso 2006-11-04 18:39 ` Mark Lord 2006-11-06 4:04 ` Alberto Alonso 2006-11-06 14:51 ` Mark Lord 2006-11-10 17:36 ` Alberto Alonso 2006-11-12 5:09 ` Mark Lord 2006-11-12 5:17 ` Alberto Alonso 2006-11-12 20:31 ` Alberto Alonso 2006-11-13 14:29 ` Mark Lord 2006-11-14 4:50 ` Alberto Alonso 2006-11-14 16:46 ` Mark Lord 2006-11-14 18:17 ` Alberto Alonso 2006-11-14 18:23 ` Mark Lord 2006-11-16 6:35 ` Alberto Alonso 2006-11-16 13:53 ` Mark Lord 2006-11-17 21:42 ` Alberto Alonso
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox