Re: sata errors with Seagate 1.5TB on AMD 780G/SB700 motherboard

Re: sata errors with Seagate 1.5TB on AMD 780G/SB700 motherboard

[Robert Hancock]

Oskar Liljeblad wrote:
> Can anyone make any sense of these SATA errors? They're killing my md RAID5
> (at least the second error did).
> 
> Hard drives (ata1/sda, ata2/sdb, ata3/sdc): Seagate ST31500341AS 1.5TB SATA
> Motherboard: Asus M3A78-EH with AMD 780G/SB700 chipset
> SATA driver: ahci
> 00:11.0 SATA controller: ATI Technologies Inc SB700/SB800 SATA Controller [AHCI mode]
> 
> Smart reports no errors on the drives, short & long tests have been run as
> well. The system is brand new.
> 
> I've read some reports about SATA 3.0 Gbps vs 1.5 Gbps problems and I'm
> considering limiting the drives to 1.5 Gbps using jumpers. Would that be a
> good idea?
> 
> 19:24:26 ata2: exception Emask 0x50 SAct 0x0 SErr 0x90a02 action 0xe frozen
> 19:24:26 ata2: irq_stat 0x00400000, PHY RDY changed
> 19:24:26 ata2: SError: { RecovComm Persist HostInt PHYRdyChg 10B8B }

RecovComm: Communications between device and host temporarily lost, but 
regained
Persist: Persistent communication or data integrity error
HostInt: Host bus adapter internal error
PHYRdyChg: PhyRdy signal changed state
10B8B: 10b to 8b decoding error occurred

Sounds like the drive and the controller are unhappy with each other, or 
there's some kind of communications or hardware problem. Not likely a 
kernel issue.

It's unclear if limiting to 1.5 Gbps would help, you could try it and see..

[PATCH] libata: Avoid overflow in ata_tf_to_lba48() when tf->hba_lbal > 127

[Roland Dreier]

In ata_tf_to_lba48(), when evaluating

	(tf->hob_lbal & 0xff) << 24

the expression is promoted to signed int (since int can hold all values
of u8).  However, if hob_lbal is 128 or more, then it is treated as a
negative signed value and sign-extended when promoted to u64 to | into
sectors, which leads to the MSB 32 bits of section getting set
incorrectly.

For example, Phillip O'Donnell <phillip.odonnell@gmail.com> reported
that a 1.5GB drive caused:

    ata3.00: HPA detected: current 2930277168, native 18446744072344861488

where 2930277168 == 0xAEA87B30 and 18446744072344861488 == 0xffffffffaea87b30
which shows the problem when hob_lbal is 0xae.

Fix this by adding a cast to u64, just as is used by for hob_lbah and
hob_lbam in the function.

Reported-by: Phillip O'Donnell <phillip.odonnell@gmail.com>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
---
Phillip, this should fix at least your cosmetic issue; can you test it
and report back?

Thanks,
  Roland

 drivers/ata/libata-core.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index bbb3cae..10424ff 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -1268,7 +1268,7 @@ u64 ata_tf_to_lba48(const struct ata_taskfile *tf)
 
 	sectors |= ((u64)(tf->hob_lbah & 0xff)) << 40;
 	sectors |= ((u64)(tf->hob_lbam & 0xff)) << 32;
-	sectors |= (tf->hob_lbal & 0xff) << 24;
+	sectors |= ((u64)(tf->hob_lbal & 0xff)) << 24;
 	sectors |= (tf->lbah & 0xff) << 16;
 	sectors |= (tf->lbam & 0xff) << 8;
 	sectors |= (tf->lbal & 0xff);

Re: [PATCH] libata: Avoid overflow in ata_tf_to_lba48() when tf->hba_lbal > 127

[Phillip O'Donnell]

Hey Roland,

Sure thing - I'll give that a try tonight.

Just had a cursory glance over libata-core.c and I've noticed that
ata_tf_read_block() uses hob_lbal in the same uncast fashion for LBA48
- reckon that one needs patching too?

Only seems to be used in libata-scsi.c within ata_gen_ata_sense()

Cheers,
Phillip

On Wed, Oct 29, 2008 at 12:52 PM, Roland Dreier <rdreier@cisco.com> wrote:
> In ata_tf_to_lba48(), when evaluating
>
>        (tf->hob_lbal & 0xff) << 24
>
> the expression is promoted to signed int (since int can hold all values
> of u8).  However, if hob_lbal is 128 or more, then it is treated as a
> negative signed value and sign-extended when promoted to u64 to | into
> sectors, which leads to the MSB 32 bits of section getting set
> incorrectly.
>
> For example, Phillip O'Donnell <phillip.odonnell@gmail.com> reported
> that a 1.5GB drive caused:
>
>    ata3.00: HPA detected: current 2930277168, native 18446744072344861488
>
> where 2930277168 == 0xAEA87B30 and 18446744072344861488 == 0xffffffffaea87b30
> which shows the problem when hob_lbal is 0xae.
>
> Fix this by adding a cast to u64, just as is used by for hob_lbah and
> hob_lbam in the function.
>
> Reported-by: Phillip O'Donnell <phillip.odonnell@gmail.com>
> Signed-off-by: Roland Dreier <rolandd@cisco.com>
> ---
> Phillip, this should fix at least your cosmetic issue; can you test it
> and report back?
>
> Thanks,
>  Roland
>
>  drivers/ata/libata-core.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> index bbb3cae..10424ff 100644
> --- a/drivers/ata/libata-core.c
> +++ b/drivers/ata/libata-core.c
> @@ -1268,7 +1268,7 @@ u64 ata_tf_to_lba48(const struct ata_taskfile *tf)
>
>        sectors |= ((u64)(tf->hob_lbah & 0xff)) << 40;
>        sectors |= ((u64)(tf->hob_lbam & 0xff)) << 32;
> -       sectors |= (tf->hob_lbal & 0xff) << 24;
> +       sectors |= ((u64)(tf->hob_lbal & 0xff)) << 24;
>        sectors |= (tf->lbah & 0xff) << 16;
>        sectors |= (tf->lbam & 0xff) << 8;
>        sectors |= (tf->lbal & 0xff);
>

Re: [PATCH] libata: Avoid overflow in ata_tf_to_lba48() when tf->hba_lbal > 127

[Phillip O'Donnell]

Confirmed - HPA is no longer detected on boot.

Cheers,
Phillip

On Wed, Oct 29, 2008 at 12:52 PM, Roland Dreier <rdreier@cisco.com> wrote:
> In ata_tf_to_lba48(), when evaluating
>
>        (tf->hob_lbal & 0xff) << 24
>
> the expression is promoted to signed int (since int can hold all values
> of u8).  However, if hob_lbal is 128 or more, then it is treated as a
> negative signed value and sign-extended when promoted to u64 to | into
> sectors, which leads to the MSB 32 bits of section getting set
> incorrectly.
>
> For example, Phillip O'Donnell <phillip.odonnell@gmail.com> reported
> that a 1.5GB drive caused:
>
>    ata3.00: HPA detected: current 2930277168, native 18446744072344861488
>
> where 2930277168 == 0xAEA87B30 and 18446744072344861488 == 0xffffffffaea87b30
> which shows the problem when hob_lbal is 0xae.
>
> Fix this by adding a cast to u64, just as is used by for hob_lbah and
> hob_lbam in the function.
>
> Reported-by: Phillip O'Donnell <phillip.odonnell@gmail.com>
> Signed-off-by: Roland Dreier <rolandd@cisco.com>
> ---
> Phillip, this should fix at least your cosmetic issue; can you test it
> and report back?
>
> Thanks,
>  Roland
>
>  drivers/ata/libata-core.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> index bbb3cae..10424ff 100644
> --- a/drivers/ata/libata-core.c
> +++ b/drivers/ata/libata-core.c
> @@ -1268,7 +1268,7 @@ u64 ata_tf_to_lba48(const struct ata_taskfile *tf)
>
>        sectors |= ((u64)(tf->hob_lbah & 0xff)) << 40;
>        sectors |= ((u64)(tf->hob_lbam & 0xff)) << 32;
> -       sectors |= (tf->hob_lbal & 0xff) << 24;
> +       sectors |= ((u64)(tf->hob_lbal & 0xff)) << 24;
>        sectors |= (tf->lbah & 0xff) << 16;
>        sectors |= (tf->lbam & 0xff) << 8;
>        sectors |= (tf->lbal & 0xff);
>

Re: sata errors with Seagate 1.5TB on AMD 780G/SB700 motherboard

[Oskar Liljeblad]

On Tuesday, October 28, 2008 at 17:37, Robert Hancock wrote:
[..]
>> Hard drives (ata1/sda, ata2/sdb, ata3/sdc): Seagate ST31500341AS 1.5TB SATA
[..]
>> 19:24:26 ata2: exception Emask 0x50 SAct 0x0 SErr 0x90a02 action 0xe frozen
>> 19:24:26 ata2: irq_stat 0x00400000, PHY RDY changed
>> 19:24:26 ata2: SError: { RecovComm Persist HostInt PHYRdyChg 10B8B }
[..]
> Sounds like the drive and the controller are unhappy with each other, or  
> there's some kind of communications or hardware problem. Not likely a  
> kernel issue.
>
> It's unclear if limiting to 1.5 Gbps would help, you could try it and see..

It seems the solution is to disable write caching. So far no errors, and
other people confirm this solution.

Anyway Seagate (inofficially) claims it's a driver issue in Linux - from
http://forums.seagate.com/stx/board/message?board.id=ata_drives&thread.id=2390&view=by_date_ascending&page=6

  "We already know about the Linux issue, it is indeed a kernel error
  causing the problem as it was explained to me by one of our developers."

Regards,

Oskar

Re: sata errors with Seagate 1.5TB on AMD 780G/SB700 motherboard

[Alan Cox]

O> Anyway Seagate (inofficially) claims it's a driver issue in Linux - from
> http://forums.seagate.com/stx/board/message?board.id=ata_drives&thread.id=2390&view=by_date_ascending&page=6

Well then perhaps they would care to share the information with us 8)

The HPA size reporting one is certinly Linux, the flush cache one I don't
think is. The fact Mac people report it and Seagate suggest workarounds
of the form of "don't use 33% of the disk" don't inspire confidence.

>   "We already know about the Linux issue, it is indeed a kernel error
>   causing the problem as it was explained to me by one of our developers."

Well if they'd care to explain it to linux-ide perhaps we can find a work
around. I would be cautious about disabling the write caching as it will
harm both performance and probably drive lifetime.

Alan

Re: sata errors with Seagate 1.5TB on AMD 780G/SB700 motherboard

[Ric Wheeler]

Alan Cox wrote:
> O> Anyway Seagate (inofficially) claims it's a driver issue in Linux - from
>   
>> http://forums.seagate.com/stx/board/message?board.id=ata_drives&thread.id=2390&view=by_date_ascending&page=6
>>     
>
> Well then perhaps they would care to share the information with us 8)
>
> The HPA size reporting one is certinly Linux, the flush cache one I don't
> think is. The fact Mac people report it and Seagate suggest workarounds
> of the form of "don't use 33% of the disk" don't inspire confidence.
>   

I suspect that the drive is simply choking on the barrier related cache 
flushing that we do - that seemed to be the MacOS error as well. The 
windows comment suggested that windows had an hba/driver bug (most 
likely unrelated to this).

If you want to avoid the issue until they fix the drive, you could run 
fast and dangerous (mount without barriers on) or slow and safe (disable 
the write cache).

>   
>>   "We already know about the Linux issue, it is indeed a kernel error
>>   causing the problem as it was explained to me by one of our developers."
>>     
>
> Well if they'd care to explain it to linux-ide perhaps we can find a work
> around. I would be cautious about disabling the write caching as it will
> harm both performance and probably drive lifetime.
>
> Alan
>   

This looks to me to be a drive firmware issue. I would wait until 
someone can test with their announced firmware upgrade before looking at 
the kernel :-)

ric

Re: sata errors with Seagate 1.5TB on AMD 780G/SB700 motherboard

[Phillip O'Donnell]

Hi Ric,

Not too sure about that - I run with XFS, which announces that it
disables the barriers on my devices (I use LVM on top of them) but
still get the same issue... Unless I've misunderstood your comment?

Cheers,
Phillip

> I suspect that the drive is simply choking on the barrier related cache
> flushing that we do - that seemed to be the MacOS error as well. The windows
> comment suggested that windows had an hba/driver bug (most likely unrelated
> to this).
>
> If you want to avoid the issue until they fix the drive, you could run fast
> and dangerous (mount without barriers on) or slow and safe (disable the
> write cache).

Re: sata errors with Seagate 1.5TB on AMD 780G/SB700 motherboard

[Ric Wheeler]

Phillip O'Donnell wrote:
> Hi Ric,
>
> Not too sure about that - I run with XFS, which announces that it
> disables the barriers on my devices (I use LVM on top of them) but
> still get the same issue... Unless I've misunderstood your comment?
>
> Cheers,
> Phillip
>   
XFS has a different issue with barriers that has been recently fixed.

I am just going based on what I read at the Seagate customer site - it 
looks like the hang was during the processing of the ATA_CACHE_FLUSH_EXT 
command.

New drives are routinely buggy to some degree, especially ones that jump 
up in capacity :-)  Seagate has a well earned reputation for quality and 
I will be surprised if they don't fix this issue soon,

Ric

>   
>> I suspect that the drive is simply choking on the barrier related cache
>> flushing that we do - that seemed to be the MacOS error as well. The windows
>> comment suggested that windows had an hba/driver bug (most likely unrelated
>> to this).
>>
>> If you want to avoid the issue until they fix the drive, you could run fast
>> and dangerous (mount without barriers on) or slow and safe (disable the
>> write cache).
>>     

Re: [PATCH] libata: Avoid overflow in ata_tf_to_lba48() when tf->hba_lbal > 127

[Robert Hancock]

Roland Dreier wrote:
> In ata_tf_to_lba48(), when evaluating
> 
> 	(tf->hob_lbal & 0xff) << 24
> 
> the expression is promoted to signed int (since int can hold all values
> of u8).  However, if hob_lbal is 128 or more, then it is treated as a
> negative signed value and sign-extended when promoted to u64 to | into
> sectors, which leads to the MSB 32 bits of section getting set
> incorrectly.
> 
> For example, Phillip O'Donnell <phillip.odonnell@gmail.com> reported
> that a 1.5GB drive caused:
> 
>     ata3.00: HPA detected: current 2930277168, native 18446744072344861488
> 
> where 2930277168 == 0xAEA87B30 and 18446744072344861488 == 0xffffffffaea87b30
> which shows the problem when hob_lbal is 0xae.
> 
> Fix this by adding a cast to u64, just as is used by for hob_lbah and
> hob_lbam in the function.
> 
> Reported-by: Phillip O'Donnell <phillip.odonnell@gmail.com>
> Signed-off-by: Roland Dreier <rolandd@cisco.com>

This should be pushed to -stable as well once it's merged..

Re: [PATCH] libata: Avoid overflow in ata_tf_to_lba48() when tf->hba_lbal > 127

[Jeff Garzik]

Roland Dreier wrote:
> In ata_tf_to_lba48(), when evaluating
> 
> 	(tf->hob_lbal & 0xff) << 24
> 
> the expression is promoted to signed int (since int can hold all values
> of u8).  However, if hob_lbal is 128 or more, then it is treated as a
> negative signed value and sign-extended when promoted to u64 to | into
> sectors, which leads to the MSB 32 bits of section getting set
> incorrectly.
> 
> For example, Phillip O'Donnell <phillip.odonnell@gmail.com> reported
> that a 1.5GB drive caused:
> 
>     ata3.00: HPA detected: current 2930277168, native 18446744072344861488
> 
> where 2930277168 == 0xAEA87B30 and 18446744072344861488 == 0xffffffffaea87b30
> which shows the problem when hob_lbal is 0xae.
> 
> Fix this by adding a cast to u64, just as is used by for hob_lbah and
> hob_lbam in the function.
> 
> Reported-by: Phillip O'Donnell <phillip.odonnell@gmail.com>
> Signed-off-by: Roland Dreier <rolandd@cisco.com>
> ---
> Phillip, this should fix at least your cosmetic issue; can you test it
> and report back?
> 
> Thanks,
>   Roland
> 
>  drivers/ata/libata-core.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

applied

Re: sata errors with Seagate 1.5TB on AMD 780G/SB700 motherboard

[Kasper Sandberg]

On Wed, 2008-10-29 at 18:37 -0400, Ric Wheeler wrote:
> Phillip O'Donnell wrote:
<snip>
> I am just going based on what I read at the Seagate customer site - it 
> looks like the hang was during the processing of the ATA_CACHE_FLUSH_EXT 
> command.
> 
> New drives are routinely buggy to some degree, especially ones that jump 
> up in capacity :-)  Seagate has a well earned reputation for quality and 
> I will be surprised if they don't fix this issue soon,

Is there any new information on this? so far the only thing i can find
seems to be people reporting the issue, but no word from seagate..

> 
> Ric
> 
> >   
> >> I suspect that the drive is simply choking on the barrier related cache
> >> flushing that we do - that seemed to be the MacOS error as well. The windows
> >> comment suggested that windows had an hba/driver bug (most likely unrelated
> >> to this).
> >>
> >> If you want to avoid the issue until they fix the drive, you could run fast
> >> and dangerous (mount without barriers on) or slow and safe (disable the
> >> write cache).
> >>     
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: sata errors with Seagate 1.5TB on AMD 780G/SB700 motherboard

[Ric Wheeler]

Kasper Sandberg wrote:
> On Wed, 2008-10-29 at 18:37 -0400, Ric Wheeler wrote:
>   
>> Phillip O'Donnell wrote:
>>     
> <snip>
>   
>> I am just going based on what I read at the Seagate customer site - it 
>> looks like the hang was during the processing of the ATA_CACHE_FLUSH_EXT 
>> command.
>>
>> New drives are routinely buggy to some degree, especially ones that jump 
>> up in capacity :-)  Seagate has a well earned reputation for quality and 
>> I will be surprised if they don't fix this issue soon,
>>     
>
> Is there any new information on this? so far the only thing i can find
> seems to be people reporting the issue, but no word from seagate..
>   

I don't actually have one of these drives, so I don't have any updates, 
sorry.

There was a recent patch to correctly calculate sector numbers for these 
disks, but I am not sure that this was the same issue you saw...

ric

>   
>> Ric
>>
>>     
>>>   
>>>       
>>>> I suspect that the drive is simply choking on the barrier related cache
>>>> flushing that we do - that seemed to be the MacOS error as well. The windows
>>>> comment suggested that windows had an hba/driver bug (most likely unrelated
>>>> to this).
>>>>
>>>> If you want to avoid the issue until they fix the drive, you could run fast
>>>> and dangerous (mount without barriers on) or slow and safe (disable the
>>>> write cache).
>>>>     
>>>>         
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>     
>
>