* Re: SATA exceptions with 2.6.20-rc5 [not found] ` <fa.4QxeKMcmkoyhlL26AivZV6BFQJQ@ifi.uio.no> @ 2007-01-23 1:24 ` Robert Hancock 2007-01-23 1:34 ` Alistair John Strachan 2007-01-23 2:44 ` Björn Steinbrink 0 siblings, 2 replies; 71+ messages in thread From: Robert Hancock @ 2007-01-23 1:24 UTC (permalink / raw) To: Björn Steinbrink, Robert Hancock, Jeff Garzik, Chr, Alistair John Strachan, linux-kernel, htejun, jens.axboe, lwalton, pomac [-- Attachment #1: Type: text/plain, Size: 2983 bytes --] Björn Steinbrink wrote: >>> Running a kernel with the return statement replace by a line that prints >>> the irq_stat instead. >>> >>> Currently I'm seeing lots of 0x10 on ata1 and 0x0 on ata2. >> 40 minutes stress test now and no exception yet. What's interesting is >> that ata1 saw exactly one interrupt with irq_stat 0x0, all others that >> might have get dropped are as above. >> I'll keep it running for some time and will then re-enable the return >> statement to see if there's a relation between the irq_stat 0x0 and the >> exception. > > No, doesn't seem to be related, did get 2 exceptions, but no irq_stat > 0x0 for ata1. Syslog/dmesg has nothing new either, still the same > pattern of dismissed irq_stats. I've finally managed to reproduce this problem on my box, by doing: watch --interval=0.1 /sbin/hdparm -I /dev/sda on one drive and then running bonnie++ on /dev/sdb connected to the other port on the same controller device. Usually within a few minutes one of the IDENTIFY commands would time out in the same way you guys have been seeing. Through some various trials and tribulations, the only conclusion I can come to is that this controller really doesn't like that NV_INT_STATUS_CK804 register being looked at in ADMA mode. I tried adding some debug code to the qc_issue function that would check to see if the BUSY flag in altstatus went high or that register showed an interrupt within a certain time afterwards, however that really seemed to hose things, the system wouldn't even boot. Try out this patch, it just calls the ata_host_intr function where appropriate without using nv_host_intr which looks at the NV_INT_STATUS_CK804 register. This is what the original ADMA patch from Mr. Mysterious NVIDIA Person did, I'm guessing there may be a reason for that. With this patch I can get through a whole bonnie++ run with the repeated IDENTIFY requests running without seeing the error. As an aside, there seems to be some dubious code in nv_host_intr, if ata_host_intr returns 0 for handled when a command is outstanding, it goes and calls ata_check_status anyway. This is rather dangerous since if an interrupt showed up right after ata_host_intr but before ata_check_status, the ata_check_status would clear it and we would forget about it. I tried fixing just that issue and still had this problem however. I suspect that code is truly broken and needs further thought, but this patch avoids calling it in the ADMA case, at any rate. As a final aside, this is another case where the hardware docs for this controller would really be useful, in order to know whether we are actually supposed to be reading that register in ADMA mode or not. I sent a query to Allen Martin at NVIDIA asking if there's a way I could get access to the documents, but I haven't heard anything yet. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/ [-- Attachment #2: sata_nv-dont-check-ck804-int-status-in-adma.patch --] [-- Type: text/plain, Size: 672 bytes --] --- linux-2.6.20-rc5/drivers/ata/sata_nv.c 2007-01-19 19:18:53.000000000 -0600 +++ linux-2.6.20-rc5debug/drivers/ata/sata_nv.c 2007-01-22 18:35:09.000000000 -0600 @@ -750,9 +750,9 @@ static irqreturn_t nv_adma_interrupt(int /* if in ATA register mode, use standard ata interrupt handler */ if (pp->flags & NV_ADMA_PORT_REGISTER_MODE) { - u8 irq_stat = readb(host->mmio_base + NV_INT_STATUS_CK804) - >> (NV_INT_PORT_SHIFT * i); - handled += nv_host_intr(ap, irq_stat); + struct ata_queued_cmd *qc = ata_qc_from_tag(ap, ap->active_tag); + if(qc && !(qc->tf.flags & ATA_TFLAG_POLLING)) + handled += ata_host_intr(ap, qc); continue; } ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-23 1:24 ` SATA exceptions with 2.6.20-rc5 Robert Hancock @ 2007-01-23 1:34 ` Alistair John Strachan 2007-01-23 1:41 ` Robert Hancock 2007-01-23 2:44 ` Björn Steinbrink 1 sibling, 1 reply; 71+ messages in thread From: Alistair John Strachan @ 2007-01-23 1:34 UTC (permalink / raw) To: Robert Hancock Cc: Björn Steinbrink, Jeff Garzik, Chr, linux-kernel, htejun, jens.axboe, lwalton, pomac On Tuesday 23 January 2007 01:24, Robert Hancock wrote: > As a final aside, this is another case where the hardware docs for this > controller would really be useful, in order to know whether we are > actually supposed to be reading that register in ADMA mode or not. I > sent a query to Allen Martin at NVIDIA asking if there's a way I could > get access to the documents, but I haven't heard anything yet. Obviously, NVIDIA's response is disappointing, but thank you for putting the time in to debug this problem. Definitely sounds like a hardware defect, I'm just glad there's a workaround. Will we see this fix in 2.6.20? -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-23 1:34 ` Alistair John Strachan @ 2007-01-23 1:41 ` Robert Hancock 2007-01-23 15:29 ` Larry Walton 0 siblings, 1 reply; 71+ messages in thread From: Robert Hancock @ 2007-01-23 1:41 UTC (permalink / raw) To: Alistair John Strachan Cc: Björn Steinbrink, Jeff Garzik, Chr, linux-kernel, htejun, jens.axboe, lwalton, pomac Alistair John Strachan wrote: > On Tuesday 23 January 2007 01:24, Robert Hancock wrote: >> As a final aside, this is another case where the hardware docs for this >> controller would really be useful, in order to know whether we are >> actually supposed to be reading that register in ADMA mode or not. I >> sent a query to Allen Martin at NVIDIA asking if there's a way I could >> get access to the documents, but I haven't heard anything yet. > > Obviously, NVIDIA's response is disappointing, but thank you for putting the > time in to debug this problem. Definitely sounds like a hardware defect, I'm > just glad there's a workaround. > > Will we see this fix in 2.6.20? Hopefully, assuming it actually does fix the problem for those that have been seeing it.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/ ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-23 1:41 ` Robert Hancock @ 2007-01-23 15:29 ` Larry Walton 0 siblings, 0 replies; 71+ messages in thread From: Larry Walton @ 2007-01-23 15:29 UTC (permalink / raw) To: Robert Hancock; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 355 bytes --] The last patch (sata_nv-force-int-dev-in-interrupt.patch) seems to have fix the problem. Much appreciated, thank you. I'd consider it a must have in 2.6.20. -- *--* Mail: lwalton@real.com *--* Voice: 206.892.6269 *--* Cell: 206.225.0154 *--* HTTP://real.com -------------------------------------- - - - - - - - R e a l - - - - - - - - [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-23 1:24 ` SATA exceptions with 2.6.20-rc5 Robert Hancock 2007-01-23 1:34 ` Alistair John Strachan @ 2007-01-23 2:44 ` Björn Steinbrink 2007-01-23 5:03 ` Robert Hancock 1 sibling, 1 reply; 71+ messages in thread From: Björn Steinbrink @ 2007-01-23 2:44 UTC (permalink / raw) To: Robert Hancock Cc: Jeff Garzik, Chr, Alistair John Strachan, linux-kernel, htejun, jens.axboe, lwalton, pomac On 2007.01.22 19:24:22 -0600, Robert Hancock wrote: > Björn Steinbrink wrote: > >>>Running a kernel with the return statement replace by a line that prints > >>>the irq_stat instead. > >>> > >>>Currently I'm seeing lots of 0x10 on ata1 and 0x0 on ata2. > >>40 minutes stress test now and no exception yet. What's interesting is > >>that ata1 saw exactly one interrupt with irq_stat 0x0, all others that > >>might have get dropped are as above. > >>I'll keep it running for some time and will then re-enable the return > >>statement to see if there's a relation between the irq_stat 0x0 and the > >>exception. > > > >No, doesn't seem to be related, did get 2 exceptions, but no irq_stat > >0x0 for ata1. Syslog/dmesg has nothing new either, still the same > >pattern of dismissed irq_stats. > > I've finally managed to reproduce this problem on my box, by doing: > > watch --interval=0.1 /sbin/hdparm -I /dev/sda > > on one drive and then running bonnie++ on /dev/sdb connected to the > other port on the same controller device. Usually within a few minutes > one of the IDENTIFY commands would time out in the same way you guys > have been seeing. > > Through some various trials and tribulations, the only conclusion I can > come to is that this controller really doesn't like that > NV_INT_STATUS_CK804 register being looked at in ADMA mode. I tried > adding some debug code to the qc_issue function that would check to see > if the BUSY flag in altstatus went high or that register showed an > interrupt within a certain time afterwards, however that really seemed > to hose things, the system wouldn't even boot. Hm, I don't think it is unhappy about looking at NV_INT_STATUS_CK804. I'm running 2.6.20-rc5 with the INT_DEV check removed for 8 hours now without a single problem and that should still look at NV_INT_STATUS_CK804, right? I just noticed that my last email might not have been clear enough. The exceptions happened when I re-enabled the return statement in addition to the debug message. Without the INT_DEV check, it is completely fine AFAICT. > Try out this patch, it just calls the ata_host_intr function where > appropriate without using nv_host_intr which looks at the > NV_INT_STATUS_CK804 register. This is what the original ADMA patch from > Mr. Mysterious NVIDIA Person did, I'm guessing there may be a reason for > that. With this patch I can get through a whole bonnie++ run with the > repeated IDENTIFY requests running without seeing the error. I'll see if I can schedule a test run for tomorrow, I currently need this box. Thanks, Björn ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-23 2:44 ` Björn Steinbrink @ 2007-01-23 5:03 ` Robert Hancock 0 siblings, 0 replies; 71+ messages in thread From: Robert Hancock @ 2007-01-23 5:03 UTC (permalink / raw) To: Björn Steinbrink, Jeff Garzik, Chr, Alistair John Strachan, linux-kernel, htejun, jens.axboe, lwalton, pomac [-- Attachment #1: Type: text/plain, Size: 878 bytes --] Björn Steinbrink wrote: > Hm, I don't think it is unhappy about looking at NV_INT_STATUS_CK804. > I'm running 2.6.20-rc5 with the INT_DEV check removed for 8 hours now > without a single problem and that should still look at > NV_INT_STATUS_CK804, right? > I just noticed that my last email might not have been clear enough. The > exceptions happened when I re-enabled the return statement in addition > to the debug message. Without the INT_DEV check, it is completely fine > AFAICT. Indeed, it seems to be just the NV_INT_DEV check that is problematic. Here's a patch that's likely better to test, it forces the NV_INT_DEV flag on when a command is active, and also fixes that questionable code in nv_host_intr that I mentioned. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/ [-- Attachment #2: sata_nv-force-int-dev-in-interrupt.patch --] [-- Type: text/plain, Size: 1315 bytes --] --- linux-2.6.20-rc5/drivers/ata/sata_nv.c 2007-01-19 19:18:53.000000000 -0600 +++ linux-2.6.20-rc5debug/drivers/ata/sata_nv.c 2007-01-22 22:33:43.000000000 -0600 @@ -700,7 +700,6 @@ static void nv_adma_check_cpb(struct ata static int nv_host_intr(struct ata_port *ap, u8 irq_stat) { struct ata_queued_cmd *qc = ata_qc_from_tag(ap, ap->active_tag); - int handled; /* freeze if hotplugged */ if (unlikely(irq_stat & (NV_INT_ADDED | NV_INT_REMOVED))) { @@ -719,13 +718,7 @@ static int nv_host_intr(struct ata_port } /* handle interrupt */ - handled = ata_host_intr(ap, qc); - if (unlikely(!handled)) { - /* spurious, clear it */ - ata_check_status(ap); - } - - return 1; + return ata_host_intr(ap, qc); } static irqreturn_t nv_adma_interrupt(int irq, void *dev_instance) @@ -752,6 +745,11 @@ static irqreturn_t nv_adma_interrupt(int if (pp->flags & NV_ADMA_PORT_REGISTER_MODE) { u8 irq_stat = readb(host->mmio_base + NV_INT_STATUS_CK804) >> (NV_INT_PORT_SHIFT * i); + if(ata_tag_valid(ap->active_tag)) + /** NV_INT_DEV indication seems unreliable at times + at least in ADMA mode. Force it on always when a + command is active, to prevent losing interrupts. */ + irq_stat |= NV_INT_DEV; handled += nv_host_intr(ap, irq_stat); continue; } ^ permalink raw reply [flat|nested] 71+ messages in thread
[parent not found: <fa.1kBz5luWz8nR0lLqm1VD4hZZYdw@ifi.uio.no>]
[parent not found: <fa.QZxgjxcwtENaZNY24NMTlKBSgIM@ifi.uio.no>]
[parent not found: <fa.fkPTbUGmKc/1pt0eD6TE4d02n+Q@ifi.uio.no>]
[parent not found: <fa.6iQt5OtHZ3x5w8eYbLxwULhLTJ0@ifi.uio.no>]
[parent not found: <fa.1aqo3IxNGJClHcBVZNTagX6bL9o@ifi.uio.no>]
[parent not found: <fa.rI60BGlFbSyfLyumqmgiOfDqCI4@ifi.uio.no>]
* Re: SATA exceptions with 2.6.20-rc5 [not found] ` <fa.rI60BGlFbSyfLyumqmgiOfDqCI4@ifi.uio.no> @ 2007-01-23 23:18 ` Robert Hancock 2007-01-24 0:39 ` Björn Steinbrink 2007-01-24 8:24 ` Ian Kumlien 0 siblings, 2 replies; 71+ messages in thread From: Robert Hancock @ 2007-01-23 23:18 UTC (permalink / raw) To: linux-kernel Cc: Larry Walton, B.Steinbrink, s0348365, pomac, chunkeey, Jeff Garzik Larry Walton wrote: > The last patch (sata_nv-force-int-dev-in-interrupt.patch) > seems to have fix the problem. Much appreciated, > thank you. I'd consider it a must have in 2.6.20. Can any of the rest of you that have been seeing this problem also confirm that this fixes it? -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/ ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-23 23:18 ` Robert Hancock @ 2007-01-24 0:39 ` Björn Steinbrink 2007-02-03 1:42 ` Björn Steinbrink 2007-01-24 8:24 ` Ian Kumlien 1 sibling, 1 reply; 71+ messages in thread From: Björn Steinbrink @ 2007-01-24 0:39 UTC (permalink / raw) To: Robert Hancock Cc: linux-kernel, Larry Walton, s0348365, pomac, chunkeey, Jeff Garzik On 2007.01.23 17:18:43 -0600, Robert Hancock wrote: > Larry Walton wrote: > >The last patch (sata_nv-force-int-dev-in-interrupt.patch) > >seems to have fix the problem. Much appreciated, > >thank you. I'd consider it a must have in 2.6.20. > > Can any of the rest of you that have been seeing this problem also > confirm that this fixes it? Seems to work for me, uptime is about an hour now and no exception yet. Had the stress test running for only about 10 minutes, but I usually got an exception within an hour even during plain irssi usage, so I'm quite confident that the patch fixes it. Thanks, Björn ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-24 0:39 ` Björn Steinbrink @ 2007-02-03 1:42 ` Björn Steinbrink 2007-02-03 5:48 ` Robert Hancock 0 siblings, 1 reply; 71+ messages in thread From: Björn Steinbrink @ 2007-02-03 1:42 UTC (permalink / raw) To: Robert Hancock, linux-kernel, Larry Walton, s0348365, pomac, chunkeey, Jeff Garzik On 2007.01.24 01:39:23 +0100, Björn Steinbrink wrote: > On 2007.01.23 17:18:43 -0600, Robert Hancock wrote: > > Larry Walton wrote: > > >The last patch (sata_nv-force-int-dev-in-interrupt.patch) > > >seems to have fix the problem. Much appreciated, > > >thank you. I'd consider it a must have in 2.6.20. > > > > Can any of the rest of you that have been seeing this problem also > > confirm that this fixes it? > > Seems to work for me, uptime is about an hour now and no exception yet. > Had the stress test running for only about 10 minutes, but I usually got > an exception within an hour even during plain irssi usage, so I'm quite > confident that the patch fixes it. Or maybe not :( Just got an exception on 2.6.20-rc6. Took 4 days of uptime to trigger, so it's just a lot harder to trigger now. Björn ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-02-03 1:42 ` Björn Steinbrink @ 2007-02-03 5:48 ` Robert Hancock 2007-02-04 1:13 ` Björn Steinbrink 0 siblings, 1 reply; 71+ messages in thread From: Robert Hancock @ 2007-02-03 5:48 UTC (permalink / raw) To: Björn Steinbrink, Robert Hancock, linux-kernel, Larry Walton, s0348365, pomac, chunkeey, Jeff Garzik Björn Steinbrink wrote: > On 2007.01.24 01:39:23 +0100, Björn Steinbrink wrote: >> On 2007.01.23 17:18:43 -0600, Robert Hancock wrote: >>> Larry Walton wrote: >>>> The last patch (sata_nv-force-int-dev-in-interrupt.patch) >>>> seems to have fix the problem. Much appreciated, >>>> thank you. I'd consider it a must have in 2.6.20. >>> Can any of the rest of you that have been seeing this problem also >>> confirm that this fixes it? >> Seems to work for me, uptime is about an hour now and no exception yet. >> Had the stress test running for only about 10 minutes, but I usually got >> an exception within an hour even during plain irssi usage, so I'm quite >> confident that the patch fixes it. > > Or maybe not :( Just got an exception on 2.6.20-rc6. Took 4 days of > uptime to trigger, so it's just a lot harder to trigger now. Same exception details as before? There's a patch in -mm (sata_nv-use-adma-for-nodata-commands.patch) which should hopefully avoid this problem for the cache flush commands, at least - can you try that one out? You'll have to apply the other sata_nv patches in -mm first, i.e. this order: http://www2.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/2.6.20-rc6-mm3/broken-out/sata_nv-cleanup-adma-error-handling-v2.patch http://www2.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/2.6.20-rc6-mm3/broken-out/sata_nv-cleanup-adma-error-handling-v2-cleanup.patch http://www2.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/2.6.20-rc6-mm3/broken-out/sata_nv-use-adma-for-nodata-commands.patch -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/ ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-02-03 5:48 ` Robert Hancock @ 2007-02-04 1:13 ` Björn Steinbrink 2007-02-09 12:03 ` Björn Steinbrink 0 siblings, 1 reply; 71+ messages in thread From: Björn Steinbrink @ 2007-02-04 1:13 UTC (permalink / raw) To: Robert Hancock Cc: linux-kernel, Larry Walton, s0348365, pomac, chunkeey, Jeff Garzik On 2007.02.02 23:48:14 -0600, Robert Hancock wrote: > Björn Steinbrink wrote: > >On 2007.01.24 01:39:23 +0100, Björn Steinbrink wrote: > >>On 2007.01.23 17:18:43 -0600, Robert Hancock wrote: > >>>Larry Walton wrote: > >>>>The last patch (sata_nv-force-int-dev-in-interrupt.patch) > >>>>seems to have fix the problem. Much appreciated, > >>>>thank you. I'd consider it a must have in 2.6.20. > >>>Can any of the rest of you that have been seeing this problem also > >>>confirm that this fixes it? > >>Seems to work for me, uptime is about an hour now and no exception yet. > >>Had the stress test running for only about 10 minutes, but I usually got > >>an exception within an hour even during plain irssi usage, so I'm quite > >>confident that the patch fixes it. > > > >Or maybe not :( Just got an exception on 2.6.20-rc6. Took 4 days of > >uptime to trigger, so it's just a lot harder to trigger now. > > Same exception details as before? Yes, exactly the same. > There's a patch in -mm (sata_nv-use-adma-for-nodata-commands.patch) > which should hopefully avoid this problem for the cache flush commands, > at least - can you try that one out? You'll have to apply the other > sata_nv patches in -mm first, i.e. this order: > > http://www2.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/2.6.20-rc6-mm3/broken-out/sata_nv-cleanup-adma-error-handling-v2.patch > http://www2.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/2.6.20-rc6-mm3/broken-out/sata_nv-cleanup-adma-error-handling-v2-cleanup.patch > http://www2.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/2.6.20-rc6-mm3/broken-out/sata_nv-use-adma-for-nodata-commands.patch Got 2.6.20-rc7 with them applied now (the rejects seemed trivial enough for me to fix them). Let's see how that works out... Björn ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-02-04 1:13 ` Björn Steinbrink @ 2007-02-09 12:03 ` Björn Steinbrink 0 siblings, 0 replies; 71+ messages in thread From: Björn Steinbrink @ 2007-02-09 12:03 UTC (permalink / raw) To: Robert Hancock, linux-kernel, Larry Walton, s0348365, pomac, chunkeey, Jeff Garzik On 2007.02.04 02:13:51 +0100, Björn Steinbrink wrote: > On 2007.02.02 23:48:14 -0600, Robert Hancock wrote: > > There's a patch in -mm (sata_nv-use-adma-for-nodata-commands.patch) > > which should hopefully avoid this problem for the cache flush commands, > > at least - can you try that one out? You'll have to apply the other > > sata_nv patches in -mm first, i.e. this order: > > > > http://www2.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/2.6.20-rc6-mm3/broken-out/sata_nv-cleanup-adma-error-handling-v2.patch > > http://www2.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/2.6.20-rc6-mm3/broken-out/sata_nv-cleanup-adma-error-handling-v2-cleanup.patch > > http://www2.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/2.6.20-rc6-mm3/broken-out/sata_nv-use-adma-for-nodata-commands.patch > > Got 2.6.20-rc7 with them applied now (the rejects seemed trivial enough > for me to fix them). Let's see how that works out... After about 1.5 days of uptime, an involuntary reboot and another 3 days of uptime, no sign of an exception. No stress testing was done, but a few disk intensive actions did happen, at least more than with that -rc6 that did throw an exception at me. Björn ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-23 23:18 ` Robert Hancock 2007-01-24 0:39 ` Björn Steinbrink @ 2007-01-24 8:24 ` Ian Kumlien 2007-01-24 14:41 ` Björn Steinbrink 1 sibling, 1 reply; 71+ messages in thread From: Ian Kumlien @ 2007-01-24 8:24 UTC (permalink / raw) To: Robert Hancock Cc: linux-kernel, Larry Walton, B.Steinbrink, s0348365, chunkeey, Jeff Garzik [-- Attachment #1: Type: text/plain, Size: 1197 bytes --] On tis, 2007-01-23 at 17:18 -0600, Robert Hancock wrote: > Larry Walton wrote: > > The last patch (sata_nv-force-int-dev-in-interrupt.patch) > > seems to have fix the problem. Much appreciated, > > thank you. I'd consider it a must have in 2.6.20. > > Can any of the rest of you that have been seeing this problem also > confirm that this fixes it? I applied it yesterday and today my dmesg contains three: BUG: at mm/truncate.c:60 cancel_dirty_page() Call Trace: [<ffffffff8029f3e5>] cancel_dirty_page+0x43/0x71 [<ffffffff802ec1ab>] reiserfs_cut_from_item+0x5f8/0x61d [<ffffffff802074fc>] find_get_page+0x21/0x47 [<ffffffff802ec51d>] reiserfs_do_truncate+0x34d/0x495 [<ffffffff802d9d47>] reiserfs_truncate_file+0x199/0x2aa [<ffffffff802df9c5>] reiserfs_file_release+0x261/0x281 [<ffffffff80211b02>] __fput+0xb1/0x17d [<ffffffff802218e0>] filp_close+0x5d/0x65 [<ffffffff8021bef5>] sys_close+0x8c/0xcf [<ffffffff8025725e>] system_call+0x7e/0x83 Which never happened before... I dunno if they are related though, but they weren't there before... (It does fix the timeout problem) -- Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-24 8:24 ` Ian Kumlien @ 2007-01-24 14:41 ` Björn Steinbrink 0 siblings, 0 replies; 71+ messages in thread From: Björn Steinbrink @ 2007-01-24 14:41 UTC (permalink / raw) To: Ian Kumlien Cc: Robert Hancock, linux-kernel, Larry Walton, s0348365, chunkeey, Jeff Garzik On 2007.01.24 09:24:00 +0100, Ian Kumlien wrote: > On tis, 2007-01-23 at 17:18 -0600, Robert Hancock wrote: > > Larry Walton wrote: > > > The last patch (sata_nv-force-int-dev-in-interrupt.patch) > > > seems to have fix the problem. Much appreciated, > > > thank you. I'd consider it a must have in 2.6.20. > > > > Can any of the rest of you that have been seeing this problem also > > confirm that this fixes it? > > I applied it yesterday and today my dmesg contains three: > BUG: at mm/truncate.c:60 cancel_dirty_page() David Chinner sent two patches regarding that bug yesterday. http://lkml.org/lkml/2007/1/23/190 http://lkml.org/lkml/2007/1/23/192 Björn ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 @ 2007-01-20 15:03 Ian Kumlien 2007-01-20 19:59 ` Robert Hancock 0 siblings, 1 reply; 71+ messages in thread From: Ian Kumlien @ 2007-01-20 15:03 UTC (permalink / raw) To: Linux-kernel; +Cc: hancockr, jeff, B.Steinbrink [-- Attachment #1: Type: text/plain, Size: 330 bytes --] Hi, I went from 2.6.19+sata_nv-adma-ncq-v7.patch, with no problems and adama enabled, to 2.6.20-rc5, which gave me problems almost instantly. I just thought that it might be interesting to know that it DID work nicely. CC since i'm not on the ml -- Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-20 15:03 Ian Kumlien @ 2007-01-20 19:59 ` Robert Hancock 2007-01-20 21:43 ` Alistair John Strachan 0 siblings, 1 reply; 71+ messages in thread From: Robert Hancock @ 2007-01-20 19:59 UTC (permalink / raw) To: pomac; +Cc: Linux-kernel, jeff, B.Steinbrink, s0348365, chunkeey Ian Kumlien wrote: > Hi, > > I went from 2.6.19+sata_nv-adma-ncq-v7.patch, with no problems and adama > enabled, to 2.6.20-rc5, which gave me problems almost instantly. > > I just thought that it might be interesting to know that it DID work > nicely. > > CC since i'm not on the ml > (I'm ccing more of the people who reported this) Well that's interesting.. The only significant change that went into 2.6.20-rc5 in that driver that wasn't in that version you mentioned was this one: http://www2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2dec7555e6bf2772749113ea0ad454fcdb8cf861 Could you (or anyone else) test what happens if you take the 2.6.20-rc5 version of sata_nv.c and try it on 2.6.19? That would tell us whether it's this change or whether it's something else (i.e. in libata core). Assuming that still doesn't work, can you then try removing these lines from nv_host_intr in 2.6.20-rc5 sata_nv.c and see what that does? /* bail out if not our interrupt */ if (!(irq_stat & NV_INT_DEV)) return 0; as that's the difference I'm most suspicious of causing the problem. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/ ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-20 19:59 ` Robert Hancock @ 2007-01-20 21:43 ` Alistair John Strachan 2007-01-20 22:11 ` Ian Kumlien 0 siblings, 1 reply; 71+ messages in thread From: Alistair John Strachan @ 2007-01-20 21:43 UTC (permalink / raw) To: Robert Hancock; +Cc: pomac, Linux-kernel, jeff, B.Steinbrink, chunkeey On Saturday 20 January 2007 19:59, Robert Hancock wrote: > Ian Kumlien wrote: > > Hi, > > > > I went from 2.6.19+sata_nv-adma-ncq-v7.patch, with no problems and adama > > enabled, to 2.6.20-rc5, which gave me problems almost instantly. > > > > I just thought that it might be interesting to know that it DID work > > nicely. > > > > CC since i'm not on the ml > > (I'm ccing more of the people who reported this) > > Well that's interesting.. The only significant change that went into > 2.6.20-rc5 in that driver that wasn't in that version you mentioned was > this one: > > http://www2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=com >mit;h=2dec7555e6bf2772749113ea0ad454fcdb8cf861 > > Could you (or anyone else) test what happens if you take the 2.6.20-rc5 > version of sata_nv.c and try it on 2.6.19? That would tell us whether > it's this change or whether it's something else (i.e. in libata core). I'm still running an -rc5 kernel with ADMA switched off entirely and I can't reproduce the problem. How is everybody else reproducing this? I've been successful installing bonnie++, then going to a large XFS partition and running "bonnie++ -u 1000:1000" and letting it run through, all defaults. It doesn't cause the problem I was seeing in -rc5 with ADMA on, when I switch ADMA off, so I think this is sufficient to fix it. Others have reported differently. Did you guys do: alistair@damocles:~$ cat /proc/cmdline root=/dev/sda1 ro sata_nv.adma=0 Or something similar? This is how Jeff suggested disabling ADMA and indeed the messages about its use disappear from dmesg. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-20 21:43 ` Alistair John Strachan @ 2007-01-20 22:11 ` Ian Kumlien 0 siblings, 0 replies; 71+ messages in thread From: Ian Kumlien @ 2007-01-20 22:11 UTC (permalink / raw) To: Alistair John Strachan Cc: Robert Hancock, Linux-kernel, jeff, B.Steinbrink, chunkeey [-- Attachment #1: Type: text/plain, Size: 2278 bytes --] On lör, 2007-01-20 at 21:43 +0000, Alistair John Strachan wrote: > On Saturday 20 January 2007 19:59, Robert Hancock wrote: > > Ian Kumlien wrote: > > > Hi, > > > > > > I went from 2.6.19+sata_nv-adma-ncq-v7.patch, with no problems and adama > > > enabled, to 2.6.20-rc5, which gave me problems almost instantly. > > > > > > I just thought that it might be interesting to know that it DID work > > > nicely. > > > > > > CC since i'm not on the ml > > > > (I'm ccing more of the people who reported this) > > > > Well that's interesting.. The only significant change that went into > > 2.6.20-rc5 in that driver that wasn't in that version you mentioned was > > this one: > > > > http://www2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=com > >mit;h=2dec7555e6bf2772749113ea0ad454fcdb8cf861 > > > > Could you (or anyone else) test what happens if you take the 2.6.20-rc5 > > version of sata_nv.c and try it on 2.6.19? That would tell us whether > > it's this change or whether it's something else (i.e. in libata core). > > I'm still running an -rc5 kernel with ADMA switched off entirely and I can't > reproduce the problem. How is everybody else reproducing this? > > I've been successful installing bonnie++, then going to a large XFS partition > and running "bonnie++ -u 1000:1000" and letting it run through, all defaults. > > It doesn't cause the problem I was seeing in -rc5 with ADMA on, when I switch > ADMA off, so I think this is sufficient to fix it. Eh? The whole point with that patch was to ADD ADMA support to sata_nv, imho that is something we want to have and i have been running with ADMA on on two computers since sata_nv-adma-ncq-v4 or 5 or so without problems. So, something has been introduced or been broken to cause this error, wouldn't it be better to find the error introduced than to just totally negate the patch in the first place? I haven't had the energy to go trough the patch that was found as causing the problem yet... I don't know if i even have all the info needed to make any form of educated guess but i'll give it a try when i have the energy. I really home someone finds it before then =) -- Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 71+ messages in thread
[parent not found: <fa.U/G88R1fWKOeQK3EBPHKK4MeRsQ@ifi.uio.no>]
[parent not found: <fa.2D0TIXbVTOgZmGg9ZJU+R7te70k@ifi.uio.no>]
[parent not found: <fa.hMhdefkReYJ4idUyqqEWJFnWUBE@ifi.uio.no>]
[parent not found: <fa.8TPWeOrcwkkHutPX5NOcJsTBO8Y@ifi.uio.no>]
[parent not found: <fa.b92BqwV090pDj7q0iBG6BChksbI@ifi.uio.no>]
[parent not found: <fa.O3RzvckSjB73Y0uL8P1nTXDRd6U@ifi.uio.no>]
* Re: SATA exceptions with 2.6.20-rc5 [not found] ` <fa.O3RzvckSjB73Y0uL8P1nTXDRd6U@ifi.uio.no> @ 2007-01-19 0:09 ` Robert Hancock 2007-01-19 0:52 ` Björn Steinbrink 0 siblings, 1 reply; 71+ messages in thread From: Robert Hancock @ 2007-01-19 0:09 UTC (permalink / raw) To: linux-kernel Cc: Larry Walton, Björn Steinbrink, jeff, htejun, jens.axboe I heard from Larry Walton who was apparently seeing this problem as well. He tried my recent "sata_nv: cleanup ADMA error handling v2" patch and originally thought it fixed the problem, but it turned out to only make it happen less often. I wouldn't expect that patch to have an effect on this problem. If it seems to reduce the frequency that would tend to be further evidence of some kind of timing-related issue where the code change just happens to make a difference. I'll see if I can come up with a debug patch for people having this problem to try, which prints out when a flush command is issued and what interrupts happen when a flush is pending. There is one important difference between ADMA and non-ADMA mode for non-DMA commands like flushes, which didn't come to mind before: ADMA mode uses MMIO registers on the controller whereas non-ADMA mode uses legacy IO registers. Posted write flushing is a concern with MMIO registers but not with PIO, the libata core is supposed to handle this but maybe it doesn't in some case(s). In fact, just looking at libata-sff.c there's this comment on the ata_exec_command_mmio function: * FIXME: missing write posting for 400nS delay enforcement That seems a bit suspicious.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/ ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-19 0:09 ` Robert Hancock @ 2007-01-19 0:52 ` Björn Steinbrink 0 siblings, 0 replies; 71+ messages in thread From: Björn Steinbrink @ 2007-01-19 0:52 UTC (permalink / raw) To: Robert Hancock; +Cc: linux-kernel, Larry Walton, jeff, htejun, jens.axboe On 2007.01.18 18:09:50 -0600, Robert Hancock wrote: > I heard from Larry Walton who was apparently seeing this problem as > well. He tried my recent "sata_nv: cleanup ADMA error handling v2" patch > and originally thought it fixed the problem, but it turned out to only > make it happen less often. > > I wouldn't expect that patch to have an effect on this problem. If it > seems to reduce the frequency that would tend to be further evidence of > some kind of timing-related issue where the code change just happens > to make a difference. > > I'll see if I can come up with a debug patch for people having this > problem to try, which prints out when a flush command is issued and what > interrupts happen when a flush is pending. > > There is one important difference between ADMA and non-ADMA mode for > non-DMA commands like flushes, which didn't come to mind before: ADMA > mode uses MMIO registers on the controller whereas non-ADMA mode uses > legacy IO registers. Posted write flushing is a concern with MMIO > registers but not with PIO, the libata core is supposed to handle this > but maybe it doesn't in some case(s). In fact, just looking at > libata-sff.c there's this comment on the ata_exec_command_mmio function: > > * FIXME: missing write posting for 400nS delay enforcement > > That seems a bit suspicious.. That would imply that disabling adma via a module parameter should make the issue go away, right? I'll try to have a test run with adma disabled over night then. Thanks, Björn ^ permalink raw reply [flat|nested] 71+ messages in thread
[parent not found: <fa.hif5u4ZXua+b0mVNaWEcItWv9i0@ifi.uio.no>]
* Re: SATA exceptions with 2.6.20-rc5 [not found] <fa.hif5u4ZXua+b0mVNaWEcItWv9i0@ifi.uio.no> @ 2007-01-14 23:43 ` Robert Hancock 2007-01-15 0:22 ` Jeff Garzik 2007-01-15 21:17 ` Björn Steinbrink 0 siblings, 2 replies; 71+ messages in thread From: Robert Hancock @ 2007-01-14 23:43 UTC (permalink / raw) To: Björn Steinbrink, jeff, linux-kernel, htejun Björn Steinbrink wrote: > Hi, > > with 2.6.20-rc{2,4,5} (no other tested yet) I see SATA exceptions quite > often, with 2.6.19 there are no such exceptions. dmesg and lspci -v > output follows. In the meantime, I'll start bisecting. ... > ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen > ata1.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 in > res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) > 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: 160086528 512-byte hdwr sectors (81964 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 Looks like all of these errors are from a FLUSH CACHE command and the drive is indicating that it is no longer busy, so presumably done. That's not a DMA-mapped command, so it wouldn't go through the ADMA machinery and I wouldn't have expected this to be handled any differently from before. Curious.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/ ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-14 23:43 ` Robert Hancock @ 2007-01-15 0:22 ` Jeff Garzik 2007-01-15 0:34 ` Björn Steinbrink 2007-01-15 2:25 ` Robert Hancock 2007-01-15 21:17 ` Björn Steinbrink 1 sibling, 2 replies; 71+ messages in thread From: Jeff Garzik @ 2007-01-15 0:22 UTC (permalink / raw) To: Robert Hancock; +Cc: Björn Steinbrink, linux-kernel, htejun Robert Hancock wrote: > Björn Steinbrink wrote: >> Hi, >> >> with 2.6.20-rc{2,4,5} (no other tested yet) I see SATA exceptions quite >> often, with 2.6.19 there are no such exceptions. dmesg and lspci -v >> output follows. In the meantime, I'll start bisecting. > > ... > >> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen >> ata1.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 in >> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) >> 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: 160086528 512-byte hdwr sectors (81964 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 > > Looks like all of these errors are from a FLUSH CACHE command and the > drive is indicating that it is no longer busy, so presumably done. > That's not a DMA-mapped command, so it wouldn't go through the ADMA > machinery and I wouldn't have expected this to be handled any > differently from before. Curious.. It's possible the flush-cache command takes longer than 30 seconds, if the cache is large, contents are discontiguous, etc. It's a pathological case, but possible. Or maybe flush-cache doesn't get a 30 second timeout, and it should...? (thinking out loud) Jeff ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-15 0:22 ` Jeff Garzik @ 2007-01-15 0:34 ` Björn Steinbrink 2007-01-15 2:47 ` Björn Steinbrink 2007-01-15 2:25 ` Robert Hancock 1 sibling, 1 reply; 71+ messages in thread From: Björn Steinbrink @ 2007-01-15 0:34 UTC (permalink / raw) To: Jeff Garzik; +Cc: Robert Hancock, linux-kernel, htejun On 2007.01.14 19:22:51 -0500, Jeff Garzik wrote: > Robert Hancock wrote: > >Björn Steinbrink wrote: > >>Hi, > >> > >>with 2.6.20-rc{2,4,5} (no other tested yet) I see SATA exceptions quite > >>often, with 2.6.19 there are no such exceptions. dmesg and lspci -v > >>output follows. In the meantime, I'll start bisecting. > > > >... > > > >>ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen > >>ata1.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 in > >> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) > >>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: 160086528 512-byte hdwr sectors (81964 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 > > > >Looks like all of these errors are from a FLUSH CACHE command and the > >drive is indicating that it is no longer busy, so presumably done. > >That's not a DMA-mapped command, so it wouldn't go through the ADMA > >machinery and I wouldn't have expected this to be handled any > >differently from before. Curious.. > > It's possible the flush-cache command takes longer than 30 seconds, if > the cache is large, contents are discontiguous, etc. It's a > pathological case, but possible. > > Or maybe flush-cache doesn't get a 30 second timeout, and it should...? > (thinking out loud) Bi-section led to commit 249e83fe839 which makes absolutely no sense to me, just in case that anyone sees any problem with that commit. I'll go and re-check a few of those commits that I marked as good. Björn ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-15 0:34 ` Björn Steinbrink @ 2007-01-15 2:47 ` Björn Steinbrink 0 siblings, 0 replies; 71+ messages in thread From: Björn Steinbrink @ 2007-01-15 2:47 UTC (permalink / raw) To: Jeff Garzik, Robert Hancock, linux-kernel, htejun On 2007.01.15 01:34:48 +0100, Björn Steinbrink wrote: > On 2007.01.14 19:22:51 -0500, Jeff Garzik wrote: > > Robert Hancock wrote: > > >Björn Steinbrink wrote: > > >>Hi, > > >> > > >>with 2.6.20-rc{2,4,5} (no other tested yet) I see SATA exceptions quite > > >>often, with 2.6.19 there are no such exceptions. dmesg and lspci -v > > >>output follows. In the meantime, I'll start bisecting. > > > > > >... > > > > > >>ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen > > >>ata1.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 in > > >> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) > > >>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: 160086528 512-byte hdwr sectors (81964 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 > > > > > >Looks like all of these errors are from a FLUSH CACHE command and the > > >drive is indicating that it is no longer busy, so presumably done. > > >That's not a DMA-mapped command, so it wouldn't go through the ADMA > > >machinery and I wouldn't have expected this to be handled any > > >differently from before. Curious.. > > > > It's possible the flush-cache command takes longer than 30 seconds, if > > the cache is large, contents are discontiguous, etc. It's a > > pathological case, but possible. > > > > Or maybe flush-cache doesn't get a 30 second timeout, and it should...? > > (thinking out loud) > > Bi-section led to commit 249e83fe839 which makes absolutely no sense to > me, just in case that anyone sees any problem with that commit. > I'll go and re-check a few of those commits that I marked as good. Next round of bisecting led to another useless result, a) it was an unrelated driver, b) the kernel I just marked as good after 20 minutes of testing decided to fail when I hit reply... Guess that it was pure luck that the kernel I marked as bad failed within 1-2 minutes. I send the git bisect log with this mail, maybe at least the early good kernel are really good and someone can make some sense out of it. At least I ended up somewhere in a series of libata changes. Thanks, Björn git-bisect start # bad: [8a2d17a56a71c5c796b0a5378ee76a105f21fdd9] Linux 2.6.20-rc2 git-bisect bad 8a2d17a56a71c5c796b0a5378ee76a105f21fdd9 # good: [c3fe6924620fd733ffe8bc8a9da1e9cde08402b3] Linux 2.6.19 git-bisect good c3fe6924620fd733ffe8bc8a9da1e9cde08402b3 # bad: [2685b267bce34c9b66626cb11664509c32a761a5] Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 git-bisect bad 2685b267bce34c9b66626cb11664509c32a761a5 # good: [a985239bdf017e00e985c3a31149d6ae128fdc5f] [POWERPC] cell: spu management xmon routines git-bisect good a985239bdf017e00e985c3a31149d6ae128fdc5f # bad: [33f2ef89f8e181486b63fdbdc97c6afa6ca9f34b] mm: make compound page destructor handling explicit git-bisect bad 33f2ef89f8e181486b63fdbdc97c6afa6ca9f34b # bad: [651857a1ecaf97a8ad9d324dd2a61675c53e541e] Merge branch 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mfasheh/ocfs2 git-bisect bad 651857a1ecaf97a8ad9d324dd2a61675c53e541e # bad: [ff51a98799931256b555446b2f5675db08de6229] Merge branch 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev git-bisect bad ff51a98799931256b555446b2f5675db08de6229 # bad: [3ac551a6a63dcbc707348772a27bd7090b081524] [libata] pata_cs5535: fix build git-bisect bad 3ac551a6a63dcbc707348772a27bd7090b081524 # good: [750426aa1ad1ddd1fa8bb4ed531a7956f3b9a27c] libata: cosmetic changes to sense generation functions git-bisect good 750426aa1ad1ddd1fa8bb4ed531a7956f3b9a27c # good: [62d64ae0ec76360736c9dc4ca2067ae8de0ba9f2] pata : more drivers that need only standard suspend and resume git-bisect good 62d64ae0ec76360736c9dc4ca2067ae8de0ba9f2 # good: [6a36261e63770ab61422550b774fe949ccca5fa9] libata: fix READ CAPACITY simulation git-bisect good 6a36261e63770ab61422550b774fe949ccca5fa9 # good: [2432697ba0ce312d60be5009ffe1fa054a761bb9] libata: implement ata_exec_internal_sg() git-bisect good 2432697ba0ce312d60be5009ffe1fa054a761bb9 # good: [70e6ad0c6d1e6cb9ee3c036a85ca2561eb1fd766] libata: prepare ata_sg_clean() for invocation from EH git-bisect good 70e6ad0c6d1e6cb9ee3c036a85ca2561eb1fd766 # good: [8e16f941226f15622fbbc416a1f3d8705001a191] ahci: do not powerdown during initialization git-bisect good 8e16f941226f15622fbbc416a1f3d8705001a191 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-15 0:22 ` Jeff Garzik 2007-01-15 0:34 ` Björn Steinbrink @ 2007-01-15 2:25 ` Robert Hancock 2007-01-15 2:53 ` Jens Axboe 1 sibling, 1 reply; 71+ messages in thread From: Robert Hancock @ 2007-01-15 2:25 UTC (permalink / raw) To: Jeff Garzik; +Cc: Björn Steinbrink, linux-kernel, htejun Jeff Garzik wrote: >> Looks like all of these errors are from a FLUSH CACHE command and the >> drive is indicating that it is no longer busy, so presumably done. >> That's not a DMA-mapped command, so it wouldn't go through the ADMA >> machinery and I wouldn't have expected this to be handled any >> differently from before. Curious.. > > It's possible the flush-cache command takes longer than 30 seconds, if > the cache is large, contents are discontiguous, etc. It's a > pathological case, but possible. > > Or maybe flush-cache doesn't get a 30 second timeout, and it should...? > (thinking out loud) > > Jeff If the flush was still in progress I would expect Busy to still be set, however.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/ ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-15 2:25 ` Robert Hancock @ 2007-01-15 2:53 ` Jens Axboe 2007-01-15 13:42 ` Jeff Garzik 0 siblings, 1 reply; 71+ messages in thread From: Jens Axboe @ 2007-01-15 2:53 UTC (permalink / raw) To: Robert Hancock; +Cc: Jeff Garzik, Björn Steinbrink, linux-kernel, htejun On Sun, Jan 14 2007, Robert Hancock wrote: > Jeff Garzik wrote: > >>Looks like all of these errors are from a FLUSH CACHE command and the > >>drive is indicating that it is no longer busy, so presumably done. > >>That's not a DMA-mapped command, so it wouldn't go through the ADMA > >>machinery and I wouldn't have expected this to be handled any > >>differently from before. Curious.. > > > >It's possible the flush-cache command takes longer than 30 seconds, if > >the cache is large, contents are discontiguous, etc. It's a > >pathological case, but possible. > > > >Or maybe flush-cache doesn't get a 30 second timeout, and it should...? > > (thinking out loud) > > > > Jeff > > If the flush was still in progress I would expect Busy to still be set, > however.. I'd be surprised if the device would not obey the 7 second timeout rule that seems to be set in stone and not allow more dirty in-drive cache than it could flush out in approximately that time. And BUSY should also be set for that case, as Robert indicates. -- Jens Axboe ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-15 2:53 ` Jens Axboe @ 2007-01-15 13:42 ` Jeff Garzik 2007-01-16 0:23 ` Jens Axboe 0 siblings, 1 reply; 71+ messages in thread From: Jeff Garzik @ 2007-01-15 13:42 UTC (permalink / raw) To: Jens Axboe; +Cc: Robert Hancock, Björn Steinbrink, linux-kernel, htejun Jens Axboe wrote: > I'd be surprised if the device would not obey the 7 second timeout rule > that seems to be set in stone and not allow more dirty in-drive cache > than it could flush out in approximately that time. AFAIK Windows flush-cache timeout is 30 seconds, not 7 as with other commands... > And BUSY should also be set for that case, as Robert indicates. Agreed. Jeff ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-15 13:42 ` Jeff Garzik @ 2007-01-16 0:23 ` Jens Axboe 2007-01-16 0:36 ` Robert Hancock 2007-01-16 1:51 ` Jeff Garzik 0 siblings, 2 replies; 71+ messages in thread From: Jens Axboe @ 2007-01-16 0:23 UTC (permalink / raw) To: Jeff Garzik; +Cc: Robert Hancock, Björn Steinbrink, linux-kernel, htejun On Mon, Jan 15 2007, Jeff Garzik wrote: > Jens Axboe wrote: > >I'd be surprised if the device would not obey the 7 second timeout rule > >that seems to be set in stone and not allow more dirty in-drive cache > >than it could flush out in approximately that time. > > AFAIK Windows flush-cache timeout is 30 seconds, not 7 as with other > commands... Ok, 7 seconds for FLUSH_CACHE would have been nice for us too though, as it would pretty much guarentee lower latencies for random writes and write back caching. The concern is the barrier code, of course. I guess I should do some timings on potential worst case patterns some day. Alan may have done that sometime in the past, iirc. -- Jens Axboe ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-16 0:23 ` Jens Axboe @ 2007-01-16 0:36 ` Robert Hancock 2007-01-16 1:51 ` Jeff Garzik 2007-01-16 1:51 ` Jeff Garzik 1 sibling, 1 reply; 71+ messages in thread From: Robert Hancock @ 2007-01-16 0:36 UTC (permalink / raw) To: Jens Axboe; +Cc: Jeff Garzik, Björn Steinbrink, linux-kernel, htejun Jens Axboe wrote: > On Mon, Jan 15 2007, Jeff Garzik wrote: >> Jens Axboe wrote: >>> I'd be surprised if the device would not obey the 7 second timeout rule >>> that seems to be set in stone and not allow more dirty in-drive cache >>> than it could flush out in approximately that time. >> AFAIK Windows flush-cache timeout is 30 seconds, not 7 as with other >> commands... > > Ok, 7 seconds for FLUSH_CACHE would have been nice for us too though, as > it would pretty much guarentee lower latencies for random writes and > write back caching. The concern is the barrier code, of course. I guess > I should do some timings on potential worst case patterns some day. Alan > may have done that sometime in the past, iirc. > Note that the ATA-7 spec for FLUSH CACHE says that "This command may take longer than 30 s to complete." -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/ ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-16 0:36 ` Robert Hancock @ 2007-01-16 1:51 ` Jeff Garzik 0 siblings, 0 replies; 71+ messages in thread From: Jeff Garzik @ 2007-01-16 1:51 UTC (permalink / raw) To: Robert Hancock; +Cc: Jens Axboe, Björn Steinbrink, linux-kernel, htejun Robert Hancock wrote: > Note that the ATA-7 spec for FLUSH CACHE says that "This command may > take longer than 30 s to complete." Yep... Jeff ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-16 0:23 ` Jens Axboe 2007-01-16 0:36 ` Robert Hancock @ 2007-01-16 1:51 ` Jeff Garzik 2007-01-22 18:17 ` Eric D. Mudama 1 sibling, 1 reply; 71+ messages in thread From: Jeff Garzik @ 2007-01-16 1:51 UTC (permalink / raw) To: Jens Axboe; +Cc: Robert Hancock, Björn Steinbrink, linux-kernel, htejun Jens Axboe wrote: > On Mon, Jan 15 2007, Jeff Garzik wrote: >> Jens Axboe wrote: >>> I'd be surprised if the device would not obey the 7 second timeout rule >>> that seems to be set in stone and not allow more dirty in-drive cache >>> than it could flush out in approximately that time. >> AFAIK Windows flush-cache timeout is 30 seconds, not 7 as with other >> commands... > > Ok, 7 seconds for FLUSH_CACHE would have been nice for us too though, as > it would pretty much guarentee lower latencies for random writes and > write back caching. The concern is the barrier code, of course. I guess > I should do some timings on potential worst case patterns some day. Alan > may have done that sometime in the past, iirc. FWIW: According to the drive guys (Eric M, among others), FLUSH CACHE will "probably" be under 30 seconds, but pathological cases might even extend beyond that. Definitely more than 7 seconds in less-than-pathological cases, unfortunately... The SCSI layer /should/ already take this (30 second timeout) into account, for SYNCHRONIZE CACHE (and thus FLUSH CACHE for libata) but I'm too slack to check at the moment. Jeff ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-16 1:51 ` Jeff Garzik @ 2007-01-22 18:17 ` Eric D. Mudama 0 siblings, 0 replies; 71+ messages in thread From: Eric D. Mudama @ 2007-01-22 18:17 UTC (permalink / raw) To: Jeff Garzik Cc: Jens Axboe, Robert Hancock, Björn Steinbrink, linux-kernel, htejun On 1/15/07, Jeff Garzik <jeff@garzik.org> wrote: > Jens Axboe wrote: > > On Mon, Jan 15 2007, Jeff Garzik wrote: > >> Jens Axboe wrote: > >>> I'd be surprised if the device would not obey the 7 second timeout rule > >>> that seems to be set in stone and not allow more dirty in-drive cache > >>> than it could flush out in approximately that time. > >> AFAIK Windows flush-cache timeout is 30 seconds, not 7 as with other > >> commands... > > > > Ok, 7 seconds for FLUSH_CACHE would have been nice for us too though, as > > it would pretty much guarentee lower latencies for random writes and > > write back caching. The concern is the barrier code, of course. I guess > > I should do some timings on potential worst case patterns some day. Alan > > may have done that sometime in the past, iirc. > > FWIW: According to the drive guys (Eric M, among others), FLUSH CACHE > will "probably" be under 30 seconds, but pathological cases might even > extend beyond that. > > Definitely more than 7 seconds in less-than-pathological cases, > unfortunately... The mentioned Maxtor model (6Yxxx) isn't susceptible to the large-buffer long completion times, due to architectural differences and availability of only small buffers. Any "real" long-completion flush on this device would, I believe, involve damage to the disk that hinders the ability to seek, settle, or write. (e.g. 30-second flushes are easy to hit if you mount the disk on a shaker-table with sufficient amplitude) Later in the thread I think people have pretty much isolated it as not the disk's problem, but just wanted to point this out. I assume that large enough customers can buy enterprise-type command completion ("all commands within X seconds") from most any disk vendor. However, these firmwares require much smarter or more active drivers or block layers, to handle the higher error rate when the data on the device is valid, but it will take longer than allowed by the arbitrary enterprise rules. Most customers who are buying this many devices have software engineers customizing the drivers or disk management applications to handle this differing behavior. --eric ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-14 23:43 ` Robert Hancock 2007-01-15 0:22 ` Jeff Garzik @ 2007-01-15 21:17 ` Björn Steinbrink 2007-01-15 23:46 ` Björn Steinbrink 1 sibling, 1 reply; 71+ messages in thread From: Björn Steinbrink @ 2007-01-15 21:17 UTC (permalink / raw) To: Robert Hancock; +Cc: jeff, linux-kernel, htejun, jens.axboe On 2007.01.14 17:43:53 -0600, Robert Hancock wrote: > Björn Steinbrink wrote: > >Hi, > > > >with 2.6.20-rc{2,4,5} (no other tested yet) I see SATA exceptions quite > >often, with 2.6.19 there are no such exceptions. dmesg and lspci -v > >output follows. In the meantime, I'll start bisecting. > > ... > > >ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen > >ata1.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 in > > res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) > >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: 160086528 512-byte hdwr sectors (81964 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 > > Looks like all of these errors are from a FLUSH CACHE command and the > drive is indicating that it is no longer busy, so presumably done. > That's not a DMA-mapped command, so it wouldn't go through the ADMA > machinery and I wouldn't have expected this to be handled any > differently from before. Curious.. My latest bisection attempt actually led to your sata_nv ADMA commit. [1] I've now backed out that patch from 2.6.20-rc5 and have my stress test running for 20 minutes now ("record" for a bad kernel surviving that test is about 40 minutes IIRC). I'll keep it running for at least 2 more hours. The test is pretty simple: while /bin/true; do ls -lR > /dev/null; done while /bin/true; do echo 255 > /proc/sys/vm/drop_caches; sleep 1; done running in parallel. Björn [1] 2dec7555e6bf2772749113ea0ad454fcdb8cf861 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-15 21:17 ` Björn Steinbrink @ 2007-01-15 23:46 ` Björn Steinbrink 2007-01-16 0:34 ` Robert Hancock 0 siblings, 1 reply; 71+ messages in thread From: Björn Steinbrink @ 2007-01-15 23:46 UTC (permalink / raw) To: Robert Hancock, jeff, linux-kernel, htejun, jens.axboe On 2007.01.15 22:17:24 +0100, Björn Steinbrink wrote: > On 2007.01.14 17:43:53 -0600, Robert Hancock wrote: > > Björn Steinbrink wrote: > > >Hi, > > > > > >with 2.6.20-rc{2,4,5} (no other tested yet) I see SATA exceptions quite > > >often, with 2.6.19 there are no such exceptions. dmesg and lspci -v > > >output follows. In the meantime, I'll start bisecting. > > > > ... > > > > >ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen > > >ata1.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 in > > > res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) > > >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: 160086528 512-byte hdwr sectors (81964 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 > > > > Looks like all of these errors are from a FLUSH CACHE command and the > > drive is indicating that it is no longer busy, so presumably done. > > That's not a DMA-mapped command, so it wouldn't go through the ADMA > > machinery and I wouldn't have expected this to be handled any > > differently from before. Curious.. > > My latest bisection attempt actually led to your sata_nv ADMA commit. [1] > I've now backed out that patch from 2.6.20-rc5 and have my stress test > running for 20 minutes now ("record" for a bad kernel surviving that > test is about 40 minutes IIRC). I'll keep it running for at least 2 more > hours. Yep, that one seems to be guilty. 2.6.20-rc5 with that commit backed out survived about 3 hours of testing, while the average was around 5 minutes for a failure, sometimes even before I could log in. I took a look at the patch, but I can't really tell anything. nv_adma_check_atapi_dma somehow looks like it should not negate its return value, so that it returns 0 (atapi dma available) when adma_enable was 1. But I'm not exactly confident about that either ;) Will it hurt if I try to remove the negation? Thanks, Björn ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-15 23:46 ` Björn Steinbrink @ 2007-01-16 0:34 ` Robert Hancock 2007-01-16 1:35 ` Björn Steinbrink ` (2 more replies) 0 siblings, 3 replies; 71+ messages in thread From: Robert Hancock @ 2007-01-16 0:34 UTC (permalink / raw) To: Björn Steinbrink, jeff, linux-kernel, htejun, jens.axboe Björn Steinbrink wrote: >> My latest bisection attempt actually led to your sata_nv ADMA commit. [1] >> I've now backed out that patch from 2.6.20-rc5 and have my stress test >> running for 20 minutes now ("record" for a bad kernel surviving that >> test is about 40 minutes IIRC). I'll keep it running for at least 2 more >> hours. > > Yep, that one seems to be guilty. 2.6.20-rc5 with that commit backed out > survived about 3 hours of testing, while the average was around 5 > minutes for a failure, sometimes even before I could log in. > I took a look at the patch, but I can't really tell anything. > nv_adma_check_atapi_dma somehow looks like it should not negate its > return value, so that it returns 0 (atapi dma available) when > adma_enable was 1. But I'm not exactly confident about that either ;) > Will it hurt if I try to remove the negation? It should be correct the way it is - that check is trying to prevent ATAPI commands from using DMA until the slave_config function has been called to set up the DMA parameters properly. When the NV_ADMA_ATAPI_SETUP_COMPLETE flag is not set, this returns 1 which disallows DMA transfers. Unless you were using an ATAPI (i.e. CD/DVD) device on the channel this wouldn't affect you anyway. I'll try your stress test when I get a chance, but I doubt I'll run into the same problem and I haven't seen any similar reports. Perhaps it's some kind of wierd timing issue or incompatibility between the controller and that drive when running in ADMA mode? I seem to remember various reports of issues with certain Maxtor drives and some nForce SATA controllers under Windows at least.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/ ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-16 0:34 ` Robert Hancock @ 2007-01-16 1:35 ` Björn Steinbrink 2007-01-16 3:00 ` Robert Hancock 2007-01-16 1:53 ` Jeff Garzik 2007-01-19 14:53 ` Alistair John Strachan 2 siblings, 1 reply; 71+ messages in thread From: Björn Steinbrink @ 2007-01-16 1:35 UTC (permalink / raw) To: Robert Hancock; +Cc: jeff, linux-kernel, htejun, jens.axboe On 2007.01.15 18:34:43 -0600, Robert Hancock wrote: > Björn Steinbrink wrote: > >>My latest bisection attempt actually led to your sata_nv ADMA commit. [1] > >>I've now backed out that patch from 2.6.20-rc5 and have my stress test > >>running for 20 minutes now ("record" for a bad kernel surviving that > >>test is about 40 minutes IIRC). I'll keep it running for at least 2 more > >>hours. > > > >Yep, that one seems to be guilty. 2.6.20-rc5 with that commit backed out > >survived about 3 hours of testing, while the average was around 5 > >minutes for a failure, sometimes even before I could log in. > >I took a look at the patch, but I can't really tell anything. > >nv_adma_check_atapi_dma somehow looks like it should not negate its > >return value, so that it returns 0 (atapi dma available) when > >adma_enable was 1. But I'm not exactly confident about that either ;) > >Will it hurt if I try to remove the negation? > > It should be correct the way it is - that check is trying to prevent > ATAPI commands from using DMA until the slave_config function has been > called to set up the DMA parameters properly. When the > NV_ADMA_ATAPI_SETUP_COMPLETE flag is not set, this returns 1 which > disallows DMA transfers. Unless you were using an ATAPI (i.e. CD/DVD) > device on the channel this wouldn't affect you anyway. I wondered about it, because the flag is cleared when adma_enabled is 1, which seems to be consistent with everything but nv_adma_check_atapi_dma. Thus I thought that nv_adma_check_atapi_dma might be wrong, but maybe setting/clearing the flag is wrong instead? *feels lost* > I'll try your stress test when I get a chance, but I doubt I'll run into > the same problem and I haven't seen any similar reports. Perhaps it's > some kind of wierd timing issue or incompatibility between the > controller and that drive when running in ADMA mode? I seem to remember > various reports of issues with certain Maxtor drives and some nForce > SATA controllers under Windows at least.. I just checked Maxtor's knowledge base, that incompatibility does not affect my drive. Thanks, Björn ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-16 1:35 ` Björn Steinbrink @ 2007-01-16 3:00 ` Robert Hancock 0 siblings, 0 replies; 71+ messages in thread From: Robert Hancock @ 2007-01-16 3:00 UTC (permalink / raw) To: Björn Steinbrink, jeff, linux-kernel, htejun, jens.axboe Björn Steinbrink wrote: >> It should be correct the way it is - that check is trying to prevent >> ATAPI commands from using DMA until the slave_config function has been >> called to set up the DMA parameters properly. When the >> NV_ADMA_ATAPI_SETUP_COMPLETE flag is not set, this returns 1 which >> disallows DMA transfers. Unless you were using an ATAPI (i.e. CD/DVD) >> device on the channel this wouldn't affect you anyway. > > I wondered about it, because the flag is cleared when adma_enabled is 1, > which seems to be consistent with everything but nv_adma_check_atapi_dma. When ADMA is enabled we can't use ATAPI at all (or so says NVidia anyway), so it has to be disabled when an ATAPI device is detected in slave_config. Since doing that implies using the legacy BMDMA engine with its greater restrictions, this is why we need to prevent DMA transfers from being attempted until those restrictions have been set properly. (Otherwise, the libata core will try to use PACKET commands on an ATAPI device with DMA enabled before slave_config is even called.) > Thus I thought that nv_adma_check_atapi_dma might be wrong, but maybe > setting/clearing the flag is wrong instead? *feels lost* -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/ ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-16 0:34 ` Robert Hancock 2007-01-16 1:35 ` Björn Steinbrink @ 2007-01-16 1:53 ` Jeff Garzik 2007-01-19 15:05 ` Alistair John Strachan 2007-01-19 14:53 ` Alistair John Strachan 2 siblings, 1 reply; 71+ messages in thread From: Jeff Garzik @ 2007-01-16 1:53 UTC (permalink / raw) To: Robert Hancock, Björn Steinbrink; +Cc: linux-kernel, htejun, jens.axboe Robert Hancock wrote: > I'll try your stress test when I get a chance, but I doubt I'll run into > the same problem and I haven't seen any similar reports. Perhaps it's > some kind of wierd timing issue or incompatibility between the > controller and that drive when running in ADMA mode? I seem to remember > various reports of issues with certain Maxtor drives and some nForce > SATA controllers under Windows at least.. Just to eliminate things, has disabling ADMA been attempted? It can be disabled using the sata_nv.adma module parameter. Jeff ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-16 1:53 ` Jeff Garzik @ 2007-01-19 15:05 ` Alistair John Strachan 2007-01-19 19:51 ` chunkeey 2007-01-20 2:41 ` Robert Hancock 0 siblings, 2 replies; 71+ messages in thread From: Alistair John Strachan @ 2007-01-19 15:05 UTC (permalink / raw) To: Jeff Garzik Cc: Robert Hancock, Björn Steinbrink, linux-kernel, htejun, jens.axboe On Tuesday 16 January 2007 01:53, Jeff Garzik wrote: > Robert Hancock wrote: > > I'll try your stress test when I get a chance, but I doubt I'll run into > > the same problem and I haven't seen any similar reports. Perhaps it's > > some kind of wierd timing issue or incompatibility between the > > controller and that drive when running in ADMA mode? I seem to remember > > various reports of issues with certain Maxtor drives and some nForce > > SATA controllers under Windows at least.. > > Just to eliminate things, has disabling ADMA been attempted? > > It can be disabled using the sata_nv.adma module parameter. Setting this option fixes the problem for me. I suggest that ADMA defaults off in 2.6.20, if there's still time to do that. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-19 15:05 ` Alistair John Strachan @ 2007-01-19 19:51 ` chunkeey 2007-01-20 2:41 ` Robert Hancock 1 sibling, 0 replies; 71+ messages in thread From: chunkeey @ 2007-01-19 19:51 UTC (permalink / raw) To: Alistair John Strachan Cc: Jeff Garzik, Robert Hancock, Björn Steinbrink, linux-kernel, htejun, jens.axboe, chunkeey On Friday, 19. January 2007 16:05, Alistair John Strachan wrote: > On Tuesday 16 January 2007 01:53, Jeff Garzik wrote: > > Robert Hancock wrote: > > > I'll try your stress test when I get a chance, but I doubt I'll run > > > into the same problem and I haven't seen any similar reports. Perhaps > > > it's some kind of wierd timing issue or incompatibility between the > > > controller and that drive when running in ADMA mode? I seem to remember > > > various reports of issues with certain Maxtor drives and some nForce > > > SATA controllers under Windows at least.. > > > > Just to eliminate things, has disabling ADMA been attempted? > > > > It can be disabled using the sata_nv.adma module parameter. > > Setting this option fixes the problem for me. I suggest that ADMA defaults > off in 2.6.20, if there's still time to do that. Not for me. I'm still have the same trouble, but less (maybe about every hour, instead of every 5 minutes). futhermore, I found a patch cocktail-2.6.20-rc3.patch: http://tinyurl.com/2gza8q, which improves the situation too! Now, the funny thing is that I've two SATA HDDs, but only 1 causes all the headaches. The affected drive is a: sda - @ata3.0 - WDC WD2500KS-00M 02.0 ATA-7, max UDMA/133, 488395055 sectors: LBA48 "ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata3.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 out res 40/00:ff:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata3: soft resetting port ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata3.00: configured for UDMA/133:PIO0 ata3: EH complete SCSI device sda: 488395055 512-byte hdwr sectors (250058 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00" the "good" HDD is a: sdb - @ata4.0 - WDC WD2500YD-01N 10.0 ATA-7, max UDMA/133, 490234752 sectors: LBA48 NCQ (depth 0/1) System: AMD64 4200+ nForce 4 SLI 2 GB SMP PREEMPT kernel ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-19 15:05 ` Alistair John Strachan 2007-01-19 19:51 ` chunkeey @ 2007-01-20 2:41 ` Robert Hancock 2007-01-20 2:47 ` Alistair John Strachan ` (4 more replies) 1 sibling, 5 replies; 71+ messages in thread From: Robert Hancock @ 2007-01-20 2:41 UTC (permalink / raw) To: Alistair John Strachan Cc: Jeff Garzik, Björn Steinbrink, linux-kernel, htejun, jens.axboe, lwalton [-- Attachment #1: Type: text/plain, Size: 1588 bytes --] Alistair John Strachan wrote: > On Tuesday 16 January 2007 01:53, Jeff Garzik wrote: >> Robert Hancock wrote: >>> I'll try your stress test when I get a chance, but I doubt I'll run into >>> the same problem and I haven't seen any similar reports. Perhaps it's >>> some kind of wierd timing issue or incompatibility between the >>> controller and that drive when running in ADMA mode? I seem to remember >>> various reports of issues with certain Maxtor drives and some nForce >>> SATA controllers under Windows at least.. >> Just to eliminate things, has disabling ADMA been attempted? >> >> It can be disabled using the sata_nv.adma module parameter. > > Setting this option fixes the problem for me. I suggest that ADMA defaults off > in 2.6.20, if there's still time to do that. > Can you guys that are having this problem try the attached debug patch? It's possible it will fix the problem, as I'm trying a private exec_command implementation that flushes the write by reading a controller register instead of reading altstatus from the drive like the libata core code does. If the problem still happens, I also added some more debugging in to help figure out what is going on, so please post full dmesg. By the way, I assume that you guys are using reiserfs or xfs, as it appears no other file systems issue flush commands automatically. I had to test this by "echo 1 > delete" on the SCSI disk in sysfs, as I am using ext3. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/ [-- Attachment #2: sata_nv-debug-flushes.patch --] [-- Type: text/plain, Size: 3164 bytes --] --- linux-2.6.20-rc5/drivers/ata/sata_nv.c 2007-01-19 19:18:53.000000000 -0600 +++ linux-2.6.20-rc5debug/drivers/ata/sata_nv.c 2007-01-19 20:25:31.000000000 -0600 @@ -245,6 +245,7 @@ static void nv_adma_bmdma_setup(struct a static void nv_adma_bmdma_start(struct ata_queued_cmd *qc); static void nv_adma_bmdma_stop(struct ata_queued_cmd *qc); static u8 nv_adma_bmdma_status(struct ata_port *ap); +static void nv_adma_exec_command(struct ata_port *ap, const struct ata_taskfile *tf); enum nv_host_type { @@ -409,7 +410,7 @@ static const struct ata_port_operations .tf_load = ata_tf_load, .tf_read = ata_tf_read, .check_atapi_dma = nv_adma_check_atapi_dma, - .exec_command = ata_exec_command, + .exec_command = nv_adma_exec_command, .check_status = ata_check_status, .dev_select = ata_std_dev_select, .bmdma_setup = nv_adma_bmdma_setup, @@ -617,6 +618,14 @@ static int nv_adma_check_atapi_dma(struc return !(pp->flags & NV_ADMA_ATAPI_SETUP_COMPLETE); } +static void nv_adma_exec_command(struct ata_port *ap, const struct ata_taskfile *tf) +{ + void __iomem* mmio = nv_adma_ctl_block(ap); + writeb(tf->command, (void __iomem *) ap->ioaddr.command_addr); + readw(mmio + NV_ADMA_CTL); /* flush */ + ndelay(400); +} + static unsigned int nv_adma_tf_to_cpb(struct ata_taskfile *tf, __le16 *cpb) { unsigned int idx = 0; @@ -701,6 +710,9 @@ static int nv_host_intr(struct ata_port { struct ata_queued_cmd *qc = ata_qc_from_tag(ap, ap->active_tag); int handled; + u8 cmd = 0; + if(qc) + cmd = qc->tf.command; /* freeze if hotplugged */ if (unlikely(irq_stat & (NV_INT_ADDED | NV_INT_REMOVED))) { @@ -709,8 +721,11 @@ static int nv_host_intr(struct ata_port } /* bail out if not our interrupt */ - if (!(irq_stat & NV_INT_DEV)) + if (!(irq_stat & NV_INT_DEV)) { + if( cmd == ATA_CMD_FLUSH || cmd == ATA_CMD_FLUSH_EXT ) + ata_port_printk(ap, KERN_NOTICE, "cmd 0x%x active but stat 0x%x\n", cmd, irq_stat); return 0; + } /* DEV interrupt w/ no active qc? */ if (unlikely(!qc || (qc->tf.flags & ATA_TFLAG_POLLING))) { @@ -720,6 +735,8 @@ static int nv_host_intr(struct ata_port /* handle interrupt */ handled = ata_host_intr(ap, qc); + if( cmd == ATA_CMD_FLUSH || cmd == ATA_CMD_FLUSH_EXT ) + ata_port_printk(ap, KERN_NOTICE, "cmd 0x%x active, stat = 0x%x, handled = 0x%x\n", cmd, irq_stat, handled); if (unlikely(!handled)) { /* spurious, clear it */ ata_check_status(ap); @@ -870,7 +887,7 @@ static void nv_adma_bmdma_setup(struct a outb(dmactl, ap->ioaddr.bmdma_addr + ATA_DMA_CMD); /* issue r/w command */ - ata_exec_command(ap, &qc->tf); + nv_adma_exec_command(ap, &qc->tf); } static void nv_adma_bmdma_start(struct ata_queued_cmd *qc) @@ -1161,6 +1178,9 @@ static unsigned int nv_adma_qc_issue(str /* use ATA register mode */ VPRINTK("no dmamap or ATAPI, using ATA register mode: 0x%lx\n", qc->flags); nv_adma_register_mode(qc->ap); + if(qc->tf.command == ATA_CMD_FLUSH || + qc->tf.command == ATA_CMD_FLUSH_EXT ) + ata_port_printk(qc->ap, KERN_NOTICE, "issue flush cmd 0x%x\n", qc->tf.command); return ata_qc_issue_prot(qc); } else nv_adma_mode(qc->ap); ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-20 2:41 ` Robert Hancock @ 2007-01-20 2:47 ` Alistair John Strachan 2007-01-20 4:15 ` Björn Steinbrink ` (3 subsequent siblings) 4 siblings, 0 replies; 71+ messages in thread From: Alistair John Strachan @ 2007-01-20 2:47 UTC (permalink / raw) To: Robert Hancock Cc: Jeff Garzik, Björn Steinbrink, linux-kernel, htejun, jens.axboe, lwalton On Saturday 20 January 2007 02:41, Robert Hancock wrote: > By the way, I assume that you guys are using reiserfs or xfs, as it > appears no other file systems issue flush commands automatically. I had > to test this by "echo 1 > delete" on the SCSI disk in sysfs, as I am > using ext3. I'll give it a spin now, and yes I'm using several large XFS partitions on this machine, layered on top of md RAID5. That's why this particular defect is so catastrophic (literally _everything_ is stalled). -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-20 2:41 ` Robert Hancock 2007-01-20 2:47 ` Alistair John Strachan @ 2007-01-20 4:15 ` Björn Steinbrink [not found] ` <20070120072755.GA4652@atjola.homenet> ` (2 subsequent siblings) 4 siblings, 0 replies; 71+ messages in thread From: Björn Steinbrink @ 2007-01-20 4:15 UTC (permalink / raw) To: Robert Hancock Cc: Alistair John Strachan, Jeff Garzik, linux-kernel, htejun, jens.axboe, lwalton On 2007.01.19 20:41:36 -0600, Robert Hancock wrote: > Alistair John Strachan wrote: > >On Tuesday 16 January 2007 01:53, Jeff Garzik wrote: > >>Robert Hancock wrote: > >>>I'll try your stress test when I get a chance, but I doubt I'll run into > >>>the same problem and I haven't seen any similar reports. Perhaps it's > >>>some kind of wierd timing issue or incompatibility between the > >>>controller and that drive when running in ADMA mode? I seem to remember > >>>various reports of issues with certain Maxtor drives and some nForce > >>>SATA controllers under Windows at least.. > >>Just to eliminate things, has disabling ADMA been attempted? > >> > >>It can be disabled using the sata_nv.adma module parameter. > > > >Setting this option fixes the problem for me. I suggest that ADMA defaults > >off in 2.6.20, if there's still time to do that. > > > > Can you guys that are having this problem try the attached debug patch? > It's possible it will fix the problem, as I'm trying a private > exec_command implementation that flushes the write by reading a > controller register instead of reading altstatus from the drive like the > libata core code does. Will give it a spin in about an hour. > If the problem still happens, I also added some more debugging in to > help figure out what is going on, so please post full dmesg. > > By the way, I assume that you guys are using reiserfs or xfs, as it > appears no other file systems issue flush commands automatically. I had > to test this by "echo 1 > delete" on the SCSI disk in sysfs, as I am > using ext3. No, ext3 here, on top of md RAID1 and LVM. Oh, and one ext2, I wonder where that comes from... Björn ^ permalink raw reply [flat|nested] 71+ messages in thread
[parent not found: <20070120072755.GA4652@atjola.homenet>]
* Re: SATA exceptions with 2.6.20-rc5 [not found] ` <20070120072755.GA4652@atjola.homenet> @ 2007-01-20 7:50 ` Björn Steinbrink 0 siblings, 0 replies; 71+ messages in thread From: Björn Steinbrink @ 2007-01-20 7:50 UTC (permalink / raw) To: Robert Hancock, Alistair John Strachan, Jeff Garzik, linux-kernel, htejun, jens.axboe, lwalton Darn, didn't remove enough stuff (hit the 100K limit), next try. Sorry if anyone gets this duplicated for whatever reason. On 2007.01.20 08:27:55 +0100, Björn Steinbrink wrote: > On 2007.01.19 20:41:36 -0600, Robert Hancock wrote: > > Alistair John Strachan wrote: > > >On Tuesday 16 January 2007 01:53, Jeff Garzik wrote: > > >>Robert Hancock wrote: > > >>>I'll try your stress test when I get a chance, but I doubt I'll run into > > >>>the same problem and I haven't seen any similar reports. Perhaps it's > > >>>some kind of wierd timing issue or incompatibility between the > > >>>controller and that drive when running in ADMA mode? I seem to remember > > >>>various reports of issues with certain Maxtor drives and some nForce > > >>>SATA controllers under Windows at least.. > > >>Just to eliminate things, has disabling ADMA been attempted? > > >> > > >>It can be disabled using the sata_nv.adma module parameter. > > > > > >Setting this option fixes the problem for me. I suggest that ADMA defaults > > >off in 2.6.20, if there's still time to do that. > > > > > > > Can you guys that are having this problem try the attached debug patch? > > It's possible it will fix the problem, as I'm trying a private > > exec_command implementation that flushes the write by reading a > > controller register instead of reading altstatus from the drive like the > > libata core code does. > > > > If the problem still happens, I also added some more debugging in to > > help figure out what is going on, so please post full dmesg. > > Running it with my little test case produced almost 1MB of dmesg before > it hit an exception. I'm not exactly sure, but the delay caused by that > exception seemed to be about twice as long as without the patch, could > be my imagination though... > > As the messages seem to be the same all the time, I snipped a good bunch > out of the log, if you really want to see the whole thing, let me know. > > Thanks, > Björn > > > > Jan 20 07:14:55 atjola syslog-ng[1592]: syslog-ng starting up; version='2.0.0' > Jan 20 07:14:55 atjola kernel: Linux version 2.6.20-rc5-sata (doener@atjola) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #7 SMP Sat Jan 20 07:11:46 CET 2007 > Jan 20 07:14:55 atjola kernel: Command line: root=/dev/md0 ro quiet > Jan 20 07:14:55 atjola kernel: BIOS-provided physical RAM map: > Jan 20 07:14:55 atjola kernel: BIOS-e820: 0000000000000000 - 000000000009f000 (usable) > Jan 20 07:14:55 atjola kernel: BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved) > Jan 20 07:14:55 atjola kernel: BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) > Jan 20 07:14:55 atjola kernel: BIOS-e820: 0000000000100000 - 000000007fee0000 (usable) > Jan 20 07:14:55 atjola kernel: BIOS-e820: 000000007fee0000 - 000000007fee3000 (ACPI NVS) > Jan 20 07:14:55 atjola kernel: BIOS-e820: 000000007fee3000 - 000000007fef0000 (ACPI data) > Jan 20 07:14:55 atjola kernel: BIOS-e820: 000000007fef0000 - 000000007ff00000 (reserved) > Jan 20 07:14:55 atjola kernel: BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) > Jan 20 07:14:55 atjola kernel: BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved) > Jan 20 07:14:55 atjola kernel: Entering add_active_range(0, 0, 159) 0 entries of 256 used > Jan 20 07:14:55 atjola kernel: Entering add_active_range(0, 256, 524000) 1 entries of 256 used > Jan 20 07:14:55 atjola kernel: end_pfn_map = 1048576 > Jan 20 07:14:55 atjola kernel: DMI 2.2 present. > Jan 20 07:14:55 atjola kernel: ACPI: RSDP (v000 Nvidia ) @ 0x00000000000f7a70 > Jan 20 07:14:55 atjola kernel: ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x000000007fee3040 > Jan 20 07:14:55 atjola kernel: ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x000000007fee30c0 > Jan 20 07:14:55 atjola kernel: ACPI: SSDT (v001 PTLTD POWERNOW 0x00000001 LTP 0x00000001) @ 0x000000007fee9540 > Jan 20 07:14:55 atjola kernel: ACPI: SRAT (v001 AMD HAMMER 0x00000001 AMD 0x00000001) @ 0x000000007fee9780 > Jan 20 07:14:55 atjola kernel: ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x000000007fee9480 > Jan 20 07:14:55 atjola kernel: ACPI: DSDT (v001 NVIDIA AWRDACPI 0x00001000 MSFT 0x0100000e) @ 0x0000000000000000 > Jan 20 07:14:55 atjola kernel: Entering add_active_range(0, 0, 159) 0 entries of 256 used > Jan 20 07:14:55 atjola kernel: Entering add_active_range(0, 256, 524000) 1 entries of 256 used > Jan 20 07:14:55 atjola kernel: Zone PFN ranges: > Jan 20 07:14:55 atjola kernel: DMA 0 -> 4096 > Jan 20 07:14:55 atjola kernel: DMA32 4096 -> 1048576 > Jan 20 07:14:55 atjola kernel: Normal 1048576 -> 1048576 > Jan 20 07:14:55 atjola kernel: early_node_map[2] active PFN ranges > Jan 20 07:14:55 atjola kernel: 0: 0 -> 159 > Jan 20 07:14:55 atjola kernel: 0: 256 -> 524000 > Jan 20 07:14:55 atjola kernel: On node 0 totalpages: 523903 > Jan 20 07:14:55 atjola kernel: DMA zone: 56 pages used for memmap > Jan 20 07:14:55 atjola kernel: DMA zone: 1122 pages reserved > Jan 20 07:14:55 atjola kernel: DMA zone: 2821 pages, LIFO batch:0 > Jan 20 07:14:55 atjola kernel: DMA32 zone: 7108 pages used for memmap > Jan 20 07:14:55 atjola kernel: DMA32 zone: 512796 pages, LIFO batch:31 > Jan 20 07:14:55 atjola kernel: Normal zone: 0 pages used for memmap > Jan 20 07:14:55 atjola kernel: Nvidia board detected. Ignoring ACPI timer override. > Jan 20 07:14:55 atjola kernel: If you got timer trouble try acpi_use_timer_override > Jan 20 07:14:55 atjola kernel: ACPI: PM-Timer IO Port: 0x1008 > Jan 20 07:14:55 atjola kernel: ACPI: Local APIC address 0xfee00000 > Jan 20 07:14:55 atjola kernel: ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) > Jan 20 07:14:55 atjola kernel: Processor #0 (Bootup-CPU) > Jan 20 07:14:55 atjola kernel: ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) > Jan 20 07:14:55 atjola kernel: Processor #1 > Jan 20 07:14:55 atjola kernel: ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) > Jan 20 07:14:55 atjola kernel: ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) > Jan 20 07:14:55 atjola kernel: ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) > Jan 20 07:14:55 atjola kernel: IOAPIC[0]: apic_id 2, address 0xfec00000, GSI 0-23 > Jan 20 07:14:55 atjola kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) > Jan 20 07:14:55 atjola kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) > Jan 20 07:14:55 atjola kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) > Jan 20 07:14:55 atjola kernel: ACPI: IRQ9 used by override. > Jan 20 07:14:55 atjola kernel: ACPI: IRQ14 used by override. > Jan 20 07:14:55 atjola kernel: ACPI: IRQ15 used by override. > Jan 20 07:14:55 atjola kernel: Setting APIC routing to flat > Jan 20 07:14:55 atjola kernel: Using ACPI (MADT) for SMP configuration information > Jan 20 07:14:55 atjola kernel: Nosave address range: 000000000009f000 - 00000000000a0000 > Jan 20 07:14:55 atjola kernel: Nosave address range: 00000000000a0000 - 00000000000f0000 > Jan 20 07:14:55 atjola kernel: Nosave address range: 00000000000f0000 - 0000000000100000 > Jan 20 07:14:55 atjola kernel: Allocating PCI resources starting at 80000000 (gap: 7ff00000:60100000) > Jan 20 07:14:55 atjola kernel: PERCPU: Allocating 32000 bytes of per cpu data > Jan 20 07:14:55 atjola kernel: Built 1 zonelists. Total pages: 515617 > Jan 20 07:14:55 atjola kernel: Kernel command line: root=/dev/md0 ro quiet > Jan 20 07:14:55 atjola kernel: Initializing CPU#0 > Jan 20 07:14:55 atjola kernel: PID hash table entries: 4096 (order: 12, 32768 bytes) > Jan 20 07:14:55 atjola kernel: Console: colour VGA+ 80x25 > Jan 20 07:14:55 atjola kernel: Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) > Jan 20 07:14:55 atjola kernel: Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) > Jan 20 07:14:55 atjola kernel: Checking aperture... > Jan 20 07:14:55 atjola kernel: CPU 0: aperture @ 7a74000000 size 32 MB > Jan 20 07:14:55 atjola kernel: Aperture too small (32 MB) > Jan 20 07:14:55 atjola kernel: No AGP bridge found > Jan 20 07:14:55 atjola kernel: Memory: 2059000k/2096000k available (2796k kernel code, 36392k reserved, 1088k data, 224k init) > Jan 20 07:14:55 atjola kernel: Calibrating delay using timer specific routine.. 2010.39 BogoMIPS (lpj=10051993) > Jan 20 07:14:55 atjola kernel: Mount-cache hash table entries: 256 > Jan 20 07:14:55 atjola kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) > Jan 20 07:14:55 atjola kernel: CPU: L2 Cache: 1024K (64 bytes/line) > Jan 20 07:14:55 atjola kernel: CPU: Physical Processor ID: 0 > Jan 20 07:14:55 atjola kernel: CPU: Processor Core ID: 0 > Jan 20 07:14:55 atjola kernel: Freeing SMP alternatives: 28k freed > Jan 20 07:14:55 atjola kernel: ACPI: Core revision 20060707 > Jan 20 07:14:55 atjola kernel: Using local APIC timer interrupts. > Jan 20 07:14:55 atjola kernel: result 12558007 > Jan 20 07:14:55 atjola kernel: Detected 12.558 MHz APIC timer. > Jan 20 07:14:55 atjola kernel: Booting processor 1/2 APIC 0x1 > Jan 20 07:14:55 atjola kernel: Initializing CPU#1 > Jan 20 07:14:55 atjola kernel: Calibrating delay using timer specific routine.. 2009.30 BogoMIPS (lpj=10046526) > Jan 20 07:14:55 atjola kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) > Jan 20 07:14:55 atjola kernel: CPU: L2 Cache: 1024K (64 bytes/line) > Jan 20 07:14:55 atjola kernel: CPU: Physical Processor ID: 0 > Jan 20 07:14:55 atjola kernel: CPU: Processor Core ID: 1 > Jan 20 07:14:55 atjola kernel: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ stepping 02 > Jan 20 07:14:55 atjola kernel: CPU 1: Syncing TSC to CPU 0. > Jan 20 07:14:55 atjola kernel: CPU 1: synchronized TSC with CPU 0 (last diff 22 cycles, maxerr 344 cycles) > Jan 20 07:14:55 atjola kernel: Brought up 2 CPUs > Jan 20 07:14:55 atjola kernel: testing NMI watchdog ... OK. > Jan 20 07:14:55 atjola kernel: Disabling vsyscall due to use of PM timer > Jan 20 07:14:55 atjola kernel: time.c: Using 3.579545 MHz WALL PM GTOD PM timer. > Jan 20 07:14:55 atjola kernel: time.c: Detected 1004.639 MHz processor. > Jan 20 07:14:55 atjola kernel: migration_cost=453 > Jan 20 07:14:55 atjola kernel: NET: Registered protocol family 16 > Jan 20 07:14:55 atjola kernel: ACPI: bus type pci registered > Jan 20 07:14:55 atjola kernel: PCI: Using configuration type 1 > Jan 20 07:14:55 atjola kernel: ACPI: Interpreter enabled > Jan 20 07:14:55 atjola kernel: ACPI: Using IOAPIC for interrupt routing > Jan 20 07:14:55 atjola kernel: ACPI: PCI Root Bridge [PCI0] (0000:00) > Jan 20 07:14:55 atjola kernel: PCI: Probing PCI hardware (bus 00) > Jan 20 07:14:55 atjola kernel: PCI: Transparent bridge - 0000:00:09.0 > Jan 20 07:14:55 atjola kernel: Boot video device is 0000:05:00.0 > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT] > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [LNK1] (IRQs 3 5 7 9 10 *11 12 14 15) > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [LNK2] (IRQs 3 5 7 9 10 11 12 14 15) *0, disabled. > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [LNK3] (IRQs 3 *5 7 9 10 11 12 14 15) > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [LNK4] (IRQs 3 5 7 9 *10 11 12 14 15) > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [LNK5] (IRQs 3 5 7 9 10 11 12 14 15) *0, disabled. > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [LUBA] (IRQs 3 *5 7 9 10 11 12 14 15) > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [LUBB] (IRQs 3 5 7 9 10 11 12 14 15) *0, disabled. > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [LMAC] (IRQs 3 5 *7 9 10 11 12 14 15) > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [LACI] (IRQs 3 5 7 9 10 11 12 14 15) *0, disabled. > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [LMCI] (IRQs *3 5 7 9 10 11 12 14 15) > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [LSMB] (IRQs 3 5 *7 9 10 11 12 14 15) > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [LUB2] (IRQs 3 5 7 9 *10 11 12 14 15) > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [LIDE] (IRQs 3 5 7 9 10 11 12 14 15) *0, disabled. > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [LSID] (IRQs 3 5 7 9 10 *11 12 14 15) > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [LFID] (IRQs 3 5 7 9 10 11 12 14 15) *0, disabled. > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [LPCA] (IRQs 3 5 7 9 10 11 12 14 15) *0, disabled. > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [APC1] (IRQs 16) *0, disabled. > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [APC2] (IRQs 17) *0, disabled. > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [APC3] (IRQs 18) *0, disabled. > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [APC4] (IRQs 19) *0, disabled. > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [APC5] (IRQs *16), disabled. > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22 23) *0, disabled. > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [APCG] (IRQs 20 21 22 23) *0, disabled. > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22 23) *0, disabled. > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [APCJ] (IRQs 20 21 22 23) *0, disabled. > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [APCK] (IRQs 20 21 22 23) *0, disabled. > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [APCS] (IRQs 20 21 22 23) *0, disabled. > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22 23) *0, disabled. > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22 23) *0, disabled. > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [APSI] (IRQs 20 21 22 23) *0, disabled. > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [APSJ] (IRQs 20 21 22 23) *0, disabled. > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [APCP] (IRQs 20 21 22 23) *0, disabled. > Jan 20 07:14:55 atjola kernel: SCSI subsystem initialized > Jan 20 07:14:55 atjola kernel: libata version 2.00 loaded. > Jan 20 07:14:55 atjola kernel: usbcore: registered new interface driver usbfs > Jan 20 07:14:55 atjola kernel: usbcore: registered new interface driver hub > Jan 20 07:14:55 atjola kernel: usbcore: registered new device driver usb > Jan 20 07:14:55 atjola kernel: PCI: Using ACPI for IRQ routing > Jan 20 07:14:55 atjola kernel: PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report > Jan 20 07:14:55 atjola kernel: PCI: Bridge: 0000:00:09.0 > Jan 20 07:14:55 atjola kernel: IO window: c000-cfff > Jan 20 07:14:55 atjola kernel: MEM window: fc000000-fdffffff > Jan 20 07:14:55 atjola kernel: PREFETCH window: fea00000-feafffff > Jan 20 07:14:55 atjola kernel: PCI: Bridge: 0000:00:0b.0 > Jan 20 07:14:55 atjola kernel: IO window: b000-bfff > Jan 20 07:14:55 atjola kernel: MEM window: fe900000-fe9fffff > Jan 20 07:14:55 atjola kernel: PREFETCH window: fe800000-fe8fffff > Jan 20 07:14:55 atjola kernel: PCI: Bridge: 0000:00:0c.0 > Jan 20 07:14:55 atjola kernel: IO window: a000-afff > Jan 20 07:14:55 atjola kernel: MEM window: fe700000-fe7fffff > Jan 20 07:14:55 atjola kernel: PREFETCH window: fe600000-fe6fffff > Jan 20 07:14:55 atjola kernel: PCI: Bridge: 0000:00:0d.0 > Jan 20 07:14:55 atjola kernel: IO window: 9000-9fff > Jan 20 07:14:55 atjola kernel: MEM window: fe500000-fe5fffff > Jan 20 07:14:55 atjola kernel: PREFETCH window: fe400000-fe4fffff > Jan 20 07:14:55 atjola kernel: PCI: Bridge: 0000:00:0e.0 > Jan 20 07:14:55 atjola kernel: IO window: 8000-8fff > Jan 20 07:14:55 atjola kernel: MEM window: f4000000-fbffffff > Jan 20 07:14:55 atjola kernel: PREFETCH window: d0000000-dfffffff > Jan 20 07:14:55 atjola kernel: PCI: Setting latency timer of device 0000:00:09.0 to 64 > Jan 20 07:14:55 atjola kernel: PCI: Setting latency timer of device 0000:00:0b.0 to 64 > Jan 20 07:14:55 atjola kernel: PCI: Setting latency timer of device 0000:00:0c.0 to 64 > Jan 20 07:14:55 atjola kernel: PCI: Setting latency timer of device 0000:00:0d.0 to 64 > Jan 20 07:14:55 atjola kernel: PCI: Setting latency timer of device 0000:00:0e.0 to 64 > Jan 20 07:14:55 atjola kernel: NET: Registered protocol family 2 > Jan 20 07:14:55 atjola kernel: IP route cache hash table entries: 65536 (order: 7, 524288 bytes) > Jan 20 07:14:55 atjola kernel: TCP established hash table entries: 262144 (order: 10, 4194304 bytes) > Jan 20 07:14:55 atjola kernel: TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) > Jan 20 07:14:55 atjola kernel: TCP: Hash tables configured (established 262144 bind 65536) > Jan 20 07:14:55 atjola kernel: TCP reno registered > Jan 20 07:14:55 atjola kernel: io scheduler noop registered > Jan 20 07:14:55 atjola kernel: io scheduler deadline registered (default) > Jan 20 07:14:55 atjola kernel: 0000:00:02.1 EHCI: BIOS handoff failed (BIOS bug ?) 01010001 > Jan 20 07:14:55 atjola kernel: PCI: Found disabled HT MSI Mapping on 0000:00:0b.0 > Jan 20 07:14:55 atjola kernel: PCI: Found enabled HT MSI Mapping on 0000:00:00.0 > Jan 20 07:14:55 atjola kernel: PCI: Found disabled HT MSI Mapping on 0000:00:0c.0 > Jan 20 07:14:55 atjola kernel: PCI: Found enabled HT MSI Mapping on 0000:00:00.0 > Jan 20 07:14:55 atjola kernel: PCI: Found disabled HT MSI Mapping on 0000:00:0d.0 > Jan 20 07:14:55 atjola kernel: PCI: Found enabled HT MSI Mapping on 0000:00:00.0 > Jan 20 07:14:55 atjola kernel: PCI: Found disabled HT MSI Mapping on 0000:00:0e.0 > Jan 20 07:14:55 atjola kernel: PCI: Found enabled HT MSI Mapping on 0000:00:00.0 > Jan 20 07:14:55 atjola kernel: PCI: Setting latency timer of device 0000:00:0b.0 to 64 > Jan 20 07:14:55 atjola kernel: assign_interrupt_mode Found MSI capability > Jan 20 07:14:55 atjola kernel: Allocate Port Service[0000:00:0b.0:pcie00] > Jan 20 07:14:55 atjola kernel: PCI: Setting latency timer of device 0000:00:0c.0 to 64 > Jan 20 07:14:55 atjola kernel: assign_interrupt_mode Found MSI capability > Jan 20 07:14:55 atjola kernel: Allocate Port Service[0000:00:0c.0:pcie00] > Jan 20 07:14:55 atjola kernel: PCI: Setting latency timer of device 0000:00:0d.0 to 64 > Jan 20 07:14:55 atjola kernel: assign_interrupt_mode Found MSI capability > Jan 20 07:14:55 atjola kernel: Allocate Port Service[0000:00:0d.0:pcie00] > Jan 20 07:14:55 atjola kernel: PCI: Setting latency timer of device 0000:00:0e.0 to 64 > Jan 20 07:14:55 atjola kernel: assign_interrupt_mode Found MSI capability > Jan 20 07:14:55 atjola kernel: Allocate Port Service[0000:00:0e.0:pcie00] > Jan 20 07:14:55 atjola kernel: input: Power Button (FF) as /class/input/input0 > Jan 20 07:14:55 atjola kernel: ACPI: Power Button (FF) [PWRF] > Jan 20 07:14:55 atjola kernel: input: Power Button (CM) as /class/input/input1 > Jan 20 07:14:55 atjola kernel: ACPI: Power Button (CM) [PWRB] > Jan 20 07:14:55 atjola kernel: ACPI: Thermal Zone [THRM] (40 C) > Jan 20 07:14:55 atjola kernel: Real Time Clock Driver v1.12ac > Jan 20 07:14:55 atjola kernel: Linux agpgart interface v0.101 (c) Dave Jones > Jan 20 07:14:55 atjola kernel: Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled > Jan 20 07:14:55 atjola kernel: tg3.c:v3.72 (January 8, 2007) > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [APC4] enabled at IRQ 19 > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt 0000:04:00.0[A] -> Link [APC4] -> GSI 19 (level, low) -> IRQ 19 > Jan 20 07:14:55 atjola kernel: PCI: Setting latency timer of device 0000:04:00.0 to 64 > Jan 20 07:14:55 atjola kernel: eth0: Tigon3 [partno(BCM95721) rev 4101 PHY(5750)] (PCI Express) 10/100/1000Base-T Ethernet 00:e0:81:55:09:b0 > Jan 20 07:14:55 atjola kernel: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1] > Jan 20 07:14:55 atjola kernel: eth0: dma_rwctrl[76180000] dma_mask[64-bit] > Jan 20 07:14:55 atjola kernel: tun: Universal TUN/TAP device driver, 1.6 > Jan 20 07:14:55 atjola kernel: tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com> > Jan 20 07:14:55 atjola kernel: Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 > Jan 20 07:14:55 atjola kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx > Jan 20 07:14:55 atjola kernel: NFORCE-CK804: IDE controller at PCI slot 0000:00:06.0 > Jan 20 07:14:55 atjola kernel: NFORCE-CK804: chipset revision 242 > Jan 20 07:14:55 atjola kernel: NFORCE-CK804: not 100% native mode: will probe irqs later > Jan 20 07:14:55 atjola kernel: NFORCE-CK804: 0000:00:06.0 (rev f2) UDMA133 controller > Jan 20 07:14:55 atjola kernel: ide0: BM-DMA at 0xe800-0xe807, BIOS settings: hda:DMA, hdb:DMA > Jan 20 07:14:55 atjola kernel: Probing IDE interface ide0... > Jan 20 07:14:55 atjola kernel: hda: TOSHIBA DVD-ROM SD-M1502, ATAPI CD/DVD-ROM drive > Jan 20 07:14:55 atjola kernel: hdb: AOPEN CD-RW CRW4852 1.00 20030123, ATAPI CD/DVD-ROM drive > Jan 20 07:14:55 atjola kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > Jan 20 07:14:55 atjola kernel: Probing IDE interface ide1... > Jan 20 07:14:55 atjola kernel: hda: ATAPI 48X DVD-ROM drive, 128kB Cache, UDMA(33) > Jan 20 07:14:55 atjola kernel: Uniform CD-ROM driver Revision: 3.20 > Jan 20 07:14:55 atjola kernel: hdb: ATAPI 40X CD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33) > Jan 20 07:14:55 atjola kernel: sata_nv 0000:00:07.0: version 3.2 > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [APSI] enabled at IRQ 23 > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt 0000:00:07.0[A] -> Link [APSI] -> GSI 23 (level, low) -> IRQ 23 > Jan 20 07:14:55 atjola kernel: sata_nv 0000:00:07.0: Using ADMA mode > Jan 20 07:14:55 atjola kernel: PCI: Setting latency timer of device 0000:00:07.0 to 64 > Jan 20 07:14:55 atjola kernel: ata1: SATA max UDMA/133 cmd 0xFFFFC20000004480 ctl 0xFFFFC200000044A0 bmdma 0xD400 irq 23 > Jan 20 07:14:55 atjola kernel: ata2: SATA max UDMA/133 cmd 0xFFFFC20000004580 ctl 0xFFFFC200000045A0 bmdma 0xD408 irq 23 > Jan 20 07:14:55 atjola kernel: scsi0 : sata_nv > Jan 20 07:14:55 atjola kernel: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) > Jan 20 07:14:55 atjola kernel: ata1.00: ATA-7, max UDMA/133, 160086528 sectors: LBA > Jan 20 07:14:55 atjola kernel: ata1.00: ata1: dev 0 multi count 16 > Jan 20 07:14:55 atjola kernel: ata1.00: configured for UDMA/133 > Jan 20 07:14:55 atjola kernel: scsi1 : sata_nv > Jan 20 07:14:55 atjola kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) > Jan 20 07:14:55 atjola kernel: ata2.00: ATA-7, max UDMA/133, 160086528 sectors: LBA > Jan 20 07:14:55 atjola kernel: ata2.00: ata2: dev 0 multi count 16 > Jan 20 07:14:55 atjola kernel: ata2.00: configured for UDMA/133 > Jan 20 07:14:55 atjola kernel: scsi 0:0:0:0: Direct-Access ATA Maxtor 6Y080M0 YAR5 PQ: 0 ANSI: 5 > Jan 20 07:14:55 atjola kernel: ata1: bounce limit 0xFFFFFFFFFFFFFFFF, segment boundary 0xFFFFFFFF, hw segs 61 > Jan 20 07:14:55 atjola kernel: SCSI device sda: 160086528 512-byte hdwr sectors (81964 MB) > Jan 20 07:14:55 atjola kernel: sda: Write Protect is off > Jan 20 07:14:55 atjola kernel: sda: Mode Sense: 00 3a 00 00 > Jan 20 07:14:55 atjola kernel: SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA > Jan 20 07:14:55 atjola kernel: SCSI device sda: 160086528 512-byte hdwr sectors (81964 MB) > Jan 20 07:14:55 atjola kernel: sda: Write Protect is off > Jan 20 07:14:55 atjola kernel: sda: Mode Sense: 00 3a 00 00 > Jan 20 07:14:55 atjola kernel: SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA > Jan 20 07:14:55 atjola kernel: sda: sda1 sda2 sda3 > Jan 20 07:14:55 atjola kernel: sd 0:0:0:0: Attached scsi disk sda > Jan 20 07:14:55 atjola kernel: scsi 1:0:0:0: Direct-Access ATA Maxtor 6Y080M0 YAR5 PQ: 0 ANSI: 5 > Jan 20 07:14:55 atjola kernel: ata2: bounce limit 0xFFFFFFFFFFFFFFFF, segment boundary 0xFFFFFFFF, hw segs 61 > Jan 20 07:14:55 atjola kernel: SCSI device sdb: 160086528 512-byte hdwr sectors (81964 MB) > Jan 20 07:14:55 atjola kernel: sdb: Write Protect is off > Jan 20 07:14:55 atjola kernel: sdb: Mode Sense: 00 3a 00 00 > Jan 20 07:14:55 atjola kernel: SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA > Jan 20 07:14:55 atjola kernel: SCSI device sdb: 160086528 512-byte hdwr sectors (81964 MB) > Jan 20 07:14:55 atjola kernel: sdb: Write Protect is off > Jan 20 07:14:55 atjola kernel: sdb: Mode Sense: 00 3a 00 00 > Jan 20 07:14:55 atjola kernel: SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA > Jan 20 07:14:55 atjola kernel: sdb: sdb1 sdb2 sdb3 > Jan 20 07:14:55 atjola kernel: sd 1:0:0:0: Attached scsi disk sdb > Jan 20 07:14:55 atjola kernel: usbmon: debugfs is not available > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [APCL] enabled at IRQ 22 > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [APCL] -> GSI 22 (level, low) -> IRQ 22 > Jan 20 07:14:55 atjola kernel: PCI: Setting latency timer of device 0000:00:02.1 to 64 > Jan 20 07:14:55 atjola kernel: ehci_hcd 0000:00:02.1: EHCI Host Controller > Jan 20 07:14:55 atjola kernel: ehci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 1 > Jan 20 07:14:55 atjola kernel: ehci_hcd 0000:00:02.1: debug port 1 > Jan 20 07:14:55 atjola kernel: PCI: cache line size of 64 is not supported by device 0000:00:02.1 > Jan 20 07:14:55 atjola kernel: ehci_hcd 0000:00:02.1: irq 22, io mem 0xfeb00000 > Jan 20 07:14:55 atjola kernel: ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 > Jan 20 07:14:55 atjola kernel: usb usb1: configuration #1 chosen from 1 choice > Jan 20 07:14:55 atjola kernel: hub 1-0:1.0: USB hub found > Jan 20 07:14:55 atjola kernel: hub 1-0:1.0: 8 ports detected > Jan 20 07:14:55 atjola kernel: ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI) > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [APCF] enabled at IRQ 21 > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [APCF] -> GSI 21 (level, low) -> IRQ 21 > Jan 20 07:14:55 atjola kernel: PCI: Setting latency timer of device 0000:00:02.0 to 64 > Jan 20 07:14:55 atjola kernel: ohci_hcd 0000:00:02.0: OHCI Host Controller > Jan 20 07:14:55 atjola kernel: ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 2 > Jan 20 07:14:55 atjola kernel: ohci_hcd 0000:00:02.0: irq 21, io mem 0xfebff000 > Jan 20 07:14:55 atjola kernel: usb usb2: configuration #1 chosen from 1 choice > Jan 20 07:14:55 atjola kernel: hub 2-0:1.0: USB hub found > Jan 20 07:14:55 atjola kernel: hub 2-0:1.0: 8 ports detected > Jan 20 07:14:55 atjola kernel: usb 1-5: new high speed USB device using ehci_hcd and address 2 > Jan 20 07:14:55 atjola kernel: usb 1-5: configuration #1 chosen from 1 choice > Jan 20 07:14:55 atjola kernel: usb 2-6: new full speed USB device using ohci_hcd and address 2 > Jan 20 07:14:55 atjola kernel: usb 2-6: configuration #1 chosen from 1 choice > Jan 20 07:14:55 atjola kernel: hub 2-6:1.0: USB hub found > Jan 20 07:14:55 atjola kernel: hub 2-6:1.0: 4 ports detected > Jan 20 07:14:55 atjola kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 2 if 0 alt 0 proto 2 vid 0x04F9 pid 0x0022 > Jan 20 07:14:55 atjola kernel: usb 2-6.3: new low speed USB device using ohci_hcd and address 3 > Jan 20 07:14:55 atjola kernel: usb 2-6.3: configuration #1 chosen from 1 choice > Jan 20 07:14:55 atjola kernel: usb 2-6.4: new low speed USB device using ohci_hcd and address 4 > Jan 20 07:14:55 atjola kernel: usb 2-6.4: configuration #1 chosen from 1 choice > Jan 20 07:14:55 atjola kernel: usbcore: registered new interface driver usblp > Jan 20 07:14:55 atjola kernel: drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver > Jan 20 07:14:55 atjola kernel: Initializing USB Mass Storage driver... > Jan 20 07:14:55 atjola kernel: usbcore: registered new interface driver usb-storage > Jan 20 07:14:55 atjola kernel: USB Mass Storage support registered. > Jan 20 07:14:55 atjola kernel: usbcore: registered new interface driver hiddev > Jan 20 07:14:55 atjola kernel: input: Lite-On Tech IBM USB Keyboard with UltraNav as /class/input/input2 > Jan 20 07:14:55 atjola kernel: input: USB HID v1.10 Keyboard [Lite-On Tech IBM USB Keyboard with UltraNav] on usb-0000:00:02.0-6.3 > Jan 20 07:14:55 atjola kernel: input: Lite-On Tech IBM USB Keyboard with UltraNav as /class/input/input3 > Jan 20 07:14:55 atjola kernel: input: USB HID v1.10 Device [Lite-On Tech IBM USB Keyboard with UltraNav] on usb-0000:00:02.0-6.3 > Jan 20 07:14:55 atjola kernel: input: Synaptics Inc. Composite TouchPad / TrackPoint as /class/input/input4 > Jan 20 07:14:55 atjola kernel: input: USB HID v1.00 Mouse [Synaptics Inc. Composite TouchPad / TrackPoint] on usb-0000:00:02.0-6.4 > Jan 20 07:14:55 atjola kernel: input: Synaptics Inc. Composite TouchPad / TrackPoint as /class/input/input5 > Jan 20 07:14:55 atjola kernel: input: USB HID v1.00 Mouse [Synaptics Inc. Composite TouchPad / TrackPoint] on usb-0000:00:02.0-6.4 > Jan 20 07:14:55 atjola kernel: usbcore: registered new interface driver usbhid > Jan 20 07:14:55 atjola kernel: drivers/usb/input/hid-core.c: v2.6:USB HID core driver > Jan 20 07:14:55 atjola kernel: serio: i8042 KBD port at 0x60,0x64 irq 1 > Jan 20 07:14:55 atjola kernel: mice: PS/2 mouse device common for all mice > Jan 20 07:14:55 atjola kernel: md: raid1 personality registered for level 1 > Jan 20 07:14:55 atjola kernel: device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel@redhat.com > Jan 20 07:14:55 atjola kernel: Advanced Linux Sound Architecture Driver Version 1.0.14rc1 (Tue Jan 09 09:56:17 2007 UTC). > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt 0000:01:08.0[A] -> Link [APC4] -> GSI 19 (level, low) -> IRQ 19 > Jan 20 07:14:55 atjola kernel: gameport: EMU10K1 is pci0000:01:08.1/gameport0, io 0xc400, speed 1194kHz > Jan 20 07:14:55 atjola kernel: input: Microsoft SideWinder GamePad as /class/input/input6 > Jan 20 07:14:55 atjola kernel: ALSA device list: > Jan 20 07:14:55 atjola kernel: #0: Audigy 1 [SB0090] (rev.3, serial:0x531102) at 0xc800, irq 19 > Jan 20 07:14:55 atjola kernel: TCP cubic registered > Jan 20 07:14:55 atjola kernel: NET: Registered protocol family 1 > Jan 20 07:14:55 atjola kernel: NET: Registered protocol family 17 > Jan 20 07:14:55 atjola kernel: NET: Registered protocol family 15 > Jan 20 07:14:55 atjola kernel: powernow-k8: Found 2 AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ processors (version 2.00.00) > Jan 20 07:14:55 atjola kernel: powernow-k8: 0 : fid 0xe (2200 MHz), vid 0x8 > Jan 20 07:14:55 atjola kernel: powernow-k8: 1 : fid 0xc (2000 MHz), vid 0xa > Jan 20 07:14:55 atjola kernel: powernow-k8: 2 : fid 0xa (1800 MHz), vid 0xc > Jan 20 07:14:55 atjola kernel: powernow-k8: 3 : fid 0x2 (1000 MHz), vid 0xe > Jan 20 07:14:55 atjola kernel: md: Autodetecting RAID arrays. > Jan 20 07:14:55 atjola kernel: md: autorun ... > Jan 20 07:14:55 atjola kernel: md: considering sdb3 ... > Jan 20 07:14:55 atjola kernel: md: adding sdb3 ... > Jan 20 07:14:55 atjola kernel: md: sdb1 has different UUID to sdb3 > Jan 20 07:14:55 atjola kernel: md: adding sda3 ... > Jan 20 07:14:55 atjola kernel: md: sda1 has different UUID to sdb3 > Jan 20 07:14:55 atjola kernel: md: created md1 > Jan 20 07:14:55 atjola kernel: md: bind<sda3> > Jan 20 07:14:55 atjola kernel: md: bind<sdb3> > Jan 20 07:14:55 atjola kernel: md: running: <sdb3><sda3> > Jan 20 07:14:55 atjola kernel: raid1: raid set md1 active with 2 out of 2 mirrors > Jan 20 07:14:55 atjola kernel: md: considering sdb1 ... > Jan 20 07:14:55 atjola kernel: md: adding sdb1 ... > Jan 20 07:14:55 atjola kernel: md: adding sda1 ... > Jan 20 07:14:55 atjola kernel: md: created md0 > Jan 20 07:14:55 atjola kernel: md: bind<sda1> > Jan 20 07:14:55 atjola kernel: md: bind<sdb1> > Jan 20 07:14:55 atjola kernel: md: running: <sdb1><sda1> > Jan 20 07:14:55 atjola kernel: raid1: raid set md0 active with 2 out of 2 mirrors > Jan 20 07:14:55 atjola kernel: md: ... autorun DONE. > Jan 20 07:14:55 atjola kernel: kjournald starting. Commit interval 5 seconds > Jan 20 07:14:55 atjola kernel: EXT3-fs: mounted filesystem with ordered data mode. > Jan 20 07:14:55 atjola kernel: VFS: Mounted root (ext3 filesystem) readonly. > Jan 20 07:14:55 atjola kernel: Freeing unused kernel memory: 224k freed > Jan 20 07:14:55 atjola kernel: forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.59. > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt Link [APCH] enabled at IRQ 20 > Jan 20 07:14:55 atjola kernel: ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [APCH] -> GSI 20 (level, low) -> IRQ 20 > Jan 20 07:14:55 atjola kernel: PCI: Setting latency timer of device 0000:00:0a.0 to 64 > Jan 20 07:14:55 atjola kernel: forcedeth: using HIGHDMA > Jan 20 07:14:55 atjola kernel: eth1: forcedeth.c: subsystem: 010f1:2865 bound to 0000:00:0a.0 > Jan 20 07:14:55 atjola kernel: Adding 979956k swap on /dev/sda2. Priority:-1 extents:1 across:979956k > Jan 20 07:14:55 atjola kernel: Adding 979956k swap on /dev/sdb2. Priority:-2 extents:1 across:979956k > Jan 20 07:14:55 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:14:55 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:14:55 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:14:55 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:55 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:55 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:14:55 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:14:55 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:14:55 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:55 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:14:55 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:55 atjola kernel: EXT3 FS on md0, internal journal > Jan 20 07:14:55 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:14:55 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:14:55 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:14:55 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:55 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:55 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:14:55 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:14:55 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:14:55 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:55 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:14:55 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:55 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:14:55 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:14:55 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:14:55 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:55 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:55 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:14:55 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:14:55 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:14:55 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:14:55 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:55 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:55 atjola kernel: kjournald starting. Commit interval 5 seconds > Jan 20 07:14:55 atjola kernel: EXT3 FS on dm-4, internal journal > Jan 20 07:14:55 atjola kernel: EXT3-fs: mounted filesystem with ordered data mode. > Jan 20 07:14:55 atjola kernel: kjournald starting. Commit interval 5 seconds > Jan 20 07:14:55 atjola kernel: EXT3 FS on dm-0, internal journal > Jan 20 07:14:55 atjola kernel: EXT3-fs: mounted filesystem with ordered data mode. > Jan 20 07:14:55 atjola kernel: kjournald starting. Commit interval 5 seconds > Jan 20 07:14:55 atjola kernel: EXT3 FS on dm-1, internal journal > Jan 20 07:14:55 atjola kernel: EXT3-fs: mounted filesystem with ordered data mode. > Jan 20 07:14:55 atjola kernel: kjournald starting. Commit interval 5 seconds > Jan 20 07:14:55 atjola kernel: EXT3 FS on dm-3, internal journal > Jan 20 07:14:55 atjola kernel: EXT3-fs: mounted filesystem with ordered data mode. > Jan 20 07:14:55 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:14:55 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:55 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:14:55 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:14:55 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:14:55 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:14:55 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:14:55 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:14:55 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:14:55 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:14:55 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:14:55 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:55 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:14:55 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:14:55 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:55 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:14:55 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:14:55 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:14:55 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:55 atjola kernel: eth1: no link during initialization. > Jan 20 07:14:55 atjola kernel: tg3: eth0: Link is up at 100 Mbps, full duplex. > Jan 20 07:14:55 atjola kernel: tg3: eth0: Flow control is off for TX and off for RX. > Jan 20 07:14:55 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:14:55 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:14:55 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:14:55 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:55 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:55 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:14:55 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:14:55 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:14:55 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:14:55 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:55 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:55 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:14:55 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:55 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:14:55 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:14:55 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:14:55 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:55 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:14:55 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:14:55 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:14:55 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:14:55 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:55 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:56 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:14:56 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:14:56 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:56 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:14:56 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:56 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:14:56 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:14:56 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:14:56 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:56 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:14:56 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:57 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:14:57 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:14:57 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:57 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:14:57 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:14:57 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:14:57 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:57 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:14:57 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:57 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:14:57 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:57 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:14:57 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:57 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:14:57 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:57 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:14:57 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:57 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:14:57 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:14:57 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:14:57 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:57 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:14:57 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:57 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:14:57 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:14:57 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:14:57 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:14:57 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:14:57 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:57 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:14:57 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:14:57 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:57 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:14:57 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:14:57 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:58 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:14:58 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:58 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:14:58 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:14:58 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:14:58 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:14:58 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:14:58 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:58 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:14:58 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:14:58 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:14:58 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:58 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:58 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:14:58 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:14:58 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:14:58 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:14:58 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:14:58 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:14:58 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 [-- SNIP --] > Jan 20 07:15:09 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:09 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:15:09 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:15:09 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:09 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:09 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:09 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:15:09 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:15:09 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:15:09 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:09 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:09 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:09 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:11 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:15:11 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:15:11 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:11 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:11 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:11 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:15:11 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:11 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:15:11 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:11 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:15:11 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:11 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:15:11 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:15:11 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:11 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:11 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:11 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:15:11 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:15:11 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:15:11 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:11 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:11 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:12 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:15:12 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:15:12 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:12 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:12 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:12 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:15:12 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:15:12 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:15:12 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:12 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:12 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:12 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:15:12 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:12 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:15:12 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:12 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:15:12 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:15:12 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:15:12 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:12 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:15:12 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:12 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:15:12 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:15:12 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:15:12 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:15:12 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:15:12 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:15:12 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:15:12 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:13 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:15:13 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:15:13 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:13 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:13 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 [-- SNIP --] > Jan 20 07:15:22 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:22 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:15:22 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:15:22 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:15:22 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:22 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:22 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:22 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:15:22 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:15:22 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:15:22 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:22 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:22 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:23 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:23 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:23 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:15:23 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:15:23 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:23 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:23 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:23 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:23 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:15:24 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:24 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:15:24 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:15:24 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:15:24 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:24 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:15:24 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:15:24 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:15:24 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:24 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:15:24 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:15:24 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:15:24 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:24 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:15:24 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:24 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:15:24 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:24 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:15:24 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:24 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:15:24 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:24 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:15:24 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:15:24 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:15:24 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:24 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:24 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:15:24 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:15:24 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:15:24 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:15:24 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:15:24 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > > [-- SNIP --] > > Jan 20 07:26:38 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:38 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:26:38 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:38 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:26:38 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:38 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:26:38 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:38 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:38 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:38 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:26:38 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:38 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:26:38 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:26:38 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:41 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:26:41 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:26:41 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:41 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:41 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:41 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:26:41 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:26:41 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:41 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:26:41 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:41 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:26:41 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:26:41 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:41 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:41 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:41 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:26:41 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:26:41 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:26:41 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:41 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:41 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:41 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:42 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:42 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:42 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:42 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:42 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:42 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:42 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:42 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:42 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:42 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:26:42 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:42 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:26:42 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:26:42 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:42 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:42 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:42 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:42 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:42 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:42 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:42 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:26:42 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:42 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:26:42 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:26:42 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:42 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:42 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:42 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:42 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:42 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:26:42 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:26:42 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:42 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:26:42 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:26:42 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:42 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:42 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:42 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:42 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:42 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:26:42 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:26:42 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:42 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:26:42 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:42 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:26:42 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:26:42 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:42 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:26:42 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:26:42 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:42 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:42 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:46 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:26:46 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:46 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:26:46 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:26:46 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:26:46 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:46 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:26:46 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:26:46 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:26:46 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:46 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:26:46 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:46 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:26:46 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:26:46 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:26:46 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:46 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:46 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:46 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:26:46 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:26:46 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:26:46 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:46 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:26:46 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:47 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:26:47 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:47 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:26:47 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:26:47 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:26:47 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:26:47 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 [-- SNIP --] > Jan 20 07:26:57 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:26:57 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:57 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:26:57 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:57 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:26:57 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:26:57 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:26:57 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:57 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:57 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:57 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:26:57 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:57 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:57 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:57 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:26:57 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:57 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:57 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:57 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:26:57 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:26:57 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:26:58 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:00 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:00 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:00 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:00 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:00 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:00 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:00 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:00 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:00 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:00 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:00 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:00 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:01 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:01 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:01 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:01 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:01 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:01 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:01 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:01 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:01 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:02 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:02 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:02 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:02 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:02 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:02 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:02 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:02 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:02 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:02 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:02 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:02 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:02 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:02 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:02 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:02 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:02 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:02 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:02 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:02 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:02 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:02 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:27 atjola kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen > Jan 20 07:27:27 atjola kernel: ata1.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 in > Jan 20 07:27:27 atjola kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) > Jan 20 07:27:28 atjola kernel: ata1: soft resetting port > Jan 20 07:27:28 atjola kernel: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) > Jan 20 07:27:28 atjola kernel: ata1.00: configured for UDMA/133 > Jan 20 07:27:28 atjola kernel: ata1: EH complete > Jan 20 07:27:28 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:27:28 atjola kernel: SCSI device sda: 160086528 512-byte hdwr sectors (81964 MB) > Jan 20 07:27:28 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:27:28 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:27:28 atjola kernel: sda: Write Protect is off > Jan 20 07:27:28 atjola kernel: sda: Mode Sense: 00 3a 00 00 > Jan 20 07:27:28 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:27:28 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:27:28 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:27:28 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:27:28 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:27:28 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:27:28 atjola kernel: SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA > Jan 20 07:27:28 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:28 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:28 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:27:28 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:27:28 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:27:28 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:27:28 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:27:28 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:27:28 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:27:28 atjola kernel: ata1: cmd 0xe7 active but stat 0x10 > Jan 20 07:27:28 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:27:28 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:27:28 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:27:28 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:27:28 atjola kernel: ata1: issue flush cmd 0xe7 > Jan 20 07:27:28 atjola kernel: ata1: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:27:28 atjola kernel: ata2: cmd 0xe7 active but stat 0x0 > Jan 20 07:27:28 atjola kernel: ata2: cmd 0xe7 active, stat = 0x1, handled = 0x1 > Jan 20 07:27:28 atjola kernel: ata2: issue flush cmd 0xe7 > Jan 20 07:27:28 atjola kernel: ata1: issue flush cmd 0xe7 > > [More of the same...] ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-20 2:41 ` Robert Hancock ` (2 preceding siblings ...) [not found] ` <20070120072755.GA4652@atjola.homenet> @ 2007-01-20 18:50 ` Chr 2007-01-20 22:32 ` Chr 4 siblings, 0 replies; 71+ messages in thread From: Chr @ 2007-01-20 18:50 UTC (permalink / raw) To: Robert Hancock Cc: Alistair John Strachan, Jeff Garzik, Björn Steinbrink, linux-kernel, htejun, jens.axboe, lwalton, chunkeey [-- Attachment #1: Type: text/plain, Size: 1735 bytes --] On Saturday, 20. January 2007 03:41, Robert Hancock wrote: > Alistair John Strachan wrote: > > On Tuesday 16 January 2007 01:53, Jeff Garzik wrote: > >> Robert Hancock wrote: > >>> I'll try your stress test when I get a chance, but I doubt I'll run > >>> into the same problem and I haven't seen any similar reports. Perhaps > >>> it's some kind of wierd timing issue or incompatibility between the > >>> controller and that drive when running in ADMA mode? I seem to remember > >>> various reports of issues with certain Maxtor drives and some nForce > >>> SATA controllers under Windows at least.. > >> > >> Just to eliminate things, has disabling ADMA been attempted? > >> > >> It can be disabled using the sata_nv.adma module parameter. > > > > Setting this option fixes the problem for me. I suggest that ADMA > > defaults off in 2.6.20, if there's still time to do that. > > Can you guys that are having this problem try the attached debug patch? > It's possible it will fix the problem, as I'm trying a private > exec_command implementation that flushes the write by reading a > controller register instead of reading altstatus from the drive like the > libata core code does. > > If the problem still happens, I also added some more debugging in to > help figure out what is going on, so please post full dmesg. > > By the way, I assume that you guys are using reiserfs or xfs, as it > appears no other file systems issue flush commands automatically. I had > to test this by "echo 1 > delete" on the SCSI disk in sysfs, as I am > using ext3. Yes, I've some reiserfs partitions, but I don't think it's reiserfs fault ;). Here is the log. (I cut out some parts, because it was too big.) BTW: please CC, I'm not on the list! [-- Attachment #2: kern.log --] [-- Type: text/x-log, Size: 38488 bytes --] 18:17:29 sys kernel: Linux version 2.6.20-rc5 (root@sys) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #2 SMP PREEMPT Sat 18:07:36 CET 2007 18:17:29 sys kernel: Command line: root=/dev/md1 ro 18:17:29 sys kernel: BIOS-provided physical RAM map: 18:17:29 sys kernel: BIOS-e820: 0000000000000000 - 000000000009f800 (usable) 18:17:29 sys kernel: BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) 18:17:29 sys kernel: BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) 18:17:29 sys kernel: BIOS-e820: 0000000000100000 - 000000007fff0000 (usable) 18:17:29 sys kernel: BIOS-e820: 000000007fff0000 - 000000007fff3000 (ACPI NVS) 18:17:29 sys kernel: BIOS-e820: 000000007fff3000 - 0000000080000000 (ACPI data) 18:17:29 sys kernel: BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) 18:17:29 sys kernel: BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved) 18:17:29 sys kernel: Entering add_active_range(0, 0, 159) 0 entries of 256 used 18:17:29 sys kernel: Entering add_active_range(0, 256, 524272) 1 entries of 256 used 18:17:29 sys kernel: end_pfn_map = 1048576 18:17:29 sys kernel: DMI 2.3 present. 18:17:29 sys kernel: ACPI: RSDP (v000 Nvidia ) @ 0x00000000000f7d30 18:17:29 sys kernel: ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x000000007fff3040 18:17:29 sys kernel: ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x000000007fff30c0 18:17:29 sys kernel: ACPI: SSDT (v001 PTLTD POWERNOW 0x00000001 LTP 0x00000001) @ 0x000000007fff9900 18:17:29 sys kernel: ACPI: SRAT (v001 AMD HAMMER 0x00000001 AMD 0x00000001) @ 0x000000007fff9b40 18:17:29 sys kernel: ACPI: MCFG (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x000000007fff9c40 18:17:29 sys kernel: ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x000000007fff9840 18:17:29 sys kernel: ACPI: DSDT (v001 NVIDIA AWRDACPI 0x00001000 MSFT 0x0100000e) @ 0x0000000000000000 18:17:29 sys kernel: Entering add_active_range(0, 0, 159) 0 entries of 256 used 18:17:29 sys kernel: Entering add_active_range(0, 256, 524272) 1 entries of 256 used 18:17:29 sys kernel: Zone PFN ranges: 18:17:29 sys kernel: DMA 0 -> 4096 18:17:29 sys kernel: DMA32 4096 -> 1048576 18:17:29 sys kernel: Normal 1048576 -> 1048576 18:17:29 sys kernel: early_node_map[2] active PFN ranges 18:17:29 sys kernel: 0: 0 -> 159 18:17:29 sys kernel: 0: 256 -> 524272 18:17:29 sys kernel: On node 0 totalpages: 524175 18:17:29 sys kernel: DMA zone: 56 pages used for memmap 18:17:29 sys kernel: DMA zone: 10 pages reserved 18:17:29 sys kernel: DMA zone: 3933 pages, LIFO batch:0 18:17:29 sys kernel: DMA32 zone: 7111 pages used for memmap 18:17:29 sys kernel: DMA32 zone: 513065 pages, LIFO batch:31 18:17:29 sys kernel: Normal zone: 0 pages used for memmap 18:17:29 sys kernel: Nvidia board detected. Ignoring ACPI timer override. 18:17:29 sys kernel: If you got timer trouble try acpi_use_timer_override 18:17:29 sys kernel: ACPI: PM-Timer IO Port: 0x4008 18:17:29 sys kernel: ACPI: Local APIC address 0xfee00000 18:17:29 sys kernel: ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) 18:17:29 sys kernel: Processor #0 (Bootup-CPU) 18:17:29 sys kernel: ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) 18:17:29 sys kernel: Processor #1 18:17:29 sys kernel: ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) 18:17:29 sys kernel: ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) 18:17:29 sys kernel: ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) 18:17:29 sys kernel: IOAPIC[0]: apic_id 2, address 0xfec00000, GSI 0-23 18:17:29 sys kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) 18:17:29 sys kernel: ACPI: BIOS IRQ0 pin2 override ignored. 18:17:29 sys kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) 18:17:29 sys kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) 18:17:29 sys kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) 18:17:29 sys kernel: ACPI: IRQ9 used by override. 18:17:29 sys kernel: ACPI: IRQ14 used by override. 18:17:29 sys kernel: ACPI: IRQ15 used by override. 18:17:29 sys kernel: Setting APIC routing to physical flat 18:17:29 sys kernel: Using ACPI (MADT) for SMP configuration information 18:17:29 sys kernel: Nosave address range: 000000000009f000 - 00000000000a0000 18:17:29 sys kernel: Nosave address range: 00000000000a0000 - 00000000000f0000 18:17:29 sys kernel: Nosave address range: 00000000000f0000 - 0000000000100000 18:17:29 sys kernel: Allocating PCI resources starting at 88000000 (gap: 80000000:60000000) 18:17:29 sys kernel: SMP: Allowing 2 CPUs, 0 hotplug CPUs 18:17:29 sys kernel: PERCPU: Allocating 32320 bytes of per cpu data 18:17:29 sys kernel: Built 1 zonelists. Total pages: 516998 18:17:29 sys kernel: Kernel command line: root=/dev/md1 ro 18:17:29 sys kernel: Initializing CPU#0 18:17:29 sys kernel: PID hash table entries: 4096 (order: 12, 32768 bytes) 18:17:29 sys kernel: Console: colour VGA+ 80x25 18:17:29 sys kernel: Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) 18:17:29 sys kernel: Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) 18:17:29 sys kernel: Checking aperture... 18:17:29 sys kernel: CPU 0: aperture @ 1844000000 size 32 MB 18:17:29 sys kernel: Aperture too small (32 MB) 18:17:29 sys kernel: No AGP bridge found 18:17:29 sys kernel: Memory: 2059096k/2097088k available (3034k kernel code, 37160k reserved, 1443k data, 212k init) 18:17:29 sys kernel: Calibrating delay using timer specific routine.. 4425.38 BogoMIPS (lpj=8850763) 18:17:29 sys kernel: Security Framework v1.0.0 initialized 18:17:29 sys kernel: SELinux: Disabled at boot. 18:17:29 sys kernel: Capability LSM initialized 18:17:29 sys kernel: Mount-cache hash table entries: 256 18:17:29 sys kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) 18:17:29 sys kernel: CPU: L2 Cache: 512K (64 bytes/line) 18:17:29 sys kernel: CPU: Physical Processor ID: 0 18:17:29 sys kernel: CPU: Processor Core ID: 0 18:17:29 sys kernel: SMP alternatives: switching to UP code 18:17:29 sys kernel: ACPI: Core revision 20060707 18:17:29 sys kernel: Using local APIC timer interrupts. 18:17:29 sys kernel: result 12564593 18:17:29 sys kernel: Detected 12.564 MHz APIC timer. 18:17:29 sys kernel: SMP alternatives: switching to SMP code 18:17:29 sys kernel: Booting processor 1/2 APIC 0x1 18:17:29 sys kernel: Initializing CPU#1 18:17:29 sys kernel: Calibrating delay using timer specific routine.. 4423.04 BogoMIPS (lpj=8846096) 18:17:29 sys kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) 18:17:29 sys kernel: CPU: L2 Cache: 512K (64 bytes/line) 18:17:29 sys kernel: CPU: Physical Processor ID: 0 18:17:29 sys kernel: CPU: Processor Core ID: 1 18:17:29 sys kernel: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ stepping 01 18:17:29 sys kernel: CPU 1: Syncing TSC to CPU 0. 18:17:29 sys kernel: CPU 1: synchronized TSC with CPU 0 (last diff 21 cycles, maxerr 507 cycles) 18:17:29 sys kernel: Brought up 2 CPUs 18:17:29 sys kernel: testing NMI watchdog ... OK. 18:17:29 sys kernel: Disabling vsyscall due to use of PM timer 18:17:29 sys kernel: time.c: Using 3.579545 MHz WALL PM GTOD PM timer. 18:17:29 sys kernel: time.c: Detected 2211.364 MHz processor. 18:17:29 sys kernel: migration_cost=216 18:17:29 sys kernel: NET: Registered protocol family 16 18:17:29 sys kernel: ACPI: bus type pci registered 18:17:29 sys kernel: PCI: Using MMCONFIG at e0000000 18:17:29 sys kernel: PCI: No mmconfig possible on device 00:18 18:17:29 sys kernel: ACPI: Interpreter enabled 18:17:29 sys kernel: ACPI: Using IOAPIC for interrupt routing 18:17:29 sys kernel: ACPI: PCI Root Bridge [PCI0] (0000:00) 18:17:29 sys kernel: PCI: Probing PCI hardware (bus 00) 18:17:29 sys kernel: PCI: Transparent bridge - 0000:00:09.0 18:17:29 sys kernel: Boot video device is 0000:01:00.0 18:17:29 sys kernel: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] 18:17:29 sys kernel: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT] 18:17:29 sys kernel: ACPI: PCI Interrupt Link [LNK1] (IRQs *3 4 5 7 9 10 11 12 14 15) 18:17:29 sys kernel: ACPI: PCI Interrupt Link [LNK2] (IRQs 3 4 5 7 9 10 11 *12 14 15) 18:17:29 sys kernel: ACPI: PCI Interrupt Link [LNK3] (IRQs 3 4 *5 7 9 10 11 12 14 15) 18:17:29 sys kernel: ACPI: PCI Interrupt Link [LNK4] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled. 18:17:29 sys kernel: ACPI: PCI Interrupt Link [LNK5] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled. 18:17:29 sys kernel: ACPI: PCI Interrupt Link [LUBA] (IRQs 3 *4 5 7 9 10 11 12 14 15) 18:17:29 sys kernel: ACPI: PCI Interrupt Link [LUBB] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled. 18:17:29 sys kernel: ACPI: PCI Interrupt Link [LMAC] (IRQs 3 4 5 *7 9 10 11 12 14 15) 18:17:29 sys kernel: ACPI: PCI Interrupt Link [LACI] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled. 18:17:29 sys kernel: ACPI: PCI Interrupt Link [LMCI] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled. 18:17:29 sys kernel: ACPI: PCI Interrupt Link [LSMB] (IRQs 3 4 5 7 9 *10 11 12 14 15) 18:17:29 sys kernel: ACPI: PCI Interrupt Link [LUB2] (IRQs 3 4 5 7 9 10 *11 12 14 15) 18:17:29 sys kernel: ACPI: PCI Interrupt Link [LIDE] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled. 18:17:29 sys kernel: ACPI: PCI Interrupt Link [LSID] (IRQs 3 4 5 7 9 10 *11 12 14 15) 18:17:29 sys kernel: ACPI: PCI Interrupt Link [LFID] (IRQs 3 4 *5 7 9 10 11 12 14 15) 18:17:29 sys kernel: ACPI: PCI Interrupt Link [LPCA] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled. 18:17:29 sys kernel: ACPI: PCI Interrupt Link [APC1] (IRQs 16) *0, disabled. 18:17:29 sys kernel: ACPI: PCI Interrupt Link [APC2] (IRQs 17) *0, disabled. 18:17:29 sys kernel: ACPI: PCI Interrupt Link [APC3] (IRQs 18) *0, disabled. 18:17:29 sys kernel: ACPI: PCI Interrupt Link [APC4] (IRQs 19) *0, disabled. 18:17:29 sys kernel: ACPI: PCI Interrupt Link [APC5] (IRQs *16), disabled. 18:17:29 sys kernel: ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22 23) *0, disabled. 18:17:29 sys kernel: ACPI: PCI Interrupt Link [APCG] (IRQs 20 21 22 23) *0, disabled. 18:17:29 sys kernel: ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22 23) *0, disabled. 18:17:29 sys kernel: ACPI: PCI Interrupt Link [APCJ] (IRQs 20 21 22 23) *0, disabled. 18:17:29 sys kernel: ACPI: PCI Interrupt Link [APCK] (IRQs 20 21 22 23) *0, disabled. 18:17:29 sys kernel: ACPI: PCI Interrupt Link [APCS] (IRQs 20 21 22 23) *0, disabled. 18:17:29 sys kernel: ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22 23) *0, disabled. 18:17:29 sys kernel: ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22 23) *0, disabled. 18:17:29 sys kernel: ACPI: PCI Interrupt Link [APSI] (IRQs 20 21 22 23) *0, disabled. 18:17:29 sys kernel: ACPI: PCI Interrupt Link [APSJ] (IRQs 20 21 22 23) *0, disabled. 18:17:29 sys kernel: ACPI: PCI Interrupt Link [APCP] (IRQs 20 21 22 23) *0, disabled. 18:17:29 sys kernel: Linux Plug and Play Support v0.97 (c) Adam Belay 18:17:29 sys kernel: pnp: PnP ACPI init 18:17:29 sys kernel: pnp: PnP ACPI: found 11 devices 18:17:29 sys kernel: SCSI subsystem initialized 18:17:29 sys kernel: libata version 2.00 loaded. 18:17:29 sys kernel: usbcore: registered new interface driver usbfs 18:17:29 sys kernel: usbcore: registered new interface driver hub 18:17:29 sys kernel: usbcore: registered new device driver usb 18:17:29 sys kernel: PCI: Using ACPI for IRQ routing 18:17:29 sys kernel: PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report 18:17:29 sys kernel: pnp: 00:01: ioport range 0x4000-0x407f could not be reserved 18:17:29 sys kernel: pnp: 00:01: ioport range 0x4080-0x40ff has been reserved 18:17:29 sys kernel: pnp: 00:01: ioport range 0x4400-0x447f has been reserved 18:17:29 sys kernel: pnp: 00:01: ioport range 0x4480-0x44ff could not be reserved 18:17:29 sys kernel: pnp: 00:01: ioport range 0x4800-0x487f has been reserved 18:17:29 sys kernel: pnp: 00:01: ioport range 0x4880-0x48ff has been reserved 18:17:29 sys kernel: PCI: Bridge: 0000:00:09.0 18:17:29 sys kernel: IO window: a000-afff 18:17:29 sys kernel: MEM window: d0000000-d1ffffff 18:17:29 sys kernel: PREFETCH window: 88000000-880fffff 18:17:29 sys kernel: PCI: Bridge: 0000:00:0b.0 18:17:29 sys kernel: IO window: disabled. 18:17:29 sys kernel: MEM window: disabled. 18:17:29 sys kernel: PREFETCH window: disabled. 18:17:29 sys kernel: PCI: Bridge: 0000:00:0c.0 18:17:29 sys kernel: IO window: disabled. 18:17:29 sys kernel: MEM window: disabled. 18:17:29 sys kernel: PREFETCH window: disabled. 18:17:29 sys kernel: PCI: Bridge: 0000:00:0d.0 18:17:29 sys kernel: IO window: disabled. 18:17:29 sys kernel: MEM window: disabled. 18:17:29 sys kernel: PREFETCH window: disabled. 18:17:29 sys kernel: PCI: Bridge: 0000:00:0e.0 18:17:29 sys kernel: IO window: disabled. 18:17:29 sys kernel: MEM window: c8000000-cfffffff 18:17:29 sys kernel: PREFETCH window: c0000000-c7ffffff 18:17:29 sys kernel: PCI: Setting latency timer of device 0000:00:09.0 to 64 18:17:29 sys kernel: PCI: Setting latency timer of device 0000:00:0b.0 to 64 18:17:29 sys kernel: PCI: Setting latency timer of device 0000:00:0c.0 to 64 18:17:29 sys kernel: PCI: Setting latency timer of device 0000:00:0d.0 to 64 18:17:29 sys kernel: PCI: Setting latency timer of device 0000:00:0e.0 to 64 18:17:29 sys kernel: NET: Registered protocol family 2 18:17:29 sys kernel: IP route cache hash table entries: 65536 (order: 7, 524288 bytes) 18:17:29 sys kernel: TCP established hash table entries: 262144 (order: 10, 4194304 bytes) 18:17:29 sys kernel: TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) 18:17:29 sys kernel: TCP: Hash tables configured (established 262144 bind 65536) 18:17:29 sys kernel: TCP reno registered 18:17:29 sys kernel: audit: initializing netlink socket (disabled) 18:17:29 sys kernel: audit(1169313393.480:1): initialized 18:17:29 sys kernel: VFS: Disk quotas dquot_6.5.1 18:17:29 sys kernel: Dquot-cache hash table entries: 512 (order 0, 4096 bytes) 18:17:29 sys kernel: JFS: nTxBlock = 8192, nTxLock = 65536 18:17:29 sys kernel: SGI XFS with large block/inode numbers, no debug enabled 18:17:29 sys kernel: SGI XFS Quota Management subsystem 18:17:29 sys kernel: io scheduler noop registered 18:17:29 sys kernel: io scheduler cfq registered (default) 18:17:29 sys kernel: PCI: Linking AER extended capability on 0000:00:0b.0 18:17:29 sys kernel: PCI: Found disabled HT MSI Mapping on 0000:00:0b.0 18:17:29 sys kernel: PCI: Found enabled HT MSI Mapping on 0000:00:00.0 18:17:29 sys kernel: PCI: Linking AER extended capability on 0000:00:0c.0 18:17:29 sys kernel: PCI: Found disabled HT MSI Mapping on 0000:00:0c.0 18:17:29 sys kernel: PCI: Found enabled HT MSI Mapping on 0000:00:00.0 18:17:29 sys kernel: PCI: Linking AER extended capability on 0000:00:0d.0 18:17:29 sys kernel: PCI: Found disabled HT MSI Mapping on 0000:00:0d.0 18:17:29 sys kernel: PCI: Found enabled HT MSI Mapping on 0000:00:00.0 18:17:29 sys kernel: PCI: Linking AER extended capability on 0000:00:0e.0 18:17:29 sys kernel: PCI: Found disabled HT MSI Mapping on 0000:00:0e.0 18:17:29 sys kernel: PCI: Found enabled HT MSI Mapping on 0000:00:00.0 18:17:29 sys kernel: PCI: Setting latency timer of device 0000:00:0b.0 to 64 18:17:29 sys kernel: assign_interrupt_mode Found MSI capability 18:17:29 sys kernel: Allocate Port Service[0000:00:0b.0:pcie00] 18:17:29 sys kernel: Allocate Port Service[0000:00:0b.0:pcie03] 18:17:29 sys kernel: PCI: Setting latency timer of device 0000:00:0c.0 to 64 18:17:29 sys kernel: assign_interrupt_mode Found MSI capability 18:17:29 sys kernel: Allocate Port Service[0000:00:0c.0:pcie00] 18:17:29 sys kernel: Allocate Port Service[0000:00:0c.0:pcie03] 18:17:29 sys kernel: PCI: Setting latency timer of device 0000:00:0d.0 to 64 18:17:29 sys kernel: assign_interrupt_mode Found MSI capability 18:17:29 sys kernel: Allocate Port Service[0000:00:0d.0:pcie00] 18:17:29 sys kernel: Allocate Port Service[0000:00:0d.0:pcie03] 18:17:29 sys kernel: PCI: Setting latency timer of device 0000:00:0e.0 to 64 18:17:29 sys kernel: assign_interrupt_mode Found MSI capability 18:17:29 sys kernel: Allocate Port Service[0000:00:0e.0:pcie00] 18:17:29 sys kernel: Allocate Port Service[0000:00:0e.0:pcie03] 18:17:29 sys kernel: input: Power Button (FF) as /class/input/input0 18:17:29 sys kernel: ACPI: Power Button (FF) [PWRF] 18:17:29 sys kernel: input: Power Button (CM) as /class/input/input1 18:17:29 sys kernel: ACPI: Power Button (CM) [PWRB] 18:17:29 sys kernel: Real Time Clock Driver v1.12ac 18:17:29 sys kernel: Linux agpgart interface v0.101 (c) Dave Jones 18:17:29 sys kernel: Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled 18:17:29 sys kernel: Floppy drive(s): fd0 is 1.44M 18:17:29 sys kernel: FDC 0 is a post-1991 82077 18:17:29 sys kernel: RAMDISK driver initialized: 4 RAM disks of 4096K size 1024 blocksize 18:17:29 sys kernel: loop: loaded (max 8 devices) 18:17:29 sys kernel: sata_nv 0000:00:07.0: version 3.2 18:17:29 sys kernel: ACPI: PCI Interrupt Link [APSI] enabled at IRQ 23 18:17:29 sys kernel: ACPI: PCI Interrupt 0000:00:07.0[A] -> Link [APSI] -> GSI 23 (level, low) -> IRQ 23 18:17:29 sys kernel: sata_nv 0000:00:07.0: Using ADMA mode 18:17:29 sys kernel: PCI: Setting latency timer of device 0000:00:07.0 to 64 18:17:29 sys kernel: ata1: SATA max UDMA/133 cmd 0xFFFFC20000028480 ctl 0xFFFFC200000284A0 bmdma 0xD800 irq 23 18:17:29 sys kernel: ata2: SATA max UDMA/133 cmd 0xFFFFC20000028580 ctl 0xFFFFC200000285A0 bmdma 0xD808 irq 23 18:17:29 sys kernel: scsi0 : sata_nv 18:17:29 sys kernel: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) 18:17:29 sys kernel: ata1.00: ATAPI, max UDMA/33 18:17:29 sys kernel: ata1.00: configured for UDMA/33 18:17:29 sys kernel: scsi1 : sata_nv 18:17:29 sys kernel: ata2: SATA link down (SStatus 0 SControl 300) 18:17:29 sys kernel: scsi 0:0:0:0: CD-ROM TSSTcorp CD/DVDW SH-S183L SB00 PQ: 0 ANSI: 5 18:17:29 sys kernel: ata1: bounce limit 0xFFFFFFFF, segment boundary 0xFFFF, hw segs 127 18:17:29 sys kernel: sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray 18:17:29 sys kernel: Uniform CD-ROM driver Revision: 3.20 18:17:29 sys kernel: sr 0:0:0:0: Attached scsi CD-ROM sr0 18:17:29 sys kernel: sr 0:0:0:0: Attached scsi generic sg0 type 5 18:17:29 sys kernel: ACPI: PCI Interrupt Link [APSJ] enabled at IRQ 22 18:17:29 sys kernel: ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [APSJ] -> GSI 22 (level, low) -> IRQ 22 18:17:29 sys kernel: sata_nv 0000:00:08.0: Using ADMA mode 18:17:29 sys kernel: PCI: Setting latency timer of device 0000:00:08.0 to 64 18:17:29 sys kernel: ata3: SATA max UDMA/133 cmd 0xFFFFC2000002A480 ctl 0xFFFFC2000002A4A0 bmdma 0xC400 irq 22 18:17:29 sys kernel: ata4: SATA max UDMA/133 cmd 0xFFFFC2000002A580 ctl 0xFFFFC2000002A5A0 bmdma 0xC408 irq 22 18:17:29 sys kernel: scsi2 : sata_nv 18:17:29 sys kernel: ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) 18:17:29 sys kernel: ata3.00: ATA-7, max UDMA/133, 488395055 sectors: LBA48 18:17:29 sys kernel: ata3.00: ata3: dev 0 multi count 1 18:17:29 sys kernel: ata3.00: configured for UDMA/133 18:17:29 sys kernel: scsi3 : sata_nv 18:17:29 sys kernel: ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300) 18:17:29 sys kernel: ata4.00: ATA-7, max UDMA/133, 490234752 sectors: LBA48 NCQ (depth 1) 18:17:29 sys kernel: ata4.00: ata4: dev 0 multi count 1 18:17:29 sys kernel: ata4.00: configured for UDMA/133 18:17:29 sys kernel: scsi 2:0:0:0: Direct-Access ATA WDC WD2500KS-00M 02.0 PQ: 0 ANSI: 5 18:17:29 sys kernel: ata3: bounce limit 0xFFFFFFFFFFFFFFFF, segment boundary 0xFFFFFFFF, hw segs 61 18:17:29 sys kernel: SCSI device sda: 488395055 512-byte hdwr sectors (250058 MB) 18:17:29 sys kernel: sda: Write Protect is off 18:17:29 sys kernel: sda: Mode Sense: 00 3a 00 00 18:17:29 sys kernel: SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA 18:17:29 sys kernel: SCSI device sda: 488395055 512-byte hdwr sectors (250058 MB) 18:17:29 sys kernel: sda: Write Protect is off 18:17:29 sys kernel: sda: Mode Sense: 00 3a 00 00 18:17:29 sys kernel: SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA 18:17:29 sys kernel: sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 sda9 sda10 sda11 sda12 > 18:17:29 sys kernel: sd 2:0:0:0: Attached scsi disk sda 18:17:29 sys kernel: sd 2:0:0:0: Attached scsi generic sg1 type 0 18:17:29 sys kernel: scsi 3:0:0:0: Direct-Access ATA WDC WD2500YD-01N 10.0 PQ: 0 ANSI: 5 18:17:29 sys kernel: ata4: bounce limit 0xFFFFFFFFFFFFFFFF, segment boundary 0xFFFFFFFF, hw segs 61 18:17:29 sys kernel: SCSI device sdb: 490234752 512-byte hdwr sectors (251000 MB) 18:17:29 sys kernel: sdb: Write Protect is off 18:17:29 sys kernel: sdb: Mode Sense: 00 3a 00 00 18:17:29 sys kernel: SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA 18:17:29 sys kernel: SCSI device sdb: 490234752 512-byte hdwr sectors (251000 MB) 18:17:29 sys kernel: sdb: Write Protect is off 18:17:29 sys kernel: sdb: Mode Sense: 00 3a 00 00 18:17:29 sys kernel: SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA 18:17:29 sys kernel: sdb: sdb1 sdb2 sdb3 < sdb5 sdb6 sdb7 sdb8 sdb9 sdb10 sdb11 sdb12 > 18:17:29 sys kernel: sd 3:0:0:0: Attached scsi disk sdb 18:17:29 sys kernel: sd 3:0:0:0: Attached scsi generic sg2 type 0 18:17:29 sys kernel: pata_amd 0000:00:06.0: version 0.2.7 18:17:29 sys kernel: PCI: Setting latency timer of device 0000:00:06.0 to 64 18:17:29 sys kernel: ata5: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14 18:17:29 sys kernel: ata6: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15 18:17:29 sys kernel: scsi4 : pata_amd 18:17:29 sys kernel: ata5.00: ATA-6, max UDMA/100, 156299375 sectors: LBA48 18:17:29 sys kernel: ata5.00: ata5: dev 0 multi count 1 18:17:29 sys kernel: ata5.00: configured for UDMA/100 18:17:29 sys kernel: scsi5 : pata_amd 18:17:29 sys kernel: ata6.00: ATAPI, max UDMA/33 18:17:29 sys kernel: ata6.00: configured for UDMA/33 18:17:29 sys kernel: scsi 4:0:0:0: Direct-Access ATA WDC WD800JB-00ET 77.0 PQ: 0 ANSI: 5 18:17:29 sys kernel: SCSI device sdc: 156299375 512-byte hdwr sectors (80025 MB) 18:17:29 sys kernel: sdc: Write Protect is off 18:17:29 sys kernel: sdc: Mode Sense: 00 3a 00 00 18:17:29 sys kernel: SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support DPO or FUA 18:17:29 sys kernel: SCSI device sdc: 156299375 512-byte hdwr sectors (80025 MB) 18:17:29 sys kernel: sdc: Write Protect is off 18:17:29 sys kernel: sdc: Mode Sense: 00 3a 00 00 18:17:29 sys kernel: SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support DPO or FUA 18:17:29 sys kernel: sdc: sdc1 sdc2 18:17:29 sys kernel: sd 4:0:0:0: Attached scsi disk sdc 18:17:29 sys kernel: sd 4:0:0:0: Attached scsi generic sg3 type 0 18:17:29 sys kernel: scsi 5:0:0:0: CD-ROM PIONEER DVD-ROM DVD-105 1.33 PQ: 0 ANSI: 5 18:17:29 sys kernel: sr1: scsi3-mmc drive: 16x/40x cd/rw xa/form2 cdda tray 18:17:29 sys kernel: sr 5:0:0:0: Attached scsi CD-ROM sr1 18:17:29 sys kernel: sr 5:0:0:0: Attached scsi generic sg4 type 5 18:17:29 sys kernel: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1 18:17:29 sys kernel: PNP: PS/2 controller doesn't have AUX irq; using default 12 18:17:29 sys kernel: serio: i8042 KBD port at 0x60,0x64 irq 1 18:17:29 sys kernel: mice: PS/2 mouse device common for all mice 18:17:29 sys kernel: input: PC Speaker as /class/input/input2 18:17:29 sys kernel: input: AT Translated Set 2 keyboard as /class/input/input3 18:17:29 sys kernel: md: linear personality registered for level -1 18:17:29 sys kernel: md: raid0 personality registered for level 0 18:17:29 sys kernel: md: raid1 personality registered for level 1 18:17:29 sys kernel: md: raid10 personality registered for level 10 18:17:29 sys kernel: device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel@redhat.com 18:17:29 sys kernel: device-mapper: multipath: version 1.0.5 loaded 18:17:29 sys kernel: device-mapper: multipath round-robin: version 1.0.0 loaded 18:17:29 sys kernel: EDAC MC: Ver: 2.0.1 2007 18:17:29 sys kernel: TCP cubic registered 18:17:29 sys kernel: Initializing XFRM netlink socket 18:17:29 sys kernel: NET: Registered protocol family 1 18:17:29 sys kernel: NET: Registered protocol family 17 18:17:29 sys kernel: NET: Registered protocol family 15 18:17:29 sys kernel: ieee80211: 802.11 data/management/control stack, git-1.1.13 18:17:29 sys kernel: ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com> 18:17:29 sys kernel: ieee80211_crypt: registered algorithm 'NULL' 18:17:29 sys kernel: ieee80211_crypt: registered algorithm 'WEP' 18:17:29 sys kernel: ACPI: (supports S0 S1 S3 S4 S5) 18:17:29 sys kernel: drivers/rtc/hctosys.c: unable to open rtc device (rtc0) 18:17:29 sys kernel: md: Autodetecting RAID arrays. 18:17:29 sys kernel: md: autorun ... [..] 18:17:29 sys kernel: md: ... autorun DONE. 18:17:29 sys kernel: ReiserFS: md1: found reiserfs format "3.6" with standard journal 18:17:29 sys kernel: ReiserFS: md1: using ordered data mode 18:17:29 sys kernel: ReiserFS: md1: journal params: device md1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 18:17:29 sys kernel: ReiserFS: md1: checking transaction log (md1) 18:17:29 sys kernel: ReiserFS: md1: Using r5 hash to sort names 18:17:29 sys kernel: VFS: Mounted root (reiserfs filesystem) readonly. 18:17:29 sys kernel: Freeing unused kernel memory: 212k freed 18:17:29 sys kernel: ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17 18:17:29 sys kernel: ACPI: PCI Interrupt 0000:05:0c.0[A] -> Link [APC2] -> GSI 17 (level, low) -> IRQ 17 18:17:29 sys kernel: skge 1.9 addr 0xd1004000 irq 17 chip Yukon-Lite rev 9 18:17:29 sys kernel: skge eth0: addr 00:15:f2:50:d7:70 18:17:29 sys kernel: forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.59. 18:17:29 sys kernel: ACPI: PCI Interrupt Link [APCH] enabled at IRQ 21 18:17:29 sys kernel: ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [APCH] -> GSI 21 (level, low) -> IRQ 21 18:17:29 sys kernel: PCI: Setting latency timer of device 0000:00:0a.0 to 64 18:17:29 sys kernel: forcedeth: using HIGHDMA 18:17:29 sys kernel: ieee1394: Initialized config rom entry `ip1394' 18:17:29 sys kernel: eth0: forcedeth.c: subsystem: 01043:8141 bound to 0000:00:0a.0 18:17:29 sys kernel: ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18 18:17:29 sys kernel: ACPI: PCI Interrupt 0000:05:07.2[B] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 18 18:17:29 sys kernel: ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[18] MMIO=[d100f000-d100f7ff] Max Packet=[2048] IR/IT contexts=[4/8] 18:17:29 sys kernel: ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16 18:17:29 sys kernel: ACPI: PCI Interrupt 0000:05:0b.0[A] -> Link [APC1] -> GSI 16 (level, low) -> IRQ 16 18:17:29 sys kernel: ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI) 18:17:29 sys kernel: ACPI: PCI Interrupt Link [APCF] enabled at IRQ 20 18:17:29 sys kernel: ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [APCF] -> GSI 20 (level, low) -> IRQ 20 [..] 18:17:29 sys kernel: ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [APCL] -> GSI 23 (level, low) -> IRQ 23 18:17:29 sys kernel: PCI: Setting latency timer of device 0000:00:02.1 to 64 18:17:29 sys kernel: ehci_hcd 0000:00:02.1: EHCI Host Controller 18:17:29 sys kernel: ehci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 2 18:17:29 sys kernel: ehci_hcd 0000:00:02.1: debug port 1 18:17:29 sys kernel: PCI: cache line size of 64 is not supported by device 0000:00:02.1 18:17:29 sys kernel: ehci_hcd 0000:00:02.1: irq 23, io mem 0xfeb00000 18:17:29 sys kernel: ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 18:17:29 sys kernel: usb usb2: configuration #1 chosen from 1 choice 18:17:29 sys kernel: i2c_adapter i2c-0: nForce2 SMBus adapter at 0x4c00 18:17:29 sys kernel: i2c_adapter i2c-1: nForce2 SMBus adapter at 0x4c40 18:17:29 sys kernel: gameport: EMU10K1 is pci0000:05:07.1/gameport0, io 0xa400, speed 1205kHz 18:17:29 sys kernel: ACPI: PCI Interrupt 0000:05:07.0[A] -> Link [APC2] -> GSI 17 (level, low) -> IRQ 17 18:17:29 sys kernel: Installing spdif_bug patch: Audigy 2 ZS [SB0350] 18:17:29 sys kernel: usb 1-4: new low speed USB device using ohci_hcd and address 2 18:17:29 sys kernel: usb 1-4: configuration #1 chosen from 1 choice 18:17:29 sys kernel: usbcore: registered new interface driver hiddev 18:17:29 sys kernel: input: Logitech USB-PS/2 Optical Mouse as /class/input/input4 18:17:29 sys kernel: input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-0000:00:02.0-4 18:17:29 sys kernel: usbcore: registered new interface driver usbhid 18:17:29 sys kernel: drivers/usb/input/hid-core.c: v2.6:USB HID core driver 18:17:29 sys kernel: ieee1394: Host added: ID:BUS[0-00:1023] GUID[00023c015112bb16] 18:17:29 sys kernel: eth1394: eth2: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0) 18:17:29 sys kernel: eth1394: eth3: IEEE-1394 IPv4 over 1394 Ethernet (fw-host1) 18:17:29 sys kernel: ieee1394: Host added: ID:BUS[1-00:1023] GUID[0011d800007ab4d6] 18:17:29 sys kernel: it87: Found IT8712F chip at 0x290, revision 7 18:17:29 sys kernel: it87: in3 is VCC (+5V) 18:17:29 sys kernel: it87: in7 is VCCH (+5V Stand-By) 18:17:29 sys kernel: powernow-k8: Found 2 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ processors (version 2.00.00) 18:17:29 sys kernel: powernow-k8: 0 : fid 0xe (2200 MHz), vid 0x8 18:17:29 sys kernel: powernow-k8: 1 : fid 0xc (2000 MHz), vid 0xa 18:17:29 sys kernel: powernow-k8: 2 : fid 0xa (1800 MHz), vid 0xc 18:17:29 sys kernel: powernow-k8: 3 : fid 0x2 (1000 MHz), vid 0x12 18:17:29 sys kernel: usbcore: registered new interface driver usbmouse 18:17:29 sys kernel: drivers/usb/input/usbmouse.c: v1.6:USB HID Boot Protocol mouse driver 18:17:29 sys kernel: Initializing USB Mass Storage driver... 18:17:29 sys kernel: usbcore: registered new interface driver usb-storage 18:17:29 sys kernel: USB Mass Storage support registered. 18:17:29 sys kernel: sr1: CDROM not ready. Make sure there is a disc in the drive. 18:17:29 sys kernel: ata4: issue flush cmd 0xea 18:17:29 sys kernel: ata3: issue flush cmd 0xea 18:17:29 sys kernel: ata3: cmd 0xea active but stat 0x10 18:17:29 sys kernel: ata4: cmd 0xea active, stat = 0x1, handled = 0x1 18:17:29 sys kernel: ata3: cmd 0xea active, stat = 0x1, handled = 0x1 18:17:29 sys kernel: ata4: issue flush cmd 0xea 18:17:29 sys kernel: ata4: cmd 0xea active but stat 0x0 18:17:29 sys kernel: ata3: issue flush cmd 0xea 18:17:29 sys kernel: ata3: cmd 0xea active but stat 0x10 18:17:29 sys kernel: ata4: cmd 0xea active, stat = 0x1, handled = 0x1 18:17:29 sys kernel: ata3: cmd 0xea active, stat = 0x1, handled = 0x1 [..] 18:17:29 sys kernel: NET: Registered protocol family 10 18:17:29 sys kernel: lo: Disabled Privacy Extensions 18:17:33 sys kernel: eth0: no IPv6 routers present 18:17:38 sys kernel: lp: driver loaded but no devices found 18:17:38 sys kernel: ppdev: user-space parallel port driver 18:17:46 sys kernel: Installing knfsd (copyright (C) 1996 okir@monad.swb.de). 18:17:47 sys kernel: NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory 18:17:47 sys kernel: NFSD: starting 90-second grace period 18:17:53 sys kernel: Bluetooth: Core ver 2.11 18:17:53 sys kernel: NET: Registered protocol family 31 18:17:53 sys kernel: Bluetooth: HCI device and connection manager initialized 18:17:53 sys kernel: Bluetooth: HCI socket layer initialized 18:17:53 sys kernel: Bluetooth: L2CAP ver 2.8 18:17:53 sys kernel: Bluetooth: L2CAP socket layer initialized 18:17:54 sys kernel: Bluetooth: RFCOMM socket layer initialized 18:17:54 sys kernel: Bluetooth: RFCOMM TTY layer initialized 18:17:54 sys kernel: Bluetooth: RFCOMM ver 1.8 18:18:09 sys kernel: ata4: issue flush cmd 0xea 18:18:09 sys kernel: ata3: issue flush cmd 0xea 18:18:09 sys kernel: ata3: cmd 0xea active but stat 0x10 18:18:09 sys kernel: ata4: cmd 0xea active, stat = 0x1, handled = 0x1 18:18:09 sys kernel: ata3: cmd 0xea active, stat = 0x1, handled = 0x1 18:18:09 sys kernel: ata4: issue flush cmd 0xea 18:18:09 sys kernel: ata4: cmd 0xea active but stat 0x0 18:18:09 sys kernel: ata3: issue flush cmd 0xea 18:18:09 sys kernel: ata3: cmd 0xea active but stat 0x10 18:18:09 sys kernel: ata4: cmd 0xea active, stat = 0x1, handled = 0x1 18:18:09 sys kernel: ata3: cmd 0xea active, stat = 0x1, handled = 0x1 18:18:09 sys kernel: ata4: issue flush cmd 0xea 18:18:09 sys kernel: ata3: issue flush cmd 0xea 18:18:09 sys kernel: ata3: cmd 0xea active but stat 0x10 18:18:09 sys kernel: ata4: cmd 0xea active, stat = 0x1, handled = 0x1 18:18:09 sys kernel: ata3: cmd 0xea active, stat = 0x1, handled = 0x1 [..] 18:18:28 sys kernel: ata3: cmd 0xea active but stat 0x10 18:18:28 sys kernel: ata4: cmd 0xea active, stat = 0x1, handled = 0x1 18:18:28 sys kernel: ata3: cmd 0xea active, stat = 0x1, handled = 0x1 18:18:28 sys kernel: ata4: issue flush cmd 0xea 18:18:28 sys kernel: ata4: cmd 0xea active but stat 0x0 18:18:28 sys kernel: ata4: cmd 0xea active but stat 0x0 18:18:28 sys kernel: ata4: cmd 0xea active but stat 0x0 18:18:28 sys kernel: ata4: cmd 0xea active but stat 0x0 18:18:28 sys kernel: ata4: cmd 0xea active but stat 0x0 18:18:28 sys kernel: ata4: cmd 0xea active but stat 0x0 18:18:28 sys kernel: ata3: issue flush cmd 0xea 18:18:28 sys kernel: ata3: cmd 0xea active but stat 0x10 18:18:28 sys kernel: ata4: cmd 0xea active, stat = 0x1, handled = 0x1 [..] 18:21:49 sys kernel: ata4: issue flush cmd 0xea 18:21:49 sys kernel: ata3: issue flush cmd 0xea 18:21:49 sys kernel: ata3: cmd 0xea active but stat 0x10 18:21:49 sys kernel: ata4: cmd 0xea active, stat = 0x1, handled = 0x1 18:21:49 sys kernel: ata3: cmd 0xea active, stat = 0x1, handled = 0x1 18:21:49 sys kernel: ata4: issue flush cmd 0xea 18:21:49 sys kernel: ata4: cmd 0xea active but stat 0x0 18:21:49 sys kernel: ata3: issue flush cmd 0xea 18:21:49 sys kernel: ata3: cmd 0xea active, stat = 0x1, handled = 0x1 18:21:49 sys kernel: ata4: cmd 0xea active but stat 0x0 18:21:49 sys kernel: ata4: cmd 0xea active, stat = 0x1, handled = 0x1 18:21:49 sys kernel: ata4: issue flush cmd 0xea 18:21:49 sys kernel: ata4: cmd 0xea active, stat = 0x1, handled = 0x1 18:21:49 sys kernel: ata4: issue flush cmd 0xea 18:21:49 sys kernel: ata4: cmd 0xea active, stat = 0x1, handled = 0x1 18:21:49 sys kernel: ata3: issue flush cmd 0xea 18:21:49 sys kernel: ata3: cmd 0xea active, stat = 0x1, handled = 0x1 18:21:49 sys kernel: ata3: issue flush cmd 0xea 18:21:49 sys kernel: ata3: cmd 0xea active, stat = 0x1, handled = 0x1 18:21:50 sys kernel: ata4: issue flush cmd 0xea 18:21:50 sys kernel: ata3: issue flush cmd 0xea 18:21:50 sys kernel: ata3: cmd 0xea active but stat 0x10 18:21:50 sys kernel: ata4: cmd 0xea active, stat = 0x1, handled = 0x1 18:21:50 sys kernel: ata3: cmd 0xea active, stat = 0x1, handled = 0x1 [..] 18:58:54 sys kernel: ata4: issue flush cmd 0xea 18:58:54 sys kernel: ata3: issue flush cmd 0xea 18:58:54 sys kernel: ata3: cmd 0xea active but stat 0x10 18:58:54 sys kernel: ata4: cmd 0xea active, stat = 0x1, handled = 0x1 18:58:54 sys kernel: ata3: cmd 0xea active but stat 0x10 18:58:54 sys kernel: ata4: issue flush cmd 0xea 18:58:54 sys kernel: ata3: cmd 0xea active but stat 0x10 18:58:54 sys kernel: ata4: cmd 0xea active, stat = 0x1, handled = 0x1 18:58:54 sys kernel: ata4: issue flush cmd 0xea 18:58:54 sys kernel: ata3: cmd 0xea active but stat 0x10 18:58:54 sys kernel: ata4: cmd 0xea active, stat = 0x1, handled = 0x1 18:58:54 sys kernel: ata3: cmd 0xea active but stat 0x10 18:58:54 sys kernel: ata4: issue flush cmd 0xea 18:58:54 sys kernel: ata3: cmd 0xea active but stat 0x10 18:58:54 sys kernel: ata4: cmd 0xea active, stat = 0x1, handled = 0x1 18:58:55 sys kernel: ata3: cmd 0xea active but stat 0x10 18:58:57 sys kernel: ata3: cmd 0xea active but stat 0x10 18:59:02 sys kernel: ata3: cmd 0xea active but stat 0x10 18:59:09 sys kernel: ata3: cmd 0xea active but stat 0x10 18:59:16 sys kernel: ata3: cmd 0xea active but stat 0x10 18:59:23 sys kernel: ata3: cmd 0xea active but stat 0x10 18:59:24 sys kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen 18:59:24 sys kernel: ata3.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 out 18:59:24 sys kernel: res 40/00:00:00:50:28/00:00:00:00:00/00 Emask 0x4 (timeout) 18:59:24 sys kernel: ata3: soft resetting port 18:59:24 sys kernel: ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) 18:59:24 sys kernel: ata3.00: configured for UDMA/133 18:59:24 sys kernel: ata3: EH complete 18:59:24 sys kernel: ata3: issue flush cmd 0xea 18:59:24 sys kernel: SCSI device sda: 488395055 512-byte hdwr sectors (250058 MB) 18:59:24 sys kernel: ata3: cmd 0xea active, stat = 0x1, handled = 0x1 18:59:24 sys kernel: ata3: issue flush cmd 0xea 18:59:24 sys kernel: sda: Write Protect is off 18:59:24 sys kernel: sda: Mode Sense: 00 3a 00 00 18:59:24 sys kernel: ata3: cmd 0xea active, stat = 0x1, handled = 0x1 18:59:24 sys kernel: ata3: issue flush cmd 0xea 18:59:24 sys kernel: SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA 18:59:24 sys kernel: ata3: cmd 0xea active but stat 0x10 18:59:24 sys kernel: ata3: cmd 0xea active, stat = 0x1, handled = 0x1 18:59:24 sys kernel: ata4: issue flush cmd 0xea 18:59:24 sys kernel: ata4: cmd 0xea active, stat = 0x1, handled = 0x1 18:59:24 sys kernel: ata4: issue flush cmd 0xea 18:59:24 sys kernel: ata4: cmd 0xea active but stat 0x0 18:59:24 sys kernel: ata4: cmd 0xea active but stat 0x0 18:59:24 sys kernel: ata4: cmd 0xea active, stat = 0x1, handled = 0x1 18:59:24 sys kernel: ata3: issue flush cmd 0xea 18:59:24 sys kernel: ata3: cmd 0xea active, stat = 0x1, handled = 0x1 18:59:24 sys kernel: ata3: issue flush cmd 0xea 18:59:24 sys kernel: ata3: cmd 0xea active, stat = 0x1, handled = 0x1 18:59:25 sys kernel: ata4: issue flush cmd 0xea 18:59:25 sys kernel: ata4: cmd 0xea active, stat = 0x1, handled = 0x1 18:59:25 sys kernel: ata4: issue flush cmd 0xea 18:59:25 sys kernel: ata4: cmd 0xea active but stat 0x0 18:59:25 sys kernel: ata3: issue flush cmd 0xea 18:59:25 sys kernel: ata3: cmd 0xea active, stat = 0x1, handled = 0x1 18:59:25 sys kernel: ata4: cmd 0xea active but stat 0x0 18:59:25 sys kernel: ata4: cmd 0xea active but stat 0x0 18:59:25 sys kernel: ata3: issue flush cmd 0xea ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-20 2:41 ` Robert Hancock ` (3 preceding siblings ...) 2007-01-20 18:50 ` Chr @ 2007-01-20 22:32 ` Chr 2007-01-21 1:50 ` Robert Hancock 4 siblings, 1 reply; 71+ messages in thread From: Chr @ 2007-01-20 22:32 UTC (permalink / raw) To: Robert Hancock Cc: Alistair John Strachan, Jeff Garzik, Björn Steinbrink, linux-kernel, htejun, jens.axboe, lwalton, chunkeey [-- Attachment #1: Type: text/plain, Size: 1468 bytes --] On Saturday, 20. January 2007 20:59, you wrote: > Ian Kumlien wrote: > > Hi, > > > > I went from 2.6.19+sata_nv-adma-ncq-v7.patch, with no problems and adama > > enabled, to 2.6.20-rc5, which gave me problems almost instantly. > > > > I just thought that it might be interesting to know that it DID work > > nicely. > > > > CC since i'm not on the ml > > (I'm ccing more of the people who reported this) > > Well that's interesting.. The only significant change that went into > 2.6.20-rc5 in that driver that wasn't in that version you mentioned was > this one: > > http://www2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=com >mit;h=2dec7555e6bf2772749113ea0ad454fcdb8cf861 > > Could you (or anyone else) test what happens if you take the 2.6.20-rc5 > version of sata_nv.c and try it on 2.6.19? That would tell us whether > it's this change or whether it's something else (i.e. in libata core). Ok, did that! (got a fresh 2.6.19 tar ball, and used 2.6.20-rc5' sata_nv.c with the oneliner in libata_sff.c) And surprise.................... after one hour uptime, there is not even one sata exceptions in dmesg! (I'll report back tomorrow...) > > Assuming that still doesn't work, can you then try removing these lines > from nv_host_intr in 2.6.20-rc5 sata_nv.c and see what that does? > > /* bail out if not our interrupt */ > if (!(irq_stat & NV_INT_DEV)) > return 0; > > as that's the difference I'm most suspicious of causing the problem. [-- Attachment #2: kern.log --] [-- Type: text/plain, Size: 23246 bytes --] Linux version 2.6.19test (root@debian64) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #2 SMP PREEMPT Sat Jan 20 22:19:20 CET 2007 Command line: root=/dev/md1 ro BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009f800 (usable) BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000007fff0000 (usable) BIOS-e820: 000000007fff0000 - 000000007fff3000 (ACPI NVS) BIOS-e820: 000000007fff3000 - 0000000080000000 (ACPI data) BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved) Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 524272) 1 entries of 256 used end_pfn_map = 1048576 DMI 2.3 present. ACPI: RSDP (v000 Nvidia ) @ 0x00000000000f7d30 ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x000000007fff3040 ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x000000007fff30c0 ACPI: SSDT (v001 PTLTD POWERNOW 0x00000001 LTP 0x00000001) @ 0x000000007fff9900 ACPI: SRAT (v001 AMD HAMMER 0x00000001 AMD 0x00000001) @ 0x000000007fff9b40 ACPI: MCFG (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x000000007fff9c40 ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x000000007fff9840 ACPI: DSDT (v001 NVIDIA AWRDACPI 0x00001000 MSFT 0x0100000e) @ 0x0000000000000000 Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 524272) 1 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 DMA32 4096 -> 1048576 Normal 1048576 -> 1048576 early_node_map[2] active PFN ranges 0: 0 -> 159 0: 256 -> 524272 On node 0 totalpages: 524175 DMA zone: 56 pages used for memmap DMA zone: 10 pages reserved DMA zone: 3933 pages, LIFO batch:0 DMA32 zone: 7111 pages used for memmap DMA32 zone: 513065 pages, LIFO batch:31 Normal zone: 0 pages used for memmap Nvidia board detected. Ignoring ACPI timer override. If you got timer trouble try acpi_use_timer_override ACPI: PM-Timer IO Port: 0x4008 ACPI: Local APIC address 0xfee00000 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Processor #1 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec00000, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: BIOS IRQ0 pin2 override ignored. ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) ACPI: IRQ9 used by override. ACPI: IRQ14 used by override. ACPI: IRQ15 used by override. Setting APIC routing to physical flat Using ACPI (MADT) for SMP configuration information Nosave address range: 000000000009f000 - 00000000000a0000 Nosave address range: 00000000000a0000 - 00000000000f0000 Nosave address range: 00000000000f0000 - 0000000000100000 Allocating PCI resources starting at 88000000 (gap: 80000000:60000000) SMP: Allowing 2 CPUs, 0 hotplug CPUs PERCPU: Allocating 32320 bytes of per cpu data Built 1 zonelists. Total pages: 516998 Kernel command line: root=/dev/md1 ro Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) Console: colour VGA+ 80x25 Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Checking aperture... CPU 0: aperture @ 1844000000 size 32 MB Aperture too small (32 MB) No AGP bridge found Memory: 2059352k/2097088k available (3025k kernel code, 37076k reserved, 1382k data, 208k init) Calibrating delay using timer specific routine.. 4425.39 BogoMIPS (lpj=8850788) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 256 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 SMP alternatives: switching to UP code ACPI: Core revision 20060707 Using local APIC timer interrupts. result 12564452 Detected 12.564 MHz APIC timer. SMP alternatives: switching to SMP code Booting processor 1/2 APIC 0x1 Initializing CPU#1 Calibrating delay using timer specific routine.. 4422.96 BogoMIPS (lpj=8845921) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU: Physical Processor ID: 0 CPU: Processor Core ID: 1 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ stepping 01 CPU 1: Syncing TSC to CPU 0. CPU 1: synchronized TSC with CPU 0 (last diff -1 cycles, maxerr 547 cycles) Brought up 2 CPUs testing NMI watchdog ... OK. Disabling vsyscall due to use of PM timer time.c: Using 3.579545 MHz WALL PM GTOD PM timer. time.c: Detected 2211.339 MHz processor. migration_cost=226 NET: Registered protocol family 16 ACPI: bus type pci registered PCI: Using MMCONFIG at e0000000 PCI: No mmconfig possible on device 00:18 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (0000:00) PCI: Probing PCI hardware (bus 00) PCI: Transparent bridge - 0000:00:09.0 Boot video device is 0000:01:00.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT] ACPI: PCI Interrupt Link [LNK1] (IRQs *3 4 5 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNK2] (IRQs 3 4 5 7 9 10 11 *12 14 15) ACPI: PCI Interrupt Link [LNK3] (IRQs 3 4 *5 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNK4] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNK5] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LUBA] (IRQs 3 *4 5 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LUBB] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LMAC] (IRQs 3 4 5 *7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LACI] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LMCI] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LSMB] (IRQs 3 4 5 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [LUB2] (IRQs 3 4 5 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LIDE] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LSID] (IRQs 3 4 5 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LFID] (IRQs 3 4 *5 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LPCA] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [APC1] (IRQs 16) *0, disabled. ACPI: PCI Interrupt Link [APC2] (IRQs 17) *0, disabled. ACPI: PCI Interrupt Link [APC3] (IRQs 18) *0, disabled. ACPI: PCI Interrupt Link [APC4] (IRQs 19) *0, disabled. ACPI: PCI Interrupt Link [APC5] (IRQs *16), disabled. ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [APCG] (IRQs 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [APCJ] (IRQs 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [APCK] (IRQs 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [APCS] (IRQs 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [APSI] (IRQs 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [APSJ] (IRQs 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [APCP] (IRQs 20 21 22 23) *0, disabled. Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: PnP ACPI: found 11 devices SCSI subsystem initialized libata version 2.00 loaded. usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report PCI-DMA: Disabling IOMMU. pnp: 00:01: ioport range 0x4000-0x407f could not be reserved pnp: 00:01: ioport range 0x4080-0x40ff has been reserved pnp: 00:01: ioport range 0x4400-0x447f has been reserved pnp: 00:01: ioport range 0x4480-0x44ff could not be reserved pnp: 00:01: ioport range 0x4800-0x487f has been reserved pnp: 00:01: ioport range 0x4880-0x48ff has been reserved PCI: Bridge: 0000:00:09.0 IO window: a000-afff MEM window: d0000000-d1ffffff PREFETCH window: 88000000-880fffff PCI: Bridge: 0000:00:0b.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:00:0c.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:00:0d.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:00:0e.0 IO window: disabled. MEM window: c8000000-cfffffff PREFETCH window: c0000000-c7ffffff PCI: Setting latency timer of device 0000:00:09.0 to 64 PCI: Setting latency timer of device 0000:00:0b.0 to 64 PCI: Setting latency timer of device 0000:00:0c.0 to 64 PCI: Setting latency timer of device 0000:00:0d.0 to 64 PCI: Setting latency timer of device 0000:00:0e.0 to 64 NET: Registered protocol family 2 IP route cache hash table entries: 65536 (order: 7, 524288 bytes) TCP established hash table entries: 262144 (order: 10, 4194304 bytes) TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) TCP: Hash tables configured (established 262144 bind 65536) TCP reno registered audit: initializing netlink socket (disabled) audit(1169328271.472:1): initialized VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 512 (order 0, 4096 bytes) JFS: nTxBlock = 8192, nTxLock = 65536 SGI XFS with large block/inode numbers, no debug enabled SGI XFS Quota Management subsystem io scheduler noop registered io scheduler cfq registered (default) PCI: Linking AER extended capability on 0000:00:0b.0 PCI: Found HT MSI mapping on 0000:00:0b.0 with capability disabled PCI: Found HT MSI mapping on 0000:00:00.0 with capability enabled PCI: Linking AER extended capability on 0000:00:0c.0 PCI: Found HT MSI mapping on 0000:00:0c.0 with capability disabled PCI: Found HT MSI mapping on 0000:00:00.0 with capability enabled PCI: Linking AER extended capability on 0000:00:0d.0 PCI: Found HT MSI mapping on 0000:00:0d.0 with capability disabled PCI: Found HT MSI mapping on 0000:00:00.0 with capability enabled PCI: Linking AER extended capability on 0000:00:0e.0 PCI: Found HT MSI mapping on 0000:00:0e.0 with capability disabled PCI: Found HT MSI mapping on 0000:00:00.0 with capability enabled PCI: Setting latency timer of device 0000:00:0b.0 to 64 pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability Allocate Port Service[0000:00:0b.0:pcie00] Allocate Port Service[0000:00:0b.0:pcie03] PCI: Setting latency timer of device 0000:00:0c.0 to 64 pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability Allocate Port Service[0000:00:0c.0:pcie00] Allocate Port Service[0000:00:0c.0:pcie03] PCI: Setting latency timer of device 0000:00:0d.0 to 64 pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability Allocate Port Service[0000:00:0d.0:pcie00] Allocate Port Service[0000:00:0d.0:pcie03] PCI: Setting latency timer of device 0000:00:0e.0 to 64 pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability Allocate Port Service[0000:00:0e.0:pcie00] Allocate Port Service[0000:00:0e.0:pcie03] ACPI: Power Button (FF) [PWRF] ACPI: Power Button (CM) [PWRB] Real Time Clock Driver v1.12ac Linux agpgart interface v0.101 (c) Dave Jones Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 RAMDISK driver initialized: 4 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) sata_nv 0000:00:07.0: version 3.2 ACPI: PCI Interrupt Link [APSI] enabled at IRQ 23 ACPI: PCI Interrupt 0000:00:07.0[A] -> Link [APSI] -> GSI 23 (level, low) -> IRQ 23 sata_nv 0000:00:07.0: Using ADMA mode PCI: Setting latency timer of device 0000:00:07.0 to 64 ata1: SATA max UDMA/133 cmd 0xFFFFC20000028480 ctl 0xFFFFC200000284A0 bmdma 0xD800 irq 23 ata2: SATA max UDMA/133 cmd 0xFFFFC20000028580 ctl 0xFFFFC200000285A0 bmdma 0xD808 irq 23 scsi0 : sata_nv ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: ATAPI, max UDMA/33 ata1.00: configured for UDMA/33 scsi1 : sata_nv ata2: SATA link down (SStatus 0 SControl 300) scsi 0:0:0:0: CD-ROM TSSTcorp CD/DVDW SH-S183L SB00 PQ: 0 ANSI: 5 ata1: bounce limit 0xFFFFFFFF, segment boundary 0xFFFF, hw segs 127 sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 sr 0:0:0:0: Attached scsi CD-ROM sr0 sr 0:0:0:0: Attached scsi generic sg0 type 5 ACPI: PCI Interrupt Link [APSJ] enabled at IRQ 22 ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [APSJ] -> GSI 22 (level, low) -> IRQ 22 sata_nv 0000:00:08.0: Using ADMA mode PCI: Setting latency timer of device 0000:00:08.0 to 64 ata3: SATA max UDMA/133 cmd 0xFFFFC2000002A480 ctl 0xFFFFC2000002A4A0 bmdma 0xC400 irq 22 ata4: SATA max UDMA/133 cmd 0xFFFFC2000002A580 ctl 0xFFFFC2000002A5A0 bmdma 0xC408 irq 22 scsi2 : sata_nv ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata3.00: ATA-7, max UDMA/133, 488395055 sectors: LBA48 ata3.00: ata3: dev 0 multi count 1 ata3.00: configured for UDMA/133 scsi3 : sata_nv ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata4.00: ATA-7, max UDMA/133, 490234752 sectors: LBA48 NCQ (depth 1) ata4.00: ata4: dev 0 multi count 1 ata4.00: configured for UDMA/133 scsi 2:0:0:0: Direct-Access ATA WDC WD2500KS-00M 02.0 PQ: 0 ANSI: 5 ata3: bounce limit 0xFFFFFFFFFFFFFFFF, segment boundary 0xFFFFFFFF, hw segs 61 SCSI device sda: 488395055 512-byte hdwr sectors (250058 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back SCSI device sda: 488395055 512-byte hdwr sectors (250058 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 sda9 sda10 sda11 sda12 > sd 2:0:0:0: Attached scsi disk sda sd 2:0:0:0: Attached scsi generic sg1 type 0 scsi 3:0:0:0: Direct-Access ATA WDC WD2500YD-01N 10.0 PQ: 0 ANSI: 5 ata4: bounce limit 0xFFFFFFFFFFFFFFFF, segment boundary 0xFFFFFFFF, hw segs 61 SCSI device sdb: 490234752 512-byte hdwr sectors (251000 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: drive cache: write back SCSI device sdb: 490234752 512-byte hdwr sectors (251000 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: drive cache: write back sdb: sdb1 sdb2 sdb3 < sdb5 sdb6 sdb7 sdb8 sdb9 sdb10 sdb11 sdb12 > sd 3:0:0:0: Attached scsi disk sdb sd 3:0:0:0: Attached scsi generic sg2 type 0 pata_amd 0000:00:06.0: version 0.2.4 PCI: Setting latency timer of device 0000:00:06.0 to 64 ata5: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14 ata6: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15 scsi4 : pata_amd ata5.00: ATA-6, max UDMA/100, 156299375 sectors: LBA48 ata5.00: ata5: dev 0 multi count 1 ata5.00: configured for UDMA/100 scsi5 : pata_amd ata6.00: ATAPI, max UDMA/33 ata6.00: configured for UDMA/33 scsi 4:0:0:0: Direct-Access ATA WDC WD800JB-00ET 77.0 PQ: 0 ANSI: 5 SCSI device sdc: 156299375 512-byte hdwr sectors (80025 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: drive cache: write back SCSI device sdc: 156299375 512-byte hdwr sectors (80025 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: drive cache: write back sdc: sdc1 sdc2 sd 4:0:0:0: Attached scsi disk sdc sd 4:0:0:0: Attached scsi generic sg3 type 0 scsi 5:0:0:0: CD-ROM PIONEER DVD-ROM DVD-105 1.33 PQ: 0 ANSI: 5 sr1: scsi3-mmc drive: 16x/40x cd/rw xa/form2 cdda tray sr 5:0:0:0: Attached scsi CD-ROM sr1 sr 5:0:0:0: Attached scsi generic sg4 type 5 PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1 PNP: PS/2 controller doesn't have AUX irq; using default 12 serio: i8042 KBD port at 0x60,0x64 irq 1 mice: PS/2 mouse device common for all mice input: PC Speaker as /class/input/input0 input: AT Translated Set 2 keyboard as /class/input/input1 md: linear personality registered for level -1 md: raid0 personality registered for level 0 md: raid1 personality registered for level 1 md: raid10 personality registered for level 10 device-mapper: ioctl: 4.10.0-ioctl (2006-09-14) initialised: dm-devel@redhat.com device-mapper: multipath: version 1.0.5 loaded device-mapper: multipath round-robin: version 1.0.0 loaded EDAC MC: Ver: 2.0.1 Jan 20 2007 TCP cubic registered Initializing XFRM netlink socket NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 15 ieee80211: 802.11 data/management/control stack, git-1.1.13 ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com> ieee80211_crypt: registered algorithm 'NULL' ieee80211_crypt: registered algorithm 'WEP' ACPI: (supports S0 S1 S3 S4 S5) drivers/rtc/hctosys.c: unable to open rtc device (rtc0) md: Autodetecting RAID arrays. md: autorun ... [..] raid1: raid set md0 active with 2 out of 2 mirrors md: ... autorun DONE. ReiserFS: md1: found reiserfs format "3.6" with standard journal ReiserFS: md1: using ordered data mode ReiserFS: md1: journal params: device md1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: md1: checking transaction log (md1) ReiserFS: md1: Using r5 hash to sort names VFS: Mounted root (reiserfs filesystem) readonly. Freeing unused kernel memory: 208k freed ACPI: PCI Interrupt Link [APCL] enabled at IRQ 21 ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [APCL] -> GSI 21 (level, low) -> IRQ 21 PCI: Setting latency timer of device 0000:00:02.1 to 64 ehci_hcd 0000:00:02.1: EHCI Host Controller ehci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 1 ehci_hcd 0000:00:02.1: debug port 1 PCI: cache line size of 64 is not supported by device 0000:00:02.1 ehci_hcd 0000:00:02.1: irq 21, io mem 0xfeb00000 ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 10 ports detected ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI) ACPI: PCI Interrupt Link [APCF] enabled at IRQ 20 ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [APCF] -> GSI 20 (level, low) -> IRQ 20 PCI: Setting latency timer of device 0000:00:02.0 to 64 ohci_hcd 0000:00:02.0: OHCI Host Controller ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 2 ohci_hcd 0000:00:02.0: irq 20, io mem 0xd2003000 usb usb2: configuration #1 chosen from 1 choice hub 2-0:1.0: USB hub found hub 2-0:1.0: 10 ports detected forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.57. ACPI: PCI Interrupt Link [APCH] enabled at IRQ 23 ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [APCH] -> GSI 23 (level, low) -> IRQ 23 PCI: Setting latency timer of device 0000:00:0a.0 to 64 forcedeth: using HIGHDMA usb 2-4: new low speed USB device using ohci_hcd and address 2 usb 2-4: configuration #1 chosen from 1 choice eth0: forcedeth.c: subsystem: 01043:8141 bound to 0000:00:0a.0 i2c_adapter i2c-0: nForce2 SMBus adapter at 0x4c00 i2c_adapter i2c-1: nForce2 SMBus adapter at 0x4c40 ieee1394: Initialized config rom entry `ip1394' ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17 ACPI: PCI Interrupt 0000:05:0c.0[A] -> Link [APC2] -> GSI 17 (level, low) -> IRQ 17 skge 1.9 addr 0xd1004000 irq 17 chip Yukon-Lite rev 9 skge eth1: addr 00:15:f2:50:d7:70 ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18 ACPI: PCI Interrupt 0000:05:07.2[B] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 18 ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[18] MMIO=[d100f000-d100f7ff] Max Packet=[2048] IR/IT contexts=[4/8] ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16 ACPI: PCI Interrupt 0000:05:0b.0[A] -> Link [APC1] -> GSI 16 (level, low) -> IRQ 16 usbcore: registered new interface driver hiddev input: Logitech USB-PS/2 Optical Mouse as /class/input/input2 input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-0000:00:02.0-4 usbcore: registered new interface driver usbhid drivers/usb/input/hid-core.c: v2.6:USB HID core driver ohci1394: fw-host1: OHCI-1394 1.1 (PCI): IRQ=[16] MMIO=[d100e000-d100e7ff] Max Packet=[2048] IR/IT contexts=[4/8] ACPI: PCI Interrupt 0000:05:07.0[A] -> Link [APC2] -> GSI 17 (level, low) -> IRQ 17 Installing spdif_bug patch: Audigy 2 ZS [SB0350] gameport: EMU10K1 is pci0000:05:07.1/gameport0, io 0xa400, speed 1205kHz ieee1394: Host added: ID:BUS[0-00:1023] GUID[00023c015112bb16] eth1394: eth2: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0) eth1394: eth3: IEEE-1394 IPv4 over 1394 Ethernet (fw-host1) ieee1394: Host added: ID:BUS[1-00:1023] GUID[0011d800007ab4d6] ieee1394: sbp2: Driver forced to serialize I/O (serialize_io=1) ieee1394: sbp2: Try serialize_io=0 for better performance it87: Found IT8712F chip at 0x290, revision 7 it87: in3 is VCC (+5V) it87: in7 is VCCH (+5V Stand-By) powernow-k8: Found 2 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ processors (version 2.00.00) powernow-k8: 0 : fid 0xe (2200 MHz), vid 0x8 powernow-k8: 1 : fid 0xc (2000 MHz), vid 0xa powernow-k8: 2 : fid 0xa (1800 MHz), vid 0xc powernow-k8: 3 : fid 0x2 (1000 MHz), vid 0x12 usbcore: registered new interface driver usbmouse drivers/usb/input/usbmouse.c: v1.6:USB HID Boot Protocol mouse driver Initializing USB Mass Storage driver... usbcore: registered new interface driver usb-storage USB Mass Storage support registered. sr1: CDROM not ready. Make sure there is a disc in the drive. [..] Adding 1951888k swap on /dev/mapper/cswap1. Priority:-1 extents:1 across:1951888k Adding 1951888k swap on /dev/mapper/cswap2. Priority:-2 extents:1 across:1951888k NET: Registered protocol family 10 lo: Disabled Privacy Extensions eth0: no IPv6 routers present lp: driver loaded but no devices found ppdev: user-space parallel port driver Installing knfsd (copyright (C) 1996 okir@monad.swb.de). NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory NFSD: starting 90-second grace period Bluetooth: Core ver 2.11 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: L2CAP ver 2.8 Bluetooth: L2CAP socket layer initialized Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM TTY layer initialized Bluetooth: RFCOMM ver 1.8 cdrom: sr0: mrw address space DMA selected cdrom: sr0: mrw address space DMA selected ISO 9660 Extensions: Microsoft Joliet Level 1 ISOFS: changing to secondary root cdrom: sr0: mrw address space DMA selected cdrom: sr0: mrw address space DMA selected ISO 9660 Extensions: Microsoft Joliet Level 1 ISOFS: changing to secondary root ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-20 22:32 ` Chr @ 2007-01-21 1:50 ` Robert Hancock 2007-01-21 3:34 ` Jeff Garzik 0 siblings, 1 reply; 71+ messages in thread From: Robert Hancock @ 2007-01-21 1:50 UTC (permalink / raw) To: Chr Cc: Alistair John Strachan, Jeff Garzik, Björn Steinbrink, linux-kernel, htejun, jens.axboe, lwalton Chr wrote: >> Could you (or anyone else) test what happens if you take the 2.6.20-rc5 >> version of sata_nv.c and try it on 2.6.19? That would tell us whether >> it's this change or whether it's something else (i.e. in libata core). > > Ok, did that! (got a fresh 2.6.19 tar ball, and used 2.6.20-rc5' sata_nv.c > with the oneliner in libata_sff.c) > > And surprise.................... after one hour uptime, there is not even one > sata exceptions in dmesg! (I'll report back tomorrow...) That is interesting, indeed.. If that holds up then I assume some other change in 2.6.20-rc is either causing or triggering this problem. It would be useful if you could try git bisect between 2.6.19 and 2.6.20-rc5, keeping the latest sata_nv.c each time, and see if that gives any indication. If not, just trying some of the different 2.6.20-rcX versions may be useful. Before that, though, can you try making this change I suggested below in 2.6.20-rc5 and see if the problem still shows up? > >> Assuming that still doesn't work, can you then try removing these lines >> from nv_host_intr in 2.6.20-rc5 sata_nv.c and see what that does? >> >> /* bail out if not our interrupt */ >> if (!(irq_stat & NV_INT_DEV)) >> return 0; >> >> as that's the difference I'm most suspicious of causing the problem. > ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-21 1:50 ` Robert Hancock @ 2007-01-21 3:34 ` Jeff Garzik 2007-01-21 4:54 ` Björn Steinbrink 0 siblings, 1 reply; 71+ messages in thread From: Jeff Garzik @ 2007-01-21 3:34 UTC (permalink / raw) To: Robert Hancock Cc: Chr, Alistair John Strachan, Björn Steinbrink, linux-kernel, htejun, jens.axboe, lwalton Robert Hancock wrote: > change in 2.6.20-rc is either causing or triggering this problem. It > would be useful if you could try git bisect between 2.6.19 and > 2.6.20-rc5, keeping the latest sata_nv.c each time, and see if that Yes, 'git bisect' would be the next step in figuring out this puzzle. Anybody up for it? Jeff ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-21 3:34 ` Jeff Garzik @ 2007-01-21 4:54 ` Björn Steinbrink 2007-01-21 6:39 ` Robert Hancock 0 siblings, 1 reply; 71+ messages in thread From: Björn Steinbrink @ 2007-01-21 4:54 UTC (permalink / raw) To: Jeff Garzik Cc: Robert Hancock, Chr, Alistair John Strachan, linux-kernel, htejun, jens.axboe, lwalton On 2007.01.20 22:34:27 -0500, Jeff Garzik wrote: > Robert Hancock wrote: > >change in 2.6.20-rc is either causing or triggering this problem. It > >would be useful if you could try git bisect between 2.6.19 and > >2.6.20-rc5, keeping the latest sata_nv.c each time, and see if that > > > Yes, 'git bisect' would be the next step in figuring out this puzzle. > > Anybody up for it? I'll go for it, but could I get an explanation how that could lead to a different result than my last bisection? I see the difference of keeping sata_nv.c but my brain can't wrap around it right now (woke up in the middle of the night and still not up to speed...). Thanks, Björn ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-21 4:54 ` Björn Steinbrink @ 2007-01-21 6:39 ` Robert Hancock 2007-01-21 8:36 ` Björn Steinbrink 0 siblings, 1 reply; 71+ messages in thread From: Robert Hancock @ 2007-01-21 6:39 UTC (permalink / raw) To: Björn Steinbrink, Jeff Garzik, Robert Hancock, Chr, Alistair John Strachan, linux-kernel, htejun, jens.axboe, lwalton Björn Steinbrink wrote: > On 2007.01.20 22:34:27 -0500, Jeff Garzik wrote: >> Robert Hancock wrote: >>> change in 2.6.20-rc is either causing or triggering this problem. It >>> would be useful if you could try git bisect between 2.6.19 and >>> 2.6.20-rc5, keeping the latest sata_nv.c each time, and see if that >> >> Yes, 'git bisect' would be the next step in figuring out this puzzle. >> >> Anybody up for it? > > I'll go for it, but could I get an explanation how that could lead to a > different result than my last bisection? I see the difference of keeping > sata_nv.c but my brain can't wrap around it right now (woke up in the > middle of the night and still not up to speed...). Whatever the problem is, only seems to show up when ADMA is enabled, and so the patch that added ADMA support shows up as the culprit from your git bisect. However, from what Chr is reporting, 2.6.19 with the ADMA support added in doesn't seem to have the problem, so presumably something else that changed in the 2.6.20-rc series is triggering it. Doing a bisect while keeping the driver code itself the same will hopefully identify what that change is.. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-21 6:39 ` Robert Hancock @ 2007-01-21 8:36 ` Björn Steinbrink 2007-01-21 17:34 ` Chr 2007-01-21 18:40 ` Björn Steinbrink 0 siblings, 2 replies; 71+ messages in thread From: Björn Steinbrink @ 2007-01-21 8:36 UTC (permalink / raw) To: Robert Hancock Cc: Jeff Garzik, Chr, Alistair John Strachan, linux-kernel, htejun, jens.axboe, lwalton On 2007.01.21 00:39:20 -0600, Robert Hancock wrote: > Björn Steinbrink wrote: > >On 2007.01.20 22:34:27 -0500, Jeff Garzik wrote: > >>Robert Hancock wrote: > >>>change in 2.6.20-rc is either causing or triggering this problem. It > >>>would be useful if you could try git bisect between 2.6.19 and > >>>2.6.20-rc5, keeping the latest sata_nv.c each time, and see if that > >> > >>Yes, 'git bisect' would be the next step in figuring out this puzzle. > >> > >>Anybody up for it? > > > >I'll go for it, but could I get an explanation how that could lead to a > >different result than my last bisection? I see the difference of keeping > >sata_nv.c but my brain can't wrap around it right now (woke up in the > >middle of the night and still not up to speed...). > > Whatever the problem is, only seems to show up when ADMA is enabled, and > so the patch that added ADMA support shows up as the culprit from your > git bisect. However, from what Chr is reporting, 2.6.19 with the ADMA > support added in doesn't seem to have the problem, so presumably > something else that changed in the 2.6.20-rc series is triggering it. > Doing a bisect while keeping the driver code itself the same will > hopefully identify what that change is.. Ah, right... sata_nv.c of course interacts with the outside world, d'oh! Up to now, I only got bad kernels, latest tested being: 94fcda1f8ab5e0cacc381c5ca1cc9aa6ad523576 Which, unless I missed a commit in the diff, only USB changes, continuing anyway. Just to make sure, here's my little helper for this bisect run, I hope it does what you expected: #!/bin/bash cp ../sata_nv.c.orig drivers/ata/sata_nv.c git bisect good cp drivers/ata/sata_nv.c ../sata_nv.c.orig cp ../sata_nv.c drivers/ata/ make oldconfig make -j4 Where "../sata_nv.c" is the version from 2.6.20-rc5. The copying is done to avoid conflicts and keep git happy. Of course there's also a version for bad kernels ;) No idea, why I didn't make that an argument to the script... Thanks, Björn ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-21 8:36 ` Björn Steinbrink @ 2007-01-21 17:34 ` Chr 2007-01-21 18:01 ` Björn Steinbrink 2007-01-21 18:40 ` Björn Steinbrink 1 sibling, 1 reply; 71+ messages in thread From: Chr @ 2007-01-21 17:34 UTC (permalink / raw) To: Björn Steinbrink Cc: Robert Hancock, Jeff Garzik, Alistair John Strachan, linux-kernel, htejun, jens.axboe, lwalton, chunkeey On Sunday, 21. January 2007 09:36, Björn Steinbrink wrote: > On 2007.01.21 00:39:20 -0600, Robert Hancock wrote: > > Ah, right... sata_nv.c of course interacts with the outside world, d'oh! > > Up to now, I only got bad kernels, latest tested being: > 94fcda1f8ab5e0cacc381c5ca1cc9aa6ad523576 > > Which, unless I missed a commit in the diff, only USB changes, > continuing anyway. > > Just to make sure, here's my little helper for this bisect run, I hope > it does what you expected: > > #!/bin/bash > cp ../sata_nv.c.orig drivers/ata/sata_nv.c > git bisect good > cp drivers/ata/sata_nv.c ../sata_nv.c.orig > cp ../sata_nv.c drivers/ata/ > make oldconfig > make -j4 > > Where "../sata_nv.c" is the version from 2.6.20-rc5. The copying is done > to avoid conflicts and keep git happy. Of course there's also a version > for bad kernels ;) No idea, why I didn't make that an argument to the > script... > > Thanks, > Björn Argggg, 2.6.19 (with 2.6.20-rc5 adma stuff) is affected too (BTW, what do you do to trigger the exceptions? Because, it takes hours to "reproduces" this silly *************). But, this time it looks slightly different: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata3.00: tag 0 cmd 0xec Emask 0x4 stat 0x40 err 0x0 (timeout) ata3: soft resetting port ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) !!! ata3.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x1) ata3.00: revalidation failed (errno=-5) ata3: failed to recover some devices, retrying in 5 secs !!! ata3: hard resetting port ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata3.00: configured for UDMA/133 ata3: EH complete SCSI device sda: 488395055 512-byte hdwr sectors (250058 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back Oh, and I got this nice SMART Error: ID# ATTRIBUTE_NAME FLAG RAW VALUE 199 UDMA_CRC_Error_Count 0x003e ... - 12 SMART Error Log Version: 1 ATA Error Count: 1 CR = Command Register [HEX] FR = Features Register [HEX] SC = Sector Count Register [HEX] SN = Sector Number Register [HEX] CL = Cylinder Low Register [HEX] CH = Cylinder High Register [HEX] DH = Device/Head Register [HEX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days. Error 1 occurred at disk power-on lifetime: 5603 hours (233 days + 11 hours) When the command that caused the error occurred, the device was in an unknown state. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 04 51 3f 00 00 00 af Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 91 00 3f 00 00 00 0f 00 05:30:59.655 INITIALIZE DEVICE PARAMETERS [OBS-6] ec 00 01 01 00 00 00 00 05:30:59.654 IDENTIFY DEVICE ec 00 00 00 00 00 00 00 05:30:56.191 IDENTIFY DEVICE ca 00 28 02 ee 9a 0c 00 05:30:56.190 WRITE DMA ca 00 10 e8 4c 10 0a 00 05:30:56.190 WRITE DMA Maybe, it's really the HDD! OT: "http://www.nvidia.com/object/680i_hotfix.html" Chr. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-21 17:34 ` Chr @ 2007-01-21 18:01 ` Björn Steinbrink 2007-01-21 20:13 ` Chr 0 siblings, 1 reply; 71+ messages in thread From: Björn Steinbrink @ 2007-01-21 18:01 UTC (permalink / raw) To: Chr Cc: Robert Hancock, Jeff Garzik, Alistair John Strachan, linux-kernel, htejun, jens.axboe, lwalton On 2007.01.21 18:34:40 +0100, Chr wrote: > On Sunday, 21. January 2007 09:36, Björn Steinbrink wrote: > > On 2007.01.21 00:39:20 -0600, Robert Hancock wrote: > > > > Ah, right... sata_nv.c of course interacts with the outside world, d'oh! > > > > Up to now, I only got bad kernels, latest tested being: > > 94fcda1f8ab5e0cacc381c5ca1cc9aa6ad523576 > > > > Which, unless I missed a commit in the diff, only USB changes, > > continuing anyway. > > > > Just to make sure, here's my little helper for this bisect run, I hope > > it does what you expected: > > > > #!/bin/bash > > cp ../sata_nv.c.orig drivers/ata/sata_nv.c > > git bisect good > > cp drivers/ata/sata_nv.c ../sata_nv.c.orig > > cp ../sata_nv.c drivers/ata/ > > make oldconfig > > make -j4 > > > > Where "../sata_nv.c" is the version from 2.6.20-rc5. The copying is done > > to avoid conflicts and keep git happy. Of course there's also a version > > for bad kernels ;) No idea, why I didn't make that an argument to the > > script... > > > > Thanks, > > Björn > > Argggg, 2.6.19 (with 2.6.20-rc5 adma stuff) is affected too (BTW, what do you > do to trigger the exceptions? Because, it takes hours to "reproduces" this > silly *************). I run those two in parallel: while /bin/true; do ls -lR / > /dev/null 2>&1; done while /bin/true; do echo 255 > /proc/sys/vm/drop_caches; sleep 1; done Not sure if running them in parallel is necessary, but I don't want to change the test setup ;) Takes between 1 and 40 minutes to trigger it. Most of the time it's around 15 minutes now, doing more random stuff in addition to that seems to trigger it even easier (like reading mail, rebuilding the kernel etc.). I'm down to 2 commits after 2.6.19 now, only bad kernels, so I tend to say that 2.6.19 with 2.6.20-rc5's sata_nv.c will also fail for me, but I thought I might finish bisection just to be sure. > But, this time it looks slightly different: > ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen > ata3.00: tag 0 cmd 0xec Emask 0x4 stat 0x40 err 0x0 (timeout) > [Rest of the error message + SMART error snipped] I get the same exception every time, doesn't change for me. And neither do I get any SMART errors or something. Thanks, Björn ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-21 18:01 ` Björn Steinbrink @ 2007-01-21 20:13 ` Chr 2007-01-22 2:39 ` Tejun Heo 0 siblings, 1 reply; 71+ messages in thread From: Chr @ 2007-01-21 20:13 UTC (permalink / raw) To: Björn Steinbrink Cc: Robert Hancock, Jeff Garzik, Alistair John Strachan, linux-kernel, htejun, jens.axboe, lwalton, chunkeey On Sunday, 21. January 2007 19:01, Björn Steinbrink wrote: > On 2007.01.21 18:34:40 +0100, Chr wrote: > > I run those two in parallel: > while /bin/true; do ls -lR / > /dev/null 2>&1; done > while /bin/true; do echo 255 > /proc/sys/vm/drop_caches; sleep 1; done > > Not sure if running them in parallel is necessary, but I don't want to > change the test setup ;) Takes between 1 and 40 minutes to trigger it. > Most of the time it's around 15 minutes now, doing more random stuff in > addition to that seems to trigger it even easier (like reading mail, > rebuilding the kernel etc.). > > I'm down to 2 commits after 2.6.19 now, only bad kernels, so I tend to > say that 2.6.19 with 2.6.20-rc5's sata_nv.c will also fail for me, but I > thought I might finish bisection just to be sure. > > > But, this time it looks slightly different: > > ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen > > ata3.00: tag 0 cmd 0xec Emask 0x4 stat 0x40 err 0x0 (timeout) > > > > [Rest of the error message + SMART error snipped] > > I get the same exception every time, doesn't change for me. And neither > do I get any SMART errors or something. > > Thanks, > Björn Ok, you won't believe this... I opened my case and rewired my drives... And guess what, my second (aka the "good") HDD is now failing! I guess, my mainboard has a (but maybe two, or three :( ) "bad" sata-port(s)! But, one small question remains: when I opened my case, I saw that my drivers are pluged in SATA jack 1 and 2... The BIOS also says they're on 1 and 2. Now, Linux says they're on port 3 & 4! it's always ata3.00! "ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata3.00: tag 0 cmd 0xea Emask 0x4 stat 0x40 err 0x0 (timeout) ata3: soft resetting port ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata3.00: configured for UDMA/133 ata3: 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: drive cache: write back" Thanks, Chr. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-21 20:13 ` Chr @ 2007-01-22 2:39 ` Tejun Heo 2007-01-22 12:32 ` Chr 0 siblings, 1 reply; 71+ messages in thread From: Tejun Heo @ 2007-01-22 2:39 UTC (permalink / raw) To: Chr Cc: Björn Steinbrink, Robert Hancock, Jeff Garzik, Alistair John Strachan, linux-kernel, jens.axboe, lwalton Hello, Chr wrote: > Ok, you won't believe this... I opened my case and rewired my drives... > And guess what, my second (aka the "good") HDD is now failing! > I guess, my mainboard has a (but maybe two, or three :( ) "bad" sata-port(s)! Or, you have power related problem. Try to rewire the power lines or connect harddrives to a separate powersupply. It's often useful to change one component at a time and watch which change the problem follows. Anyways, you seem to be suffering transmission failures, not a driver problem. Thanks. -- tejun ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-22 2:39 ` Tejun Heo @ 2007-01-22 12:32 ` Chr 0 siblings, 0 replies; 71+ messages in thread From: Chr @ 2007-01-22 12:32 UTC (permalink / raw) To: Tejun Heo Cc: Björn Steinbrink, Robert Hancock, Jeff Garzik, Alistair John Strachan, linux-kernel, jens.axboe, lwalton, chunkeey On Monday, 22. January 2007 03:39, Tejun Heo wrote: > Hello, > > Chr wrote: > > Ok, you won't believe this... I opened my case and rewired my drives... > > And guess what, my second (aka the "good") HDD is now failing! > > I guess, my mainboard has a (but maybe two, or three :( ) "bad" sata-port(s)! > > Or, you have power related problem. Try to rewire the power lines or > connect harddrives to a separate powersupply. It's often useful to > change one component at a time and watch which change the problem > follows. Anyways, you seem to be suffering transmission failures, not a > driver problem. > > Thanks. > Yes and no, it's probably not a power problem, I've tried another PSU with the same result :( . Futhermore, the RAID0 setup makes it impossible to try only one drive alone :(. Anyway,the WD2500KS is known to have some strange bugs in the FW. e.g.: It reports 255°C right after a cold start. ( http://www.bugtrack.almico.com/view.php?id=468 ). Thanks, Chr. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-21 8:36 ` Björn Steinbrink 2007-01-21 17:34 ` Chr @ 2007-01-21 18:40 ` Björn Steinbrink 2007-01-21 19:58 ` Robert Hancock 1 sibling, 1 reply; 71+ messages in thread From: Björn Steinbrink @ 2007-01-21 18:40 UTC (permalink / raw) To: Robert Hancock, Jeff Garzik, Chr, Alistair John Strachan, linux-kernel, htejun, jens.axboe, lwalton On 2007.01.21 09:36:18 +0100, Björn Steinbrink wrote: > On 2007.01.21 00:39:20 -0600, Robert Hancock wrote: > > Björn Steinbrink wrote: > > >On 2007.01.20 22:34:27 -0500, Jeff Garzik wrote: > > >>Robert Hancock wrote: > > >>>change in 2.6.20-rc is either causing or triggering this problem. It > > >>>would be useful if you could try git bisect between 2.6.19 and > > >>>2.6.20-rc5, keeping the latest sata_nv.c each time, and see if that > > >> > > >>Yes, 'git bisect' would be the next step in figuring out this puzzle. > > >> > > >>Anybody up for it? > > > > > >I'll go for it, but could I get an explanation how that could lead to a > > >different result than my last bisection? I see the difference of keeping > > >sata_nv.c but my brain can't wrap around it right now (woke up in the > > >middle of the night and still not up to speed...). > > > > Whatever the problem is, only seems to show up when ADMA is enabled, and > > so the patch that added ADMA support shows up as the culprit from your > > git bisect. However, from what Chr is reporting, 2.6.19 with the ADMA > > support added in doesn't seem to have the problem, so presumably > > something else that changed in the 2.6.20-rc series is triggering it. > > Doing a bisect while keeping the driver code itself the same will > > hopefully identify what that change is.. > > Ah, right... sata_nv.c of course interacts with the outside world, d'oh! > > Up to now, I only got bad kernels, latest tested being: > 94fcda1f8ab5e0cacc381c5ca1cc9aa6ad523576 > > Which, unless I missed a commit in the diff, only USB changes, > continuing anyway. All kernels were bad using that approach. So back to square 1. :/ Björn ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-21 18:40 ` Björn Steinbrink @ 2007-01-21 19:58 ` Robert Hancock 2007-01-21 22:08 ` Björn Steinbrink 2007-01-21 22:27 ` Björn Steinbrink 0 siblings, 2 replies; 71+ messages in thread From: Robert Hancock @ 2007-01-21 19:58 UTC (permalink / raw) To: Björn Steinbrink, Robert Hancock, Jeff Garzik, Chr, Alistair John Strachan, linux-kernel, htejun, jens.axboe, lwalton [-- Attachment #1: Type: text/plain, Size: 936 bytes --] Björn Steinbrink wrote: > All kernels were bad using that approach. So back to square 1. :/ > > Björn > OK guys, here's a new patch to try against 2.6.20-rc5: Right now when switching between ADMA mode and legacy mode (i.e. when going from doing normal DMA reads/writes to doing a FLUSH CACHE) we just set the ADMA GO register bit appropriately and continue with no delay. It looks like in some cases the controller doesn't respond to this immediately, it takes some nanoseconds for the controller's status registers to reflect the change that was made. It's possible that if we were trying to issue commands during this time, the controller might not react properly. This patch adds some code to wait for the status register to change to the state we asked for before continuing. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/ [-- Attachment #2: sata_nv-wait-for-response-on-adma-switch.patch --] [-- Type: text/plain, Size: 1980 bytes --] --- linux-2.6.20-rc5/drivers/ata/sata_nv.c 2007-01-19 19:18:53.000000000 -0600 +++ linux-2.6.20-rc5debug/drivers/ata/sata_nv.c 2007-01-21 13:35:17.000000000 -0600 @@ -509,14 +509,38 @@ static void nv_adma_register_mode(struct { void __iomem *mmio = nv_adma_ctl_block(ap); struct nv_adma_port_priv *pp = ap->private_data; - u16 tmp; + u16 tmp, status; + int count = 0; if (pp->flags & NV_ADMA_PORT_REGISTER_MODE) return; + status = readw(mmio + NV_ADMA_STAT); + while(!(status & NV_ADMA_STAT_IDLE) && count < 20) { + ndelay(50); + status = readw(mmio + NV_ADMA_STAT); + count++; + } + if(count == 20) + ata_port_printk(ap, KERN_WARNING, + "timeout waiting for ADMA IDLE, stat=0x%hx\n", + status); + tmp = readw(mmio + NV_ADMA_CTL); writew(tmp & ~NV_ADMA_CTL_GO, mmio + NV_ADMA_CTL); + count = 0; + status = readw(mmio + NV_ADMA_STAT); + while(!(status & NV_ADMA_STAT_LEGACY) && count < 20) { + ndelay(50); + status = readw(mmio + NV_ADMA_STAT); + count++; + } + if(count == 20) + ata_port_printk(ap, KERN_WARNING, + "timeout waiting for ADMA LEGACY, stat=0x%hx\n", + status); + pp->flags |= NV_ADMA_PORT_REGISTER_MODE; } @@ -524,7 +548,8 @@ static void nv_adma_mode(struct ata_port { void __iomem *mmio = nv_adma_ctl_block(ap); struct nv_adma_port_priv *pp = ap->private_data; - u16 tmp; + u16 tmp, status; + int count = 0; if (!(pp->flags & NV_ADMA_PORT_REGISTER_MODE)) return; @@ -534,6 +559,18 @@ static void nv_adma_mode(struct ata_port tmp = readw(mmio + NV_ADMA_CTL); writew(tmp | NV_ADMA_CTL_GO, mmio + NV_ADMA_CTL); + status = readw(mmio + NV_ADMA_STAT); + while(((status & NV_ADMA_STAT_LEGACY) || + !(status & NV_ADMA_STAT_IDLE)) && count < 20) { + ndelay(50); + status = readw(mmio + NV_ADMA_STAT); + count++; + } + if(count == 20) + ata_port_printk(ap, KERN_WARNING, + "timeout waiting for ADMA LEGACY clear and IDLE, stat=0x%hx\n", + status); + pp->flags &= ~NV_ADMA_PORT_REGISTER_MODE; } ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-21 19:58 ` Robert Hancock @ 2007-01-21 22:08 ` Björn Steinbrink 2007-01-21 22:11 ` Björn Steinbrink 2007-01-21 22:27 ` Björn Steinbrink 1 sibling, 1 reply; 71+ messages in thread From: Björn Steinbrink @ 2007-01-21 22:08 UTC (permalink / raw) To: Robert Hancock Cc: Jeff Garzik, Chr, Alistair John Strachan, linux-kernel, htejun, jens.axboe, lwalton On 2007.01.21 13:58:01 -0600, Robert Hancock wrote: > Björn Steinbrink wrote: > >All kernels were bad using that approach. So back to square 1. :/ > > > >Björn > > > > OK guys, here's a new patch to try against 2.6.20-rc5: > > Right now when switching between ADMA mode and legacy mode (i.e. when > going from doing normal DMA reads/writes to doing a FLUSH CACHE) we just > set the ADMA GO register bit appropriately and continue with no delay. > It looks like in some cases the controller doesn't respond to this > immediately, it takes some nanoseconds for the controller's status > registers to reflect the change that was made. It's possible that if we > were trying to issue commands during this time, the controller might not > react properly. This patch adds some code to wait for the status > register to change to the state we asked for before continuing. I went for the "I feel lucky" route and did just add mmio reads after the mmio writes, posting them. Rationale being that if it is a write posting issue, the debug patch would/could actually hide it AFAICT. It's the "I feel lucky" route, because my whole "knowledge" about mmio and write posting originates from the few things I read up on when you discovered the comment about write posting in the generic ata code. Björn ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-21 22:08 ` Björn Steinbrink @ 2007-01-21 22:11 ` Björn Steinbrink 2007-01-21 22:26 ` Robert Hancock 0 siblings, 1 reply; 71+ messages in thread From: Björn Steinbrink @ 2007-01-21 22:11 UTC (permalink / raw) To: Robert Hancock, Jeff Garzik, Chr, Alistair John Strachan, linux-kernel, htejun, jens.axboe, lwalton On 2007.01.21 23:08:11 +0100, Björn Steinbrink wrote: > On 2007.01.21 13:58:01 -0600, Robert Hancock wrote: > > Björn Steinbrink wrote: > > >All kernels were bad using that approach. So back to square 1. :/ > > > > > >Björn > > > > > > > OK guys, here's a new patch to try against 2.6.20-rc5: > > > > Right now when switching between ADMA mode and legacy mode (i.e. when > > going from doing normal DMA reads/writes to doing a FLUSH CACHE) we just > > set the ADMA GO register bit appropriately and continue with no delay. > > It looks like in some cases the controller doesn't respond to this > > immediately, it takes some nanoseconds for the controller's status > > registers to reflect the change that was made. It's possible that if we > > were trying to issue commands during this time, the controller might not > > react properly. This patch adds some code to wait for the status > > register to change to the state we asked for before continuing. > > I went for the "I feel lucky" route and did just add mmio reads after the > mmio writes, posting them. Rationale being that if it is a write posting > issue, the debug patch would/could actually hide it AFAICT. > It's the "I feel lucky" route, because my whole "knowledge" about mmio > and write posting originates from the few things I read up on when you > discovered the comment about write posting in the generic ata code. Uhm, yeah, exception occured about the time that I hit "send". Björn ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-21 22:11 ` Björn Steinbrink @ 2007-01-21 22:26 ` Robert Hancock 0 siblings, 0 replies; 71+ messages in thread From: Robert Hancock @ 2007-01-21 22:26 UTC (permalink / raw) To: Björn Steinbrink, Robert Hancock, Jeff Garzik, Chr, Alistair John Strachan, linux-kernel, htejun, jens.axboe, lwalton Björn Steinbrink wrote: > On 2007.01.21 23:08:11 +0100, Björn Steinbrink wrote: >> On 2007.01.21 13:58:01 -0600, Robert Hancock wrote: >>> Björn Steinbrink wrote: >>>> All kernels were bad using that approach. So back to square 1. :/ >>>> >>>> Björn >>>> >>> OK guys, here's a new patch to try against 2.6.20-rc5: >>> >>> Right now when switching between ADMA mode and legacy mode (i.e. when >>> going from doing normal DMA reads/writes to doing a FLUSH CACHE) we just >>> set the ADMA GO register bit appropriately and continue with no delay. >>> It looks like in some cases the controller doesn't respond to this >>> immediately, it takes some nanoseconds for the controller's status >>> registers to reflect the change that was made. It's possible that if we >>> were trying to issue commands during this time, the controller might not >>> react properly. This patch adds some code to wait for the status >>> register to change to the state we asked for before continuing. >> I went for the "I feel lucky" route and did just add mmio reads after the >> mmio writes, posting them. Rationale being that if it is a write posting >> issue, the debug patch would/could actually hide it AFAICT. >> It's the "I feel lucky" route, because my whole "knowledge" about mmio >> and write posting originates from the few things I read up on when you >> discovered the comment about write posting in the generic ata code. > > Uhm, yeah, exception occured about the time that I hit "send". > > Björn Yeah, I don't think just adding reads to flush posted writes is enough here - it seems to need more delay than that, and it also wasn't always in the idle state even before we would write the register.. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-21 19:58 ` Robert Hancock 2007-01-21 22:08 ` Björn Steinbrink @ 2007-01-21 22:27 ` Björn Steinbrink 2007-01-22 0:17 ` Robert Hancock 1 sibling, 1 reply; 71+ messages in thread From: Björn Steinbrink @ 2007-01-21 22:27 UTC (permalink / raw) To: Robert Hancock Cc: Jeff Garzik, Chr, Alistair John Strachan, linux-kernel, htejun, jens.axboe, lwalton On 2007.01.21 13:58:01 -0600, Robert Hancock wrote: > Björn Steinbrink wrote: > >All kernels were bad using that approach. So back to square 1. :/ > > > >Björn > > > > OK guys, here's a new patch to try against 2.6.20-rc5: > > Right now when switching between ADMA mode and legacy mode (i.e. when > going from doing normal DMA reads/writes to doing a FLUSH CACHE) we just > set the ADMA GO register bit appropriately and continue with no delay. > It looks like in some cases the controller doesn't respond to this > immediately, it takes some nanoseconds for the controller's status > registers to reflect the change that was made. It's possible that if we > were trying to issue commands during this time, the controller might not > react properly. This patch adds some code to wait for the status > register to change to the state we asked for before continuing. Just got two exceptions with your patch, none of the debug messages were issued. Björn ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-21 22:27 ` Björn Steinbrink @ 2007-01-22 0:17 ` Robert Hancock 2007-01-22 16:12 ` Björn Steinbrink 0 siblings, 1 reply; 71+ messages in thread From: Robert Hancock @ 2007-01-22 0:17 UTC (permalink / raw) To: Björn Steinbrink Cc: Jeff Garzik, Chr, Alistair John Strachan, linux-kernel, htejun, jens.axboe, lwalton, pomac Björn Steinbrink wrote: > On 2007.01.21 13:58:01 -0600, Robert Hancock wrote: >> Björn Steinbrink wrote: >>> All kernels were bad using that approach. So back to square 1. :/ >>> >>> Björn >>> >> OK guys, here's a new patch to try against 2.6.20-rc5: >> >> Right now when switching between ADMA mode and legacy mode (i.e. when >> going from doing normal DMA reads/writes to doing a FLUSH CACHE) we just >> set the ADMA GO register bit appropriately and continue with no delay. >> It looks like in some cases the controller doesn't respond to this >> immediately, it takes some nanoseconds for the controller's status >> registers to reflect the change that was made. It's possible that if we >> were trying to issue commands during this time, the controller might not >> react properly. This patch adds some code to wait for the status >> register to change to the state we asked for before continuing. > > Just got two exceptions with your patch, none of the debug messages were > issued. > > Björn Hmm, another miss, apparently.. Has anyone tried removing these lines from nv_host_intr in 2.6.20-rc5 sata_nv.c and see what that does? /* bail out if not our interrupt */ if (!(irq_stat & NV_INT_DEV)) return 0; -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/ ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-22 0:17 ` Robert Hancock @ 2007-01-22 16:12 ` Björn Steinbrink 2007-01-22 16:57 ` Björn Steinbrink 0 siblings, 1 reply; 71+ messages in thread From: Björn Steinbrink @ 2007-01-22 16:12 UTC (permalink / raw) To: Robert Hancock Cc: Jeff Garzik, Chr, Alistair John Strachan, linux-kernel, htejun, jens.axboe, lwalton, pomac On 2007.01.21 18:17:01 -0600, Robert Hancock wrote: > Björn Steinbrink wrote: > >On 2007.01.21 13:58:01 -0600, Robert Hancock wrote: > >>Björn Steinbrink wrote: > >>>All kernels were bad using that approach. So back to square 1. :/ > >>> > >>>Björn > >>> > >>OK guys, here's a new patch to try against 2.6.20-rc5: > >> > >>Right now when switching between ADMA mode and legacy mode (i.e. when > >>going from doing normal DMA reads/writes to doing a FLUSH CACHE) we just > >>set the ADMA GO register bit appropriately and continue with no delay. > >>It looks like in some cases the controller doesn't respond to this > >>immediately, it takes some nanoseconds for the controller's status > >>registers to reflect the change that was made. It's possible that if we > >>were trying to issue commands during this time, the controller might not > >>react properly. This patch adds some code to wait for the status > >>register to change to the state we asked for before continuing. > > > >Just got two exceptions with your patch, none of the debug messages were > >issued. > > > >Björn > > Hmm, another miss, apparently.. Has anyone tried removing these lines > >from nv_host_intr in 2.6.20-rc5 sata_nv.c and see what that does? > > /* bail out if not our interrupt */ > if (!(irq_stat & NV_INT_DEV)) > return 0; Running a kernel with the return statement replace by a line that prints the irq_stat instead. Currently I'm seeing lots of 0x10 on ata1 and 0x0 on ata2. Björn ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-22 16:12 ` Björn Steinbrink @ 2007-01-22 16:57 ` Björn Steinbrink 2007-01-22 17:53 ` Björn Steinbrink 0 siblings, 1 reply; 71+ messages in thread From: Björn Steinbrink @ 2007-01-22 16:57 UTC (permalink / raw) To: Robert Hancock, Jeff Garzik, Chr, Alistair John Strachan, linux-kernel, htejun, jens.axboe, lwalton, pomac On 2007.01.22 17:12:40 +0100, Björn Steinbrink wrote: > On 2007.01.21 18:17:01 -0600, Robert Hancock wrote: > > Björn Steinbrink wrote: > > >On 2007.01.21 13:58:01 -0600, Robert Hancock wrote: > > >>Björn Steinbrink wrote: > > >>>All kernels were bad using that approach. So back to square 1. :/ > > >>> > > >>>Björn > > >>> > > >>OK guys, here's a new patch to try against 2.6.20-rc5: > > >> > > >>Right now when switching between ADMA mode and legacy mode (i.e. when > > >>going from doing normal DMA reads/writes to doing a FLUSH CACHE) we just > > >>set the ADMA GO register bit appropriately and continue with no delay. > > >>It looks like in some cases the controller doesn't respond to this > > >>immediately, it takes some nanoseconds for the controller's status > > >>registers to reflect the change that was made. It's possible that if we > > >>were trying to issue commands during this time, the controller might not > > >>react properly. This patch adds some code to wait for the status > > >>register to change to the state we asked for before continuing. > > > > > >Just got two exceptions with your patch, none of the debug messages were > > >issued. > > > > > >Björn > > > > Hmm, another miss, apparently.. Has anyone tried removing these lines > > >from nv_host_intr in 2.6.20-rc5 sata_nv.c and see what that does? > > > > /* bail out if not our interrupt */ > > if (!(irq_stat & NV_INT_DEV)) > > return 0; > > Running a kernel with the return statement replace by a line that prints > the irq_stat instead. > > Currently I'm seeing lots of 0x10 on ata1 and 0x0 on ata2. 40 minutes stress test now and no exception yet. What's interesting is that ata1 saw exactly one interrupt with irq_stat 0x0, all others that might have get dropped are as above. I'll keep it running for some time and will then re-enable the return statement to see if there's a relation between the irq_stat 0x0 and the exception. Björn ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-22 16:57 ` Björn Steinbrink @ 2007-01-22 17:53 ` Björn Steinbrink 0 siblings, 0 replies; 71+ messages in thread From: Björn Steinbrink @ 2007-01-22 17:53 UTC (permalink / raw) To: Robert Hancock, Jeff Garzik, Chr, Alistair John Strachan, linux-kernel, htejun, jens.axboe, lwalton, pomac On 2007.01.22 17:57:08 +0100, Björn Steinbrink wrote: > On 2007.01.22 17:12:40 +0100, Björn Steinbrink wrote: > > On 2007.01.21 18:17:01 -0600, Robert Hancock wrote: > > > Hmm, another miss, apparently.. Has anyone tried removing these lines > > > >from nv_host_intr in 2.6.20-rc5 sata_nv.c and see what that does? > > > > > > /* bail out if not our interrupt */ > > > if (!(irq_stat & NV_INT_DEV)) > > > return 0; > > > > Running a kernel with the return statement replace by a line that prints > > the irq_stat instead. > > > > Currently I'm seeing lots of 0x10 on ata1 and 0x0 on ata2. > > 40 minutes stress test now and no exception yet. What's interesting is > that ata1 saw exactly one interrupt with irq_stat 0x0, all others that > might have get dropped are as above. > I'll keep it running for some time and will then re-enable the return > statement to see if there's a relation between the irq_stat 0x0 and the > exception. No, doesn't seem to be related, did get 2 exceptions, but no irq_stat 0x0 for ata1. Syslog/dmesg has nothing new either, still the same pattern of dismissed irq_stats. Björn ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-16 0:34 ` Robert Hancock 2007-01-16 1:35 ` Björn Steinbrink 2007-01-16 1:53 ` Jeff Garzik @ 2007-01-19 14:53 ` Alistair John Strachan 2 siblings, 0 replies; 71+ messages in thread From: Alistair John Strachan @ 2007-01-19 14:53 UTC (permalink / raw) To: Robert Hancock Cc: Björn Steinbrink, jeff, linux-kernel, htejun, jens.axboe On Tuesday 16 January 2007 00:34, Robert Hancock wrote: > I'll try your stress test when I get a chance, but I doubt I'll run into > the same problem and I haven't seen any similar reports. Perhaps it's > some kind of wierd timing issue or incompatibility between the > controller and that drive when running in ADMA mode? I seem to remember > various reports of issues with certain Maxtor drives and some nForce > SATA controllers under Windows at least.. I have exactly the same problem on -rc5 and it causes all I/O to stall periodically if I do _anything_ I/O intensive. On my box, I have 4 sata_nv handled SATA ports, with two pairs of different drives (two Maxtor, two WD) and it happens randomly on both. So it's absolutely nothing to do with the drive make/model. I'll try Jeff's suggestion of disabling ADMA now, but I think something more radical than this workaround should make it into 2.6.20 final, otherwise a lot of people are going to have broken boxes. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. ^ permalink raw reply [flat|nested] 71+ messages in thread
* SATA exceptions with 2.6.20-rc5 @ 2007-01-14 22:44 Björn Steinbrink 2007-01-15 6:48 ` Mikael Pettersson 0 siblings, 1 reply; 71+ messages in thread From: Björn Steinbrink @ 2007-01-14 22:44 UTC (permalink / raw) To: jeff; +Cc: linux-kernel, htejun Hi, with 2.6.20-rc{2,4,5} (no other tested yet) I see SATA exceptions quite often, with 2.6.19 there are no such exceptions. dmesg and lspci -v output follows. In the meantime, I'll start bisecting. Thanks Björn Linux version 2.6.20-rc2 (doener@atjola) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #4 SMP Sun Dec 31 12:54:22 CET 2006 Command line: root=/dev/md0 ro quiet BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009f000 (usable) BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000007fee0000 (usable) BIOS-e820: 000000007fee0000 - 000000007fee3000 (ACPI NVS) BIOS-e820: 000000007fee3000 - 000000007fef0000 (ACPI data) BIOS-e820: 000000007fef0000 - 000000007ff00000 (reserved) BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved) Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 524000) 1 entries of 256 used end_pfn_map = 1048576 DMI 2.2 present. ACPI: RSDP (v000 Nvidia ) @ 0x00000000000f7a70 ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x000000007fee3040 ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x000000007fee30c0 ACPI: SSDT (v001 PTLTD POWERNOW 0x00000001 LTP 0x00000001) @ 0x000000007fee9540 ACPI: SRAT (v001 AMD HAMMER 0x00000001 AMD 0x00000001) @ 0x000000007fee9780 ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x000000007fee9480 ACPI: DSDT (v001 NVIDIA AWRDACPI 0x00001000 MSFT 0x0100000e) @ 0x0000000000000000 Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 524000) 1 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 DMA32 4096 -> 1048576 Normal 1048576 -> 1048576 early_node_map[2] active PFN ranges 0: 0 -> 159 0: 256 -> 524000 On node 0 totalpages: 523903 DMA zone: 56 pages used for memmap DMA zone: 1122 pages reserved DMA zone: 2821 pages, LIFO batch:0 DMA32 zone: 7108 pages used for memmap DMA32 zone: 512796 pages, LIFO batch:31 Normal zone: 0 pages used for memmap Nvidia board detected. Ignoring ACPI timer override. If you got timer trouble try acpi_use_timer_override ACPI: PM-Timer IO Port: 0x1008 ACPI: Local APIC address 0xfee00000 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Processor #1 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec00000, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) ACPI: IRQ9 used by override. ACPI: IRQ14 used by override. ACPI: IRQ15 used by override. Setting APIC routing to flat Using ACPI (MADT) for SMP configuration information Nosave address range: 000000000009f000 - 00000000000a0000 Nosave address range: 00000000000a0000 - 00000000000f0000 Nosave address range: 00000000000f0000 - 0000000000100000 Allocating PCI resources starting at 80000000 (gap: 7ff00000:60100000) PERCPU: Allocating 32000 bytes of per cpu data Built 1 zonelists. Total pages: 515617 Kernel command line: root=/dev/md0 ro quiet Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) Console: colour VGA+ 80x25 Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Checking aperture... CPU 0: aperture @ 5a74000000 size 32 MB Aperture too small (32 MB) No AGP bridge found Memory: 2059000k/2096000k available (2795k kernel code, 36392k reserved, 1089k data, 224k init) Calibrating delay using timer specific routine.. 4422.42 BogoMIPS (lpj=22112114) Mount-cache hash table entries: 256 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 Freeing SMP alternatives: 28k freed ACPI: Core revision 20060707 Using local APIC timer interrupts. result 12558084 Detected 12.558 MHz APIC timer. Booting processor 1/2 APIC 0x1 Initializing CPU#1 Calibrating delay using timer specific routine.. 4420.44 BogoMIPS (lpj=22102213) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU: Physical Processor ID: 0 CPU: Processor Core ID: 1 AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ stepping 02 CPU 1: Syncing TSC to CPU 0. CPU 1: synchronized TSC with CPU 0 (last diff 89 cycles, maxerr 393 cycles) Brought up 2 CPUs testing NMI watchdog ... OK. Disabling vsyscall due to use of PM timer time.c: Using 3.579545 MHz WALL PM GTOD PM timer. time.c: Detected 2210.219 MHz processor. migration_cost=327 NET: Registered protocol family 16 ACPI: bus type pci registered PCI: Using configuration type 1 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (0000:00) PCI: Probing PCI hardware (bus 00) PCI: Transparent bridge - 0000:00:09.0 Boot video device is 0000:05:00.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT] ACPI: PCI Interrupt Link [LNK1] (IRQs 3 5 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNK2] (IRQs 3 5 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNK3] (IRQs 3 *5 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNK4] (IRQs 3 5 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNK5] (IRQs 3 5 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LUBA] (IRQs 3 *5 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LUBB] (IRQs 3 5 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LMAC] (IRQs 3 5 *7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LACI] (IRQs 3 5 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LMCI] (IRQs *3 5 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LSMB] (IRQs 3 5 *7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LUB2] (IRQs 3 5 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [LIDE] (IRQs 3 5 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LSID] (IRQs 3 5 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LFID] (IRQs 3 5 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LPCA] (IRQs 3 5 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [APC1] (IRQs 16) *0, disabled. ACPI: PCI Interrupt Link [APC2] (IRQs 17) *0, disabled. ACPI: PCI Interrupt Link [APC3] (IRQs 18) *0, disabled. ACPI: PCI Interrupt Link [APC4] (IRQs 19) *0, disabled. ACPI: PCI Interrupt Link [APC5] (IRQs *16), disabled. ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [APCG] (IRQs 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [APCJ] (IRQs 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [APCK] (IRQs 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [APCS] (IRQs 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [APSI] (IRQs 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [APSJ] (IRQs 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [APCP] (IRQs 20 21 22 23) *0, disabled. SCSI subsystem initialized libata version 2.00 loaded. usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report PCI: Bridge: 0000:00:09.0 IO window: c000-cfff MEM window: fc000000-fdffffff PREFETCH window: fea00000-feafffff PCI: Bridge: 0000:00:0b.0 IO window: b000-bfff MEM window: fe900000-fe9fffff PREFETCH window: fe800000-fe8fffff PCI: Bridge: 0000:00:0c.0 IO window: a000-afff MEM window: fe700000-fe7fffff PREFETCH window: fe600000-fe6fffff PCI: Bridge: 0000:00:0d.0 IO window: 9000-9fff MEM window: fe500000-fe5fffff PREFETCH window: fe400000-fe4fffff PCI: Bridge: 0000:00:0e.0 IO window: 8000-8fff MEM window: f4000000-fbffffff PREFETCH window: d0000000-dfffffff PCI: Setting latency timer of device 0000:00:09.0 to 64 PCI: Setting latency timer of device 0000:00:0b.0 to 64 PCI: Setting latency timer of device 0000:00:0c.0 to 64 PCI: Setting latency timer of device 0000:00:0d.0 to 64 PCI: Setting latency timer of device 0000:00:0e.0 to 64 NET: Registered protocol family 2 IP route cache hash table entries: 65536 (order: 7, 524288 bytes) TCP established hash table entries: 262144 (order: 10, 4194304 bytes) TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) TCP: Hash tables configured (established 262144 bind 65536) TCP reno registered io scheduler noop registered io scheduler deadline registered (default) 0000:00:02.1 EHCI: BIOS handoff failed (BIOS bug ?) 01010001 PCI: Found disabled HT MSI Mapping on 0000:00:0b.0 PCI: MSI quirk detected. MSI disabled on chipset 0000:00:0b.0. PCI: Found disabled HT MSI Mapping on 0000:00:0c.0 PCI: MSI quirk detected. MSI disabled on chipset 0000:00:0c.0. PCI: Found disabled HT MSI Mapping on 0000:00:0d.0 PCI: MSI quirk detected. MSI disabled on chipset 0000:00:0d.0. PCI: Found disabled HT MSI Mapping on 0000:00:0e.0 PCI: MSI quirk detected. MSI disabled on chipset 0000:00:0e.0. PCI: Setting latency timer of device 0000:00:0b.0 to 64 assign_interrupt_mode Found MSI capability Allocate Port Service[0000:00:0b.0:pcie00] PCI: Setting latency timer of device 0000:00:0c.0 to 64 assign_interrupt_mode Found MSI capability Allocate Port Service[0000:00:0c.0:pcie00] PCI: Setting latency timer of device 0000:00:0d.0 to 64 assign_interrupt_mode Found MSI capability Allocate Port Service[0000:00:0d.0:pcie00] PCI: Setting latency timer of device 0000:00:0e.0 to 64 assign_interrupt_mode Found MSI capability Allocate Port Service[0000:00:0e.0:pcie00] input: Power Button (FF) as /class/input/input0 ACPI: Power Button (FF) [PWRF] input: Power Button (CM) as /class/input/input1 ACPI: Power Button (CM) [PWRB] ACPI: Thermal Zone [THRM] (40 C) Real Time Clock Driver v1.12ac Linux agpgart interface v0.101 (c) Dave Jones Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled tg3.c:v3.71 (December 15, 2006) ACPI: PCI Interrupt Link [APC4] enabled at IRQ 19 ACPI: PCI Interrupt 0000:04:00.0[A] -> Link [APC4] -> GSI 19 (level, low) -> IRQ 19 PCI: Setting latency timer of device 0000:04:00.0 to 64 eth0: Tigon3 [partno(BCM95721) rev 4101 PHY(5750)] (PCI Express) 10/100/1000Base-T Ethernet 00:e0:81:55:09:b0 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1] eth0: dma_rwctrl[76180000] dma_mask[64-bit] tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx NFORCE-CK804: IDE controller at PCI slot 0000:00:06.0 NFORCE-CK804: chipset revision 242 NFORCE-CK804: not 100% native mode: will probe irqs later NFORCE-CK804: 0000:00:06.0 (rev f2) UDMA133 controller ide0: BM-DMA at 0xe800-0xe807, BIOS settings: hda:DMA, hdb:DMA Probing IDE interface ide0... hda: TOSHIBA DVD-ROM SD-M1502, ATAPI CD/DVD-ROM drive hdb: AOPEN CD-RW CRW4852 1.00 20030123, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... hda: ATAPI 48X DVD-ROM drive, 128kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.20 hdb: ATAPI 40X CD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33) sata_nv 0000:00:07.0: version 3.2 ACPI: PCI Interrupt Link [APSI] enabled at IRQ 23 ACPI: PCI Interrupt 0000:00:07.0[A] -> Link [APSI] -> GSI 23 (level, low) -> IRQ 23 sata_nv 0000:00:07.0: Using ADMA mode PCI: Setting latency timer of device 0000:00:07.0 to 64 ata1: SATA max UDMA/133 cmd 0xFFFFC20000004480 ctl 0xFFFFC200000044A0 bmdma 0xD400 irq 23 ata2: SATA max UDMA/133 cmd 0xFFFFC20000004580 ctl 0xFFFFC200000045A0 bmdma 0xD408 irq 23 scsi0 : sata_nv ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: ATA-7, max UDMA/133, 160086528 sectors: LBA ata1.00: ata1: dev 0 multi count 16 ata1.00: configured for UDMA/133 scsi1 : sata_nv ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata2.00: ATA-7, max UDMA/133, 160086528 sectors: LBA ata2.00: ata2: dev 0 multi count 16 ata2.00: configured for UDMA/133 scsi 0:0:0:0: Direct-Access ATA Maxtor 6Y080M0 YAR5 PQ: 0 ANSI: 5 ata1: bounce limit 0xFFFFFFFFFFFFFFFF, segment boundary 0xFFFFFFFF, hw segs 61 SCSI device sda: 160086528 512-byte hdwr sectors (81964 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 SCSI device sda: 160086528 512-byte hdwr sectors (81964 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 sda: sda1 sda2 sda3 sd 0:0:0:0: Attached scsi disk sda scsi 1:0:0:0: Direct-Access ATA Maxtor 6Y080M0 YAR5 PQ: 0 ANSI: 5 ata2: bounce limit 0xFFFFFFFFFFFFFFFF, segment boundary 0xFFFFFFFF, hw segs 61 SCSI device sdb: 160086528 512-byte hdwr sectors (81964 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdb: 160086528 512-byte hdwr sectors (81964 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb: sdb1 sdb2 sdb3 sd 1:0:0:0: Attached scsi disk sdb usbmon: debugfs is not available ACPI: PCI Interrupt Link [APCL] enabled at IRQ 22 ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [APCL] -> GSI 22 (level, low) -> IRQ 22 PCI: Setting latency timer of device 0000:00:02.1 to 64 ehci_hcd 0000:00:02.1: EHCI Host Controller ehci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 1 ehci_hcd 0000:00:02.1: debug port 1 PCI: cache line size of 64 is not supported by device 0000:00:02.1 ehci_hcd 0000:00:02.1: irq 22, io mem 0xfeb00000 ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 8 ports detected ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI) ACPI: PCI Interrupt Link [APCF] enabled at IRQ 21 ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [APCF] -> GSI 21 (level, low) -> IRQ 21 PCI: Setting latency timer of device 0000:00:02.0 to 64 ohci_hcd 0000:00:02.0: OHCI Host Controller ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 2 ohci_hcd 0000:00:02.0: irq 21, io mem 0xfebff000 usb usb2: configuration #1 chosen from 1 choice hub 2-0:1.0: USB hub found hub 2-0:1.0: 8 ports detected usb 1-5: new high speed USB device using ehci_hcd and address 2 usb 1-5: configuration #1 chosen from 1 choice usb 2-6: new full speed USB device using ohci_hcd and address 2 usb 2-6: configuration #1 chosen from 1 choice hub 2-6:1.0: USB hub found hub 2-6:1.0: 4 ports detected drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 2 if 0 alt 0 proto 2 vid 0x04F9 pid 0x0022 usb 2-6.3: new low speed USB device using ohci_hcd and address 3 usb 2-6.3: configuration #1 chosen from 1 choice usb 2-6.4: new low speed USB device using ohci_hcd and address 4 usb 2-6.4: configuration #1 chosen from 1 choice usbcore: registered new interface driver usblp drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver Initializing USB Mass Storage driver... usbcore: registered new interface driver usb-storage USB Mass Storage support registered. usbcore: registered new interface driver hiddev input: Lite-On Tech IBM USB Keyboard with UltraNav as /class/input/input2 input: USB HID v1.10 Keyboard [Lite-On Tech IBM USB Keyboard with UltraNav] on usb-0000:00:02.0-6.3 input: Lite-On Tech IBM USB Keyboard with UltraNav as /class/input/input3 input: USB HID v1.10 Device [Lite-On Tech IBM USB Keyboard with UltraNav] on usb-0000:00:02.0-6.3 input: Synaptics Inc. Composite TouchPad / TrackPoint as /class/input/input4 input: USB HID v1.00 Mouse [Synaptics Inc. Composite TouchPad / TrackPoint] on usb-0000:00:02.0-6.4 input: Synaptics Inc. Composite TouchPad / TrackPoint as /class/input/input5 input: USB HID v1.00 Mouse [Synaptics Inc. Composite TouchPad / TrackPoint] on usb-0000:00:02.0-6.4 usbcore: registered new interface driver usbhid drivers/usb/input/hid-core.c: v2.6:USB HID core driver serio: i8042 KBD port at 0x60,0x64 irq 1 gameport: EMU10K1 is pci0000:01:08.1/gameport0, io 0xc400, speed 1205kHz mice: PS/2 mouse device common for all mice md: raid1 personality registered for level 1 device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel@redhat.com Advanced Linux Sound Architecture Driver Version 1.0.14rc1 (Wed Dec 20 08:11:48 2006 UTC). ACPI: PCI Interrupt 0000:01:08.0[A] -> Link [APC4] -> GSI 19 (level, low) -> IRQ 19 sidewinder.c: unknown joystick device detected on pci0000:01:08.1/gameport0, contact <vojtech@ucw.cz> sidewinder.c: ID packet, 225 bits. [153952b1b912b1b913b1ab5295a95ab52912b52913b1291a95291ab12] sidewinder.c: Data packet, 5 bits. [ff] ALSA device list: #0: Audigy 1 [SB0090] (rev.3, serial:0x531102) at 0xc800, irq 19 TCP cubic registered NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 15 powernow-k8: Found 2 AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ processors (version 2.00.00) powernow-k8: 0 : fid 0xe (2200 MHz), vid 0x8 powernow-k8: 1 : fid 0xc (2000 MHz), vid 0xa powernow-k8: 2 : fid 0xa (1800 MHz), vid 0xc powernow-k8: 3 : fid 0x2 (1000 MHz), vid 0xe md: Autodetecting RAID arrays. md: autorun ... md: considering sdb3 ... md: adding sdb3 ... md: sdb1 has different UUID to sdb3 md: adding sda3 ... md: sda1 has different UUID to sdb3 md: created md1 md: bind<sda3> md: bind<sdb3> md: running: <sdb3><sda3> raid1: raid set md1 active with 2 out of 2 mirrors md: considering sdb1 ... md: adding sdb1 ... md: adding sda1 ... md: created md0 md: bind<sda1> md: bind<sdb1> md: running: <sdb1><sda1> raid1: raid set md0 active with 2 out of 2 mirrors md: ... autorun DONE. kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 224k freed forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.59. ACPI: PCI Interrupt Link [APCH] enabled at IRQ 20 ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [APCH] -> GSI 20 (level, low) -> IRQ 20 PCI: Setting latency timer of device 0000:00:0a.0 to 64 forcedeth: using HIGHDMA eth1: forcedeth.c: subsystem: 010f1:2865 bound to 0000:00:0a.0 Adding 979956k swap on /dev/sda2. Priority:-1 extents:1 across:979956k Adding 979956k swap on /dev/sdb2. Priority:-2 extents:1 across:979956k EXT3 FS on md0, internal journal kjournald starting. Commit interval 5 seconds EXT3 FS on dm-4, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on dm-0, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on dm-1, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on dm-3, internal journal EXT3-fs: mounted filesystem with ordered data mode. eth1: no link during initialization. tg3: eth0: Link is up at 100 Mbps, full duplex. tg3: eth0: Flow control is off for TX and off for RX. nvidia: module license 'NVIDIA' taints kernel. ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18 ACPI: PCI Interrupt 0000:05:00.0[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 18 PCI: Setting latency timer of device 0000:05:00.0 to 64 NVRM: loading NVIDIA Linux x86_64 Kernel Module 1.0-9631 Thu Nov 9 17:35:27 PST 2006 ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) 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: 160086528 512-byte hdwr sectors (81964 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 ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) 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: 160086528 512-byte hdwr sectors (81964 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 ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) 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: 160086528 512-byte hdwr sectors (81964 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 ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata2: soft resetting port ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata2.00: configured for UDMA/133 ata2: EH complete SCSI device sdb: 160086528 512-byte hdwr sectors (81964 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata2: soft resetting port ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata2.00: configured for UDMA/133 ata2: EH complete SCSI device sdb: 160086528 512-byte hdwr sectors (81964 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA 00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) Subsystem: Tyan Computer Unknown device 2865 Flags: bus master, 66MHz, fast devsel, latency 0 Capabilities: <access denied> 00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3) Subsystem: Tyan Computer Unknown device 2865 Flags: bus master, 66MHz, fast devsel, latency 0 00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2) Subsystem: Tyan Computer Unknown device 2865 Flags: 66MHz, fast devsel, IRQ 7 I/O ports at fc00 [size=32] I/O ports at 1c00 [size=64] I/O ports at 1c40 [size=64] Capabilities: <access denied> 00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2) (prog-if 10 [OHCI]) Subsystem: Tyan Computer Unknown device 2865 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 21 Memory at febff000 (32-bit, non-prefetchable) [size=4K] Capabilities: <access denied> 00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3) (prog-if 20 [EHCI]) Subsystem: Tyan Computer Unknown device 2865 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 22 Memory at feb00000 (32-bit, non-prefetchable) [size=256] Capabilities: <access denied> 00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) (prog-if 8a [Master SecP PriP]) Subsystem: Tyan Computer Unknown device 2865 Flags: bus master, 66MHz, fast devsel, latency 0 [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 000003f0 (type 3, non-prefetchable) [disabled] [size=1] [virtual] Memory at 00000170 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 00000370 (type 3, non-prefetchable) [disabled] [size=1] I/O ports at e800 [size=16] Capabilities: <access denied> 00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) (prog-if 85 [Master SecO PriO]) Subsystem: Tyan Computer Unknown device 2865 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 23 I/O ports at 09f0 [size=8] I/O ports at 0bf0 [size=4] I/O ports at 0970 [size=8] I/O ports at 0b70 [size=4] I/O ports at d400 [size=16] Memory at febfc000 (32-bit, non-prefetchable) [size=4K] Capabilities: <access denied> 00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2) (prog-if 01 [Subtractive decode]) Flags: bus master, 66MHz, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=32 I/O behind bridge: 0000c000-0000cfff Memory behind bridge: fc000000-fdffffff Prefetchable memory behind bridge: fea00000-feafffff 00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3) Subsystem: Tyan Computer Unknown device 2865 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 20 Memory at febfb000 (32-bit, non-prefetchable) [size=4K] I/O ports at d000 [size=8] Capabilities: <access denied> 00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 I/O behind bridge: 0000b000-0000bfff Memory behind bridge: fe900000-fe9fffff Prefetchable memory behind bridge: 00000000fe800000-00000000fe8fffff Capabilities: <access denied> 00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: 0000a000-0000afff Memory behind bridge: fe700000-fe7fffff Prefetchable memory behind bridge: 00000000fe600000-00000000fe6fffff Capabilities: <access denied> 00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 I/O behind bridge: 00009000-00009fff Memory behind bridge: fe500000-fe5fffff Prefetchable memory behind bridge: 00000000fe400000-00000000fe4fffff Capabilities: <access denied> 00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=05, subordinate=05, sec-latency=0 I/O behind bridge: 00008000-00008fff Memory behind bridge: f4000000-fbffffff Prefetchable memory behind bridge: 00000000d0000000-00000000dfffffff Capabilities: <access denied> 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration Flags: fast devsel Capabilities: <access denied> 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map Flags: fast devsel 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller Flags: fast devsel 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control Flags: fast devsel 01:05.0 Display controller: ATI Technologies Inc Rage XL (rev 27) Flags: stepping, medium devsel, IRQ 10 Memory at fc000000 (32-bit, non-prefetchable) [disabled] [size=16M] I/O ports at cc00 [disabled] [size=256] Memory at fdfff000 (32-bit, non-prefetchable) [disabled] [size=4K] [virtual] Expansion ROM at fea00000 [disabled] [size=128K] Capabilities: <access denied> 01:08.0 Multimedia audio controller: Creative Labs SB Audigy (rev 03) Subsystem: Creative Labs SB0090 Audigy Player/OEM Flags: bus master, medium devsel, latency 32, IRQ 19 I/O ports at c800 [size=32] Capabilities: <access denied> 01:08.1 Input device controller: Creative Labs SB Audigy Game Port (rev 03) Subsystem: Creative Labs SB Audigy MIDI/Game Port Flags: bus master, medium devsel, latency 32 I/O ports at c400 [size=8] Capabilities: <access denied> 01:08.2 FireWire (IEEE 1394): Creative Labs SB Audigy FireWire Port (prog-if 10 [OHCI]) Subsystem: Creative Labs SB Audigy FireWire Port Flags: bus master, medium devsel, latency 32, IRQ 11 Memory at fdffe000 (32-bit, non-prefetchable) [size=2K] Memory at fdff8000 (32-bit, non-prefetchable) [size=16K] Capabilities: <access denied> 04:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express (rev 11) Subsystem: Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express Flags: bus master, fast devsel, latency 0, IRQ 19 Memory at fe5f0000 (64-bit, non-prefetchable) [size=64K] Capabilities: <access denied> 05:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce 6600] (rev a2) (prog-if 00 [VGA]) Flags: bus master, fast devsel, latency 0, IRQ 18 Memory at f4000000 (32-bit, non-prefetchable) [size=64M] Memory at d0000000 (64-bit, prefetchable) [size=256M] Memory at fa000000 (64-bit, non-prefetchable) [size=16M] [virtual] Expansion ROM at f8000000 [disabled] [size=128K] Capabilities: <access denied> ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-14 22:44 Björn Steinbrink @ 2007-01-15 6:48 ` Mikael Pettersson 2007-01-15 13:43 ` Jeff Garzik 2007-01-15 13:47 ` Björn Steinbrink 0 siblings, 2 replies; 71+ messages in thread From: Mikael Pettersson @ 2007-01-15 6:48 UTC (permalink / raw) To: Björn Steinbrink; +Cc: jeff, linux-kernel, htejun Björn Steinbrink writes: > Hi, > > with 2.6.20-rc{2,4,5} (no other tested yet) I see SATA exceptions quite > often, with 2.6.19 there are no such exceptions. dmesg and lspci -v > output follows. In the meantime, I'll start bisecting. > > Thanks > Björn > > > Linux version 2.6.20-rc2 (doener@atjola) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #4 SMP Sun Dec 31 12:54:22 CET 2006 [uneventful kernel log omitted] > sata_nv 0000:00:07.0: Using ADMA mode > PCI: Setting latency timer of device 0000:00:07.0 to 64 > ata1: SATA max UDMA/133 cmd 0xFFFFC20000004480 ctl 0xFFFFC200000044A0 bmdma 0xD400 irq 23 > ata2: SATA max UDMA/133 cmd 0xFFFFC20000004580 ctl 0xFFFFC200000045A0 bmdma 0xD408 irq 23 > scsi0 : sata_nv > ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) > ata1.00: ATA-7, max UDMA/133, 160086528 sectors: LBA > ata1.00: ata1: dev 0 multi count 16 > ata1.00: configured for UDMA/133 > scsi1 : sata_nv > ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) > ata2.00: ATA-7, max UDMA/133, 160086528 sectors: LBA > ata2.00: ata2: dev 0 multi count 16 > ata2.00: configured for UDMA/133 > scsi 0:0:0:0: Direct-Access ATA Maxtor 6Y080M0 YAR5 PQ: 0 ANSI: 5 > ata1: bounce limit 0xFFFFFFFFFFFFFFFF, segment boundary 0xFFFFFFFF, hw segs 61 > SCSI device sda: 160086528 512-byte hdwr sectors (81964 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 > SCSI device sda: 160086528 512-byte hdwr sectors (81964 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 > sda: sda1 sda2 sda3 > sd 0:0:0:0: Attached scsi disk sda > scsi 1:0:0:0: Direct-Access ATA Maxtor 6Y080M0 YAR5 PQ: 0 ANSI: 5 > ata2: bounce limit 0xFFFFFFFFFFFFFFFF, segment boundary 0xFFFFFFFF, hw segs 61 > SCSI device sdb: 160086528 512-byte hdwr sectors (81964 MB) > sdb: Write Protect is off > sdb: Mode Sense: 00 3a 00 00 > SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA > SCSI device sdb: 160086528 512-byte hdwr sectors (81964 MB) > sdb: Write Protect is off > sdb: Mode Sense: 00 3a 00 00 > SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA > sdb: sdb1 sdb2 sdb3 > sd 1:0:0:0: Attached scsi disk sdb Things are fine so far. [more uneventful kernel log omitted] > NVRM: loading NVIDIA Linux x86_64 Kernel Module 1.0-9631 Thu Nov 9 17:35:27 PST 2006 > ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen > ata1.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 in > res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) > 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: 160086528 512-byte hdwr sectors (81964 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 > ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen > ata1.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 out > res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) and then things start to break. Notice how the problems started exactly at the point the "NVRM" NVIDIA module (whatever it is) was loaded ... ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-15 6:48 ` Mikael Pettersson @ 2007-01-15 13:43 ` Jeff Garzik 2007-01-15 13:47 ` Björn Steinbrink 1 sibling, 0 replies; 71+ messages in thread From: Jeff Garzik @ 2007-01-15 13:43 UTC (permalink / raw) To: Mikael Pettersson; +Cc: Björn Steinbrink, linux-kernel, htejun Mikael Pettersson wrote: > Notice how the problems started exactly at the point the > "NVRM" NVIDIA module (whatever it is) was loaded ... Yes, that's a bit suspicious... Jeff ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: SATA exceptions with 2.6.20-rc5 2007-01-15 6:48 ` Mikael Pettersson 2007-01-15 13:43 ` Jeff Garzik @ 2007-01-15 13:47 ` Björn Steinbrink 1 sibling, 0 replies; 71+ messages in thread From: Björn Steinbrink @ 2007-01-15 13:47 UTC (permalink / raw) To: Mikael Pettersson; +Cc: jeff, linux-kernel, htejun On 2007.01.15 07:48:23 +0100, Mikael Pettersson wrote: > Notice how the problems started exactly at the point the > "NVRM" NVIDIA module (whatever it is) was loaded ... That's not the reason. Yeah, I should not have sent a log of a run with the nvidia module loaded, but the same thing happens without it. For the bisection kernels I did not even build the nvidia module and did the testing at the console. Björn ^ permalink raw reply [flat|nested] 71+ messages in thread
end of thread, other threads:[~2007-02-09 12:03 UTC | newest] Thread overview: 71+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <fa.ow4pXUncgdZmfLf3oyfrn1W+Bk0@ifi.uio.no> [not found] ` <fa.SoSeidhDuEr/K0kN+L4vW61Vpnc@ifi.uio.no> [not found] ` <fa.m8QbVQMhuOshKzTdlSjNjOhaNcc@ifi.uio.no> [not found] ` <fa.hDS02YCM8Tv1/STeTpJGEQD/49s@ifi.uio.no> [not found] ` <fa.eqBbU9XvtTizNMpuUjctnk8vuOI@ifi.uio.no> [not found] ` <fa.4QxeKMcmkoyhlL26AivZV6BFQJQ@ifi.uio.no> 2007-01-23 1:24 ` SATA exceptions with 2.6.20-rc5 Robert Hancock 2007-01-23 1:34 ` Alistair John Strachan 2007-01-23 1:41 ` Robert Hancock 2007-01-23 15:29 ` Larry Walton 2007-01-23 2:44 ` Björn Steinbrink 2007-01-23 5:03 ` Robert Hancock [not found] <fa.1kBz5luWz8nR0lLqm1VD4hZZYdw@ifi.uio.no> [not found] ` <fa.QZxgjxcwtENaZNY24NMTlKBSgIM@ifi.uio.no> [not found] ` <fa.fkPTbUGmKc/1pt0eD6TE4d02n+Q@ifi.uio.no> [not found] ` <fa.6iQt5OtHZ3x5w8eYbLxwULhLTJ0@ifi.uio.no> [not found] ` <fa.1aqo3IxNGJClHcBVZNTagX6bL9o@ifi.uio.no> [not found] ` <fa.rI60BGlFbSyfLyumqmgiOfDqCI4@ifi.uio.no> 2007-01-23 23:18 ` Robert Hancock 2007-01-24 0:39 ` Björn Steinbrink 2007-02-03 1:42 ` Björn Steinbrink 2007-02-03 5:48 ` Robert Hancock 2007-02-04 1:13 ` Björn Steinbrink 2007-02-09 12:03 ` Björn Steinbrink 2007-01-24 8:24 ` Ian Kumlien 2007-01-24 14:41 ` Björn Steinbrink 2007-01-20 15:03 Ian Kumlien 2007-01-20 19:59 ` Robert Hancock 2007-01-20 21:43 ` Alistair John Strachan 2007-01-20 22:11 ` Ian Kumlien [not found] <fa.U/G88R1fWKOeQK3EBPHKK4MeRsQ@ifi.uio.no> [not found] ` <fa.2D0TIXbVTOgZmGg9ZJU+R7te70k@ifi.uio.no> [not found] ` <fa.hMhdefkReYJ4idUyqqEWJFnWUBE@ifi.uio.no> [not found] ` <fa.8TPWeOrcwkkHutPX5NOcJsTBO8Y@ifi.uio.no> [not found] ` <fa.b92BqwV090pDj7q0iBG6BChksbI@ifi.uio.no> [not found] ` <fa.O3RzvckSjB73Y0uL8P1nTXDRd6U@ifi.uio.no> 2007-01-19 0:09 ` Robert Hancock 2007-01-19 0:52 ` Björn Steinbrink [not found] <fa.hif5u4ZXua+b0mVNaWEcItWv9i0@ifi.uio.no> 2007-01-14 23:43 ` Robert Hancock 2007-01-15 0:22 ` Jeff Garzik 2007-01-15 0:34 ` Björn Steinbrink 2007-01-15 2:47 ` Björn Steinbrink 2007-01-15 2:25 ` Robert Hancock 2007-01-15 2:53 ` Jens Axboe 2007-01-15 13:42 ` Jeff Garzik 2007-01-16 0:23 ` Jens Axboe 2007-01-16 0:36 ` Robert Hancock 2007-01-16 1:51 ` Jeff Garzik 2007-01-16 1:51 ` Jeff Garzik 2007-01-22 18:17 ` Eric D. Mudama 2007-01-15 21:17 ` Björn Steinbrink 2007-01-15 23:46 ` Björn Steinbrink 2007-01-16 0:34 ` Robert Hancock 2007-01-16 1:35 ` Björn Steinbrink 2007-01-16 3:00 ` Robert Hancock 2007-01-16 1:53 ` Jeff Garzik 2007-01-19 15:05 ` Alistair John Strachan 2007-01-19 19:51 ` chunkeey 2007-01-20 2:41 ` Robert Hancock 2007-01-20 2:47 ` Alistair John Strachan 2007-01-20 4:15 ` Björn Steinbrink [not found] ` <20070120072755.GA4652@atjola.homenet> 2007-01-20 7:50 ` Björn Steinbrink 2007-01-20 18:50 ` Chr 2007-01-20 22:32 ` Chr 2007-01-21 1:50 ` Robert Hancock 2007-01-21 3:34 ` Jeff Garzik 2007-01-21 4:54 ` Björn Steinbrink 2007-01-21 6:39 ` Robert Hancock 2007-01-21 8:36 ` Björn Steinbrink 2007-01-21 17:34 ` Chr 2007-01-21 18:01 ` Björn Steinbrink 2007-01-21 20:13 ` Chr 2007-01-22 2:39 ` Tejun Heo 2007-01-22 12:32 ` Chr 2007-01-21 18:40 ` Björn Steinbrink 2007-01-21 19:58 ` Robert Hancock 2007-01-21 22:08 ` Björn Steinbrink 2007-01-21 22:11 ` Björn Steinbrink 2007-01-21 22:26 ` Robert Hancock 2007-01-21 22:27 ` Björn Steinbrink 2007-01-22 0:17 ` Robert Hancock 2007-01-22 16:12 ` Björn Steinbrink 2007-01-22 16:57 ` Björn Steinbrink 2007-01-22 17:53 ` Björn Steinbrink 2007-01-19 14:53 ` Alistair John Strachan -- strict thread matches above, loose matches on Subject: below -- 2007-01-14 22:44 Björn Steinbrink 2007-01-15 6:48 ` Mikael Pettersson 2007-01-15 13:43 ` Jeff Garzik 2007-01-15 13:47 ` Björn Steinbrink
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.