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

[Alex Martelli]

On 7/17/06, Rick Moen <rick at linuxmafia.com> wrote:
   ...
> > Yeah, that's what I'll try as the last resort if the need/urge to use
> > USB keyboard and mouse becomes a big deal -- "compile a tweaked
> > kernel" is apparently still the Linux panacea in much the same way as
> > "reboot the box" is for Windows or "fix privileges" for MacOSX (of
> > course, kernel compilation is so much faster today that it lacks the
> > charismatic, sin-purging virtues it used to have a dozen years ago,
> > but still...:-).
>
> Honestly, I think you were extremely unlucky.  I've gotten so spoiled by
> modular vendor kernels that I seldom bother to compile my own, and
> haven't had to do so to work around hardware-related hangs in many, many
> years.

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!"... but, for my box, that
doesn't seem to be a problem (except for the Ubuntu 6.06 kernel, which
DOES kernelpanic with ACPI on but not with its off -- all the many
other kernels I've tried, including etch's, appear to have no problem
with ACPI on my box, happily sailing past it).  And of course it's not
JUST _hangs_ -- e.g., 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)... 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.


> > But, not before checking exactly what's going on at
> > that "Detecting hardware" step... one thing that would be useful for
> > the purpose: how do I save the dmesg from boot-time when I know the
> > boot process is going to hang midway through, so I can later stare at
> > every detail at leisure?
>
> Er, well, if you either boot single-user or from a maintenance disk
> (e.g., Knoppix), everything up to the switch to multiuser should still
> be in the console log, retrievable using dmesg.

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


> > The only suggestion about that that came at the installfest was to
> > boot from a "serial console"
>
> Huh?  {scratches head}  Maybe I'm missing something, here.
>
> When you say "the Detecting hardware step, you mean this, right?  (Note

[snipped most of the kernel messages, as I don't have the box at hand
now to reliably compare them anyway]

> Detecting hardware: e1000 ipr usb_ohci ehci_hcd            <=== HERE

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

> I'm guessing that message is generated right around
> /etc/rcS.d/S20modutils , in the Debian startup sequence.  (You might
> want to verify that, though.)

OK, thanks for the tip, I'll verify.

> However, disabling the modutils script seems more than a little drastic:
> Maybe you should put "modulename off" in /etc/module , for some suitable
> value of "modulename" whose autoloading by the booting kernel you want
> to avert (pending debugging).

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


Thanks,

Alex