[svlug] the continuing saga of the supercheap eMachines box;-)

[Rick Moen]

Quoting Alex Martelli (aleaxit at gmail.com):

> Well, I may be unlucky in some respects but lucky in others -- for
> example, the _universal_ outcry from people at the installfest
> regarding all sort of kernelpanics (and other issues of whatsoever
> kind) at install &c was "disable ACPI!"... 

Reminds me:  Here's a set of boot parameters that were required to get
RHEL4 to boot on a new box I'd recently been working on (can't recall which;
could have been one of the new HP or IBM workstations):  "linux acpi=off
apm=off noprobe hda=noprobe sda=noprobe aic79xx=off aic79xx=noprobe".  
Probably not all those were absolutely required (or necessarily even
valid); this was one of those "try something; stop when you've achieved
rough success" sorts of things.  The essence of it seems to have been:
By default, the installer kernel autoprobing the aic79xx driver for 
the (unused) SCSI chipset prevented the (crucial) SATA driver from
working.  Ergo, that set of boot options was a grope in the dark to
force _no_ SCSI autoprobe.  Bizarre, eh?

(I think I threw noapic and nolapic in there, too, at first.)

Anyway, it's very common for the kernel's valiant effort at supporting
the ACPI spec (a classic example of second-system effect, if I ever saw
one) to trip up a Linux machine, and disabling ACPI _is_ a common
(if somewhat generic) debugging suggestion, for that reason.

> ...it seems that (just about systematically and everywhere), having
> APIC on (as opposed to ACPI!-), on a machine with AMD64 and an API
> chipset, means that the time-of-day clock runs about twice as fast as
> the real-world time (disably APIC is apparently the one and only way
> to fix that)...

Hmm, I'll have to check that on some local Opteron boxes.  The ones I
run tend to be nailed to NTP, so I might not notice.  ;->

> ...given how widespread cheap AMD64 machines with AMD chipsets are,
> and the fact that the issue is repeatedly mentioned on mailing lists
> etc over the last 3 years or so, it doesn't seem "extremely unlucky"
> to run smack into it.

If memory serves (and I do believe it does), my remark about "extremely
unlucky" referred specifically to your not being able to boot a default
Debian-testing 2.4.x kernel with your motherboard's USB chipset enabled
-- not to this newly-disclosed problem with kernel support for your
Advanced Programmable Interrupt Controller (APIC) chip.

I have no objection to your changing the subject, but please don't
suggest you're answering me when you do.  ;->

> But I can boot Knoppix and just about every other distro I've tried
> (if it gets to booting at all as opposed to kernelpanic, like Ubuntu
> 6.06 when ACPI is enabled) _without_ running into the problem of
> interest, so those logs aren't exactly the ones I'd like to see
> (except perhaps in order to compare them with the logs from the
> failing boots, i.e. those from Debian).

Yes, plainly you're going to want to boot singleuser, actually.

> Yep -- it hangs forever after the "hardware:" (unless I disable the
> onchip USB in which case it proceeds just fine).

OK, but I'm still scratching my head over the previously-cited "serial
console" suggestion.  (Whiskey Tango Foxtrot?)

> OK, if I can determine the specific module that's having problems (or
> maybe I could focus on 'discover', as Tim Utschig suggests, and
> finding some kludge to reorder things, if module ordering does turn
> out to be the issue).

Basically, "focussing on discover" _amounts to_ determining the specific
module (or module load order) that's having problems.  "discover" (like
"kudzu", common on RH-like systems) attempts to manage probing and
loading of modules for hardware; leave it enabled if you like that
effect, disable it if you want to take charge of module selection on
your own.