Re: 2.6.21-rc5-mm2 - compile error on x86-64
The patch did not apply, but mm3 compiled so I'll try that instead. Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2 - compile error on x86-64
Helge Hafting <[EMAIL PROTECTED]> writes: > Correct. I seem to remember that the latter is considered > "deprecated, but some programs may still depend on it". So I disabled it to > see what broke. udev complained about the missing /proc/sys/kernel/hotplug, > but was happy to use /sys/kernel/uevent_helper instead. I didn't > notice other problems, so I left things like that. Well if anything it is the other way around. The preferred interface to sysctls is /proc/sys. There is the whole thing where people aren't to happy with non-process related things in /proc, so in that sense there is a bit of deprecation, but /proc and /proc/sys are fully supported. The plethora of configuration is what remains when I dug into the binary sys_sysctl interface and tested the assertion that no one uses it, and it has been deprecated for years and we could just kill it. We can now remove the binary sys_sysctl syscall while keeping /proc/sys support. Someday I might even get ambitious and add the appropriate deprecated warnings so we can kill the binary interface. I got as far as seeing that there were a small handful of real programs that use sys_sysctl. I looked at how were giving notice and realized that was insufficient to tell users we were deprecating the thing. I didn't see much point (except being able to immediate drop support) to removing sys_sysctl and since we would have to go a couple of years still supporting it to remove it properly I got lazy and stopped. Maybe myself or someone else can get ambitious and deprecate sys_sysctl properly and we can remove it one of these years... Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2 - compile error on x86-64
On Thu, Mar 29, 2007 at 02:28:16PM -0700, Andrew Morton wrote: > On Thu, 29 Mar 2007 20:20:20 +0200 > Helge Hafting <[EMAIL PROTECTED]> wrote: > [...] > yup, people will presumably work on fixing these things up after the > feature hits mainline. > > > LD init/built-in.o > > LD .tmp_vmlinux1 > > fs/built-in.o: In function `proc_root_init': > > /usr/src/linux/fs/proc/root.c:83: undefined reference to `proc_sys_init' > > Ah. I assume you have CONFIG_SYSCTL=y, CONFIG_PROC_SYSCTL=n? Correct. I seem to remember that the latter is considered "deprecated, but some programs may still depend on it". So I disabled it to see what broke. udev complained about the missing /proc/sys/kernel/hotplug, but was happy to use /sys/kernel/uevent_helper instead. I didn't notice other problems, so I left things like that. Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2 -- ACPI problems (lid switch broken, always shows running from AC, plugging in AC hangs machine)
On 3/30/07, Len Brown <[EMAIL PROTECTED]> wrote: On Thursday 29 March 2007 17:49, Miles Lane wrote: > Hmm. I've reproduced these problems with vanilla 2.6.21-rc5, so the > latest acpi-git changes are off the hook I think the 1st message on this thread holds the answer: > ACPI: BIOS bug: multiple APIC/MADT found, using 2 > ACPI: If "acpi_apic_instance=0" works better, notify linux-acpi@vger.kernel.org Looking at your acpidump in http://bugzilla.kernel.org/show_bug.cgi?id=8283 clearly the 2nd table is broken (it is missing the SCI override) and that is why you get no ACPI interrupts. If Windows works on your machine -- ACPI events such as power button etc -- then that is proof that Windows doesn't use the 2nd MADT and I need to revert 09fe58356d148ff66901ddf639e725ca1a48a0af Yes, the patch you sent fixes these problems. Thanks! Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2 -- ACPI problems (lid switch broken, always shows running from AC, plugging in AC hangs machine)
On Thursday 29 March 2007 17:49, Miles Lane wrote: > Hmm. I've reproduced these problems with vanilla 2.6.21-rc5, so the > latest acpi-git changes are off the hook I think the 1st message on this thread holds the answer: > ACPI: BIOS bug: multiple APIC/MADT found, using 2 > ACPI: If "acpi_apic_instance=0" works better, notify > linux-acpi@vger.kernel.org Looking at your acpidump in http://bugzilla.kernel.org/show_bug.cgi?id=8283 clearly the 2nd table is broken (it is missing the SCI override) and that is why you get no ACPI interrupts. If Windows works on your machine -- ACPI events such as power button etc -- then that is proof that Windows doesn't use the 2nd MADT and I need to revert 09fe58356d148ff66901ddf639e725ca1a48a0af thanks, -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2 -- ACPI problems (lid switch broken, always shows running from AC, plugging in AC hangs machine)
On Thursday 29 March 2007 17:49, Miles Lane wrote: Hmm. I've reproduced these problems with vanilla 2.6.21-rc5, so the latest acpi-git changes are off the hook I think the 1st message on this thread holds the answer: ACPI: BIOS bug: multiple APIC/MADT found, using 2 ACPI: If acpi_apic_instance=0 works better, notify linux-acpi@vger.kernel.org Looking at your acpidump in http://bugzilla.kernel.org/show_bug.cgi?id=8283 clearly the 2nd table is broken (it is missing the SCI override) and that is why you get no ACPI interrupts. If Windows works on your machine -- ACPI events such as power button etc -- then that is proof that Windows doesn't use the 2nd MADT and I need to revert 09fe58356d148ff66901ddf639e725ca1a48a0af thanks, -Len - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2 -- ACPI problems (lid switch broken, always shows running from AC, plugging in AC hangs machine)
On 3/30/07, Len Brown [EMAIL PROTECTED] wrote: On Thursday 29 March 2007 17:49, Miles Lane wrote: Hmm. I've reproduced these problems with vanilla 2.6.21-rc5, so the latest acpi-git changes are off the hook I think the 1st message on this thread holds the answer: ACPI: BIOS bug: multiple APIC/MADT found, using 2 ACPI: If acpi_apic_instance=0 works better, notify linux-acpi@vger.kernel.org Looking at your acpidump in http://bugzilla.kernel.org/show_bug.cgi?id=8283 clearly the 2nd table is broken (it is missing the SCI override) and that is why you get no ACPI interrupts. If Windows works on your machine -- ACPI events such as power button etc -- then that is proof that Windows doesn't use the 2nd MADT and I need to revert 09fe58356d148ff66901ddf639e725ca1a48a0af Yes, the patch you sent fixes these problems. Thanks! Miles - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2 - compile error on x86-64
On Thu, Mar 29, 2007 at 02:28:16PM -0700, Andrew Morton wrote: On Thu, 29 Mar 2007 20:20:20 +0200 Helge Hafting [EMAIL PROTECTED] wrote: [...] yup, people will presumably work on fixing these things up after the feature hits mainline. LD init/built-in.o LD .tmp_vmlinux1 fs/built-in.o: In function `proc_root_init': /usr/src/linux/fs/proc/root.c:83: undefined reference to `proc_sys_init' Ah. I assume you have CONFIG_SYSCTL=y, CONFIG_PROC_SYSCTL=n? Correct. I seem to remember that the latter is considered deprecated, but some programs may still depend on it. So I disabled it to see what broke. udev complained about the missing /proc/sys/kernel/hotplug, but was happy to use /sys/kernel/uevent_helper instead. I didn't notice other problems, so I left things like that. Helge Hafting - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2 - compile error on x86-64
Helge Hafting [EMAIL PROTECTED] writes: Correct. I seem to remember that the latter is considered deprecated, but some programs may still depend on it. So I disabled it to see what broke. udev complained about the missing /proc/sys/kernel/hotplug, but was happy to use /sys/kernel/uevent_helper instead. I didn't notice other problems, so I left things like that. Well if anything it is the other way around. The preferred interface to sysctls is /proc/sys. There is the whole thing where people aren't to happy with non-process related things in /proc, so in that sense there is a bit of deprecation, but /proc and /proc/sys are fully supported. The plethora of configuration is what remains when I dug into the binary sys_sysctl interface and tested the assertion that no one uses it, and it has been deprecated for years and we could just kill it. We can now remove the binary sys_sysctl syscall while keeping /proc/sys support. Someday I might even get ambitious and add the appropriate deprecated warnings so we can kill the binary interface. I got as far as seeing that there were a small handful of real programs that use sys_sysctl. I looked at how were giving notice and realized that was insufficient to tell users we were deprecating the thing. I didn't see much point (except being able to immediate drop support) to removing sys_sysctl and since we would have to go a couple of years still supporting it to remove it properly I got lazy and stopped. Maybe myself or someone else can get ambitious and deprecate sys_sysctl properly and we can remove it one of these years... Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2 - compile error on x86-64
The patch did not apply, but mm3 compiled so I'll try that instead. Helge Hafting - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2 - compile error on x86-64
Andrew Morton <[EMAIL PROTECTED]> writes: > > config PROC_SYSCTL > bool "Sysctl support (/proc/sys)" if EMBEDDED > depends on PROC_FS > select SYSCTL > default y > > CONFIG_PROC_SYSCTL depends on CONFIG_PROC_FS > CONFIG_PROC_SYSCTL selects CONFIG_SYSCTL > > So I don't see anything preventing CONFIG_SYSCTL=y, CONFIG_PROC_FS=y, > CONFIG_PROC_SYSCTL=n. I assume we can make this combination compile, link > and run easily enough. I dunno if it makes any actual sense though? > > > I'd have thought that PROC_SYSCTL should just depend on SYSCTL. But > SYSCTL's Kconfig setup is weird. Yes. My memory is now coming back. I did a few weird things in there when I was making the binary interface optional, and it looks like I never updated the #ifdef in fs/proc/root.c The primary intent was to allow the proc support without the binary interface but I guess the other configuration makes some sense as well in an embedded scenario when you are trying to be as efficient as possible. As I recall the binary interface is less resource intensive then the /proc interface. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2 - compile error on x86-64
On Thu, 29 Mar 2007 16:10:50 -0600 Eric W. Biederman wrote: > Andrew Morton <[EMAIL PROTECTED]> writes: > > > > Ah. I assume you have CONFIG_SYSCTL=y, CONFIG_PROC_SYSCTL=n? > > > > > > > > > > From: Andrew Morton <[EMAIL PROTECTED]> > > > > We're using #ifdef CONFIG_SYSCTL, but we should be using CONFIG_PROC_SYSCTL, > > so we get > > I have no problem with the patch it is clearly more correct than what we > are doing now but I didn't think it was possible to select > CONFIG_SYSCTL and CONFIG_PROCFS without CONFIG_PROC_SYSCTL being > selected... > Do we have a constraint problem in Kconfig? Or am I misremembering things? Hi Eric, Looks like you are just misremembering things... > > fs/built-in.o: In function `proc_root_init': > > /usr/src/linux/fs/proc/root.c:83: undefined reference to `proc_sys_init' > > > > Fix that up and remove an ifdef-in-C. > > > > Cc: "Eric W. Biederman" <[EMAIL PROTECTED]> > > Cc: Helge Hafting <[EMAIL PROTECTED]> > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2 - compile error on x86-64
Andrew Morton <[EMAIL PROTECTED]> writes: > > Ah. I assume you have CONFIG_SYSCTL=y, CONFIG_PROC_SYSCTL=n? > > > > > From: Andrew Morton <[EMAIL PROTECTED]> > > We're using #ifdef CONFIG_SYSCTL, but we should be using CONFIG_PROC_SYSCTL, > so we get I have no problem with the patch it is clearly more correct than what we are doing now but I didn't think it was possible to select CONFIG_SYSCTL and CONFIG_PROCFS without CONFIG_PROC_SYSCTL being selected... Do we have a constraint problem in Kconfig? Or am I misremembering things? > fs/built-in.o: In function `proc_root_init': > /usr/src/linux/fs/proc/root.c:83: undefined reference to `proc_sys_init' > > Fix that up and remove an ifdef-in-C. > > Cc: "Eric W. Biederman" <[EMAIL PROTECTED]> > Cc: Helge Hafting <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2 -- ACPI problems (lid switch broken, always shows running from AC, plugging in AC hangs machine)
Hmm. I've reproduced these problems with vanilla 2.6.21-rc5, so the latest acpi-git changes are off the hook. I am currently trying to reproduce the problems with 2.6.21-rc4. I'll let you know how it turns out. Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2 - compile error on x86-64
On Thu, 29 Mar 2007 20:20:20 +0200
Helge Hafting <[EMAIL PROTECTED]> wrote:
> I tried compiling this on x86-64, and got this compile error:
> CC init/version.o
> CC init/missing_syscalls.o
> In file included from init/missing_syscalls.c:97:
> init/missing_syscalls.h:279:2: warning: #warning syscall ssetmask not
> implemented
> init/missing_syscalls.h:1263:2: warning: #warning syscall getcpu not
> implemented
> init/missing_syscalls.h:1267:2: warning: #warning syscall epoll_pwait not
> implemented
> init/missing_syscalls.h:1271:2: warning: #warning syscall lutimesat not
> implemented
> init/missing_syscalls.h:1275:2: warning: #warning syscall revokeat not
> implemented
> init/missing_syscalls.h:1279:2: warning: #warning syscall frevoke not
> implemented
yup, people will presumably work on fixing these things up after the
feature hits mainline.
> LD init/built-in.o
> LD .tmp_vmlinux1
> fs/built-in.o: In function `proc_root_init':
> /usr/src/linux/fs/proc/root.c:83: undefined reference to `proc_sys_init'
Ah. I assume you have CONFIG_SYSCTL=y, CONFIG_PROC_SYSCTL=n?
From: Andrew Morton <[EMAIL PROTECTED]>
We're using #ifdef CONFIG_SYSCTL, but we should be using CONFIG_PROC_SYSCTL,
so we get
fs/built-in.o: In function `proc_root_init':
/usr/src/linux/fs/proc/root.c:83: undefined reference to `proc_sys_init'
Fix that up and remove an ifdef-in-C.
Cc: "Eric W. Biederman" <[EMAIL PROTECTED]>
Cc: Helge Hafting <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
fs/proc/internal.h |4
fs/proc/root.c |2 --
2 files changed, 4 insertions(+), 2 deletions(-)
diff -puN
fs/proc/root.c~proc-fix-linkage-with-config_sysctl=y-config_proc_sysctl=n
fs/proc/root.c
--- a/fs/proc/root.c~proc-fix-linkage-with-config_sysctl=y-config_proc_sysctl=n
+++ a/fs/proc/root.c
@@ -79,9 +79,7 @@ void __init proc_root_init(void)
proc_device_tree_init();
#endif
proc_bus = proc_mkdir("bus", NULL);
-#ifdef CONFIG_SYSCTL
proc_sys_init();
-#endif
}
static int proc_root_getattr(struct vfsmount *mnt, struct dentry *dentry,
struct kstat *stat
diff -puN
fs/proc/internal.h~proc-fix-linkage-with-config_sysctl=y-config_proc_sysctl=n
fs/proc/internal.h
---
a/fs/proc/internal.h~proc-fix-linkage-with-config_sysctl=y-config_proc_sysctl=n
+++ a/fs/proc/internal.h
@@ -11,7 +11,11 @@
#include
+#ifdef CONFIG_PROC_SYSCTL
extern int proc_sys_init(void);
+#else
+static inline void proc_sys_init(void) { }
+#endif
struct vmalloc_info {
unsigned long used;
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2 -- ACPI problems (lid switch broken, always shows running from AC, plugging in AC hangs machine)
Added: http://bugzilla.kernel.org/show_bug.cgi?id=8283 I am going to double-check with vanilla 2.6.21-rc5 and make sure none of the problems are happening there. Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2 - compile error on x86-64
I tried compiling this on x86-64, and got this compile error: CC init/version.o CC init/missing_syscalls.o In file included from init/missing_syscalls.c:97: init/missing_syscalls.h:279:2: warning: #warning syscall ssetmask not implemented init/missing_syscalls.h:1263:2: warning: #warning syscall getcpu not implemented init/missing_syscalls.h:1267:2: warning: #warning syscall epoll_pwait not implemented init/missing_syscalls.h:1271:2: warning: #warning syscall lutimesat not implemented init/missing_syscalls.h:1275:2: warning: #warning syscall revokeat not implemented init/missing_syscalls.h:1279:2: warning: #warning syscall frevoke not implemented LD init/built-in.o LD .tmp_vmlinux1 fs/built-in.o: In function `proc_root_init': /usr/src/linux/fs/proc/root.c:83: undefined reference to `proc_sys_init' make: *** [.tmp_vmlinux1] Error 1 Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2
On Thu, 29 Mar 2007 09:53:27 -0800 Badari Pulavarty <[EMAIL PROTECTED]> wrote: > On Mon, 2007-03-26 at 21:16 -0800, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/ > > > > > > - This is the same as 2.6.12-rc5-mm1, except the staircase deadline CPU > > scheduler has been added. > > make allyesconfig - didn't give me a clean build :( > (not crucial for me to get it right -- but FYI). > > Thanks, > Badari > > CHK include/linux/version.h > CHK include/linux/utsrelease.h > CHK include/linux/compile.h > CC drivers/net/e100.o > LD drivers/net/wireless/built-in.o > CC drivers/net/epic100.o > CC drivers/net/sis190.o > drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': > drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition > of `zd_chip_switch_radio_on' > CC drivers/net/sis900.o > drivers/net/wireless/zd1211rw/built-in.o:drivers/net/wireless/zd1211rw/zd_chip.c:89: > first defined here > drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': > > [zillions more errors] yeah, not surprised. John, please test allyesconfig ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2 -- ACPI problems (lid switch broken, always shows running from AC, plugging in AC hangs machine)
On Thursday 29 March 2007 04:15, Andrew Morton wrote: > On Thu, 29 Mar 2007 01:00:45 -0700 "Miles Lane" <[EMAIL PROTECTED]> wrote: > > > On 3/28/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > On Wed, 28 Mar 2007 13:55:54 -0700 > > > "Miles Lane" <[EMAIL PROTECTED]> wrote: > > > > > > > My laptop (HP dv1240us) is always showing that my laptop is plugged > > > > into AC power, even when it is running off of the battery. When I > > > > plug into the AC after running on the battery, the machine immediately > > > > locks up. Also, the laptop lid button isn't working -- pressing it > > > > doesn't trigger a suspend. > > > > > > OK, thanks. > > > > > > If you have time, could you please test > > > > > > 2.6.21-rc5 + > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/origin.patch > > > + > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/git-acpi.patch > > > which will allow us to eliminate any non-acpi patches. > > > > Okay, I tested with those patches and got the same problems with the > > resulting build. > > I can't reproduce the hang on plugging in the AC with either > > 2.6.21-rc5-mm2 or the > > build with the patches you sent. So it sounds like the most serious problem, the hang, is not reproducible without the reset of the -mm tree. > > The other problems are 100% reproducible. > > I have some new details: > > > > 1. Power always shows up as plugged in to AC. > > 2. The lid button is non-operational for initiating a suspend. > > 3. Suspending from the Gnome shutdown menu works. Afterwards, the > > lid button works for resuming from suspend. > > 4. If I suspend, resume and then try to shutdown; when I see the > > message "The machine will now halt" the power does not shut off. That > > is, the various buttons on my laptop stay lit up. I am forced to > > shutdown by holding down the power button for five seconds. > > > > Thanks. So we can conclude that all these problems are due to changes in > 2.6.21-rc5-mm2's git-acpi.patch? Miles, Please apply the latest acpi patch directly on top of Linus' tree. http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/test/2.6.21/acpi-test-20070126-2.6.21-rc5.diff.gz If Andrew and I are in sync, you should get the same issues above as above -- no hang, but still problems 1-4. Then revert that patch and edit it to delete all changes to ec.c and apply it again. ie. keep drivers/acpi/ec.c from Linus's tree and re-test. If the symptoms 1-4 go away, then we've isolated the regression to the changes to ec.c. Also, it might be helpful to open up a bug report here: http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI and attach to it the output from acpidump thanks, -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2
On Mon, 2007-03-26 at 21:16 -0800, Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/ > > > - This is the same as 2.6.12-rc5-mm1, except the staircase deadline CPU > scheduler has been added. make allyesconfig - didn't give me a clean build :( (not crucial for me to get it right -- but FYI). Thanks, Badari CHK include/linux/version.h CHK include/linux/utsrelease.h CHK include/linux/compile.h CC drivers/net/e100.o LD drivers/net/wireless/built-in.o CC drivers/net/epic100.o CC drivers/net/sis190.o drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `zd_chip_switch_radio_on' CC drivers/net/sis900.o drivers/net/wireless/zd1211rw/built-in.o:drivers/net/wireless/zd1211rw/zd_chip.c:89: first defined here drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `bcm43xx_dma_tx_suspend' drivers/net/wireless/bcm43xx/built-in.o:drivers/net/wireless/bcm43xx/bcm43xx_main.c:696: first defined here ld: Warning: size of symbol `bcm43xx_dma_tx_suspend' changed from 141 in drivers/net/wireless/bcm43xx/built-in.o to 108 in drivers/net/wireless/mac80211/built-in.o drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `zd_tail' drivers/net/wireless/zd1211rw/built-in.o:drivers/net/wireless/zd1211rw/zd_chip.c:89: first defined here drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `bcm43xx_pio_tx_resume' drivers/net/wireless/bcm43xx/built-in.o:drivers/net/wireless/bcm43xx/bcm43xx_main.c:696: first defined here ld: Warning: size of symbol `bcm43xx_pio_tx_resume' changed from 101 in drivers/net/wireless/bcm43xx/built-in.o to 89 in drivers/net/wireless/mac80211/built-in.o drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `bcm43xx_phy_xmitpower' drivers/net/wireless/bcm43xx/built-in.o:drivers/net/wireless/bcm43xx/bcm43xx_main.c:696: first defined here ld: Warning: size of symbol `bcm43xx_phy_xmitpower' changed from 1312 in drivers/net/wireless/bcm43xx/built-in.o to 1126 in drivers/net/wireless/mac80211/built-in.o drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `zd_chip_disable_hwint' drivers/net/wireless/zd1211rw/built-in.o:drivers/net/wireless/zd1211rw/zd_chip.c:89: first defined here drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `bcm43xx_shm_write16' drivers/net/wireless/bcm43xx/built-in.o:drivers/net/wireless/bcm43xx/bcm43xx_main.c:696: first defined here ld: Warning: size of symbol `bcm43xx_shm_write16' changed from 127 in drivers/net/wireless/bcm43xx/built-in.o to 218 in drivers/net/wireless/mac80211/built-in.o drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `zd_usb_tx' drivers/net/wireless/zd1211rw/built-in.o:drivers/net/wireless/zd1211rw/zd_chip.c:89: first defined here drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `bcm43xx_raw_phy_unlock' drivers/net/wireless/bcm43xx/built-in.o:drivers/net/wireless/bcm43xx/bcm43xx_main.c:696: first defined here ld: Warning: size of symbol `bcm43xx_raw_phy_unlock' changed from 238 in drivers/net/wireless/bcm43xx/built-in.o to 168 in drivers/net/wireless/mac80211/built-in.o drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `zd_switch_radio_off' drivers/net/wireless/zd1211rw/built-in.o:drivers/net/wireless/zd1211rw/zd_chip.c:89: first defined here drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `bcm43xx_dmacontroller_base' drivers/net/wireless/bcm43xx/built-in.o:drivers/net/wireless/bcm43xx/bcm43xx_main.c:696: first defined here drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `zd_chip_control_leds' drivers/net/wireless/zd1211rw/built-in.o:drivers/net/wireless/zd1211rw/zd_chip.c:89: first defined here drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/m
Re: tty OOPS (Re: 2.6.21-rc5-mm2)
On Wed, Mar 28, 2007 at 01:07:56PM -0700, Andrew Morton wrote: > On Wed, 28 Mar 2007 22:56:32 +0400 > Alexey Dobriyan <[EMAIL PROTECTED]> wrote: > > > On Wed, Mar 28, 2007 at 10:38:14PM +0400, Alexey Dobriyan wrote: > > > On Wed, Mar 28, 2007 at 08:04:46PM +0200, Andreas Mohr wrote: > > > > [unrelated maintainers removed, Alexey added] > > > > > > > > On Wed, Mar 28, 2007 at 07:45:24PM +0200, Andreas Mohr wrote: > > > > > Hi, > > > > > > > > > > just wanted to add that when analyzing the backtrace I found the > > > > > comment > > > > > at drivers/char/vt.c/con_close() to be VERY suspicious... > > > > > (need to take tty_mutex to prevent concurrent thread tty access). > > > > > This might just be what happened here despite trying to protect > > > > > against it. > > > > > > > > OK, can we assume that one of > > > > > > > > +protect-tty-drivers-list-with-tty_mutex.patch > > > > +tty-minor-merge-correction.patch > > > > +tty-in-tiocsctty-when-we-steal-a-tty-hang-it-up-fix.patch > > > > > > > > is responsible / not implemented fully? > > > > > > #2 is just comment removal. > > > > > > I may state the obvious, but __iget() in sysfs_drop_dentry() gets NULL > > > inode and you aren't failing on spin_lock one line above because of UP > > > without spinlock debugging. > > > > The only suspicious new patch in -rc5-mm1 to me is > > fix-sysfs-reclaim-crash.patch which removes "sd->s_dentry = NULL;". Note > > that whole sysfs_drop_dentry() is NOP if ->s_dentry is NULL. > > > > Could you try to revert it? > > > > Alexey, who knows very little about sysfs internals > > cc's added. > > > Also added is the sad little missive I sent to the USB guys last night, > which is similar-looking: > > > > Begin forwarded message: > > Date: Wed, 28 Mar 2007 00:34:45 -0700 > From: Andrew Morton <[EMAIL PROTECTED]> > To: linux-usb-devel@lists.sourceforge.net > Subject: usb/sysfs oops in 2.6.21-rc5-mm1 > > > > I think the connector wasn't pushed in terribly well, so there might have > been some contact bounce. > > > [15813.836000] ipw2200: Firmware error detected. Restarting. > [17200.268000] hub 2-0:1.0: port 1 disabled by hub (EMI?), re-enabling... > [17200.268000] usb 2-1: USB disconnect, address 4 > [17200.268000] BUG: unable to handle kernel NULL pointer dereference at > virtual address 0024 > [17200.268000] printing eip: > [17200.268000] c016e447 > [17200.268000] *pde = > [17200.268000] Oops: [#1] > [17200.268000] last sysfs file: block/sr0/size > [17200.268000] Modules linked in: udf i915 drm ipw2200 sonypi ipv6 autofs4 > hidp l2cap sunrpc nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 > xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables > cpufreq_ondemand video sbs button battery asus_acpi ac nvram hci_usb > bluetooth ieee80211 ohci1394 ieee1394 joydev ieee80211_crypt snd_hda_intel > snd_hda_codec ehci_hcd uhci_hcd sg snd_seq_dummy snd_seq_oss > snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm > snd_timer snd sr_mod cdrom piix soundcore i2c_i801 snd_page_alloc i2c_core > pcspkr generic ext3 jbd ide_disk ide_core > [17200.268000] CPU:0 > [17200.268000] EIP:0060:[]Not tainted VLI > [17200.268000] EFLAGS: 00010246 (2.6.21-rc5-mm1 #1) > [17200.268000] EIP is at __iget+0x3/0x48 > [17200.268000] eax: ebx: ecx: edx: c8a90514 > [17200.268000] esi: c8a90514 edi: ebp: c8cea5e4 esp: c210fe5c > [17200.268000] ds: 007b es: 007b fs: 00d8 gs: ss: 0068 > [17200.268000] Process khubd (pid: 155, ti=c210e000 task=c209b6f0 > task.ti=c210e000) > [17200.268000] Stack: c2493a14 c0192933 c8cea5e8 c0338373 c0338373 c8cea5e4 > c0192a90 c889ba24 > [17200.268000]c033836f c8a90514 c8cea58c c889ba08 c8556a40 df8918c0 > c24e6418 c0230d46 > [17200.268000]c889ba08 c889ba08 c0230dd8 c889ba08 c889ba00 df8918c0 > c24e6418 c0230ffa > [17200.268000] Call Trace: > [17200.268000] [] sysfs_drop_dentry+0x2b/0xc3 > [17200.268000] [] sysfs_hash_and_remove+0x86/0x12c > [17200.268000] [] device_remove_file+0x19/0x25 > [17200.268000] [] device_del+0x26/0x240 > [17200.268000] [] device_unregister+0x8/0x10 > [17200.268000] [] usb_remove_ep_files+0x4d/0x60 > [17200.268000] [] usb_new_device+0x199/0x1ab > [17200.268000] [] usb_remove_sysfs_intf_files+0x1e/0x43 > [17200.268000] [] usb_disable_device+0x55/0xbb > [17200.268000] [] usb_disconnect+0x87/0x100 > [17200.268000] [] hub_thread+0x361/0xa70 > [17200.268000] [] d_lookup+0x16/0x31 > [17200.268000] [] __wake_up_common+0x31/0x4f > [17200.268000] [] autoremove_wake_function+0x0/0x35 > [17200.268000] [] hub_thread+0x0/0xa70 > [17200.268000] [] kthread+0xa0/0xc9 > [17200.268000] [] kthread+0x0/0xc9 > [17200.268000] [] kernel_thread_helper+0x7/0x10 > [17200.268000] === > [17200.268000] Code: 00 00 00 89 d8 81 ce 00 02 00 00 e8 3e ba 01 00 8b 43 20 > 31 c9 89 f2 89 04 24 89 d8 e8 19 25 01 00
Re: 2.6.21-rc5-mm2 -- ACPI problems (lid switch broken, always shows running from AC, plugging in AC hangs machine)
On Thu, 29 Mar 2007 01:00:45 -0700 "Miles Lane" <[EMAIL PROTECTED]> wrote: > On 3/28/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > On Wed, 28 Mar 2007 13:55:54 -0700 > > "Miles Lane" <[EMAIL PROTECTED]> wrote: > > > > > My laptop (HP dv1240us) is always showing that my laptop is plugged > > > into AC power, even when it is running off of the battery. When I > > > plug into the AC after running on the battery, the machine immediately > > > locks up. Also, the laptop lid button isn't working -- pressing it > > > doesn't trigger a suspend. > > > > OK, thanks. > > > > If you have time, could you please test > > > > 2.6.21-rc5 + > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/origin.patch > > + > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/git-acpi.patch > > which will allow us to eliminate any non-acpi patches. > > Okay, I tested with those patches and got the same problems with the > resulting build. > I can't reproduce the hang on plugging in the AC with either > 2.6.21-rc5-mm2 or the > build with the patches you sent. The other problems are 100% reproducible. > I have some new details: > > 1. Power always shows up as plugged in to AC. > 2. The lid button is non-operational for initiating a suspend. > 3. Suspending from the Gnome shutdown menu works. Afterwards, the > lid button works for resuming from suspend. > 4. If I suspend, resume and then try to shutdown; when I see the > message "The machine will now halt" the power does not shut off. That > is, the various buttons on my laptop stay lit up. I am forced to > shutdown by holding down the power button for five seconds. > Thanks. So we can conclude that all these problems are due to changes in 2.6.21-rc5-mm2's git-acpi.patch? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2 -- ACPI problems (lid switch broken, always shows running from AC, plugging in AC hangs machine)
On 3/28/07, Andrew Morton <[EMAIL PROTECTED]> wrote: On Wed, 28 Mar 2007 13:55:54 -0700 "Miles Lane" <[EMAIL PROTECTED]> wrote: > My laptop (HP dv1240us) is always showing that my laptop is plugged > into AC power, even when it is running off of the battery. When I > plug into the AC after running on the battery, the machine immediately > locks up. Also, the laptop lid button isn't working -- pressing it > doesn't trigger a suspend. OK, thanks. If you have time, could you please test 2.6.21-rc5 + ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/origin.patch + ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/git-acpi.patch which will allow us to eliminate any non-acpi patches. Okay, I tested with those patches and got the same problems with the resulting build. I can't reproduce the hang on plugging in the AC with either 2.6.21-rc5-mm2 or the build with the patches you sent. The other problems are 100% reproducible. I have some new details: 1. Power always shows up as plugged in to AC. 2. The lid button is non-operational for initiating a suspend. 3. Suspending from the Gnome shutdown menu works. Afterwards, the lid button works for resuming from suspend. 4. If I suspend, resume and then try to shutdown; when I see the message "The machine will now halt" the power does not shut off. That is, the various buttons on my laptop stay lit up. I am forced to shutdown by holding down the power button for five seconds. I hope this helps, Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2 -- ACPI problems (lid switch broken, always shows running from AC, plugging in AC hangs machine)
On 3/28/07, Andrew Morton [EMAIL PROTECTED] wrote: On Wed, 28 Mar 2007 13:55:54 -0700 Miles Lane [EMAIL PROTECTED] wrote: My laptop (HP dv1240us) is always showing that my laptop is plugged into AC power, even when it is running off of the battery. When I plug into the AC after running on the battery, the machine immediately locks up. Also, the laptop lid button isn't working -- pressing it doesn't trigger a suspend. OK, thanks. If you have time, could you please test 2.6.21-rc5 + ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/origin.patch + ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/git-acpi.patch which will allow us to eliminate any non-acpi patches. Okay, I tested with those patches and got the same problems with the resulting build. I can't reproduce the hang on plugging in the AC with either 2.6.21-rc5-mm2 or the build with the patches you sent. The other problems are 100% reproducible. I have some new details: 1. Power always shows up as plugged in to AC. 2. The lid button is non-operational for initiating a suspend. 3. Suspending from the Gnome shutdown menu works. Afterwards, the lid button works for resuming from suspend. 4. If I suspend, resume and then try to shutdown; when I see the message The machine will now halt the power does not shut off. That is, the various buttons on my laptop stay lit up. I am forced to shutdown by holding down the power button for five seconds. I hope this helps, Miles - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2 -- ACPI problems (lid switch broken, always shows running from AC, plugging in AC hangs machine)
On Thu, 29 Mar 2007 01:00:45 -0700 Miles Lane [EMAIL PROTECTED] wrote: On 3/28/07, Andrew Morton [EMAIL PROTECTED] wrote: On Wed, 28 Mar 2007 13:55:54 -0700 Miles Lane [EMAIL PROTECTED] wrote: My laptop (HP dv1240us) is always showing that my laptop is plugged into AC power, even when it is running off of the battery. When I plug into the AC after running on the battery, the machine immediately locks up. Also, the laptop lid button isn't working -- pressing it doesn't trigger a suspend. OK, thanks. If you have time, could you please test 2.6.21-rc5 + ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/origin.patch + ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/git-acpi.patch which will allow us to eliminate any non-acpi patches. Okay, I tested with those patches and got the same problems with the resulting build. I can't reproduce the hang on plugging in the AC with either 2.6.21-rc5-mm2 or the build with the patches you sent. The other problems are 100% reproducible. I have some new details: 1. Power always shows up as plugged in to AC. 2. The lid button is non-operational for initiating a suspend. 3. Suspending from the Gnome shutdown menu works. Afterwards, the lid button works for resuming from suspend. 4. If I suspend, resume and then try to shutdown; when I see the message The machine will now halt the power does not shut off. That is, the various buttons on my laptop stay lit up. I am forced to shutdown by holding down the power button for five seconds. Thanks. So we can conclude that all these problems are due to changes in 2.6.21-rc5-mm2's git-acpi.patch? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tty OOPS (Re: 2.6.21-rc5-mm2)
On Wed, Mar 28, 2007 at 01:07:56PM -0700, Andrew Morton wrote: On Wed, 28 Mar 2007 22:56:32 +0400 Alexey Dobriyan [EMAIL PROTECTED] wrote: On Wed, Mar 28, 2007 at 10:38:14PM +0400, Alexey Dobriyan wrote: On Wed, Mar 28, 2007 at 08:04:46PM +0200, Andreas Mohr wrote: [unrelated maintainers removed, Alexey added] On Wed, Mar 28, 2007 at 07:45:24PM +0200, Andreas Mohr wrote: Hi, just wanted to add that when analyzing the backtrace I found the comment at drivers/char/vt.c/con_close() to be VERY suspicious... (need to take tty_mutex to prevent concurrent thread tty access). This might just be what happened here despite trying to protect against it. OK, can we assume that one of +protect-tty-drivers-list-with-tty_mutex.patch +tty-minor-merge-correction.patch +tty-in-tiocsctty-when-we-steal-a-tty-hang-it-up-fix.patch is responsible / not implemented fully? #2 is just comment removal. I may state the obvious, but __iget() in sysfs_drop_dentry() gets NULL inode and you aren't failing on spin_lock one line above because of UP without spinlock debugging. The only suspicious new patch in -rc5-mm1 to me is fix-sysfs-reclaim-crash.patch which removes sd-s_dentry = NULL;. Note that whole sysfs_drop_dentry() is NOP if -s_dentry is NULL. Could you try to revert it? Alexey, who knows very little about sysfs internals cc's added. Also added is the sad little missive I sent to the USB guys last night, which is similar-looking: Begin forwarded message: Date: Wed, 28 Mar 2007 00:34:45 -0700 From: Andrew Morton [EMAIL PROTECTED] To: linux-usb-devel@lists.sourceforge.net Subject: usb/sysfs oops in 2.6.21-rc5-mm1 I think the connector wasn't pushed in terribly well, so there might have been some contact bounce. [15813.836000] ipw2200: Firmware error detected. Restarting. [17200.268000] hub 2-0:1.0: port 1 disabled by hub (EMI?), re-enabling... [17200.268000] usb 2-1: USB disconnect, address 4 [17200.268000] BUG: unable to handle kernel NULL pointer dereference at virtual address 0024 [17200.268000] printing eip: [17200.268000] c016e447 [17200.268000] *pde = [17200.268000] Oops: [#1] [17200.268000] last sysfs file: block/sr0/size [17200.268000] Modules linked in: udf i915 drm ipw2200 sonypi ipv6 autofs4 hidp l2cap sunrpc nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables cpufreq_ondemand video sbs button battery asus_acpi ac nvram hci_usb bluetooth ieee80211 ohci1394 ieee1394 joydev ieee80211_crypt snd_hda_intel snd_hda_codec ehci_hcd uhci_hcd sg snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd sr_mod cdrom piix soundcore i2c_i801 snd_page_alloc i2c_core pcspkr generic ext3 jbd ide_disk ide_core [17200.268000] CPU:0 [17200.268000] EIP:0060:[c016e447]Not tainted VLI [17200.268000] EFLAGS: 00010246 (2.6.21-rc5-mm1 #1) [17200.268000] EIP is at __iget+0x3/0x48 [17200.268000] eax: ebx: ecx: edx: c8a90514 [17200.268000] esi: c8a90514 edi: ebp: c8cea5e4 esp: c210fe5c [17200.268000] ds: 007b es: 007b fs: 00d8 gs: ss: 0068 [17200.268000] Process khubd (pid: 155, ti=c210e000 task=c209b6f0 task.ti=c210e000) [17200.268000] Stack: c2493a14 c0192933 c8cea5e8 c0338373 c0338373 c8cea5e4 c0192a90 c889ba24 [17200.268000]c033836f c8a90514 c8cea58c c889ba08 c8556a40 df8918c0 c24e6418 c0230d46 [17200.268000]c889ba08 c889ba08 c0230dd8 c889ba08 c889ba00 df8918c0 c24e6418 c0230ffa [17200.268000] Call Trace: [17200.268000] [c0192933] sysfs_drop_dentry+0x2b/0xc3 [17200.268000] [c0192a90] sysfs_hash_and_remove+0x86/0x12c [17200.268000] [c0230d46] device_remove_file+0x19/0x25 [17200.268000] [c0230dd8] device_del+0x26/0x240 [17200.268000] [c0230ffa] device_unregister+0x8/0x10 [17200.268000] [c026739a] usb_remove_ep_files+0x4d/0x60 [17200.268000] [c0260031] usb_new_device+0x199/0x1ab [17200.268000] [c0266d14] usb_remove_sysfs_intf_files+0x1e/0x43 [17200.268000] [c026312d] usb_disable_device+0x55/0xbb [17200.268000] [c0260415] usb_disconnect+0x87/0x100 [17200.268000] [c0260842] hub_thread+0x361/0xa70 [17200.268000] [c016d394] d_lookup+0x16/0x31 [17200.268000] [c01174df] __wake_up_common+0x31/0x4f [17200.268000] [c0128754] autoremove_wake_function+0x0/0x35 [17200.268000] [c02604e1] hub_thread+0x0/0xa70 [17200.268000] [c01285f7] kthread+0xa0/0xc9 [17200.268000] [c0128557] kthread+0x0/0xc9 [17200.268000] [c010464f] kernel_thread_helper+0x7/0x10 [17200.268000] === [17200.268000] Code: 00 00 00 89 d8 81 ce 00 02 00 00 e8 3e ba 01 00 8b 43 20 31 c9 89 f2 89 04 24 89 d8 e8 19 25 01 00 58 5b 5e c3 90 90 90 53 89 c3 83 78 24 00 74 05 ff 40 24
Re: 2.6.21-rc5-mm2
On Mon, 2007-03-26 at 21:16 -0800, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/ - This is the same as 2.6.12-rc5-mm1, except the staircase deadline CPU scheduler has been added. make allyesconfig - didn't give me a clean build :( (not crucial for me to get it right -- but FYI). Thanks, Badari CHK include/linux/version.h CHK include/linux/utsrelease.h CHK include/linux/compile.h CC drivers/net/e100.o LD drivers/net/wireless/built-in.o CC drivers/net/epic100.o CC drivers/net/sis190.o drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `zd_chip_switch_radio_on' CC drivers/net/sis900.o drivers/net/wireless/zd1211rw/built-in.o:drivers/net/wireless/zd1211rw/zd_chip.c:89: first defined here drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `bcm43xx_dma_tx_suspend' drivers/net/wireless/bcm43xx/built-in.o:drivers/net/wireless/bcm43xx/bcm43xx_main.c:696: first defined here ld: Warning: size of symbol `bcm43xx_dma_tx_suspend' changed from 141 in drivers/net/wireless/bcm43xx/built-in.o to 108 in drivers/net/wireless/mac80211/built-in.o drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `zd_tail' drivers/net/wireless/zd1211rw/built-in.o:drivers/net/wireless/zd1211rw/zd_chip.c:89: first defined here drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `bcm43xx_pio_tx_resume' drivers/net/wireless/bcm43xx/built-in.o:drivers/net/wireless/bcm43xx/bcm43xx_main.c:696: first defined here ld: Warning: size of symbol `bcm43xx_pio_tx_resume' changed from 101 in drivers/net/wireless/bcm43xx/built-in.o to 89 in drivers/net/wireless/mac80211/built-in.o drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `bcm43xx_phy_xmitpower' drivers/net/wireless/bcm43xx/built-in.o:drivers/net/wireless/bcm43xx/bcm43xx_main.c:696: first defined here ld: Warning: size of symbol `bcm43xx_phy_xmitpower' changed from 1312 in drivers/net/wireless/bcm43xx/built-in.o to 1126 in drivers/net/wireless/mac80211/built-in.o drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `zd_chip_disable_hwint' drivers/net/wireless/zd1211rw/built-in.o:drivers/net/wireless/zd1211rw/zd_chip.c:89: first defined here drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `bcm43xx_shm_write16' drivers/net/wireless/bcm43xx/built-in.o:drivers/net/wireless/bcm43xx/bcm43xx_main.c:696: first defined here ld: Warning: size of symbol `bcm43xx_shm_write16' changed from 127 in drivers/net/wireless/bcm43xx/built-in.o to 218 in drivers/net/wireless/mac80211/built-in.o drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `zd_usb_tx' drivers/net/wireless/zd1211rw/built-in.o:drivers/net/wireless/zd1211rw/zd_chip.c:89: first defined here drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `bcm43xx_raw_phy_unlock' drivers/net/wireless/bcm43xx/built-in.o:drivers/net/wireless/bcm43xx/bcm43xx_main.c:696: first defined here ld: Warning: size of symbol `bcm43xx_raw_phy_unlock' changed from 238 in drivers/net/wireless/bcm43xx/built-in.o to 168 in drivers/net/wireless/mac80211/built-in.o drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `zd_switch_radio_off' drivers/net/wireless/zd1211rw/built-in.o:drivers/net/wireless/zd1211rw/zd_chip.c:89: first defined here drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `bcm43xx_dmacontroller_base' drivers/net/wireless/bcm43xx/built-in.o:drivers/net/wireless/bcm43xx/bcm43xx_main.c:696: first defined here drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `zd_chip_control_leds' drivers/net/wireless/zd1211rw/built-in.o:drivers/net/wireless/zd1211rw/zd_chip.c:89: first defined here drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx
Re: 2.6.21-rc5-mm2 -- ACPI problems (lid switch broken, always shows running from AC, plugging in AC hangs machine)
On Thursday 29 March 2007 04:15, Andrew Morton wrote: On Thu, 29 Mar 2007 01:00:45 -0700 Miles Lane [EMAIL PROTECTED] wrote: On 3/28/07, Andrew Morton [EMAIL PROTECTED] wrote: On Wed, 28 Mar 2007 13:55:54 -0700 Miles Lane [EMAIL PROTECTED] wrote: My laptop (HP dv1240us) is always showing that my laptop is plugged into AC power, even when it is running off of the battery. When I plug into the AC after running on the battery, the machine immediately locks up. Also, the laptop lid button isn't working -- pressing it doesn't trigger a suspend. OK, thanks. If you have time, could you please test 2.6.21-rc5 + ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/origin.patch + ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/git-acpi.patch which will allow us to eliminate any non-acpi patches. Okay, I tested with those patches and got the same problems with the resulting build. I can't reproduce the hang on plugging in the AC with either 2.6.21-rc5-mm2 or the build with the patches you sent. So it sounds like the most serious problem, the hang, is not reproducible without the reset of the -mm tree. The other problems are 100% reproducible. I have some new details: 1. Power always shows up as plugged in to AC. 2. The lid button is non-operational for initiating a suspend. 3. Suspending from the Gnome shutdown menu works. Afterwards, the lid button works for resuming from suspend. 4. If I suspend, resume and then try to shutdown; when I see the message The machine will now halt the power does not shut off. That is, the various buttons on my laptop stay lit up. I am forced to shutdown by holding down the power button for five seconds. Thanks. So we can conclude that all these problems are due to changes in 2.6.21-rc5-mm2's git-acpi.patch? Miles, Please apply the latest acpi patch directly on top of Linus' tree. http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/test/2.6.21/acpi-test-20070126-2.6.21-rc5.diff.gz If Andrew and I are in sync, you should get the same issues above as above -- no hang, but still problems 1-4. Then revert that patch and edit it to delete all changes to ec.c and apply it again. ie. keep drivers/acpi/ec.c from Linus's tree and re-test. If the symptoms 1-4 go away, then we've isolated the regression to the changes to ec.c. Also, it might be helpful to open up a bug report here: http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI and attach to it the output from acpidump thanks, -Len - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2
On Thu, 29 Mar 2007 09:53:27 -0800 Badari Pulavarty [EMAIL PROTECTED] wrote: On Mon, 2007-03-26 at 21:16 -0800, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/ - This is the same as 2.6.12-rc5-mm1, except the staircase deadline CPU scheduler has been added. make allyesconfig - didn't give me a clean build :( (not crucial for me to get it right -- but FYI). Thanks, Badari CHK include/linux/version.h CHK include/linux/utsrelease.h CHK include/linux/compile.h CC drivers/net/e100.o LD drivers/net/wireless/built-in.o CC drivers/net/epic100.o CC drivers/net/sis190.o drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `zd_chip_switch_radio_on' CC drivers/net/sis900.o drivers/net/wireless/zd1211rw/built-in.o:drivers/net/wireless/zd1211rw/zd_chip.c:89: first defined here drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': [zillions more errors] yeah, not surprised. John, please test allyesconfig ;) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2 - compile error on x86-64
I tried compiling this on x86-64, and got this compile error: CC init/version.o CC init/missing_syscalls.o In file included from init/missing_syscalls.c:97: init/missing_syscalls.h:279:2: warning: #warning syscall ssetmask not implemented init/missing_syscalls.h:1263:2: warning: #warning syscall getcpu not implemented init/missing_syscalls.h:1267:2: warning: #warning syscall epoll_pwait not implemented init/missing_syscalls.h:1271:2: warning: #warning syscall lutimesat not implemented init/missing_syscalls.h:1275:2: warning: #warning syscall revokeat not implemented init/missing_syscalls.h:1279:2: warning: #warning syscall frevoke not implemented LD init/built-in.o LD .tmp_vmlinux1 fs/built-in.o: In function `proc_root_init': /usr/src/linux/fs/proc/root.c:83: undefined reference to `proc_sys_init' make: *** [.tmp_vmlinux1] Error 1 Helge Hafting - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2 - compile error on x86-64
On Thu, 29 Mar 2007 20:20:20 +0200
Helge Hafting [EMAIL PROTECTED] wrote:
I tried compiling this on x86-64, and got this compile error:
CC init/version.o
CC init/missing_syscalls.o
In file included from init/missing_syscalls.c:97:
init/missing_syscalls.h:279:2: warning: #warning syscall ssetmask not
implemented
init/missing_syscalls.h:1263:2: warning: #warning syscall getcpu not
implemented
init/missing_syscalls.h:1267:2: warning: #warning syscall epoll_pwait not
implemented
init/missing_syscalls.h:1271:2: warning: #warning syscall lutimesat not
implemented
init/missing_syscalls.h:1275:2: warning: #warning syscall revokeat not
implemented
init/missing_syscalls.h:1279:2: warning: #warning syscall frevoke not
implemented
yup, people will presumably work on fixing these things up after the
feature hits mainline.
LD init/built-in.o
LD .tmp_vmlinux1
fs/built-in.o: In function `proc_root_init':
/usr/src/linux/fs/proc/root.c:83: undefined reference to `proc_sys_init'
Ah. I assume you have CONFIG_SYSCTL=y, CONFIG_PROC_SYSCTL=n?
From: Andrew Morton [EMAIL PROTECTED]
We're using #ifdef CONFIG_SYSCTL, but we should be using CONFIG_PROC_SYSCTL,
so we get
fs/built-in.o: In function `proc_root_init':
/usr/src/linux/fs/proc/root.c:83: undefined reference to `proc_sys_init'
Fix that up and remove an ifdef-in-C.
Cc: Eric W. Biederman [EMAIL PROTECTED]
Cc: Helge Hafting [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
fs/proc/internal.h |4
fs/proc/root.c |2 --
2 files changed, 4 insertions(+), 2 deletions(-)
diff -puN
fs/proc/root.c~proc-fix-linkage-with-config_sysctl=y-config_proc_sysctl=n
fs/proc/root.c
--- a/fs/proc/root.c~proc-fix-linkage-with-config_sysctl=y-config_proc_sysctl=n
+++ a/fs/proc/root.c
@@ -79,9 +79,7 @@ void __init proc_root_init(void)
proc_device_tree_init();
#endif
proc_bus = proc_mkdir(bus, NULL);
-#ifdef CONFIG_SYSCTL
proc_sys_init();
-#endif
}
static int proc_root_getattr(struct vfsmount *mnt, struct dentry *dentry,
struct kstat *stat
diff -puN
fs/proc/internal.h~proc-fix-linkage-with-config_sysctl=y-config_proc_sysctl=n
fs/proc/internal.h
---
a/fs/proc/internal.h~proc-fix-linkage-with-config_sysctl=y-config_proc_sysctl=n
+++ a/fs/proc/internal.h
@@ -11,7 +11,11 @@
#include linux/proc_fs.h
+#ifdef CONFIG_PROC_SYSCTL
extern int proc_sys_init(void);
+#else
+static inline void proc_sys_init(void) { }
+#endif
struct vmalloc_info {
unsigned long used;
_
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2 - compile error on x86-64
Andrew Morton [EMAIL PROTECTED] writes: Ah. I assume you have CONFIG_SYSCTL=y, CONFIG_PROC_SYSCTL=n? From: Andrew Morton [EMAIL PROTECTED] We're using #ifdef CONFIG_SYSCTL, but we should be using CONFIG_PROC_SYSCTL, so we get I have no problem with the patch it is clearly more correct than what we are doing now but I didn't think it was possible to select CONFIG_SYSCTL and CONFIG_PROCFS without CONFIG_PROC_SYSCTL being selected... Do we have a constraint problem in Kconfig? Or am I misremembering things? fs/built-in.o: In function `proc_root_init': /usr/src/linux/fs/proc/root.c:83: undefined reference to `proc_sys_init' Fix that up and remove an ifdef-in-C. Cc: Eric W. Biederman [EMAIL PROTECTED] Cc: Helge Hafting [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2 - compile error on x86-64
On Thu, 29 Mar 2007 16:10:50 -0600 Eric W. Biederman wrote: Andrew Morton [EMAIL PROTECTED] writes: Ah. I assume you have CONFIG_SYSCTL=y, CONFIG_PROC_SYSCTL=n? From: Andrew Morton [EMAIL PROTECTED] We're using #ifdef CONFIG_SYSCTL, but we should be using CONFIG_PROC_SYSCTL, so we get I have no problem with the patch it is clearly more correct than what we are doing now but I didn't think it was possible to select CONFIG_SYSCTL and CONFIG_PROCFS without CONFIG_PROC_SYSCTL being selected... Do we have a constraint problem in Kconfig? Or am I misremembering things? Hi Eric, Looks like you are just misremembering things... fs/built-in.o: In function `proc_root_init': /usr/src/linux/fs/proc/root.c:83: undefined reference to `proc_sys_init' Fix that up and remove an ifdef-in-C. Cc: Eric W. Biederman [EMAIL PROTECTED] Cc: Helge Hafting [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2 -- ACPI problems (lid switch broken, always shows running from AC, plugging in AC hangs machine)
Added: http://bugzilla.kernel.org/show_bug.cgi?id=8283 I am going to double-check with vanilla 2.6.21-rc5 and make sure none of the problems are happening there. Miles - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2 -- ACPI problems (lid switch broken, always shows running from AC, plugging in AC hangs machine)
Hmm. I've reproduced these problems with vanilla 2.6.21-rc5, so the latest acpi-git changes are off the hook. I am currently trying to reproduce the problems with 2.6.21-rc4. I'll let you know how it turns out. Miles - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2 - compile error on x86-64
Andrew Morton [EMAIL PROTECTED] writes: config PROC_SYSCTL bool Sysctl support (/proc/sys) if EMBEDDED depends on PROC_FS select SYSCTL default y CONFIG_PROC_SYSCTL depends on CONFIG_PROC_FS CONFIG_PROC_SYSCTL selects CONFIG_SYSCTL So I don't see anything preventing CONFIG_SYSCTL=y, CONFIG_PROC_FS=y, CONFIG_PROC_SYSCTL=n. I assume we can make this combination compile, link and run easily enough. I dunno if it makes any actual sense though? I'd have thought that PROC_SYSCTL should just depend on SYSCTL. But SYSCTL's Kconfig setup is weird. Yes. My memory is now coming back. I did a few weird things in there when I was making the binary interface optional, and it looks like I never updated the #ifdef in fs/proc/root.c The primary intent was to allow the proc support without the binary interface but I guess the other configuration makes some sense as well in an embedded scenario when you are trying to be as efficient as possible. As I recall the binary interface is less resource intensive then the /proc interface. Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [FIXED] Re: tty OOPS (Re: 2.6.21-rc5-mm2)
Apologies -- I didn't notice lkml on the cc list. I'll catch up from lkml directly. -- Ethan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2 -- ACPI problems (lid switch broken, always shows running from AC, plugging in AC hangs machine)
On Wed, 28 Mar 2007 13:55:54 -0700 "Miles Lane" <[EMAIL PROTECTED]> wrote: > My laptop (HP dv1240us) is always showing that my laptop is plugged > into AC power, even when it is running off of the battery. When I > plug into the AC after running on the battery, the machine immediately > locks up. Also, the laptop lid button isn't working -- pressing it > doesn't trigger a suspend. OK, thanks. If you have time, could you please test 2.6.21-rc5 + ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/origin.patch + ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/git-acpi.patch which will allow us to eliminate any non-acpi patches. And please keep an eye on these bugs for us, don't let us merge these problems into 2.6.22. It is bad of us to allow known failures to propagate into mainline and it has happened a couple of times in recent months. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [FIXED] Re: tty OOPS (Re: 2.6.21-rc5-mm2)
Andreas Mohr wrote: Hi, On Wed, Mar 28, 2007 at 10:56:32PM +0400, Alexey Dobriyan wrote: The only suspicious new patch in -rc5-mm1 to me is fix-sysfs-reclaim-crash.patch which removes "sd->s_dentry = NULL;". Note that whole sysfs_drop_dentry() is NOP if ->s_dentry is NULL. Could you try to revert it? Alexey, who knows very little about sysfs internals Apparently that's still too much knowledge ;) Or, in other words: 6 reboots already and not a single problem! So yes, the removal of the NULLing line in this patch most likely has caused this issue on my box. Now the question is whether something as simple as that is a fully correct fix or whether something should be done entirely differently. I'll let people more familiar with those parts decide about it... Sorry -- I've only just been cc'd on this mail thread. Are we claiming that this patch/fix has caused a new problem, or successfully fixed an old problem? Thanks! -- Ethan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.21-rc5-mm2 -- ACPI problems (lid switch broken, always shows running from AC, plugging in AC hangs machine)
Hello, My laptop (HP dv1240us) is always showing that my laptop is plugged into AC power, even when it is running off of the battery. When I plug into the AC after running on the battery, the machine immediately locks up. Also, the laptop lid button isn't working -- pressing it doesn't trigger a suspend. # # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_PM_LEGACY is not set # CONFIG_PM_DEBUG is not set # CONFIG_PM_SYSFS_DEPRECATED is not set CONFIG_SOFTWARE_SUSPEND=y CONFIG_PM_STD_PARTITION="" # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y # CONFIG_ACPI_SLEEP_PROC_SLEEP is not set # CONFIG_ACPI_PROCFS is not set CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=m CONFIG_ACPI_DOCK=m # CONFIG_ACPI_BAY is not set CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_THERMAL=m CONFIG_ACPI_ASUS=m CONFIG_ACPI_TOSHIBA=m CONFIG_ACPI_BLACKLIST_YEAR=2000 CONFIG_ACPI_DEBUG=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y CONFIG_ACPI_CONTAINER=m CONFIG_ACPI_SBS=m CONFIG_APM=m # CONFIG_APM_IGNORE_USER_SUSPEND is not set # CONFIG_APM_DO_ENABLE is not set # CONFIG_APM_CPU_IDLE is not set # CONFIG_APM_DISPLAY_BLANK is not set # CONFIG_APM_ALLOW_INTS is not set # CONFIG_APM_REAL_MODE_POWER_OFF is not set # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=m CONFIG_CPU_FREQ_DEBUG=y CONFIG_CPU_FREQ_STAT=m CONFIG_CPU_FREQ_STAT_DETAILS=y # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=m CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=m CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m # # CPUFreq processor drivers # CONFIG_X86_ACPI_CPUFREQ=m # CONFIG_X86_POWERNOW_K6 is not set # CONFIG_X86_POWERNOW_K7 is not set # CONFIG_X86_POWERNOW_K8 is not set # CONFIG_X86_GX_SUSPMOD is not set # CONFIG_X86_SPEEDSTEP_CENTRINO is not set CONFIG_X86_SPEEDSTEP_ICH=m CONFIG_X86_SPEEDSTEP_LIB=m CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK=y # # CPU idle PM support # # CONFIG_CPU_IDLE is not set [0.00] Linux version 2.6.21-rc5-mm2 ([EMAIL PROTECTED]) (gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)) #7 Wed Mar 28 10:55:43 PDT 2007 [0.00] BIOS-provided physical RAM map: [0.00] sanitize start [0.00] sanitize end [0.00] copy_e820_map() start: size: 0009f800 end: 0009f800 type: 1 [0.00] copy_e820_map() type is E820_RAM [0.00] copy_e820_map() start: 0009f800 size: 0800 end: 000a type: 2 [0.00] copy_e820_map() start: 000ce000 size: 2000 end: 000d type: 2 [0.00] copy_e820_map() start: 000dc000 size: 00024000 end: 0010 type: 2 [0.00] copy_e820_map() start: 0010 size: 3dde end: 3dee type: 1 [0.00] copy_e820_map() type is E820_RAM [0.00] copy_e820_map() start: 3dee size: c000 end: 3deec000 type: 3 [0.00] copy_e820_map() start: 3deec000 size: 00014000 end: 3df0 type: 4 [0.00] copy_e820_map() start: 3df0 size: 0210 end: 4000 type: 2 [0.00] copy_e820_map() start: fec0 size: 0001 end: fec1 type: 2 [0.00] copy_e820_map() start: fee0 size: 1000 end: fee01000 type: 2 [0.00] copy_e820_map() start: ff80 size: 0040 end: ffc0 type: 2 [0.00] copy_e820_map() start: fc00 size: 0400 end: 0001 type: 2 [0.00] BIOS-e820: - 0009f800 (usable) [0.00] BIOS-e820: 0009f800 - 000a (reserved) [0.00] BIOS-e820: 000ce000 - 000d (reserved) [0.00] BIOS-e820: 000dc000 - 0010 (reserved) [0.00] BIOS-e820: 0010 - 3dee (usable) [0.00] BIOS-e820: 3dee - 3deec000 (ACPI data) [0.00] BIOS-e820: 3deec000 - 3df0 (ACPI NVS) [0.00] BIOS-e820: 3df0 - 4000 (reserved) [0.00] BIOS-e820: fec0 - fec1 (reserved) [0.00] BIOS-e820: fee0 - fee01000 (reserved) [0.00] BIOS-e820: ff80 - ffc0 (reserved) [0.00] BIOS-e820: fc00 - 0001 (reserved) [0.00] 94MB HIGHMEM available. [0.00] 896MB LOWMEM available. [0.00] found SMP MP-table at 000f7e30 [0.00] Entering add_active_range(0, 0, 253664) 0 entries of 256 used [0.00] sizeof(struct page) = 32 [0.00] Zone PFN ranges: [0.000
Re: 2.6.21-rc5-mm2 OOPS and spinlock lockup
On Wed, 28 Mar 2007 14:20:16 -0600 Zan Lynx <[EMAIL PROTECTED]> wrote: > On Mon, 2007-03-26 at 21:16 -0800, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/ > > > > > > - This is the same as 2.6.12-rc5-mm1, except the staircase deadline CPU > > scheduler has been added. > > Here is the last bit of netconsole dump I had from my laptop when the > kernel died just now. > > Note that the kernel is compiled with SMP but the laptop is one core > only. I have CONFIG_DEBUG_SPINLOCK=y and CONFIG_DEBUG_SPINLOCK_SLEEP=y > > It's AMD-64. > > [ 2597.436421] Hangcheck: hangcheck value past margin! > [ 2794.356033] Unable to handle kernel NULL pointer dereference at > 00c0 RIP: > [ 2794.356058] [] _raw_spin_lock+0x1f/0x140 > [ 2794.356088] PGD 9f39067 PUD 9f38067 PMD 0 > [ 2794.356180] Oops: [1] PREEMPT SMP > [ 2794.356261] last sysfs file: > devices/system/cpu/cpu0/cpufreq/scaling_setspeed > [ 2794.356328] CPU 0 > [ 2794.356341] Modules linked in: netconsole nls_iso8859_1 nls_cp437 vfat fat > nls_base zaurus cdc_ether usbnet snd_pcm_oss snd_mixer_oss rfcomm hidp hid > l2cap ipv6 hci_usb bluetooth usb_storage snd_intel8x0 psmouse serio_raw > snd_ac97_codec ac97_bus snd_pcm snd_timer snd snd_page_alloc ehci_hcd > ohci_hcd ssb usbcore evdev sg > [ 2794.357227] Pid: 8049, comm: khidpd_046db3e1 Not tainted 2.6.21-rc5-mm2 #1 > [ 2794.357295] RIP: 0010:[] [] > _raw_spin_lock+0x1f/0x140 > [ 2794.357318] RSP: :81000d865d10 EFLAGS: 00010282 > [ 2794.357329] RAX: 81000d739040 RBX: 00b8 RCX: > > [ 2794.357396] RDX: RSI: RDI: > 00b8 > [ 2794.357408] RBP: 81000e23dd08 R08: 0002 R09: > > [ 2794.357422] R10: 80318019 R11: R12: > 81000e23dd10 > [ 2794.357435] R13: R14: 81000e16b928 R15: > 81000b518720 > [] _raw_spin_lock+0x1f/0x140 > [ 2794.359149] RSP > [ 2794.359214] CR2: 00c0 > [ 2794.359268] note: khidpd_046db3e1[8049] exited with preempt_count 3 > [ 2804.355026] BUG: soft lockup detected on CPU#0! > [ 2804.355037] > [ 2804.355039] Call Trace: > [ 2804.355051][] softlockup_tick+0xf9/0x140 > [ 2804.355140] [] update_process_times+0x57/0x90 > [ 2804.355157] [] smp_local_timer_interrupt+0x34/0x60 > [ 2804.355171] [] smp_send_timer_broadcast_ipi+0x3a/0x60 > [ 2804.355188] [] timer_interrupt+0x23/0x30 > [ 2804.355259] [] handle_IRQ_event+0x1e/0x60 > [ 2804.355275] [] handle_edge_irq+0xfa/0x150 > [ 2804.355291] [] do_IRQ+0x110/0x190 > [ 2804.355306] [] ret_from_intr+0x0/0xf > [ 2804.355371][] shrink_dcache_parent+0x2c/0x120 > [ 2804.355399] [] _raw_spin_lock+0xac/0x140 > [ 2804.355413] [] _raw_spin_lock+0xb9/0x140 > [ 2804.355484] [] shrink_dcache_parent+0x2c/0x120 > [ 2804.355499] [] proc_flush_task+0x76/0x220 > [ 2804.355518] [] release_task+0x316/0x360 > [ 2804.355532] [] do_wait+0x80f/0xc10 > [ 2804.355607] [] default_wake_function+0x0/0x10 > [ 2804.355624] [] system_call+0x7e/0x83 Thanks. This might have been caused by fix-sysfs-reclaim-crash.patch, which I have now dropped. If you're able to reproduce the crash, please see if reverting that patch (reproduced below) fixes it. If it isn't reproducibl, please keep an eye out for problems in next -mm. From: Maneesh Soni <[EMAIL PROTECTED]> Maybe. happens without i_mutex. It also nullifies s_dentry just to indicate that the associated dentry is evicted. sysfs_readdir() access the s_dentry, and gets the inode number from the associated dentry, if there is one, else it invokes iunique(). This can create a race situation, and crash while accessing the dentry/inode in sysfs_readdir(). o The following patch always use i_unique() to get the inode number. This is ok as sysfs doesnot have permanent inode numbering. It could be slower but avoids the above mentioned race. o This also avoids the now unnecessary s_dentry in sysfs_d_iput(). Signed-off-by: Maneesh Soni <[EMAIL PROTECTED]> Cc: Ethan Solomita <[EMAIL PROTECTED]> Cc: Dipankar Sarma <[EMAIL PROTECTED]> Cc: Greg KH <[EMAIL PROTECTED]> Cc: Martin Bligh <[EMAIL PROTECTED]> Cc: Rohit Seth <[EMAIL PROTECTED]> Cc: Al Viro <[EMAIL PROTECTED]> Cc: Christoph Hellwig <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- fs/sysfs/dir.c |6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff -puN fs/sysfs/dir.c~fix-sysfs-reclaim-crash fs/sysfs/dir.c --- a/fs/sysfs/dir.c~fix-sysfs-reclaim-crash +++ a/fs/sysfs/dir.c @@ -20,7 +20,6 @@ static void sysfs_d_iput(struct dentry *
Re: 2.6.21-rc5-mm2 OOPS and spinlock lockup
On Mon, 2007-03-26 at 21:16 -0800, Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/ > > > - This is the same as 2.6.12-rc5-mm1, except the staircase deadline CPU > scheduler has been added. Here is the last bit of netconsole dump I had from my laptop when the kernel died just now. Note that the kernel is compiled with SMP but the laptop is one core only. I have CONFIG_DEBUG_SPINLOCK=y and CONFIG_DEBUG_SPINLOCK_SLEEP=y It's AMD-64. [ 2597.436421] Hangcheck: hangcheck value past margin! [ 2794.356033] Unable to handle kernel NULL pointer dereference at 00c0 RIP: [ 2794.356058] [] _raw_spin_lock+0x1f/0x140 [ 2794.356088] PGD 9f39067 PUD 9f38067 PMD 0 [ 2794.356180] Oops: [1] PREEMPT SMP [ 2794.356261] last sysfs file: devices/system/cpu/cpu0/cpufreq/scaling_setspeed [ 2794.356328] CPU 0 [ 2794.356341] Modules linked in: netconsole nls_iso8859_1 nls_cp437 vfat fat nls_base zaurus cdc_ether usbnet snd_pcm_oss snd_mixer_oss rfcomm hidp hid l2cap ipv6 hci_usb bluetooth usb_storage snd_intel8x0 psmouse serio_raw snd_ac97_codec ac97_bus snd_pcm snd_timer snd snd_page_alloc ehci_hcd ohci_hcd ssb usbcore evdev sg [ 2794.357227] Pid: 8049, comm: khidpd_046db3e1 Not tainted 2.6.21-rc5-mm2 #1 [ 2794.357295] RIP: 0010:[] [] _raw_spin_lock+0x1f/0x140 [ 2794.357318] RSP: :81000d865d10 EFLAGS: 00010282 [ 2794.357329] RAX: 81000d739040 RBX: 00b8 RCX: [ 2794.357396] RDX: RSI: RDI: 00b8 [ 2794.357408] RBP: 81000e23dd08 R08: 0002 R09: [ 2794.357422] R10: 80318019 R11: R12: 81000e23dd10 [ 2794.357435] R13: R14: 81000e16b928 R15: 81000b518720 [] _raw_spin_lock+0x1f/0x140 [ 2794.359149] RSP [ 2794.359214] CR2: 00c0 [ 2794.359268] note: khidpd_046db3e1[8049] exited with preempt_count 3 [ 2804.355026] BUG: soft lockup detected on CPU#0! [ 2804.355037] [ 2804.355039] Call Trace: [ 2804.355051][] softlockup_tick+0xf9/0x140 [ 2804.355140] [] update_process_times+0x57/0x90 [ 2804.355157] [] smp_local_timer_interrupt+0x34/0x60 [ 2804.355171] [] smp_send_timer_broadcast_ipi+0x3a/0x60 [ 2804.355188] [] timer_interrupt+0x23/0x30 [ 2804.355259] [] handle_IRQ_event+0x1e/0x60 [ 2804.355275] [] handle_edge_irq+0xfa/0x150 [ 2804.355291] [] do_IRQ+0x110/0x190 [ 2804.355306] [] ret_from_intr+0x0/0xf [ 2804.355371][] shrink_dcache_parent+0x2c/0x120 [ 2804.355399] [] _raw_spin_lock+0xac/0x140 [ 2804.355413] [] _raw_spin_lock+0xb9/0x140 [ 2804.355484] [] shrink_dcache_parent+0x2c/0x120 [ 2804.355499] [] proc_flush_task+0x76/0x220 [ 2804.355518] [] release_task+0x316/0x360 [ 2804.355532] [] do_wait+0x80f/0xc10 [ 2804.355607] [] default_wake_function+0x0/0x10 [ 2804.355624] [] system_call+0x7e/0x83 [ 2804.355639] [ 2804.355646] INFO: lockdep is turned off. [ 2821.783782] BUG: spinlock lockup on CPU#0, init/1, 806b0e00 [ 2821.783793] [ 2821.783794] Call Trace: [ 2821.783830] [] _raw_spin_lock+0xfa/0x140 [ 2821.783845] [] shrink_dcache_parent+0x2c/0x120 [ 2821.783866] [] proc_flush_task+0x76/0x220 [ 2821.783895] [] release_task+0x316/0x360 [ 2821.783910] [] do_wait+0x80f/0xc10 [ 2821.783939] [] default_wake_function+0x0/0x10 [ 2821.783956] [] system_call+0x7e/0x83 [ 2821.783983] [ 2821.783989] INFO: lockdep is turned off. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
[FIXED] Re: tty OOPS (Re: 2.6.21-rc5-mm2)
Hi, On Wed, Mar 28, 2007 at 10:56:32PM +0400, Alexey Dobriyan wrote: > The only suspicious new patch in -rc5-mm1 to me is > fix-sysfs-reclaim-crash.patch which removes "sd->s_dentry = NULL;". Note > that whole sysfs_drop_dentry() is NOP if ->s_dentry is NULL. > > Could you try to revert it? > > Alexey, who knows very little about sysfs internals Apparently that's still too much knowledge ;) Or, in other words: 6 reboots already and not a single problem! So yes, the removal of the NULLing line in this patch most likely has caused this issue on my box. Now the question is whether something as simple as that is a fully correct fix or whether something should be done entirely differently. I'll let people more familiar with those parts decide about it... Thanks! Andreas Mohr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tty OOPS (Re: 2.6.21-rc5-mm2)
On Wed, 28 Mar 2007 22:56:32 +0400 Alexey Dobriyan <[EMAIL PROTECTED]> wrote: > On Wed, Mar 28, 2007 at 10:38:14PM +0400, Alexey Dobriyan wrote: > > On Wed, Mar 28, 2007 at 08:04:46PM +0200, Andreas Mohr wrote: > > > [unrelated maintainers removed, Alexey added] > > > > > > On Wed, Mar 28, 2007 at 07:45:24PM +0200, Andreas Mohr wrote: > > > > Hi, > > > > > > > > just wanted to add that when analyzing the backtrace I found the comment > > > > at drivers/char/vt.c/con_close() to be VERY suspicious... > > > > (need to take tty_mutex to prevent concurrent thread tty access). > > > > This might just be what happened here despite trying to protect against > > > > it. > > > > > > OK, can we assume that one of > > > > > > +protect-tty-drivers-list-with-tty_mutex.patch > > > +tty-minor-merge-correction.patch > > > +tty-in-tiocsctty-when-we-steal-a-tty-hang-it-up-fix.patch > > > > > > is responsible / not implemented fully? > > > > #2 is just comment removal. > > > > I may state the obvious, but __iget() in sysfs_drop_dentry() gets NULL > > inode and you aren't failing on spin_lock one line above because of UP > > without spinlock debugging. > > The only suspicious new patch in -rc5-mm1 to me is > fix-sysfs-reclaim-crash.patch which removes "sd->s_dentry = NULL;". Note > that whole sysfs_drop_dentry() is NOP if ->s_dentry is NULL. > > Could you try to revert it? > > Alexey, who knows very little about sysfs internals cc's added. Also added is the sad little missive I sent to the USB guys last night, which is similar-looking: Begin forwarded message: Date: Wed, 28 Mar 2007 00:34:45 -0700 From: Andrew Morton <[EMAIL PROTECTED]> To: linux-usb-devel@lists.sourceforge.net Subject: usb/sysfs oops in 2.6.21-rc5-mm1 I think the connector wasn't pushed in terribly well, so there might have been some contact bounce. [15813.836000] ipw2200: Firmware error detected. Restarting. [17200.268000] hub 2-0:1.0: port 1 disabled by hub (EMI?), re-enabling... [17200.268000] usb 2-1: USB disconnect, address 4 [17200.268000] BUG: unable to handle kernel NULL pointer dereference at virtual address 0024 [17200.268000] printing eip: [17200.268000] c016e447 [17200.268000] *pde = [17200.268000] Oops: [#1] [17200.268000] last sysfs file: block/sr0/size [17200.268000] Modules linked in: udf i915 drm ipw2200 sonypi ipv6 autofs4 hidp l2cap sunrpc nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables cpufreq_ondemand video sbs button battery asus_acpi ac nvram hci_usb bluetooth ieee80211 ohci1394 ieee1394 joydev ieee80211_crypt snd_hda_intel snd_hda_codec ehci_hcd uhci_hcd sg snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd sr_mod cdrom piix soundcore i2c_i801 snd_page_alloc i2c_core pcspkr generic ext3 jbd ide_disk ide_core [17200.268000] CPU:0 [17200.268000] EIP:0060:[]Not tainted VLI [17200.268000] EFLAGS: 00010246 (2.6.21-rc5-mm1 #1) [17200.268000] EIP is at __iget+0x3/0x48 [17200.268000] eax: ebx: ecx: edx: c8a90514 [17200.268000] esi: c8a90514 edi: ebp: c8cea5e4 esp: c210fe5c [17200.268000] ds: 007b es: 007b fs: 00d8 gs: ss: 0068 [17200.268000] Process khubd (pid: 155, ti=c210e000 task=c209b6f0 task.ti=c210e000) [17200.268000] Stack: c2493a14 c0192933 c8cea5e8 c0338373 c0338373 c8cea5e4 c0192a90 c889ba24 [17200.268000]c033836f c8a90514 c8cea58c c889ba08 c8556a40 df8918c0 c24e6418 c0230d46 [17200.268000]c889ba08 c889ba08 c0230dd8 c889ba08 c889ba00 df8918c0 c24e6418 c0230ffa [17200.268000] Call Trace: [17200.268000] [] sysfs_drop_dentry+0x2b/0xc3 [17200.268000] [] sysfs_hash_and_remove+0x86/0x12c [17200.268000] [] device_remove_file+0x19/0x25 [17200.268000] [] device_del+0x26/0x240 [17200.268000] [] device_unregister+0x8/0x10 [17200.268000] [] usb_remove_ep_files+0x4d/0x60 [17200.268000] [] usb_new_device+0x199/0x1ab [17200.268000] [] usb_remove_sysfs_intf_files+0x1e/0x43 [17200.268000] [] usb_disable_device+0x55/0xbb [17200.268000] [] usb_disconnect+0x87/0x100 [17200.268000] [] hub_thread+0x361/0xa70 [17200.268000] [] d_lookup+0x16/0x31 [17200.268000] [] __wake_up_common+0x31/0x4f [17200.268000] [] autoremove_wake_function+0x0/0x35 [17200.268000] [] hub_thread+0x0/0xa70 [17200.268000] [] kthread+0xa0/0xc9 [17200.268000] [] kthread+0x0/0xc9 [17200.268000] [] kernel_thread_helper+0x7/0x10 [17200.268000] === [17200.268000] Code: 00 00 00 89 d8 81 ce 00 02 00 00 e8 3e ba 01 00 8b 43 20 31 c9 89 f2 89 04 24 89 d8 e8 19 25 01 00 58 5b 5e c3 90 90 90 53 89 c3 <83> 78 24 00 74 05 ff 40 24 eb 38 ff 40 24 f6 80 2c 01 00 00 0f [17200.268000] EIP: [] __iget+0x3/0x48 SS:ESP 0068:c210fe5c [17327.844000] ipw2200: Firmware error detected. Restarting. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the
Re: tty OOPS (Re: 2.6.21-rc5-mm2)
On Wed, Mar 28, 2007 at 10:38:14PM +0400, Alexey Dobriyan wrote: > On Wed, Mar 28, 2007 at 08:04:46PM +0200, Andreas Mohr wrote: > > [unrelated maintainers removed, Alexey added] > > > > On Wed, Mar 28, 2007 at 07:45:24PM +0200, Andreas Mohr wrote: > > > Hi, > > > > > > just wanted to add that when analyzing the backtrace I found the comment > > > at drivers/char/vt.c/con_close() to be VERY suspicious... > > > (need to take tty_mutex to prevent concurrent thread tty access). > > > This might just be what happened here despite trying to protect against > > > it. > > > > OK, can we assume that one of > > > > +protect-tty-drivers-list-with-tty_mutex.patch > > +tty-minor-merge-correction.patch > > +tty-in-tiocsctty-when-we-steal-a-tty-hang-it-up-fix.patch > > > > is responsible / not implemented fully? > > #2 is just comment removal. > > I may state the obvious, but __iget() in sysfs_drop_dentry() gets NULL > inode and you aren't failing on spin_lock one line above because of UP > without spinlock debugging. The only suspicious new patch in -rc5-mm1 to me is fix-sysfs-reclaim-crash.patch which removes "sd->s_dentry = NULL;". Note that whole sysfs_drop_dentry() is NOP if ->s_dentry is NULL. Could you try to revert it? Alexey, who knows very little about sysfs internals - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tty OOPS (Re: 2.6.21-rc5-mm2)
On Wed, Mar 28, 2007 at 08:04:46PM +0200, Andreas Mohr wrote: > [unrelated maintainers removed, Alexey added] > > On Wed, Mar 28, 2007 at 07:45:24PM +0200, Andreas Mohr wrote: > > Hi, > > > > just wanted to add that when analyzing the backtrace I found the comment > > at drivers/char/vt.c/con_close() to be VERY suspicious... > > (need to take tty_mutex to prevent concurrent thread tty access). > > This might just be what happened here despite trying to protect against it. > > OK, can we assume that one of > > +protect-tty-drivers-list-with-tty_mutex.patch > +tty-minor-merge-correction.patch > +tty-in-tiocsctty-when-we-steal-a-tty-hang-it-up-fix.patch > > is responsible / not implemented fully? #2 is just comment removal. I may state the obvious, but __iget() in sysfs_drop_dentry() gets NULL inode and you aren't failing on spin_lock one line above because of UP without spinlock debugging. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
tty OOPS (Re: 2.6.21-rc5-mm2)
Hi, [unrelated maintainers removed, Alexey added] On Wed, Mar 28, 2007 at 07:45:24PM +0200, Andreas Mohr wrote: > Hi, > > just wanted to add that when analyzing the backtrace I found the comment > at drivers/char/vt.c/con_close() to be VERY suspicious... > (need to take tty_mutex to prevent concurrent thread tty access). > This might just be what happened here despite trying to protect against it. OK, can we assume that one of +protect-tty-drivers-list-with-tty_mutex.patch +tty-minor-merge-correction.patch +tty-in-tiocsctty-when-we-steal-a-tty-hang-it-up-fix.patch is responsible / not implemented fully? Andreas Mohr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.21-rc5-mm2
Patch attached here should fix the issue.
Thanks,
Venki
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of Christian
>Sent: Wednesday, March 28, 2007 10:42 AM
>To: linux-kernel@vger.kernel.org
>Subject: Re: 2.6.21-rc5-mm2
>
>Hello lkml!
>
>I have a problem with the new cpuidle infrastructure. My
>system locks up hard
>on bootup with the message ACPI cpuidle could not initialize
>cpu0 and cpu1.
>When I deselect cpuidle in the kernel config everything works
>fine again.
>My system is AMD64 X2 with NForce4 chipset.
>
>-Christian
>-
>To unsubscribe from this list: send the line "unsubscribe
>linux-kernel" in
>the body of a message to [EMAIL PROTECTED]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
--- Begin Message ---
From: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Patch for cpuidle boot hang reported by Larry Finger here.
http://www.ussg.iu.edu/hypermail/linux/kernel/0703.2/2025.html
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Cc: Len Brown <[EMAIL PROTECTED]>
Cc: Larry Finger <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/cpuidle/cpuidle.c | 26 +++---
drivers/cpuidle/driver.c |4 ++--
2 files changed, 21 insertions(+), 9 deletions(-)
diff -puN drivers/cpuidle/cpuidle.c~cpuidle-fix-boot-hang
drivers/cpuidle/cpuidle.c
--- a/drivers/cpuidle/cpuidle.c~cpuidle-fix-boot-hang
+++ a/drivers/cpuidle/cpuidle.c
@@ -119,6 +119,7 @@ static int cpuidle_add_device(struct sys
dev = _cpu(cpuidle_devices, cpu);
+ dev->cpu = cpu;
mutex_lock(_lock);
if (cpu_is_offline(cpu)) {
mutex_unlock(_lock);
@@ -129,15 +130,26 @@ static int cpuidle_add_device(struct sys
mutex_unlock(_lock);
return 0;
}
- dev->status |= CPUIDLE_STATUS_DETECTED;
- list_add(>device_list, _detected_devices);
- cpuidle_add_sysfs(sys_dev);
- if (cpuidle_curr_driver)
- cpuidle_attach_driver(dev);
- if (cpuidle_curr_governor)
- cpuidle_attach_governor(dev);
+ if (cpuidle_curr_driver) {
+ if (cpuidle_attach_driver(dev))
+ goto err_ret;
+ }
+
+ if (cpuidle_curr_governor) {
+ if (cpuidle_attach_governor(dev)) {
+ cpuidle_detach_driver(dev);
+ goto err_ret;
+ }
+ }
+
if (cpuidle_device_can_idle(dev))
cpuidle_install_idle_handler();
+
+ list_add(>device_list, _detected_devices);
+ cpuidle_add_sysfs(sys_dev);
+ dev->status |= CPUIDLE_STATUS_DETECTED;
+
+err_ret:
mutex_unlock(_lock);
return 0;
diff -puN drivers/cpuidle/driver.c~cpuidle-fix-boot-hang
drivers/cpuidle/driver.c
--- a/drivers/cpuidle/driver.c~cpuidle-fix-boot-hang
+++ a/drivers/cpuidle/driver.c
@@ -37,8 +37,8 @@ int cpuidle_attach_driver(struct cpuidle
ret = cpuidle_curr_driver->init(dev);
if (ret) {
module_put(cpuidle_curr_driver->owner);
- printk(KERN_ERR "cpuidle: driver %s failed to attach to cpu
%d\n",
- cpuidle_curr_driver->name, dev->cpu);
+ printk(KERN_INFO "cpuidle: driver %s failed to attach to "
+ "cpu %d\n", cpuidle_curr_driver->name, dev->cpu);
} else {
if (dev->status & CPUIDLE_STATUS_GOVERNOR_ATTACHED)
cpuidle_rescan_device(dev);
_
--- End Message ---
Re: 2.6.21-rc5-mm2
Hello lkml! I have a problem with the new cpuidle infrastructure. My system locks up hard on bootup with the message ACPI cpuidle could not initialize cpu0 and cpu1. When I deselect cpuidle in the kernel config everything works fine again. My system is AMD64 X2 with NForce4 chipset. -Christian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2
Hi, just wanted to add that when analyzing the backtrace I found the comment at drivers/char/vt.c/con_close() to be VERY suspicious... (need to take tty_mutex to prevent concurrent thread tty access). This might just be what happened here despite trying to protect against it. Andreas Mohr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2
On Mon, 2007-03-26 at 21:16 -0800, Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/ > > > - This is the same as 2.6.12-rc5-mm1, except the staircase deadline CPU > scheduler has been added. Booted fine on my x86-64 and ppc64 machines. Both failed to boot 2.6.21-rc4-mm1. Thanks, Badari - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2
Hi, On Wed, Mar 28, 2007 at 07:02:14PM +0200, Andreas Mohr wrote: > Hi, > > On Mon, Mar 26, 2007 at 09:16:27PM -0800, Andrew Morton wrote: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/ > > > > > > - This is the same as 2.6.12-rc5-mm1, except the staircase deadline CPU > > scheduler has been added. > > OOPS (hand-pasted), happens on roughly 85% of bootups, didn't seem to > occur during my several previous 2.6.21-rc4-mm1 bootups: Still happens after having added just-published RSDL fixup patch and reinstalled resulting kernel package. .config diff between -rc4-mm1 and -rc5-mm1 is negligible. Interesting items in current .config: CONFIG_SWAP_PREFETCH=y CONFIG_SYSFS_DEPRECATED=y CONFIG_RT_MUTEXES=y CONFIG_TICK_ONESHOT=y CONFIG_HIGH_RES_TIMERS=y CONFIG_PREEMPT_VOLUNTARY=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_ADAPTIVE_READAHEAD=y CONFIG_HZ=250 CONFIG_X86_PM_TIMER=y # CONFIG_CPU_IDLE is not set CONFIG_PNP=y CONFIG_PNPACPI=y CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_IDEACPI=y CONFIG_RTC=y Thanks, Andreas Mohr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2
Hi, On Mon, Mar 26, 2007 at 09:16:27PM -0800, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/ > > > - This is the same as 2.6.12-rc5-mm1, except the staircase deadline CPU > scheduler has been added. OOPS (hand-pasted), happens on roughly 85% of bootups, didn't seem to occur during my several previous 2.6.21-rc4-mm1 bootups: - ... Setting up ICE socket directory /tmp/.ICE-unix...done. BUG: unable to handle kernel NULL pointer dereference at virtual address 0024 ! ==> last sysfs file: block/loop7/removable <=== Process init trace: show_trace_log_lvl+0x1a show_stack_log_lvl+0x9d show_registers+0x1c0 die+0xe5 do_page_fault+0x432 error_code+0x71 sysfs_drop_dentry+0x30 sysfs_hash_and_remove+0x8e sysfs_remove_file+0xd device_remove_file+0x1c device_del+0x1ed device_unregister+0x26 device_destroy+0x8a vcs_remove_sysfs+0x1a con_close+0x4c release_dev+0x1f0 tty_release+0xa __fput+0xb8 fput+0x31 filp_close+0x54 put_files_struct+0x7c do_exit+0x1e3 sys_exit_group+0x0 sys_exit_group+0xf syscall_call+0x7 EIP: __iget+0x6 Fixing recursive fault but reboot is needed! - Any hints? Possibly existing bug surfaced due to RSDL scheduling timing differences? I did NOT test -mm1 to check this. P3/700 UP i815 IDE ext3, Debian unstable. Further .config available on request. Note that something killed my /bin/run-parts (Debian) and S10portmap files (and possibly some others are corrupted??), so it might be something fishy (but this fishiness could also have uncovered this OOPS, so...). Restoring those files didn't change the status quo. CC'd relevant maintainers/recent submitters. Andreas Mohr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.21-rc5-mm2] add compile.h dependency for missing_syscalls.o in init/Makefile
On Wed, Mar 28, 2007 at 11:56:01AM -0400, Lee Schermerhorn wrote: > PATCH 2.6.21-rc5-mm2: add compile.h dependency for missing_syscalls.o > > Add a dependency on include/linux/compile.h to missing_syscalls.o > target in init/Makefile. Without this, [ia64] build fails with: > > init/missing_syscalls.c:5:27: error: linux/compile.h: No such file or > directory > In file included from init/missing_syscalls.c:97: Thanks. But in the end I made another solution that avoids the compile.h dependency. It is kbuild.git and will appear in next -mm. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.21-rc5-mm2] add compile.h dependency for missing_syscalls.o in init/Makefile
PATCH 2.6.21-rc5-mm2: add compile.h dependency for missing_syscalls.o Add a dependency on include/linux/compile.h to missing_syscalls.o target in init/Makefile. Without this, [ia64] build fails with: init/missing_syscalls.c:5:27: error: linux/compile.h: No such file or directory In file included from init/missing_syscalls.c:97: Signed-off-by: Lee Schermerhorn <[EMAIL PROTECTED]> init/Makefile |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: Linux/init/Makefile === --- Linux.orig/init/Makefile2007-03-28 10:44:14.0 -0400 +++ Linux/init/Makefile 2007-03-28 11:02:59.0 -0400 @@ -21,7 +21,7 @@ clean-files := ../include/linux/compile. # dependencies on generated files need to be listed explicitly $(obj)/version.o: include/linux/compile.h -$(obj)/missing_syscalls.o: $(obj)/missing_syscalls.h +$(obj)/missing_syscalls.o: $(obj)/missing_syscalls.h include/linux/compile.h # compile.h changes depending on hostname, generation number, etc, # so we regenerate it always. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.21-rc5-mm2] add compile.h dependency for missing_syscalls.o in init/Makefile
PATCH 2.6.21-rc5-mm2: add compile.h dependency for missing_syscalls.o Add a dependency on include/linux/compile.h to missing_syscalls.o target in init/Makefile. Without this, [ia64] build fails with: init/missing_syscalls.c:5:27: error: linux/compile.h: No such file or directory In file included from init/missing_syscalls.c:97: Signed-off-by: Lee Schermerhorn [EMAIL PROTECTED] init/Makefile |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: Linux/init/Makefile === --- Linux.orig/init/Makefile2007-03-28 10:44:14.0 -0400 +++ Linux/init/Makefile 2007-03-28 11:02:59.0 -0400 @@ -21,7 +21,7 @@ clean-files := ../include/linux/compile. # dependencies on generated files need to be listed explicitly $(obj)/version.o: include/linux/compile.h -$(obj)/missing_syscalls.o: $(obj)/missing_syscalls.h +$(obj)/missing_syscalls.o: $(obj)/missing_syscalls.h include/linux/compile.h # compile.h changes depending on hostname, generation number, etc, # so we regenerate it always. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.21-rc5-mm2] add compile.h dependency for missing_syscalls.o in init/Makefile
On Wed, Mar 28, 2007 at 11:56:01AM -0400, Lee Schermerhorn wrote: PATCH 2.6.21-rc5-mm2: add compile.h dependency for missing_syscalls.o Add a dependency on include/linux/compile.h to missing_syscalls.o target in init/Makefile. Without this, [ia64] build fails with: init/missing_syscalls.c:5:27: error: linux/compile.h: No such file or directory In file included from init/missing_syscalls.c:97: Thanks. But in the end I made another solution that avoids the compile.h dependency. It is kbuild.git and will appear in next -mm. Sam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2
Hi, On Mon, Mar 26, 2007 at 09:16:27PM -0800, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/ - This is the same as 2.6.12-rc5-mm1, except the staircase deadline CPU scheduler has been added. OOPS (hand-pasted), happens on roughly 85% of bootups, didn't seem to occur during my several previous 2.6.21-rc4-mm1 bootups: - ... Setting up ICE socket directory /tmp/.ICE-unix...done. BUG: unable to handle kernel NULL pointer dereference at virtual address 0024 ! == last sysfs file: block/loop7/removable === Process init trace: show_trace_log_lvl+0x1a show_stack_log_lvl+0x9d show_registers+0x1c0 die+0xe5 do_page_fault+0x432 error_code+0x71 sysfs_drop_dentry+0x30 sysfs_hash_and_remove+0x8e sysfs_remove_file+0xd device_remove_file+0x1c device_del+0x1ed device_unregister+0x26 device_destroy+0x8a vcs_remove_sysfs+0x1a con_close+0x4c release_dev+0x1f0 tty_release+0xa __fput+0xb8 fput+0x31 filp_close+0x54 put_files_struct+0x7c do_exit+0x1e3 sys_exit_group+0x0 sys_exit_group+0xf syscall_call+0x7 EIP: __iget+0x6 Fixing recursive fault but reboot is needed! - Any hints? Possibly existing bug surfaced due to RSDL scheduling timing differences? I did NOT test -mm1 to check this. P3/700 UP i815 IDE ext3, Debian unstable. Further .config available on request. Note that something killed my /bin/run-parts (Debian) and S10portmap files (and possibly some others are corrupted??), so it might be something fishy (but this fishiness could also have uncovered this OOPS, so...). Restoring those files didn't change the status quo. CC'd relevant maintainers/recent submitters. Andreas Mohr - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2
Hi, On Wed, Mar 28, 2007 at 07:02:14PM +0200, Andreas Mohr wrote: Hi, On Mon, Mar 26, 2007 at 09:16:27PM -0800, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/ - This is the same as 2.6.12-rc5-mm1, except the staircase deadline CPU scheduler has been added. OOPS (hand-pasted), happens on roughly 85% of bootups, didn't seem to occur during my several previous 2.6.21-rc4-mm1 bootups: Still happens after having added just-published RSDL fixup patch and reinstalled resulting kernel package. .config diff between -rc4-mm1 and -rc5-mm1 is negligible. Interesting items in current .config: CONFIG_SWAP_PREFETCH=y CONFIG_SYSFS_DEPRECATED=y CONFIG_RT_MUTEXES=y CONFIG_TICK_ONESHOT=y CONFIG_HIGH_RES_TIMERS=y CONFIG_PREEMPT_VOLUNTARY=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_ADAPTIVE_READAHEAD=y CONFIG_HZ=250 CONFIG_X86_PM_TIMER=y # CONFIG_CPU_IDLE is not set CONFIG_PNP=y CONFIG_PNPACPI=y CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_IDEACPI=y CONFIG_RTC=y Thanks, Andreas Mohr - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2
On Mon, 2007-03-26 at 21:16 -0800, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/ - This is the same as 2.6.12-rc5-mm1, except the staircase deadline CPU scheduler has been added. Booted fine on my x86-64 and ppc64 machines. Both failed to boot 2.6.21-rc4-mm1. Thanks, Badari - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2
Hi, just wanted to add that when analyzing the backtrace I found the comment at drivers/char/vt.c/con_close() to be VERY suspicious... (need to take tty_mutex to prevent concurrent thread tty access). This might just be what happened here despite trying to protect against it. Andreas Mohr - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2
Hello lkml! I have a problem with the new cpuidle infrastructure. My system locks up hard on bootup with the message ACPI cpuidle could not initialize cpu0 and cpu1. When I deselect cpuidle in the kernel config everything works fine again. My system is AMD64 X2 with NForce4 chipset. -Christian - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.21-rc5-mm2
Patch attached here should fix the issue.
Thanks,
Venki
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Christian
Sent: Wednesday, March 28, 2007 10:42 AM
To: linux-kernel@vger.kernel.org
Subject: Re: 2.6.21-rc5-mm2
Hello lkml!
I have a problem with the new cpuidle infrastructure. My
system locks up hard
on bootup with the message ACPI cpuidle could not initialize
cpu0 and cpu1.
When I deselect cpuidle in the kernel config everything works
fine again.
My system is AMD64 X2 with NForce4 chipset.
-Christian
-
To unsubscribe from this list: send the line unsubscribe
linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
---BeginMessage---
From: Venkatesh Pallipadi [EMAIL PROTECTED]
Patch for cpuidle boot hang reported by Larry Finger here.
http://www.ussg.iu.edu/hypermail/linux/kernel/0703.2/2025.html
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
Cc: Len Brown [EMAIL PROTECTED]
Cc: Larry Finger [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/cpuidle/cpuidle.c | 26 +++---
drivers/cpuidle/driver.c |4 ++--
2 files changed, 21 insertions(+), 9 deletions(-)
diff -puN drivers/cpuidle/cpuidle.c~cpuidle-fix-boot-hang
drivers/cpuidle/cpuidle.c
--- a/drivers/cpuidle/cpuidle.c~cpuidle-fix-boot-hang
+++ a/drivers/cpuidle/cpuidle.c
@@ -119,6 +119,7 @@ static int cpuidle_add_device(struct sys
dev = per_cpu(cpuidle_devices, cpu);
+ dev-cpu = cpu;
mutex_lock(cpuidle_lock);
if (cpu_is_offline(cpu)) {
mutex_unlock(cpuidle_lock);
@@ -129,15 +130,26 @@ static int cpuidle_add_device(struct sys
mutex_unlock(cpuidle_lock);
return 0;
}
- dev-status |= CPUIDLE_STATUS_DETECTED;
- list_add(dev-device_list, cpuidle_detected_devices);
- cpuidle_add_sysfs(sys_dev);
- if (cpuidle_curr_driver)
- cpuidle_attach_driver(dev);
- if (cpuidle_curr_governor)
- cpuidle_attach_governor(dev);
+ if (cpuidle_curr_driver) {
+ if (cpuidle_attach_driver(dev))
+ goto err_ret;
+ }
+
+ if (cpuidle_curr_governor) {
+ if (cpuidle_attach_governor(dev)) {
+ cpuidle_detach_driver(dev);
+ goto err_ret;
+ }
+ }
+
if (cpuidle_device_can_idle(dev))
cpuidle_install_idle_handler();
+
+ list_add(dev-device_list, cpuidle_detected_devices);
+ cpuidle_add_sysfs(sys_dev);
+ dev-status |= CPUIDLE_STATUS_DETECTED;
+
+err_ret:
mutex_unlock(cpuidle_lock);
return 0;
diff -puN drivers/cpuidle/driver.c~cpuidle-fix-boot-hang
drivers/cpuidle/driver.c
--- a/drivers/cpuidle/driver.c~cpuidle-fix-boot-hang
+++ a/drivers/cpuidle/driver.c
@@ -37,8 +37,8 @@ int cpuidle_attach_driver(struct cpuidle
ret = cpuidle_curr_driver-init(dev);
if (ret) {
module_put(cpuidle_curr_driver-owner);
- printk(KERN_ERR cpuidle: driver %s failed to attach to cpu
%d\n,
- cpuidle_curr_driver-name, dev-cpu);
+ printk(KERN_INFO cpuidle: driver %s failed to attach to
+ cpu %d\n, cpuidle_curr_driver-name, dev-cpu);
} else {
if (dev-status CPUIDLE_STATUS_GOVERNOR_ATTACHED)
cpuidle_rescan_device(dev);
_
---End Message---
tty OOPS (Re: 2.6.21-rc5-mm2)
Hi, [unrelated maintainers removed, Alexey added] On Wed, Mar 28, 2007 at 07:45:24PM +0200, Andreas Mohr wrote: Hi, just wanted to add that when analyzing the backtrace I found the comment at drivers/char/vt.c/con_close() to be VERY suspicious... (need to take tty_mutex to prevent concurrent thread tty access). This might just be what happened here despite trying to protect against it. OK, can we assume that one of +protect-tty-drivers-list-with-tty_mutex.patch +tty-minor-merge-correction.patch +tty-in-tiocsctty-when-we-steal-a-tty-hang-it-up-fix.patch is responsible / not implemented fully? Andreas Mohr - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tty OOPS (Re: 2.6.21-rc5-mm2)
On Wed, Mar 28, 2007 at 08:04:46PM +0200, Andreas Mohr wrote: [unrelated maintainers removed, Alexey added] On Wed, Mar 28, 2007 at 07:45:24PM +0200, Andreas Mohr wrote: Hi, just wanted to add that when analyzing the backtrace I found the comment at drivers/char/vt.c/con_close() to be VERY suspicious... (need to take tty_mutex to prevent concurrent thread tty access). This might just be what happened here despite trying to protect against it. OK, can we assume that one of +protect-tty-drivers-list-with-tty_mutex.patch +tty-minor-merge-correction.patch +tty-in-tiocsctty-when-we-steal-a-tty-hang-it-up-fix.patch is responsible / not implemented fully? #2 is just comment removal. I may state the obvious, but __iget() in sysfs_drop_dentry() gets NULL inode and you aren't failing on spin_lock one line above because of UP without spinlock debugging. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tty OOPS (Re: 2.6.21-rc5-mm2)
On Wed, Mar 28, 2007 at 10:38:14PM +0400, Alexey Dobriyan wrote: On Wed, Mar 28, 2007 at 08:04:46PM +0200, Andreas Mohr wrote: [unrelated maintainers removed, Alexey added] On Wed, Mar 28, 2007 at 07:45:24PM +0200, Andreas Mohr wrote: Hi, just wanted to add that when analyzing the backtrace I found the comment at drivers/char/vt.c/con_close() to be VERY suspicious... (need to take tty_mutex to prevent concurrent thread tty access). This might just be what happened here despite trying to protect against it. OK, can we assume that one of +protect-tty-drivers-list-with-tty_mutex.patch +tty-minor-merge-correction.patch +tty-in-tiocsctty-when-we-steal-a-tty-hang-it-up-fix.patch is responsible / not implemented fully? #2 is just comment removal. I may state the obvious, but __iget() in sysfs_drop_dentry() gets NULL inode and you aren't failing on spin_lock one line above because of UP without spinlock debugging. The only suspicious new patch in -rc5-mm1 to me is fix-sysfs-reclaim-crash.patch which removes sd-s_dentry = NULL;. Note that whole sysfs_drop_dentry() is NOP if -s_dentry is NULL. Could you try to revert it? Alexey, who knows very little about sysfs internals - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tty OOPS (Re: 2.6.21-rc5-mm2)
On Wed, 28 Mar 2007 22:56:32 +0400 Alexey Dobriyan [EMAIL PROTECTED] wrote: On Wed, Mar 28, 2007 at 10:38:14PM +0400, Alexey Dobriyan wrote: On Wed, Mar 28, 2007 at 08:04:46PM +0200, Andreas Mohr wrote: [unrelated maintainers removed, Alexey added] On Wed, Mar 28, 2007 at 07:45:24PM +0200, Andreas Mohr wrote: Hi, just wanted to add that when analyzing the backtrace I found the comment at drivers/char/vt.c/con_close() to be VERY suspicious... (need to take tty_mutex to prevent concurrent thread tty access). This might just be what happened here despite trying to protect against it. OK, can we assume that one of +protect-tty-drivers-list-with-tty_mutex.patch +tty-minor-merge-correction.patch +tty-in-tiocsctty-when-we-steal-a-tty-hang-it-up-fix.patch is responsible / not implemented fully? #2 is just comment removal. I may state the obvious, but __iget() in sysfs_drop_dentry() gets NULL inode and you aren't failing on spin_lock one line above because of UP without spinlock debugging. The only suspicious new patch in -rc5-mm1 to me is fix-sysfs-reclaim-crash.patch which removes sd-s_dentry = NULL;. Note that whole sysfs_drop_dentry() is NOP if -s_dentry is NULL. Could you try to revert it? Alexey, who knows very little about sysfs internals cc's added. Also added is the sad little missive I sent to the USB guys last night, which is similar-looking: Begin forwarded message: Date: Wed, 28 Mar 2007 00:34:45 -0700 From: Andrew Morton [EMAIL PROTECTED] To: linux-usb-devel@lists.sourceforge.net Subject: usb/sysfs oops in 2.6.21-rc5-mm1 I think the connector wasn't pushed in terribly well, so there might have been some contact bounce. [15813.836000] ipw2200: Firmware error detected. Restarting. [17200.268000] hub 2-0:1.0: port 1 disabled by hub (EMI?), re-enabling... [17200.268000] usb 2-1: USB disconnect, address 4 [17200.268000] BUG: unable to handle kernel NULL pointer dereference at virtual address 0024 [17200.268000] printing eip: [17200.268000] c016e447 [17200.268000] *pde = [17200.268000] Oops: [#1] [17200.268000] last sysfs file: block/sr0/size [17200.268000] Modules linked in: udf i915 drm ipw2200 sonypi ipv6 autofs4 hidp l2cap sunrpc nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables cpufreq_ondemand video sbs button battery asus_acpi ac nvram hci_usb bluetooth ieee80211 ohci1394 ieee1394 joydev ieee80211_crypt snd_hda_intel snd_hda_codec ehci_hcd uhci_hcd sg snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd sr_mod cdrom piix soundcore i2c_i801 snd_page_alloc i2c_core pcspkr generic ext3 jbd ide_disk ide_core [17200.268000] CPU:0 [17200.268000] EIP:0060:[c016e447]Not tainted VLI [17200.268000] EFLAGS: 00010246 (2.6.21-rc5-mm1 #1) [17200.268000] EIP is at __iget+0x3/0x48 [17200.268000] eax: ebx: ecx: edx: c8a90514 [17200.268000] esi: c8a90514 edi: ebp: c8cea5e4 esp: c210fe5c [17200.268000] ds: 007b es: 007b fs: 00d8 gs: ss: 0068 [17200.268000] Process khubd (pid: 155, ti=c210e000 task=c209b6f0 task.ti=c210e000) [17200.268000] Stack: c2493a14 c0192933 c8cea5e8 c0338373 c0338373 c8cea5e4 c0192a90 c889ba24 [17200.268000]c033836f c8a90514 c8cea58c c889ba08 c8556a40 df8918c0 c24e6418 c0230d46 [17200.268000]c889ba08 c889ba08 c0230dd8 c889ba08 c889ba00 df8918c0 c24e6418 c0230ffa [17200.268000] Call Trace: [17200.268000] [c0192933] sysfs_drop_dentry+0x2b/0xc3 [17200.268000] [c0192a90] sysfs_hash_and_remove+0x86/0x12c [17200.268000] [c0230d46] device_remove_file+0x19/0x25 [17200.268000] [c0230dd8] device_del+0x26/0x240 [17200.268000] [c0230ffa] device_unregister+0x8/0x10 [17200.268000] [c026739a] usb_remove_ep_files+0x4d/0x60 [17200.268000] [c0260031] usb_new_device+0x199/0x1ab [17200.268000] [c0266d14] usb_remove_sysfs_intf_files+0x1e/0x43 [17200.268000] [c026312d] usb_disable_device+0x55/0xbb [17200.268000] [c0260415] usb_disconnect+0x87/0x100 [17200.268000] [c0260842] hub_thread+0x361/0xa70 [17200.268000] [c016d394] d_lookup+0x16/0x31 [17200.268000] [c01174df] __wake_up_common+0x31/0x4f [17200.268000] [c0128754] autoremove_wake_function+0x0/0x35 [17200.268000] [c02604e1] hub_thread+0x0/0xa70 [17200.268000] [c01285f7] kthread+0xa0/0xc9 [17200.268000] [c0128557] kthread+0x0/0xc9 [17200.268000] [c010464f] kernel_thread_helper+0x7/0x10 [17200.268000] === [17200.268000] Code: 00 00 00 89 d8 81 ce 00 02 00 00 e8 3e ba 01 00 8b 43 20 31 c9 89 f2 89 04 24 89 d8 e8 19 25 01 00 58 5b 5e c3 90 90 90 53 89 c3 83 78 24 00 74 05 ff 40 24 eb 38 ff 40 24 f6 80 2c 01 00 00 0f [17200.268000] EIP: [c016e447] __iget+0x3/0x48 SS:ESP 0068:c210fe5c [17327.844000] ipw2200: Firmware error detected. Restarting. - To
[FIXED] Re: tty OOPS (Re: 2.6.21-rc5-mm2)
Hi, On Wed, Mar 28, 2007 at 10:56:32PM +0400, Alexey Dobriyan wrote: The only suspicious new patch in -rc5-mm1 to me is fix-sysfs-reclaim-crash.patch which removes sd-s_dentry = NULL;. Note that whole sysfs_drop_dentry() is NOP if -s_dentry is NULL. Could you try to revert it? Alexey, who knows very little about sysfs internals Apparently that's still too much knowledge ;) Or, in other words: 6 reboots already and not a single problem! So yes, the removal of the NULLing line in this patch most likely has caused this issue on my box. Now the question is whether something as simple as that is a fully correct fix or whether something should be done entirely differently. I'll let people more familiar with those parts decide about it... Thanks! Andreas Mohr - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2 OOPS and spinlock lockup
On Mon, 2007-03-26 at 21:16 -0800, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/ - This is the same as 2.6.12-rc5-mm1, except the staircase deadline CPU scheduler has been added. Here is the last bit of netconsole dump I had from my laptop when the kernel died just now. Note that the kernel is compiled with SMP but the laptop is one core only. I have CONFIG_DEBUG_SPINLOCK=y and CONFIG_DEBUG_SPINLOCK_SLEEP=y It's AMD-64. [ 2597.436421] Hangcheck: hangcheck value past margin! [ 2794.356033] Unable to handle kernel NULL pointer dereference at 00c0 RIP: [ 2794.356058] [8020761f] _raw_spin_lock+0x1f/0x140 [ 2794.356088] PGD 9f39067 PUD 9f38067 PMD 0 [ 2794.356180] Oops: [1] PREEMPT SMP [ 2794.356261] last sysfs file: devices/system/cpu/cpu0/cpufreq/scaling_setspeed [ 2794.356328] CPU 0 [ 2794.356341] Modules linked in: netconsole nls_iso8859_1 nls_cp437 vfat fat nls_base zaurus cdc_ether usbnet snd_pcm_oss snd_mixer_oss rfcomm hidp hid l2cap ipv6 hci_usb bluetooth usb_storage snd_intel8x0 psmouse serio_raw snd_ac97_codec ac97_bus snd_pcm snd_timer snd snd_page_alloc ehci_hcd ohci_hcd ssb usbcore evdev sg [ 2794.357227] Pid: 8049, comm: khidpd_046db3e1 Not tainted 2.6.21-rc5-mm2 #1 [ 2794.357295] RIP: 0010:[8020761f] [8020761f] _raw_spin_lock+0x1f/0x140 [ 2794.357318] RSP: :81000d865d10 EFLAGS: 00010282 [ 2794.357329] RAX: 81000d739040 RBX: 00b8 RCX: [ 2794.357396] RDX: RSI: RDI: 00b8 [ 2794.357408] RBP: 81000e23dd08 R08: 0002 R09: [ 2794.357422] R10: 80318019 R11: R12: 81000e23dd10 [ 2794.357435] R13: R14: 81000e16b928 R15: 81000b518720 [8020761f] _raw_spin_lock+0x1f/0x140 [ 2794.359149] RSP 81000d865d10 [ 2794.359214] CR2: 00c0 [ 2794.359268] note: khidpd_046db3e1[8049] exited with preempt_count 3 [ 2804.355026] BUG: soft lockup detected on CPU#0! [ 2804.355037] [ 2804.355039] Call Trace: [ 2804.355051] IRQ [802c7659] softlockup_tick+0xf9/0x140 [ 2804.355140] [8029ba37] update_process_times+0x57/0x90 [ 2804.355157] [8027b1e4] smp_local_timer_interrupt+0x34/0x60 [ 2804.355171] [8027b5ba] smp_send_timer_broadcast_ipi+0x3a/0x60 [ 2804.355188] [80271423] timer_interrupt+0x23/0x30 [ 2804.355259] [8020fe0e] handle_IRQ_event+0x1e/0x60 [ 2804.355275] [802c919a] handle_edge_irq+0xfa/0x150 [ 2804.355291] [80270180] do_IRQ+0x110/0x190 [ 2804.355306] [8025f666] ret_from_intr+0x0/0xf [ 2804.355371] EOI [8024e22c] shrink_dcache_parent+0x2c/0x120 [ 2804.355399] [802076ac] _raw_spin_lock+0xac/0x140 [ 2804.355413] [802076b9] _raw_spin_lock+0xb9/0x140 [ 2804.355484] [8024e22c] shrink_dcache_parent+0x2c/0x120 [ 2804.355499] [80312456] proc_flush_task+0x76/0x220 [ 2804.355518] [80216f56] release_task+0x316/0x360 [ 2804.355532] [8022796f] do_wait+0x80f/0xc10 [ 2804.355607] [80290d90] default_wake_function+0x0/0x10 [ 2804.355624] [8025f11e] system_call+0x7e/0x83 [ 2804.355639] [ 2804.355646] INFO: lockdep is turned off. [ 2821.783782] BUG: spinlock lockup on CPU#0, init/1, 806b0e00 [ 2821.783793] [ 2821.783794] Call Trace: [ 2821.783830] [802076fa] _raw_spin_lock+0xfa/0x140 [ 2821.783845] [8024e22c] shrink_dcache_parent+0x2c/0x120 [ 2821.783866] [80312456] proc_flush_task+0x76/0x220 [ 2821.783895] [80216f56] release_task+0x316/0x360 [ 2821.783910] [8022796f] do_wait+0x80f/0xc10 [ 2821.783939] [80290d90] default_wake_function+0x0/0x10 [ 2821.783956] [8025f11e] system_call+0x7e/0x83 [ 2821.783983] [ 2821.783989] INFO: lockdep is turned off. -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: 2.6.21-rc5-mm2 OOPS and spinlock lockup
On Wed, 28 Mar 2007 14:20:16 -0600 Zan Lynx [EMAIL PROTECTED] wrote: On Mon, 2007-03-26 at 21:16 -0800, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/ - This is the same as 2.6.12-rc5-mm1, except the staircase deadline CPU scheduler has been added. Here is the last bit of netconsole dump I had from my laptop when the kernel died just now. Note that the kernel is compiled with SMP but the laptop is one core only. I have CONFIG_DEBUG_SPINLOCK=y and CONFIG_DEBUG_SPINLOCK_SLEEP=y It's AMD-64. [ 2597.436421] Hangcheck: hangcheck value past margin! [ 2794.356033] Unable to handle kernel NULL pointer dereference at 00c0 RIP: [ 2794.356058] [8020761f] _raw_spin_lock+0x1f/0x140 [ 2794.356088] PGD 9f39067 PUD 9f38067 PMD 0 [ 2794.356180] Oops: [1] PREEMPT SMP [ 2794.356261] last sysfs file: devices/system/cpu/cpu0/cpufreq/scaling_setspeed [ 2794.356328] CPU 0 [ 2794.356341] Modules linked in: netconsole nls_iso8859_1 nls_cp437 vfat fat nls_base zaurus cdc_ether usbnet snd_pcm_oss snd_mixer_oss rfcomm hidp hid l2cap ipv6 hci_usb bluetooth usb_storage snd_intel8x0 psmouse serio_raw snd_ac97_codec ac97_bus snd_pcm snd_timer snd snd_page_alloc ehci_hcd ohci_hcd ssb usbcore evdev sg [ 2794.357227] Pid: 8049, comm: khidpd_046db3e1 Not tainted 2.6.21-rc5-mm2 #1 [ 2794.357295] RIP: 0010:[8020761f] [8020761f] _raw_spin_lock+0x1f/0x140 [ 2794.357318] RSP: :81000d865d10 EFLAGS: 00010282 [ 2794.357329] RAX: 81000d739040 RBX: 00b8 RCX: [ 2794.357396] RDX: RSI: RDI: 00b8 [ 2794.357408] RBP: 81000e23dd08 R08: 0002 R09: [ 2794.357422] R10: 80318019 R11: R12: 81000e23dd10 [ 2794.357435] R13: R14: 81000e16b928 R15: 81000b518720 [8020761f] _raw_spin_lock+0x1f/0x140 [ 2794.359149] RSP 81000d865d10 [ 2794.359214] CR2: 00c0 [ 2794.359268] note: khidpd_046db3e1[8049] exited with preempt_count 3 [ 2804.355026] BUG: soft lockup detected on CPU#0! [ 2804.355037] [ 2804.355039] Call Trace: [ 2804.355051] IRQ [802c7659] softlockup_tick+0xf9/0x140 [ 2804.355140] [8029ba37] update_process_times+0x57/0x90 [ 2804.355157] [8027b1e4] smp_local_timer_interrupt+0x34/0x60 [ 2804.355171] [8027b5ba] smp_send_timer_broadcast_ipi+0x3a/0x60 [ 2804.355188] [80271423] timer_interrupt+0x23/0x30 [ 2804.355259] [8020fe0e] handle_IRQ_event+0x1e/0x60 [ 2804.355275] [802c919a] handle_edge_irq+0xfa/0x150 [ 2804.355291] [80270180] do_IRQ+0x110/0x190 [ 2804.355306] [8025f666] ret_from_intr+0x0/0xf [ 2804.355371] EOI [8024e22c] shrink_dcache_parent+0x2c/0x120 [ 2804.355399] [802076ac] _raw_spin_lock+0xac/0x140 [ 2804.355413] [802076b9] _raw_spin_lock+0xb9/0x140 [ 2804.355484] [8024e22c] shrink_dcache_parent+0x2c/0x120 [ 2804.355499] [80312456] proc_flush_task+0x76/0x220 [ 2804.355518] [80216f56] release_task+0x316/0x360 [ 2804.355532] [8022796f] do_wait+0x80f/0xc10 [ 2804.355607] [80290d90] default_wake_function+0x0/0x10 [ 2804.355624] [8025f11e] system_call+0x7e/0x83 Thanks. This might have been caused by fix-sysfs-reclaim-crash.patch, which I have now dropped. If you're able to reproduce the crash, please see if reverting that patch (reproduced below) fixes it. If it isn't reproducibl, please keep an eye out for problems in next -mm. From: Maneesh Soni [EMAIL PROTECTED] Maybe. happens without i_mutex. It also nullifies s_dentry just to indicate that the associated dentry is evicted. sysfs_readdir() access the s_dentry, and gets the inode number from the associated dentry, if there is one, else it invokes iunique(). This can create a race situation, and crash while accessing the dentry/inode in sysfs_readdir(). o The following patch always use i_unique() to get the inode number. This is ok as sysfs doesnot have permanent inode numbering. It could be slower but avoids the above mentioned race. o This also avoids the now unnecessary s_dentry in sysfs_d_iput(). Signed-off-by: Maneesh Soni [EMAIL PROTECTED] Cc: Ethan Solomita [EMAIL PROTECTED] Cc: Dipankar Sarma [EMAIL PROTECTED] Cc: Greg KH [EMAIL PROTECTED] Cc: Martin Bligh [EMAIL PROTECTED] Cc: Rohit Seth [EMAIL PROTECTED] Cc: Al Viro [EMAIL PROTECTED] Cc: Christoph Hellwig [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- fs/sysfs/dir.c |6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff -puN fs/sysfs/dir.c~fix-sysfs-reclaim-crash fs/sysfs/dir.c --- a/fs/sysfs/dir.c~fix-sysfs-reclaim-crash +++ a/fs/sysfs/dir.c @@ -20,7 +20,6 @@ static void sysfs_d_iput(struct dentry * if (sd
2.6.21-rc5-mm2 -- ACPI problems (lid switch broken, always shows running from AC, plugging in AC hangs machine)
Hello, My laptop (HP dv1240us) is always showing that my laptop is plugged into AC power, even when it is running off of the battery. When I plug into the AC after running on the battery, the machine immediately locks up. Also, the laptop lid button isn't working -- pressing it doesn't trigger a suspend. # # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_PM_LEGACY is not set # CONFIG_PM_DEBUG is not set # CONFIG_PM_SYSFS_DEPRECATED is not set CONFIG_SOFTWARE_SUSPEND=y CONFIG_PM_STD_PARTITION= # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y # CONFIG_ACPI_SLEEP_PROC_SLEEP is not set # CONFIG_ACPI_PROCFS is not set CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=m CONFIG_ACPI_DOCK=m # CONFIG_ACPI_BAY is not set CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_THERMAL=m CONFIG_ACPI_ASUS=m CONFIG_ACPI_TOSHIBA=m CONFIG_ACPI_BLACKLIST_YEAR=2000 CONFIG_ACPI_DEBUG=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y CONFIG_ACPI_CONTAINER=m CONFIG_ACPI_SBS=m CONFIG_APM=m # CONFIG_APM_IGNORE_USER_SUSPEND is not set # CONFIG_APM_DO_ENABLE is not set # CONFIG_APM_CPU_IDLE is not set # CONFIG_APM_DISPLAY_BLANK is not set # CONFIG_APM_ALLOW_INTS is not set # CONFIG_APM_REAL_MODE_POWER_OFF is not set # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=m CONFIG_CPU_FREQ_DEBUG=y CONFIG_CPU_FREQ_STAT=m CONFIG_CPU_FREQ_STAT_DETAILS=y # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=m CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=m CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m # # CPUFreq processor drivers # CONFIG_X86_ACPI_CPUFREQ=m # CONFIG_X86_POWERNOW_K6 is not set # CONFIG_X86_POWERNOW_K7 is not set # CONFIG_X86_POWERNOW_K8 is not set # CONFIG_X86_GX_SUSPMOD is not set # CONFIG_X86_SPEEDSTEP_CENTRINO is not set CONFIG_X86_SPEEDSTEP_ICH=m CONFIG_X86_SPEEDSTEP_LIB=m CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK=y # # CPU idle PM support # # CONFIG_CPU_IDLE is not set [0.00] Linux version 2.6.21-rc5-mm2 ([EMAIL PROTECTED]) (gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)) #7 Wed Mar 28 10:55:43 PDT 2007 [0.00] BIOS-provided physical RAM map: [0.00] sanitize start [0.00] sanitize end [0.00] copy_e820_map() start: size: 0009f800 end: 0009f800 type: 1 [0.00] copy_e820_map() type is E820_RAM [0.00] copy_e820_map() start: 0009f800 size: 0800 end: 000a type: 2 [0.00] copy_e820_map() start: 000ce000 size: 2000 end: 000d type: 2 [0.00] copy_e820_map() start: 000dc000 size: 00024000 end: 0010 type: 2 [0.00] copy_e820_map() start: 0010 size: 3dde end: 3dee type: 1 [0.00] copy_e820_map() type is E820_RAM [0.00] copy_e820_map() start: 3dee size: c000 end: 3deec000 type: 3 [0.00] copy_e820_map() start: 3deec000 size: 00014000 end: 3df0 type: 4 [0.00] copy_e820_map() start: 3df0 size: 0210 end: 4000 type: 2 [0.00] copy_e820_map() start: fec0 size: 0001 end: fec1 type: 2 [0.00] copy_e820_map() start: fee0 size: 1000 end: fee01000 type: 2 [0.00] copy_e820_map() start: ff80 size: 0040 end: ffc0 type: 2 [0.00] copy_e820_map() start: fc00 size: 0400 end: 0001 type: 2 [0.00] BIOS-e820: - 0009f800 (usable) [0.00] BIOS-e820: 0009f800 - 000a (reserved) [0.00] BIOS-e820: 000ce000 - 000d (reserved) [0.00] BIOS-e820: 000dc000 - 0010 (reserved) [0.00] BIOS-e820: 0010 - 3dee (usable) [0.00] BIOS-e820: 3dee - 3deec000 (ACPI data) [0.00] BIOS-e820: 3deec000 - 3df0 (ACPI NVS) [0.00] BIOS-e820: 3df0 - 4000 (reserved) [0.00] BIOS-e820: fec0 - fec1 (reserved) [0.00] BIOS-e820: fee0 - fee01000 (reserved) [0.00] BIOS-e820: ff80 - ffc0 (reserved) [0.00] BIOS-e820: fc00 - 0001 (reserved) [0.00] 94MB HIGHMEM available. [0.00] 896MB LOWMEM available. [0.00] found SMP MP-table at 000f7e30 [0.00] Entering add_active_range(0, 0, 253664) 0 entries of 256 used [0.00] sizeof(struct page) = 32 [0.00] Zone PFN ranges: [0.00] DMA
Re: [FIXED] Re: tty OOPS (Re: 2.6.21-rc5-mm2)
Andreas Mohr wrote: Hi, On Wed, Mar 28, 2007 at 10:56:32PM +0400, Alexey Dobriyan wrote: The only suspicious new patch in -rc5-mm1 to me is fix-sysfs-reclaim-crash.patch which removes sd-s_dentry = NULL;. Note that whole sysfs_drop_dentry() is NOP if -s_dentry is NULL. Could you try to revert it? Alexey, who knows very little about sysfs internals Apparently that's still too much knowledge ;) Or, in other words: 6 reboots already and not a single problem! So yes, the removal of the NULLing line in this patch most likely has caused this issue on my box. Now the question is whether something as simple as that is a fully correct fix or whether something should be done entirely differently. I'll let people more familiar with those parts decide about it... Sorry -- I've only just been cc'd on this mail thread. Are we claiming that this patch/fix has caused a new problem, or successfully fixed an old problem? Thanks! -- Ethan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [FIXED] Re: tty OOPS (Re: 2.6.21-rc5-mm2)
Apologies -- I didn't notice lkml on the cc list. I'll catch up from lkml directly. -- Ethan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2 -- ACPI problems (lid switch broken, always shows running from AC, plugging in AC hangs machine)
On Wed, 28 Mar 2007 13:55:54 -0700 Miles Lane [EMAIL PROTECTED] wrote: My laptop (HP dv1240us) is always showing that my laptop is plugged into AC power, even when it is running off of the battery. When I plug into the AC after running on the battery, the machine immediately locks up. Also, the laptop lid button isn't working -- pressing it doesn't trigger a suspend. OK, thanks. If you have time, could you please test 2.6.21-rc5 + ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/origin.patch + ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/git-acpi.patch which will allow us to eliminate any non-acpi patches. And please keep an eye on these bugs for us, don't let us merge these problems into 2.6.22. It is bad of us to allow known failures to propagate into mainline and it has happened a couple of times in recent months. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2
On Mon, Mar 26, 2007 at 09:16:27PM -0800, Andrew Morton wrote: > - This is the same as 2.6.12-rc5-mm1, except the staircase deadline CPU > scheduler has been added. This boots without incident on the Altix I've got where prior versions of RSDL all had issues. Count RSDL as fixed here. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm2
On Mon, Mar 26, 2007 at 09:16:27PM -0800, Andrew Morton wrote: - This is the same as 2.6.12-rc5-mm1, except the staircase deadline CPU scheduler has been added. This boots without incident on the Altix I've got where prior versions of RSDL all had issues. Count RSDL as fixed here. -- wli - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.21-rc5-mm2
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/ - This is the same as 2.6.12-rc5-mm1, except the staircase deadline CPU scheduler has been added. Boilerplate: - See the `hot-fixes' directory for any important updates to this patchset. - To fetch an -mm tree using git, use (for example) git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.16-rc2-mm1 git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1 - -mm kernel commit activity can be reviewed by subscribing to the mm-commits mailing list. echo "subscribe mm-commits" | mail [EMAIL PROTECTED] - If you hit a bug in -mm and it is not obvious which patch caused it, it is most valuable if you can perform a bisection search to identify which patch introduced the bug. Instructions for this process are at http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt But beware that this process takes some time (around ten rebuilds and reboots), so consider reporting the bug first and if we cannot immediately identify the faulty patch, then perform the bisection search. - When reporting bugs, please try to Cc: the relevant maintainer and mailing list on any email. - When reporting bugs in this kernel via email, please also rewrite the email Subject: in some manner to reflect the nature of the bug. Some developers filter by Subject: when looking for messages to read. - Occasional snapshots of the -mm lineup are uploaded to ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on the mm-commits list. Changes since 2.6.21-rc5-mm1: +sched-dont-renice-kernel-threads.patch +sched-remove-sleepavg-from-proc.patch +sched-implement-staircase-deadline-cpu-scheduler.patch +sched-remove-noninteractive-flag.patch +sched-document-sd-cpu-scheduler.patch scheduler-of-the-day. All 1082 patches: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/patch-series - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.21-rc5-mm2
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/ - This is the same as 2.6.12-rc5-mm1, except the staircase deadline CPU scheduler has been added. Boilerplate: - See the `hot-fixes' directory for any important updates to this patchset. - To fetch an -mm tree using git, use (for example) git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.16-rc2-mm1 git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1 - -mm kernel commit activity can be reviewed by subscribing to the mm-commits mailing list. echo subscribe mm-commits | mail [EMAIL PROTECTED] - If you hit a bug in -mm and it is not obvious which patch caused it, it is most valuable if you can perform a bisection search to identify which patch introduced the bug. Instructions for this process are at http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt But beware that this process takes some time (around ten rebuilds and reboots), so consider reporting the bug first and if we cannot immediately identify the faulty patch, then perform the bisection search. - When reporting bugs, please try to Cc: the relevant maintainer and mailing list on any email. - When reporting bugs in this kernel via email, please also rewrite the email Subject: in some manner to reflect the nature of the bug. Some developers filter by Subject: when looking for messages to read. - Occasional snapshots of the -mm lineup are uploaded to ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on the mm-commits list. Changes since 2.6.21-rc5-mm1: +sched-dont-renice-kernel-threads.patch +sched-remove-sleepavg-from-proc.patch +sched-implement-staircase-deadline-cpu-scheduler.patch +sched-remove-noninteractive-flag.patch +sched-document-sd-cpu-scheduler.patch scheduler-of-the-day. All 1082 patches: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/patch-series - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
