Mailing List Archive

On Thu, 7 Oct 2004 20:21:05 -0700 (PDT), Dustin
<laurence@alice.caltech.edu> wrote:
> Here's a fairly naive question. I'm trying to track down suspected rare
> flaky disk behavior. The system is:
>
> NF7-S (SATA controller is Silicon Image)
> Athlon XP 2600+
> Hitachi SATA drives
>
> I've heard some people have had trouble with SATA systems, and a logical
> step would be to flash the m'board to the latest Abit bios (there was a
> SATA controller upgrade sometime after my BIOS version), but...seems like
> I remember that Linux ignores the BIOS after booting.

Ummmm, I'm not sure where you heard this, but the BIOS is the basic
interface between the hardware and the software. Linux can't ignore
the BIOS, it couldn't run.

> If so, does the
> BIOS version actually matter when running Linux? And more generally, is
> there a good package for stress-testing a disk drive? At this point
> running a stress test overnight or longer seems like a good idea.
>

--
paperCrane --Justin Patrin--

--
gentoo-user@gentoo.org mailing list

On 7 Oct 2004, at 21:41, Justin Patrin wrote:
> On Thu, 7 Oct 2004 20:21:05 -0700 (PDT), Dustin
> <laurence@alice.caltech.edu> wrote:
>> Here's a fairly naive question. I'm trying to track down suspected
>> rare
>> flaky disk behavior. The system is:
>>
>> NF7-S (SATA controller is Silicon Image)
>> Athlon XP 2600+
>> Hitachi SATA drives
>>
>> I've heard some people have had trouble with SATA systems, and a
>> logical
>> step would be to flash the m'board to the latest Abit bios (there was
>> a
>> SATA controller upgrade sometime after my BIOS version), but...seems
>> like
>> I remember that Linux ignores the BIOS after booting.
>
> Ummmm, I'm not sure where you heard this, but the BIOS is the basic
> interface between the hardware and the software. Linux can't ignore
> the BIOS, it couldn't run.

False. Linux generally bypasses the BIOS for most I/O. For example, an
old
Compaq machine I've got has a BIOS that doesn't support hard disks above
8GB. It complains on startup, but runs just fine under Linux, because
the
Linux kernel just addresses the disk controller directly. This is
standard
behaviour.

On Fri, 8 Oct 2004 16:41:04 -0700, Andrew Farmer <andfarm@teknovis.com> wrote:
> On 7 Oct 2004, at 21:41, Justin Patrin wrote:
> > On Thu, 7 Oct 2004 20:21:05 -0700 (PDT), Dustin
> > <laurence@alice.caltech.edu> wrote:
> >> Here's a fairly naive question. I'm trying to track down suspected
> >> rare
> >> flaky disk behavior. The system is:
> >>
> >> NF7-S (SATA controller is Silicon Image)
> >> Athlon XP 2600+
> >> Hitachi SATA drives
> >>
> >> I've heard some people have had trouble with SATA systems, and a
> >> logical
> >> step would be to flash the m'board to the latest Abit bios (there was
> >> a
> >> SATA controller upgrade sometime after my BIOS version), but...seems
> >> like
> >> I remember that Linux ignores the BIOS after booting.
> >
> > Ummmm, I'm not sure where you heard this, but the BIOS is the basic
> > interface between the hardware and the software. Linux can't ignore
> > the BIOS, it couldn't run.
>
> False. Linux generally bypasses the BIOS for most I/O. For example, an
> old
> Compaq machine I've got has a BIOS that doesn't support hard disks above
> 8GB. It complains on startup, but runs just fine under Linux, because
> the
> Linux kernel just addresses the disk controller directly. This is
> standard
> behaviour.
>

It still has to use the BIOS for the initial boot-up, though. It can
only bypass it once it's started the basic system. Updating a BIOS
*can* help things, even if Linux bypasses it for the normal I/O.

--
paperCrane --Justin Patrin--

--
gentoo-user@gentoo.org mailing list

On Fri, 8 Oct 2004, Justin Patrin wrote:

> It still has to use the BIOS for the initial boot-up, though. It can
> only bypass it once it's started the basic system. Updating a BIOS
> *can* help things, even if Linux bypasses it for the normal I/O.

What I've been able to track down so far is that NF7-S BIOSes 21 and 22
contained buggy SATA code (4.2.43) and seemed to cause a number of people
similar disk corruption problems. I've flashed to v26, which is reported
to have a working SATA BIOS (4.2.47). This took a fair amount of hunting.

Since I can't trust anything on the system, I'll have to do a complete
reinstall, but I'd like to know if the problems are likely solved first.
Problem is, all the reports I've been able to track down so far are from
MS-Windows users, as you might guess. Since I don't have a diagnostic
(until the rare situation where something fails to write properly), I
don't really know if I've solved the problem or not. if it's a driver
problem I've done nothing. I'm still searching for more info and was
hoping someone here had hit the same problem.

Another possibility I'm trying to track down: I just found a mention of
there being two kernel drivers for this controller, and IDE-system driver
and a SCSI-like driver. It's possible I am accidentally using the wrong
driver in addition to whatever BIOS problems I may or may not have. Best
if I know which to use before I rebuild.

On the brighter side, I've been blaming Gentoo for my instability
problems, well and also the loose nut behind the keyboard. It'd be nice
if it turns out that not only is Gentoo more stable than I had come to
suspect, but I can even feel good that I've kept the poor thing limping
along as long as I have with intermittent disk corruption.

Dustin


--
gentoo-user@gentoo.org mailing list

I fired off that message a little too fast. I've hunted down the specific
drivers: the IDE subsystem driver is "siimage" and the SCSI driver is
"sata_sil". The latter appears to be marked experimental in both. I used
the former.

So the question is, which is the preferred driver for Silicon Image 3112a
chipsets, or better yet specifically the Abit NF7 boards: siimage.ko or
sata_sil.ko? Does it matter which kernel we're talking about (running 2.6
but would re-install on 2.4 because of the dropped Philips webcam support
in 2.6)?

Dustin


--
gentoo-user@gentoo.org mailing list