Debian (Knoppix) on HP a350n

[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.

You're more familiar with Linux in general & Debian in particular; I don't
doubt your "impression" is more-accurate than mine!    ;-)


>> 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.

I presume you're unclear about my mention of libata going into 2.4.22
then coming out again (being away from home & unable to consult my box
seems clear (to me))...

I just mean that
(1)
I had found quite a few references to libata being in a 2.4.22 path, e.g...
   /lib/modules/2.4.22-1.2140.nptlBOOT/kernel/drivers/scsi/libata.o
& similar showing up in lots of Google-hits;
(2)
I hadn't seen (?m)any such with libata in a 2.4.24 path; and
(3)
I had found some comments from MarcelloT &/or JeffG to the effect of
having "thought better of" making libata part of 2.4.x & those wanting
it "should" move to 2.6.

I had concluded, perhaps wrongly, that it was inserted into the "main"
2.4 tree with 2.4.22 & removed again upon reflection.  It's (more than)
possible that I was just reading too quickly/shallowly & drawing
unwarranted conclusions.


>> 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.

If it's a theoretcial boost to the ceiling, IMHO, that should be made
explicit:  as I read "...gives a ~10M/s speed boost..." I'd expect to
see that as a real performance-increase on the desktop (if I were a
streaming-video-geek, FrEx, I'd be salivating).


>> 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 hardly a benchmarking expert; if you'd like to suggest a test or
suite (reasonably-easy-to-run), and a pointer to a baseline (to which
my numbers can be compared), I'd be pleased to run the tests & contribute
my numbers.


>> 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.

<nod>   But, as noted above, the doc's *appear* (IMHO) to say otherwise;
that in fact SATA mode can (potentially) give a 10M/s speed-boost.  I
(now) know this is a "theoretical" boost, but that's not how I had read
the doc.


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

<g>  The box has had a total of about 3h of uptime since I got Debian
installed; "working OK" is IMHO a premature conclusion.  I'd like to
find a few tests to apply and/or have a plan in case I find the thing
going panic/freeze on me...


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

Paranoia.
;)


>> 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.

Personally, I like to actually get online with my modems...
;^)

(I'll try the "simple" test if I can't get online).


- Steve S.