Re: Promise PDC20376

[David Ellingsworth]

On Fri, Oct 24, 2008 at 9:04 AM, David Ellingsworth
<da...@identd.dyndns.org> wrote:
> I recently purchased a Seagate 1.5 TB drive to attach to the Promise
> Fasttrak SATA 376 (PDC20376) controller on my Asus A7V8X motherboard.
> After installing the drive, I went into the FastTrak setup and
> configured a simple array which consisted only of this drive. At this
> point I noticed the FastTrak setup could not identify the drive's
> size, none the less it reported the array as functional upon reboot
> and showed what appeared to be the Cylinder/Sectors/Head count for the
> array. Next, I proceeded to install a rather recent copy of Kbuntu
> with kernel version 2.6.20. The Kbuntu installer found the array and
> installed without incident. However upon trying to boot into the newly
> installed copy of Linux, Grub stopped at stage 1.5 with an error code
> of 17. I've read that this error code is usually the result of Grub
> not being able to identify the type of file system or that Grub's
> drive mapping didn't match the one used by the bios. As I only have
> the one drive in the system, it seems unlikely that Grub was
> misconfigured.
>
> Upon having little success installing Linux, I attempted to install
> Windows XP to see if it's boot loader suffered from the same problem.
> To my surprise, the Windows boot loader also halted with an error. The
> error was "A drive read error has occurred. Please press Ctrl+Alt+Del
> to restart." As a result of both Linux and Windows failing to boot, I
> believe this problem may be a result of firmware/bios used for the
> on-board Promise SATA controller, which unfortunately is embedded in
> the system bios.
>
> Asus's technical support indicated that even if this is the case they
> will _not_ release an updated bios for this board. In any event, there
> are a few things I have yet to try. Like (1) trying the latest kernel
> version and sata_promise driver during install, (2) using a newer
> version of Grub, and (3) attempting to boot the drive using another
> SATA controller. If neither 1 nor 2 correct the issue and the drive
> operates fine under 3 then my only option is to update the
> firmware/bios for the on-board controller to see if it resolves the
> issue.
>
> The current firmware/bios version of the controller as reported by
> FastTrak is 1.00.0.21 which is provided with the latest Asus bios
> release for this motherboard. After a lot of searching I have been
> unable to find a firmware/bios revision newer than the one I currently
> have for this chip. However, I did see that Promise has a 1.00.0.37
> bios/firmware for their FastTrak S150 TX2plus card. This card uses
> their PDC20371 chip and the features it provides seem fairly similar
> to those of the PDC20376, but it's unknown if its firmware/bios would
> be compatible with the PDC20376.
>
> I'm therefore left wondering what differences exist between these two
> chips and whether or not using the firmware/bios for the PDC20371 with
> the PDC20376 could cause any major damage. Can anyone familiar with
> these chips foresee any issues or problems with doing something like
> this?

Since I put this out there, I felt it was important to follow-up on so
others could benefit from my experiences. After extensive testing, the
cause of the problems I've experienced are a result of a bug in the
Fasttrak bios for the Promise 376 controller. Specifically speaking,
bios interrupt 13h, AH=42 fails to read the requested sector from the
drive despite the fact that bios interrupt 13h, AH=41, BX=0x55AA
indicates the drive supports LBA extensions. The only known
work-around at this time is to limit the size of the primary boot
partition to 8GB or less and place it below the 8GB boundary where LBA
extensions are not required to read the drive. I have contacted
Promise concerning this issue and will provide more updates if
anything metabolizes. Until then any users experiencing similar issues
should use the work-around I've described above to boot the operating
system of their choice.

Regards,

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

[Mikael Pettersson]

For booting with grub only /boot needs to be accessible by the BIOS,
so it's common to make /boot a separate partition early on the disk
with / and other partitions higher up.

This is the first I've heard of any Promise SATA controller having
such lame limitations.

[David Ellingsworth]

> > Since I put this out there, I felt it was important to follow-up on so
> > others could benefit from my experiences. After extensive testing, the
> > cause of the problems I've experienced are a result of a bug in the
> > Fasttrak bios for the Promise 376 controller. Specifically speaking,
> > bios interrupt 13h, AH=42 fails to read the requested sector from the
> > drive despite the fact that bios interrupt 13h, AH=41, BX=0x55AA
> > indicates the drive supports LBA extensions. The only known
> > work-around at this time is to limit the size of the primary boot
> > partition to 8GB or less and place it below the 8GB boundary where LBA
> > extensions are not required to read the drive. I have contacted
> > Promise concerning this issue and will provide more updates if
> > anything metabolizes. Until then any users experiencing similar issues
> > should use the work-around I've described above to boot the operating
> > system of their choice.
>
> For booting with grub only /boot needs to be accessible by the BIOS,
> so it's common to make /boot a separate partition early on the disk
> with / and other partitions higher up.
>
> This is the first I've heard of any Promise SATA controller having
> such lame limitations.
>

A small update to this. It seems the above mentioned interrupt fails
somewhere around the 128GB boundary. Interrupt 13h, AH=42 uses a 64
bit sector address and should be capable of addressing the entire
drive. For a SATA controller, this limitation seems relatively
arbitrary. For IDE controllers, a limitation such as this is
apparently common.

Regards,

David Ellingsworth

[Alan Cox]

> A small update to this. It seems the above mentioned interrupt fails
> somewhere around the 128GB boundary. Interrupt 13h, AH=42 uses a 64
> bit sector address and should be capable of addressing the entire
> drive. For a SATA controller, this limitation seems relatively
> arbitrary. For IDE controllers, a limitation such as this is
> apparently common.

137GB I would imagine. That is the point at which LBA48 commands must be
used not LBA28 and presumably their BIOS code only supports old format
commands

[David Ellingsworth]

On Tue, Dec 2, 2008 at 5:50 AM, Alan Cox <al...@lxorguk.ukuu.org.uk> wrote:
>> A small update to this. It seems the above mentioned interrupt fails
>> somewhere around the 128GB boundary. Interrupt 13h, AH=42 uses a 64
>> bit sector address and should be capable of addressing the entire
>> drive. For a SATA controller, this limitation seems relatively
>> arbitrary. For IDE controllers, a limitation such as this is
>> apparently common.
>
> 137GB I would imagine. That is the point at which LBA48 commands must be
> used not LBA28 and presumably their BIOS code only supports old format
> commands
>

Right, with LBA28 addressing you get 2^28 sector addresses = 2^27 KiB
= 2^17 MiB = 2^7 GiB = 128 GiB which is approximately 137GB. When I
wrote 128GB I really meant 128 GiB.

Regards,

David Ellingsworth

P.S. I hate the "new" binary size notations they only cause confusion.