Re: [Bugme-new] [Bug 7495] New: Kernel periodically hangs.

[Patrick McFarland <diablod3@gmail.com>]

On Sunday 12 November 2006 10:21, Adrian Bunk wrote:
> On Sun, Nov 12, 2006 at 03:16:38PM +0100, Arjan van de Ven wrote:
> > > > We KNOW it can't work on a sizable amount of machines.  This is why
> > > > it is a config option; you can enable it if YOUR machine is KNOWN to
> > > > work, and you get some gains. But it's also understood that it often
> > > > it won't work. So any sensible distro (since they have to aim for a
> > > > wide audience) disables this option ...
> > >
> > > Nowadays, many distributions only ship CONFIG_SMP=y kernels...
> >
> > that's a calculated risk on their side (and they know that); they're
> > balancing not functioning on a set of machines off against needing more
> > kernels.
>
> This might soon affect the majority of Linux users, so it's a case that
> has to be handled...

I actually agree here. Linux needs to be easier for people to use, not harder. 
Isn't there a way for bootloaders or the kernel early on figure out if the 
machine supports SMP, and if it doesnt, load a uniproc kernel instead?

> > > You miss my point.
> > >
> > > You said you'd suspect it to be turned off automatic most of the time,
> > > and that's the point I think you might be wrong at.
> >
> > it won't be turned off on machines that support dual core processors
> > etc, since those DO get validated and designed for APIC use.. even if
> > you only stick a single core processor in. So yes you're right, that
> > nowadays is a pretty large group. But it's the safe group I guess:)
>
> But if APIC is even used on my more than 1 year old 40 Euro Socket A
> board (AFAIK there have never been dual core Socket A processors, there
> were no Socket A hyperthreading CPUs, it's not an SMP board, and the
> VIA KT600 is not an SMP chipset) it's not in what you call "safe group",
> and I don't see any reason why my board should behave different in this
> respect from all of the millions of other UP Socket A boards.
>
> Googling show that it could be that your claim "APIC on true UP (no
> Hyperthreading/Dualcore) is a thing no hardware vendor tests (Microsoft
> doesn't use it)" earlier in this thread was wrong. Looking at e.g. [1],
> it seems Windows does use the APIC even on UP.

Socket A CPUs are also ungodly common. They're as common as slot 1/socket 370 
Pentium 3s, and, at least with my old P3 board, trying to use APIC on UP 
caused lockups. My Duron 1ghz laptop also does the same thing. (Booting 
either with noapic fixes it).

So yeah, if distros make stupid choices like these, then we're pretty screwed.

> cu
> Adrian
>
> [1] http://www.microsoft.com/whdc/system/sysperf/IO-APIC.mspx

-- 
Patrick McFarland || http://AdTerrasPerAspera.com
"Computer games don't affect kids; I mean if Pac-Man affected us as kids,
we'd all be running around in darkened rooms, munching magic pills and
listening to repetitive electronic music." -- Kristian Wilson, Nintendo,
Inc, 1989