linux-kernel - Re: [PATCH] ahci.c: fix ati sb600 sata IRQ_TF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5767b9100703270253j2ac3b543y499323b42c6402b@mail.gmail.com>
Date:	Tue, 27 Mar 2007 17:53:12 +0800
From:	"Conke Hu" <conke.hu@...il.com>
To:	"Tejun Heo" <htejun@...il.com>
Cc:	"Jeff Garzik" <jeff@...zik.org>, Alan <alan@...rguk.ukuu.org.uk>,
	"Andrew Morton" <akpm@...l.org>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ahci.c: fix ati sb600 sata IRQ_TF_ERR

On 3/15/07, Tejun Heo <htejun@...il.com> wrote:
> Conke Hu wrote:
> >> E  Internal error: The host bus adapter experienced an internal error
> >> that caused the operation to fail and may have put the host bus adapter
> >> into an error state. Host software should reset the interface before
> >> re-trying the operation. If the condition persists, the host bus adapter
> >> may suffer from a design issue rendering it incompatible with the
> >> attached device.
> >>
> >
> > Yes, I saw this too :) and I am contacting the hardware engineers to
> > check if there is any hardware bug.
> > But, even though this were a hardware bug and could be fixed, we would
> > still need this patch since many SB600 boards have already come into
> > the market and those ASICs can never be fixed :(
>
> Yeap, we certainly need the workaround.  I was just having a little fun.
>  :-)
>
> >> 4381 isn't affected while 4380 is?
> >
> > I never see such an ID, and plan to remove 0x4381.
> > The patch which added the PCI IDs was not sent out by myself. I
> > checked all SB600 boards, and not found any 0x4381 controller, only
> > 0x4380 instead. In fact, SB600 RAID and Non-RAID share the same PCI
> > device ID, only with class code different.
>
> I see.
>
> >> Anyways, Conke Hu, can you please take a look at my patch from a month
> >> ago?  It's almost identical but SERR_INTERNAL is always ignored on both
> >> SB600 PCI IDs, which I think is safer.  Does this fix what you're seeing?
> >>
> >
> > I just read your patch. Another difference is that my patch ignores
> > SERR_INTERNAL only when the command is ATAPI and IRQ_TF_ERR occurs. In
> > other cases, I think, we'd better not ignore the SERR_INTERNEL. Right?
>
> Yeah, I noticed the difference.  I don't really care but I was thinking
> that SERR_INTERNAL might be set in other similar situations too.  e.g.
> TF error from ATA device or what not, so I thought it would be safer to
> ignore the bit altogether.  You probably need to consult your hardware
> people about when exactly the bit misbehaves but unless proven
> otherwise, I'd prefer to always ignore the bit.  Also, please rename the
> enum constant and flag name.
>

Thank you, Tejun!
I was discussing with our HW designers on this topic. It is a HW
design issue and will be fixed in SB700, the next generation of
AMD/ATI southbridge.

The correct walkaround/solution for SB600 SATA is:
1. ignore SERR_INTERNAL for both ATA and ATAPI device (as you suggested :p ).
2. ignore SERR_INTERNAL only on IRQ_TF_ERR.

I'll re-create the patch.

Conke
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/