Debian (Knoppix) on HP a350n

[Rick Moen]

Hi, Steve.

Quoting sms@sonic.net (sms@sonic.net):

[ICH5 is similar enough to preceding Intel ATA chipsets that Linux 
support doesn't usually have serious problems:]

> That isn't the... "impression" I got from the Google'ing & reading I did
> last month.  I can only be happy it worked easier than I expected.

<shrug>

I'm dependent on the same anecdotal evidence + other readings and
surmises, since I haven't actually encountered any of this hardware
(yet).  My impression is that ICH5 support pretty much worked by around
2.4.18 -- which is of interest to Debian users because it's what the
Official Debian 3.0/woody installer's bf24 installation "flavour" uses.
Reportedly, the failure mode when it does fail is in the form of system
freeze-ups.

So, I'm inferring that a lot of the impression you got was from users of
earlier kernels -- but also that 2.4.18's support was, even at that,
pretty iffy.

> Yes; I *think* I'm running 2.4.24 (per the Knoppix site; but I'm away from
> home & can't actually verify it); interestingly, it appears that libata
> was added to 2.4.22 then "retired" in favor of 2.6 kernels (?), though I
> may be mis-interpreting what I'm seeing.

I'm not quite sure what you mean, here.

> Quoting "http://www.linuxmafia.com/faq/Hardware/sata.html" again --
>    "... libata is highly desirable since it supports many additional
>    chipsets, and gives a ~10M/s speed boost to others.) "

That's a performance ceiling.  Actual system performance is still going
to be limited by physical disk access, which is just plain nowhere near
that fast.

> I can see that the hdparm test may not have been a definitive test, but
> it _looks_ (to the casual eye) as if a speed-test might show faster
> access on a SATA drive if SATA support is enabled.  <shrug>

Well, I look forward with interest to your test results.   There may be
some aspect of this I'm not yet aware of.  But there's a long history in
ATA of confusing bus-speed ceilings with actual performance, in
situations where the bottleneck was plainly and dramatically elsewhere.

> I'm FAR from the cutting edge of knowlege, sadly, and while I was
> suspicious of the "hdparm" (as a reliable "metric"), it doesn't really
> seem as if this was really "rubbish" (as an off-the-cuff test).

Please note that I didn't say your hdparm results (which I've not seen)
are rubbish.  I said that the notion that running an ATA chipset 
in SATA rather than PATA mode automatically makes it faster (when
performance would be obviously bottlenecked by physical drive access) is
rubbish.  What accounts for your test results (whatever they are) is an
entirely different discussion, which we have not had.

> > Anyhow, if you want to find what communications mode your ATA chain(s)
> > is (are) set to use, look in the BIOS Setup screens.
> 
> That says how the HW is set; is there no linux command-line way to check
> what the kernel is doing?

1.  One reason I didn't address that question is that I don't offhand
know the answer.

2.  That notwithstanding, since what you said you wanted to find out is
whether the HD is being talked to in SATA mode, a sufficient answer is
to look at the BIOS.

If the BIOS says the HD is being talked to in SATA mode, then by
implication that's what the kernel must be doing, since there's no other
way to talk to the HD.  OK?

> Actually, I'm *willing* to have it run faster; but honestly, I don't need
> insane speed.

Well, that's good, since you won't get that with ATA, in the first
place.  ;->

> What I really want is a nice stable system, & so I don't
> like to run in a dodgy "PATA compatible" mode that may hang/freeze my
> kernel at some indeterminate future point... 

Er, you seem to have that backwards:  Running the chipset in PATA mode
makes it radically _less_ likely to encounter freezes -- because you
would not need leading-edge driver support.

> It's rather looking as if I'm gonna want to compile me a
> libata-enabled kernel.   :-P

Er... huh?

1.  Nothing _wrong_ with compiling a kernel containing the libata driver
set, if that's what you want to do.  But:

2.  You said your system's working OK.  So, what problem are you trying
to fix?

3.  If you decide for some reason that you want a kernel containing the
libata drivers, you still don't need to compile it yourself if you don't
feel like it.  You could, for example, retrieve a precompiled 2.6.x
kernel image from the Debian mirrors, instead.  

But I honestly don't understand why you aren't just "declaring victory
and going home", as the old saying goes.

> I was actually thinking I'd try the Nike Method (just do it) for this; a
> foray into "man -k" seems to point me at "wvdial" (a new command to me),
> though I'd be glad enough for a pointer to anything "easier".

Um, well, just setting the /dev/modem symlink to the correct port and
getting an "OK' result when you type "ATE1" in minicom should be a
sufficient winmodem-or-not test.  But I personally lack the patience to
futz around with internal modems any more for reasons amply explained at
the aforementioned link, so you're on your own, there.

> But, while "winmodems" are admittedly non-real, IMHO "external,
> serial-port" modems are also a bit... well, non-real (reminiscent of
> the archaic hobbyist phase of the industry (think "Wargames")).  YMMV.

Yep.  All God's chillun' got opinions.  (Vide Web page.)

> I've got financial constraints, too.

As I said, decide what your time's worth.  Good luck.

-- 
Cheers,     Founding member of the Hyphenation Society, a grassroots-based, 
Rick Moen   not-for-profit, locally-owned-and-operated, cooperatively-managed,
rick@linuxmafia.com     modern-American-English-usage-improvement association.