Re: Local APIC option (CONFIG_X86_UP_APIC) locks up Inspiron 8100

Re: Local APIC option (CONFIG_X86_UP_APIC) locks up Inspiron 8100

[Mikael Pettersson]

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

Re: Local APIC option (CONFIG_X86_UP_APIC) locks up Inspiron 8100

[andersg]

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

Re: Local APIC option (CONFIG_X86_UP_APIC) locks up Inspiron 8100

[Stevie O]

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.

Re: Local APIC option (CONFIG_X86_UP_APIC) locks up Inspiron 8100

[andersg]

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

Re: Local APIC option (CONFIG_X86_UP_APIC) locks up Inspiron 8100

[Mikael Pettersson]

On Wed, 31 Oct 2001 22:42:01 +0100, andersg@0x63.nu 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

Re: Local APIC option (CONFIG_X86_UP_APIC) locks up Inspiron 8100

[Mikael Pettersson]

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

Re: Local APIC option (CONFIG_X86_UP_APIC) locks up Inspiron 8100

[Alan Cox]

> 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

Local APIC option (CONFIG_X86_UP_APIC) locks up Inspiron 8100

[Stevie O]

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