I just bought a Dell Inspiron 8100. <long story of what happened snipped>.
So after a few dozen kernel builds I've narrowed it down to this: When I
build the 2.4.13 kernel with Local APIC support (CONFIG_X86_UP_APIC=y), two
things happen (so far that i've noticed):
1) The power button stops working, as if the kernel was intercepting the
signal and ignoring it. I have to hold it for five seconds to turn off the
machine.
2) Anytime I change the plugged-in status of the AC adapter (if it wasn't
plugged in, if I plug it in; if it was plugged in, if I unplug it), the
machine locks up completely.
As the help on this option has no warnings about it being dangerous to use,
I would really like to help find out what part of it is locking up. The
only problem, is... I have no idea where to start.
One other thing: how would the kernel react to the "SpeedStep" feature of
changing the CPU speed while things are still running?
--
Stevie-O
Real programmers use COPY CON PROGRAM.EXE
> 2) Anytime I change the plugged-in status of the AC adapter (if it wasn't
> plugged in, if I plug it in; if it was plugged in, if I unplug it), the
> machine locks up completely.
Not all BIOS firmware can cope when we switch to UP-APIC. Some laptops
really don't like it one bit.
> One other thing: how would the kernel react to the "SpeedStep" feature of
> changing the CPU speed while things are still running?
Depends on the laptop. Speedstop is not documented by intel so either it
works because the APM bios did the right thing, or it doesn't work because
it didn't. The only kernel issue is delay loops. We calibrate them at boot
and assume the base clock is constant. In practice this isnt showing up as
a real problem, although we do need to switch to the ACPI timers on later
laptops
Alan Cox writes:
> > 2) Anytime I change the plugged-in status of the AC adapter (if it wasn't
> > plugged in, if I plug it in; if it was plugged in, if I unplug it), the
> > machine locks up completely.
>
> Not all BIOS firmware can cope when we switch to UP-APIC. Some laptops
> really don't like it one bit.
Correct, and the I8x00 is the prime example of that.
I have a fix, but it involves fairly major surgery:
- Implement bt_ioremap()/bt_iounmap() which work at early boot-time (the
normal ioremap doesn't work yet). This is done by adding 16 boot-time
only fixmap entries, and using those for temporary mappings. These
fixmap entries are reclaimed once vmalloc() is initialised, so they
don't steal address space permanently.
This would also help some other code which wants to scan arbitrary
physical memory at early boot-time.
- Move dmi_scan from main to the i386 setup_arch(). To permit this, ioremap()
is changed to bt_ioremap(), and vmalloc() to alloc_bootmem().
- Add a blacklist entry in dmi_scan, which sets a "don't enable local APIC"
flag if the I8000 or any problematic machine is found.
- Move init_apic_mappings() from setup_arch() to trap_init(). This is
so that kernel command-line parameters can be used to override stuff.
- Change detect_init_apic() to refuse to enable the local APIC if the
blacklist flag is set.
The patch is still _very_ rough, but it seems to work. Let me know if you want it.
/Mikael
I wrote:
> > Not all BIOS firmware can cope when we switch to UP-APIC. Some laptops
> > really don't like it one bit.
>
>Correct, and the I8x00 is the prime example of that.
>
>I have a fix, but it involves fairly major surgery:
>- Implement bt_ioremap()/bt_iounmap() which work at early boot-time (the
> normal ioremap doesn't work yet).
>...
>The patch is still _very_ rough, but it seems to work. Let me know if you want it.
The patch is now available at
http://www.csd.uu.se/~mikpe/linux/patch-2.4.13ac5-init-order-5
/Mikael
On Wed, Oct 31, 2001 at 09:11:38PM +0100, Mikael Pettersson wrote:
> I wrote:
> > > Not all BIOS firmware can cope when we switch to UP-APIC. Some laptops
> > > really don't like it one bit.
> >
> >Correct, and the I8x00 is the prime example of that.
> >
> >I have a fix, but it involves fairly major surgery:
> >- Implement bt_ioremap()/bt_iounmap() which work at early boot-time (the
> > normal ioremap doesn't work yet).
> >...
> >The patch is still _very_ rough, but it seems to work. Let me know if you want it.
>
> The patch is now available at
> http://www.csd.uu.se/~mikpe/linux/patch-2.4.13ac5-init-order-5
The same problem appears on "Dell Latitude C810". So that should probably be
added to the dmi-backlist too.
--
//anders/g
On Wed, 31 Oct 2001 22:42:01 +0100, [email protected] wrote:
> > > > Not all BIOS firmware can cope when we switch to UP-APIC. Some laptops
> > > > really don't like it one bit.
> > >
> > >Correct, and the I8x00 is the prime example of that.
> > >
> > >I have a fix, but it involves fairly major surgery:
> > >- Implement bt_ioremap()/bt_iounmap() which work at early boot-time (the
> > > normal ioremap doesn't work yet).
> > >...
> > >The patch is still _very_ rough, but it seems to work. Let me know if you want it.
> >
> > The patch is now available at
> > http://www.csd.uu.se/~mikpe/linux/patch-2.4.13ac5-init-order-5
>
> The same problem appears on "Dell Latitude C810". So that should probably be
> added to the dmi-backlist too.
You have confirmed that allowing the local APIC to be enabled
causes it to lock up at system management events, and that keeping
the local APIC disabled prevents those lockups?
Send me the DMI scan output (change the dmi_printk #define in dmi_scan.c
to actually do a printk) and I'll add the C810 to the blacklist.
/Mikael
On Wed, Oct 31, 2001 at 11:17:16PM +0100, Mikael Pettersson wrote:
> > > The patch is now available at
> > > http://www.csd.uu.se/~mikpe/linux/patch-2.4.13ac5-init-order-5
> >
> > The same problem appears on "Dell Latitude C810". So that should probably be
> > added to the dmi-backlist too.
>
> You have confirmed that allowing the local APIC to be enabled
> causes it to lock up at system management events, and that keeping
> the local APIC disabled prevents those lockups?
>
> Send me the DMI scan output (change the dmi_printk #define in dmi_scan.c
> to actually do a printk) and I'll add the C810 to the blacklist.
I havn't tested your patch, but with CONFIG_X86_UP_APIC=y it locks up and
without it it doesn't. It isn't my laptop so can't do any futher
investigations at the moment, but the owner was very happy that he now could
plug the power without the computer locking up so probably he'll let me do
some more tests on it tomorrow.
--
//anders/g
At 10:44 AM 10/31/2001 +0000, Alan Cox wrote:
> > One other thing: how would the kernel react to the "SpeedStep" feature of
> > changing the CPU speed while things are still running?
>
>Depends on the laptop. Speedstop is not documented by intel so either it
>works because the APM bios did the right thing, or it doesn't work because
>it didn't. The only kernel issue is delay loops. We calibrate them at boot
>and assume the base clock is constant. In practice this isnt showing up as
>a real problem, although we do need to switch to the ACPI timers on later
>laptops
Yeah, that's what I'm concerned with -- the delay loops. I don't know what
they're used for, so I don't know what the CPU speed change would affect.
Mine would switch between 1.0GHz (996MHz according to /proc/cpuinfo) and
733MHz (730MHz). That's a difference of 36% - a timer calibrated to wait 1s
at 733MHz would only wait for 0.733s at 1GHz, and .3s can be quite
important in the computing world.
And, of course, since the BIOS can't handle APCI, using an APCI timer
wouldn't help much, would it?
--
Stevie-O
Real programmers use dd if=/dev/mouse of=a.out and move their mice around.