2.6.25-rc5-mm1 - Kernel
This is a discussion on 2.6.25-rc5-mm1 - Kernel ; 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 @@ ...
 |
| | LinkBack | Tools |
|
#61
03-14-2008, 08:10 PM
| |||
| |||
 Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/  |
|
#62
03-14-2008, 08:30 PM
| |||
| |||
| Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |
|
#63
03-14-2008, 09:00 PM
| |||
| |||
| Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |
|
#65
03-14-2008, 09:40 PM
| |||
| |||
| Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |
|
#66
03-14-2008, 11:00 PM
| |||
| |||
| Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |
|
#67
03-14-2008, 11:40 PM
| |||
| |||
| Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot 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 #include #include +#include #include #include @@ -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); _ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |
|
#68
03-15-2008, 12:00 PM
| |||
| |||
| Re: 2.6.25-rc5-mm1: "consolechars" hangs on boot On 03/14, Laurent Riffard wrote: > > >>>With 2.6.25-rc5-mm1, my system (Ubuntu 7.10/Gutsy) reliably hangs on > >>>boot. Sysrq-T shows 12 "consolechars" processes stuck in do_exit call. > >>> > >>>The bisection said "Sucker is > >>>patches/signals-send_signal-factor-out-signal_group_exit-checks.patch" > >>> > consolechars ? de8925bc 3432 2795 1 > . > . > . > Call Trace: > do_exit+0x5dd/0x5e1 > do_group_exit+0x5e/0x86 > sys_exit_group+0xf/0x11 > sysenter_past_esp+0x5f/0xa5 Aha, the task doesn't hang, it has exited (as expected), please see below... > >And. While doing this patch I forgot we should fix the bugs with init > >first! > >(will try to make the patch soon). > > > >Laurent, any chance you can try 2.6.25-rc5-mm1 + the patch below? > >Unlikely it can help, but would be great to be sure. > > Yes it does help ! Thanks. > > Despite a big ERR in dmesg, the system now runs fine. > > [ 26.780261] ERR!! init is killed by 10 Great. Thanks a lot Laurent! So what happens is: We have the very old bug (bugs, actually) with the global init && signals which I tried to fix many times but can't find a simple solution. The fatal signal sent to init doesn't really kill it (we have the check in get_signal_to_deliver) but it sets SIGNAL_GROUP_EXIT. This is wrong, now init can't exec, this has other bad implications, and this is just insane. With the signals-send_signal-factor-out-signal_group_exit-checks.patch the task with SIGNAL_GROUP_EXIT doesn't recieve the signals. While this change itself is (I hope) correct, the "killed" /sbin/init now can't see SIGCHLD and the system hangs on boot. > [ 26.781709] [ > [ 26.781719] [ > [ 26.781729] [ > [ 26.781737] [ > [ 26.781747] [ > [ 26.781757] [ > [ 26.781767] [ > [ 26.781791] [ > [ 26.781803] [ > [ 26.781815] [ Not a kernel problem, but this looks a bit strange to me. init has SIG_DFL for SIGUSR1, and someone does kill(1, SIGUSR1). Note that init was explicitly targeted, the signal was not sent to prgp or -1. Most likely Ubuntu knows what it does, and I can't find any email at ubuntu.com to cc... Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |
|
#69
03-15-2008, 12:20 PM
| |||
| |||
| Re: [2.6.25-rc5-mm1] WARNING: at drivers/base/sys.c:173 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...-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) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3rc1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH2742MdB4Whm86/kRAv/ZAJ9wHRGJV9wZDxWkk5uUlqCQfaNqjgCeIU3z fMy1oiGH9kRxMbzJkffG5s8= =Y1Oo -----END PGP SIGNATURE----- |
|
#70
03-15-2008, 12:50 PM
| |||
| |||
| Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot 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 - [ - [ - [ - [ - [ - [ - [ - [ - [ - [ - [ - [ - [ - [ - [ - [ - ======================= 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 + [ + [ + [ + [ + [ + [ + [ + [ + [ + [ + [ + [ + [ + [ + [ + [ + ======================= 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) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3rc1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH28V4MdB4Whm86/kRAlCbAJ9QE44/noLVNiNUWSjymXy9DoNmSwCdG3KT RFx0vd3TCbfC/N1W2yL31Yc= =7yHe -----END PGP SIGNATURE----- |
|
#71
03-15-2008, 07:30 PM
| |||
| |||
| Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot 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/kerne...cca4913e7fcd47 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |
|
#72
03-15-2008, 07:50 PM
| |||
| |||
| Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot 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/kerne...cca4913e7fcd47 > > 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 From a0e8247f5f0dd5f332639b5635258a35c3648159 Mon Sep 17 00:00:00 2001 From: Eric Piel 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 --- 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 #include #include +#include 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 |
|
#73
03-15-2008, 08:30 PM
| |||
| |||
| Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |
|
#74
03-16-2008, 12:20 AM
| |||
| |||
| Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot 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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |
|
#75
03-16-2008, 08:20 PM
| |||
| |||
| Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot 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 > - [ > - [ > - [ > - [ > - [ > - [ > - [ > - [ > - [ > - [ > - [ > - [ > - [ > - [ > - [ > - [ > - ======================= > 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 > + [ > + [ > + [ > + [ > + [ > + [ > + [ > + [ > + [ > + [ > + [ > + [ > + [ > + [ > + [ > + [ > + ======================= > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |
|
#76
03-16-2008, 09:40 PM
| |||
| |||
| Re: 2.6.25-rc5-mm1 build failure of pcsp.c Hello, The build on my laptop (32bit x86) fails. sound/drivers/pcsp/pcsp.c: In function 'snd_pcsp_create': sound/drivers/pcsp/pcsp.c:54: error: 'loops_per_jiffy' undeclared (first use in this function) sound/drivers/pcsp/pcsp.c:54: error: (Each undeclared identifier is reported only once sound/drivers/pcsp/pcsp.c:54: error: for each function it appears in.) Seems like the patch below is needed. Mariusz Signed-off-by: Mariusz Kozlowski --- linux-2.6.25-rc5-mm1-a/sound/drivers/pcsp/pcsp.c 2008-03-16 21:34:28.000000000 +0100 +++ linux-2.6.25-rc5-mm1-b/sound/drivers/pcsp/pcsp.c 2008-03-16 21:58:58.000000000 +0100 @@ -12,6 +12,7 @@ #include #include #include +#include #include #include "pcsp_input.h" #include "pcsp.h" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |
|
#77
03-17-2008, 10:50 AM
| |||
| |||
| Re: [2.6.25-rc5-mm1] regression: cannot run Postfix sendmail command as non-root Tilman Schmidt wrote: > Am 13.03.2008 23:21 schrieb Daniel Lezcano: >> Tilman Schmidt wrote: > >>> ts@xenon:~/kernel> /usr/sbin/sendmail -t < patch-usb-reduce-syslog-clutter-v3 >>> postdrop: warning: can't open /proc/net/if_inet6 (Permission denied) - skipping IPv6 configuration >>> postdrop: fatal: parameter inet_interfaces: no local interface found for ::1 >>> sendmail: warning: command "/usr/sbin/postdrop -r" exited with status 1 >>> sendmail: fatal: ts(1000): unable to execute /usr/sbin/postdrop -r: Success >>> ts@xenon:~/kernel> >>> >>> and unsurprisingly, the mail is not sent. If I do the same as root, >>> everything works as usual, there is no console output from the >>> sendmail command, and the mail goes out as it should. All other >>> networking applications appear to be running normally. > >> Is it possible to have your config file used to compile the kernel ? > > Sure. You can find it at > http://gollum.phnxsoft.com/~ts/linux...2.6.25-rc5-mm1 Thanks, I was not able to reproduce it, but I think I didn't configured postfix as I should had. What version do you use ? If I may ask you, can you put your postfix configuration file and a strace -f of your failing command ? on your website, that will help me a lot to investigate. -- Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |
|
#78
03-17-2008, 12:30 PM
| |||
| |||
| Re: [2.6.25-rc5-mm1] BUG: spinlock bad magic early during boot 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 > > + [ > > + [ > > + [ > > + [ > > + [ > > + [ > > + [ > > + [ > > + [ > > + [ > > + [ > > + [ > > + [ > > + [ > > + [ > > + [ > > + ======================= > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |
|
#79
03-17-2008, 01:00 PM
| |||
| |||
| Re: [2.6.25-rc5-mm1] regression: cannot run Postfix sendmail command as non-root I also tried to reproduce your problem with Postfix (on a Debian distro) but failed to obtain the error message. While googling for the error string, I found this link which report the same kind of error when Postfix is used with grsecurity (in 2006): http://blog.jensthebrain.de/archives...und-grsecurity I barely understand German so I'm not sure it is related to your problem. Benjamin On Mon, Mar 17, 2008 at 11:44 AM, Daniel Lezcano > Tilman Schmidt wrote: > > Am 13.03.2008 23:21 schrieb Daniel Lezcano: > >> Tilman Schmidt wrote: > > > >>> ts@xenon:~/kernel> /usr/sbin/sendmail -t < patch-usb-reduce-syslog-clutter-v3 > >>> postdrop: warning: can't open /proc/net/if_inet6 (Permission denied) - skipping IPv6 configuration > >>> postdrop: fatal: parameter inet_interfaces: no local interface found for ::1 > >>> sendmail: warning: command "/usr/sbin/postdrop -r" exited with status 1 > >>> sendmail: fatal: ts(1000): unable to execute /usr/sbin/postdrop -r: Success > >>> ts@xenon:~/kernel> > >>> > >>> and unsurprisingly, the mail is not sent. If I do the same as root, > >>> everything works as usual, there is no console output from the > >>> sendmail command, and the mail goes out as it should. All other > >>> networking applications appear to be running normally. > > > >> Is it possible to have your config file used to compile the kernel ? > > > > Sure. You can find it at > > http://gollum.phnxsoft.com/~ts/linux...2.6.25-rc5-mm1 > > Thanks, > > I was not able to reproduce it, but I think I didn't configured postfix > as I should had. What version do you use ? > If I may ask you, can you put your postfix configuration file and a > strace -f of your failing command ? on your website, that will help me a > lot to investigate. > > -- Daniel > > > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |
|
#80
03-17-2008, 01:10 PM
| |||
| |||
| Re: [2.6.25-rc5-mm1] regression: cannot run Postfix sendmail command as non-root Daniel Lezcano schrieb: > I was not able to reproduce it, but I think I didn't configured postfix > as I should had. What version do you use ? It's the one that comes with openSUSE 10.3: ts@xenon:~> rpm -q postfix postfix-2.4.5-20.2 > If I may ask you, can you put your postfix configuration file and a > strace -f of your failing command ? on your website, that will help me a > lot to investigate. Sure, no problem. You may find them at http://gollum.phnxsoft.com/~ts/linux/main.cf http://gollum.phnxsoft.com/~ts/linux/strace.log 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) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH3mzHQ3+did9BuFsRAnbKAJ9oHGy2VxrAEhzAE/fix4Fhx0dq4ACbB0tu 5L7z+g04FX9uxXKRm/5E0wI= =vk8G -----END PGP SIGNATURE----- |