Re: 3Com NIC
Hello, On Thu, 10 Jan 2008 18:43:10 +0100 BERTRAND Joël <[EMAIL PROTECTED]> wrote: > ifconfig returns : > > eth2 Link encap:Ethernet HWaddr 00:04:75:df:1c:6d >inet adr:192.168.253.1 Bcast:192.168.253.255 > Masque:255.255.255.0 >UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >RX packets:1019611 errors:0 dropped:0 overruns:782 frame:0 >TX packets:1244862 errors:4389 dropped:0 overruns:0 carrier:0 >collisions:0 lg file transmission:1000 >RX bytes:93503 (106.0 MiB) TX bytes:1119932615 (1.0 GiB) >Interruption:17 Adresse de base:0x8000 > > and dmesg : > > NETDEV WATCHDOG: eth2: transmit timed out > eth2: transmit timed out, tx_status 00 status 8601. >diagnostics: net 0ccc media 8880 dma 003a fifo > eth2: Interrupt posted but not delivered -- IRQ blocked by another device? >Flags; bus-master 1, dirty 224(0) current 224(0) >Transmit list vs. f800a05ce200. >0: @f800a05ce200 length 807d status 0001007d >1: @f800a05ce260 length 804e status 0001004e >2: @f800a05ce2c0 length 804a status 0001004a >3: @f800a05ce320 length 8048 status 00010048 >4: @f800a05ce380 length 804a status 0001004a >5: @f800a05ce3e0 length 8042 status 00010042 >6: @f800a05ce440 length 804e status 0001004e >7: @f800a05ce4a0 length 8042 status 00010042 >8: @f800a05ce500 length 804e status 0001004e >9: @f800a05ce560 length 8048 status 00010048 >10: @f800a05ce5c0 length 804a status 0001004a >11: @f800a05ce620 length 804e status 0001004e >12: @f800a05ce680 length 8042 status 00010042 >13: @f800a05ce6e0 length 8042 status 00010042 >14: @f800a05ce740 length 8042 status 80010042 >15: @f800a05ce7a0 length 8052 status 80010052 > eth2: Resetting the Tx ring pointer. > > rayleigh:[~] > cat /proc/interrupts > CPU0 CPU2 >0: 561601936 561601824 timer >1: 0 0 sun4u PSYCHO_PCIERR >2: 0 0 sun4u PSYCHO_UE >3: 0 0 sun4u PSYCHO_CE >8: 461146 0 sun4u su(kbd) >9: 03350888 sun4u su(mouse) > 10: 0 0 sun4u parport0 > 11: 2 0 sun4u floppy > 12: 0 0 sun4u cs4231(capture) > 13: 360263 0 sun4u cs4231(play) > 14: 0 36484826 sun4u eth0 > 15: 0 27118288 sun4u sym53c8xx > 16: 30 0 sun4u sym53c8xx > 17: 9061771171078 sun4u eth2 > 18: 19345145 0 sun4u aic7xxx > 19: 1 584788 sun4u ohci_hcd:usb2 > 20: 0 0 sun4u ohci_hcd:usb3 > 21: 1467 sun4u ehci_hcd:usb1 > 22: 0 0 sun4u PSYCHO_PCIERR > 24: 27308743 0 sun4u eth1 > rayleigh:[~] > Is this only with eth2 ? It seems to be the only one to have interrupts delivered to CPU0 and CPU2... Just my $0.02 ;) Paul -- Paul RollandE-Mail : rol(at)witbe.net Witbe.net SATel. +33 (0)1 47 67 77 77 Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 F-92057 Paris La DefenseRIPE : PR12-RIPE Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur "Some people dream of success... while others wake up and work hard at it" "I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?'" --Mike Godwin, Electronic Frontier Foundation -- 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: 3Com NIC
Hello, On Thu, 10 Jan 2008 18:43:10 +0100 BERTRAND Joël [EMAIL PROTECTED] wrote: ifconfig returns : eth2 Link encap:Ethernet HWaddr 00:04:75:df:1c:6d inet adr:192.168.253.1 Bcast:192.168.253.255 Masque:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1019611 errors:0 dropped:0 overruns:782 frame:0 TX packets:1244862 errors:4389 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 RX bytes:93503 (106.0 MiB) TX bytes:1119932615 (1.0 GiB) Interruption:17 Adresse de base:0x8000 and dmesg : NETDEV WATCHDOG: eth2: transmit timed out eth2: transmit timed out, tx_status 00 status 8601. diagnostics: net 0ccc media 8880 dma 003a fifo eth2: Interrupt posted but not delivered -- IRQ blocked by another device? Flags; bus-master 1, dirty 224(0) current 224(0) Transmit list vs. f800a05ce200. 0: @f800a05ce200 length 807d status 0001007d 1: @f800a05ce260 length 804e status 0001004e 2: @f800a05ce2c0 length 804a status 0001004a 3: @f800a05ce320 length 8048 status 00010048 4: @f800a05ce380 length 804a status 0001004a 5: @f800a05ce3e0 length 8042 status 00010042 6: @f800a05ce440 length 804e status 0001004e 7: @f800a05ce4a0 length 8042 status 00010042 8: @f800a05ce500 length 804e status 0001004e 9: @f800a05ce560 length 8048 status 00010048 10: @f800a05ce5c0 length 804a status 0001004a 11: @f800a05ce620 length 804e status 0001004e 12: @f800a05ce680 length 8042 status 00010042 13: @f800a05ce6e0 length 8042 status 00010042 14: @f800a05ce740 length 8042 status 80010042 15: @f800a05ce7a0 length 8052 status 80010052 eth2: Resetting the Tx ring pointer. rayleigh:[~] cat /proc/interrupts CPU0 CPU2 0: 561601936 561601824 NULL timer 1: 0 0 sun4u PSYCHO_PCIERR 2: 0 0 sun4u PSYCHO_UE 3: 0 0 sun4u PSYCHO_CE 8: 461146 0 sun4u su(kbd) 9: 03350888 sun4u su(mouse) 10: 0 0 sun4u parport0 11: 2 0 sun4u floppy 12: 0 0 sun4u cs4231(capture) 13: 360263 0 sun4u cs4231(play) 14: 0 36484826 sun4u eth0 15: 0 27118288 sun4u sym53c8xx 16: 30 0 sun4u sym53c8xx 17: 9061771171078 sun4u eth2 18: 19345145 0 sun4u aic7xxx 19: 1 584788 sun4u ohci_hcd:usb2 20: 0 0 sun4u ohci_hcd:usb3 21: 1467 sun4u ehci_hcd:usb1 22: 0 0 sun4u PSYCHO_PCIERR 24: 27308743 0 sun4u eth1 rayleigh:[~] Is this only with eth2 ? It seems to be the only one to have interrupts delivered to CPU0 and CPU2... Just my $0.02 ;) Paul -- Paul RollandE-Mail : rol(at)witbe.net Witbe.net SATel. +33 (0)1 47 67 77 77 Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 F-92057 Paris La DefenseRIPE : PR12-RIPE Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur Some people dream of success... while others wake up and work hard at it I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?' --Mike Godwin, Electronic Frontier Foundation -- 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: Module for simulating network default
Hello, On Sun, 06 Jan 2008 23:42:07 -0800 (PST) David Miller <[EMAIL PROTECTED]> wrote: > From: Paul Rolland <[EMAIL PROTECTED]> > Date: Mon, 7 Jan 2008 08:37:04 +0100 > > > I remember reading some time ago about a network driver to "simulate" > > network default, for example packet loss... > > Unfortunately, I can't find the post, neither in my mailbox nor in > > archives... > > > > Does anyone has an URL that you could send me ? > > You want the "netem" packet scheduler, and you'll get better > answers to networking questions on the networking list > [EMAIL PROTECTED] Thanks David, I'll have a look at this. For netdev, as I'm not subscribed, please don't forget to copy me on reply ;) Regards, Paul -- 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/
Module for simulating network default
Hello, I remember reading some time ago about a network driver to "simulate" network default, for example packet loss... Unfortunately, I can't find the post, neither in my mailbox nor in archives... Does anyone has an URL that you could send me ? Regards, Paul -- 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/
Module for simulating network default
Hello, I remember reading some time ago about a network driver to simulate network default, for example packet loss... Unfortunately, I can't find the post, neither in my mailbox nor in archives... Does anyone has an URL that you could send me ? Regards, Paul -- 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: Module for simulating network default
Hello, On Sun, 06 Jan 2008 23:42:07 -0800 (PST) David Miller [EMAIL PROTECTED] wrote: From: Paul Rolland [EMAIL PROTECTED] Date: Mon, 7 Jan 2008 08:37:04 +0100 I remember reading some time ago about a network driver to simulate network default, for example packet loss... Unfortunately, I can't find the post, neither in my mailbox nor in archives... Does anyone has an URL that you could send me ? You want the netem packet scheduler, and you'll get better answers to networking questions on the networking list [EMAIL PROTECTED] Thanks David, I'll have a look at this. For netdev, as I'm not subscribed, please don't forget to copy me on reply ;) Regards, Paul -- 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] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
Hello, On Fri, 14 Dec 2007 23:29:55 + Alan Cox <[EMAIL PROTECTED]> wrote: > On Fri, 14 Dec 2007 14:13:46 -0800 > "H. Peter Anvin" <[EMAIL PROTECTED]> wrote: > > > Pavel Machek wrote: > > > On Fri 2007-12-14 10:02:57, H. Peter Anvin wrote: > > > > How long will that take to boot on a 386? > > Well the dumb approach to fix that would seem to be to initialise it to > > cpu->family 3 -> 50MHz 4 -> 300Mhz 5-> etc... Just an idea : from what I've read, the problem (port 80 hanging) only occurs on 'modern' machines... So why not : - use port 80 for old CPUs (PII, PIII) where it has never really been a problem, - use the cpu->family to do a best match for CPU freq thus we could avoid increasing boot time too much... Paul -- 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] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
Hello, On Fri, 14 Dec 2007 23:29:55 + Alan Cox [EMAIL PROTECTED] wrote: On Fri, 14 Dec 2007 14:13:46 -0800 H. Peter Anvin [EMAIL PROTECTED] wrote: Pavel Machek wrote: On Fri 2007-12-14 10:02:57, H. Peter Anvin wrote: How long will that take to boot on a 386? Well the dumb approach to fix that would seem to be to initialise it to cpu-family 3 - 50MHz 4 - 300Mhz 5- etc... Just an idea : from what I've read, the problem (port 80 hanging) only occurs on 'modern' machines... So why not : - use port 80 for old CPUs (PII, PIII) where it has never really been a problem, - use the cpu-family to do a best match for CPU freq thus we could avoid increasing boot time too much... Paul -- 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: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Hello, On Tue, 11 Dec 2007 16:28:56 +0100 Rene Herman <[EMAIL PROTECTED]> wrote: > On 11-12-07 15:15, Rene Herman wrote: > > > On 11-12-07 14:32, Paul Rolland wrote: > > > This might be a bit more constant, I suppose. This serialises with cpuid. > Don't see a difference locally, but perhaps you do. Well, yes, at least on the PIII and the Opteron... Core2 is still changing a lot... > On a Duron 1300 with an actual ISA bus, "out" is between 1300 and 1600 for > me and "in" between 1200 and 1500 with a few flukes above that which will I > suppose be caused by the bus (ISA _or_ PCI) being momentarily busy or some > such... The results : Core 2Duo 1.73 GHz : [EMAIL PROTECTED] tmp]# ./in2 out: 2777 in : 2519 [EMAIL PROTECTED] tmp]# ./in2 out: 2440 in : 2391 [EMAIL PROTECTED] tmp]# ./in2 out: 2460 in : 2388 Pentium III : [EMAIL PROTECTED] /tmp]# ./in2 out: 746 in : 747 [EMAIL PROTECTED] /tmp]# ./in2 out: 746 in : 747 [EMAIL PROTECTED] /tmp]# ./in2 out: 746 in : 745 AMD Opteron 150 : -bash-3.1# ./in2 out: 4846 in : 4845 -bash-3.1# ./in2 out: 4846 in : 4846 -bash-3.1# ./in2 out: 4846 in : 4845 Paul -- 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: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Hello, On Tue, 11 Dec 2007 14:16:01 +0100 Rene Herman <[EMAIL PROTECTED]> wrote: > On 11-12-07 13:08, David Newall wrote: > > > Rene Herman wrote: > (*) some local testing shows it to be almost exactly that for both out and > in on my own PC -- a little over. If anyone cares, see attached little test > program. The "little over" I don't worry about. 0 us delay is also fine for > me and if any code was _that_ fragile it would have broken long ago. Some results : Core 2Duo 1.73GHz : [EMAIL PROTECTED] tmp]# ./in out = 2366 in = 2496 [EMAIL PROTECTED] tmp]# ./in out = 3094 in = 2379 Plain old PIII 600 MHz: [EMAIL PROTECTED] /tmp]# ./in out = 314 in = 543 [EMAIL PROTECTED] /tmp]# ./in out = 319 in = 538 [EMAIL PROTECTED] /tmp]# ./in out = 319 in = 550 [EMAIL PROTECTED] /tmp]# ./in out = 329 in = 531 Opteron 150 2.4GHz : -bash-3.1# ./in out = 4801 in = 4863 -bash-3.1# ./in out = 5041 in = 4909 -bash-3.1# ./in out = 4829 in = 4886 Paul -- 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: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Hello, On Tue, 11 Dec 2007 14:16:01 +0100 Rene Herman [EMAIL PROTECTED] wrote: On 11-12-07 13:08, David Newall wrote: Rene Herman wrote: (*) some local testing shows it to be almost exactly that for both out and in on my own PC -- a little over. If anyone cares, see attached little test program. The little over I don't worry about. 0 us delay is also fine for me and if any code was _that_ fragile it would have broken long ago. Some results : Core 2Duo 1.73GHz : [EMAIL PROTECTED] tmp]# ./in out = 2366 in = 2496 [EMAIL PROTECTED] tmp]# ./in out = 3094 in = 2379 Plain old PIII 600 MHz: [EMAIL PROTECTED] /tmp]# ./in out = 314 in = 543 [EMAIL PROTECTED] /tmp]# ./in out = 319 in = 538 [EMAIL PROTECTED] /tmp]# ./in out = 319 in = 550 [EMAIL PROTECTED] /tmp]# ./in out = 329 in = 531 Opteron 150 2.4GHz : -bash-3.1# ./in out = 4801 in = 4863 -bash-3.1# ./in out = 5041 in = 4909 -bash-3.1# ./in out = 4829 in = 4886 Paul -- 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: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Hello, On Tue, 11 Dec 2007 16:28:56 +0100 Rene Herman [EMAIL PROTECTED] wrote: On 11-12-07 15:15, Rene Herman wrote: On 11-12-07 14:32, Paul Rolland wrote: This might be a bit more constant, I suppose. This serialises with cpuid. Don't see a difference locally, but perhaps you do. Well, yes, at least on the PIII and the Opteron... Core2 is still changing a lot... On a Duron 1300 with an actual ISA bus, out is between 1300 and 1600 for me and in between 1200 and 1500 with a few flukes above that which will I suppose be caused by the bus (ISA _or_ PCI) being momentarily busy or some such... The results : Core 2Duo 1.73 GHz : [EMAIL PROTECTED] tmp]# ./in2 out: 2777 in : 2519 [EMAIL PROTECTED] tmp]# ./in2 out: 2440 in : 2391 [EMAIL PROTECTED] tmp]# ./in2 out: 2460 in : 2388 Pentium III : [EMAIL PROTECTED] /tmp]# ./in2 out: 746 in : 747 [EMAIL PROTECTED] /tmp]# ./in2 out: 746 in : 747 [EMAIL PROTECTED] /tmp]# ./in2 out: 746 in : 745 AMD Opteron 150 : -bash-3.1# ./in2 out: 4846 in : 4845 -bash-3.1# ./in2 out: 4846 in : 4846 -bash-3.1# ./in2 out: 4846 in : 4845 Paul -- 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: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Hi, On Tue, 11 Dec 2007 12:12:59 +1030 David Newall <[EMAIL PROTECTED]> wrote: > H. Peter Anvin wrote: > > David Newall wrote: > > > > I think a single ISA bus transaction is 1 µs, so two of them back to > > back should be 2 µs, not 8 µs... > > Exactly. You think it's 2us, but the documentation doesn't say. The _p > functions are generic inasmuch as they provide an unspecified delay. Well, if the delay is so much unspecified, what about _reading_ port 0x80 ? Will the delay be shorter ? And if so, what about reading port 0x80 and writing the value back ? inb al,0x80 outb 0x80,al I've been wondering since the beginning of this thread if the problem is not just the value we put to port 0x80, not writing to the port... Just my 0.02 Eur... Paul -- Paul RollandE-Mail : rol(at)witbe.net Witbe.net SATel. +33 (0)1 47 67 77 77 Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 F-92057 Paris La DefenseRIPE : PR12-RIPE Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur "Some people dream of success... while others wake up and work hard at it" "I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?'" --Mike Godwin, Electronic Frontier Foundation -- 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: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Hi, On Tue, 11 Dec 2007 12:12:59 +1030 David Newall [EMAIL PROTECTED] wrote: H. Peter Anvin wrote: David Newall wrote: I think a single ISA bus transaction is 1 µs, so two of them back to back should be 2 µs, not 8 µs... Exactly. You think it's 2us, but the documentation doesn't say. The _p functions are generic inasmuch as they provide an unspecified delay. Well, if the delay is so much unspecified, what about _reading_ port 0x80 ? Will the delay be shorter ? And if so, what about reading port 0x80 and writing the value back ? inb al,0x80 outb 0x80,al I've been wondering since the beginning of this thread if the problem is not just the value we put to port 0x80, not writing to the port... Just my 0.02 Eur... Paul -- Paul RollandE-Mail : rol(at)witbe.net Witbe.net SATel. +33 (0)1 47 67 77 77 Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 F-92057 Paris La DefenseRIPE : PR12-RIPE Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur Some people dream of success... while others wake up and work hard at it I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?' --Mike Godwin, Electronic Frontier Foundation -- 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: constant_tsc and TSC unstable
Hello, On Thu, 29 Nov 2007 15:29:49 -0800 "Pallipadi, Venkatesh" <[EMAIL PROTECTED]> wrote: > TSCs on Core 2 Duo are supposed to be in sync unless CPU supports deep idle > states like C2, C3. Can you send the full /proc/cpuinfo and full dmesg. > Sure I can... [EMAIL PROTECTED] log]# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU T5300 @ 1.73GHz stepping: 2 cpu MHz : 800.000 cache size : 2048 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat ps e36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmo n pebs bts pni monitor ds_cpl est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 3461.13 clflush size: 64 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU T5300 @ 1.73GHz stepping: 2 cpu MHz : 800.000 cache size : 2048 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat ps e36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmo n pebs bts pni monitor ds_cpl est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 3458.02 clflush size: 64 Regards, Paul dmesg Description: Binary data
Re: constant_tsc and TSC unstable
Hello, On Thu, 29 Nov 2007 15:29:49 -0800 Pallipadi, Venkatesh [EMAIL PROTECTED] wrote: TSCs on Core 2 Duo are supposed to be in sync unless CPU supports deep idle states like C2, C3. Can you send the full /proc/cpuinfo and full dmesg. Sure I can... [EMAIL PROTECTED] log]# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU T5300 @ 1.73GHz stepping: 2 cpu MHz : 800.000 cache size : 2048 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat ps e36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmo n pebs bts pni monitor ds_cpl est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 3461.13 clflush size: 64 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU T5300 @ 1.73GHz stepping: 2 cpu MHz : 800.000 cache size : 2048 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat ps e36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmo n pebs bts pni monitor ds_cpl est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 3458.02 clflush size: 64 Regards, Paul dmesg Description: Binary data
Re: [2.6.22.5] irq X: nobody cared but X is successfully used by libata
Hello, On Fri, 19 Oct 2007 12:23:15 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote: > > On 26/08/07, Paul Rolland <[EMAIL PROTECTED]> wrote: > >> My machine (an ASUS P5W-DH-Deluxe, Core2, 4Go RAM, 3 SATA and 2IDE) is > >> reporting a : > >> irq 23: nobody cared (try booting with the "irqpoll" option) > >> together with a Call Trace, but : > >> - irqpoll is present on the command line, > >> - the irq is reported to be used by libata, > >> - the irqpoll option is mandatory if I want _some_ of my SATA disks to > >> be accessible. > >> > >> I've attached a file with : > >> - dmesg, > >> - cat /proc/interrupts > >> - lspci > >> - lspci -vvv > >> - my .config > >> > >> I've tried mounting and accessing all the disks, and it works. > >> The last weird thing : though reported as used by libata, the irq 23 > >> counter seems to be fixed at 21, though I've mounted and accessed > >> all the disks ! > > Does this still happen with 2.6.23? If so, please post boot log. Thanks. > Built and booted already twice, and so far, no problem anymore. I'll continue to watch this carefully, and will report any problem that could be related to this. Regards, Paul -- Paul RollandE-Mail : rol(at)witbe.net Witbe.net SATel. +33 (0)1 47 67 77 77 Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 F-92057 Paris La DefenseRIPE : PR12-RIPE Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur "Some people dream of success... while others wake up and work hard at it" "I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?'" --Mike Godwin, Electronic Frontier Foundation - 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: [2.6.22.5] irq X: nobody cared but X is successfully used by libata
Hello, On Fri, 19 Oct 2007 12:23:15 +0900 Tejun Heo [EMAIL PROTECTED] wrote: On 26/08/07, Paul Rolland [EMAIL PROTECTED] wrote: My machine (an ASUS P5W-DH-Deluxe, Core2, 4Go RAM, 3 SATA and 2IDE) is reporting a : irq 23: nobody cared (try booting with the irqpoll option) together with a Call Trace, but : - irqpoll is present on the command line, - the irq is reported to be used by libata, - the irqpoll option is mandatory if I want _some_ of my SATA disks to be accessible. I've attached a file with : - dmesg, - cat /proc/interrupts - lspci - lspci -vvv - my .config I've tried mounting and accessing all the disks, and it works. The last weird thing : though reported as used by libata, the irq 23 counter seems to be fixed at 21, though I've mounted and accessed all the disks ! Does this still happen with 2.6.23? If so, please post boot log. Thanks. Built and booted already twice, and so far, no problem anymore. I'll continue to watch this carefully, and will report any problem that could be related to this. Regards, Paul -- Paul RollandE-Mail : rol(at)witbe.net Witbe.net SATel. +33 (0)1 47 67 77 77 Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 F-92057 Paris La DefenseRIPE : PR12-RIPE Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur Some people dream of success... while others wake up and work hard at it I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?' --Mike Godwin, Electronic Frontier Foundation - 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: [2.6.22.5] irq X: nobody cared but X is successfully used by libata
Hi Tejun, On Fri, 19 Oct 2007 12:23:15 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote: > > On 26/08/07, Paul Rolland <[EMAIL PROTECTED]> wrote: > >> My machine (an ASUS P5W-DH-Deluxe, Core2, 4Go RAM, 3 SATA and 2IDE) is > >> reporting a : > >> irq 23: nobody cared (try booting with the "irqpoll" option) > >> together with a Call Trace, but : > >> - irqpoll is present on the command line, > >> - the irq is reported to be used by libata, > >> - the irqpoll option is mandatory if I want _some_ of my SATA disks to > >> be accessible. > > Does this still happen with 2.6.23? If so, please post boot log. Thanks. > Not tested yet, will do so during the WE. Regards, Paul - 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: [2.6.22.5] irq X: nobody cared but X is successfully used by libata
Hi Tejun, On Fri, 19 Oct 2007 12:23:15 +0900 Tejun Heo [EMAIL PROTECTED] wrote: On 26/08/07, Paul Rolland [EMAIL PROTECTED] wrote: My machine (an ASUS P5W-DH-Deluxe, Core2, 4Go RAM, 3 SATA and 2IDE) is reporting a : irq 23: nobody cared (try booting with the irqpoll option) together with a Call Trace, but : - irqpoll is present on the command line, - the irq is reported to be used by libata, - the irqpoll option is mandatory if I want _some_ of my SATA disks to be accessible. Does this still happen with 2.6.23? If so, please post boot log. Thanks. Not tested yet, will do so during the WE. Regards, Paul - 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: 2.6.23-rc7 - _random_ IRQ23 : nobody cared
Hi, On Fri, 28 Sep 2007 08:27:58 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > This is an Asus P5W-DH Deluxe motherboard, with a Core2 6400 CPU, > > a bunch of disk (2 IDE, 3 SATA, 1 CDRW and 1 DVDRW-DL), and a damned > > Olitec PCI V92 V2 modem. > > What chipset ? 965gm ? 975x Paul -- Paul RollandE-Mail : rol(at)witbe.net Witbe.net SATel. +33 (0)1 47 67 77 77 Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 F-92057 Paris La DefenseRIPE : PR12-RIPE Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur "Some people dream of success... while others wake up and work hard at it" "I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?'" --Mike Godwin, Electronic Frontier Foundation - 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: 2.6.23-rc7 - _random_ IRQ23 : nobody cared
Hi, On Fri, 28 Sep 2007 08:27:58 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: This is an Asus P5W-DH Deluxe motherboard, with a Core2 6400 CPU, a bunch of disk (2 IDE, 3 SATA, 1 CDRW and 1 DVDRW-DL), and a damned Olitec PCI V92 V2 modem. What chipset ? 965gm ? 975x Paul -- Paul RollandE-Mail : rol(at)witbe.net Witbe.net SATel. +33 (0)1 47 67 77 77 Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 F-92057 Paris La DefenseRIPE : PR12-RIPE Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur Some people dream of success... while others wake up and work hard at it I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?' --Mike Godwin, Electronic Frontier Foundation - 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: 2.6.23-rc7 - _random_ IRQ23 : nobody cared
Hello, On Thu, 27 Sep 2007 19:04:11 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > Let me guess... this is a T61 or X61 ? Bad luck ;) This is an Asus P5W-DH Deluxe motherboard, with a Core2 6400 CPU, a bunch of disk (2 IDE, 3 SATA, 1 CDRW and 1 DVDRW-DL), and a damned Olitec PCI V92 V2 modem. Paul - 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: 2.6.23-rc7 - _random_ IRQ23 : nobody cared
Hi Tejun,
On Thu, 27 Sep 2007 09:55:22 +0900
Tejun Heo <[EMAIL PROTECTED]> wrote:
> Paul Rolland wrote:
> > Hi David,
> >
> > On Mon, 24 Sep 2007 23:56:59 +0930
> > David Newall <[EMAIL PROTECTED]> wrote:
> >
> >> Paul Rolland "(???) wrote:
> >>> Hell, IRQ 23 is shared between libata and my modem !!!
> >>>
> >> Tried using the modem?
> >
> Can you change driver load order such that the driver for the modem is
> loaded first?
As I said, it's not possible, because :
- the modem driver is an out-kernel one, so I have to wait the end of the
boot process so that it can be loaded,
- libata on IRQ23 is the one taking care of my disks, and I suspect it
quite hard to install a modem driver before having the disk driver
installed.
I was thinking of delaying the disabling of the IRQ, which is basically the
other part of the problem (the first part being that spurious IRQ from the
modem). If it is possible to do that long enough for the modem driver to be
loaded, then the "IRQ xx : nobody cared" becomes an informational message
during the boot process, and then it vanishes, leaving a perfectly working
machine.
I suspect something in note_interrupt that would do (totally
untested, just thinking loudly) :
/* Allow some delay to complete boot process before
* killing an IRQ. This allow some modules to be
* loaded before we decide the IRQ will not be handled.
*/
if (jiffies > 120*HZ) {
/*
* Now kill the IRQ
*/
printk(KERN_EMERG "Disabling IRQ #%d\n", irq);
desc->status |= IRQ_DISABLED;
desc->depth = 1;
desc->chip->disable(irq);
}
I'll try that this week-end, but if someone has an opinion about it, I'll
be glad to know :)
Regards,
Paul
-
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: 2.6.23-rc7 - _random_ IRQ23 : nobody cared
Hi Tejun,
On Thu, 27 Sep 2007 09:55:22 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
Paul Rolland wrote:
Hi David,
On Mon, 24 Sep 2007 23:56:59 +0930
David Newall [EMAIL PROTECTED] wrote:
Paul Rolland (???) wrote:
Hell, IRQ 23 is shared between libata and my modem !!!
Tried using the modem?
Can you change driver load order such that the driver for the modem is
loaded first?
As I said, it's not possible, because :
- the modem driver is an out-kernel one, so I have to wait the end of the
boot process so that it can be loaded,
- libata on IRQ23 is the one taking care of my disks, and I suspect it
quite hard to install a modem driver before having the disk driver
installed.
I was thinking of delaying the disabling of the IRQ, which is basically the
other part of the problem (the first part being that spurious IRQ from the
modem). If it is possible to do that long enough for the modem driver to be
loaded, then the IRQ xx : nobody cared becomes an informational message
during the boot process, and then it vanishes, leaving a perfectly working
machine.
I suspect something in note_interrupt that would do (totally
untested, just thinking loudly) :
/* Allow some delay to complete boot process before
* killing an IRQ. This allow some modules to be
* loaded before we decide the IRQ will not be handled.
*/
if (jiffies 120*HZ) {
/*
* Now kill the IRQ
*/
printk(KERN_EMERG Disabling IRQ #%d\n, irq);
desc-status |= IRQ_DISABLED;
desc-depth = 1;
desc-chip-disable(irq);
}
I'll try that this week-end, but if someone has an opinion about it, I'll
be glad to know :)
Regards,
Paul
-
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: 2.6.23-rc7 - _random_ IRQ23 : nobody cared
Hello, On Thu, 27 Sep 2007 19:04:11 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: Let me guess... this is a T61 or X61 ? Bad luck ;) This is an Asus P5W-DH Deluxe motherboard, with a Core2 6400 CPU, a bunch of disk (2 IDE, 3 SATA, 1 CDRW and 1 DVDRW-DL), and a damned Olitec PCI V92 V2 modem. Paul - 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: 2.6.23-rc7 - _random_ IRQ23 : nobody cared
Hi David, On Mon, 24 Sep 2007 23:56:59 +0930 David Newall <[EMAIL PROTECTED]> wrote: > Paul Rolland "(???) wrote: > > Hell, IRQ 23 is shared between libata and my modem !!! > > > > Tried using the modem? When no problem is reported, both the libata part and the modem are OK. When the problem is reported, at that time, only libata is handling IRQ23 (the modem is a WinModem, and the driver is an out-kernel module), this is still kernel boot time, and the disabling of the IRQ makes my machine unable to complete the boot process (too many disk timeout). It could be good to be able to delay the disabling of an IRQ something long enough to allow all the modules to be loaded... Paul - 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: 2.6.23-rc7 - _random_ IRQ23 : nobody cared
Hi David, On Mon, 24 Sep 2007 23:56:59 +0930 David Newall [EMAIL PROTECTED] wrote: Paul Rolland (???) wrote: Hell, IRQ 23 is shared between libata and my modem !!! Tried using the modem? When no problem is reported, both the libata part and the modem are OK. When the problem is reported, at that time, only libata is handling IRQ23 (the modem is a WinModem, and the driver is an out-kernel module), this is still kernel boot time, and the disabling of the IRQ makes my machine unable to complete the boot process (too many disk timeout). It could be good to be able to delay the disabling of an IRQ something long enough to allow all the modules to be loaded... Paul - 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: 2.6.23-rc6 : crash with RTL8187 USB
Hello, > [PATCH] mac80211: fix initialisation when built-in > http://article.gmane.org/gmane.linux.kernel.wireless.general/5710/match=patch+mac80211+initialisation > > [PATCH] cfg80211: fix initialisation if built-in > http://article.gmane.org/gmane.linux.network/71326/match=patch+cfg80211+initialisation This is not present in 2.6.23-rc7 ! :((( Paul -- Paul RollandE-Mail : rol(at)witbe.net Witbe.net SATel. +33 (0)1 47 67 77 77 Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 F-92057 Paris La DefenseRIPE : PR12-RIPE Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur "Some people dream of success... while others wake up and work hard at it" Volley Theory: It is better to have lobbed and lost than never to have lobbed at all. - 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: 2.6.23-rc6 : crash with RTL8187 USB
Hello, [PATCH] mac80211: fix initialisation when built-in http://article.gmane.org/gmane.linux.kernel.wireless.general/5710/match=patch+mac80211+initialisation [PATCH] cfg80211: fix initialisation if built-in http://article.gmane.org/gmane.linux.network/71326/match=patch+cfg80211+initialisation This is not present in 2.6.23-rc7 ! :((( Paul -- Paul RollandE-Mail : rol(at)witbe.net Witbe.net SATel. +33 (0)1 47 67 77 77 Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 F-92057 Paris La DefenseRIPE : PR12-RIPE Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur Some people dream of success... while others wake up and work hard at it Volley Theory: It is better to have lobbed and lost than never to have lobbed at all. - 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: 2.6.23-rc6 : crash with RTL8187 USB
Hi Rob, On Sat, 15 Sep 2007 12:21:39 -0400 "Rob Hussey" <[EMAIL PROTECTED]> wrote: > On 9/15/07, ポール・ロラン Paul Rolland <[EMAIL PROTECTED]> wrote: > > Hello, > > > I had this problem as well. It has to do with mac80211, cfg80211 and > the rate control algorithm not initializing early enough in the boot > process. These two patches should fix it: > > [PATCH] mac80211: fix initialisation when built-in > http://article.gmane.org/gmane.linux.kernel.wireless.general/5710/match=patch+mac80211+initialisation > > [PATCH] cfg80211: fix initialisation if built-in > http://article.gmane.org/gmane.linux.network/71326/match=patch+cfg80211+initialisation Yes, they do ! Thanks very much, Regards, Paul -- Paul RollandE-Mail : rol(at)witbe.net Witbe.net SATel. +33 (0)1 47 67 77 77 Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 F-92057 Paris La DefenseRIPE : PR12-RIPE Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur "Some people dream of success... while others wake up and work hard at it" "I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?'" --Mike Godwin, Electronic Frontier Foundation - 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: rtl8187 driver in 2.6.23-rc6-git5: kernel panic if not used as a module. Works as a module.
Hi Eric, On Sat, 15 Sep 2007 16:27:30 +0200 Eric Valette <[EMAIL PROTECTED]> wrote: > Eric Valette wrote: > > > I can probably take a picture of the backtrace if you want. > > Just saw that just above my message in the LKML web interface, someone > posted a backtrace. Mine is different but at least, we are at least two > to have the crash. Well, I have it when compiling rtl8187 inside the kernel, but I still have to try it as a module, to confirm we are facing the same bug... Please allow me some time for that, I'll post an update. Regards, Paul -- Paul RollandE-Mail : rol(at)witbe.net Witbe.net SATel. +33 (0)1 47 67 77 77 Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 F-92057 Paris La DefenseRIPE : PR12-RIPE Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur "Some people dream of success... while others wake up and work hard at it" "I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?'" --Mike Godwin, Electronic Frontier Foundation - 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: sata & scsi suggestion for make menuconfig
Hello Stefan, On Sat, 15 Sep 2007 10:25:39 +0200 Stefan Richter <[EMAIL PROTECTED]> wrote: > Paul Rolland wrote: > > getting too much of "No help text available" > > usually results in people no more reading the help text. > > I assert that a Kconfig prompt (a visible Kconfig variable) _without_ > help text is a bug. Here is an example from 2.6.34-rc6 : .config - Linux Kernel v2.6.23-rc6 Configuration -- +- Provide RTC interrupt -+ | There is no help available for this kernel option. | | Symbol: HPET_EMULATE_RTC [=y] | | Prompt: Provide RTC interrupt | | Defined at arch/x86_64/Kconfig:471| | Depends on: HPET_TIMER && RTC=y | | Location: | | -> Processor type and features | Regards, Paul - 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: sata & scsi suggestion for make menuconfig
Hello, On Fri, 14 Sep 2007 17:15:22 +0200 Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Fri, Sep 14, 2007 at 04:54:07PM +0200, Stefan Richter wrote: > > Adrian Bunk wrote: > > > On Sun, Sep 09, 2007 at 05:11:44PM -0400, Jeff Garzik wrote: > > >> Let's step back a moment and consider the actual scale and impact of > > >> the problem at hand. > Do "make menuconfig" with the .config you are normally using, count the > number of options that are visible, and ask yourself whether we can > really expect users to read the help texts for every single option shown. > > People mostly read help texts for options where they don't understand > what this option is about - and "Serial ATA" therefore is an option that > is likely to get enabled without the user looking at the help text. > As a "make menuconfig" user, let me say that I agree. Of course, I'm used to rebuild kernel, but sometimes, some options are not clear, and the help text is searched for. But, getting too much of "No help text available" usually results in people no more reading the help text. What about splitting the screen to have the top half with the menu, and the bottom half with the help ? Paul -- Paul RollandE-Mail : rol(at)witbe.net Witbe.net SATel. +33 (0)1 47 67 77 77 Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 F-92057 Paris La DefenseRIPE : PR12-RIPE Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur "Some people dream of success... while others wake up and work hard at it" "I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?'" --Mike Godwin, Electronic Frontier Foundation - 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: sata scsi suggestion for make menuconfig
Hello, On Fri, 14 Sep 2007 17:15:22 +0200 Adrian Bunk [EMAIL PROTECTED] wrote: On Fri, Sep 14, 2007 at 04:54:07PM +0200, Stefan Richter wrote: Adrian Bunk wrote: On Sun, Sep 09, 2007 at 05:11:44PM -0400, Jeff Garzik wrote: Let's step back a moment and consider the actual scale and impact of the problem at hand. Do make menuconfig with the .config you are normally using, count the number of options that are visible, and ask yourself whether we can really expect users to read the help texts for every single option shown. People mostly read help texts for options where they don't understand what this option is about - and Serial ATA therefore is an option that is likely to get enabled without the user looking at the help text. As a make menuconfig user, let me say that I agree. Of course, I'm used to rebuild kernel, but sometimes, some options are not clear, and the help text is searched for. But, getting too much of No help text available usually results in people no more reading the help text. What about splitting the screen to have the top half with the menu, and the bottom half with the help ? Paul -- Paul RollandE-Mail : rol(at)witbe.net Witbe.net SATel. +33 (0)1 47 67 77 77 Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 F-92057 Paris La DefenseRIPE : PR12-RIPE Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur Some people dream of success... while others wake up and work hard at it I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?' --Mike Godwin, Electronic Frontier Foundation - 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: sata scsi suggestion for make menuconfig
Hello Stefan, On Sat, 15 Sep 2007 10:25:39 +0200 Stefan Richter [EMAIL PROTECTED] wrote: Paul Rolland wrote: getting too much of No help text available usually results in people no more reading the help text. I assert that a Kconfig prompt (a visible Kconfig variable) _without_ help text is a bug. Here is an example from 2.6.34-rc6 : .config - Linux Kernel v2.6.23-rc6 Configuration -- +- Provide RTC interrupt -+ | There is no help available for this kernel option. | | Symbol: HPET_EMULATE_RTC [=y] | | Prompt: Provide RTC interrupt | | Defined at arch/x86_64/Kconfig:471| | Depends on: HPET_TIMER RTC=y | | Location: | | - Processor type and features | Regards, Paul - 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: rtl8187 driver in 2.6.23-rc6-git5: kernel panic if not used as a module. Works as a module.
Hi Eric, On Sat, 15 Sep 2007 16:27:30 +0200 Eric Valette [EMAIL PROTECTED] wrote: Eric Valette wrote: I can probably take a picture of the backtrace if you want. Just saw that just above my message in the LKML web interface, someone posted a backtrace. Mine is different but at least, we are at least two to have the crash. Well, I have it when compiling rtl8187 inside the kernel, but I still have to try it as a module, to confirm we are facing the same bug... Please allow me some time for that, I'll post an update. Regards, Paul -- Paul RollandE-Mail : rol(at)witbe.net Witbe.net SATel. +33 (0)1 47 67 77 77 Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 F-92057 Paris La DefenseRIPE : PR12-RIPE Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur Some people dream of success... while others wake up and work hard at it I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?' --Mike Godwin, Electronic Frontier Foundation - 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: 2.6.23-rc6 : crash with RTL8187 USB
Hi Rob, On Sat, 15 Sep 2007 12:21:39 -0400 Rob Hussey [EMAIL PROTECTED] wrote: On 9/15/07, ポール・ロラン Paul Rolland [EMAIL PROTECTED] wrote: Hello, I had this problem as well. It has to do with mac80211, cfg80211 and the rate control algorithm not initializing early enough in the boot process. These two patches should fix it: [PATCH] mac80211: fix initialisation when built-in http://article.gmane.org/gmane.linux.kernel.wireless.general/5710/match=patch+mac80211+initialisation [PATCH] cfg80211: fix initialisation if built-in http://article.gmane.org/gmane.linux.network/71326/match=patch+cfg80211+initialisation Yes, they do ! Thanks very much, Regards, Paul -- Paul RollandE-Mail : rol(at)witbe.net Witbe.net SATel. +33 (0)1 47 67 77 77 Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 F-92057 Paris La DefenseRIPE : PR12-RIPE Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur Some people dream of success... while others wake up and work hard at it I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?' --Mike Godwin, Electronic Frontier Foundation - 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: [2.6.22.5] irq X: nobody cared but X is successfully used by libata
Hello Tejun, On Sat, 08 Sep 2007 16:23:20 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote: > Paul Rolland wrote: > > Hello, > > > > My machine (an ASUS P5W-DH-Deluxe, Core2, 4Go RAM, 3 SATA and 2IDE) is > > reporting a : > > irq 23: nobody cared (try booting with the "irqpoll" option) > > together with a Call Trace, but : > > - irqpoll is present on the command line, > > - the irq is reported to be used by libata, > > - the irqpoll option is mandatory if I want _some_ of my SATA disks to > > be accessible. > > So, if you don't add the 'irqpoll' option, IO to disks don't work at all > after nobody cared message, right? IO to disks don't work for SOME disks, but some others are still Ok (I've three SATA and two IDE). Also, what is weird is the content of dmesg : after the nobody care, it looks as if IRQ 23 is reuse for another device (SMBus), but /proc/interrupts still reports it being used by libata. I've been trying 2.6.23-rc5, and I'm still having this IRQ 23 nobody cared message. Regards, Paul -- Paul RollandE-Mail : rol(at)witbe.net Witbe.net SATel. +33 (0)1 47 67 77 77 Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 F-92057 Paris La DefenseRIPE : PR12-RIPE Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur "Some people dream of success... while others wake up and work hard at it" "I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?'" --Mike Godwin, Electronic Frontier Foundation - 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: [2.6.22.5] irq X: nobody cared but X is successfully used by libata
Hello Tejun, On Sat, 08 Sep 2007 16:23:20 +0900 Tejun Heo [EMAIL PROTECTED] wrote: Paul Rolland wrote: Hello, My machine (an ASUS P5W-DH-Deluxe, Core2, 4Go RAM, 3 SATA and 2IDE) is reporting a : irq 23: nobody cared (try booting with the irqpoll option) together with a Call Trace, but : - irqpoll is present on the command line, - the irq is reported to be used by libata, - the irqpoll option is mandatory if I want _some_ of my SATA disks to be accessible. So, if you don't add the 'irqpoll' option, IO to disks don't work at all after nobody cared message, right? IO to disks don't work for SOME disks, but some others are still Ok (I've three SATA and two IDE). Also, what is weird is the content of dmesg : after the nobody care, it looks as if IRQ 23 is reuse for another device (SMBus), but /proc/interrupts still reports it being used by libata. I've been trying 2.6.23-rc5, and I'm still having this IRQ 23 nobody cared message. Regards, Paul -- Paul RollandE-Mail : rol(at)witbe.net Witbe.net SATel. +33 (0)1 47 67 77 77 Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 F-92057 Paris La DefenseRIPE : PR12-RIPE Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur Some people dream of success... while others wake up and work hard at it I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?' --Mike Godwin, Electronic Frontier Foundation - 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: 2.6.23-rc3-mm1
Hello, On Sat, 25 Aug 2007 00:28:09 -0400 Dave Jones <[EMAIL PROTECTED]> wrote: > On Fri, Aug 24, 2007 at 08:30:00PM -0700, Andrew Morton wrote: > > > > <6>Linux agpgart interface v0.102 > > > +<6>rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0 > > > +<4>rtc_cmos: probe of 00:03 failed with error -16 > > > +<6>agpgart: suspend/resume problematic: resume with 3D/DRI active > > > may lockup X.Org +<4>on some chipset/BIOS combos (see DEBUG_AGP_PM > > > in intel-agp.c) <6>agpgart: Detected an Intel 965Q Chipset. > > > <6>agpgart: Unknown page table size, assuming 512KB > > > <6>agpgart: Detected 7676K stolen memory. > > > <6>agpgart: AGP aperture is 256M @ 0x4000 > > > -<6>rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0 > > > -<4>rtc_cmos: probe of 00:03 failed with error -16 > > > > I wonder if that was supposed to happen. It's also happening in > > 2.6.23-rc3 base. > > EBUSY. I've seen this happen when you have both CONFIG_RTC and > CONFIG_RTC_DRV_CMOS set. This one is becoming quite worth an entry in a FAQ, it pops up one every month ;) There was a discussion about preventing both being set at the same time when configuring, but I don't remember how it ends... Paul - 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: 2.6.23-rc3-mm1
Hello, On Sat, 25 Aug 2007 00:28:09 -0400 Dave Jones [EMAIL PROTECTED] wrote: On Fri, Aug 24, 2007 at 08:30:00PM -0700, Andrew Morton wrote: 6Linux agpgart interface v0.102 +6rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0 +4rtc_cmos: probe of 00:03 failed with error -16 +6agpgart: suspend/resume problematic: resume with 3D/DRI active may lockup X.Org +4on some chipset/BIOS combos (see DEBUG_AGP_PM in intel-agp.c) 6agpgart: Detected an Intel 965Q Chipset. 6agpgart: Unknown page table size, assuming 512KB 6agpgart: Detected 7676K stolen memory. 6agpgart: AGP aperture is 256M @ 0x4000 -6rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0 -4rtc_cmos: probe of 00:03 failed with error -16 I wonder if that was supposed to happen. It's also happening in 2.6.23-rc3 base. EBUSY. I've seen this happen when you have both CONFIG_RTC and CONFIG_RTC_DRV_CMOS set. This one is becoming quite worth an entry in a FAQ, it pops up one every month ;) There was a discussion about preventing both being set at the same time when configuring, but I don't remember how it ends... Paul - 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/
Strange problem with Device Mapper
Hello, I've a machine that has been installed with Intel Soft Raid on top of 2 SATA disks. I'm trying to have this work as a RAID-1 array. Bios configuration has been done, using 128K chunk, and the kernel (2.6.20.7) sees perfectly /dev/mapper/isw__RAID1 But, I'm facing two problems : 1 - If i try to create partitions on this device, it does fail (the values are not interpreted correctly) 2 - To avoid 1), I stop the RAID array (dmraid -an), then I do create exactly the same partition set on /dev/sda, and /dev/sdb, and then I reactivate RAID (dmraid -ay). This allows me to see all the /dev/mapper/isw_xxx_RAID1p1, p2, ... But, running fsck -t ext2 /dev/mapper/isw_xxx_RAID1p1 ends in a lock when the partition is larger than 10Go (well, it is Ok on the 10Go one, and it locks on the 100Go). Not a real hardlock, I still can switch to a new VC, but it's not more possible to start a new command or to stop fsck. Should I do everything on the physical disks before activating RAID ? Is it a normal behavior ? BTW, I also noticed that such a device doesn't support BLKRRPART ioctl... So it is possible that what I'm doing is wrong... Any idea ? Regards, Paul - 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/
Strange problem with Device Mapper
Hello, I've a machine that has been installed with Intel Soft Raid on top of 2 SATA disks. I'm trying to have this work as a RAID-1 array. Bios configuration has been done, using 128K chunk, and the kernel (2.6.20.7) sees perfectly /dev/mapper/isw__RAID1 But, I'm facing two problems : 1 - If i try to create partitions on this device, it does fail (the values are not interpreted correctly) 2 - To avoid 1), I stop the RAID array (dmraid -an), then I do create exactly the same partition set on /dev/sda, and /dev/sdb, and then I reactivate RAID (dmraid -ay). This allows me to see all the /dev/mapper/isw_xxx_RAID1p1, p2, ... But, running fsck -t ext2 /dev/mapper/isw_xxx_RAID1p1 ends in a lock when the partition is larger than 10Go (well, it is Ok on the 10Go one, and it locks on the 100Go). Not a real hardlock, I still can switch to a new VC, but it's not more possible to start a new command or to stop fsck. Should I do everything on the physical disks before activating RAID ? Is it a normal behavior ? BTW, I also noticed that such a device doesn't support BLKRRPART ioctl... So it is possible that what I'm doing is wrong... Any idea ? Regards, Paul - 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: Why is /dev on a different filesystem ? [Kernel 2.6.20.3]
> Might want to 'cat /proc/mounts', and ponder the fact that a > filesystem > can be mounted and not listed in /etc/mtab, and then see if > your system > has 'udev' installed and enabled. Damn ! You're right : cat /proc/mounts | grep dev none /dev tmpfs rw 0 0 and no, I don't have any udev running, still can't stand it ;) Thx for the pointer, I was too much trusting df :( Regards, Paul - 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/
Why is /dev on a different filesystem ? [Kernel 2.6.20.3]
Hello,
I was trying to backup a machine using tar and the --one-file-system option
and I was getting an archive without /dev, but tar was spitting :
/dev: file is on a different filesystem; not dumped
So, I had a look at the code in tar, and the comparison is done on the
stat.st_dev field...
I then wrote a simple program to stat("/", ...) and stat("/dev", ...),
and got :
For / :
st_dev : 769
st_ino : 2
st_mode : 16877
st_nlink : 23
st_uid : 0
st_gid : 0
st_rdev : 0
st_size : 4096
For /dev :
st_dev : 15
st_ino : 1117
st_mode : 16877
st_nlink : 23
st_uid : 0
st_gid : 0
st_rdev : 0
st_size : 165580
So, obviously, tar is right...
man 2 stat says :
The st_dev field describes the device on which this file resides.
and df -a reports :
[EMAIL PROTECTED] src]# df -a
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda1 7936256 3105556 4421048 42% /
proc 0 0 0 - /proc
sysfs0 0 0 - /sys
devpts 0 0 0 - /dev/pts
tmpfs 517632 0517632 0% /dev/shm
/dev/hda5 61787140237360 58360480 1% /usr/local/witbe
/dev/hda2 4956316142292 4558192 4% /var/log
none 0 0 0 -
/proc/sys/fs/binfmt_misc
So, obviously, /dev is on /, but the stat(2) says no.
Who is right, and where is the bug ?
Kernel 2.4 had it right : /dev was on /, no doubt.
Regards,
Paul
-
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/
Why is /dev on a different filesystem ? [Kernel 2.6.20.3]
Hello, I was trying to backup a machine using tar and the --one-file-system option and I was getting an archive without /dev, but tar was spitting : /dev: file is on a different filesystem; not dumped So, I had a look at the code in tar, and the comparison is done on the stat.st_dev field... I then wrote a simple program to stat(/, ...) and stat(/dev, ...), and got : For / : st_dev : 769 st_ino : 2 st_mode : 16877 st_nlink : 23 st_uid : 0 st_gid : 0 st_rdev : 0 st_size : 4096 For /dev : st_dev : 15 st_ino : 1117 st_mode : 16877 st_nlink : 23 st_uid : 0 st_gid : 0 st_rdev : 0 st_size : 165580 So, obviously, tar is right... man 2 stat says : The st_dev field describes the device on which this file resides. and df -a reports : [EMAIL PROTECTED] src]# df -a Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda1 7936256 3105556 4421048 42% / proc 0 0 0 - /proc sysfs0 0 0 - /sys devpts 0 0 0 - /dev/pts tmpfs 517632 0517632 0% /dev/shm /dev/hda5 61787140237360 58360480 1% /usr/local/witbe /dev/hda2 4956316142292 4558192 4% /var/log none 0 0 0 - /proc/sys/fs/binfmt_misc So, obviously, /dev is on /, but the stat(2) says no. Who is right, and where is the bug ? Kernel 2.4 had it right : /dev was on /, no doubt. Regards, Paul - 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: Why is /dev on a different filesystem ? [Kernel 2.6.20.3]
Might want to 'cat /proc/mounts', and ponder the fact that a filesystem can be mounted and not listed in /etc/mtab, and then see if your system has 'udev' installed and enabled. Damn ! You're right : cat /proc/mounts | grep dev none /dev tmpfs rw 0 0 and no, I don't have any udev running, still can't stand it ;) Thx for the pointer, I was too much trusting df :( Regards, Paul - 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: [git patches] libata fixes
> Oh... that's just weird. It seems you'll have to continue > boot with the > timeouts for the time being. Sorry about that. Would you agree to a patch to add a kernel boot parameter to skip some ata ports ? I found some archives refering to some "ataX=noprobe", but it seems to have no effect, and I'd like to resurrect it for libata, at least to help me support my configuration ? If no, I'll just cook it for me, without posting it... Regards, Paul - 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: [git patches] libata fixes
Oh... that's just weird. It seems you'll have to continue boot with the timeouts for the time being. Sorry about that. Would you agree to a patch to add a kernel boot parameter to skip some ata ports ? I found some archives refering to some ataX=noprobe, but it seems to have no effect, and I'd like to resurrect it for libata, at least to help me support my configuration ? If no, I'll just cook it for me, without posting it... Regards, Paul - 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: [git patches] libata fixes
Doh ! Got that : ACPI: PCI Interrupt :00:1f.2[B] -> GSI 23 (level, low) -> IRQ 23 ahci :00:1f.2: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode ahci :00:1f.2: flags: 64bit ncq led clo pio slum part ata1: SATA max UDMA/133 cmd 0xc208e900 ctl 0x bmdma 0x irq 504 ata2: SATA max UDMA/133 cmd 0xc208e980 ctl 0x bmdma 0x irq 504 ata3: SATA max UDMA/133 cmd 0xc208ea00 ctl 0x bmdma 0x irq 504 ata4: SATA max UDMA/133 cmd 0xc208ea80 ctl 0x bmdma 0x irq 504 scsi0 : ahci ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133 ata1.00: 490234752 sectors, multi 0: LBA48 NCQ (not used) ata1.00: configured for UDMA/133 scsi1 : ahci ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata2.00: ATA-6: External Disk 0, RGL10364, max UDMA/133 ata2.00: 1 sectors, multi 1: LBA48 ata2.00: configured for UDMA/133 scsi2 : ahci ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata3.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133 ata3.00: 490234752 sectors, multi 0: LBA48 NCQ (not used) ata3.00: configured for UDMA/133 scsi3 : ahci ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata4.00: ATA-7: ST3500641AS, 3.AAB, max UDMA/133 ata4.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 31/32) ata4.00: configured for UDMA/133 scsi 0:0:0:0: Direct-Access ATA Maxtor 6L250S0 BANC PQ: 0 ANSI: 5 SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB) sda: Write Protect is off SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB) sda: Write Protect is off SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sd 0:0:0:0: Attached scsi disk sda sd 0:0:0:0: Attached scsi generic sg0 type 0 scsi 1:0:0:0: Direct-Access ATA External Disk 0 RGL1 PQ: 0 ANSI: 5 SCSI device sdb: 1 512-byte hdwr sectors (0 MB) sdb: Write Protect is off SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdb: 1 512-byte hdwr sectors (0 MB) sdb: Write Protect is off SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb:<3>irq 504: nobody cared (try booting with the "irqpoll" option) Call Trace: [] __report_bad_irq+0x35/0x90 [] note_interrupt+0x21a/0x270 [] handle_edge_irq+0x10f/0x150 [] do_IRQ+0x7b/0xf0 [] mwait_idle+0x0/0x50 [] ret_from_intr+0x0/0xa [] vgacon_cursor+0x0/0x1d0 [] mwait_idle+0x46/0x50 [] cpu_idle+0x5c/0xa0 [] start_kernel+0x2aa/0x2c0 [] _sinittext+0x176/0x180 handlers: [] (ahci_interrupt+0x0/0x590) Disabling IRQ #504 unknown partition table sd 1:0:0:0: Attached scsi disk sdb sd 1:0:0:0: Attached scsi generic sg1 type 0 scsi 2:0:0:0: Direct-Access ATA Maxtor 6L250S0 BANC PQ: 0 ANSI: 5 SCSI device sdc: 490234752 512-byte hdwr sectors (251000 MB) sdc: Write Protect is off and though it said : sdb:<3>irq 504: nobody cared (try booting with the "irqpoll" option) I _am_ booting with the irqpoll option ! Paul - 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: [git patches] libata fixes
Hi, > This is NCQ protocol violation on the drive's side shown on some early > drives. No need to worry too much about it. The drive will just get > blacklisted for NCQ and should work fine. > Thx. Also, remember one of the problem I have, with ata2 going to timeout because this port of the ICH7 is connected to a PMT ? You suggested me to connect a disk to one of the SATA port of the PMT, and reboot the machine to see if the timeout would vanish... I've just done it, and here is the relevant part of the boot log : ACPI: PCI Interrupt :00:1f.2[B] -> GSI 23 (level, low) -> IRQ 23 ahci :00:1f.2: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode ahci :00:1f.2: flags: 64bit ncq led clo pio slum part ata1: SATA max UDMA/133 cmd 0xc208e900 ctl 0x bmdma 0x irq 504 ata2: SATA max UDMA/133 cmd 0xc208e980 ctl 0x bmdma 0x irq 504 ata3: SATA max UDMA/133 cmd 0xc208ea00 ctl 0x bmdma 0x irq 504 ata4: SATA max UDMA/133 cmd 0xc208ea80 ctl 0x bmdma 0x irq 504 scsi0 : ahci ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133 ata1.00: 490234752 sectors, multi 0: LBA48 NCQ (not used) ata1.00: configured for UDMA/133 scsi1 : ahci ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata2.00: ATA-6: External Disk 0, RGL10364, max UDMA/133 ata2.00: 1 sectors, multi 1: LBA48 ata2.00: configured for UDMA/133 scsi2 : ahci ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata3.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133 ata3.00: 490234752 sectors, multi 0: LBA48 NCQ (not used) ata3.00: configured for UDMA/133 scsi3 : ahci ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata4.00: ATA-7: ST3500641AS, 3.AAB, max UDMA/133 ata4.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 31/32) ata4.00: configured for UDMA/133 scsi 0:0:0:0: Direct-Access ATA Maxtor 6L250S0 BANC PQ: 0 ANSI: 5 SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB) sda: Write Protect is off SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB) sda: Write Protect is off SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sd 0:0:0:0: Attached scsi disk sda sd 0:0:0:0: Attached scsi generic sg0 type 0 scsi 1:0:0:0: Direct-Access ATA External Disk 0 RGL1 PQ: 0 ANSI: 5 SCSI device sdb: 1 512-byte hdwr sectors (0 MB) sdb: Write Protect is off SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdb: 1 512-byte hdwr sectors (0 MB) sdb: Write Protect is off SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb: unknown partition table sd 1:0:0:0: Attached scsi disk sdb sd 1:0:0:0: Attached scsi generic sg1 type 0 scsi 2:0:0:0: Direct-Access ATA Maxtor 6L250S0 BANC PQ: 0 ANSI: 5 SCSI device sdc: 490234752 512-byte hdwr sectors (251000 MB) sdc: Write Protect is off SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdc: 490234752 512-byte hdwr sectors (251000 MB) sdc: Write Protect is off SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdc: sdc1 sdc2 sd 2:0:0:0: Attached scsi disk sdc sd 2:0:0:0: Attached scsi generic sg2 type 0 scsi 3:0:0:0: Direct-Access ATA ST3500641AS 3.AA PQ: 0 ANSI: 5 SCSI device sdd: 976773168 512-byte hdwr sectors (500108 MB) sdd: Write Protect is off SCSI device sdd: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdd: 976773168 512-byte hdwr sectors (500108 MB) sdd: Write Protect is off SCSI device sdd: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdd: sdd1 sdd2 sdd3 sd 3:0:0:0: Attached scsi disk sdd sd 3:0:0:0: Attached scsi generic sg3 type 0 ACPI: PCI Interrupt :02:00.0[A] -> GSI 17 (level, low) -> IRQ 17 ahci :02:00.0: AHCI 0001. 32 slots 2 ports 3 Gbps 0x3 impl SATA mode ahci :02:00.0: flags: 64bit ncq pm led clo pmp pio slum part ... The good news is that there is no more timeout, which is excellent ! The bad news is that the disk is not detected... but maybe I should do something in the BIOS configuration. I'll try to have a look at this, because connecting a disk to avoid TO without being able to use it is not that good ;) Regards, Paul - 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: [git patches] libata fixes
Hello, > Yeap, more than three HSM violations in ten minutes. That's the > criteria for turning off NCQ. Good to see it working. It look like a > lot because libata reports all active commands (can't help as on HSM > failure, there's no way to determine which caused it) and the SCSI > prints revalidation messages, but it's still only three errors. > > Thanks for verifying that. I wanted to verify it works in > the field as expected. Glad to help ! Anyhow, how should I consider these "errors" ? Are they real failure that can affect data integrity on the disk, or some kind of "protocol" errors with the disk, that are covered by soft (retry or so), and don't affect data ? Regards, Paul - 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: [git patches] libata fixes
Hello, > Can you put the harddisk under high load and see what happens? How > often do those errors occur? Care to post full dmesg? I started again a stock 2.6.21-rc4, and ran that : while (/bin/true); do tar jxf linux-2.6.19.1.tar.bz2; rm -rf linux-2.6.19.1; echo -n "."; done After several minutes (I waited more than 300 loops to be completed), and a lot of errors, I finally managed to see : Mar 18 10:32:47 riri kernel: ata1.00: NCQ disabled due to excessive errors /var/log/messages contains : Mar 18 10:15:04 riri syslogd 1.4.1#17ubuntu7: restart. Mar 18 10:15:04 riri kernel: Inspecting /boot/System.map-2.6.21-rc4 Mar 18 10:15:04 riri kernel: Loaded 39327 symbols from /boot/System.map-2.6.21-rc4. Mar 18 10:15:04 riri kernel: Symbols match kernel version 2.6.21. Mar 18 10:15:04 riri kernel: No module symbols loaded - kernel modules not enabled. Mar 18 10:15:04 riri kernel: Linux version 2.6.21-rc4 ([EMAIL PROTECTED]) (gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)) #1 SMP PREEMPT Sat Mar 17 18:50:10 CET 2007 Mar 18 10:15:04 riri kernel: Command line: root=/dev/sde1 ro ata2=noprobe console=ttyS0,9600 console=tty0 vga=extended irqpoll Mar 18 10:15:04 riri kernel: BIOS-provided physical RAM map: Mar 18 10:15:04 riri kernel: BIOS-e820: - 0009fc00 (usable) Mar 18 10:15:04 riri kernel: BIOS-e820: 0009fc00 - 000a (reserved) Mar 18 10:15:04 riri kernel: BIOS-e820: 000e4000 - 0010 (reserved) Mar 18 10:15:04 riri kernel: BIOS-e820: 0010 - c7f8 (usable) Mar 18 10:15:04 riri kernel: BIOS-e820: c7f8 - c7f8e000 (ACPI data) Mar 18 10:15:04 riri kernel: BIOS-e820: c7f8e000 - c7fe (ACPI NVS) Mar 18 10:15:04 riri kernel: BIOS-e820: c7fe - c800 (reserved) Mar 18 10:15:04 riri kernel: BIOS-e820: ffb0 - 0001 (reserved) Mar 18 10:15:04 riri kernel: end_pfn_map = 1048576 Mar 18 10:15:04 riri kernel: DMI 2.4 present. Mar 18 10:15:04 riri kernel: ACPI: RSDP 000FAF20, 0024 (r2 ACPIAM) Mar 18 10:15:04 riri kernel: ACPI: XSDT C7F80100, 005C (r1 A_M_I_ OEMXSDT 12000608 MSFT 97) Mar 18 10:15:04 riri kernel: ACPI: FACP C7F80290, 00F4 (r3 A_M_I_ OEMFACP 12000608 MSFT 97) Mar 18 10:15:04 riri kernel: ACPI: DSDT C7F80410, 8FC4 (r1 A0543 A0543000 0 INTL 20060113) Mar 18 10:15:04 riri kernel: ACPI: FACS C7F8E000, 0040 Mar 18 10:15:04 riri kernel: ACPI: APIC C7F80390, 0080 (r1 A_M_I_ OEMAPIC 12000608 MSFT 97) Mar 18 10:15:04 riri kernel: ACPI: OEMB C7F8E040, 0066 (r1 A_M_I_ AMI_OEM 12000608 MSFT 97) Mar 18 10:15:04 riri kernel: ACPI: HPET C7F893E0, 0038 (r1 A_M_I_ OEMHPET 12000608 MSFT 97) Mar 18 10:15:04 riri kernel: ACPI: MCFG C7F89420, 003C (r1 A_M_I_ OEMMCFG 12000608 MSFT 97) Mar 18 10:15:04 riri kernel: ACPI: SSDT C7F8E0B0, 01C6 (r1AMI CPU1PM 1 INTL 20060113) Mar 18 10:15:04 riri kernel: ACPI: SSDT C7F8E280, 013A (r1AMI CPU2PM 1 INTL 20060113) Mar 18 10:15:04 riri kernel: Zone PFN ranges: Mar 18 10:15:04 riri kernel: DMA 0 -> 4096 Mar 18 10:15:04 riri kernel: DMA324096 -> 1048576 Mar 18 10:15:04 riri kernel: Normal1048576 -> 1048576 Mar 18 10:15:04 riri kernel: early_node_map[2] active PFN ranges Mar 18 10:15:04 riri kernel: 0:0 -> 159 Mar 18 10:15:04 riri kernel: 0: 256 -> 819072 Mar 18 10:15:04 riri kernel: ACPI: PM-Timer IO Port: 0x808 Mar 18 10:15:04 riri kernel: ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Mar 18 10:15:04 riri kernel: Processor #0 (Bootup-CPU) Mar 18 10:15:04 riri kernel: ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Mar 18 10:15:04 riri kernel: Processor #1 Mar 18 10:15:04 riri kernel: ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled) Mar 18 10:15:04 riri kernel: ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled) Mar 18 10:15:04 riri kernel: ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) Mar 18 10:15:04 riri kernel: IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 Mar 18 10:15:04 riri kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) Mar 18 10:15:04 riri kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Mar 18 10:15:04 riri kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) Mar 18 10:15:04 riri kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Mar 18 10:15:04 riri kernel: Setting APIC routing to flat Mar 18 10:15:04 riri kernel: ACPI: HPET id: 0x8086a201 base: 0xfed0 Mar 18 10:15:04 riri kernel: Using ACPI (MADT) for SMP configuration information Mar 18 10:15:04 riri kernel: Nosave address range: 0009f000 - 000a Mar 18 10:15:04 riri kernel: Nosave address range: 000a - 000e4000 Mar 18 10:15:04 riri kernel: Nosave address range: 000e4000 - 0010 Mar 18 10:15:04 riri kernel: Allocating PCI resources starting at cc00 (gap: c800:37b0) Mar 18 10:15:04 riri
RE: [git patches] libata fixes
Hello, Can you put the harddisk under high load and see what happens? How often do those errors occur? Care to post full dmesg? I started again a stock 2.6.21-rc4, and ran that : while (/bin/true); do tar jxf linux-2.6.19.1.tar.bz2; rm -rf linux-2.6.19.1; echo -n .; done After several minutes (I waited more than 300 loops to be completed), and a lot of errors, I finally managed to see : Mar 18 10:32:47 riri kernel: ata1.00: NCQ disabled due to excessive errors /var/log/messages contains : Mar 18 10:15:04 riri syslogd 1.4.1#17ubuntu7: restart. Mar 18 10:15:04 riri kernel: Inspecting /boot/System.map-2.6.21-rc4 Mar 18 10:15:04 riri kernel: Loaded 39327 symbols from /boot/System.map-2.6.21-rc4. Mar 18 10:15:04 riri kernel: Symbols match kernel version 2.6.21. Mar 18 10:15:04 riri kernel: No module symbols loaded - kernel modules not enabled. Mar 18 10:15:04 riri kernel: Linux version 2.6.21-rc4 ([EMAIL PROTECTED]) (gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)) #1 SMP PREEMPT Sat Mar 17 18:50:10 CET 2007 Mar 18 10:15:04 riri kernel: Command line: root=/dev/sde1 ro ata2=noprobe console=ttyS0,9600 console=tty0 vga=extended irqpoll Mar 18 10:15:04 riri kernel: BIOS-provided physical RAM map: Mar 18 10:15:04 riri kernel: BIOS-e820: - 0009fc00 (usable) Mar 18 10:15:04 riri kernel: BIOS-e820: 0009fc00 - 000a (reserved) Mar 18 10:15:04 riri kernel: BIOS-e820: 000e4000 - 0010 (reserved) Mar 18 10:15:04 riri kernel: BIOS-e820: 0010 - c7f8 (usable) Mar 18 10:15:04 riri kernel: BIOS-e820: c7f8 - c7f8e000 (ACPI data) Mar 18 10:15:04 riri kernel: BIOS-e820: c7f8e000 - c7fe (ACPI NVS) Mar 18 10:15:04 riri kernel: BIOS-e820: c7fe - c800 (reserved) Mar 18 10:15:04 riri kernel: BIOS-e820: ffb0 - 0001 (reserved) Mar 18 10:15:04 riri kernel: end_pfn_map = 1048576 Mar 18 10:15:04 riri kernel: DMI 2.4 present. Mar 18 10:15:04 riri kernel: ACPI: RSDP 000FAF20, 0024 (r2 ACPIAM) Mar 18 10:15:04 riri kernel: ACPI: XSDT C7F80100, 005C (r1 A_M_I_ OEMXSDT 12000608 MSFT 97) Mar 18 10:15:04 riri kernel: ACPI: FACP C7F80290, 00F4 (r3 A_M_I_ OEMFACP 12000608 MSFT 97) Mar 18 10:15:04 riri kernel: ACPI: DSDT C7F80410, 8FC4 (r1 A0543 A0543000 0 INTL 20060113) Mar 18 10:15:04 riri kernel: ACPI: FACS C7F8E000, 0040 Mar 18 10:15:04 riri kernel: ACPI: APIC C7F80390, 0080 (r1 A_M_I_ OEMAPIC 12000608 MSFT 97) Mar 18 10:15:04 riri kernel: ACPI: OEMB C7F8E040, 0066 (r1 A_M_I_ AMI_OEM 12000608 MSFT 97) Mar 18 10:15:04 riri kernel: ACPI: HPET C7F893E0, 0038 (r1 A_M_I_ OEMHPET 12000608 MSFT 97) Mar 18 10:15:04 riri kernel: ACPI: MCFG C7F89420, 003C (r1 A_M_I_ OEMMCFG 12000608 MSFT 97) Mar 18 10:15:04 riri kernel: ACPI: SSDT C7F8E0B0, 01C6 (r1AMI CPU1PM 1 INTL 20060113) Mar 18 10:15:04 riri kernel: ACPI: SSDT C7F8E280, 013A (r1AMI CPU2PM 1 INTL 20060113) Mar 18 10:15:04 riri kernel: Zone PFN ranges: Mar 18 10:15:04 riri kernel: DMA 0 - 4096 Mar 18 10:15:04 riri kernel: DMA324096 - 1048576 Mar 18 10:15:04 riri kernel: Normal1048576 - 1048576 Mar 18 10:15:04 riri kernel: early_node_map[2] active PFN ranges Mar 18 10:15:04 riri kernel: 0:0 - 159 Mar 18 10:15:04 riri kernel: 0: 256 - 819072 Mar 18 10:15:04 riri kernel: ACPI: PM-Timer IO Port: 0x808 Mar 18 10:15:04 riri kernel: ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Mar 18 10:15:04 riri kernel: Processor #0 (Bootup-CPU) Mar 18 10:15:04 riri kernel: ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Mar 18 10:15:04 riri kernel: Processor #1 Mar 18 10:15:04 riri kernel: ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled) Mar 18 10:15:04 riri kernel: ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled) Mar 18 10:15:04 riri kernel: ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) Mar 18 10:15:04 riri kernel: IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 Mar 18 10:15:04 riri kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) Mar 18 10:15:04 riri kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Mar 18 10:15:04 riri kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) Mar 18 10:15:04 riri kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Mar 18 10:15:04 riri kernel: Setting APIC routing to flat Mar 18 10:15:04 riri kernel: ACPI: HPET id: 0x8086a201 base: 0xfed0 Mar 18 10:15:04 riri kernel: Using ACPI (MADT) for SMP configuration information Mar 18 10:15:04 riri kernel: Nosave address range: 0009f000 - 000a Mar 18 10:15:04 riri kernel: Nosave address range: 000a - 000e4000 Mar 18 10:15:04 riri kernel: Nosave address range: 000e4000 - 0010 Mar 18 10:15:04 riri kernel: Allocating PCI resources starting at cc00 (gap: c800:37b0) Mar 18 10:15:04 riri kernel:
RE: [git patches] libata fixes
Hello, Yeap, more than three HSM violations in ten minutes. That's the criteria for turning off NCQ. Good to see it working. It look like a lot because libata reports all active commands (can't help as on HSM failure, there's no way to determine which caused it) and the SCSI prints revalidation messages, but it's still only three errors. Thanks for verifying that. I wanted to verify it works in the field as expected. Glad to help ! Anyhow, how should I consider these errors ? Are they real failure that can affect data integrity on the disk, or some kind of protocol errors with the disk, that are covered by soft (retry or so), and don't affect data ? Regards, Paul - 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: [git patches] libata fixes
Hi, This is NCQ protocol violation on the drive's side shown on some early drives. No need to worry too much about it. The drive will just get blacklisted for NCQ and should work fine. Thx. Also, remember one of the problem I have, with ata2 going to timeout because this port of the ICH7 is connected to a PMT ? You suggested me to connect a disk to one of the SATA port of the PMT, and reboot the machine to see if the timeout would vanish... I've just done it, and here is the relevant part of the boot log : ACPI: PCI Interrupt :00:1f.2[B] - GSI 23 (level, low) - IRQ 23 ahci :00:1f.2: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode ahci :00:1f.2: flags: 64bit ncq led clo pio slum part ata1: SATA max UDMA/133 cmd 0xc208e900 ctl 0x bmdma 0x irq 504 ata2: SATA max UDMA/133 cmd 0xc208e980 ctl 0x bmdma 0x irq 504 ata3: SATA max UDMA/133 cmd 0xc208ea00 ctl 0x bmdma 0x irq 504 ata4: SATA max UDMA/133 cmd 0xc208ea80 ctl 0x bmdma 0x irq 504 scsi0 : ahci ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133 ata1.00: 490234752 sectors, multi 0: LBA48 NCQ (not used) ata1.00: configured for UDMA/133 scsi1 : ahci ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata2.00: ATA-6: External Disk 0, RGL10364, max UDMA/133 ata2.00: 1 sectors, multi 1: LBA48 ata2.00: configured for UDMA/133 scsi2 : ahci ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata3.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133 ata3.00: 490234752 sectors, multi 0: LBA48 NCQ (not used) ata3.00: configured for UDMA/133 scsi3 : ahci ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata4.00: ATA-7: ST3500641AS, 3.AAB, max UDMA/133 ata4.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 31/32) ata4.00: configured for UDMA/133 scsi 0:0:0:0: Direct-Access ATA Maxtor 6L250S0 BANC PQ: 0 ANSI: 5 SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB) sda: Write Protect is off SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB) sda: Write Protect is off SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sd 0:0:0:0: Attached scsi disk sda sd 0:0:0:0: Attached scsi generic sg0 type 0 scsi 1:0:0:0: Direct-Access ATA External Disk 0 RGL1 PQ: 0 ANSI: 5 SCSI device sdb: 1 512-byte hdwr sectors (0 MB) sdb: Write Protect is off SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdb: 1 512-byte hdwr sectors (0 MB) sdb: Write Protect is off SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb: unknown partition table sd 1:0:0:0: Attached scsi disk sdb sd 1:0:0:0: Attached scsi generic sg1 type 0 scsi 2:0:0:0: Direct-Access ATA Maxtor 6L250S0 BANC PQ: 0 ANSI: 5 SCSI device sdc: 490234752 512-byte hdwr sectors (251000 MB) sdc: Write Protect is off SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdc: 490234752 512-byte hdwr sectors (251000 MB) sdc: Write Protect is off SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdc: sdc1 sdc2 sd 2:0:0:0: Attached scsi disk sdc sd 2:0:0:0: Attached scsi generic sg2 type 0 scsi 3:0:0:0: Direct-Access ATA ST3500641AS 3.AA PQ: 0 ANSI: 5 SCSI device sdd: 976773168 512-byte hdwr sectors (500108 MB) sdd: Write Protect is off SCSI device sdd: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdd: 976773168 512-byte hdwr sectors (500108 MB) sdd: Write Protect is off SCSI device sdd: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdd: sdd1 sdd2 sdd3 sd 3:0:0:0: Attached scsi disk sdd sd 3:0:0:0: Attached scsi generic sg3 type 0 ACPI: PCI Interrupt :02:00.0[A] - GSI 17 (level, low) - IRQ 17 ahci :02:00.0: AHCI 0001. 32 slots 2 ports 3 Gbps 0x3 impl SATA mode ahci :02:00.0: flags: 64bit ncq pm led clo pmp pio slum part ... The good news is that there is no more timeout, which is excellent ! The bad news is that the disk is not detected... but maybe I should do something in the BIOS configuration. I'll try to have a look at this, because connecting a disk to avoid TO without being able to use it is not that good ;) Regards, Paul - 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: [git patches] libata fixes
Doh ! Got that : ACPI: PCI Interrupt :00:1f.2[B] - GSI 23 (level, low) - IRQ 23 ahci :00:1f.2: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode ahci :00:1f.2: flags: 64bit ncq led clo pio slum part ata1: SATA max UDMA/133 cmd 0xc208e900 ctl 0x bmdma 0x irq 504 ata2: SATA max UDMA/133 cmd 0xc208e980 ctl 0x bmdma 0x irq 504 ata3: SATA max UDMA/133 cmd 0xc208ea00 ctl 0x bmdma 0x irq 504 ata4: SATA max UDMA/133 cmd 0xc208ea80 ctl 0x bmdma 0x irq 504 scsi0 : ahci ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133 ata1.00: 490234752 sectors, multi 0: LBA48 NCQ (not used) ata1.00: configured for UDMA/133 scsi1 : ahci ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata2.00: ATA-6: External Disk 0, RGL10364, max UDMA/133 ata2.00: 1 sectors, multi 1: LBA48 ata2.00: configured for UDMA/133 scsi2 : ahci ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata3.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133 ata3.00: 490234752 sectors, multi 0: LBA48 NCQ (not used) ata3.00: configured for UDMA/133 scsi3 : ahci ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata4.00: ATA-7: ST3500641AS, 3.AAB, max UDMA/133 ata4.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 31/32) ata4.00: configured for UDMA/133 scsi 0:0:0:0: Direct-Access ATA Maxtor 6L250S0 BANC PQ: 0 ANSI: 5 SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB) sda: Write Protect is off SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB) sda: Write Protect is off SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sd 0:0:0:0: Attached scsi disk sda sd 0:0:0:0: Attached scsi generic sg0 type 0 scsi 1:0:0:0: Direct-Access ATA External Disk 0 RGL1 PQ: 0 ANSI: 5 SCSI device sdb: 1 512-byte hdwr sectors (0 MB) sdb: Write Protect is off SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdb: 1 512-byte hdwr sectors (0 MB) sdb: Write Protect is off SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb:3irq 504: nobody cared (try booting with the irqpoll option) Call Trace: IRQ [802b0245] __report_bad_irq+0x35/0x90 [802b04ba] note_interrupt+0x21a/0x270 [802b128f] handle_edge_irq+0x10f/0x150 [8026f3eb] do_IRQ+0x7b/0xf0 [80259e70] mwait_idle+0x0/0x50 [802612d1] ret_from_intr+0x0/0xa EOI [8042bff0] vgacon_cursor+0x0/0x1d0 [80259eb6] mwait_idle+0x46/0x50 [8024aebc] cpu_idle+0x5c/0xa0 [808b984a] start_kernel+0x2aa/0x2c0 [808b9176] _sinittext+0x176/0x180 handlers: [804e1c90] (ahci_interrupt+0x0/0x590) Disabling IRQ #504 unknown partition table sd 1:0:0:0: Attached scsi disk sdb sd 1:0:0:0: Attached scsi generic sg1 type 0 scsi 2:0:0:0: Direct-Access ATA Maxtor 6L250S0 BANC PQ: 0 ANSI: 5 SCSI device sdc: 490234752 512-byte hdwr sectors (251000 MB) sdc: Write Protect is off and though it said : sdb:3irq 504: nobody cared (try booting with the irqpoll option) I _am_ booting with the irqpoll option ! Paul - 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: [git patches] libata fixes
Hello, > The kernel says that NCQ is turned off due to excessive > errors. If your > HSM violation is intermittent, it might not trigger tho. I've just grep'ed thru all my messages, and I can't find anything stating that NCQ is being turned off... Paul - 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: [git patches] libata fixes
> If you leave it alone, does libata turn off NCQ and boot continues? boot continues, but I can't tell anything about libata turning of NCQ... I've had a bunch of them at some while while compiling some kernel, so it was quite some time after booting. Is there a message I can check for that would indicate NCQ being turned off ? Regards, Paul - 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: [git patches] libata fixes
Hello,
> Please match the firmware version as well for the Maxtor drives
Ok.
> > --- linux-2.6.21-rc4/drivers/ata/libata-core.c 2007-03-17
> 19:29:45.0
> > +0100
> > +++ linux-2.6.21-rc4-Maxtor/drivers/ata/libata-core.c 2007-03-17
> > 19:37:28.0 +0100
> > @@ -3359,6 +3359,8 @@
> > { "WDC WD740ADFD-00", NULL, ATA_HORKAGE_NONCQ },
> > /* http://thread.gmane.org/gmane.linux.ide/14907 */
> > { "FUJITSU MHT2060BH", NULL, ATA_HORKAGE_NONCQ },
> > + /* NCQ is broken */
> > + { "Maxtor 6L250S0", NULL,
> ATA_HORKAGE_NONCQ },
> >
> > /* Devices with NCQ limits */
> >
> >
> > Signed-off-by: Paul Rolland <[EMAIL PROTECTED]>
>
> NAK - but add the firmware to the match and you can have an Ack 8)
Second try, compiled _and_ boot tested, of course.
dmesg says :
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133
ata1.00: 490234752 sectors, multi 0: LBA48 NCQ (not used)
ata1.00: configured for UDMA/133
--- linux-2.6.21-rc4/drivers/ata/libata-core.c 2007-03-17 19:47:49.0
+0100
+++ linux-2.6.21-rc4-Maxtor/drivers/ata/libata-core.c 2007-03-17
20:24:01.0 +0100
@@ -3359,6 +3359,8 @@
{ "WDC WD740ADFD-00", NULL, ATA_HORKAGE_NONCQ },
/* http://thread.gmane.org/gmane.linux.ide/14907 */
{ "FUJITSU MHT2060BH", NULL, ATA_HORKAGE_NONCQ },
+ /* NCQ is broken */
+ { "Maxtor 6L250S0", "BANC1G10", ATA_HORKAGE_NONCQ },
/* Devices with NCQ limits */
Signed-off-by: Paul Rolland <[EMAIL PROTECTED]>
Regards,
Paul
-
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: [git patches] libata fixes
Hello,
Here is a patch to avoid these pesky messages for the Maxtor disk :
--- linux-2.6.21-rc4/drivers/ata/libata-core.c 2007-03-17 19:29:45.0
+0100
+++ linux-2.6.21-rc4-Maxtor/drivers/ata/libata-core.c 2007-03-17
19:37:28.0 +0100
@@ -3359,6 +3359,8 @@
{ "WDC WD740ADFD-00", NULL, ATA_HORKAGE_NONCQ },
/* http://thread.gmane.org/gmane.linux.ide/14907 */
{ "FUJITSU MHT2060BH", NULL, ATA_HORKAGE_NONCQ },
+ /* NCQ is broken */
+ { "Maxtor 6L250S0", NULL, ATA_HORKAGE_NONCQ },
/* Devices with NCQ limits */
Signed-off-by: Paul Rolland <[EMAIL PROTECTED]>
With this applied, my machine has stopped all those painful messages.
dmesg now says :
[EMAIL PROTECTED]:/Kernels# dmesg | grep LBA
ata1.00: 490234752 sectors, multi 0: LBA48 NCQ (not used)
ata2.00: 640 sectors, multi 1: LBA
ata3.00: 490234752 sectors, multi 0: LBA48 NCQ (not used)
instead of NCQ (depth 31/32), but there doesn't seem to be any adverse
effects.
Regards,
Paul
Paul Rolland, rol(at)as2917.net
ex-AS2917 Network administrator and Peering Coordinator
--
Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur
"Some people dream of success... while others wake up and work hard at it"
"I worry about my child and the Internet all the time, even though she's too
young to have logged on yet. Here's what I worry about. I worry that 10 or 15
years from now, she will come to me and say 'Daddy, where were you when they
took freedom of the press away from the Internet?'"
--Mike Godwin, Electronic Frontier Foundation
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Paul Rolland
> Sent: Saturday, March 17, 2007 6:59 PM
> To: 'Tejun Heo'
> Cc: 'Linus Torvalds'; 'Jeff Garzik'; 'Alan Cox'; 'Andrew
> Morton'; linux-ide@vger.kernel.org; 'LKML'; 'Eric D. Mudama'
> Subject: RE: [git patches] libata fixes
>
> Hello,
>
> I'm preparing to attach a disk.
> In the meantime, I've rebuild a 2.6.21-rc4, and got that
> while booting :
> ...
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata1.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133
> ata1.00: 490234752 sectors, multi 0: LBA48 NCQ (depth 31/32)
> ata1.00: configured for UDMA/133
> ...
> Adding 2096436k swap on /dev/sde5. Priority:-1 extents:1
> across:2096436k
> Adding 4192956k swap on /dev/sda3. Priority:-2 extents:1
> across:4192956k
> ata1.00: exception Emask 0x2 SAct 0x7fc3 SErr 0x0 action
> 0x2 frozen
> ata1.00: (spurious completions during NCQ issue=0x0 SAct=0x7fc3
> FIS=004040a1:0020)
> ata1.00: cmd 60/01:00:52:eb:ff/00:00:09:00:00/40 tag 0 cdb
> 0x0 data 512 in
> res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
> (HSM violation)
> ata1.00: cmd 60/40:08:53:eb:ff/00:00:09:00:00/40 tag 1 cdb
> 0x0 data 32768 in
> res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
> (HSM violation)
> ata1.00: cmd 60/01:30:39:eb:ff/00:00:09:00:00/40 tag 6 cdb
> 0x0 data 512 in
> res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
> (HSM violation)
> ata1.00: cmd 60/01:38:3a:eb:ff/00:00:09:00:00/40 tag 7 cdb
> 0x0 data 512 in
> res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
> (HSM violation)
> ata1.00: cmd 60/01:40:3b:eb:ff/00:00:09:00:00/40 tag 8 cdb
> 0x0 data 512 in
> res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
> (HSM violation)
> ata1.00: cmd 60/01:48:3c:eb:ff/00:00:09:00:00/40 tag 9 cdb
> 0x0 data 512 in
> res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
> (HSM violation)
> ata1.00: cmd 60/01:50:3d:eb:ff/00:00:09:00:00/40 tag 10 cdb
> 0x0 data 512 in
> res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
> (HSM violation)
> ata1.00: cmd 60/01:58:3e:eb:ff/00:00:09:00:00/40 tag 11 cdb
> 0x0 data 512 in
> res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
> (HSM violation)
> ata1.00: cmd 60/01:60:3f:eb:ff/00:00:09:00:00/40 tag 12 cdb
> 0x0 data 512 in
> res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
> (HSM violation)
> ata1.00: cmd 60/01:68:40:eb:ff/00:00:09:00:00/40 tag 13 cdb
> 0x0 data 512 in
> res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
> (HSM violation)
> ata1.00: cmd 60/01:70:41:eb:ff/00:00:09:00:00/40 tag 14 cdb
> 0x0 data 512 in
> res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
> (HSM violation)
> ata1.00: cmd 60/01:78:42:eb:ff/00:00:09:00:00/40 tag 15 cdb
> 0x0 data 512 in
> res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
> (HSM violation)
> ata1.00: cmd 60/01:80:43:eb:ff/00:00:09:00:00/40 tag 16 cdb
> 0x0 data 512 in
> res 40/00:08:53:eb:ff/00:00:09:00:00/4
RE: [git patches] libata fixes
Hello, I'm preparing to attach a disk. In the meantime, I've rebuild a 2.6.21-rc4, and got that while booting : ... ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133 ata1.00: 490234752 sectors, multi 0: LBA48 NCQ (depth 31/32) ata1.00: configured for UDMA/133 ... Adding 2096436k swap on /dev/sde5. Priority:-1 extents:1 across:2096436k Adding 4192956k swap on /dev/sda3. Priority:-2 extents:1 across:4192956k ata1.00: exception Emask 0x2 SAct 0x7fc3 SErr 0x0 action 0x2 frozen ata1.00: (spurious completions during NCQ issue=0x0 SAct=0x7fc3 FIS=004040a1:0020) ata1.00: cmd 60/01:00:52:eb:ff/00:00:09:00:00/40 tag 0 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/40:08:53:eb:ff/00:00:09:00:00/40 tag 1 cdb 0x0 data 32768 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:30:39:eb:ff/00:00:09:00:00/40 tag 6 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:38:3a:eb:ff/00:00:09:00:00/40 tag 7 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:40:3b:eb:ff/00:00:09:00:00/40 tag 8 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:48:3c:eb:ff/00:00:09:00:00/40 tag 9 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:50:3d:eb:ff/00:00:09:00:00/40 tag 10 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:58:3e:eb:ff/00:00:09:00:00/40 tag 11 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:60:3f:eb:ff/00:00:09:00:00/40 tag 12 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:68:40:eb:ff/00:00:09:00:00/40 tag 13 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:70:41:eb:ff/00:00:09:00:00/40 tag 14 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:78:42:eb:ff/00:00:09:00:00/40 tag 15 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:80:43:eb:ff/00:00:09:00:00/40 tag 16 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:88:44:eb:ff/00:00:09:00:00/40 tag 17 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:90:45:eb:ff/00:00:09:00:00/40 tag 18 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:98:46:eb:ff/00:00:09:00:00/40 tag 19 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:a0:47:eb:ff/00:00:09:00:00/40 tag 20 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:a8:48:eb:ff/00:00:09:00:00/40 tag 21 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:b0:49:eb:ff/00:00:09:00:00/40 tag 22 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:b8:4a:eb:ff/00:00:09:00:00/40 tag 23 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:c0:4b:eb:ff/00:00:09:00:00/40 tag 24 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:c8:4c:eb:ff/00:00:09:00:00/40 tag 25 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:d0:4d:eb:ff/00:00:09:00:00/40 tag 26 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:d8:4e:eb:ff/00:00:09:00:00/40 tag 27 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:e0:4f:eb:ff/00:00:09:00:00/40 tag 28 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:e8:50:eb:ff/00:00:09:00:00/40 tag 29 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:f0:51:eb:ff/00:00:09:00:00/40 tag 30 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1: soft resetting port Kernel is a stock 2.6.21-rc4 I've just downloaded... I seem to remember this could be NCQ-related, and my disk should have been blacklisted, but is this already in 2.6.21-rc4 ? Regards, Paul Paul Rolland, rol(at)as2917.net ex-AS2917 Network administrator
RE: [git patches] libata fixes
> > PS : I'd like to try 2.6.21-rc3, but it seems that this is > breaking my > > config : disk naming is no more the same, and I end up with a panic > > Warning: unable to open an initial console > > though i've been compiling with the same .config I was > using for 2.6.21-rc2 > > Gaah. Can you get a log through serial console or netconsole > to see what changed? > Sorry, I've had no time this week for that. I've just switch to 2.6.21-rc4, and carefully restored config from 2.6.21-rc2, and boot is Ok... So, I must have done something bad when building 2.6.21-rc3, sorry for the noise. Regards, Paul - 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: [git patches] libata fixes
PS : I'd like to try 2.6.21-rc3, but it seems that this is breaking my config : disk naming is no more the same, and I end up with a panic Warning: unable to open an initial console though i've been compiling with the same .config I was using for 2.6.21-rc2 Gaah. Can you get a log through serial console or netconsole to see what changed? Sorry, I've had no time this week for that. I've just switch to 2.6.21-rc4, and carefully restored config from 2.6.21-rc2, and boot is Ok... So, I must have done something bad when building 2.6.21-rc3, sorry for the noise. Regards, Paul - 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: [git patches] libata fixes
Hello, I'm preparing to attach a disk. In the meantime, I've rebuild a 2.6.21-rc4, and got that while booting : ... ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133 ata1.00: 490234752 sectors, multi 0: LBA48 NCQ (depth 31/32) ata1.00: configured for UDMA/133 ... Adding 2096436k swap on /dev/sde5. Priority:-1 extents:1 across:2096436k Adding 4192956k swap on /dev/sda3. Priority:-2 extents:1 across:4192956k ata1.00: exception Emask 0x2 SAct 0x7fc3 SErr 0x0 action 0x2 frozen ata1.00: (spurious completions during NCQ issue=0x0 SAct=0x7fc3 FIS=004040a1:0020) ata1.00: cmd 60/01:00:52:eb:ff/00:00:09:00:00/40 tag 0 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/40:08:53:eb:ff/00:00:09:00:00/40 tag 1 cdb 0x0 data 32768 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:30:39:eb:ff/00:00:09:00:00/40 tag 6 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:38:3a:eb:ff/00:00:09:00:00/40 tag 7 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:40:3b:eb:ff/00:00:09:00:00/40 tag 8 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:48:3c:eb:ff/00:00:09:00:00/40 tag 9 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:50:3d:eb:ff/00:00:09:00:00/40 tag 10 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:58:3e:eb:ff/00:00:09:00:00/40 tag 11 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:60:3f:eb:ff/00:00:09:00:00/40 tag 12 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:68:40:eb:ff/00:00:09:00:00/40 tag 13 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:70:41:eb:ff/00:00:09:00:00/40 tag 14 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:78:42:eb:ff/00:00:09:00:00/40 tag 15 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:80:43:eb:ff/00:00:09:00:00/40 tag 16 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:88:44:eb:ff/00:00:09:00:00/40 tag 17 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:90:45:eb:ff/00:00:09:00:00/40 tag 18 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:98:46:eb:ff/00:00:09:00:00/40 tag 19 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:a0:47:eb:ff/00:00:09:00:00/40 tag 20 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:a8:48:eb:ff/00:00:09:00:00/40 tag 21 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:b0:49:eb:ff/00:00:09:00:00/40 tag 22 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:b8:4a:eb:ff/00:00:09:00:00/40 tag 23 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:c0:4b:eb:ff/00:00:09:00:00/40 tag 24 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:c8:4c:eb:ff/00:00:09:00:00/40 tag 25 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:d0:4d:eb:ff/00:00:09:00:00/40 tag 26 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:d8:4e:eb:ff/00:00:09:00:00/40 tag 27 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:e0:4f:eb:ff/00:00:09:00:00/40 tag 28 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:e8:50:eb:ff/00:00:09:00:00/40 tag 29 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/01:f0:51:eb:ff/00:00:09:00:00/40 tag 30 cdb 0x0 data 512 in res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) ata1: soft resetting port Kernel is a stock 2.6.21-rc4 I've just downloaded... I seem to remember this could be NCQ-related, and my disk should have been blacklisted, but is this already in 2.6.21-rc4 ? Regards, Paul Paul Rolland, rol(at)as2917.net ex-AS2917 Network administrator
RE: [git patches] libata fixes
Hello,
Here is a patch to avoid these pesky messages for the Maxtor disk :
--- linux-2.6.21-rc4/drivers/ata/libata-core.c 2007-03-17 19:29:45.0
+0100
+++ linux-2.6.21-rc4-Maxtor/drivers/ata/libata-core.c 2007-03-17
19:37:28.0 +0100
@@ -3359,6 +3359,8 @@
{ WDC WD740ADFD-00, NULL, ATA_HORKAGE_NONCQ },
/* http://thread.gmane.org/gmane.linux.ide/14907 */
{ FUJITSU MHT2060BH, NULL, ATA_HORKAGE_NONCQ },
+ /* NCQ is broken */
+ { Maxtor 6L250S0, NULL, ATA_HORKAGE_NONCQ },
/* Devices with NCQ limits */
Signed-off-by: Paul Rolland [EMAIL PROTECTED]
With this applied, my machine has stopped all those painful messages.
dmesg now says :
[EMAIL PROTECTED]:/Kernels# dmesg | grep LBA
ata1.00: 490234752 sectors, multi 0: LBA48 NCQ (not used)
ata2.00: 640 sectors, multi 1: LBA
ata3.00: 490234752 sectors, multi 0: LBA48 NCQ (not used)
instead of NCQ (depth 31/32), but there doesn't seem to be any adverse
effects.
Regards,
Paul
Paul Rolland, rol(at)as2917.net
ex-AS2917 Network administrator and Peering Coordinator
--
Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur
Some people dream of success... while others wake up and work hard at it
I worry about my child and the Internet all the time, even though she's too
young to have logged on yet. Here's what I worry about. I worry that 10 or 15
years from now, she will come to me and say 'Daddy, where were you when they
took freedom of the press away from the Internet?'
--Mike Godwin, Electronic Frontier Foundation
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Rolland
Sent: Saturday, March 17, 2007 6:59 PM
To: 'Tejun Heo'
Cc: 'Linus Torvalds'; 'Jeff Garzik'; 'Alan Cox'; 'Andrew
Morton'; linux-ide@vger.kernel.org; 'LKML'; 'Eric D. Mudama'
Subject: RE: [git patches] libata fixes
Hello,
I'm preparing to attach a disk.
In the meantime, I've rebuild a 2.6.21-rc4, and got that
while booting :
...
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133
ata1.00: 490234752 sectors, multi 0: LBA48 NCQ (depth 31/32)
ata1.00: configured for UDMA/133
...
Adding 2096436k swap on /dev/sde5. Priority:-1 extents:1
across:2096436k
Adding 4192956k swap on /dev/sda3. Priority:-2 extents:1
across:4192956k
ata1.00: exception Emask 0x2 SAct 0x7fc3 SErr 0x0 action
0x2 frozen
ata1.00: (spurious completions during NCQ issue=0x0 SAct=0x7fc3
FIS=004040a1:0020)
ata1.00: cmd 60/01:00:52:eb:ff/00:00:09:00:00/40 tag 0 cdb
0x0 data 512 in
res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
(HSM violation)
ata1.00: cmd 60/40:08:53:eb:ff/00:00:09:00:00/40 tag 1 cdb
0x0 data 32768 in
res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
(HSM violation)
ata1.00: cmd 60/01:30:39:eb:ff/00:00:09:00:00/40 tag 6 cdb
0x0 data 512 in
res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
(HSM violation)
ata1.00: cmd 60/01:38:3a:eb:ff/00:00:09:00:00/40 tag 7 cdb
0x0 data 512 in
res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
(HSM violation)
ata1.00: cmd 60/01:40:3b:eb:ff/00:00:09:00:00/40 tag 8 cdb
0x0 data 512 in
res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
(HSM violation)
ata1.00: cmd 60/01:48:3c:eb:ff/00:00:09:00:00/40 tag 9 cdb
0x0 data 512 in
res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
(HSM violation)
ata1.00: cmd 60/01:50:3d:eb:ff/00:00:09:00:00/40 tag 10 cdb
0x0 data 512 in
res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
(HSM violation)
ata1.00: cmd 60/01:58:3e:eb:ff/00:00:09:00:00/40 tag 11 cdb
0x0 data 512 in
res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
(HSM violation)
ata1.00: cmd 60/01:60:3f:eb:ff/00:00:09:00:00/40 tag 12 cdb
0x0 data 512 in
res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
(HSM violation)
ata1.00: cmd 60/01:68:40:eb:ff/00:00:09:00:00/40 tag 13 cdb
0x0 data 512 in
res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
(HSM violation)
ata1.00: cmd 60/01:70:41:eb:ff/00:00:09:00:00/40 tag 14 cdb
0x0 data 512 in
res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
(HSM violation)
ata1.00: cmd 60/01:78:42:eb:ff/00:00:09:00:00/40 tag 15 cdb
0x0 data 512 in
res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
(HSM violation)
ata1.00: cmd 60/01:80:43:eb:ff/00:00:09:00:00/40 tag 16 cdb
0x0 data 512 in
res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
(HSM violation)
ata1.00: cmd 60/01:88:44:eb:ff/00:00:09:00:00/40 tag 17 cdb
0x0 data 512 in
res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
(HSM violation)
ata1.00: cmd 60/01:90:45:eb:ff/00:00:09:00:00/40 tag 18 cdb
0x0 data 512 in
res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
(HSM violation)
ata1.00: cmd 60/01:98:46:eb:ff/00:00:09
RE: [git patches] libata fixes
Hello,
Please match the firmware version as well for the Maxtor drives
Ok.
--- linux-2.6.21-rc4/drivers/ata/libata-core.c 2007-03-17
19:29:45.0
+0100
+++ linux-2.6.21-rc4-Maxtor/drivers/ata/libata-core.c 2007-03-17
19:37:28.0 +0100
@@ -3359,6 +3359,8 @@
{ WDC WD740ADFD-00, NULL, ATA_HORKAGE_NONCQ },
/* http://thread.gmane.org/gmane.linux.ide/14907 */
{ FUJITSU MHT2060BH, NULL, ATA_HORKAGE_NONCQ },
+ /* NCQ is broken */
+ { Maxtor 6L250S0, NULL,
ATA_HORKAGE_NONCQ },
/* Devices with NCQ limits */
Signed-off-by: Paul Rolland [EMAIL PROTECTED]
NAK - but add the firmware to the match and you can have an Ack 8)
Second try, compiled _and_ boot tested, of course.
dmesg says :
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133
ata1.00: 490234752 sectors, multi 0: LBA48 NCQ (not used)
ata1.00: configured for UDMA/133
--- linux-2.6.21-rc4/drivers/ata/libata-core.c 2007-03-17 19:47:49.0
+0100
+++ linux-2.6.21-rc4-Maxtor/drivers/ata/libata-core.c 2007-03-17
20:24:01.0 +0100
@@ -3359,6 +3359,8 @@
{ WDC WD740ADFD-00, NULL, ATA_HORKAGE_NONCQ },
/* http://thread.gmane.org/gmane.linux.ide/14907 */
{ FUJITSU MHT2060BH, NULL, ATA_HORKAGE_NONCQ },
+ /* NCQ is broken */
+ { Maxtor 6L250S0, BANC1G10, ATA_HORKAGE_NONCQ },
/* Devices with NCQ limits */
Signed-off-by: Paul Rolland [EMAIL PROTECTED]
Regards,
Paul
-
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: [git patches] libata fixes
If you leave it alone, does libata turn off NCQ and boot continues? boot continues, but I can't tell anything about libata turning of NCQ... I've had a bunch of them at some while while compiling some kernel, so it was quite some time after booting. Is there a message I can check for that would indicate NCQ being turned off ? Regards, Paul - 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: [git patches] libata fixes
Hello, The kernel says that NCQ is turned off due to excessive errors. If your HSM violation is intermittent, it might not trigger tho. I've just grep'ed thru all my messages, and I can't find anything stating that NCQ is being turned off... Paul - 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: RSDL v0.30 cpu scheduler for ... 2.6.18.8 kernel
Hello Vincent, > patched kernel. Now it looks more like 5 seconds faster! > Wow.. nice work CK! > > 2.6.18.8 vanilla kernel: > [ 48.185716] libata version 2.00 loaded. > [ 49.838513] scsi0 : sata_nv > > > 2.6.18.8-rsdl-0.30: > [ 43.144312] libata version 2.00 loaded. > [ 45.820504] Vendor: ATA Model: Maxtor 6B250S0Rev: BANC > [ 45.822721] Type: Direct-Access As it seems the 5s net gain is during the early phase of the boot process, could you please post longer dmesgs, to let us know where the gain occurs ? Regards, Paul - 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: [git patches] libata fixes
Hello, > > That sounds a quite expensive solution ;) > > You should be able to just move the drive attached at ata1 to ata2. > Please report whether that works. I'll try to find an unused disk... As I said, these ports are part of Asus EZRaid solution, and i'd prefer this piece of code not to try to write anything on the disk ;) ... but I should find a disk without too much problem. Paul - 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: [git patches] libata fixes
Hello, > It involves a long timeout, so it's bothersome. This is caused by > Silicon Image 4726/3726 storage processor (SATA Port Multiplier with > extra features) attached to one of the ICH ports. Yes, I think this is the part Asus is using for it's EZ-Raid feature on this motherboard, and they seem to like their EZ-Raid, so it's likely to become more and more common. > If the first downstream port in the PMP is empty and it gets reset in I confirm it is empty in my config. > work very well with the current ATA reset sequence and gets identified > only after a few failures thus causing long timeout. 30s to 1min ;( > I keep forgetting about this. I'll ask SIMG how to deal with > this. For > the time being, connecting a device to the PMP port should remove the > timeouts. That sounds a quite expensive solution ;) Paul - 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: [git patches] libata fixes
Hello, > Ok, so that's just a message irritation, not actually bothersome > otherwise? It is somewhat painful, because delays involved are quite long, and it is not possible to explain the machine to "ignore" the port, and skip to the next one... > > The second problem is a Jmicron363 controler that is > failing to detect > > the DVD-RW that is connected, unless I use the irqpoll > option as Tejun has > > suggested. > > .. and this one has never worked without irqpoll? Exactly. > So it's the irq16 one that is the Jmicron controller and just isn't > getting any interrupts? It's IRQ 16 that is reported as affected to the Jmicron from the dmesg output, yes. > Since all the other interrupts work (and MSI worked for other > controllers), I don't think it's interrupt-routing related. > Especially as MSI shouldn't even care about things like that. > > And since it all works when "irqpoll" is used, that implies that the > *only* thing that is broken is literally irq delivery. Surely, also if you add the using pci=nomsi doesn't change anything. > Gaah. Can you get a log through serial console or netconsole > to see what changed? I'll try to do that Regards, Paul - 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: RSDL v0.30 cpu scheduler for ... 2.6.18.8 kernel
Hello Vincent, patched kernel. Now it looks more like 5 seconds faster! Wow.. nice work CK! 2.6.18.8 vanilla kernel: [ 48.185716] libata version 2.00 loaded. [ 49.838513] scsi0 : sata_nv 2.6.18.8-rsdl-0.30: [ 43.144312] libata version 2.00 loaded. [ 45.820504] Vendor: ATA Model: Maxtor 6B250S0Rev: BANC [ 45.822721] Type: Direct-Access As it seems the 5s net gain is during the early phase of the boot process, could you please post longer dmesgs, to let us know where the gain occurs ? Regards, Paul - 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: [git patches] libata fixes
Hello, Ok, so that's just a message irritation, not actually bothersome otherwise? It is somewhat painful, because delays involved are quite long, and it is not possible to explain the machine to ignore the port, and skip to the next one... The second problem is a Jmicron363 controler that is failing to detect the DVD-RW that is connected, unless I use the irqpoll option as Tejun has suggested. .. and this one has never worked without irqpoll? Exactly. So it's the irq16 one that is the Jmicron controller and just isn't getting any interrupts? It's IRQ 16 that is reported as affected to the Jmicron from the dmesg output, yes. Since all the other interrupts work (and MSI worked for other controllers), I don't think it's interrupt-routing related. Especially as MSI shouldn't even care about things like that. And since it all works when irqpoll is used, that implies that the *only* thing that is broken is literally irq delivery. Surely, also if you add the using pci=nomsi doesn't change anything. Gaah. Can you get a log through serial console or netconsole to see what changed? I'll try to do that Regards, Paul - 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: [git patches] libata fixes
Hello, It involves a long timeout, so it's bothersome. This is caused by Silicon Image 4726/3726 storage processor (SATA Port Multiplier with extra features) attached to one of the ICH ports. Yes, I think this is the part Asus is using for it's EZ-Raid feature on this motherboard, and they seem to like their EZ-Raid, so it's likely to become more and more common. If the first downstream port in the PMP is empty and it gets reset in I confirm it is empty in my config. work very well with the current ATA reset sequence and gets identified only after a few failures thus causing long timeout. 30s to 1min ;( I keep forgetting about this. I'll ask SIMG how to deal with this. For the time being, connecting a device to the PMP port should remove the timeouts. That sounds a quite expensive solution ;) Paul - 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: [git patches] libata fixes
Hello, That sounds a quite expensive solution ;) You should be able to just move the drive attached at ata1 to ata2. Please report whether that works. I'll try to find an unused disk... As I said, these ports are part of Asus EZRaid solution, and i'd prefer this piece of code not to try to write anything on the disk ;) ... but I should find a disk without too much problem. Paul - 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: [git patches] libata fixes
Hello, > > Nope... I tried several patches from Tejun, and also some > that Jeff posted > > to linux-ide, but no luck. The only way to have this DVD-RW > working is to > > use irqpoll on the command line... > > So it has *never* worked? That's what I'm trying to see - you had a > "before" and "after" dmesg in one of your posts, and the "before" one > looked fine (as if it was working) because it didn't have the error > messages. > > So I'm just trying to figure out where the regression started... > > > To complete, here are some more output from the machine : > > What happens if you disable MSI entirely? Use "pci=nomsi" on > the command > line. > > The > > ata2.00: qc timeout (cmd 0xec) > ata2.00: failed to IDENTIFY (I/O error, err_mask=0x104) > > messages happen for you on the controller that claims MSI: > > ata2: SATA max UDMA/133 cmd 0xc208a980 ctl > 0x bmdma 0x irq 504 > > and quite frankly, we've had lots of bugs with MSI, both in > hardware and > in software. OK, I see, we are talking about two different problems... My machine is having two problems : the one you are describing above, which is due to a SIL controler being connected to one port of the ICH7 (at least, it seems to), and probing it goes timeout, but nothing is connected on it. The second problem is a Jmicron363 controler that is failing to detect the DVD-RW that is connected, unless I use the irqpoll option as Tejun has suggested. >From what I remember, except my initial description of the problem, no attempt has been made yet to workaround/understand the first problem, and all the mails I've exchanged were focused on the second one. But, as you suggest it, I'm adding pci=nomsi to the command line rebooting... no change for this part of the problem. OK, the /proc/interrupt for this config, and the dmesg attached. 3 [23:22] [EMAIL PROTECTED]:~> cat /proc/interrupts CPU0 CPU1 0: 297549 0 IO-APIC-edge timer 1: 7 0 IO-APIC-edge i8042 4: 13 0 IO-APIC-edge serial 6: 5 0 IO-APIC-edge floppy 8: 1 0 IO-APIC-edge rtc 9: 0 0 IO-APIC-fasteoi acpi 12:126 0 IO-APIC-edge i8042 14: 8313 0 IO-APIC-edge libata 15: 0 0 IO-APIC-edge libata 16: 0 0 IO-APIC-fasteoi eth1, libata 17: 0 0 IO-APIC-fasteoi uhci_hcd:usb3 18: 6894 0 IO-APIC-fasteoi uhci_hcd:usb4 19:579 0 IO-APIC-fasteoi eth0, uhci_hcd:usb5, HDA Intel 20:104 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2 21: 3 0 IO-APIC-fasteoi ohci1394 23: 7205 0 IO-APIC-fasteoi libata NMI:783540 LOC: 291823 290536 PS : I'd like to try 2.6.21-rc3, but it seems that this is breaking my config : disk naming is no more the same, and I end up with a panic Warning: unable to open an initial console though i've been compiling with the same .config I was using for 2.6.21-rc2 Regards, Paul dmesg-2.6.21-rc2-irqpoll-nomsi Description: Binary data
RE: [git patches] libata fixes
Just one point that may be interesting, as it seems that this is IRQ related : at the beginning of the dmesg, it seems that IRQ16 is used for sky2/Yukon , but when reading /proc/interrupts, it has been remapped to IRQ 505... Could this also affect libata ? Regards, Paul Paul Rolland, rol(at)as2917.net ex-AS2917 Network administrator and Peering Coordinator -- Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur "Some people dream of success... while others wake up and work hard at it" "I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?'" --Mike Godwin, Electronic Frontier Foundation > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Paul Rolland > Sent: Sunday, March 11, 2007 7:35 PM > To: 'Linus Torvalds' > Cc: 'Tejun Heo'; 'Jeff Garzik'; 'Andrew Morton'; > linux-ide@vger.kernel.org; 'LKML'; 'Eric D. Mudama' > Subject: RE: [git patches] libata fixes > > Hello, > > > do I understand correctly that the *only* difference between > > the working > > setup is that you applied (by hand) the libata patch that > > Jeff sent out? > > > > So plain 2.6.21-rc2 works fine, but with the patch applied, > > you get no > > interrupts on the DVD drive? > > Nope... I tried several patches from Tejun, and also some > that Jeff posted > to linux-ide, but no luck. The only way to have this DVD-RW > working is to > use irqpoll on the command line... > > Sorry to have been unclear > > To complete, here are some more output from the machine : > - a dmesg without irqpoll, > - a dmesg with irqpoll, > - a copy of /proc/interrupts > 6 [19:33] [EMAIL PROTECTED]:~> cat /proc/interrupts >CPU0 CPU1 > 0: 357022 0 IO-APIC-edge timer > 1: 8 0 IO-APIC-edge i8042 > 4: 14 0 IO-APIC-edge serial > 6: 5 0 IO-APIC-edge floppy > 8: 1 0 IO-APIC-edge rtc > 9: 0 0 IO-APIC-fasteoi acpi > 12:129 0 IO-APIC-edge i8042 > 14: 7639 0 IO-APIC-edge libata > 15: 0 0 IO-APIC-edge libata > 16: 0 0 IO-APIC-fasteoi libata > 17: 0 0 IO-APIC-fasteoi uhci_hcd:usb3 > 18: 0 0 IO-APIC-fasteoi uhci_hcd:usb4 > 19:204 0 IO-APIC-fasteoi uhci_hcd:usb5, > HDA Intel > 20:107 0 IO-APIC-fasteoi ehci_hcd:usb1, > uhci_hcd:usb2 > 21: 3 0 IO-APIC-fasteoi ohci1394 > 504: 8243 0 PCI-MSI-edge libata > 505: 1 0 PCI-MSI-edge eth1 > 506:386 0 PCI-MSI-edge eth0 > NMI:771531 > LOC: 569318 578684 > ERR: 0 > > Regards, > Paul > - 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: [git patches] libata fixes
Hello, > It seems like IRQ is not getting through. The first IRQ > driven command is failing for you. H > Extract is : > ata7: PATA max UDMA/100 cmd 0x00019c00 ctl 0x00019882 bmdma > 0x00019400 irq 16 > ata8: PATA max UDMA/100 cmd 0x00019800 ctl 0x00019482 bmdma > 0x00019408 irq 16 IRQ 16 is IO-APIC-fasteoi for libata, and is not shared... but all the others libata IRQ are IO-APIC-edge. > * Does giving 'acpi=off' or 'irqpoll' make any difference? > > * Can you connect a harddisk to the channel and see whether > that works? Tried that.. Disk is identified as ATA-7: Mastor 6Y080L0, YAR41BW0, max UDMA/13 and then timeout again... Tried then with acpi=off, same result (identify is OK, but then timeout), and irqpoll and then it was OK Let's then go back to my DVD-RW and test irqpoll... and ... Yes Got it ! It is identified, it can be mounted, and read as /dev/sr1 ! /proc/interrupts show a count of 0 for IRQ 16, so yes, it goes somewhere else... Doing some diffs on copy of /proc/interrupts while accessing the DVD gives two possibilities : IRQ14 or IRQ18, but both are also counting when not accessing the DVD... Question : does running with irqpoll affects performance ? Paul - 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: [git patches] libata fixes
Hello, It seems like IRQ is not getting through. The first IRQ driven command is failing for you. H Extract is : ata7: PATA max UDMA/100 cmd 0x00019c00 ctl 0x00019882 bmdma 0x00019400 irq 16 ata8: PATA max UDMA/100 cmd 0x00019800 ctl 0x00019482 bmdma 0x00019408 irq 16 IRQ 16 is IO-APIC-fasteoi for libata, and is not shared... but all the others libata IRQ are IO-APIC-edge. * Does giving 'acpi=off' or 'irqpoll' make any difference? * Can you connect a harddisk to the channel and see whether that works? Tried that.. Disk is identified as ATA-7: Mastor 6Y080L0, YAR41BW0, max UDMA/13 and then timeout again... Tried then with acpi=off, same result (identify is OK, but then timeout), and irqpoll and then it was OK Let's then go back to my DVD-RW and test irqpoll... and ... Yes Got it ! It is identified, it can be mounted, and read as /dev/sr1 ! /proc/interrupts show a count of 0 for IRQ 16, so yes, it goes somewhere else... Doing some diffs on copy of /proc/interrupts while accessing the DVD gives two possibilities : IRQ14 or IRQ18, but both are also counting when not accessing the DVD... Question : does running with irqpoll affects performance ? Paul - 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: [git patches] libata fixes
Just one point that may be interesting, as it seems that this is IRQ related : at the beginning of the dmesg, it seems that IRQ16 is used for sky2/Yukon , but when reading /proc/interrupts, it has been remapped to IRQ 505... Could this also affect libata ? Regards, Paul Paul Rolland, rol(at)as2917.net ex-AS2917 Network administrator and Peering Coordinator -- Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur Some people dream of success... while others wake up and work hard at it I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?' --Mike Godwin, Electronic Frontier Foundation -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Rolland Sent: Sunday, March 11, 2007 7:35 PM To: 'Linus Torvalds' Cc: 'Tejun Heo'; 'Jeff Garzik'; 'Andrew Morton'; linux-ide@vger.kernel.org; 'LKML'; 'Eric D. Mudama' Subject: RE: [git patches] libata fixes Hello, do I understand correctly that the *only* difference between the working setup is that you applied (by hand) the libata patch that Jeff sent out? So plain 2.6.21-rc2 works fine, but with the patch applied, you get no interrupts on the DVD drive? Nope... I tried several patches from Tejun, and also some that Jeff posted to linux-ide, but no luck. The only way to have this DVD-RW working is to use irqpoll on the command line... Sorry to have been unclear To complete, here are some more output from the machine : - a dmesg without irqpoll, - a dmesg with irqpoll, - a copy of /proc/interrupts 6 [19:33] [EMAIL PROTECTED]:~ cat /proc/interrupts CPU0 CPU1 0: 357022 0 IO-APIC-edge timer 1: 8 0 IO-APIC-edge i8042 4: 14 0 IO-APIC-edge serial 6: 5 0 IO-APIC-edge floppy 8: 1 0 IO-APIC-edge rtc 9: 0 0 IO-APIC-fasteoi acpi 12:129 0 IO-APIC-edge i8042 14: 7639 0 IO-APIC-edge libata 15: 0 0 IO-APIC-edge libata 16: 0 0 IO-APIC-fasteoi libata 17: 0 0 IO-APIC-fasteoi uhci_hcd:usb3 18: 0 0 IO-APIC-fasteoi uhci_hcd:usb4 19:204 0 IO-APIC-fasteoi uhci_hcd:usb5, HDA Intel 20:107 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2 21: 3 0 IO-APIC-fasteoi ohci1394 504: 8243 0 PCI-MSI-edge libata 505: 1 0 PCI-MSI-edge eth1 506:386 0 PCI-MSI-edge eth0 NMI:771531 LOC: 569318 578684 ERR: 0 Regards, Paul - 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: [git patches] libata fixes
Hello, Nope... I tried several patches from Tejun, and also some that Jeff posted to linux-ide, but no luck. The only way to have this DVD-RW working is to use irqpoll on the command line... So it has *never* worked? That's what I'm trying to see - you had a before and after dmesg in one of your posts, and the before one looked fine (as if it was working) because it didn't have the error messages. So I'm just trying to figure out where the regression started... To complete, here are some more output from the machine : What happens if you disable MSI entirely? Use pci=nomsi on the command line. The ata2.00: qc timeout (cmd 0xec) ata2.00: failed to IDENTIFY (I/O error, err_mask=0x104) messages happen for you on the controller that claims MSI: ata2: SATA max UDMA/133 cmd 0xc208a980 ctl 0x bmdma 0x irq 504 and quite frankly, we've had lots of bugs with MSI, both in hardware and in software. OK, I see, we are talking about two different problems... My machine is having two problems : the one you are describing above, which is due to a SIL controler being connected to one port of the ICH7 (at least, it seems to), and probing it goes timeout, but nothing is connected on it. The second problem is a Jmicron363 controler that is failing to detect the DVD-RW that is connected, unless I use the irqpoll option as Tejun has suggested. From what I remember, except my initial description of the problem, no attempt has been made yet to workaround/understand the first problem, and all the mails I've exchanged were focused on the second one. But, as you suggest it, I'm adding pci=nomsi to the command line rebooting... no change for this part of the problem. OK, the /proc/interrupt for this config, and the dmesg attached. 3 [23:22] [EMAIL PROTECTED]:~ cat /proc/interrupts CPU0 CPU1 0: 297549 0 IO-APIC-edge timer 1: 7 0 IO-APIC-edge i8042 4: 13 0 IO-APIC-edge serial 6: 5 0 IO-APIC-edge floppy 8: 1 0 IO-APIC-edge rtc 9: 0 0 IO-APIC-fasteoi acpi 12:126 0 IO-APIC-edge i8042 14: 8313 0 IO-APIC-edge libata 15: 0 0 IO-APIC-edge libata 16: 0 0 IO-APIC-fasteoi eth1, libata 17: 0 0 IO-APIC-fasteoi uhci_hcd:usb3 18: 6894 0 IO-APIC-fasteoi uhci_hcd:usb4 19:579 0 IO-APIC-fasteoi eth0, uhci_hcd:usb5, HDA Intel 20:104 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2 21: 3 0 IO-APIC-fasteoi ohci1394 23: 7205 0 IO-APIC-fasteoi libata NMI:783540 LOC: 291823 290536 PS : I'd like to try 2.6.21-rc3, but it seems that this is breaking my config : disk naming is no more the same, and I end up with a panic Warning: unable to open an initial console though i've been compiling with the same .config I was using for 2.6.21-rc2 Regards, Paul dmesg-2.6.21-rc2-irqpoll-nomsi Description: Binary data
RE: 2.6.21-rc2 : Oops in rtc_cmos...
Hello, > > Yes, it does, so it's a Good One (tm), > > And points out that $SUBJECT is misleading; the root cause of > the oops isn't rtc_cmos. Workaround, don't enable the legacy > driver for this hardware. Well, sorry for that, but my point was that without enabling CONFIG_DRV_RTC_CMOS and only using CONFIG_RTC, my dmesg says : drivers/rtc/hctosys.c: unable to open rtc device (rtc0) Having seem that, I got thru all the options, trying to find what I could have forgot as an option, and added the RTC_CMOS one, that resulted in an Oops... > One of the good things about getting rtc-cmos merged: it > exposes this new RTC framework to new mistakes, which helps > fix some of the remaining rough spots. Good ;) > > pnp: Device 00:03 does not support disabling. > > Blame the PNP stack for that particular useless message. > I'l send a fix for that one too. OK, ready to test ! > > drivers/rtc/hctosys.c: unable to open rtc device (rtc0) > Because probing 00:03 failed, was never fully usable. > So then rtc0 couldn't be found. You'd get the same > message if, say, the RTC was loaded as a module. It seems to me that the DRV_RTC_CMOS and the "standard" CONFIG_RTC shouldn't be used at the same time... Am I correct on that ? Wouldn't it be better to have this dependancy enforced ? Regards, Paul - 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: 2.6.21-rc2 : Oops in rtc_cmos...
Hello, Yes, it does, so it's a Good One (tm), And points out that $SUBJECT is misleading; the root cause of the oops isn't rtc_cmos. Workaround, don't enable the legacy driver for this hardware. Well, sorry for that, but my point was that without enabling CONFIG_DRV_RTC_CMOS and only using CONFIG_RTC, my dmesg says : drivers/rtc/hctosys.c: unable to open rtc device (rtc0) Having seem that, I got thru all the options, trying to find what I could have forgot as an option, and added the RTC_CMOS one, that resulted in an Oops... One of the good things about getting rtc-cmos merged: it exposes this new RTC framework to new mistakes, which helps fix some of the remaining rough spots. Good ;) pnp: Device 00:03 does not support disabling. Blame the PNP stack for that particular useless message. I'l send a fix for that one too. OK, ready to test ! drivers/rtc/hctosys.c: unable to open rtc device (rtc0) Because probing 00:03 failed, was never fully usable. So then rtc0 couldn't be found. You'd get the same message if, say, the RTC was loaded as a module. It seems to me that the DRV_RTC_CMOS and the standard CONFIG_RTC shouldn't be used at the same time... Am I correct on that ? Wouldn't it be better to have this dependancy enforced ? Regards, Paul - 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: [git patches] libata fixes
Hell Tejun, I've boot-tested this yesterday, with no real luck... 1 - Tested on top of 2.6.21-rc2 (hope it's fine for you), 2 - Collected a full dmesg before and after Extract is : ata7: PATA max UDMA/100 cmd 0x00019c00 ctl 0x00019882 bmdma 0x00 019400 irq 16 ata8: PATA max UDMA/100 cmd 0x00019800 ctl 0x00019482 bmdma 0x00 019408 irq 16 scsi6 : pata_jmicron ata7.00: ATAPI, max UDMA/66 ata7.00: configured for UDMA/66 scsi7 : pata_jmicron ATA: abnormal status 0x7F on port 0x00019807 ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata7.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata7: soft resetting port ata7.00: configured for UDMA/66 ata7: EH complete ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata7.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata7: soft resetting port ata7.00: configured for UDMA/66 ata7: EH complete ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata7.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata7: soft resetting port ata7.00: configured for UDMA/66 ata7: EH complete ata7.00: limiting speed to UDMA/44:PIO4 ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata7.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata7: soft resetting port ata7.00: configured for UDMA/44 ata7: EH complete Hope this helps... Regards, Paul Paul Rolland, rol(at)as2917.net ex-AS2917 Network administrator and Peering Coordinator -- Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur "Some people dream of success... while others wake up and work hard at it" "I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?'" --Mike Godwin, Electronic Frontier Foundation > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tejun Heo > Sent: Monday, March 05, 2007 4:45 PM > To: [EMAIL PROTECTED] > Cc: 'Jeff Garzik'; 'Andrew Morton'; 'Linus Torvalds'; > linux-ide@vger.kernel.org; 'LKML'; 'Eric D. Mudama' > Subject: Re: [git patches] libata fixes > > Paul Rolland wrote: > > Hello, > > > >> Your drive has some issues with NCQ and is scheduled to be > blacklisted > >> such that it isn't enabled. libata used to ignore the > >> condition but now > >> considers it NCQ protocol violation and fails all pending commands. > > > > OK, do you need an hdparm report to fully identify the disk ? > > Nope, we already know. > > >> libata EH should turn NCQ off automatically after a few of > the above > >> errors. I'd love to see how that actually works in the field (full > >> dmesg please). If it doesn't, it needs fixing. > > > > I'll get you one tonite, I don't have access to the machine > right now. > > Great. Thanks. > > -- > tejun > - > To unsubscribe from this list: send the line "unsubscribe > linux-ide" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > dmesg-2.6.21-rc2.before.bz2 Description: Binary data dmesg-2.6.21-rc2.after.bz2 Description: Binary data
RE: 2.6.21-rc2 : Oops in rtc_cmos...
Hello Adrian, > does the patch in http://lkml.org/lkml/2007/2/23/184 fix your problem? Yes, it does, so it's a Good One (tm), but I don't understand what's going on then... My dmesg says, related to rtc : ... rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0 pnp: Device 00:03 does not support disabling. rtc_cmos: probe of 00:03 failed with error -16 ... and then later : ... drivers/rtc/hctosys.c: unable to open rtc device (rtc0) ... What does this all mean ? I thought an RTC Cmos was always there on a standard PC motherboard... (that's why I had activated the option in the first time). Regards, Paul - 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: [git patches] libata fixes
Hello, > Your drive has some issues with NCQ and is scheduled to be blacklisted > such that it isn't enabled. libata used to ignore the > condition but now > considers it NCQ protocol violation and fails all pending commands. OK, do you need an hdparm report to fully identify the disk ? > libata EH should turn NCQ off automatically after a few of the above > errors. I'd love to see how that actually works in the field (full > dmesg please). If it doesn't, it needs fixing. I'll get you one tonite, I don't have access to the machine right now. Regards, Paul - 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: [git patches] libata fixes
Hello, > 1. Has it ever worked with the previous kernels? I can't tell, this machine is new, and it never booted something that was not a 2.6.20 or 2.6.21. > 2. If you connect a harddisk to pata_jmicron, does it work? > > 3. Does applying the attached patch fix your problem? Will do these two tonite when back home. Thanks, Paul - 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: [git patches] libata fixes
Hello, 1. Has it ever worked with the previous kernels? I can't tell, this machine is new, and it never booted something that was not a 2.6.20 or 2.6.21. 2. If you connect a harddisk to pata_jmicron, does it work? 3. Does applying the attached patch fix your problem? Will do these two tonite when back home. Thanks, Paul - 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: [git patches] libata fixes
Hello, Your drive has some issues with NCQ and is scheduled to be blacklisted such that it isn't enabled. libata used to ignore the condition but now considers it NCQ protocol violation and fails all pending commands. OK, do you need an hdparm report to fully identify the disk ? libata EH should turn NCQ off automatically after a few of the above errors. I'd love to see how that actually works in the field (full dmesg please). If it doesn't, it needs fixing. I'll get you one tonite, I don't have access to the machine right now. Regards, Paul - 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: 2.6.21-rc2 : Oops in rtc_cmos...
Hello Adrian, does the patch in http://lkml.org/lkml/2007/2/23/184 fix your problem? Yes, it does, so it's a Good One (tm), but I don't understand what's going on then... My dmesg says, related to rtc : ... rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0 pnp: Device 00:03 does not support disabling. rtc_cmos: probe of 00:03 failed with error -16 ... and then later : ... drivers/rtc/hctosys.c: unable to open rtc device (rtc0) ... What does this all mean ? I thought an RTC Cmos was always there on a standard PC motherboard... (that's why I had activated the option in the first time). Regards, Paul - 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: [git patches] libata fixes
Hell Tejun, I've boot-tested this yesterday, with no real luck... 1 - Tested on top of 2.6.21-rc2 (hope it's fine for you), 2 - Collected a full dmesg before and after Extract is : ata7: PATA max UDMA/100 cmd 0x00019c00 ctl 0x00019882 bmdma 0x00 019400 irq 16 ata8: PATA max UDMA/100 cmd 0x00019800 ctl 0x00019482 bmdma 0x00 019408 irq 16 scsi6 : pata_jmicron ata7.00: ATAPI, max UDMA/66 ata7.00: configured for UDMA/66 scsi7 : pata_jmicron ATA: abnormal status 0x7F on port 0x00019807 ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata7.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata7: soft resetting port ata7.00: configured for UDMA/66 ata7: EH complete ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata7.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata7: soft resetting port ata7.00: configured for UDMA/66 ata7: EH complete ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata7.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata7: soft resetting port ata7.00: configured for UDMA/66 ata7: EH complete ata7.00: limiting speed to UDMA/44:PIO4 ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata7.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata7: soft resetting port ata7.00: configured for UDMA/44 ata7: EH complete Hope this helps... Regards, Paul Paul Rolland, rol(at)as2917.net ex-AS2917 Network administrator and Peering Coordinator -- Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur Some people dream of success... while others wake up and work hard at it I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?' --Mike Godwin, Electronic Frontier Foundation -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tejun Heo Sent: Monday, March 05, 2007 4:45 PM To: [EMAIL PROTECTED] Cc: 'Jeff Garzik'; 'Andrew Morton'; 'Linus Torvalds'; linux-ide@vger.kernel.org; 'LKML'; 'Eric D. Mudama' Subject: Re: [git patches] libata fixes Paul Rolland wrote: Hello, Your drive has some issues with NCQ and is scheduled to be blacklisted such that it isn't enabled. libata used to ignore the condition but now considers it NCQ protocol violation and fails all pending commands. OK, do you need an hdparm report to fully identify the disk ? Nope, we already know. libata EH should turn NCQ off automatically after a few of the above errors. I'd love to see how that actually works in the field (full dmesg please). If it doesn't, it needs fixing. I'll get you one tonite, I don't have access to the machine right now. Great. Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html dmesg-2.6.21-rc2.before.bz2 Description: Binary data dmesg-2.6.21-rc2.after.bz2 Description: Binary data
2.6.21-rc2 : Oops in rtc_cmos...
Hello, My machine is Oopsing at boot time, and ends up in a panic when I have : CONFIG_RTC_DRV_CMOS=y in my .config Here is a transcript of the Oops - no serial console at the moment - I made my best to copy without a mistake ! rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0 Unable to handle kernel NULL pointer dereference at 0030 RIP: [] rtc_sysfs_remove_device+0x1b/0x40 PGD 0 Oops: [1] PREEMPT SMP CPU 0 Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.21-rc2 #3 RIP: 0010:[] [] rtc_sysfs_remove_device+0x1b/0x40 RSP: :fff81000427fd60 EFLAGS: 00010202 RAX: RBX: 8100c70c1400 RCX: 0070 RDX: 8055a8a0 RSI: 80896e60 RDI: 8100c70c1400 RBP: 8100c70c1400 R08: 8100c7d594c0 R09: 0007 R10: 0002 R11: 804269a0 R12: 8100c74fd4e8 R13: 8100c74fd4f8 R14: 8100c74fd400 R15: FS: () GS:808cf000() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 0030 CR3: 00201000 CR4: 26e0 Process swapper (pid 1, threadinfo 81000427e000, task 8100426d740) Stack: 80896e60 8049fa41 8100c709aa80 8100c70c1400 0008 8100c7516b28 0008 8049fb39 8100c7516800 8055c066 Call Trace: [] class_device_del+0x81/0x170 [] class_device_unregister+0x9/0x20 [] cmos_pnp_probe+0x226/0x250 [] pnp_device_probe+0x91/0xd0 [] __driver_attach+0x0/0xb0 [] really_probe+0xba/0x160 [] __driver_attache+0x0/0xb0 [] __driver_attach+0x62/0xb0 [] bus_for_each_dev+0x49/0x80 [] bus_add_driver+0x7a/0x1e0 [] init+0x1a2/0x2b0 [] schedule_tail+0x3f/0xa0 [] child_rip+0xa/0x12 [] init+0x0/0x2b0 [] child_rip+0x0/0x12 Code: 48 83 78 30 00 74 0c 48 c7 c6 e0 e4 6c 80 e8 a2 4b f4 ff 48 RIP [] rtc_sysfs_remove_device+0x1b/0x40 RSP CR2: 0030 Kernel panic - not syncing: Attempted to kill init! Please find below my config .config Regards, Paul # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc2 # Sun Mar 4 19:12:12 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set CONFIG_UTS_NS=y # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_CPUSETS is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_RELAY=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Block layer # CONFIG_BLOCK=y CONFIG_BLK_DEV_IO_TRACE=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set # CONFIG_MK8 is not set # CONFIG_MPSC is not set CONFIG_MCORE2=y # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_MICROCODE=y CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_X86_HT=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y CONFIG_SMP=y CONFIG_SCHED_SMT=y CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY
2.6.21-rc2 : Oops in rtc_cmos...
Hello, My machine is Oopsing at boot time, and ends up in a panic when I have : CONFIG_RTC_DRV_CMOS=y in my .config Here is a transcript of the Oops - no serial console at the moment - I made my best to copy without a mistake ! rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0 Unable to handle kernel NULL pointer dereference at 0030 RIP: [8055a8bb] rtc_sysfs_remove_device+0x1b/0x40 PGD 0 Oops: [1] PREEMPT SMP CPU 0 Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.21-rc2 #3 RIP: 0010:[8055a8bb] [8055a8bb] rtc_sysfs_remove_device+0x1b/0x40 RSP: :fff81000427fd60 EFLAGS: 00010202 RAX: RBX: 8100c70c1400 RCX: 0070 RDX: 8055a8a0 RSI: 80896e60 RDI: 8100c70c1400 RBP: 8100c70c1400 R08: 8100c7d594c0 R09: 0007 R10: 0002 R11: 804269a0 R12: 8100c74fd4e8 R13: 8100c74fd4f8 R14: 8100c74fd400 R15: FS: () GS:808cf000() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 0030 CR3: 00201000 CR4: 26e0 Process swapper (pid 1, threadinfo 81000427e000, task 8100426d740) Stack: 80896e60 8049fa41 8100c709aa80 8100c70c1400 0008 8100c7516b28 0008 8049fb39 8100c7516800 8055c066 Call Trace: [8049fa41] class_device_del+0x81/0x170 [8049fb39] class_device_unregister+0x9/0x20 [8055c066] cmos_pnp_probe+0x226/0x250 [80448e11] pnp_device_probe+0x91/0xd0 [8049f000] __driver_attach+0x0/0xb0 [8049ec7a] really_probe+0xba/0x160 [8049f000] __driver_attache+0x0/0xb0 [8049f062] __driver_attach+0x62/0xb0 [8049dd19] bus_for_each_dev+0x49/0x80 [8049e26a] bus_add_driver+0x7a/0x1e0 [808f7a02] init+0x1a2/0x2b0 [8022897f] schedule_tail+0x3f/0xa0 [80262458] child_rip+0xa/0x12 [808f7860] init+0x0/0x2b0 [8026244e] child_rip+0x0/0x12 Code: 48 83 78 30 00 74 0c 48 c7 c6 e0 e4 6c 80 e8 a2 4b f4 ff 48 RIP [8055a8bb] rtc_sysfs_remove_device+0x1b/0x40 RSP 81000427fd60 CR2: 0030 Kernel panic - not syncing: Attempted to kill init! Please find below my config .config Regards, Paul # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc2 # Sun Mar 4 19:12:12 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set CONFIG_UTS_NS=y # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_CPUSETS is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_RELAY=y CONFIG_INITRAMFS_SOURCE= # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Block layer # CONFIG_BLOCK=y CONFIG_BLK_DEV_IO_TRACE=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=anticipatory # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set # CONFIG_MK8 is not set # CONFIG_MPSC is not set CONFIG_MCORE2=y # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTERNODE_CACHE_BYTES=64
RE: [PATCH] libata: Cable detection fixes
Hello,
Tried this (as well as the next one to activate the cable_detect),
but it doesn't help my DVD-RW detection problem on pata_jmicron :
PCI: Enabling device :02:00.1 ( -> 0001)
ACPI: PCI Interrupt :02:00.1[B] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device :02:00.1 to 64
ata9: PATA max UDMA/100 cmd 0x00019c00 ctl 0x00019882 bmdma
0x00019400 irq 16
ata10: PATA max UDMA/100 cmd 0x00019800 ctl 0x00019482 bmdma
0x00019408 irq 16
scsi8 : pata_jmicron
ata9.00: ATAPI, max UDMA/66
ata9.00: qc timeout (cmd 0xef)
ata9.00: failed to set xfermode (err_mask=0x4)
ata9.00: limiting speed to UDMA/44
ata9: failed to recover some devices, retrying in 5 secs
ata9.00: qc timeout (cmd 0xef)
ata9.00: failed to set xfermode (err_mask=0x4)
ata9.00: limiting speed to PIO0
ata9: failed to recover some devices, retrying in 5 secs
ata9.00: qc timeout (cmd 0xef)
ata9.00: failed to set xfermode (err_mask=0x4)
ata9.00: disabled
scsi9 : pata_jmicron
But it seems Alan's patch doesn't touch the jmicron code, so this may
explain why it doesn't help...
Regards,
Paul
Paul Rolland, rol(at)as2917.net
ex-AS2917 Network administrator and Peering Coordinator
--
Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur
"Some people dream of success... while others wake up and work hard at it"
"I worry about my child and the Internet all the time, even though she's too
young to have logged on yet. Here's what I worry about. I worry that 10 or 15
years from now, she will come to me and say 'Daddy, where were you when they
took freedom of the press away from the Internet?'"
--Mike Godwin, Electronic Frontier Foundation
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Alan
> Sent: Thursday, March 01, 2007 6:30 PM
> To: linux-ide@vger.kernel.org; linux-kernel@vger.kernel.org;
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: [PATCH] libata: Cable detection fixes
>
>
> 2.6.21-rc has horrible problems with libata and PATA cable types (and
> thus speeds). This occurs because Tejun fixed a pile of other bugs and
> we now do cable detect enforcement for drive side detection properly.
>
> Unfortunately we don't do the process around cable detection
> right. Tejun
> identified the problem and pointed to the right Annex in the
> spec, this patch
> implements the needed changes.
>
> The basic requirement is that we have to identify the slave before the
> master.
>
> The patch switches the identify order so that we can do the drive side
> detection correctly.
>
> Secondly we add a ->cable_detect() method called after the identify
> sequence which allows a host to do host side detection at this point
> should it wish, or to modify the results of the drive side identify.
>
> This separate ->cable_detect method also cleans up a lot of
> code because
> many drivers have their own error_handler methods which
> really just set
> the cable type.
>
> If there is no ->cable_detect method the cable type is left alone so a
> driver setting it earlier (eg because it has the SATA flags set or
> because it uses the old error_handler approach) will still do
> the right
> thing (or at least the same thing) as before.
>
> This patch simply adds the cable_detect method and helpers it
> doesn't use
> them but other follow up patches will (ie Adrian please don't submit
> patches to unexport them ;))
>
> Alan
>
>
> diff -u --new-file --recursive --exclude-from
> /usr/src/exclude
> linux.vanilla-2.6.21-rc2/drivers/ata/libata-core.c
> linux-2.6.21-rc2/drivers/ata/libata-core.c
> --- linux.vanilla-2.6.21-rc2/drivers/ata/libata-core.c
> 2007-03-01 13:36:03.0 +
> +++ linux-2.6.21-rc2/drivers/ata/libata-core.c
> 2007-03-01 15:49:21.853448880 +
> @@ -1800,6 +1800,56 @@
> }
>
> /**
> + * ata_cable_40wire- return 40pin cable type
> + * @ap: port
> + *
> + * Helper method for drivers which want to hardwire 40 pin cable
> + * detection.
> + */
> +
> +int ata_cable_40wire(struct ata_port *ap)
> +{
> + return ATA_CBL_PATA40;
> +}
> +
> +/**
> + * ata_cable_80wire- return 40pin cable type
> + * @ap: port
> + *
> + * Helper method for drivers which want to hardwire 80 pin cable
> + * detection.
> + */
> +
> +int ata_cable_80wire(struct ata_port *ap)
> +{
> + return ATA_CBL_PATA80;
> +}
> +
> +/**
> + * ata_cable_unknown - return unknown PATA cable.
> + * @ap: port
> + *
> + * Helper method for drivers which have no PATA cable detection.
> + */
> +
> +
RE: [git patches] libata fixes
1024 in
res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/02:68:62:ec:c4/00:00:0e:00:00/40 tag 13 cdb 0x0 data 1024 in
res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/02:70:64:ec:c4/00:00:0e:00:00/40 tag 14 cdb 0x0 data 1024 in
res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/02:78:66:ec:c4/00:00:0e:00:00/40 tag 15 cdb 0x0 data 1024 in
res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation)
ata1: soft resetting port
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: configured for UDMA/133
ata1: EH complete
SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support
DPO or FUA
This last part was not present when booting stock 2.6.21-rc1
Any other info you may need, please ask.
Regards,
Paul
Paul Rolland, rol(at)as2917.net
ex-AS2917 Network administrator and Peering Coordinator
--
Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur
"Some people dream of success... while others wake up and work hard at it"
"I worry about my child and the Internet all the time, even though she's too
young to have logged on yet. Here's what I worry about. I worry that 10 or 15
years from now, she will come to me and say 'Daddy, where were you when they
took freedom of the press away from the Internet?'"
--Mike Godwin, Electronic Frontier Foundation
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Garzik
> Sent: Friday, March 02, 2007 3:09 AM
> To: Andrew Morton; Linus Torvalds
> Cc: linux-ide@vger.kernel.org; LKML
> Subject: [git patches] libata fixes
>
>
> Does not include Alan's stuff, per recent email thread.
>
> Please pull from 'upstream-linus' branch of
> master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev
> .git upstream-linus
>
> to receive the following updates:
>
> drivers/ata/ahci.c | 55 ++--
> drivers/ata/libata-core.c |5 ++-
> drivers/ata/pata_cs5520.c |1 -
> drivers/ata/pata_isapnp.c |1 -
> drivers/ata/pata_jmicron.c | 51 ++
> drivers/ata/pata_platform.c |1 -
> drivers/ata/sata_sil24.c|3 --
> drivers/pci/quirks.c| 83
> +++---
> 8 files changed, 95 insertions(+), 105 deletions(-)
>
> Tejun Heo (7):
> libata: clear drvdata in ata_host_release(), take#2
> sata_sil24: kill unused local variable idx in sil24_fill_sg()
> libata: blacklist FUJITSU MHT2060BH for NCQ
> pata_jmicron: drop unnecessary device programming in [re]init
> jmicron ATA: reimplement jmicron ATA quirk
> ahci/pata_jmicron: match class not function number
> ahci: improve spurious SDB FIS handling
>
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index 6d93240..1539734 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -200,6 +200,7 @@ struct ahci_port_priv {
> /* for NCQ spurious interrupt analysis */
> unsigned intncq_saw_d2h:1;
> unsigned intncq_saw_dmas:1;
> + unsigned intncq_saw_sdb:1;
> };
>
> static u32 ahci_scr_read (struct ata_port *ap, unsigned int sc_reg);
> @@ -384,12 +385,9 @@ static const struct pci_device_id
> ahci_pci_tbl[] = {
> { PCI_VDEVICE(INTEL, 0x294d), board_ahci_pi }, /* ICH9 */
> { PCI_VDEVICE(INTEL, 0x294e), board_ahci_pi }, /* ICH9M */
>
> - /* JMicron */
> - { PCI_VDEVICE(JMICRON, 0x2360), board_ahci_ign_iferr },
> /* JMB360 */
> - { PCI_VDEVICE(JMICRON, 0x2361), board_ahci_ign_iferr },
> /* JMB361 */
> - { PCI_VDEVICE(JMICRON, 0x2363), board_ahci_ign_iferr },
> /* JMB363 */
> - { PCI_VDEVICE(JMICRON, 0x2365), board_ahci_ign_iferr },
> /* JMB365 */
> - { PCI_VDEVICE(JMICRON, 0x2366), board_ahci_ign_iferr },
> /* JMB366 */
> + /* JMicron 360/1/3/5/6, match class to avoid IDE function */
> + { PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
> + PCI_CLASS_STORAGE_SATA_AHCI, 0xff, board_ahci_ign_iferr },
>
> /* ATI */
> { PCI_VDEVICE(ATI, 0x4380), board_ahci }, /* ATI SB600
> non-raid */
> @@ -1160,23 +1158,31 @@ static void ahci_host_intr(struct
> ata_port *ap)
> }
>
> if (status & PORT_IRQ_SDB_FIS) {
> - /* SDB FIS containing spurious completions might be
> - * dangerous, whine and fail commands with HSM
> - * violation. EH will turn off NCQ after several such
RE: [git patches] libata fixes
:0e:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/02:68:62:ec:c4/00:00:0e:00:00/40 tag 13 cdb 0x0 data 1024 in
res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/02:70:64:ec:c4/00:00:0e:00:00/40 tag 14 cdb 0x0 data 1024 in
res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/02:78:66:ec:c4/00:00:0e:00:00/40 tag 15 cdb 0x0 data 1024 in
res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation)
ata1: soft resetting port
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: configured for UDMA/133
ata1: EH complete
SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support
DPO or FUA
This last part was not present when booting stock 2.6.21-rc1
Any other info you may need, please ask.
Regards,
Paul
Paul Rolland, rol(at)as2917.net
ex-AS2917 Network administrator and Peering Coordinator
--
Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur
Some people dream of success... while others wake up and work hard at it
I worry about my child and the Internet all the time, even though she's too
young to have logged on yet. Here's what I worry about. I worry that 10 or 15
years from now, she will come to me and say 'Daddy, where were you when they
took freedom of the press away from the Internet?'
--Mike Godwin, Electronic Frontier Foundation
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff Garzik
Sent: Friday, March 02, 2007 3:09 AM
To: Andrew Morton; Linus Torvalds
Cc: linux-ide@vger.kernel.org; LKML
Subject: [git patches] libata fixes
Does not include Alan's stuff, per recent email thread.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev
.git upstream-linus
to receive the following updates:
drivers/ata/ahci.c | 55 ++--
drivers/ata/libata-core.c |5 ++-
drivers/ata/pata_cs5520.c |1 -
drivers/ata/pata_isapnp.c |1 -
drivers/ata/pata_jmicron.c | 51 ++
drivers/ata/pata_platform.c |1 -
drivers/ata/sata_sil24.c|3 --
drivers/pci/quirks.c| 83
+++---
8 files changed, 95 insertions(+), 105 deletions(-)
Tejun Heo (7):
libata: clear drvdata in ata_host_release(), take#2
sata_sil24: kill unused local variable idx in sil24_fill_sg()
libata: blacklist FUJITSU MHT2060BH for NCQ
pata_jmicron: drop unnecessary device programming in [re]init
jmicron ATA: reimplement jmicron ATA quirk
ahci/pata_jmicron: match class not function number
ahci: improve spurious SDB FIS handling
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 6d93240..1539734 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -200,6 +200,7 @@ struct ahci_port_priv {
/* for NCQ spurious interrupt analysis */
unsigned intncq_saw_d2h:1;
unsigned intncq_saw_dmas:1;
+ unsigned intncq_saw_sdb:1;
};
static u32 ahci_scr_read (struct ata_port *ap, unsigned int sc_reg);
@@ -384,12 +385,9 @@ static const struct pci_device_id
ahci_pci_tbl[] = {
{ PCI_VDEVICE(INTEL, 0x294d), board_ahci_pi }, /* ICH9 */
{ PCI_VDEVICE(INTEL, 0x294e), board_ahci_pi }, /* ICH9M */
- /* JMicron */
- { PCI_VDEVICE(JMICRON, 0x2360), board_ahci_ign_iferr },
/* JMB360 */
- { PCI_VDEVICE(JMICRON, 0x2361), board_ahci_ign_iferr },
/* JMB361 */
- { PCI_VDEVICE(JMICRON, 0x2363), board_ahci_ign_iferr },
/* JMB363 */
- { PCI_VDEVICE(JMICRON, 0x2365), board_ahci_ign_iferr },
/* JMB365 */
- { PCI_VDEVICE(JMICRON, 0x2366), board_ahci_ign_iferr },
/* JMB366 */
+ /* JMicron 360/1/3/5/6, match class to avoid IDE function */
+ { PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
+ PCI_CLASS_STORAGE_SATA_AHCI, 0xff, board_ahci_ign_iferr },
/* ATI */
{ PCI_VDEVICE(ATI, 0x4380), board_ahci }, /* ATI SB600
non-raid */
@@ -1160,23 +1158,31 @@ static void ahci_host_intr(struct
ata_port *ap)
}
if (status PORT_IRQ_SDB_FIS) {
- /* SDB FIS containing spurious completions might be
- * dangerous, whine and fail commands with HSM
- * violation. EH will turn off NCQ after several such
- * failures.
- */
const __le32 *f = pp-rx_fis + RX_FIS_SDB;
- ata_ehi_push_desc(ehi, spurious completion during NCQ
- issue=0x%x SAct=0x%x FIS=%08x:%08x,
- readl(port_mmio + PORT_CMD_ISSUE),
- readl(port_mmio + PORT_SCR_ACT
RE: [PATCH] libata: Cable detection fixes
Hello,
Tried this (as well as the next one to activate the cable_detect),
but it doesn't help my DVD-RW detection problem on pata_jmicron :
PCI: Enabling device :02:00.1 ( - 0001)
ACPI: PCI Interrupt :02:00.1[B] - GSI 16 (level, low) - IRQ 16
PCI: Setting latency timer of device :02:00.1 to 64
ata9: PATA max UDMA/100 cmd 0x00019c00 ctl 0x00019882 bmdma
0x00019400 irq 16
ata10: PATA max UDMA/100 cmd 0x00019800 ctl 0x00019482 bmdma
0x00019408 irq 16
scsi8 : pata_jmicron
ata9.00: ATAPI, max UDMA/66
ata9.00: qc timeout (cmd 0xef)
ata9.00: failed to set xfermode (err_mask=0x4)
ata9.00: limiting speed to UDMA/44
ata9: failed to recover some devices, retrying in 5 secs
ata9.00: qc timeout (cmd 0xef)
ata9.00: failed to set xfermode (err_mask=0x4)
ata9.00: limiting speed to PIO0
ata9: failed to recover some devices, retrying in 5 secs
ata9.00: qc timeout (cmd 0xef)
ata9.00: failed to set xfermode (err_mask=0x4)
ata9.00: disabled
scsi9 : pata_jmicron
But it seems Alan's patch doesn't touch the jmicron code, so this may
explain why it doesn't help...
Regards,
Paul
Paul Rolland, rol(at)as2917.net
ex-AS2917 Network administrator and Peering Coordinator
--
Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur
Some people dream of success... while others wake up and work hard at it
I worry about my child and the Internet all the time, even though she's too
young to have logged on yet. Here's what I worry about. I worry that 10 or 15
years from now, she will come to me and say 'Daddy, where were you when they
took freedom of the press away from the Internet?'
--Mike Godwin, Electronic Frontier Foundation
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Alan
Sent: Thursday, March 01, 2007 6:30 PM
To: linux-ide@vger.kernel.org; linux-kernel@vger.kernel.org;
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [PATCH] libata: Cable detection fixes
2.6.21-rc has horrible problems with libata and PATA cable types (and
thus speeds). This occurs because Tejun fixed a pile of other bugs and
we now do cable detect enforcement for drive side detection properly.
Unfortunately we don't do the process around cable detection
right. Tejun
identified the problem and pointed to the right Annex in the
spec, this patch
implements the needed changes.
The basic requirement is that we have to identify the slave before the
master.
The patch switches the identify order so that we can do the drive side
detection correctly.
Secondly we add a -cable_detect() method called after the identify
sequence which allows a host to do host side detection at this point
should it wish, or to modify the results of the drive side identify.
This separate -cable_detect method also cleans up a lot of
code because
many drivers have their own error_handler methods which
really just set
the cable type.
If there is no -cable_detect method the cable type is left alone so a
driver setting it earlier (eg because it has the SATA flags set or
because it uses the old error_handler approach) will still do
the right
thing (or at least the same thing) as before.
This patch simply adds the cable_detect method and helpers it
doesn't use
them but other follow up patches will (ie Adrian please don't submit
patches to unexport them ;))
Alan
diff -u --new-file --recursive --exclude-from
/usr/src/exclude
linux.vanilla-2.6.21-rc2/drivers/ata/libata-core.c
linux-2.6.21-rc2/drivers/ata/libata-core.c
--- linux.vanilla-2.6.21-rc2/drivers/ata/libata-core.c
2007-03-01 13:36:03.0 +
+++ linux-2.6.21-rc2/drivers/ata/libata-core.c
2007-03-01 15:49:21.853448880 +
@@ -1800,6 +1800,56 @@
}
/**
+ * ata_cable_40wire- return 40pin cable type
+ * @ap: port
+ *
+ * Helper method for drivers which want to hardwire 40 pin cable
+ * detection.
+ */
+
+int ata_cable_40wire(struct ata_port *ap)
+{
+ return ATA_CBL_PATA40;
+}
+
+/**
+ * ata_cable_80wire- return 40pin cable type
+ * @ap: port
+ *
+ * Helper method for drivers which want to hardwire 80 pin cable
+ * detection.
+ */
+
+int ata_cable_80wire(struct ata_port *ap)
+{
+ return ATA_CBL_PATA80;
+}
+
+/**
+ * ata_cable_unknown - return unknown PATA cable.
+ * @ap: port
+ *
+ * Helper method for drivers which have no PATA cable detection.
+ */
+
+int ata_cable_unknown(struct ata_port *ap)
+{
+ return ATA_CBL_PATA_UNK;
+}
+
+/**
+ * ata_cable_sata - return SATA cable type
+ * @ap: port
+ *
+ * Helper method for drivers which have SATA cables
+ */
+
+int ata_cable_sata(struct ata_port *ap)
+{
+ return ATA_CBL_SATA;
+}
+
+/**
* ata_bus_probe - Reset and probe ATA bus
* @ap: Bus to probe
*
@@ -1850,8 +1900,11 @@
for (i
