Andrew Morton wrote:
> On Thu, 30 Aug 2007 09:24:18 + Nigel Kukard <[EMAIL PROTECTED]> wrote:
>
>> Hrmmm,
>>
>
> > > Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
> > > 0x0001c807
> > > Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7
On Thu, 30 Aug 2007 09:24:18 + Nigel Kukard <[EMAIL PROTECTED]> wrote:
> Hrmmm,
>
> >> >
> >> > > > Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
> >> > > > 0x0001c807
> >> > > > Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
> >> > > > 0x0
Hrmmm,
>> >
>> > > > Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
>> > > > 0x0001c807
>> > > > Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
>> > > > 0x0001c807
>> >
>> > Unrelated to the other error, but I've been meaning to ask for a whil
> >
> > > > Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
> > > > 0x0001c807
> > > > Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
> > > > 0x0001c807
> >
> > Unrelated to the other error, but I've been meaning to ask for a while..
> > If th
On Thu, Jun 14, 2007 at 02:28:54PM -0400, Dave Jones wrote:
> On Thu, Jun 14, 2007 at 12:21:49PM -0400, Jeff Garzik wrote:
>
> > > Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
> > > 0x0001c807
> > > Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
Hi Jeff,
Ok ... second part of my problem. Where should I look in trying to debug
the below problem...
Regards
Nigel
Jun 18 07:59:56 nigel-m2v kernel: ata2.00: exception Emask 0x0 SAct 0x0
SErr 0x0 action 0x2 frozen
Jun 18 07:59:56 nigel-m2v kernel: ata2.00: cmd
ca/00:08:bf:ab:68/00:00:00:00:00/
On Thu, Jun 14, 2007 at 12:21:49PM -0400, Jeff Garzik wrote:
> > Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
> > 0x0001c807
> > Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
> > 0x0001c807
Unrelated to the other error, but I've been meaning to ask
Nigel Kukard wrote:
I'm stumped trying to track down the below intermittent problem.
I've confirmed this problem on 2.6.19, 2.6.20 and 2.6.21.
Jun 14 07:55:52 nigel-m2v kernel: ata2.00: exception Emask 0x0 SAct 0x0
SErr 0x0 action 0x2 frozen
Jun 14 07:55:52 nigel-m2v kernel: ata2.00: cmd
>> I'm stumped trying to track down the below intermittent problem.
>>
>> I've confirmed this problem on 2.6.19, 2.6.20 and 2.6.21.
>>
>> Any help greatly appreciated!
>>
>> Regards
>> Nigel
>>
>>
>> Jun 14 07:55:52 nigel-m2v kernel: ata2.00: exception Emask 0x0 SAct 0x0
>> SErr 0x0 action 0x
Nigel Kukard wrote:
I'm stumped trying to track down the below intermittent problem.
I've confirmed this problem on 2.6.19, 2.6.20 and 2.6.21.
Any help greatly appreciated!
Regards
Nigel
Jun 14 07:55:52 nigel-m2v kernel: ata2.00: exception Emask 0x0 SAct 0x0
SErr 0x0 action 0x2 frozen
Ju
Christian wrote:
I'm seeing the same here since a few days. Before it worked great (even with
NCQ). I've been getting those messages since 2.6.21-rc3-mm1 and with the
latest Ubuntu feisty kernel (2.6.20-11-generic #2 SMP Thu Mar 15 03:43:56 UTC
2007 x86_64 GNU/Linux)
System is Athlon64 X2, Nf
I'm seeing the same here since a few days. Before it worked great (even with
NCQ). I've been getting those messages since 2.6.21-rc3-mm1 and with the
latest Ubuntu feisty kernel (2.6.20-11-generic #2 SMP Thu Mar 15 03:43:56 UTC
2007 x86_64 GNU/Linux)
System is Athlon64 X2, Nforce4, 3x Samsung S
On Fri, 16 Mar 2007 17:44:25 -0600
Robert Hancock <[EMAIL PROTECTED]> wrote:
> Charles Shannon Hendrix wrote:
> > I normally run a modified 2.6.19 kernel and it works great.
> >
> > I recently tried 2.6.20 and had severe SATA problems with it.
> >
> > Yesterday I tried 2.6.20.3, and the problems
On Friday 16 March 2007 23:44, you wrote:
> Charles Shannon Hendrix wrote:
> > I normally run a modified 2.6.19 kernel and it works great.
> >
> > I recently tried 2.6.20 and had severe SATA problems with it.
> >
> > Yesterday I tried 2.6.20.3, and the problems are still there.
>
> Can you try 2.6.
Charles Shannon Hendrix wrote:
I normally run a modified 2.6.19 kernel and it works great.
I recently tried 2.6.20 and had severe SATA problems with it.
Yesterday I tried 2.6.20.3, and the problems are still there.
Can you try 2.6.21-rc and see if the problem is fixed in those kernels?
--
Ro
On Fri, 16 Mar 2007 11:58:21 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Charles Shannon Hendrix wrote:
> > I normally run a modified 2.6.19 kernel and it works great.
> >
> > I recently tried 2.6.20 and had severe SATA problems with it.
> >
> > Yesterday I tried 2.6.20.3, and the problems ar
Charles Shannon Hendrix wrote:
I normally run a modified 2.6.19 kernel and it works great.
I recently tried 2.6.20 and had severe SATA problems with it.
Yesterday I tried 2.6.20.3, and the problems are still there.
Setting the module parameter 'adma' to zero fixes this, yes?
Jeff
Tejun Heo wrote:
Pablo Sebastian Greco wrote:
Tejun Heo wrote:
* Pablo, the bug you saw was bad interaction between blacklisted NCQ
device and dynamic queue depth adjustment. Patches are submitted to fix
the problem. Just drop the blacklist patch. Your drives should work
fine in NCQ
ebruary 21, 2007 7:24 AM
> To: Tejun Heo
> Cc: Pablo Sebastian Greco; linux-kernel@vger.kernel.org
> Subject: Re: SATA problems
>
> Tejun,
>
> I checked out the kernel 2.6.19 to 2.6.20 Changelog. Seems like you
> fixed a problem with the JMB363. The Asus P5B-Deluxe I am using h
Tejun,
I checked out the kernel 2.6.19 to 2.6.20 Changelog. Seems like you
fixed a problem with the JMB363. The Asus P5B-Deluxe I am using has a
JMB363 - besides an Intel ICH8R - with the SATA ports set to AHCI as
well. Looks like that might have been the source of the problem in
2.6.19.
Thanks,
Tejun,
thanks. In preparation of your patch I installed a vanilla 2.6.20.1
kernel on my FC6
system. Amazingly the problem went away with the vanilla(!) kernel and NCQ
is enabled at boot time (queue_depth is 31). I guess I should have
tried that kernel
earlier.
The patches you sent earlier apply
Marcus Haebler wrote:
> thanks for the patches! I am on an Intel P965/ICH8R.
I see. That can happen too. There was a race window where in-flight
r/w command which left SCSI midlayer but pending on libata gets executed
in the wrong mode. If possible, please verify that it doesn't happen
with the
Pablo Sebastian Greco wrote:
> Tejun Heo wrote:
>> * Pablo, the bug you saw was bad interaction between blacklisted NCQ
>> device and dynamic queue depth adjustment. Patches are submitted to fix
>> the problem. Just drop the blacklist patch. Your drives should work
>> fine in NCQ mode. My gut f
Tejun,
thanks for the patches! I am on an Intel P965/ICH8R.
Best,
Marcus
On 2/20/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
* Pablo, the bug you saw was bad interaction between blacklisted NCQ
device and dynamic queue depth adjustment. Patches are submitted to fix
the problem. Just drop the b
Tejun Heo wrote:
* Pablo, the bug you saw was bad interaction between blacklisted NCQ
device and dynamic queue depth adjustment. Patches are submitted to fix
the problem. Just drop the blacklist patch. Your drives should work
fine in NCQ mode. My gut feeling is that your problem is power rela
* Pablo, the bug you saw was bad interaction between blacklisted NCQ
device and dynamic queue depth adjustment. Patches are submitted to fix
the problem. Just drop the blacklist patch. Your drives should work
fine in NCQ mode. My gut feeling is that your problem is power related
from the beginn
Marcus Haebler wrote:
I opened a bug report (228979) on bugzilla.redhat.com on this one because
I have the same issue under FC6 2.6.19-1.2895. Here is the link:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228979
Do you have any more updates on this problem? Is there a way I can help
I opened a bug report (228979) on bugzilla.redhat.com on this one because
I have the same issue under FC6 2.6.19-1.2895. Here is the link:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228979
Do you have any more updates on this problem? Is there a way I can help
by providing debug dat
Pablo Sebastian Greco wrote:
> Well, it took me a few days, but I think I'm ready to report back. One
> of the drives was failing, and it stopped after rewiring power supply so
> the last problem seems to be corrected.
> OTOH, your blacklist seems to be needed too, now I'm running FC6
> distributi
Tejun Heo wrote:
Hello, Pablo.
Please apply common hardware debugging method. You know, swap drives.
Use separate power supply for disks, swap cables, etc...
It seems more like a hardware problem at this point.
Thanks.
Well, it took me a few days, but I think I'm ready to report back. On
Hello, Pablo.
Please apply common hardware debugging method. You know, swap drives.
Use separate power supply for disks, swap cables, etc...
It seems more like a hardware problem at this point.
Thanks.
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
Pablo Sebastian Greco wrote:
Tejun Heo wrote:
Pablo Sebastian Greco wrote:
After an uptime of 13:34 under heavy load and no errors, I'm pretty
sure your patch is correct. Is there a way to backport this to
2.6.18.x?
I forgot this (even though I implemented it) but you can turn off NC
Tejun Heo wrote:
Pablo Sebastian Greco wrote:
After an uptime of 13:34 under heavy load and no errors, I'm pretty
sure your patch is correct. Is there a way to backport this to 2.6.18.x?
I forgot this (even though I implemented it) but you can turn off NCQ by
doing the following.
# e
Tejun Heo wrote:
Pablo Sebastian Greco wrote:
After an uptime of 13:34 under heavy load and no errors, I'm pretty
sure your patch is correct. Is there a way to backport this to 2.6.18.x?
I forgot this (even though I implemented it) but you can turn off NCQ by
doing the following.
# echo 1 >
Pablo Sebastian Greco wrote:
> After an uptime of 13:34 under heavy load and no errors, I'm pretty
> sure your patch is correct. Is there a way to backport this to 2.6.18.x?
I forgot this (even though I implemented it) but you can turn off NCQ by
doing the following.
# echo 1 > /sys/block/sdX/de
Pablo Sebastian Greco wrote:
Tejun Heo wrote:
Pablo Sebastian Greco wrote:
By crash I mean the whole system going down, having to reset the entire
machine.
I'm sending you 4 files:
dmesg: current boot dmesg, just a boot, because no errors appeared
after
last crash, since the server is out o
Tejun Heo wrote:
Pablo Sebastian Greco wrote:
By crash I mean the whole system going down, having to reset the entire
machine.
I'm sending you 4 files:
dmesg: current boot dmesg, just a boot, because no errors appeared after
last crash, since the server is out of production right now (errors
Pablo Sebastian Greco wrote:
> By crash I mean the whole system going down, having to reset the entire
> machine.
> I'm sending you 4 files:
> dmesg: current boot dmesg, just a boot, because no errors appeared after
> last crash, since the server is out of production right now (errors
> usually app
Pablo Sebastian Greco wrote:
> First of all, thanks for everything, and my excuses if I'm doing
> anything wrong, this is my first lkml mail, but I've read all the faq,
> so should be OK.
> This is the machine with the problem:
>
> Intel ServerBoard S5000VSA
> Dual Core Xeon 2.66 (Intel(R) Xeon(TM
39 matches
Mail list logo