something strange in libata-core.c for kernel 2.6.22-rc3
Mybe I am wrong, but if you are detecting 40-wire cable to set them to
DMA/33, why the check includes also 80-wire cables configuring them to
DMA/33 too?
With this patch my nvidia4 IDE controllers detects correctly and configure
correctly DMA/100 for my HD and DMA/33 for my DVD (the first uses a
80-wire cable, the second a 40-wire cable).
Am I wrong somewhere?
--- libata-core.c.orig 2007-05-20 14:31:25.0 +0200
+++ libata-core.c 2007-05-20 14:34:01.0 +0200
@@ -3901,8 +3901,7 @@
/* UDMA/44 or higher would be available */
if((ap->cbl == ATA_CBL_PATA40) ||
(ata_drive_40wire(dev->id) &&
-(ap->cbl == ATA_CBL_PATA_UNK ||
- ap->cbl == ATA_CBL_PATA80))) {
+(ap->cbl == ATA_CBL_PATA_UNK))) {
ata_dev_printk(dev, KERN_WARNING,
"limited to UDMA/33 due to 40-wire cable\n");
xfer_mask &= ~(0xF8 << ATA_SHIFT_UDMA);
regards
Luigi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
something strange in libata-core.c for kernel 2.6.22-rc3
Mybe I am wrong, but if you are detecting 40-wire cable to set them to
DMA/33, why the check includes also 80-wire cables configuring them to
DMA/33 too?
With this patch my nvidia4 IDE controllers detects correctly and configure
correctly DMA/100 for my HD and DMA/33 for my DVD (the first uses a
80-wire cable, the second a 40-wire cable).
Am I wrong somewhere?
--- libata-core.c.orig 2007-05-20 14:31:25.0 +0200
+++ libata-core.c 2007-05-20 14:34:01.0 +0200
@@ -3901,8 +3901,7 @@
/* UDMA/44 or higher would be available */
if((ap-cbl == ATA_CBL_PATA40) ||
(ata_drive_40wire(dev-id)
-(ap-cbl == ATA_CBL_PATA_UNK ||
- ap-cbl == ATA_CBL_PATA80))) {
+(ap-cbl == ATA_CBL_PATA_UNK))) {
ata_dev_printk(dev, KERN_WARNING,
limited to UDMA/33 due to 40-wire cable\n);
xfer_mask = ~(0xF8 ATA_SHIFT_UDMA);
regards
Luigi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Scalability
On Wed, 2 May 2007, Daniel J Blueman wrote: Date: Wed, 2 May 2007 16:43:44 +0100 From: Daniel J Blueman <[EMAIL PROTECTED]> To: Rajib Majumder <[EMAIL PROTECTED]> Cc: Linux Kernel Subject: Re: Kernel Scalability Resent-Date: Wed, 02 May 2007 17:44:58 +0200 Resent-From: <[EMAIL PROTECTED]> On 2 May, 14:00, "Rajib Majumder" <[EMAIL PROTECTED]> wrote: Hi, I am wondering if 2.4.x/2.6.x kernel is scalable enough to run on 8-CPU hardware. Do we have any scalability comparison data between 2.4/2.6 kernels and beyond 4-CPU? If yes, is the scalablity is near linear? Any input is appreciated. There are 128-processor IA64 systems which run recent 2.6 kernels out there; the per-processor counters, RCU and page-fault scalability work has been instrumental to the necessary scaling for decent resource usage on these. IIRC, there were some patches being developed to improve pagecache scalability lately too, but I guess it all depends on what kind of workload you have... To stay on systems probably more familiar to the user who asked this question, there are also some 64 core X86_64 bot AMD and Intel out there, here the 2.6 kernel is doing very well even on those intel CPU with shared L2 cache. I have some 16 and 32 core Opteron and never had scalability problems. You have to pay a lot of attention to your kernel configuration (100 HZ, just BKL preemption), and to the filesystems you decide to use. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Scalability
On Wed, 2 May 2007, Daniel J Blueman wrote: Date: Wed, 2 May 2007 16:43:44 +0100 From: Daniel J Blueman [EMAIL PROTECTED] To: Rajib Majumder [EMAIL PROTECTED] Cc: Linux Kernel linux-kernel@vger.kernel.org Subject: Re: Kernel Scalability Resent-Date: Wed, 02 May 2007 17:44:58 +0200 Resent-From: [EMAIL PROTECTED] On 2 May, 14:00, Rajib Majumder [EMAIL PROTECTED] wrote: Hi, I am wondering if 2.4.x/2.6.x kernel is scalable enough to run on 8-CPU hardware. Do we have any scalability comparison data between 2.4/2.6 kernels and beyond 4-CPU? If yes, is the scalablity is near linear? Any input is appreciated. There are 128-processor IA64 systems which run recent 2.6 kernels out there; the per-processor counters, RCU and page-fault scalability work has been instrumental to the necessary scaling for decent resource usage on these. IIRC, there were some patches being developed to improve pagecache scalability lately too, but I guess it all depends on what kind of workload you have... To stay on systems probably more familiar to the user who asked this question, there are also some 64 core X86_64 bot AMD and Intel out there, here the 2.6 kernel is doing very well even on those intel CPU with shared L2 cache. I have some 16 and 32 core Opteron and never had scalability problems. You have to pay a lot of attention to your kernel configuration (100 HZ, just BKL preemption), and to the filesystems you decide to use. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about Reiser4
Here is something I don't understand... It seems there is a maintainer, namesys people, which is what I was supposing, and probably it is the most qualified one for reiser4, but it also seems you imply that they are not interested right now in kernel inclusion, since they are not asking "in this moment" for it. Do I misunderstand? To me it seems they are implicitally interested in kernel inclusion since they are maintaining the code, and they alredy asked for this. regards Luigi On Mon, 23 Apr 2007, Andrew Morton wrote: The namesys engineers continue to maintain reiser4 and I continue to receive patches for it. Right now I'd say that the main blockages for reiser4 are a) the developers aren't presently asking for inclusion (afaik) and b) lack of reviewing effort from other kernel developers. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about Reiser4
Here is something I don't understand... It seems there is a maintainer, namesys people, which is what I was supposing, and probably it is the most qualified one for reiser4, but it also seems you imply that they are not interested right now in kernel inclusion, since they are not asking in this moment for it. Do I misunderstand? To me it seems they are implicitally interested in kernel inclusion since they are maintaining the code, and they alredy asked for this. regards Luigi On Mon, 23 Apr 2007, Andrew Morton wrote: The namesys engineers continue to maintain reiser4 and I continue to receive patches for it. Right now I'd say that the main blockages for reiser4 are a) the developers aren't presently asking for inclusion (afaik) and b) lack of reviewing effort from other kernel developers. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
IDE disk runs just in DMA/33 with 2.6.20.2 on nVidia CK804 controller
Hi, I reported this also for 2.6.20 kernel. new libata with controller nVidia CK804 initializes the disk in DMA/33, with with 2.6.19.5 and previous the disk is correctly inizialized in DMA/100. Tha cable is OK, and with older kernels the disks runs without troubles. The sistem has two sata disks on nvidia CK804 controllers, and then a disk as primary master, and a dvd writer (DMA/33) as secondary master) here is lspci -vxxx 00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) (prog-if 8a [Master SecP PriP]) Subsystem: Unknown device f043:815a Flags: bus master, 66MHz, fast devsel, latency 0 I/O ports at f000 [size=16] Capabilities: [44] Power Management version 2 00: de 10 53 00 05 00 b0 00 f2 8a 01 01 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 f0 00 00 00 00 00 00 00 00 00 00 43 f0 5a 81 30: 00 00 00 00 44 00 00 00 00 00 00 00 00 00 03 01 40: 43 f0 5a 81 01 00 02 00 00 00 00 00 00 00 00 00 50: 03 f0 01 00 00 00 00 00 a8 20 a8 20 22 00 20 20 60: 00 c0 00 c6 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 50 96 29 00 00 04 20 00 9e 4f 00 90: 00 00 02 30 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 10 ff ff ff 0a 11 30 07 00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) (prog-if 85 [Master SecO PriO]) Subsystem: ASUSTeK Computer Inc. Unknown device 815a Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 23 I/O ports at 09f0 [size=8] I/O ports at 0bf0 [size=4] I/O ports at 0970 [size=8] I/O ports at 0b70 [size=4] I/O ports at d800 [size=16] Memory at d5002000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 00: de 10 54 00 07 00 b0 00 f3 85 01 01 00 00 00 00 10: f1 09 00 00 f1 0b 00 00 71 09 00 00 71 0b 00 00 20: 01 d8 00 00 00 20 00 d5 00 00 00 00 43 10 5a 81 30: 00 00 00 00 44 00 00 00 00 00 00 00 0b 01 03 01 40: 43 10 5a 81 01 00 02 00 00 00 00 00 00 00 00 00 50: 17 00 00 15 00 00 00 00 a8 20 a8 20 66 00 20 20 60: 00 c0 00 c6 11 0c 00 00 08 0f 06 42 00 00 00 00 70: 2c 78 c4 40 01 10 00 00 01 10 00 00 20 00 20 00 80: 00 00 00 40 00 50 4a 7f 00 00 02 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 06 00 06 10 00 00 01 01 a0: 50 01 00 7c 00 00 00 00 00 00 00 00 33 bb aa 02 b0: 05 cc 84 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 0a 00 0a 00 08 00 02 a8 d0: 01 00 02 0d 42 00 00 00 00 00 00 00 0f 00 d0 87 e0: 01 00 02 0d 42 00 00 00 00 00 00 00 f7 e0 e2 01 f0: 00 00 00 00 00 00 00 00 00 ff ff ff 0f 36 32 07 00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) (prog-if 85 [Master SecO PriO]) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 22 I/O ports at 09e0 [size=8] I/O ports at 0be0 [size=4] I/O ports at 0960 [size=8] I/O ports at 0b60 [size=4] I/O ports at c400 [size=16] Memory at d5001000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 00: de 10 55 00 07 00 b0 00 f3 85 01 01 00 00 00 00 10: e1 09 00 00 e1 0b 00 00 61 09 00 00 61 0b 00 00 20: 01 c4 00 00 00 10 00 d5 00 00 00 00 43 10 5a 81 30: 00 00 00 00 44 00 00 00 00 00 00 00 0a 01 03 01 40: 43 10 5a 81 01 00 02 00 00 00 00 00 00 00 00 00 50: 17 00 00 15 00 00 00 00 a8 20 a8 20 66 00 20 20 60: 00 c0 00 c6 11 0c 00 00 08 0f 06 42 00 00 00 00 70: 2c 78 c4 40 01 10 00 00 01 10 00 00 20 00 20 00 80: 00 00 00 40 00 a0 4a 7f 00 00 02 2c 00 00 00 00 90: 00 00 00 00 00 00 00 00 06 00 06 10 00 00 01 01 a0: 50 01 00 7c 00 00 00 00 00 00 00 00 33 bb aa 02 b0: 05 cc 84 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 0a 00 0a 00 08 00 02 a8 d0: 01 00 02 0d 42 00 00 00 00 00 00 00 ea 9f f6 80 e0: 01 00 02 0d 42 00 00 00 00 00 00 00 50 80 00 00 f0: 00 00 00 00 00 00 00 00 00 ff ff ff 11 3f 32 07 00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2) (prog-if 01 [Subtractive decode]) Flags: bus master, 66MHz, fast devsel, latency 0 Bus: primary=00, secondary=05, subordinate=05, sec-latency=128 I/O behind bridge: a000-afff Memory behind bridge: d300-d4ff Prefetchable memory behind bridge: 8800-880f 00: de 10 5c 00 07 01 a0 00 a2 01 04 06 00 00 01 00 10: 00 00 00 00 00 00 00 00 00 05 05 80 a0 a0 80 a2 20: 00 d3 f0 d4 00 88 00 88 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 06 40: 00 00 07 00 01 00 02 00 07 00 00 00 00 00 44 01 50: 00 00 fe 7f 00 00 00 00 ff 1f ff 1f 00 00 00 00 60: 00 00 00 00 00
IDE disk runs just in DMA/33 with 2.6.20.2 on nVidia CK804 controller
Hi, I reported this also for 2.6.20 kernel. new libata with controller nVidia CK804 initializes the disk in DMA/33, with with 2.6.19.5 and previous the disk is correctly inizialized in DMA/100. Tha cable is OK, and with older kernels the disks runs without troubles. The sistem has two sata disks on nvidia CK804 controllers, and then a disk as primary master, and a dvd writer (DMA/33) as secondary master) here is lspci -vxxx 00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) (prog-if 8a [Master SecP PriP]) Subsystem: Unknown device f043:815a Flags: bus master, 66MHz, fast devsel, latency 0 I/O ports at f000 [size=16] Capabilities: [44] Power Management version 2 00: de 10 53 00 05 00 b0 00 f2 8a 01 01 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 f0 00 00 00 00 00 00 00 00 00 00 43 f0 5a 81 30: 00 00 00 00 44 00 00 00 00 00 00 00 00 00 03 01 40: 43 f0 5a 81 01 00 02 00 00 00 00 00 00 00 00 00 50: 03 f0 01 00 00 00 00 00 a8 20 a8 20 22 00 20 20 60: 00 c0 00 c6 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 50 96 29 00 00 04 20 00 9e 4f 00 90: 00 00 02 30 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 10 ff ff ff 0a 11 30 07 00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) (prog-if 85 [Master SecO PriO]) Subsystem: ASUSTeK Computer Inc. Unknown device 815a Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 23 I/O ports at 09f0 [size=8] I/O ports at 0bf0 [size=4] I/O ports at 0970 [size=8] I/O ports at 0b70 [size=4] I/O ports at d800 [size=16] Memory at d5002000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 00: de 10 54 00 07 00 b0 00 f3 85 01 01 00 00 00 00 10: f1 09 00 00 f1 0b 00 00 71 09 00 00 71 0b 00 00 20: 01 d8 00 00 00 20 00 d5 00 00 00 00 43 10 5a 81 30: 00 00 00 00 44 00 00 00 00 00 00 00 0b 01 03 01 40: 43 10 5a 81 01 00 02 00 00 00 00 00 00 00 00 00 50: 17 00 00 15 00 00 00 00 a8 20 a8 20 66 00 20 20 60: 00 c0 00 c6 11 0c 00 00 08 0f 06 42 00 00 00 00 70: 2c 78 c4 40 01 10 00 00 01 10 00 00 20 00 20 00 80: 00 00 00 40 00 50 4a 7f 00 00 02 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 06 00 06 10 00 00 01 01 a0: 50 01 00 7c 00 00 00 00 00 00 00 00 33 bb aa 02 b0: 05 cc 84 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 0a 00 0a 00 08 00 02 a8 d0: 01 00 02 0d 42 00 00 00 00 00 00 00 0f 00 d0 87 e0: 01 00 02 0d 42 00 00 00 00 00 00 00 f7 e0 e2 01 f0: 00 00 00 00 00 00 00 00 00 ff ff ff 0f 36 32 07 00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) (prog-if 85 [Master SecO PriO]) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 22 I/O ports at 09e0 [size=8] I/O ports at 0be0 [size=4] I/O ports at 0960 [size=8] I/O ports at 0b60 [size=4] I/O ports at c400 [size=16] Memory at d5001000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 00: de 10 55 00 07 00 b0 00 f3 85 01 01 00 00 00 00 10: e1 09 00 00 e1 0b 00 00 61 09 00 00 61 0b 00 00 20: 01 c4 00 00 00 10 00 d5 00 00 00 00 43 10 5a 81 30: 00 00 00 00 44 00 00 00 00 00 00 00 0a 01 03 01 40: 43 10 5a 81 01 00 02 00 00 00 00 00 00 00 00 00 50: 17 00 00 15 00 00 00 00 a8 20 a8 20 66 00 20 20 60: 00 c0 00 c6 11 0c 00 00 08 0f 06 42 00 00 00 00 70: 2c 78 c4 40 01 10 00 00 01 10 00 00 20 00 20 00 80: 00 00 00 40 00 a0 4a 7f 00 00 02 2c 00 00 00 00 90: 00 00 00 00 00 00 00 00 06 00 06 10 00 00 01 01 a0: 50 01 00 7c 00 00 00 00 00 00 00 00 33 bb aa 02 b0: 05 cc 84 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 0a 00 0a 00 08 00 02 a8 d0: 01 00 02 0d 42 00 00 00 00 00 00 00 ea 9f f6 80 e0: 01 00 02 0d 42 00 00 00 00 00 00 00 50 80 00 00 f0: 00 00 00 00 00 00 00 00 00 ff ff ff 11 3f 32 07 00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2) (prog-if 01 [Subtractive decode]) Flags: bus master, 66MHz, fast devsel, latency 0 Bus: primary=00, secondary=05, subordinate=05, sec-latency=128 I/O behind bridge: a000-afff Memory behind bridge: d300-d4ff Prefetchable memory behind bridge: 8800-880f 00: de 10 5c 00 07 01 a0 00 a2 01 04 06 00 00 01 00 10: 00 00 00 00 00 00 00 00 00 05 05 80 a0 a0 80 a2 20: 00 d3 f0 d4 00 88 00 88 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 06 40: 00 00 07 00 01 00 02 00 07 00 00 00 00 00 44 01 50: 00 00 fe 7f 00 00 00 00 ff 1f ff 1f 00 00 00 00 60: 00 00 00 00 00
Re: [BUG?] ata disk running maximum at DMA33 with 2.6.20 and new pata driver, NV CK804 ide controller.
Well, the cable is OK, of course I checked. On Wed, 7 Feb 2007, Robert Hancock wrote: Date: Wed, 07 Feb 2007 22:36:58 -0600 From: Robert Hancock <[EMAIL PROTECTED]> To: Alan <[EMAIL PROTECTED]>, linux-kernel Cc: Luigi Genoni <[EMAIL PROTECTED]> Subject: Re: [BUG?] ata disk running maximum at DMA33 with 2.6.20 and new pata driver, NV CK804 ide controller. Resent-Date: Thu, 08 Feb 2007 05:47:22 +0100 Resent-From: <[EMAIL PROTECTED]> Alan wrote: On Wed, 7 Feb 2007 01:19:36 +0100 Luigi Genoni <[EMAIL PROTECTED]> wrote: Hi, since upgrading to kernel 2.6.20 my pata disk, using new pata driver, is initialized maximum in DMA33 mode (and obviously performances drop consequently), as you can see from: Interesting. Willing to test any patch. Firstly can you see if its consistently the case that booting 2.6.20 gives UDMA33 and 2.6.19 UDMA100 over a few reboots. If it is please drop the 2.6.19 drivers/ata/pamd_amd into 2.6.20 and try that. As an aside to this sort of problem, shouldn't we print some kind of loud message in dmesg when we force a high-UDMA-capable device down to UDMA33 due to a 40-wire cable detection? In the case where it truly is a 40-wire cable the user may want to know that and replace the cable, if it isn't it gives more of a hint of why the drive isn't running at full speed.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG?] ata disk running maximum at DMA33 with 2.6.20 and new pata driver, NV CK804 ide controller.
Well, the cable is OK, of course I checked. On Wed, 7 Feb 2007, Robert Hancock wrote: Date: Wed, 07 Feb 2007 22:36:58 -0600 From: Robert Hancock [EMAIL PROTECTED] To: Alan [EMAIL PROTECTED], linux-kernel linux-kernel@vger.kernel.org Cc: Luigi Genoni [EMAIL PROTECTED] Subject: Re: [BUG?] ata disk running maximum at DMA33 with 2.6.20 and new pata driver, NV CK804 ide controller. Resent-Date: Thu, 08 Feb 2007 05:47:22 +0100 Resent-From: [EMAIL PROTECTED] Alan wrote: On Wed, 7 Feb 2007 01:19:36 +0100 Luigi Genoni [EMAIL PROTECTED] wrote: Hi, since upgrading to kernel 2.6.20 my pata disk, using new pata driver, is initialized maximum in DMA33 mode (and obviously performances drop consequently), as you can see from: Interesting. Willing to test any patch. Firstly can you see if its consistently the case that booting 2.6.20 gives UDMA33 and 2.6.19 UDMA100 over a few reboots. If it is please drop the 2.6.19 drivers/ata/pamd_amd into 2.6.20 and try that. As an aside to this sort of problem, shouldn't we print some kind of loud message in dmesg when we force a high-UDMA-capable device down to UDMA33 due to a 40-wire cable detection? In the case where it truly is a 40-wire cable the user may want to know that and replace the cable, if it isn't it gives more of a hint of why the drive isn't running at full speed.. -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG?] ata disk running maximum at DMA33 with 2.6.20 and new pata driver, NV CK804 ide controller.
I did the test you asked and yes, it is consistently booting at DMA33 with 2.6.20 and DMA100 with 2.6.19.3 (20 reboots, 10 2.6.20 and 10 2.6.19 in sparse order). I am compiling a 2.6.20 kernel with older pata_amd.c driver and will let you know. seeing the diff I do exspect it to compile cleanly. Luigi On Wed, 7 Feb 2007, Alan wrote: Date: Wed, 7 Feb 2007 12:20:00 + From: Alan <[EMAIL PROTECTED]> To: Luigi Genoni <[EMAIL PROTECTED]> Cc: linux-ide@vger.kernel.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org Subject: Re: [BUG?] ata disk running maximum at DMA33 with 2.6.20 and new pata driver, NV CK804 ide controller. Resent-Date: Wed, 07 Feb 2007 13:17:42 +0100 Resent-From: <[EMAIL PROTECTED]> On Wed, 7 Feb 2007 01:19:36 +0100 Luigi Genoni <[EMAIL PROTECTED]> wrote: Hi, since upgrading to kernel 2.6.20 my pata disk, using new pata driver, is initialized maximum in DMA33 mode (and obviously performances drop consequently), as you can see from: Interesting. Willing to test any patch. Firstly can you see if its consistently the case that booting 2.6.20 gives UDMA33 and 2.6.19 UDMA100 over a few reboots. If it is please drop the 2.6.19 drivers/ata/pamd_amd into 2.6.20 and try that. Thanks Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG?] ata disk running maximum at DMA33 with 2.6.20 and new pata driver, NV CK804 ide controller.
I did the test you asked and yes, it is consistently booting at DMA33 with 2.6.20 and DMA100 with 2.6.19.3 (20 reboots, 10 2.6.20 and 10 2.6.19 in sparse order). I am compiling a 2.6.20 kernel with older pata_amd.c driver and will let you know. seeing the diff I do exspect it to compile cleanly. Luigi On Wed, 7 Feb 2007, Alan wrote: Date: Wed, 7 Feb 2007 12:20:00 + From: Alan [EMAIL PROTECTED] To: Luigi Genoni [EMAIL PROTECTED] Cc: linux-ide@vger.kernel.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org Subject: Re: [BUG?] ata disk running maximum at DMA33 with 2.6.20 and new pata driver, NV CK804 ide controller. Resent-Date: Wed, 07 Feb 2007 13:17:42 +0100 Resent-From: [EMAIL PROTECTED] On Wed, 7 Feb 2007 01:19:36 +0100 Luigi Genoni [EMAIL PROTECTED] wrote: Hi, since upgrading to kernel 2.6.20 my pata disk, using new pata driver, is initialized maximum in DMA33 mode (and obviously performances drop consequently), as you can see from: Interesting. Willing to test any patch. Firstly can you see if its consistently the case that booting 2.6.20 gives UDMA33 and 2.6.19 UDMA100 over a few reboots. If it is please drop the 2.6.19 drivers/ata/pamd_amd into 2.6.20 and try that. Thanks Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG?] ata disk running maximum at DMA33 with 2.6.20 and new pata driver, NV CK804 ide controller.
Hi, since upgrading to kernel 2.6.20 my pata disk, using new pata driver, is initialized maximum in DMA33 mode, as you can see from: pata_amd :00:06.0: version 0.2.7 PCI: Setting latency timer of device :00:06.0 to 64 ata5: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14 ata6: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15 scsi4 : pata_amd ata5.00: ATA-7, max UDMA/100, 156368016 sectors: LBA48 ata5.00: ata5: dev 0 multi count 1 ata5.00: configured for UDMA/33 scsi5 : pata_amd ata6.00: ATAPI, max UDMA/33 ata6.00: configured for UDMA/33 scsi 4:0:0:0: Direct-Access ATA SAMSUNG SP0822N WA10 PQ: 0 ANSI: 5 SCSI device sdc: 156368016 512-byte hdwr sectors (80060 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdc: 156368016 512-byte hdwr sectors (80060 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdc: sdc1 sdc2 sdc3 sd 4:0:0:0: Attached scsi disk sdc while with kernel 2.6.19.X it was initialized correctly in DMA100 mode: pata_amd :00:06.0: version 0.2.4 PCI: Setting latency timer of device :00:06.0 to 64 ata5: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14 ata6: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15 scsi4 : pata_amd ata5.00: ATA-7, max UDMA/100, 156368016 sectors: LBA48 ata5.00: ata5: dev 0 multi count 1 ata5.00: configured for UDMA/100 scsi5 : pata_amd ata6.00: ATAPI, max UDMA/33 ata6.00: configured for UDMA/33 scsi 4:0:0:0: Direct-Access ATA SAMSUNG SP0822N WA10 PQ: 0 ANSI: 5 SCSI device sdc: 156368016 512-byte hdwr sectors (80060 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: drive cache: write back SCSI device sdc: 156368016 512-byte hdwr sectors (80060 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: drive cache: write back sdc: sdc1 sdc2 sdc3 sd 4:0:0:0: Attached scsi disk sdc I have other 2 sata disks on this system, and I have no problems with them. I Wonder if this is due to some controller/disk problem triggered just by 2.6.20 kernel (I saw there are a lot of changes into eh code), while 2.6.19.X and previous sees everything OK. This system is an Athlon64 X2 3800+ with an nvidia2 IDE controller here is the lspci -v 00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) Subsystem: ASUSTeK Computer Inc. Unknown device 815a Flags: bus master, 66MHz, fast devsel, latency 0 Capabilities: [44] HyperTransport: Slave or Primary Interface Capabilities: [e0] HyperTransport: MSI Mapping 00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Flags: bus master, 66MHz, fast devsel, latency 0 00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Flags: 66MHz, fast devsel, IRQ 10 I/O ports at e400 [size=32] I/O ports at 4c00 [size=64] I/O ports at 4c40 [size=64] Capabilities: [44] Power Management version 2 00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2) (prog-if 10 [OHCI]) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 20 Memory at d4004000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 22 Memory at d4005000 (32-bit, non-prefetchable) [size=256] Capabilities: [44] Debug port Capabilities: [80] Power Management version 2 00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2) Subsystem: ASUSTeK Computer Inc. Unknown device 8166 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 23 I/O ports at dc00 [size=256] I/O ports at e000 [size=256] Memory at d4003000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) (prog-if 8a [Master SecP PriP]) Subsystem: Unknown device f043:815a Flags: bus master, 66MHz, fast devsel, latency 0 [virtual] Memory at 01f0 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 03f0 (type 3, non-prefetchable) [disabled] [size=1] [virtual] Memory at 0170 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 0370 (type 3, non-prefetchable) [disabled] [size=1] I/O ports at f000 [size=16] Capabilities: [44] Power
[BUG?] ata disk running maximum at DMA33 with 2.6.20 and new pata driver, NV CK804 ide controller.
Hi, since upgrading to kernel 2.6.20 my pata disk, using new pata driver, is initialized maximum in DMA33 mode, as you can see from: pata_amd :00:06.0: version 0.2.7 PCI: Setting latency timer of device :00:06.0 to 64 ata5: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14 ata6: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15 scsi4 : pata_amd ata5.00: ATA-7, max UDMA/100, 156368016 sectors: LBA48 ata5.00: ata5: dev 0 multi count 1 ata5.00: configured for UDMA/33 scsi5 : pata_amd ata6.00: ATAPI, max UDMA/33 ata6.00: configured for UDMA/33 scsi 4:0:0:0: Direct-Access ATA SAMSUNG SP0822N WA10 PQ: 0 ANSI: 5 SCSI device sdc: 156368016 512-byte hdwr sectors (80060 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdc: 156368016 512-byte hdwr sectors (80060 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdc: sdc1 sdc2 sdc3 sd 4:0:0:0: Attached scsi disk sdc while with kernel 2.6.19.X it was initialized correctly in DMA100 mode: pata_amd :00:06.0: version 0.2.4 PCI: Setting latency timer of device :00:06.0 to 64 ata5: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14 ata6: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15 scsi4 : pata_amd ata5.00: ATA-7, max UDMA/100, 156368016 sectors: LBA48 ata5.00: ata5: dev 0 multi count 1 ata5.00: configured for UDMA/100 scsi5 : pata_amd ata6.00: ATAPI, max UDMA/33 ata6.00: configured for UDMA/33 scsi 4:0:0:0: Direct-Access ATA SAMSUNG SP0822N WA10 PQ: 0 ANSI: 5 SCSI device sdc: 156368016 512-byte hdwr sectors (80060 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: drive cache: write back SCSI device sdc: 156368016 512-byte hdwr sectors (80060 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: drive cache: write back sdc: sdc1 sdc2 sdc3 sd 4:0:0:0: Attached scsi disk sdc I have other 2 sata disks on this system, and I have no problems with them. I Wonder if this is due to some controller/disk problem triggered just by 2.6.20 kernel (I saw there are a lot of changes into eh code), while 2.6.19.X and previous sees everything OK. This system is an Athlon64 X2 3800+ with an nvidia2 IDE controller here is the lspci -v 00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) Subsystem: ASUSTeK Computer Inc. Unknown device 815a Flags: bus master, 66MHz, fast devsel, latency 0 Capabilities: [44] HyperTransport: Slave or Primary Interface Capabilities: [e0] HyperTransport: MSI Mapping 00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Flags: bus master, 66MHz, fast devsel, latency 0 00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Flags: 66MHz, fast devsel, IRQ 10 I/O ports at e400 [size=32] I/O ports at 4c00 [size=64] I/O ports at 4c40 [size=64] Capabilities: [44] Power Management version 2 00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2) (prog-if 10 [OHCI]) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 20 Memory at d4004000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 22 Memory at d4005000 (32-bit, non-prefetchable) [size=256] Capabilities: [44] Debug port Capabilities: [80] Power Management version 2 00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2) Subsystem: ASUSTeK Computer Inc. Unknown device 8166 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 23 I/O ports at dc00 [size=256] I/O ports at e000 [size=256] Memory at d4003000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) (prog-if 8a [Master SecP PriP]) Subsystem: Unknown device f043:815a Flags: bus master, 66MHz, fast devsel, latency 0 [virtual] Memory at 01f0 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 03f0 (type 3, non-prefetchable) [disabled] [size=1] [virtual] Memory at 0170 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 0370 (type 3, non-prefetchable) [disabled] [size=1] I/O ports at f000 [size=16] Capabilities: [44] Power
Re: [PATCH 2/2] x86_64 irq: Handle irqs pending in IRR during irq migration.
As I reported when I tested this patch, it works, but I could see an
abnormally high load averay while triggering the error message. anyway, it
is better to have an high load averag three or four times higher than what
you would expect then a crash/reboot. isn't it? :)
Luigi Genoni
p.s.
will test the other definitive patch on montday on both 8 and 16 CPU
system.
On Sat, 3 Feb 2007, Eric W. Biederman wrote:
Date: Sat, 03 Feb 2007 00:55:11 -0700
From: Eric W. Biederman <[EMAIL PROTECTED]>
To: Arjan van de Ven <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>, linux-kernel@vger.kernel.org,
"Lu, Yinghai" <[EMAIL PROTECTED]>,
Luigi Genoni <[EMAIL PROTECTED]>, Ingo Molnar <[EMAIL PROTECTED]>,
Natalie Protasevich <[EMAIL PROTECTED]>, Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: [PATCH 2/2] x86_64 irq: Handle irqs pending in IRR during irq
migration.
Resent-Date: Sat, 03 Feb 2007 09:05:10 +0100
Resent-From: <[EMAIL PROTECTED]>
Arjan van de Ven <[EMAIL PROTECTED]> writes:
Once the migration operation is complete we know we will receive
no more interrupts on this vector so the irq pending state for
this irq will no longer be updated. If the irq is not pending and
we are in the intermediate state we immediately free the vector,
otherwise in we free the vector in do_IRQ when the pending irq
arrives.
So is this a for-2.6.20 thing? The bug was present in 2.6.19, so
I assume it doesn't affect many people?
I got a few reports of this; irqbalance may trigger this kernel bug it
seems... I would suggest to consider this for 2.6.20 since it's a
hard-hang case
Yes. The bug I fixed will not happen if you don't migrate irqs.
At the very least we want the patch below (already in -mm)
that makes it not a hard hang case.
Subject: [PATCH] x86_64: Survive having no irq mapping for a vector
Occasionally the kernel has bugs that result in no irq being
found for a given cpu vector. If we acknowledge the irq
the system has a good chance of continuing even though we dropped
an missed an irq message. If we continue to simply print a
message and drop and not acknowledge the irq the system is
likely to become non-responsive shortly there after.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/irq.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/x86_64/kernel/irq.c b/arch/x86_64/kernel/irq.c
index 0c06af6..648055a 100644
--- a/arch/x86_64/kernel/irq.c
+++ b/arch/x86_64/kernel/irq.c
@@ -120,9 +120,14 @@ asmlinkage unsigned int do_IRQ(struct pt_regs *regs)
if (likely(irq < NR_IRQS))
generic_handle_irq(irq);
- else if (printk_ratelimit())
- printk(KERN_EMERG "%s: %d.%d No irq handler for vector\n",
- __func__, smp_processor_id(), vector);
+ else {
+ if (!disable_apic)
+ ack_APIC_irq();
+
+ if (printk_ratelimit())
+ printk(KERN_EMERG "%s: %d.%d No irq handler for
vector\n",
+ __func__, smp_processor_id(), vector);
+ }
irq_exit();
--
1.4.4.1.g278f
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] x86_64 irq: Handle irqs pending in IRR during irq migration.
As I reported when I tested this patch, it works, but I could see an
abnormally high load averay while triggering the error message. anyway, it
is better to have an high load averag three or four times higher than what
you would expect then a crash/reboot. isn't it? :)
Luigi Genoni
p.s.
will test the other definitive patch on montday on both 8 and 16 CPU
system.
On Sat, 3 Feb 2007, Eric W. Biederman wrote:
Date: Sat, 03 Feb 2007 00:55:11 -0700
From: Eric W. Biederman [EMAIL PROTECTED]
To: Arjan van de Ven [EMAIL PROTECTED]
Cc: Andrew Morton [EMAIL PROTECTED], linux-kernel@vger.kernel.org,
Lu, Yinghai [EMAIL PROTECTED],
Luigi Genoni [EMAIL PROTECTED], Ingo Molnar [EMAIL PROTECTED],
Natalie Protasevich [EMAIL PROTECTED], Andi Kleen [EMAIL PROTECTED]
Subject: Re: [PATCH 2/2] x86_64 irq: Handle irqs pending in IRR during irq
migration.
Resent-Date: Sat, 03 Feb 2007 09:05:10 +0100
Resent-From: [EMAIL PROTECTED]
Arjan van de Ven [EMAIL PROTECTED] writes:
Once the migration operation is complete we know we will receive
no more interrupts on this vector so the irq pending state for
this irq will no longer be updated. If the irq is not pending and
we are in the intermediate state we immediately free the vector,
otherwise in we free the vector in do_IRQ when the pending irq
arrives.
So is this a for-2.6.20 thing? The bug was present in 2.6.19, so
I assume it doesn't affect many people?
I got a few reports of this; irqbalance may trigger this kernel bug it
seems... I would suggest to consider this for 2.6.20 since it's a
hard-hang case
Yes. The bug I fixed will not happen if you don't migrate irqs.
At the very least we want the patch below (already in -mm)
that makes it not a hard hang case.
Subject: [PATCH] x86_64: Survive having no irq mapping for a vector
Occasionally the kernel has bugs that result in no irq being
found for a given cpu vector. If we acknowledge the irq
the system has a good chance of continuing even though we dropped
an missed an irq message. If we continue to simply print a
message and drop and not acknowledge the irq the system is
likely to become non-responsive shortly there after.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
arch/x86_64/kernel/irq.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/x86_64/kernel/irq.c b/arch/x86_64/kernel/irq.c
index 0c06af6..648055a 100644
--- a/arch/x86_64/kernel/irq.c
+++ b/arch/x86_64/kernel/irq.c
@@ -120,9 +120,14 @@ asmlinkage unsigned int do_IRQ(struct pt_regs *regs)
if (likely(irq NR_IRQS))
generic_handle_irq(irq);
- else if (printk_ratelimit())
- printk(KERN_EMERG %s: %d.%d No irq handler for vector\n,
- __func__, smp_processor_id(), vector);
+ else {
+ if (!disable_apic)
+ ack_APIC_irq();
+
+ if (printk_ratelimit())
+ printk(KERN_EMERG %s: %d.%d No irq handler for
vector\n,
+ __func__, smp_processor_id(), vector);
+ }
irq_exit();
--
1.4.4.1.g278f
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: System crash after "No irq handler for vector" linux 2.6.19
reproduced. it took more or less one hour to reproduce it. I could reproduce it olny running also irqbalance 0.55 and commenting out the sleep 1. The message in syslog is the same and then, after a few seconds I think, KABOM! system crash and reboot. I tested also a similar system that has 4 dual core CPU Opteron 2600MHZ. On this system (linux sees 8 CPU, but it is the same kernel, same gcc, same config, same glibc, same active services) I could not reproduce it even running irqbalance 0.55 in almost 1 hour. Maybe I could reproduce it waiting for more time, but my users need to do their work, so I could not have a longer test window. So on 16 CPU I had the crash, on 8 CPU I had no crash. I need to give back the system to the users, so if you need other tests, please, tell me as soon. thanx Luigi Genoni On Monday 22 January 2007 18:14, Eric W. Biederman wrote: "Luigi Genoni" <[EMAIL PROTECTED]> writes: > (e-mail resent because not delivered using my other e-mail account) > > Hi, > this night a linux server 8 dual core CPU Optern 2600Mhz crashed just > after giving this message > > Jan 22 04:48:28 frey kernel: do_IRQ: 1.98 No irq handler for vector Ok. This indicates that the hardware is doing something we didn't expect. We don't know which irq the hardware was trying to deliver when it sent vector 0x98 to cpu 1. > I have no other logs, and I eventually lost the OOPS since I have no net > console setled up. If you had an oops it may have meant the above message was a secondary symptom. Groan. If it stayed up long enough to give an OOPS then there is a chance the above message appearing only once had nothing to do with the actual crash. How long had the system been up? > As I said sistem is running linux 2.6.19 compiled with gcc 4.1.1 for AMD > Opteron (attached see .config), no kernel preemption excepted the BKL > preemption. glibc 2.4. > > System has 16 GB RAM and 8 dual core Opteron 2600Mhz. > > I am running irqbalance 0.55. > > any hints on what has happened? Three guesses. - A race triggered by irq migration (but I would expect more people to be yelling). The code path where that message comes from is new in 2.6.19 so it may not have had all of the bugs found yet :( - A weird hardware or BIOS setup. - A secondary symptom triggered by some other bug. If this winds up being reproducible we should be able to track it down. If not this may end up in the files of crap something bad happened that we don't understand. The one condition I know how to test for (if you are willing) is an irq migration race. Simply by triggering irq migration much more often, and thus increasing our chances of hitting a problem. Stopping irqbalance and running something like: for irq in 0 24 28 29 44 45 60 68 ; do while :; do for mask in 1 2 4 8 10 20 40 80 100 200 400 800 1000 2000 4000 8000 ; do echo mask > /proc/irq/$irq/smp_affinity sleep 1 done done & done Should force every irq to migrate once a second, and removing the sleep 1 is even harsher, although we max at one irq migration by irq received. If some variation of the above loop does not trigger the do_IRQ ??? No irq handler for vector message chances are it isn't a race in irq migration. If we can rule out the race scenario it will at least put us in the right direction for guessing what went wrong with your box. Eric -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: System crash after No irq handler for vector linux 2.6.19
reproduced. it took more or less one hour to reproduce it. I could reproduce it olny running also irqbalance 0.55 and commenting out the sleep 1. The message in syslog is the same and then, after a few seconds I think, KABOM! system crash and reboot. I tested also a similar system that has 4 dual core CPU Opteron 2600MHZ. On this system (linux sees 8 CPU, but it is the same kernel, same gcc, same config, same glibc, same active services) I could not reproduce it even running irqbalance 0.55 in almost 1 hour. Maybe I could reproduce it waiting for more time, but my users need to do their work, so I could not have a longer test window. So on 16 CPU I had the crash, on 8 CPU I had no crash. I need to give back the system to the users, so if you need other tests, please, tell me as soon. thanx Luigi Genoni On Monday 22 January 2007 18:14, Eric W. Biederman wrote: Luigi Genoni [EMAIL PROTECTED] writes: (e-mail resent because not delivered using my other e-mail account) Hi, this night a linux server 8 dual core CPU Optern 2600Mhz crashed just after giving this message Jan 22 04:48:28 frey kernel: do_IRQ: 1.98 No irq handler for vector Ok. This indicates that the hardware is doing something we didn't expect. We don't know which irq the hardware was trying to deliver when it sent vector 0x98 to cpu 1. I have no other logs, and I eventually lost the OOPS since I have no net console setled up. If you had an oops it may have meant the above message was a secondary symptom. Groan. If it stayed up long enough to give an OOPS then there is a chance the above message appearing only once had nothing to do with the actual crash. How long had the system been up? As I said sistem is running linux 2.6.19 compiled with gcc 4.1.1 for AMD Opteron (attached see .config), no kernel preemption excepted the BKL preemption. glibc 2.4. System has 16 GB RAM and 8 dual core Opteron 2600Mhz. I am running irqbalance 0.55. any hints on what has happened? Three guesses. - A race triggered by irq migration (but I would expect more people to be yelling). The code path where that message comes from is new in 2.6.19 so it may not have had all of the bugs found yet :( - A weird hardware or BIOS setup. - A secondary symptom triggered by some other bug. If this winds up being reproducible we should be able to track it down. If not this may end up in the files of crap something bad happened that we don't understand. The one condition I know how to test for (if you are willing) is an irq migration race. Simply by triggering irq migration much more often, and thus increasing our chances of hitting a problem. Stopping irqbalance and running something like: for irq in 0 24 28 29 44 45 60 68 ; do while :; do for mask in 1 2 4 8 10 20 40 80 100 200 400 800 1000 2000 4000 8000 ; do echo mask /proc/irq/$irq/smp_affinity sleep 1 done done done Should force every irq to migrate once a second, and removing the sleep 1 is even harsher, although we max at one irq migration by irq received. If some variation of the above loop does not trigger the do_IRQ ??? No irq handler for vector message chances are it isn't a race in irq migration. If we can rule out the race scenario it will at least put us in the right direction for guessing what went wrong with your box. Eric -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Gaming Interface
On Mon, 8 Jan 2007, Dirk wrote: Alright. I came to discuss an idea I had because I realized that installing Windows and running Linux in VMware is the only _fun_ way to play "real" Games and have Linux at the same time. And everyone who says I'm a troll doesn't like Games or simple things. Dirk Please, don't think so. The point is simpler. Linux has its own standard, which is a Unix one, openGL on X11 and then SDL. There is a kernel component to get 3d acceleration with openGL, which is DRM. This standard is nice, and openGL is available also on windows, where doom3, quake4 and the like use it happily. There is no point to introduce something different and to change this standard. Luigi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Gaming Interface
On Mon, 8 Jan 2007, Dirk wrote: Alright. I came to discuss an idea I had because I realized that installing Windows and running Linux in VMware is the only _fun_ way to play real Games and have Linux at the same time. And everyone who says I'm a troll doesn't like Games or simple things. Dirk Please, don't think so. The point is simpler. Linux has its own standard, which is a Unix one, openGL on X11 and then SDL. There is a kernel component to get 3d acceleration with openGL, which is DRM. This standard is nice, and openGL is available also on windows, where doom3, quake4 and the like use it happily. There is no point to introduce something different and to change this standard. Luigi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel + gcc 4.1 = several problems
Just curious why on Opteron dual core 2600MHZ I get:
phoenix:{root}:/tmp> gcc -DCMOV -Wall -O2 t.c
phoenix:{root}:/tmp>time ./a.out
6
real0m0.117s
user0m0.120s
sys 0m0.000s
phoenix:{root}:/tmp>gcc -Wall -O2 t.c
phoenix:{root}:/tmp> time ./a.out
6
real0m0.136s
user0m0.130s
sys 0m0.010s
Regards
(I understand it is very different from P4)
Luigi Genoni
On Wed, 3 Jan 2007, Linus Torvalds wrote:
Date: Wed, 3 Jan 2007 08:03:37 -0800 (PST)
From: Linus Torvalds <[EMAIL PROTECTED]>
To: Grzegorz Kulewski <[EMAIL PROTECTED]>
Cc: Alan <[EMAIL PROTECTED]>, Mikael Pettersson <[EMAIL PROTECTED]>,
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org,
[EMAIL PROTECTED]
Subject: Re: kernel + gcc 4.1 = several problems
Resent-Date: Wed, 03 Jan 2007 17:16:00 +0100
Resent-From: <[EMAIL PROTECTED]>
On Wed, 3 Jan 2007, Grzegorz Kulewski wrote:
Could you explain why CMOV is pointless now? Are there any benchmarks proving
that?
CMOV (and, more generically, any "predicated instruction") tends to
generally a bad idea on an aggressively out-of-order CPU. It doesn't
always have to be horrible, but in practice it is seldom very nice, and
(as usual) on the P4 it can be really quite bad.
On a P4, I think a cmov basically takes 10 cycles.
But even ignoring the usual P4 "I suck at things that aren't totally
normal", cmov is actually not a great idea. You can always replace it by
j forward
mov ..., %reg
forward:
and assuming the branch is AT ALL predictable (and 95+% of all branches
are), the branch-over will actually be a LOT better for a CPU.
Why? Becuase branches can be predicted, and when they are predicted they
basically go away. They go away on many levels, too. Not just the branch
itself, but the _conditional_ for the branch goes away as far as the
critical path of code is concerned: the CPU still has to calculate it and
check it, but from a performance angle it "doesn't exist any more",
because it's not holding anything else up (well, you want to do it in
_some_ reasonable time, but the point stands..)
Similarly, whichever side of the branch wasn't taken goes away. Again, in
an out-of-order machine with register renaming, this means that even if
the branch isn't taken above, and you end up executing all the non-branch
instructions, because you now UNCONDITIONALLY over-write the register, the
old data in the register is now DEAD, so now all the OTHER writes to that
register are off the critical path too!
So the end result is that with a conditional branch, ona good CPU, the
_only_ part of the code that is actually performance-sensitive is the
actual calculation of the value that gets used!
In contrast, if you use a predicated instruction, ALL of it is on the
critical path. Calculating the conditional is on the critical path.
Calculating the value that gets used is obviously ALSO on the critical
path, but so is the calculation for the value that DOESN'T get used too.
So the cmov - rather than speeding things up - actually slows things down,
because it makes more code be dependent on each other.
So here's the basic rule:
- cmov is sometimes nice for code density. It's not a big win, but it
certainly can be a win.
- if you KNOW the branch is totally unpredictable, cmov is often good for
performance. But a compiler almost never knows that, and even if you
train it with input data and profiling, remember that not very many
branches _are_ totally unpredictable, so even if you were to know that
something is unpredictable, it's going to be very rare.
- on a P4, branch mispredictions are expensive, but so is cmov, so all
the above is to some degree exaggerated. On nicer microarchitectures
(the Intel Core 2 in particular is something I have to say is very nice
indeed), the difference will be a lot less noticeable. The loss from
cmov isn't very big (it's not as sucky as P4), but neither is the win
(branch misprediction isn't that expensive either).
Here's an example program that you can test and time yourself.
On my Core 2, I get
[EMAIL PROTECTED] ~]$ gcc -DCMOV -Wall -O2 t.c
[EMAIL PROTECTED] ~]$ time ./a.out
6
real0m0.194s
user0m0.192s
sys 0m0.000s
[EMAIL PROTECTED] ~]$ gcc -Wall -O2 t.c
[EMAIL PROTECTED] ~]$ time ./a.out
6
real0m0.167s
user0m0.168s
sys 0m0.000s
ie the cmov is quite a bit slower. Maybe I did something wrong. But note
how cmov not only is slower, it's fundamnetally more limited too (ie the
branch-over can actually do a lot of things cmov simply cannot do).
So don't use cmov. Except for non-performance-critical code, or if you
really care about code-size, and it helps (which is actually fairly rare:
quite often cmov isn't even smaller than a conditional jump and a regular
move,
Re: kernel + gcc 4.1 = several problems
Just to make clearer why I am so curious, this from X86_64 X2 3800+:
DarkStar:{venom}:/tmp> gcc -DCMOV -Wall -O2 t.c
DarkStar:{venom}:/tmp>time ./a.out
6
real0m0.151s
user0m0.150s
sys 0m0.000s
DarkStar:{venom}:/tmp> gcc -Wall -O2 t.c
DarkStar:{venom}:/tmp> time ./a.out
6
real0m0.176s
user0m0.180s
sys 0m0.000s
DarkStar:{venom}:/tmp>gcc -m32 -DCMOV -Wall -O2 t.c
DarkStar:{venom}:/tmp>time ./a.out
6
real0m0.152s
user0m0.160s
sys 0m0.000s
DarkStar:{venom}:/tmp>gcc -m32 -Wall -O2 t.c
DarkStar:{venom}:/tmp>time ./a.out
6
real0m0.200s
user0m0.200s
sys 0m0.000s
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel + gcc 4.1 = several problems
Just to make clearer why I am so curious, this from X86_64 X2 3800+:
DarkStar:{venom}:/tmp gcc -DCMOV -Wall -O2 t.c
DarkStar:{venom}:/tmptime ./a.out
6
real0m0.151s
user0m0.150s
sys 0m0.000s
DarkStar:{venom}:/tmp gcc -Wall -O2 t.c
DarkStar:{venom}:/tmp time ./a.out
6
real0m0.176s
user0m0.180s
sys 0m0.000s
DarkStar:{venom}:/tmpgcc -m32 -DCMOV -Wall -O2 t.c
DarkStar:{venom}:/tmptime ./a.out
6
real0m0.152s
user0m0.160s
sys 0m0.000s
DarkStar:{venom}:/tmpgcc -m32 -Wall -O2 t.c
DarkStar:{venom}:/tmptime ./a.out
6
real0m0.200s
user0m0.200s
sys 0m0.000s
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel + gcc 4.1 = several problems
Just curious why on Opteron dual core 2600MHZ I get:
phoenix:{root}:/tmp gcc -DCMOV -Wall -O2 t.c
phoenix:{root}:/tmptime ./a.out
6
real0m0.117s
user0m0.120s
sys 0m0.000s
phoenix:{root}:/tmpgcc -Wall -O2 t.c
phoenix:{root}:/tmp time ./a.out
6
real0m0.136s
user0m0.130s
sys 0m0.010s
Regards
(I understand it is very different from P4)
Luigi Genoni
On Wed, 3 Jan 2007, Linus Torvalds wrote:
Date: Wed, 3 Jan 2007 08:03:37 -0800 (PST)
From: Linus Torvalds [EMAIL PROTECTED]
To: Grzegorz Kulewski [EMAIL PROTECTED]
Cc: Alan [EMAIL PROTECTED], Mikael Pettersson [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org,
[EMAIL PROTECTED]
Subject: Re: kernel + gcc 4.1 = several problems
Resent-Date: Wed, 03 Jan 2007 17:16:00 +0100
Resent-From: [EMAIL PROTECTED]
On Wed, 3 Jan 2007, Grzegorz Kulewski wrote:
Could you explain why CMOV is pointless now? Are there any benchmarks proving
that?
CMOV (and, more generically, any predicated instruction) tends to
generally a bad idea on an aggressively out-of-order CPU. It doesn't
always have to be horrible, but in practice it is seldom very nice, and
(as usual) on the P4 it can be really quite bad.
On a P4, I think a cmov basically takes 10 cycles.
But even ignoring the usual P4 I suck at things that aren't totally
normal, cmov is actually not a great idea. You can always replace it by
jnegated condition forward
mov ..., %reg
forward:
and assuming the branch is AT ALL predictable (and 95+% of all branches
are), the branch-over will actually be a LOT better for a CPU.
Why? Becuase branches can be predicted, and when they are predicted they
basically go away. They go away on many levels, too. Not just the branch
itself, but the _conditional_ for the branch goes away as far as the
critical path of code is concerned: the CPU still has to calculate it and
check it, but from a performance angle it doesn't exist any more,
because it's not holding anything else up (well, you want to do it in
_some_ reasonable time, but the point stands..)
Similarly, whichever side of the branch wasn't taken goes away. Again, in
an out-of-order machine with register renaming, this means that even if
the branch isn't taken above, and you end up executing all the non-branch
instructions, because you now UNCONDITIONALLY over-write the register, the
old data in the register is now DEAD, so now all the OTHER writes to that
register are off the critical path too!
So the end result is that with a conditional branch, ona good CPU, the
_only_ part of the code that is actually performance-sensitive is the
actual calculation of the value that gets used!
In contrast, if you use a predicated instruction, ALL of it is on the
critical path. Calculating the conditional is on the critical path.
Calculating the value that gets used is obviously ALSO on the critical
path, but so is the calculation for the value that DOESN'T get used too.
So the cmov - rather than speeding things up - actually slows things down,
because it makes more code be dependent on each other.
So here's the basic rule:
- cmov is sometimes nice for code density. It's not a big win, but it
certainly can be a win.
- if you KNOW the branch is totally unpredictable, cmov is often good for
performance. But a compiler almost never knows that, and even if you
train it with input data and profiling, remember that not very many
branches _are_ totally unpredictable, so even if you were to know that
something is unpredictable, it's going to be very rare.
- on a P4, branch mispredictions are expensive, but so is cmov, so all
the above is to some degree exaggerated. On nicer microarchitectures
(the Intel Core 2 in particular is something I have to say is very nice
indeed), the difference will be a lot less noticeable. The loss from
cmov isn't very big (it's not as sucky as P4), but neither is the win
(branch misprediction isn't that expensive either).
Here's an example program that you can test and time yourself.
On my Core 2, I get
[EMAIL PROTECTED] ~]$ gcc -DCMOV -Wall -O2 t.c
[EMAIL PROTECTED] ~]$ time ./a.out
6
real0m0.194s
user0m0.192s
sys 0m0.000s
[EMAIL PROTECTED] ~]$ gcc -Wall -O2 t.c
[EMAIL PROTECTED] ~]$ time ./a.out
6
real0m0.167s
user0m0.168s
sys 0m0.000s
ie the cmov is quite a bit slower. Maybe I did something wrong. But note
how cmov not only is slower, it's fundamnetally more limited too (ie the
branch-over can actually do a lot of things cmov simply cannot do).
So don't use cmov. Except for non-performance-critical code, or if you
really care about code-size, and it helps (which is actually fairly rare:
quite often cmov isn't even smaller than a conditional jump and a regular
move,
