Re: 2.6.25-rc5-mm1

Re: 2.6.25-rc5-mm1

[Dave Young]

Hi, I got the following lockdep warning:
(add linux-acpi to cc)

[    0.097109] ACPI: Core revision 20070126
[    0.097282] INFO: trying to register non-static key.
[    0.097355] the code is fine but needs lockdep annotation.
[    0.097428] turning off the locking correctness validator.
[    0.097503] Pid: 0, comm: swapper Not tainted 2.6.25-rc5-mm1 #3
[    0.097578]  [<c0127bf8>] ? printk+0x18/0x20
[    0.097716]  [<c014b01c>] __lock_acquire+0x40c/0x760
[    0.097822]  [<c0181ba0>] ? alloc_debug_processing+0xb0/0x140
[    0.097959]  [<c014b969>] lock_acquire+0x79/0xb0
[    0.098063]  [<c0140204>] ? down_trylock+0x14/0x40
[    0.098197]  [<c03df9e8>] _spin_lock_irqsave+0x48/0xa0
[    0.098303]  [<c0140204>] ? down_trylock+0x14/0x40
[    0.098436]  [<c0140204>] down_trylock+0x14/0x40
[    0.098540]  [<c027c7ea>] acpi_os_wait_semaphore+0x3e/0xb9
[    0.098647]  [<c029263e>] acpi_ut_acquire_mutex+0x34/0x72
[    0.098753]  [<c0289ab1>] acpi_ns_root_initialize+0x19/0x250
[    0.098859]  [<c05453e6>] acpi_initialize_subsystem+0x42/0x64
[    0.098966]  [<c0545725>] acpi_early_init+0x50/0xef
[    0.099070]  [<c052b7f6>] start_kernel+0x1e6/0x250
[    0.099175]  [<c052b1a0>] ? unknown_bootoption+0x0/0x130
[    0.099310]  [<c052b008>] __init_begin+0x8/0x10
[    0.099414]  =======================

Re: [2.6.25-rc5-mm1] WARNING: at drivers/base/sys.c:173

[Dave Jones]

On Thu, Mar 13, 2008 at 11:34:39AM -0700, Greg KH wrote:
 > On Thu, Mar 13, 2008 at 01:15:52AM +0100, Tilman Schmidt wrote:
 > > Am 11.03.2008 09:14 schrieb Andrew Morton:
 > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc5/2.6.25-rc5-mm1/
 > > 
 > > Late during boot, this issues the following warning on my Pentium D,
 > > apparently when trying to load an appropriate CPU frequency driver:
 > > 
 > > [   56.759128] ------------[ cut here ]------------
 > > [   56.765058] WARNING: at drivers/base/sys.c:173 sysdev_driver_register+0x34/0xce()
 > > [   56.776027] Modules linked in: acpi_cpufreq(+) speedstep_lib ip6table_filter ip6_tables x_tables ipv6 microcode firmware_class loop osst st sr_mod cdrom pata_acpi bas_gigaset snd_hda_intel gigaset isdn snd_pcm ata_generic<6>ip_tables: (C) 2000-2006 Netfilter Core Team
 > > [   56.785293]  snd_timer aic7xxx slhc snd ohci1394 rtc_cmos ieee1394 shpchp crc_ccitt iTCO_wdt e1000e rtc_core iTCO_vendor_support soundcore scsi_transport_spi watchdog_core pci_hotplug intel_agp button thermal agpgart rtc_lib processor i2c_i801 watchdog_dev parport_pc i2c_core snd_page_alloc parport pata_marvell sg ext3 jbd mbcache linear sd_mod usbhid hid ff_memless ahci libata scsi_mod ehci_hcd uhci_hcd usbcore dm_snapshot dm_mod
 > > [   56.805358] Pid: 2856, comm: modprobe Not tainted 2.6.25-rc5-mm1-testing #1
 > > [   56.810766]  [<c01272e9>] warn_on_slowpath+0x41/0x6d
 > > [   56.820628]  [<c0230065>] ? acpi_ns_lookup+0x2b5/0x497
 > > [   56.830455]  [<c0230e25>] ? acpi_evaluate_object+0x23e/0x249
 > > [   56.840414]  [<c02ff809>] ? mutex_unlock+0x8/0xa
 > > [   56.848380]  [<fa9fec1d>] ? acpi_processor_preregister_performance+0x4e6/0x4f1 [processor]
 > > [   56.858297]  [<c0286438>] ? cpufreq_register_driver+0x42/0xfc
 > > [   56.868263]  [<c026423d>] sysdev_driver_register+0x34/0xce
 > > [   56.877974]  [<c0286476>] cpufreq_register_driver+0x80/0xfc
 > > [   56.887327]  [<facde034>] acpi_cpufreq_init+0x34/0x3a [acpi_cpufreq]
 > > [   56.897290]  [<c014ad7a>] sys_init_module+0x1816/0x1943
 > > [   56.907304]  [<facb5000>] ? icmp_checkentry+0x0/0x14 [ip_tables]
 > > [   56.917255]  [<c0183cd2>] ? sys_read+0x3b/0x60
 > > [   56.925094]  [<c0106aec>] sysenter_past_esp+0x6d/0xc5
 > > [   56.935071]  =======================
 > > [   56.945016] ---[ end trace 9ade9adb26b6da0a ]---
 > > 
 > > Looking back, -rc3-mm1 did that too.
 > > Mainline (-rc3 through -rc5) never did.
 > > Let me know if you need more information.
 > > CCing Dave Jones for cpufreq and Greg KH for sysdev.
 > 
 > This implys that a cpufreq module is getting registered twice in the
 > sysdev code :(

I'm wondering if the processor driver has registered something
that acpi_cpufreq is also trying to do.  Cc'ing linux-acpi

	Dave

-- 
http://www.codemonkey.org.uk

Re: [2.6.25-rc5-mm1] WARNING: at drivers/base/sys.c:173

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 2523 bytes --]

Am 13.03.2008 20:56 schrieb Dave Jones:

>  > [   56.759128] ------------[ cut here ]------------
>  > [   56.765058] WARNING: at drivers/base/sys.c:173 sysdev_driver_register+0x34/0xce()
>  > [   56.776027] Modules linked in: acpi_cpufreq(+) speedstep_lib ip6table_filter ip6_tables x_tables ipv6 microcode firmware_class loop osst st sr_mod cdrom pata_acpi bas_gigaset snd_hda_intel gigaset isdn snd_pcm ata_generic<6>ip_tables: (C) 2000-2006 Netfilter Core Team
>  > [   56.785293]  snd_timer aic7xxx slhc snd ohci1394 rtc_cmos ieee1394 shpchp crc_ccitt iTCO_wdt e1000e rtc_core iTCO_vendor_support soundcore scsi_transport_spi watchdog_core pci_hotplug intel_agp button thermal agpgart rtc_lib processor i2c_i801 watchdog_dev parport_pc i2c_core snd_page_alloc parport pata_marvell sg ext3 jbd mbcache linear sd_mod usbhid hid ff_memless ahci libata scsi_mod ehci_hcd uhci_hcd usbcore dm_snapshot dm_mod
>  > [   56.805358] Pid: 2856, comm: modprobe Not tainted 2.6.25-rc5-mm1-testing #1
>  > [   56.810766]  [<c01272e9>] warn_on_slowpath+0x41/0x6d
>  > [   56.820628]  [<c0230065>] ? acpi_ns_lookup+0x2b5/0x497
>  > [   56.830455]  [<c0230e25>] ? acpi_evaluate_object+0x23e/0x249
>  > [   56.840414]  [<c02ff809>] ? mutex_unlock+0x8/0xa
>  > [   56.848380]  [<fa9fec1d>] ? acpi_processor_preregister_performance+0x4e6/0x4f1 [processor]
>  > [   56.858297]  [<c0286438>] ? cpufreq_register_driver+0x42/0xfc
>  > [   56.868263]  [<c026423d>] sysdev_driver_register+0x34/0xce
>  > [   56.877974]  [<c0286476>] cpufreq_register_driver+0x80/0xfc
>  > [   56.887327]  [<facde034>] acpi_cpufreq_init+0x34/0x3a [acpi_cpufreq]
>  > [   56.897290]  [<c014ad7a>] sys_init_module+0x1816/0x1943
>  > [   56.907304]  [<facb5000>] ? icmp_checkentry+0x0/0x14 [ip_tables]
>  > [   56.917255]  [<c0183cd2>] ? sys_read+0x3b/0x60
>  > [   56.925094]  [<c0106aec>] sysenter_past_esp+0x6d/0xc5
>  > [   56.935071]  =======================
>  > [   56.945016] ---[ end trace 9ade9adb26b6da0a ]---

> Full dmesg please, with CPU_FREQ_DEBUG=y, and boot with cpufreq.debug=7

You can find it at
http://gollum.phnxsoft.com/~ts/linux/dmesg.out
and the corresponding .config right beside it at
http://gollum.phnxsoft.com/~ts/linux/config-2.6.25-rc5-mm1

CCing linux-acpi as you did in your other mail.

HTH
T.

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: [2.6.25-rc5-mm1] WARNING: at drivers/base/sys.c:173

[Dave Jones]

On Fri, Mar 14, 2008 at 01:01:18AM +0100, Tilman Schmidt wrote:

 > > Full dmesg please, with CPU_FREQ_DEBUG=y, and boot with cpufreq.debug=7
 > 
 > You can find it at
 > http://gollum.phnxsoft.com/~ts/linux/dmesg.out
 > and the corresponding .config right beside it at
 > http://gollum.phnxsoft.com/~ts/linux/config-2.6.25-rc5-mm1
 > 
 > CCing linux-acpi as you did in your other mail.

The interesting bits..

[   46.075145] cpufreq-core: trying to register driver centrino

here we've done sysdev_driver_register(&cpu_sysdev_class,&cpufreq_sysdev_driver);
(see cpufreq_register_driver in drivers/cpufreq/cpufreq.c)
This is the only place we register sysdev entries.

[   46.075155] cpufreq-core: adding CPU 0
[   46.075163] speedstep-centrino: found unsupported CPU with Enhanced SpeedStep: send /proc/cpuinfo to cpufreq@lists.linux.org.uk
[   46.075167] cpufreq-core: initialization failed

this ENODEVs

[   46.075173] cpufreq-core: adding CPU 1
[   46.075176] cpufreq-core: initialization failed

Same for the 2nd CPU.

[   46.075180] cpufreq-core: no CPU initialized for driver centrino

here we hit this part of cpufreq_register_driver

                /* if all ->init() calls failed, unregister */
                if (ret) {
                        dprintk("no CPU initialized for driver %s\n",
                                                        driver_data->name);
                        sysdev_driver_unregister(&cpu_sysdev_class,
                                                &cpufreq_sysdev_driver);


So we release all the refs.


[   46.075185] cpufreq-core: unregistering CPU 0
[   46.075190] cpufreq-core: unregistering CPU 1

These are the sysdev callbacks.

[   46.429147] powernow: This module only works with AMD K7 CPUs
[   47.081642] speedstep-lib: x86: f, model: 6
[   47.081649] speedstep-ich: Intel(R) SpeedStep(TM) capable processor not found

These drivers don't even get as far as calling cpufreq_register_driver,
they ENODEV way before things get that far along.

[   47.262236] acpi-cpufreq: acpi_cpufreq_init
[   47.262242] acpi-cpufreq: acpi_cpufreq_early_init
[   47.262262] cpufreq-core: trying to register driver acpi-cpufreq
[   47.262272] ------------[ cut here ]------------
[   47.267635] WARNING: at drivers/base/sys.c:173 sysdev_driver_register+0x34/0xce()

Boom.  I'm really puzzled. At this point, we shouldn't have any leaked refs
on the objects.  Needs more thinking.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [2.6.25-rc5-mm1] WARNING: at drivers/base/sys.c:173

[Zhao Yakui]

On Fri, 2008-03-14 at 01:01 +0100, Tilman Schmidt wrote:
> Am 13.03.2008 20:56 schrieb Dave Jones:
> 
> >  > [   56.759128] ------------[ cut here ]------------
> >  > [   56.765058] WARNING: at drivers/base/sys.c:173 sysdev_driver_register+0x34/0xce()
> >  > [   56.776027] Modules linked in: acpi_cpufreq(+) speedstep_lib ip6table_filter ip6_tables x_tables ipv6 microcode firmware_class loop osst st sr_mod cdrom pata_acpi bas_gigaset snd_hda_intel gigaset isdn snd_pcm ata_generic<6>ip_tables: (C) 2000-2006 Netfilter Core Team
> >  > [   56.785293]  snd_timer aic7xxx slhc snd ohci1394 rtc_cmos ieee1394 shpchp crc_ccitt iTCO_wdt e1000e rtc_core iTCO_vendor_support soundcore scsi_transport_spi watchdog_core pci_hotplug intel_agp button thermal agpgart rtc_lib processor i2c_i801 watchdog_dev parport_pc i2c_core snd_page_alloc parport pata_marvell sg ext3 jbd mbcache linear sd_mod usbhid hid ff_memless ahci libata scsi_mod ehci_hcd uhci_hcd usbcore dm_snapshot dm_mod
> >  > [   56.805358] Pid: 2856, comm: modprobe Not tainted 2.6.25-rc5-mm1-testing #1
> >  > [   56.810766]  [<c01272e9>] warn_on_slowpath+0x41/0x6d
> >  > [   56.820628]  [<c0230065>] ? acpi_ns_lookup+0x2b5/0x497
> >  > [   56.830455]  [<c0230e25>] ? acpi_evaluate_object+0x23e/0x249
> >  > [   56.840414]  [<c02ff809>] ? mutex_unlock+0x8/0xa
> >  > [   56.848380]  [<fa9fec1d>] ? acpi_processor_preregister_performance+0x4e6/0x4f1 [processor]
> >  > [   56.858297]  [<c0286438>] ? cpufreq_register_driver+0x42/0xfc
> >  > [   56.868263]  [<c026423d>] sysdev_driver_register+0x34/0xce
> >  > [   56.877974]  [<c0286476>] cpufreq_register_driver+0x80/0xfc
> >  > [   56.887327]  [<facde034>] acpi_cpufreq_init+0x34/0x3a [acpi_cpufreq]
> >  > [   56.897290]  [<c014ad7a>] sys_init_module+0x1816/0x1943
> >  > [   56.907304]  [<facb5000>] ? icmp_checkentry+0x0/0x14 [ip_tables]
> >  > [   56.917255]  [<c0183cd2>] ? sys_read+0x3b/0x60
> >  > [   56.925094]  [<c0106aec>] sysenter_past_esp+0x6d/0xc5
> >  > [   56.935071]  =======================
> >  > [   56.945016] ---[ end trace 9ade9adb26b6da0a ]---
> 
> > Full dmesg please, with CPU_FREQ_DEBUG=y, and boot with cpufreq.debug=7
> 
> You can find it at
> http://gollum.phnxsoft.com/~ts/linux/dmesg.out
> and the corresponding .config right beside it at
> http://gollum.phnxsoft.com/~ts/linux/config-2.6.25-rc5-mm1
> 
> CCing linux-acpi as you did in your other mail.

Please set CONFIG_ACPI_DEBUG and boot the system with the option of
"acpi.debug_layer=0x01010000 acpi.debug_level=0x1f".

It will be great if the acpidump output is attached.

Thanks.

> HTH
> T.
> 

Re: [2.6.25-rc5-mm1] WARNING: at drivers/base/sys.c:173

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 655 bytes --]

On Fri, 14 Mar 2008 08:57:11 +0800, Zhao Yakui wrote:
> Please set CONFIG_ACPI_DEBUG and boot the system with the option of
> "acpi.debug_layer=0x01010000 acpi.debug_level=0x1f".

CONFIG_ACPI_DEBUG is already set, but I cannot reboot the machine
right now. I'll probably get a chance for that in about 12 hours.

> It will be great if the acpidump output is attached.

Available now at
http://gollum.phnxsoft.com/~ts/linux/acpidump.out

HTH
T.

-- 
Tilman Schmidt                    E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

[Dave Hansen]

For those of you new to this thread, here's the initial report:

	http://marc.info/?t=120536629300001&r=1&w=2

I'm pretty sure the root cause of this bug is this commit:

	ACPI: basic initramfs DSDT override support
	71fc47a9adf8ee89e5c96a47222915c5485ac437

Which did this hunk:
        
        @@ -648,6 +654,7 @@ asmlinkage void __init start_kernel(void)
         
                check_bugs();
         
        +       populate_rootfs(); /* For DSDT override from initramfs
        */
                acpi_early_init(); /* before LAPIC and SMP init */
         
                /* Do the rest non-__init'ed, we're now alive */
        	rest_init();
        ...

Well, the fs initcalls aren't actually done until during rest_init(),
including initializing my mnt_writer[] spinlocks.  I guess I could
statically initialize them, but that's not the root of the problem, it's
just the canary in the coal mine.

I think the populate_rootfs() call is completely bogus and certainly
can't be done before the initcalls.  But, I don't immediately have any
better suggestions for you.  Can you delay the ACPI init until after the
fs initcalls are made?

-- Dave

Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

[Linus Torvalds]

On Fri, 14 Mar 2008, Dave Hansen wrote:
>
> For those of you new to this thread, here's the initial report:
> 
> 	http://marc.info/?t=120536629300001&r=1&w=2
> 
> I'm pretty sure the root cause of this bug is this commit:
> 
> 	ACPI: basic initramfs DSDT override support
> 	71fc47a9adf8ee89e5c96a47222915c5485ac437

Time to just revert that one? It caused some other issues too, iirc. 

Len?

		Linus

Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

[Eric Piel]

Dave Hansen wrote:
> For those of you new to this thread, here's the initial report:
> 
> 	http://marc.info/?t=120536629300001&r=1&w=2
> 
> I'm pretty sure the root cause of this bug is this commit:
> 
> 	ACPI: basic initramfs DSDT override support
> 	71fc47a9adf8ee89e5c96a47222915c5485ac437
> 
> Which did this hunk:
>         
>         @@ -648,6 +654,7 @@ asmlinkage void __init start_kernel(void)
>          
>                 check_bugs();
>          
>         +       populate_rootfs(); /* For DSDT override from initramfs
>         */
>                 acpi_early_init(); /* before LAPIC and SMP init */
>          
>                 /* Do the rest non-__init'ed, we're now alive */
>         	rest_init();
>         ...
> 
> Well, the fs initcalls aren't actually done until during rest_init(),
> including initializing my mnt_writer[] spinlocks.  I guess I could
> statically initialize them, but that's not the root of the problem, it's
> just the canary in the coal mine.
> 
> I think the populate_rootfs() call is completely bogus and certainly
> can't be done before the initcalls.  But, I don't immediately have any
> better suggestions for you.  Can you delay the ACPI init until after the
> fs initcalls are made?
Hi,

I have made a patch to fix problems with regards to early userspace 
calls (http://lkml.org/lkml/2008/2/23/306) but I don't think it will 
solve this bug. So far I had not heard of problems with filesystem 
initialization.

I'm not sure it would be possible to delay acpi_early_init() until after 
the fs initcalls. Maybe Len knows. How about trying the opposite: what 
is the barely minimum to initialize so that the rootfs can be populated 
and read? Would it be possible to have a kind of 
early_mnt_writer_initialize() that would do that?

See you,
Eric

Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

[Dave Hansen]

On Fri, 2008-03-14 at 21:51 +0100, Eric Piel wrote:
> I'm not sure it would be possible to delay acpi_early_init() until after 
> the fs initcalls. Maybe Len knows. How about trying the opposite: what 
> is the barely minimum to initialize so that the rootfs can be populated 
> and read? Would it be possible to have a kind of 
> early_mnt_writer_initialize() that would do that?

I *can* probably do it earlier, maybe even statically, but I think
you're missing the point a bit here.  We've just been super lucky so far
that populate_rootfs() doesn't depend on any other initcalls (or at
least BUG_ON() because of them).  There may be some more buglets hiding
around.

It'd be a shame to have to have "super_early_fs_initcall()" logic for
every part of the VFS or any other initcall for that matter that you
might need.  How do we tell all future VFS hackers that they have to do
this so that the next guy doesn't break it?  I certainly missed it. :)

We could separate out the initcalls and just have the fs ones run before
the rest do.  But, I'm not sure what interactions *THAT* might have.
There are arch-specific initcalls, and I have no idea if the fs init
code depends on *those*.  That's a lot of code to check.

It is nailed when you the patch says:

+       /*
+        * Never do this at home, only the user-space is allowed to open a file.
+        * The clean way would be to use the firmware loader. But this code must be run
+        * before there is any userspace available. So we need a static/init firmware
+        * infrastructure, which doesn't exist yet...
+        */

I think requiring FS access this early in the boot processes is just
broken.  It seems like the author of the patch knew a better way and
tried to get away with a hack.  I think it backfired. :)

-- Dave

Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

[Eric Piel]

Dave Hansen wrote:
> On Fri, 2008-03-14 at 21:51 +0100, Eric Piel wrote:
>> I'm not sure it would be possible to delay acpi_early_init() until after 
>> the fs initcalls. Maybe Len knows. How about trying the opposite: what 
>> is the barely minimum to initialize so that the rootfs can be populated 
>> and read? Would it be possible to have a kind of 
>> early_mnt_writer_initialize() that would do that?
> 
> I *can* probably do it earlier, maybe even statically, but I think
> you're missing the point a bit here.  We've just been super lucky so far
> that populate_rootfs() doesn't depend on any other initcalls (or at
> least BUG_ON() because of them).  There may be some more buglets hiding
> around.
Actually, each time I look at init/main.c I feel like we are super lucky 
that Linux boots ;-)

> 
> It'd be a shame to have to have "super_early_fs_initcall()" logic for
> every part of the VFS or any other initcall for that matter that you
> might need.  How do we tell all future VFS hackers that they have to do
> this so that the next guy doesn't break it?  I certainly missed it. :)
Well, my point was that actually populate_rootfs() does _very_ little 
with regard to FS manipulation, acpi_find_dsdt_initrd() even less. The 
task of checking that everything needed is available beforehand is 
certainly not the same magnitude as the one of the Danaides as you 
seemed to implied ;-)

The fact is, this patch has been tested a lot, because it's been used by 
several distributions for a long time. I expect that the only potential 
problems are corner cases that are possible to work around.

> 
> We could separate out the initcalls and just have the fs ones run before
> the rest do.  But, I'm not sure what interactions *THAT* might have.
> There are arch-specific initcalls, and I have no idea if the fs init
> code depends on *those*.  That's a lot of code to check.
Yes, we agree on this. That would be crazy :-)

> 
> It is nailed when you the patch says:
> 
> +       /*
> +        * Never do this at home, only the user-space is allowed to open a file.
> +        * The clean way would be to use the firmware loader. But this code must be run
> +        * before there is any userspace available. So we need a static/init firmware
> +        * infrastructure, which doesn't exist yet...
> +        */
> 
> I think requiring FS access this early in the boot processes is just
> broken.  It seems like the author of the patch knew a better way and
> tried to get away with a hack.  I think it backfired. :)
I'm actually the author of this comment... The static/init firmware 
infrastructure that I mentioned was more just about a way to hide the fs 
access in a special part of the kernel, not avoiding it. We used to have 
a different way but it was even uglier: append the DSDT after the 
initramfs, and then access it _directly_. This implies teaching 
populate_rootfs() to not panic when seeing DSDTs and loosing the benefit 
of the compression.

That said, I'm really not against any complete different approach. All 
that is needed is being able to read a file early at boot (the DSDT) 
without having to recompile the kernel each time the file is modified. 
For instance someone had once mentioned modifying the in-kernel DSDT by 
unlinking and relinking the bzimage. If one can show me how to do that 
I'd be happy to implement it...

Eric

Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

[Dave Hansen]

On Fri, 2008-03-14 at 23:50 +0100, Eric Piel wrote:
> > It'd be a shame to have to have "super_early_fs_initcall()" logic for
> > every part of the VFS or any other initcall for that matter that you
> > might need.  How do we tell all future VFS hackers that they have to do
> > this so that the next guy doesn't break it?  I certainly missed it. :)
> Well, my point was that actually populate_rootfs() does _very_ little 
> with regard to FS manipulation, acpi_find_dsdt_initrd() even less. The 
> task of checking that everything needed is available beforehand is 
> certainly not the same magnitude as the one of the Danaides as you 
> seemed to implied ;-)

The problem is defining how much "very little" is, and making sure that
all the other kernel developers agree with you on it.

Anyway, I'm sick of too much bitching and too little coding.  Andrew,
here's a patch for -mm that will at least shut up the spinlock warnings.
Al, you'll also need something similar to this for when you get Linus to
pull your git tree that has the r/o bind mount patches. 
It's a hack, but I don't know any better way to do it until the ACPI
mess gets cleaned up.

Arjan, is there a way to statically set lockdep classes for a spinlock
that I'm missing?

I'll leave it to everyone else to describe the evils of calling into
*any* fs code before the fs initcalls have been made. 

-- Dave


I'm not happy with this patch, but I don't see an easier way
to do it.  We can't statically initialize the lockdep classes
as far as I can see.

---

 linux-2.6.git-dave/fs/namespace.c        |    3 +--
 linux-2.6.git-dave/include/linux/mount.h |    1 +
 linux-2.6.git-dave/init/main.c           |    8 ++++++++
 3 files changed, 10 insertions(+), 2 deletions(-)

diff -puN fs/namei.c~robind-statically-initialize-locks fs/namei.c
diff -puN fs/namespace.c~robind-statically-initialize-locks fs/namespace.c
--- linux-2.6.git/fs/namespace.c~robind-statically-initialize-locks	2008-03-14 16:12:44.000000000 -0700
+++ linux-2.6.git-dave/fs/namespace.c	2008-03-14 16:16:43.000000000 -0700
@@ -158,7 +158,7 @@ struct mnt_writer {
 } ____cacheline_aligned_in_smp;
 static DEFINE_PER_CPU(struct mnt_writer, mnt_writers);
 
-static int __init init_mnt_writers(void)
+int __init init_mnt_writers(void)
 {
 	int cpu;
 	for_each_possible_cpu(cpu) {
@@ -169,7 +169,6 @@ static int __init init_mnt_writers(void)
 	}
 	return 0;
 }
-fs_initcall(init_mnt_writers);
 
 static void unlock_mnt_writers(void)
 {
diff -puN init/main.c~robind-statically-initialize-locks init/main.c
--- linux-2.6.git/init/main.c~robind-statically-initialize-locks	2008-03-14 16:13:02.000000000 -0700
+++ linux-2.6.git-dave/init/main.c	2008-03-14 16:17:33.000000000 -0700
@@ -58,6 +58,7 @@
 #include <linux/kthread.h>
 #include <linux/sched.h>
 #include <linux/signal.h>
+#include <linux/mount.h>
 
 #include <asm/io.h>
 #include <asm/bugs.h>
@@ -650,6 +651,13 @@ asmlinkage void __init start_kernel(void
 
 	check_bugs();
 
+	/*
+	 * This is a horrible hack.  The ACPI code needs
+	 * to learn how to do "DSDT override" without fs
+	 * access or do it later in boot - Dave Hansen
+	 */
+	init_mnt_writers();
+
 	populate_rootfs(); /* For DSDT override from initramfs */
 	acpi_early_init(); /* before LAPIC and SMP init */
 
diff -puN include/linux/mount.h~robind-statically-initialize-locks include/linux/mount.h
--- linux-2.6.git/include/linux/mount.h~robind-statically-initialize-locks	2008-03-14 16:16:04.000000000 -0700
+++ linux-2.6.git-dave/include/linux/mount.h	2008-03-14 16:16:34.000000000 -0700
@@ -79,6 +79,7 @@ static inline struct vfsmount *mntget(st
 	return mnt;
 }
 
+extern int init_mnt_writers(void);
 extern int mnt_want_write(struct vfsmount *mnt);
 extern void mnt_drop_write(struct vfsmount *mnt);
 extern void mntput_no_expire(struct vfsmount *mnt);
_

Re: [2.6.25-rc5-mm1] WARNING: at drivers/base/sys.c:173

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]

Am 14.03.2008 01:57 schrieb Zhao Yakui:
> 
> Please set CONFIG_ACPI_DEBUG and boot the system with the option of
> "acpi.debug_layer=0x01010000 acpi.debug_level=0x1f".
> 
> It will be great if the acpidump output is attached.

Ok, that took a bit longer than I hoped, but the result is now
finally available at:

http://gollum.phnxsoft.com/~ts/linux/dmesg-acpidebug.out

Note that I doctored this a bit: the dmesg buffer had already
overflowed by the time I ran the dmesg command, so I manually
prepended the missing part from the file /var/log/boot.msg into
which SUSE saves the early kernel messages. The border between
the two is marked off by the string "~~~~~~~~splice~~~~~~~~",
and I left a line of overlap to make it very clear.

The output of acpidump is unchanged wrt what I already posted.
(Unsurprisingly, but nevertheless I checked. Call me paranoid. ;-)

HTH
T.

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 2778 bytes --]

Am 15.03.2008 00:29 schrieb Dave Hansen:
> Anyway, I'm sick of too much bitching and too little coding.  Andrew,
> here's a patch for -mm that will at least shut up the spinlock warnings.

Sorry to say, it doesn't. That is, it does shut up the warning I
reported, but there's a new one appearing now instead, three lines
later. Here's the dmesg diff:

@@ -216,29 +216,30 @@
 CPU0: Thermal monitoring enabled
 Compat vDSO mapped to ffffe000.
 Checking 'hlt' instruction... OK.
-BUG: spinlock bad magic on CPU#0, swapper/0
- lock: c2c19380, .magic: 00000000, .owner: swapper/0, .owner_cpu: 0
-Pid: 0, comm: swapper Not tainted 2.6.25-rc5-mm1-testing #2
- [<c01f728c>] spin_bug+0x7c/0x87
- [<c01f72b0>] _raw_spin_unlock+0x19/0x71
- [<c0301922>] _spin_unlock+0x1d/0x3c
- [<c01981aa>] mnt_want_write+0x62/0x88
- [<c018c382>] sys_mkdirat+0x86/0xd6
- [<c04260ab>] ? clean_path+0x16/0x4a
- [<c017fd6f>] ? kfree+0xd8/0xec
- [<c018c3e2>] sys_mkdir+0x10/0x12
- [<c0426353>] do_name+0x112/0x1b3
- [<c042558b>] write_buffer+0x1d/0x2c
- [<c04255fe>] flush_window+0x64/0xb3
- [<c04272f5>] unpack_to_rootfs+0x62c/0x8b9
- [<c04275a2>] populate_rootfs+0x20/0x109
- [<c0429ed2>] ? alternative_instructions+0x153/0x158
- [<c04248f5>] start_kernel+0x343/0x355
- [<c0424019>] i386_start_kernel+0x8/0xa
- =======================
 Unpacking initramfs... done
-Freeing initrd memory: 8767k freed
+Freeing initrd memory: 8834k freed
 ACPI: Core revision 20070126
+INFO: trying to register non-static key.
+the code is fine but needs lockdep annotation.
+turning off the locking correctness validator.
+Pid: 0, comm: swapper Not tainted 2.6.25-rc5-mm1-testing #3
+ [<c014321e>] __lock_acquire+0x144/0xb6e
+ [<c010b1a2>] ? native_sched_clock+0xe0/0xff
+ [<c017fc57>] ? kmem_cache_alloc+0x89/0xc9
+ [<c0142ce0>] ? trace_hardirqs_on+0xe8/0x11d
+ [<c014404f>] lock_acquire+0x6a/0x90
+ [<c013b460>] ? down_trylock+0xc/0x27
+ [<c03016cb>] _spin_lock_irqsave+0x42/0x72
+ [<c013b460>] ? down_trylock+0xc/0x27
+ [<c013b460>] down_trylock+0xc/0x27
+ [<c021fa65>] acpi_os_wait_semaphore+0x67/0x13d
+ [<c023a39e>] acpi_ut_acquire_mutex+0x65/0xcf
+ [<c0230261>] acpi_ns_root_initialize+0x1a/0x289
+ [<c043ad54>] acpi_initialize_subsystem+0x47/0x6a
+ [<c043afd4>] acpi_early_init+0x57/0xf8
+ [<c04248ff>] start_kernel+0x34d/0x35a
+ [<c0424019>] i386_start_kernel+0x8/0xa
+ =======================
 ACPI: Checking initramfs for custom DSDT
 Parsing all Control Methods:
 Table [DSDT](id 0001) - 637 Objects with 63 Devices 160 Methods 41 Regions

HTH
T.

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

[Linus Torvalds]

On Sat, 15 Mar 2008, Tilman Schmidt wrote:
> 
> Sorry to say, it doesn't. That is, it does shut up the warning I
> reported, but there's a new one appearing now instead, three lines
> later.

I've reverted the whole thing. Or rather, since there were various small 
fixup commits over time, and a simple revert doesn't really work, I ended 
up just removing the option and the code that was conditional on it - that 
way, if we really want to fight this out some time (after 2.6.25 is out) 
or some vendor wants to use a known-broken option anyway, there's a simple 
and fairly clean commit to revert the revert.

It's commit 9a9e0d685553af76cb6ae2af93cca4913e7fcd47, see 

	http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9a9e0d685553af76cb6ae2af93cca4913e7fcd47

for details if you aren't a git person.

But quite frankly I don't think that we even want to re-introduce this in 
that form. If we really want to have a dynamic custom DSDT, I think we 
should do the whole DSDT replacement *much* later by ACPI (like just 
before driver loading or something like that).

If the BIOS-provided DSDT is _so_ broken that we cannot even get core 
stuff like the CPU's going, I think it has more serious issues than any 
custom DSDT will ever fix, but letting ACPI actually switch DSDT's at 
run-time (instead of just replacing it when looking for it very very early 
in the boot sequence) in order to work around some device issues sounds 
reasonably sane.

So how about aiming to make that DSDT-replacement something you can do 
from any kernel module, _after_ the original DSDT has already been parsed? 
And then the whole "load it from initrd" turns into a regular thing that 
we can do pretty early, but that we don't have to do quite _this_ early!

		Linus

Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

[Éric Piel]

[-- Attachment #1: Type: text/plain, Size: 2514 bytes --]

15/03/08 20:21, Linus Torvalds wrote/a écrit:
> 
> On Sat, 15 Mar 2008, Tilman Schmidt wrote:
>> Sorry to say, it doesn't. That is, it does shut up the warning I
>> reported, but there's a new one appearing now instead, three lines
>> later.
> 
> I've reverted the whole thing. Or rather, since there were various small 
> fixup commits over time, and a simple revert doesn't really work, I ended 
> up just removing the option and the code that was conditional on it - that 
> way, if we really want to fight this out some time (after 2.6.25 is out) 
> or some vendor wants to use a known-broken option anyway, there's a simple 
> and fairly clean commit to revert the revert.
> 
> It's commit 9a9e0d685553af76cb6ae2af93cca4913e7fcd47, see 
> 
> 	http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9a9e0d685553af76cb6ae2af93cca4913e7fcd47
> 
> for details if you aren't a git person.
Hi,
It's a pity, I had just nearly finished a new approach. Instead of
relying on populate_rootfs() and the filesystem infrastructure, the new
approach directly finds the file in the initramfs. With
unpack_to_rootfs(), it turned out to be rather straightforward. Attached
 is a half-tested version of the patch (it boots and works but I haven't
compiled without the option yet). Just in case you would like to change
your mind ;-)


> But quite frankly I don't think that we even want to re-introduce this in 
> that form. If we really want to have a dynamic custom DSDT, I think we 
> should do the whole DSDT replacement *much* later by ACPI (like just 
> before driver loading or something like that).
> 
> If the BIOS-provided DSDT is _so_ broken that we cannot even get core 
> stuff like the CPU's going, I think it has more serious issues than any 
> custom DSDT will ever fix, but letting ACPI actually switch DSDT's at 
> run-time (instead of just replacing it when looking for it very very early 
> in the boot sequence) in order to work around some device issues sounds 
> reasonably sane.
> 
> So how about aiming to make that DSDT-replacement something you can do 
> from any kernel module, _after_ the original DSDT has already been parsed? 
> And then the whole "load it from initrd" turns into a regular thing that 
> we can do pretty early, but that we don't have to do quite _this_ early!
Indeed, this form of DSDT override would be the best. However, I have no
idea what is necessary to implement it. Len, does this approach sound
feasible? Where should I start looking at?

Eric


[-- Attachment #2: 0001-DSDT-in-initramfs-directly-access-the-initramfs.patch --]
[-- Type: text/plain, Size: 7354 bytes --]

>From a0e8247f5f0dd5f332639b5635258a35c3648159 Mon Sep 17 00:00:00 2001
From: Eric Piel <eric@circle.(none)>
Date: Sat, 15 Mar 2008 19:49:05 +0100
Subject: [PATCH 1/1] DSDT in initramfs: directly access the initramfs

The current method for reading the DSDT in the initramfs uses the filesystem. Not only this is bad because such functions should normally not used in the kernel, but in addition it brings the requirement that the filesystem infrastructure is already initialised before initialising ACPI. This is quite unlikely to ever happen. (cf http://marc.info/?t=120536629300001&r=1&w=2)

This patch changes the method of access to initramfs. It uses directly unpack_to_rootfs(). This is build over the "check_only" mode: the initramfs is just read... but if we find a file matching the one we are looking for we copy it to memory.

Signed-off-by: Eric Piel <eric.piel@tremplin-utc.net>
---
 drivers/acpi/osl.c |   62 +----------------------------------------
 init/initramfs.c   |   79 ++++++++++++++++++++++++++++++++++++++++++++++++----
 init/main.c        |    7 ----
 3 files changed, 74 insertions(+), 74 deletions(-)

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 065819b..8fa630f 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -93,6 +93,7 @@ static char osi_additional_string[OSI_STRING_LENGTH_MAX];
 
 #ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
 static int acpi_no_initrd_override;
+extern struct acpi_table_header *acpi_find_dsdt_initrd(void);
 #endif
 
 /*
@@ -324,67 +325,6 @@ acpi_os_predefined_override(const struct acpi_predefined_names *init_val,
 	return AE_OK;
 }
 
-#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
-static struct acpi_table_header *acpi_find_dsdt_initrd(void)
-{
-	struct file *firmware_file;
-	mm_segment_t oldfs;
-	unsigned long len, len2;
-	struct acpi_table_header *dsdt_buffer, *ret = NULL;
-	struct kstat stat;
-	char *ramfs_dsdt_name = "/DSDT.aml";
-
-	printk(KERN_INFO PREFIX "Checking initramfs for custom DSDT\n");
-
-	/*
-	 * Never do this at home, only the user-space is allowed to open a file.
-	 * The clean way would be to use the firmware loader.
-	 * But this code must be run before there is any userspace available.
-	 * A static/init firmware infrastructure doesn't exist yet...
-	 */
-	if (vfs_stat(ramfs_dsdt_name, &stat) < 0)
-		return ret;
-
-	len = stat.size;
-	/* check especially against empty files */
-	if (len <= 4) {
-		printk(KERN_ERR PREFIX "Failed: DSDT only %lu bytes.\n", len);
-		return ret;
-	}
-
-	firmware_file = filp_open(ramfs_dsdt_name, O_RDONLY, 0);
-	if (IS_ERR(firmware_file)) {
-		printk(KERN_ERR PREFIX "Failed to open %s.\n", ramfs_dsdt_name);
-		return ret;
-	}
-
-	dsdt_buffer = kmalloc(len, GFP_ATOMIC);
-	if (!dsdt_buffer) {
-		printk(KERN_ERR PREFIX "Failed to allocate %lu bytes.\n", len);
-		goto err;
-	}
-
-	oldfs = get_fs();
-	set_fs(KERNEL_DS);
-	len2 = vfs_read(firmware_file, (char __user *)dsdt_buffer, len,
-		&firmware_file->f_pos);
-	set_fs(oldfs);
-	if (len2 < len) {
-		printk(KERN_ERR PREFIX "Failed to read %lu bytes from %s.\n",
-			len, ramfs_dsdt_name);
-		ACPI_FREE(dsdt_buffer);
-		goto err;
-	}
-
-	printk(KERN_INFO PREFIX "Found %lu byte DSDT in %s.\n",
-			len, ramfs_dsdt_name);
-	ret = dsdt_buffer;
-err:
-	filp_close(firmware_file, NULL);
-	return ret;
-}
-#endif
-
 acpi_status
 acpi_os_table_override(struct acpi_table_header * existing_table,
 		       struct acpi_table_header ** new_table)
diff --git a/init/initramfs.c b/init/initramfs.c
index c0b1e05..224bf48 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -6,8 +6,15 @@
 #include <linux/delay.h>
 #include <linux/string.h>
 #include <linux/syscalls.h>
+#include <acpi/acpi.h>
 
 static __initdata char *message;
+#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
+static __initdata char *file_looked_for;
+static __initdata void *file_mem;
+#else
+#define file_looked_for 0
+#endif
 static void __init error(char *x)
 {
 	if (!message)
@@ -123,6 +130,7 @@ static __initdata enum state {
 	SkipIt,
 	GotName,
 	CopyFile,
+	CopyFileMem,
 	GotSymlink,
 	Reset
 } state, next_state;
@@ -267,6 +275,11 @@ static int __init do_name(void)
 		free_hash();
 		return 0;
 	}
+	if (file_looked_for) {
+		if (S_ISREG(mode) && (strcmp(collected, file_looked_for) == 0))
+			state = CopyFileMem;
+		return 0;
+	}
 	if (dry_run)
 		return 0;
 	clean_path(collected, mode);
@@ -299,6 +312,37 @@ static int __init do_name(void)
 	return 0;
 }
 
+#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
+static int __init do_copy_mem(void)
+{
+	static void *file_current; /* current position in the file */
+	if (file_mem == NULL) {
+		if (body_len < 4) { /* check especially against empty files */
+			error("file is less than 4 bytes");
+			return 1;
+		}
+		file_mem = kmalloc(body_len, GFP_ATOMIC);
+		if (!file_mem) {
+			error("failed to allocate enough memory");
+			return 1;
+		}
+		file_current = file_mem;
+	}
+	if (count >= body_len) {
+		memcpy(file_current, victim, body_len);
+		eat(body_len);
+	} else {
+		memcpy(file_current, victim, count);
+		body_len -= count;
+		file_current += count;
+		eat(count);
+	}
+	return 1;
+}
+#else
+#define do_copy_mem NULL
+#endif
+
 static int __init do_copy(void)
 {
 	if (count >= body_len) {
@@ -333,6 +377,7 @@ static __initdata int (*actions[])(void) = {
 	[SkipIt]	= do_skip,
 	[GotName]	= do_name,
 	[CopyFile]	= do_copy,
+	[CopyFileMem]	= do_copy_mem,
 	[GotSymlink]	= do_symlink,
 	[Reset]		= do_reset,
 };
@@ -538,7 +583,7 @@ skip:
 	initrd_end = 0;
 }
 
-int __init populate_rootfs(void)
+static int __init populate_rootfs(void)
 {
 	char *err = unpack_to_rootfs(__initramfs_start,
 			 __initramfs_end - __initramfs_start, 0);
@@ -577,10 +622,32 @@ int __init populate_rootfs(void)
 	}
 	return 0;
 }
-#ifndef CONFIG_ACPI_CUSTOM_DSDT_INITRD
-/*
- * if this option is enabled, populate_rootfs() is called _earlier_ in the
- * boot sequence. This insures that the ACPI initialisation can find the file.
- */
 rootfs_initcall(populate_rootfs);
+
+#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
+struct acpi_table_header *acpi_find_dsdt_initrd(void)
+{
+	char *err, *ramfs_dsdt_name = "DSDT.aml";
+
+	printk(KERN_INFO "ACPI: Checking initramfs for custom DSDT\n");
+	file_mem = NULL;
+	file_looked_for = ramfs_dsdt_name;
+	err = unpack_to_rootfs((char *)initrd_start,
+			initrd_end - initrd_start, 1);
+	file_looked_for = NULL;
+
+	if (err) {
+		/*
+		 * Even if reading the DSDT file was successful,
+		 * we give up if the initramfs cannot be entirely read.
+		 */
+		kfree(file_mem);
+		printk(KERN_ERR "ACPI: Aborded because %s.\n", err);
+		return NULL;
+	}
+	if (file_mem)
+		printk(KERN_INFO "ACPI: Found DSDT in %s.\n", ramfs_dsdt_name);
+
+	return file_mem;
+}
 #endif
diff --git a/init/main.c b/init/main.c
index fbb0167..99ce949 100644
--- a/init/main.c
+++ b/init/main.c
@@ -102,12 +102,6 @@ static inline void mark_rodata_ro(void) { }
 extern void tc_init(void);
 #endif
 
-#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
-extern int populate_rootfs(void);
-#else
-static inline void populate_rootfs(void) {}
-#endif
-
 enum system_states system_state;
 EXPORT_SYMBOL(system_state);
 
@@ -650,7 +644,6 @@ asmlinkage void __init start_kernel(void)
 
 	check_bugs();
 
-	populate_rootfs(); /* For DSDT override from initramfs */
 	acpi_early_init(); /* before LAPIC and SMP init */
 
 	/* Do the rest non-__init'ed, we're now alive */
-- 
1.5.4.3

Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

[Linus Torvalds]

On Sat, 15 Mar 2008, ?ric Piel wrote:
>
> It's a pity, I had just nearly finished a new approach. Instead of
> relying on populate_rootfs() and the filesystem infrastructure, the new
> approach directly finds the file in the initramfs.

So that avoids the VFS layer issues, but it's still strictly much worse 
than just having a run-time loading.

What's the problem with just loading a new DSDT later? Potentially as in 
*much* later: including when user-space is all up-and-running? 

For things like DVD install images, you'd quite possibly want to have a 
few known-workaround DSDT images with the installer, and just say "ok, we 
want to fix up this ACPI crap in order to get working suspend/resume" kind 
of thing.

So what's the reason for pushing for this insanely-early workaround in the 
first place, instead of letting user-space do something like

	cat my-dsdt-image > /proc/sys/acpi/DSDT

or whatever at runtime?

		Linus

Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

[Éric Piel]

15/03/08 21:19, Linus Torvalds wrote/a écrit:
> What's the problem with just loading a new DSDT later? Potentially as in 
> *much* later: including when user-space is all up-and-running? 
> 
:
> So what's the reason for pushing for this insanely-early workaround in the 
> first place, instead of letting user-space do something like
> 
> 	cat my-dsdt-image > /proc/sys/acpi/DSDT
> 
> or whatever at runtime?
Yeah, or probably more something like this nowadays ;-)
	cat my-dsdt-image > /sys/firmware/acpi/tables/DSDT

As I said in my previous email, I'm already convinced that late-override
of ACPI table approach would be very interesting to investigate.
However, this cannot be taken lightly. A _lot_ of places in the kernel
depend on the ACPI and nothing has ever been done in the direction of
dynamic modification of the APCI tables. The implementation is likely to
be much bigger than the current 100 lines of patch.

That said, it should be possible to draw some assumptions without
restraining much the functionality. Such as:
 * every object present in the original table is still present is the
new table
 * they keep the same name

Len, do you think it would be feasible? How do you think the
implementation could be done?

Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

[Dave Hansen]

On Sat, 2008-03-15 at 13:47 +0100, Tilman Schmidt wrote:
> > Anyway, I'm sick of too much bitching and too little coding.
> Andrew,
> > here's a patch for -mm that will at least shut up the spinlock
> warnings.
> 
> Sorry to say, it doesn't. That is, it does shut up the warning I
> reported, but there's a new one appearing now instead, three lines
> later. Here's the dmesg diff:
> 
> @@ -216,29 +216,30 @@
>  CPU0: Thermal monitoring enabled
>  Compat vDSO mapped to ffffe000.
>  Checking 'hlt' instruction... OK.
> -BUG: spinlock bad magic on CPU#0, swapper/0
> - lock: c2c19380, .magic: 00000000, .owner: swapper/0, .owner_cpu: 0
> -Pid: 0, comm: swapper Not tainted 2.6.25-rc5-mm1-testing #2
> - [<c01f728c>] spin_bug+0x7c/0x87
> - [<c01f72b0>] _raw_spin_unlock+0x19/0x71
> - [<c0301922>] _spin_unlock+0x1d/0x3c
> - [<c01981aa>] mnt_want_write+0x62/0x88
> - [<c018c382>] sys_mkdirat+0x86/0xd6
> - [<c04260ab>] ? clean_path+0x16/0x4a
> - [<c017fd6f>] ? kfree+0xd8/0xec
> - [<c018c3e2>] sys_mkdir+0x10/0x12
> - [<c0426353>] do_name+0x112/0x1b3
> - [<c042558b>] write_buffer+0x1d/0x2c
> - [<c04255fe>] flush_window+0x64/0xb3
> - [<c04272f5>] unpack_to_rootfs+0x62c/0x8b9
> - [<c04275a2>] populate_rootfs+0x20/0x109
> - [<c0429ed2>] ? alternative_instructions+0x153/0x158
> - [<c04248f5>] start_kernel+0x343/0x355
> - [<c0424019>] i386_start_kernel+0x8/0xa
> - =======================
>  Unpacking initramfs... done
> -Freeing initrd memory: 8767k freed
> +Freeing initrd memory: 8834k freed
>  ACPI: Core revision 20070126
> +INFO: trying to register non-static key.
> +the code is fine but needs lockdep annotation.
> +turning off the locking correctness validator.
> +Pid: 0, comm: swapper Not tainted 2.6.25-rc5-mm1-testing #3
> + [<c014321e>] __lock_acquire+0x144/0xb6e
> + [<c010b1a2>] ? native_sched_clock+0xe0/0xff
> + [<c017fc57>] ? kmem_cache_alloc+0x89/0xc9
> + [<c0142ce0>] ? trace_hardirqs_on+0xe8/0x11d
> + [<c014404f>] lock_acquire+0x6a/0x90
> + [<c013b460>] ? down_trylock+0xc/0x27
> + [<c03016cb>] _spin_lock_irqsave+0x42/0x72
> + [<c013b460>] ? down_trylock+0xc/0x27
> + [<c013b460>] down_trylock+0xc/0x27
> + [<c021fa65>] acpi_os_wait_semaphore+0x67/0x13d
> + [<c023a39e>] acpi_ut_acquire_mutex+0x65/0xcf
> + [<c0230261>] acpi_ns_root_initialize+0x1a/0x289
> + [<c043ad54>] acpi_initialize_subsystem+0x47/0x6a
> + [<c043afd4>] acpi_early_init+0x57/0xf8
> + [<c04248ff>] start_kernel+0x34d/0x35a
> + [<c0424019>] i386_start_kernel+0x8/0xa
> + =======================
>  ACPI: Checking initramfs for custom DSDT
>  Parsing all Control Methods:
>  Table [DSDT](id 0001) - 637 Objects with 63 Devices 160 Methods 41
> Regions

Hi Tim,

Again, thanks for the excellent bug reporting. 

This is actually a different problem (and not my code again, thank
goodness).  I think a few of these got fixed in current -mm.  According
to Peter Z, these mean:

> It means the lock_class_key ended up in non-static storage.
> 
> In practise it often means you initialized a on-stack structure
> incorrectly. DECLARE_WAIT_QUEUE_HEAD() vs
> DECLARE_WAIT_QUEUE_HEAD_ONSTACK() for example.

So, this looks like an on-stack ACPI structure that got initialized
wrongly.  At least we already have those dudes on the cc. :)

But, this might also get fixed by reverting the patch as Linus just did.
It might just be best to wait for another -mm release and see how it
settles out.  

-- Dave

Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

[Peter Zijlstra]

On Sun, 2008-03-16 at 13:11 -0700, Dave Hansen wrote:

> >  ACPI: Core revision 20070126
> > +INFO: trying to register non-static key.
> > +the code is fine but needs lockdep annotation.
> > +turning off the locking correctness validator.
> > +Pid: 0, comm: swapper Not tainted 2.6.25-rc5-mm1-testing #3
> > + [<c014321e>] __lock_acquire+0x144/0xb6e
> > + [<c010b1a2>] ? native_sched_clock+0xe0/0xff
> > + [<c017fc57>] ? kmem_cache_alloc+0x89/0xc9
> > + [<c0142ce0>] ? trace_hardirqs_on+0xe8/0x11d
> > + [<c014404f>] lock_acquire+0x6a/0x90
> > + [<c013b460>] ? down_trylock+0xc/0x27
> > + [<c03016cb>] _spin_lock_irqsave+0x42/0x72
> > + [<c013b460>] ? down_trylock+0xc/0x27
> > + [<c013b460>] down_trylock+0xc/0x27
> > + [<c021fa65>] acpi_os_wait_semaphore+0x67/0x13d
> > + [<c023a39e>] acpi_ut_acquire_mutex+0x65/0xcf
> > + [<c0230261>] acpi_ns_root_initialize+0x1a/0x289
> > + [<c043ad54>] acpi_initialize_subsystem+0x47/0x6a
> > + [<c043afd4>] acpi_early_init+0x57/0xf8
> > + [<c04248ff>] start_kernel+0x34d/0x35a
> > + [<c0424019>] i386_start_kernel+0x8/0xa
> > + =======================
> >  ACPI: Checking initramfs for custom DSDT
> >  Parsing all Control Methods:
> >  Table [DSDT](id 0001) - 637 Objects with 63 Devices 160 Methods 41
> > Regions
> 
> Hi Tim,
> 
> Again, thanks for the excellent bug reporting. 
> 
> This is actually a different problem (and not my code again, thank
> goodness).  I think a few of these got fixed in current -mm.  According
> to Peter Z, these mean:
> 
> > It means the lock_class_key ended up in non-static storage.
> > 
> > In practise it often means you initialized a on-stack structure
> > incorrectly. DECLARE_WAIT_QUEUE_HEAD() vs
> > DECLARE_WAIT_QUEUE_HEAD_ONSTACK() for example.
> 
> So, this looks like an on-stack ACPI structure that got initialized
> wrongly.  At least we already have those dudes on the cc. :)

Actually looks like the semaphore thing again, its a spinlock inside of
down_tylock().

> But, this might also get fixed by reverting the patch as Linus just did.
> It might just be best to wait for another -mm release and see how it
> settles out.  

Looks like another of the semaphore thingies.. Does this go away once
you apply the semaphore lockdep fixup from here:

  http://lkml.org/lkml/2008/3/12/63

Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

[Len Brown]

I agree with Linus' decision to revert/disable this feature.
I think it is appropriate to muck with this in -mm, but not in -rc6
Kudos to Christoph, who recommended we revert it back at -rc2.

> > What's the problem with just loading a new DSDT later? Potentially as in 
> > *much* later: including when user-space is all up-and-running? 

I don't think re-loading the DSDT at run-time would be practical.

First, booting with the OEM DSDT may nullify the benefit
of overriding the OEM DSDT -- the damage may have already been done.

Secondly, unwinding everything that depends on the DSDT is on the
order of kexec or suspend/resume.  We're talking about all the stuff
that PNP does at boot time, plus device discovery and driver binding.

The feature on the table here is an initrd DSDT override.
We already have the ability to statically compile a DSDT
override into the kernel image.  That capability is sufficient
for kernel developers.

The initrd version of the DSDT override is really for one scenario.
Somebody who has a BIOS that even Windows can't deal with -- so
no amount of "Windows bug compatbility" will help Linux with it.
They must be capable eough to generate or acquire a modified DSDT.
They must be unwilling/unable to re-build their kenrel from scratch
each time they update it.  Eg. following debian unstable updates etc.

I think that customer deserves support, particularly because they get
bragging rights that Linux works better on a box build for Windows
than Windows does:-)
However, I don't think there are enough customers like this to
justify a huge effort that would add risk to Linux.

-Len

Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

[Len Brown]

> We used to have 
> a different way but it was even uglier: append the DSDT after the 
> initramfs, and then access it _directly_. This implies teaching 
> populate_rootfs() to not panic when seeing DSDTs and loosing the benefit 
> of the compression.

DSDT's are generally 4KB to 64KB, so I don't think compression
for a DSDT override is important.

-Len

Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

[Len Brown]

> For things like DVD install images, you'd quite possibly want to have a 
> few known-workaround DSDT images with the installer, and just say "ok, we 
> want to fix up this ACPI crap in order to get working suspend/resume" kind 
> of thing.

For a Linux distro to ship DSDT override images, they'd have to
have some licensing & support arrangement with the OEM
who actually owns that BIOS code.

While this wouldn't defy any laws of physics, it doesn't
look compatible with current industry business practices.

OEMs are more likely to simply ship a BIOS update ISO.

-Len

Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

[Len Brown]

On Saturday 15 March 2008, Éric Piel wrote:
> 15/03/08 20:21, Linus Torvalds wrote/a écrit:
> > 
> > I've reverted the whole thing. Or rather, since there were various small 
> > fixup commits over time, and a simple revert doesn't really work, I ended 
> > up just removing the option and the code that was conditional on it - that 
> > way, if we really want to fight this out some time (after 2.6.25 is out) 
> > or some vendor wants to use a known-broken option anyway, there's a simple 
> > and fairly clean commit to revert the revert.
> > 
> > It's commit 9a9e0d685553af76cb6ae2af93cca4913e7fcd47, see 
> > 
> > 	http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9a9e0d685553af76cb6ae2af93cca4913e7fcd47
> > 
> > for details if you aren't a git person.

> It's a pity, I had just nearly finished a new approach. Instead of
> relying on populate_rootfs() and the filesystem infrastructure, the new
> approach directly finds the file in the initramfs. With
> unpack_to_rootfs(), it turned out to be rather straightforward. Attached
>  is a half-tested version of the patch (it boots and works but I haven't
> compiled without the option yet). Just in case you would like to change
> your mind ;-)

I recommend that you make a new proposal for 2.6.26
that applies on top of Linus' top-of-tree and that we
include lkml in hashing it out rather than just linux-acpi.

thanks,
-Len
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

[Len Brown]

> > The initrd version of the DSDT override is really for one scenario.
> > Somebody who has a BIOS that even Windows can't deal with -- so
> > no amount of "Windows bug compatbility" will help Linux with it.

> No, this is for people getting involved in ACPI.
> Everybody thinks ACPI is that complicated..., but it's not.
> It's amazing how far people can debug ACPI bugs (yes, even people who
> "do not even know" how to compile a kernel) by simply analyzing the ASL
> BIOS code.

Thomas,
The justification above is what convinced me
that we should try to integrate this feature.
Further, although we failed in 2.6.25,
I think we should continue to try to get this capability integrated.

If you think it will be useful for additional purposes, that's great.
As you know, I'm somewhat skeptical, as I've seen huge mistakes such
as a database of modified BIOS images created and used when the users
have absolutely no idea what they're doing.  But we don't have to
agree on this to move forward.

thanks,
-Len

Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 1697 bytes --]

Am 17.03.2008 13:23 schrieb Peter Zijlstra:
> On Sun, 2008-03-16 at 13:11 -0700, Dave Hansen wrote:
> 
>>>  ACPI: Core revision 20070126
>>> +INFO: trying to register non-static key.
>>> +the code is fine but needs lockdep annotation.
>>> +turning off the locking correctness validator.
>>> +Pid: 0, comm: swapper Not tainted 2.6.25-rc5-mm1-testing #3
>>> + [<c014321e>] __lock_acquire+0x144/0xb6e
>>> + [<c010b1a2>] ? native_sched_clock+0xe0/0xff
>>> + [<c017fc57>] ? kmem_cache_alloc+0x89/0xc9
>>> + [<c0142ce0>] ? trace_hardirqs_on+0xe8/0x11d
>>> + [<c014404f>] lock_acquire+0x6a/0x90
>>> + [<c013b460>] ? down_trylock+0xc/0x27
>>> + [<c03016cb>] _spin_lock_irqsave+0x42/0x72
>>> + [<c013b460>] ? down_trylock+0xc/0x27
>>> + [<c013b460>] down_trylock+0xc/0x27
>>> + [<c021fa65>] acpi_os_wait_semaphore+0x67/0x13d
>>> + [<c023a39e>] acpi_ut_acquire_mutex+0x65/0xcf
>>> + [<c0230261>] acpi_ns_root_initialize+0x1a/0x289
>>> + [<c043ad54>] acpi_initialize_subsystem+0x47/0x6a
>>> + [<c043afd4>] acpi_early_init+0x57/0xf8
>>> + [<c04248ff>] start_kernel+0x34d/0x35a
>>> + [<c0424019>] i386_start_kernel+0x8/0xa
>>> + =======================
>>>  ACPI: Checking initramfs for custom DSDT
[...]
> Looks like another of the semaphore thingies.. Does this go away once
> you apply the semaphore lockdep fixup from here:
> 
>   http://lkml.org/lkml/2008/3/12/63

Yes, it does. With that patch on top of Dave's, I see no stack
backtraces in dmesg anymore.

HTH
T.

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

[Thomas Renninger]

On Tue, 2008-03-18 at 16:32 -0400, Len Brown wrote:
> > > The initrd version of the DSDT override is really for one scenario.
> > > Somebody who has a BIOS that even Windows can't deal with -- so
> > > no amount of "Windows bug compatbility" will help Linux with it.
> 
> > No, this is for people getting involved in ACPI.
> > Everybody thinks ACPI is that complicated..., but it's not.
> > It's amazing how far people can debug ACPI bugs (yes, even people who
> > "do not even know" how to compile a kernel) by simply analyzing the ASL
> > BIOS code.
> 
> Thomas,
> The justification above is what convinced me
> that we should try to integrate this feature.
> Further, although we failed in 2.6.25,
> I think we should continue to try to get this capability integrated.
> 
> If you think it will be useful for additional purposes, that's great.
> As you know, I'm somewhat skeptical, as I've seen huge mistakes such
> as a database of modified BIOS images created and used when the users
> have absolutely no idea what they're doing.
But even here we now have the only existing database for some research.
-> very important IMO.
> But we don't have to
> agree on this to move forward.
I think we fully agree.
I don't mind to add a message in big letters: "Only override the DSDT
for debugging, please report any findings" or whatever, we can add this
ten times in a row, still it is an important feature which is worth
pushing (and getting populate_root_fs being able to be executed earlier
is a feature others also like to see AFAIK).

    Thomas

Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

[Pavel Machek]

Hi!

> > It's a pity, I had just nearly finished a new approach. Instead of
> > relying on populate_rootfs() and the filesystem infrastructure, the new
> > approach directly finds the file in the initramfs.
> 
> So that avoids the VFS layer issues, but it's still strictly much worse 
> than just having a run-time loading.
> 
> What's the problem with just loading a new DSDT later? Potentially as in 
> *much* later: including when user-space is all up-and-running? 
> 
> For things like DVD install images, you'd quite possibly want to have a 
> few known-workaround DSDT images with the installer, and just say "ok, we 
> want to fix up this ACPI crap in order to get working suspend/resume" kind 
> of thing.
> 
> So what's the reason for pushing for this insanely-early workaround in the 
> first place, instead of letting user-space do something like
> 
> 	cat my-dsdt-image > /proc/sys/acpi/DSDT
> 
> or whatever at runtime?

You have interpretted code runing (AML), and you want to replace it
with different code?

Akin to changing from one kernel to different during runtime?

Yes, I guess it might work for very simple changes, but if you need to change
data structures between origina and modified DSDT, you are in for a
big trouble, right?
							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

[Dave Hansen]

On Fri, 2008-03-21 at 14:17 +0100, Pavel Machek wrote:
> > So what's the reason for pushing for this insanely-early workaround in the 
> > first place, instead of letting user-space do something like
> > 
> >       cat my-dsdt-image > /proc/sys/acpi/DSDT
> > 
> > or whatever at runtime?
> 
> You have interpretted code runing (AML), and you want to replace it
> with different code?
> 
> Akin to changing from one kernel to different during runtime?

Heh.  That gave me an idea.

Can we use kexec for this?  Let's say you get as far in boot as the
initrd and realize that you're running on one of these screwed up
systems.  Can you stick the new DSDT somewhere known (and safe) in
memory, and kexec yourself back to the beginning of the kernel boot?

When you boot up the second time, you have the new, shiny DSDT there
which is, of course, used instead of the bogus BIOS one.

It costs you some bootup time, but we're talking about working around
really busted hardware here.  

-- Dave

Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

[Pavel Machek]

Hi!
> > > So what's the reason for pushing for this insanely-early workaround in the 
> > > first place, instead of letting user-space do something like
> > > 
> > >       cat my-dsdt-image > /proc/sys/acpi/DSDT
> > > 
> > > or whatever at runtime?
> > 
> > You have interpretted code runing (AML), and you want to replace it
> > with different code?
> > 
> > Akin to changing from one kernel to different during runtime?
> 
> Heh.  That gave me an idea.
> 
> Can we use kexec for this?  Let's say you get as far in boot as the
> initrd and realize that you're running on one of these screwed up
> systems.  Can you stick the new DSDT somewhere known (and safe) in
> memory, and kexec yourself back to the beginning of the kernel boot?
> 
> When you boot up the second time, you have the new, shiny DSDT there
> which is, of course, used instead of the bogus BIOS one.
> 
> It costs you some bootup time, but we're talking about working around
> really busted hardware here.  

Hmmm. I guess we should turn off acpi mode, kexec, turn on acpi mode
with new dsdt.

Turning off acpi is not exactly easy, but specs describe how to do
it...

So yes, this is hard but doable.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

[Eric Piel]

Pavel Machek wrote:
> Hi!
>> Can we use kexec for this?  Let's say you get as far in boot as the
>> initrd and realize that you're running on one of these screwed up
>> systems.  Can you stick the new DSDT somewhere known (and safe) in
>> memory, and kexec yourself back to the beginning of the kernel boot?
>>
>> When you boot up the second time, you have the new, shiny DSDT there
>> which is, of course, used instead of the bogus BIOS one.
>>
>> It costs you some bootup time, but we're talking about working around
>> really busted hardware here.  
> 
> Hmmm. I guess we should turn off acpi mode, kexec, turn on acpi mode
> with new dsdt.
> 
> Turning off acpi is not exactly easy, but specs describe how to do
> it...
Why do you think it's necessary to turn off acpi mode? What will not 
work if we keep it on all the time?

BTW, let me summarize my understanding of the kexec approach:
* the userspace write the new DSDT (cat my-dsdt-image > 
/sys/firmware/acpi/tables/DSDT)
* the kernel don't use this DSDT directly but keeps it somewhere warm 
and fuzzy in the RAM
* userspace does a kexec
* the new kernel boots and at some (early) point, dsdt_override() is 
called. It detects that the special place in the RAM for a new DSDT is 
used. It provides this pointer to ACPI as the new place to read the DSDT.

Dave, am I correctly understanding the scenario you had in mind?

I have pratically no knowledge of kexec. Is there a documented way to 
pass big chunk of data from one kernel to another one? How can I do that?

Eric

Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

[Pavel Machek]

On Mon 2008-03-24 18:05:14, Eric Piel wrote:
> Pavel Machek wrote:
>> Hi!
>>> Can we use kexec for this?  Let's say you get as far in boot as the
>>> initrd and realize that you're running on one of these screwed up
>>> systems.  Can you stick the new DSDT somewhere known (and safe) in
>>> memory, and kexec yourself back to the beginning of the kernel boot?
>>>
>>> When you boot up the second time, you have the new, shiny DSDT there
>>> which is, of course, used instead of the bogus BIOS one.
>>>
>>> It costs you some bootup time, but we're talking about working around
>>> really busted hardware here.  
>>
>> Hmmm. I guess we should turn off acpi mode, kexec, turn on acpi mode
>> with new dsdt.
>>
>> Turning off acpi is not exactly easy, but specs describe how to do
>> it...
> Why do you think it's necessary to turn off acpi mode? What will not work 
> if we keep it on all the time?
>
> BTW, let me summarize my understanding of the kexec approach:
> * the userspace write the new DSDT (cat my-dsdt-image > 
> /sys/firmware/acpi/tables/DSDT)
> * the kernel don't use this DSDT directly but keeps it somewhere warm and 
> fuzzy in the RAM
> * userspace does a kexec
> * the new kernel boots and at some (early) point, dsdt_override() is 
> called. It detects that the special place in the RAM for a new DSDT is 
> used. It provides this pointer to ACPI as the new place to read the
> DSDT.

Yes, and now ACPI layer tries to enable already enabled ACPI... which
is no-no according to spec, but you may be able to  get away with it.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
pomozte zachranit klanovicky les:  http://www.ujezdskystrom.info/

Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

[Dave Hansen]

On Mon, 2008-03-24 at 18:05 +0100, Eric Piel wrote:
> BTW, let me summarize my understanding of the kexec approach:
> * the userspace write the new DSDT (cat my-dsdt-image > 
> /sys/firmware/acpi/tables/DSDT)
> * the kernel don't use this DSDT directly but keeps it somewhere warm 
> and fuzzy in the RAM
> * userspace does a kexec
> * the new kernel boots and at some (early) point, dsdt_override() is 
> called. It detects that the special place in the RAM for a new DSDT is 
> used. It provides this pointer to ACPI as the new place to read the DSDT.
> 
> Dave, am I correctly understanding the scenario you had in mind?

Yeah, that's basically what I was thinking.

But, this is only for a case where we can't do the real runtime
replacement that Linus has been advocating.  That approach is clearly
superior, but I would imagine that it'll require some serious ACPI
surgery and won't cover things like if the SRAT table was messed up.

> I have pratically no knowledge of kexec. Is there a documented way to 
> pass big chunk of data from one kernel to another one? How can I do that?

Heh.  Documented, no.  What OS do you think this is? ;)  I'm not sure it
has ever been really needed before.  

At one point, kexec just make a copy of the e820 table to tell the new
kernel where it's ram was.  If you carved out a chunk of memory and set
it as reserved, the new kernel could go looking there.

kexec is Eric Biederman's (on cc) baby, and he might have some more
concrete suggestions for you.

-- Dave

Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot

[Helge Hafting]

Dave Hansen wrote:
> On Fri, 2008-03-21 at 14:17 +0100, Pavel Machek wrote:
>   
>>> So what's the reason for pushing for this insanely-early workaround in the 
>>> first place, instead of letting user-space do something like
>>>
>>>       cat my-dsdt-image > /proc/sys/acpi/DSDT
>>>
>>> or whatever at runtime?
>>>       
>> You have interpretted code runing (AML), and you want to replace it
>> with different code?
>>
>> Akin to changing from one kernel to different during runtime?
>>     
>
> Heh.  That gave me an idea.
>
> Can we use kexec for this?  Let's say you get as far in boot as the
> initrd and realize that you're running on one of these screwed up
> systems.  Can you stick the new DSDT somewhere known (and safe) in
> memory, and kexec yourself back to the beginning of the kernel boot?
>
> When you boot up the second time, you have the new, shiny DSDT there
> which is, of course, used instead of the bogus BIOS one.
>   
I see a problem here. 
This could work. And if it is successful, the "kexec reboot around 
busted hw"-trick
is used for other stuff as well.

So your broken machine reboots with some fix, then it reboots with the
custom DSDT. Is the previous fix preserved? Then a third problem is hit,
another kexec reboot. Is the first fix _and_ the custom DSDT
preserved on this reboot?  Or do we get an infinite sequence of reboots,
alternating between a couple of completely unrelated fixes for bad 
hw/bios...

Once there is more than one fix utilizing this trick, some "protocol" for
managing a string of  kexec fixes might become necessary.

Helge Hafting