A8N-SLi Premium, Maxtor 6V300F0 - some strange behaviour

[Wolfgang Draxinger]

First I must apologize at the readers in the german NGs, that
this is a crosspost in english NGs with english text, but I want
to keep it in a single thread and spread it internationally; the
more people can read it, the higher the probability that someone
other who reads this has the same problems.

Last weekend I got the components for my new system, with the
motherboard being an Asus A8N-SLi Premium and 3 Maxtor 6V300F0
SATA (Diamondmax 10) HDDs for storage. The HDDs are connected to
the nForce4 SATA Controller and I got both Linux and Windows
installed without major problems. But I stumbled over some
strange bahaviour and I hope someone may have an idea on what's
going on.

The first and most annoying is, that after some resets (either
warm reboot, or reset by reset switch) some of the HDDs don't
get recognized. Thereafer only a complete poweroff/poweron will
make them get recognized again. I have not yet found a way to
reproduce this behaviour, it just happens sometime. Notable is,
that allthough it's not determined which HDDs will get not
recognized, after a reset the same HDDs doesn't get recognized
again. Also I never had experienced the case that all HDDs don't
get recognized. I first stumbled over this, after I've boot into
Linux and the "md" RAID-5 I created from _partitions_ on the
disks (the partitions are on exactly the same blocks on all
HDDs) was reported to be about to fail. This also indicates,
that it is not a pure BIOS problem, since Linux doesn't see the
HDDs either in the case this happens.

The second strangenes, not really a problem, but more a brain
twister are some discrepancies between the numbering of the HDDs
in the BIOS configuration, the boot sequence and the numbering
in by the operating systems. The mainboard has 4 SATA
connectors, numberes SATA 1 to SATA 4 (well, that's logical and
nothing else expected). Of course I connected my HDDs in the
order 1,2,3. The strange happend when I tried to boot the Linux
I had installed on /dev/sda, expecting that this would be the
device identified by the BIOS as SATA 1. However instead of SATA
1 my Linux seems to have found it's way to the HDD identified by
the BIOS as SATA 3. But now it comes: Windows get's booted from
BIOS SATA 1, but Linux sees it on /dev/sdb (the second HDD). And
to top it: Linux and Windows agree, that Linux lies on HDD 1,
Windows on HDD 2 and that the first 30GB on HDD 3 are still
unformated.
Okay, here comes a table to summarize:

#HDD: SATA connector used

#HDD | OS | BIOS |
-----+----+------+
1 | 2 | 3 |
-----+----+------+
2 | 3 | 2 |
-----+----+------+
3 | 1 | 1 |

And maybe it's getting even more weird if I connect a fourth HDD.
I'd like to do to see what happens, but unfortunately I got no
spare one.

And last but not least I got a question about the Sil 3114
controller SW-RAID BIOS. After I got the components I was
experimenting a bit with the components to see what fits my
needs the best. I also tried out to use the Sil 3114 RAID for
both Linux (using dmraid to map it to Linux md functionality)
and Windows, so that they would share the RAID. But in the end I
didn't like it. So I straightly rewired the HDDs to the nForce4
SATA controller without deleting the RAID from them. I expected,
that after putting fresh partition tables and filesystems on
them there would remain no rests from the RAID configuration.
But after the "HDD doesn't get recognized" problem I wanted to
try them on the Sil 3114, but magically the Sil saw them in a
RAID again; if I have the HDD not connected to the Sil it's RAID
BIOS shows no RAID config. So either the RAID configuration gets
stored somewhere in the CMOS or the RAID controller, or on a
part of the disk, where fdisk and mkfs/format don't get. The
question is, if I can delete the RAID in the Sil RAID BIOS while
having the HDDs connected without having the data on them fried
or not.


And before someone replies "use google": I did and got tons of
complaints about data corruption and other strange stuff with a
A8N Maxtor combination, but I've experienced none of those. Once
the system is running it's ultra stable and I got none of the
problems discribed on the pages google reports me.

Thanks in advance for every usefull idea, hint and awnser that I
get to my problems, oberservations and questions.

Wolfgang Draxinger

Output from lspci and relevant parts of hal-device and Linux
kernel log following (and please remove this in all replies,
it's really not neccesary to cite this), the kernel used is
Linux 2.6.15 Gentoo patchset R5:

### lspci ###
00:00.0 Memory controller: nVidia Corporation CK804 Memory
Controller (rev a3)
00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller
(rev a2)
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller
(rev a3)
00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2)
00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA
Controller (rev f3)
00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA
Controller (rev f3)
00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2)
00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev
a3)
00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Miscellaneous Control
01:00.0 VGA compatible controller: nVidia Corporation GeForce
7800 GT (rev a1)
05:06.0 Multimedia audio controller: Creative Labs SB Audigy (rev
04)
05:06.1 Input device controller: Creative Labs SB Audigy
MIDI/Game port (rev 04)
05:06.2 FireWire (IEEE 1394): Creative Labs SB Audigy FireWire
Port (rev 04)
05:0b.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A
IEEE-1394a-2000 Controller (PHY/Link)
05:0c.0 Ethernet controller: Marvell Technology Group Ltd.
88E8001 Gigabit Ethernet Controller (rev 13)

### hal-device entries for HDD 1-3 ###
9: udi = '/org/freedesktop/Hal/devices/storage_serial_V6012QKG'
block.storage_device =
'/org/freedesktop/Hal/devices/storage_serial_V6012QKG' (string)
info.udi =
'/org/freedesktop/Hal/devices/storage_serial_V6012QKG' (string)
storage.serial = 'V6012QKG' (string)
info.category = 'storage' (string)
info.product = 'Maxtor 6V300F0' (string)
info.vendor = 'ATA' (string)
storage.physical_device =
'/org/freedesktop/Hal/devices/pci_10de_54_scsi_host_0_scsi_device_lun0' (string)
storage.lun = 0 (0x0) (int)
storage.drive_type = 'disk' (string)
storage.vendor = 'ATA' (string)
storage.model = 'Maxtor 6V300F0' (string)
storage.bus = 'scsi' (string)
block.minor = 0 (0x0) (int)
block.major = 8 (0x8) (int)
block.device = '/dev/sda' (string)
info.parent =
'/org/freedesktop/Hal/devices/pci_10de_54_scsi_host_0_scsi_device_lun0' (string)
linux.sysfs_path_device = '/sys/block/sda' (string)
linux.sysfs_path = '/sys/block/sda' (string)

12: udi = '/org/freedesktop/Hal/devices/storage_serial_V601J4XG'
storage.policy.should_mount = false (bool)
block.storage_device =
'/org/freedesktop/Hal/devices/storage_serial_V601J4XG' (string)
info.udi =
'/org/freedesktop/Hal/devices/storage_serial_V601J4XG' (string)
storage.serial = 'V601J4XG' (string)
info.product = 'Maxtor 6V300F0' (string)
info.vendor = 'ATA' (string)
storage.physical_device =
'/org/freedesktop/Hal/devices/pci_10de_55_scsi_host_0_scsi_device_lun0' (string)
storage.lun = 0 (0x0) (int)
storage.drive_type = 'disk' (string)
storage.vendor = 'ATA' (string)
storage.model = 'Maxtor 6V300F0' (string)
storage.bus = 'scsi' (string)
block.minor = 16 (0x10) (int)
block.major = 8 (0x8) (int)
block.device = '/dev/sdb' (string)
'/org/freedesktop/Hal/devices/pci_10de_55_scsi_host_0_scsi_device_lun0' (string)
linux.sysfs_path_device = '/sys/block/sdb' (string)
linux.sysfs_path = '/sys/block/sdb' (string)

15: udi = '/org/freedesktop/Hal/devices/storage_serial_V601N2WG'
block.storage_device =
'/org/freedesktop/Hal/devices/storage_serial_V601N2WG' (string)
info.udi =
'/org/freedesktop/Hal/devices/storage_serial_V601N2WG' (string)
storage.serial = 'V601N2WG' (string)
info.product = 'Maxtor 6V300F0' (string)
info.vendor = 'ATA' (string)
storage.physical_device =
'/org/freedesktop/Hal/devices/pci_10de_55_scsi_host_scsi_device_lun0' (string)
storage.lun = 0 (0x0) (int)
storage.drive_type = 'disk' (string)
storage.vendor = 'ATA' (string)
storage.model = 'Maxtor 6V300F0' (string)
storage.bus = 'scsi' (string)
block.minor = 32 (0x20) (int)
block.major = 8 (0x8) (int)
block.device = '/dev/sdc' (string)
'/org/freedesktop/Hal/devices/pci_10de_55_scsi_host_scsi_device_lun0' (string)
linux.sysfs_path_device = '/sys/block/sdc' (string)
linux.sysfs_path = '/sys/block/sdc' (string)

### Kernel log, SATA device enumeration ###
ata1: SATA max UDMA/133 cmd 0x9F0 ctl 0xBF2 bmdma 0xD800 irq 217
ata2: SATA max UDMA/133 cmd 0x970 ctl 0xB72 bmdma 0xD808 irq 217
ata1: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4773 85:7c69 86:3e01
87:4763 88:407f
ata1: dev 0 ATA-7, max UDMA/133, 586114704 sectors: LBA48
nv_sata: Primary device added
nv_sata: Primary device removed
nv_sata: Secondary device added
nv_sata: Secondary device removed
ata1: dev 0 configured for UDMA/133
scsi0 : sata_nv
ata2: no device found (phy stat 00000000)
scsi1 : sata_nv
Vendor: ATA Model: Maxtor 6V300F0 Rev: VA11
Type: Direct-Access ANSI SCSI revision:
05
ACPI: PCI Interrupt Link [APSJ] enabled at IRQ 22
GSI 17 sharing vector 0xE1 and IRQ 17
ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [APSJ] -> GSI 22
(level, low) -> IRQ 225
PCI: Setting latency timer of device 0000:00:08.0 to 64
ata3: SATA max UDMA/133 cmd 0x9E0 ctl 0xBE2 bmdma 0xC400 irq 225
ata4: SATA max UDMA/133 cmd 0x960 ctl 0xB62 bmdma 0xC408 irq 225
ata3: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4773 85:7c69 86:3e01
87:4763 88:407f
ata3: dev 0 ATA-7, max UDMA/133, 586114704 sectors: LBA48
nv_sata: Primary device added
nv_sata: Primary device removed
nv_sata: Secondary device added
nv_sata: Secondary device removed
ata3: dev 0 configured for UDMA/133
scsi2 : sata_nv
ata4: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4773 85:7c69 86:3e01
87:4763 88:407f
ata4: dev 0 ATA-7, max UDMA/133, 586114704 sectors: LBA48
nv_sata: Primary device added
nv_sata: Primary device removed
nv_sata: Secondary device added
nv_sata: Secondary device removed
ata4: dev 0 configured for UDMA/133
scsi3 : sata_nv
Vendor: ATA Model: Maxtor 6V300F0 Rev: VA11
Type: Direct-Access ANSI SCSI revision:
05
Vendor: ATA Model: Maxtor 6V300F0 Rev: VA11
Type: Direct-Access ANSI SCSI revision:
05
SCSI device sda: 586114704 512-byte hdwr sectors (300091 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 586114704 512-byte hdwr sectors (300091 MB)
SCSI device sda: drive cache: write back
sda: sda1 sda2 sda3 sda4
sd 0:0:0:0: Attached scsi disk sda
SCSI device sdb: 586114704 512-byte hdwr sectors (300091 MB)
SCSI device sdb: drive cache: write back
SCSI device sdb: 586114704 512-byte hdwr sectors (300091 MB)
SCSI device sdb: drive cache: write back
sdb: sdb1 sdb2
sd 2:0:0:0: Attached scsi disk sdb
SCSI device sdc: 586114704 512-byte hdwr sectors (300091 MB)
SCSI device sdc: drive cache: write back
SCSI device sdc: 586114704 512-byte hdwr sectors (300091 MB)
SCSI device sdc: drive cache: write back
sdc: sdc1 sdc2
sd 3:0:0:0: Attached scsi disk sdc

--

 

[Steffen Bruns]

...
Last weekend I got the components for my new system, with the
motherboard being an Asus A8N-SLi Premium and 3 Maxtor 6V300F0
SATA (Diamondmax 10) HDDs for storage. The HDDs are connected to
the nForce4 SATA Controller and I got both Linux and Windows
installed without major problems. But I stumbled over some
strange bahaviour and I hope someone may have an idea on what's
going on.

The first and most annoying is, that after some resets (either
warm reboot, or reset by reset switch) some of the HDDs don't
get recognized. Thereafer only a complete poweroff/poweron will
make them get recognized again. I have not yet found a way to
reproduce this behaviour, it just happens sometime. ...

http://www.computerbase.de/news/hardware/laufwerke/massenspeicher/2006/f
ebruar/maxtor_inkompatibilitaet_nforce_4/


Steffen

 

[Chris]

First I must apologize at the readers in the german NGs, that
this is a crosspost in english NGs with english text, but I want
to keep it in a single thread and spread it internationally; the
more people can read it, the higher the probability that someone
other who reads this has the same problems.

What you should really be apologising for is the huge number of
cross-posts. You have no reason to cross-post to more than 2-3 ngs.

The first and most annoying is, that after some resets (either
warm reboot, or reset by reset switch) some of the HDDs don't
get recognized. Thereafer only a complete poweroff/poweron will
make them get recognized again. I have not yet found a way to
reproduce this behaviour, it just happens sometime. Notable is,
that allthough it's not determined which HDDs will get not
recognized, after a reset the same HDDs doesn't get recognized
again. Also I never had experienced the case that all HDDs don't
get recognized. I first stumbled over this, after I've boot into
Linux and the "md" RAID-5 I created from _partitions_ on the
disks (the partitions are on exactly the same blocks on all
HDDs) was reported to be about to fail. This also indicates,
that it is not a pure BIOS problem, since Linux doesn't see the
HDDs either in the case this happens.

Is your PSU powerful enough? Three HDDs and a GF 7800 GT will suck a lot
of juice esp. at boot. You will need at least 450W of good quality
power.

 

[Wolfgang Draxinger]

Is your PSU powerful enough? Three HDDs and a GF 7800 GT will
suck a lot of juice esp. at boot. You will need at least 450W
of good quality power.

I got a 500W Enermax PSU - no problem there. As I already state I
never got these problem on a fresh powerup. It's only happening
if the system was already running and I did a reboot or a hard
reset.

Wolfgang Draxinger
--

 

[Rod Speed]

Wolfgang Draxinger wrote

What you should really be apologising for is the huge number of
cross-posts. You have no reason to cross-post to more than 2-3 ngs.

Wrong. Particularly with an unusual fault like that.

 

[Arno Wagner]

First I must apologize at the readers in the german NGs, that
this is a crosspost in english NGs with english text, but I want
to keep it in a single thread and spread it internationally; the
more people can read it, the higher the probability that someone
other who reads this has the same problems.

Last weekend I got the components for my new system, with the
motherboard being an Asus A8N-SLi Premium and 3 Maxtor 6V300F0
SATA (Diamondmax 10) HDDs for storage. The HDDs are connected to
the nForce4 SATA Controller and I got both Linux and Windows
installed without major problems. But I stumbled over some
strange bahaviour and I hope someone may have an idea on what's
going on.

The first and most annoying is, that after some resets (either
warm reboot, or reset by reset switch) some of the HDDs don't
get recognized. Thereafer only a complete poweroff/poweron will
make them get recognized again. I have not yet found a way to
reproduce this behaviour, it just happens sometime. Notable is,
that allthough it's not determined which HDDs will get not
recognized, after a reset the same HDDs doesn't get recognized
again. Also I never had experienced the case that all HDDs don't
get recognized. I first stumbled over this, after I've boot into
Linux and the "md" RAID-5 I created from _partitions_ on the
disks (the partitions are on exactly the same blocks on all
HDDs) was reported to be about to fail. This also indicates,
that it is not a pure BIOS problem, since Linux doesn't see the
HDDs either in the case this happens.

Check whether this only happens when Linux or when Windows was
the previous OS running. It is possible that either OS
initialises the hardware in a way that prevents clean
re-initialisation by the other OS or the BIOS. If Linux is the
problem, then try with a different kernel and look into the
kernel bugzilla (bugzilla.kernel.org) whether this is a known
problem. If not, file a bug report.

I had a similar problem with 2.6.15: It ould initialise my
Marvell GbE controller in a way that only a complete poweroff
(switch off on the PSU) would make it accessable again under XP
or 2.6.12. I think 2.6.12 is a good kernel to use for comparison.

The second strangenes, not really a problem, but more a brain
twister are some discrepancies between the numbering of the HDDs
in the BIOS configuration, the boot sequence and the numbering
in by the operating systems.

[...]

Not surprising: The controller BIOS likely numbers the connectors
in a not obvious order. That works as long as you rely on the
BIOS. Linux brings its own drivers and uses a generic order,
bypassing the BIOS. Solution: Boot from sda, but tell the
kernel that the root partition is on sdc. The Kernel will not
mind. It does not care where it is loaded from.

And last but not least I got a question about the Sil 3114
controller SW-RAID BIOS.

[...]

No idea about this one.

And before someone replies "use google": I did and got tons of
complaints about data corruption and other strange stuff with a
A8N Maxtor combination, but I've experienced none of those. Once
the system is running it's ultra stable and I got none of the
problems discribed on the pages google reports me.

Thanks in advance for every usefull idea, hint and awnser that I
get to my problems, oberservations and questions.

Wolfgang Draxinger

Gr"iusse,
Arno

 

[Folkert Rienstra]

What you should really be apologising for is the huge number of
cross-posts. You have no reason to cross-post to more than 2-3 ngs.

So then, when will you be apologising to him for not having bothered to
even carefully read his post -that may have taken him hours to craft-
for more than 10 seconds.

Is your PSU powerful enough?
Three HDDs and a GF 7800 GT will suck a lot of juice

esp. at boot.

At a cold (powerup) boot. If you had bothered to read his post
you would have known that's not when he has the problems.
When he finally does a cold boot, that is when he recovers.

 

[Wolfgang Draxinger]

Check whether this only happens when Linux or when Windows was
the previous OS running.

Nope, it doesn't depend on the OS. It even happens if I use
GRUB's command line to reboot the system, and I really doubt,
that GRUB does any initialization or other stuff to the
controllers.

In fact it seems, that this is related to some HDD firmware
issue. Maxtor reported, that their SATA-II HDDs have issues with
the nForce4 chipset and provide a firmware upgrade for the HDDs
(you must contact them by phone or E-Mail and they will send you
a bootable ISO image with the flash utility by E-Mail to you
then). There's also the possibility to send in the HDD as RMA
and they flash it for you.

As a workaround some articles state that the HDD should be
jumpered into SATA-I mode, but actually this didn't work for me,
it made things even worse :-(

Now I wait for that ISO image and hope, that it will help. And I
hope, that I can flash the HDD without trouble. (Wish me luck)

Not surprising: The controller BIOS likely numbers the
connectors in a not obvious order. That works as long as you
rely on the BIOS. Linux brings its own drivers and uses a
generic order, bypassing the BIOS. Solution: Boot from sda, but
tell the kernel that the root partition is on sdc. The Kernel
will not mind. It does not care where it is loaded from.

Well, as a Linux user (and developer) since 1996 I know, that
Linux cares about the BIOS as much like I care about a sack of
rice falling in china. But I also know, that Windows at least
shows some "respect" for what the BIOS tells it, and I was
rather suprised, that Windows enumerates the HDDs in the very
same way like Linux then.

I did a bit of experimentation and was able to unclutter the
enumeration schemes. We have to distinguish between 3 numbers a
HDD gets assigned.
- First there is the number "A" shown by the BIOS configuration
tool and the boot device selection tool.
- Sencondly there is the HDDs numbers "B" the BIOS reports to the
bootloaders via some BIOS calls
- And third there is the HDD number "C" as seen by the OS, if it
does it's enumeration based on the PCI Bus ID (I figured out,
that the both SATA controllers get assigned their Bus ID in the
reverse order as the BIOS enumerates them)

Now while A is static B and C are dynamic, depending on the
amount of disks connected, but they are easily predicted onece
you figured out the scheme.

A is just the number of the SATA connector as it is printed in
the mainboard manual or on the mainboard itself. No magic here.

The bootsequence B is determined by iterating through the
connectors A in order. So if e.g. HDDs are connected to A1, A3
and A4 the boot sequence mapping is B1<->A1, B2<->A3, B3<->A4.
Well if you think about it it's really logical and can be
expected.

The ordering of C is dynamic too, but the iteration scheme is
different to the boot sequence numbering. The OS sees the HDDs
in the order A3, A4, A1, A2 (this is due to the "swapped" Bus
IDs). Thus if we take our example of HDDs connected to A1, A3
and A4 it will result in C1<->A3, C2<->A4, C3<->A1. It looks
weird if you stumble over it in the first place, but one you
figured it out it's really predictable.

Now I also see what was probably happening at Asus: Some guy
placed the SATA connectors 1-4 in the PCB Editor, but accidently
swapped the naming 1,2 <-> 3,4 (this sort of thing happens very
oftenly in PCB designs; happend to me, too, 2 or 3 times yet,
and it probably won't be the only ones). Technically everything
was allright, it were only _printed_ numbers swapped and printed
wrongly on both the PCB and in the manual. Now some bottom
feeder of manager or marketeer (somehow I must think of Stef
from Userfriendly.org ;-)) thougt: "What a bad look does this
mistake cast on our company!" and so forced one of the poor BIOS
developers to swap the naming and enumeration within the BIOS.
Everything looked fine to the manager/marketeer but being not on
his heights of modern operating systems he didn't knew, that the
BIOS has become one of the least important bits of code in a
computer system nowadays, and that OS do their very own
enumeration. In fact I think, that it would have been better to
add a errata document to the manual, at best printed on some
flourescent red paper with a big exclamation mark.

Wolfgang Draxinger
--

 

[Arno Wagner]

Arno Wagner wrote:

Nope, it doesn't depend on the OS. It even happens if I use
GRUB's command line to reboot the system, and I really doubt,
that GRUB does any initialization or other stuff to the
controllers.

Interesting. Then it is a BIOS or hardware issue.

In fact it seems, that this is related to some HDD firmware
issue. Maxtor reported, that their SATA-II HDDs have issues with
the nForce4 chipset and provide a firmware upgrade for the HDDs
(you must contact them by phone or E-Mail and they will send you
a bootable ISO image with the flash utility by E-Mail to you
then). There's also the possibility to send in the HDD as RMA
and they flash it for you.

Sounds reasonable. Then you should the the ISO image and
flash the new firmware.

As a workaround some articles state that the HDD should be
jumpered into SATA-I mode, but actually this didn't work for me,
it made things even worse :-(

Now I wait for that ISO image and hope, that it will help. And I
hope, that I can flash the HDD without trouble. (Wish me luck)

Good luck! Should work though, unless you have a not too stable
system.

Well, as a Linux user (and developer) since 1996 I know, that
Linux cares about the BIOS as much like I care about a sack of
rice falling in china. But I also know, that Windows at least
shows some "respect" for what the BIOS tells it, and I was
rather suprised, that Windows enumerates the HDDs in the very
same way like Linux then.
[...]

Now I also see what was probably happening at Asus: Some guy
placed the SATA connectors 1-4 in the PCB Editor, but accidently
swapped the naming 1,2 <-> 3,4 (this sort of thing happens very
oftenly in PCB designs; happend to me, too, 2 or 3 times yet,
and it probably won't be the only ones). Technically everything
was allright, it were only _printed_ numbers swapped and printed
wrongly on both the PCB and in the manual. Now some bottom
feeder of manager or marketeer (somehow I must think of Stef
from Userfriendly.org ;-)) thougt: "What a bad look does this
mistake cast on our company!" and so forced one of the poor BIOS
developers to swap the naming and enumeration within the BIOS.
Everything looked fine to the manager/marketeer but being not on
his heights of modern operating systems he didn't knew, that the
BIOS has become one of the least important bits of code in a
computer system nowadays, and that OS do their very own
enumeration. In fact I think, that it would have been better to
add a errata document to the manual, at best printed on some
flourescent red paper with a big exclamation mark.

Actually that is pretty close to what I suspected.

Arno

 

[General Schvantzkoph]

On Thu, 16 Feb 2006 03:28:58 +0100, Wolfgang Draxinger wrote:

I saw a mention on one of the news sites last week that Maxtor has issued
a firmware patch to fix an incompatibility Nforce 4 chipsets. If you can
exchange those Maxtor drives for a decent brand like Seagate that would be
your best course of action.