Hi Miles.
On Tue, Sep 18, 2007 at 11:27:23AM -0400, Miles Lane wrote:
> Selecting Help for "Subarchitecture Type" causes "make menuconfig" to
> crash, and the bash display settings have to be reset.

Not reproduceable here.
But I noticed that we pass a null pointer to a vsprintf function which
in the cases you pointed out printed a (null) at my system.
Could you plase try if attached patch fix your system.

Thanks,
Sam

diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
index 2ee12a7..1935818 100644
--- a/scripts/kconfig/mconf.c
+++ b/scripts/kconfig/mconf.c
@@ -357,8 +357,9 @@ static void get_symbol_str(struct gstr *r, struct symbol *sym)
bool hit;
struct property *prop;

- str_printf(r, "Symbol: %s [=%s]\n", sym->name,
- sym_get_string_value(sym));
+ if (sym && sym->name)
+ str_printf(r, "Symbol: %s [=%s]\n", sym->name,
+ sym_get_string_value(sym));
for_all_prompts(sym, prop)
get_prompt_str(r, prop);
hit = false;

2007-09-18 19:33:17

Hello,

I wrote a simple script that finds all modules in /lib/modules/`uname -r`
and performs sth like 'modprobe $x; rmmod $x;' for every of them. The result is the
output below. This actually happens when rmmod'ing a module.

I narrowed it down to modules mmc_core and firewire_core. To reproduce that just
rmmod them.

PS. X doesn't work but that's another story.

Regards,

Mariusz

WARNING: at lib/kref.c:33 kref_get()
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c024c567>] kref_get+0x40/0x42
[<c024b81e>] kobject_get+0x12/0x17
[<c02d5800>] bus_get+0x11/0x22
[<c02d5a89>] bus_remove_file+0xe/0x27
[<c02d5ab2>] remove_probe_files+0x10/0x1f
[<c02d5afc>] bus_unregister+0x3b/0x66
[<dee3c2bd>] sdio_unregister_bus+0xd/0xf [mmc_core]
[<dee3d66d>] mmc_exit+0xd/0x23 [mmc_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
WARNING: at lib/kref.c:33 kref_get()
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c024c567>] kref_get+0x40/0x42
[<c024b81e>] kobject_get+0x12/0x17
[<c02d5800>] bus_get+0x11/0x22
[<c02d5a89>] bus_remove_file+0xe/0x27
[<c02d5abe>] remove_probe_files+0x1c/0x1f
[<c02d5afc>] bus_unregister+0x3b/0x66
[<dee3c2bd>] sdio_unregister_bus+0xd/0xf [mmc_core]
[<dee3d66d>] mmc_exit+0xd/0x23 [mmc_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
BUG: atomic counter underflow at:
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c024c5b5>] kref_put+0x4c/0xa7
[<c024b74e>] kobject_put+0x14/0x16
[<c024b809>] unlink+0x3b/0x3e
[<c024b886>] kobject_del+0x16/0x19
[<c024b8a4>] kobject_unregister+0x1b/0x25
[<c024b8bd>] kset_unregister+0xf/0x11
[<c02d5b04>] bus_unregister+0x43/0x66
[<dee3c2bd>] sdio_unregister_bus+0xd/0xf [mmc_core]
[<dee3d66d>] mmc_exit+0xd/0x23 [mmc_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
BUG: atomic counter underflow at:
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c024c5b5>] kref_put+0x4c/0xa7
[<c024b74e>] kobject_put+0x14/0x16
[<c024b809>] unlink+0x3b/0x3e
[<c024b886>] kobject_del+0x16/0x19
[<c024b8a4>] kobject_unregister+0x1b/0x25
[<c024b8bd>] kset_unregister+0xf/0x11
[<c02d5b0f>] bus_unregister+0x4e/0x66
[<dee3c2bd>] sdio_unregister_bus+0xd/0xf [mmc_core]
[<dee3d66d>] mmc_exit+0xd/0x23 [mmc_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
WARNING: at lib/kref.c:33 kref_get()
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c024c567>] kref_get+0x40/0x42
[<c024b81e>] kobject_get+0x12/0x17
[<c02d5800>] bus_get+0x11/0x22
[<c02d5a89>] bus_remove_file+0xe/0x27
[<c02d5b1b>] bus_unregister+0x5a/0x66
[<dee3c2bd>] sdio_unregister_bus+0xd/0xf [mmc_core]
[<dee3d66d>] mmc_exit+0xd/0x23 [mmc_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
BUG: atomic counter underflow at:
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c024c5b5>] kref_put+0x4c/0xa7
[<c024b74e>] kobject_put+0x14/0x16
[<c024b809>] unlink+0x3b/0x3e
[<c024b886>] kobject_del+0x16/0x19
[<c024b8a4>] kobject_unregister+0x1b/0x25
[<c024b8bd>] kset_unregister+0xf/0x11
[<c024b8c7>] subsystem_unregister+0x8/0xa
[<c02d5b23>] bus_unregister+0x62/0x66
[<dee3c2bd>] sdio_unregister_bus+0xd/0xf [mmc_core]
[<dee3d66d>] mmc_exit+0xd/0x23 [mmc_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
------------[ cut here ]------------
kernel BUG at mm/slab.c:592!
invalid opcode: 0000 [#1] PREEMPT
last sysfs file: /block/hdc/removable
Modules linked in: mmc_core pcmcia option usbserial firmware_class 8139too 8250_pci yenta_socket 8250 serial_core rsrc_nonstatic pcmcia_core
Sep 19 05:51:23 orion kernel:
Pid: 6048, comm: rmmod Not tainted (2.6.23-rc6-mm1 #1)
EIP: 0060:[<c015dabb>] EFLAGS: 00010046 CPU: 0
EIP is at kfree+0xad/0xc0
EAX: 00000400 EBX: c05caa48 ECX: 00000000 EDX: c1009e00
ESI: 00000000 EDI: c04f0815 EBP: c2a11e88 ESP: c2a11e78
DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process rmmod (pid: 6048, ti=c2a10000 task=c28f2030 task.ti=c2a10000)
last branch before last exception/interrupt
from c015da5c (kfree+0x4e/0xc0)
to c015dabb (kfree+0xad/0xc0)
Stack: 00000286 c05caa48 00000000 00000000 c2a11ea0 c024b7b5 00000000 c05caa4c
c024b7c1 c05caa20 c2a11ea8 c024b7cc c2a11ec8 c024c596 c1815800 c181e1c0
c2a11ed0 00000286 dee431b0 c05caa90 c2a11ed0 c024b74e c2a11ee8 c024b79d
Call Trace:
[<c024b7b5>] kobject_cleanup+0x65/0x71
[<c024b7cc>] kobject_release+0xb/0xd
[<c024c596>] kref_put+0x2d/0xa7
[<c024b74e>] kobject_put+0x14/0x16
[<c024b79d>] kobject_cleanup+0x4d/0x71
[<c024b7cc>] kobject_release+0xb/0xd
[<c024c596>] kref_put+0x2d/0xa7
[<c024b74e>] kobject_put+0x14/0x16
[<c024b8ab>] kobject_unregister+0x22/0x25
[<c024b8bd>] kset_unregister+0xf/0x11
[<c024b8c7>] subsystem_unregister+0x8/0xa
[<c02d5b23>] bus_unregister+0x62/0x66
[<dee3906f>] mmc_unregister_bus+0xd/0xf [mmc_core]
[<dee3d677>] mmc_exit+0x17/0x23 [mmc_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
INFO: lockdep is turned off.
Code: ff ff 75 f0 9d 83 c4 04 5b 5e 5f 5d c3 ff 75 f0 9d e8 87 51 fd ff 83 c4 04 5b 5e 5f 5d c3 89 da 89 f0 e8 96 fe ff ff 8b 03 eb bf <0f> 0b eb fe 8b 52 0c eb 94 8b 52 0c 8b 0a e9 7c ff ff ff 55 89
EIP: [<c015dabb>] kfree+0xad/0xc0 SS:ESP 0068:c2a11e78
BUG: sleeping function called from invalid context at kernel/rwsem.c:20
in_atomic():0, irqs_disabled():1
INFO: lockdep is turned off.
irq event stamp: 2530
hardirqs last enabled at (2529): [<c015da91>] kfree+0x83/0xc0
hardirqs last disabled at (2530): [<c015da28>] kfree+0x1a/0xc0
softirqs last enabled at (2396): [<c011dc2f>] __do_softirq+0xa4/0xb2
softirqs last disabled at (2371): [<c011dc88>] do_softirq+0x4b/0x4d
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c0114c6d>] __might_sleep+0xb7/0xc9
[<c012db84>] down_read+0x18/0x4b
[<c0140792>] acct_collect+0x3b/0x145
[<c011c0e6>] do_exit+0x12f/0x89a
[<c0105089>] do_trap+0x0/0xa9
[<c010510c>] do_trap+0x83/0xa9
[<c01053f1>] do_invalid_op+0x88/0x92
[<c0420b1a>] error_code+0x6a/0x70
[<c015dabb>] kfree+0xad/0xc0
[<c024b7b5>] kobject_cleanup+0x65/0x71
[<c024b7cc>] kobject_release+0xb/0xd
[<c024c596>] kref_put+0x2d/0xa7
[<c024b74e>] kobject_put+0x14/0x16
[<c024b79d>] kobject_cleanup+0x4d/0x71
[<c024b7cc>] kobject_release+0xb/0xd
[<c024c596>] kref_put+0x2d/0xa7
[<c024b74e>] kobject_put+0x14/0x16
[<c024b8ab>] kobject_unregister+0x22/0x25
[<c024b8bd>] kset_unregister+0xf/0x11
[<c024b8c7>] subsystem_unregister+0x8/0xa
[<c02d5b23>] bus_unregister+0x62/0x66
[<dee3906f>] mmc_unregister_bus+0xd/0xf [mmc_core]
[<dee3d677>] mmc_exit+0x17/0x23 [mmc_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
modprobing: aes-i586
modprobing: twofish-i586
modprobing: anubis
modprobing: blowfish
modprobing: camellia
modprobing: cast5
modprobing: cast6
modprobing: cbc
modprobing: crc32c
modprobing: crypto_hash
modprobing: crypto_null
modprobing: deflate
modprobing: des
modprobing: fcrypt
modprobing: gf128mul
modprobing: hmac
modprobing: khazad
modprobing: lrw
modprobing: md4
modprobing: md5
modprobing: michael_mic
modprobing: pcbc
modprobing: serpent
modprobing: sha1
modprobing: sha256
modprobing: sha512
modprobing: tea
modprobing: tgr192
modprobing: twofish
modprobing: twofish_common
modprobing: wp512
modprobing: xcbc
modprobing: firmware_class
modprobing: sonypi
sonypi: Sony Programmable I/O Controller Driver v1.26.
sonypi: please try the sony-laptop module instead and report failures, see also http://www.linux.it/~malattia/wiki/index.php/Sony_drivers
sonypi: detected type2 model, verbose = 0, fnkeyinit = off, camera = off, compat = off, mask = 0xffffffff, useinput = on, acpi = on
sonypi: enabled at irq=11, port1=0x1080, port2=0x1084
sonypi: device allocated minor is 63
input: Sony Vaio Jogdial as /class/input/input7
input: Sony Vaio Keys as /class/input/input8
sonypi command failed at drivers/char/sonypi.c : sonypi_call1 (line 652)
sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 663)
sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 665)
sonypi command failed at drivers/char/sonypi.c : sonypi_call1 (line 652)
sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 663)
sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 665)
sonypi: removed.
modprobing: amd-rng
modprobing: geode-rng
modprobing: intel-rng
modprobing: rng-core
modprobing: via-rng
modprobing: geode-aes
modprobing: padlock-aes
padlock: VIA PadLock not detected.
modprobing: padlock-sha
padlock: VIA PadLock Hash Engine not detected.
modprobing: firewire-core
WARNING: at lib/kref.c:33 kref_get()
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c024c567>] kref_get+0x40/0x42
[<c024b81e>] kobject_get+0x12/0x17
[<c024b97b>] kobject_init+0x43/0x82
[<c024b9c8>] kset_init+0xe/0x2e
[<c024be4f>] kset_register+0x15/0x38
[<c024be7a>] subsystem_register+0x8/0xa
[<c02d6008>] bus_register+0x65/0x209
[<ded6300d>] fw_core_init+0xd/0x99 [firewire_core]
[<c013aceb>] sys_init_module+0x125/0x1612
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
------------[ cut here ]------------
kernel BUG at mm/slab.c:592!
invalid opcode: 0000 [#2] PREEMPT
last sysfs file: /class/input/input7/modalias
Modules linked in: firewire_core crc_itu_t rng_core gf128mul crypto_hash zlib_deflate zlib_inflate libcrc32c mmc_core pcmcia option usbserial firmware_class 8139too 8250_pci yenta_socket 8250 serial_core rsrc_nonstatic pcmcia_core
Sep 19 05:51:48 orion kernel:
Pid: 6881, comm: rmmod Tainted: G D (2.6.23-rc6-mm1 #1)
EIP: 0060:[<c015dabb>] EFLAGS: 00010046 CPU: 0
EIP is at kfree+0xad/0xc0
EAX: 00000400 EBX: c05caa48 ECX: 00000000 EDX: c1009e00
ESI: 00000000 EDI: c04f0815 EBP: c2683e90 ESP: c2683e80
DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process rmmod (pid: 6881, ti=c2682000 task=c18d6030 task.ti=c2682000)
last branch before last exception/interrupt
from c015da5c (kfree+0x4e/0xc0)
to c015dabb (kfree+0xad/0xc0)
Stack: 00000286 c05caa48 00000000 00000000 c2683ea8 c024b7b5 00000000 c05caa4c
c024b7c1 c05caa20 c2683eb0 c024b7cc c2683ed0 c024c596 c1815800 c181e1c0
c2683ed8 00000286 dee09bd0 c05caa90 c2683ed8 c024b74e c2683ef0 c024b79d
Call Trace:
[<c024b7b5>] kobject_cleanup+0x65/0x71
[<c024b7cc>] kobject_release+0xb/0xd
[<c024c596>] kref_put+0x2d/0xa7
[<c024b74e>] kobject_put+0x14/0x16
[<c024b79d>] kobject_cleanup+0x4d/0x71
[<c024b7cc>] kobject_release+0xb/0xd
[<c024c596>] kref_put+0x2d/0xa7
[<c024b74e>] kobject_put+0x14/0x16
[<c024b8ab>] kobject_unregister+0x22/0x25
[<c024b8bd>] kset_unregister+0xf/0x11
[<c024b8c7>] subsystem_unregister+0x8/0xa
[<c02d5b23>] bus_unregister+0x62/0x66
[<dee0531c>] fw_core_cleanup+0x1c/0x1e [firewire_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
INFO: lockdep is turned off.
Code: ff ff 75 f0 9d 83 c4 04 5b 5e 5f 5d c3 ff 75 f0 9d e8 87 51 fd ff 83 c4 04 5b 5e 5f 5d c3 89 da 89 f0 e8 96 fe ff ff 8b 03 eb bf <0f> 0b eb fe 8b 52 0c eb 94 8b 52 0c 8b 0a e9 7c ff ff ff 55 89
EIP: [<c015dabb>] kfree+0xad/0xc0 SS:ESP 0068:c2683e80
BUG: sleeping function called from invalid context at kernel/rwsem.c:20
in_atomic():0, irqs_disabled():1
INFO: lockdep is turned off.
irq event stamp: 0
hardirqs last enabled at (0): [<00000000>] 0x0
hardirqs last disabled at (0): [<c011743e>] copy_process+0x412/0x1395
softirqs last enabled at (0): [<c011745c>] copy_process+0x430/0x1395
softirqs last disabled at (0): [<00000000>] 0x0
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c0114c6d>] __might_sleep+0xb7/0xc9
[<c012db84>] down_read+0x18/0x4b
[<c0140792>] acct_collect+0x3b/0x145
[<c011c0e6>] do_exit+0x12f/0x89a
[<c0105089>] do_trap+0x0/0xa9
[<c010510c>] do_trap+0x83/0xa9
[<c01053f1>] do_invalid_op+0x88/0x92
[<c0420b1a>] error_code+0x6a/0x70
[<c015dabb>] kfree+0xad/0xc0
[<c024b7b5>] kobject_cleanup+0x65/0x71
[<c024b7cc>] kobject_release+0xb/0xd
[<c024c596>] kref_put+0x2d/0xa7
[<c024b74e>] kobject_put+0x14/0x16
[<c024b79d>] kobject_cleanup+0x4d/0x71
[<c024b7cc>] kobject_release+0xb/0xd
[<c024c596>] kref_put+0x2d/0xa7
[<c024b74e>] kobject_put+0x14/0x16
[<c024b8ab>] kobject_unregister+0x22/0x25
[<c024b8bd>] kset_unregister+0xf/0x11
[<c024b8c7>] subsystem_unregister+0x8/0xa
[<c02d5b23>] bus_unregister+0x62/0x66
[<dee0531c>] fw_core_cleanup+0x1c/0x1e [firewire_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
modprobing: mmc_block
BUG: sleeping function called from invalid context at mm/slab.c:3051
in_atomic():1, irqs_disabled():0
INFO: lockdep is turned off.
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c0114c6d>] __might_sleep+0xb7/0xc9
[<c015e09a>] kmem_cache_alloc+0x78/0xac
[<c023623f>] do_shmat+0x195/0x377
[<c0107e8a>] sys_ipc+0x138/0x240
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
BUG: scheduling while atomic: X/6941/0x00000005
INFO: lockdep is turned off.
irq event stamp: 0
hardirqs last enabled at (0): [<00000000>] 0x0
hardirqs last disabled at (0): [<c011743e>] copy_process+0x412/0x1395
softirqs last enabled at (0): [<c011745c>] copy_process+0x430/0x1395
softirqs last disabled at (0): [<00000000>] 0x0
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c01158b2>] __schedule_bug+0x6e/0x75
[<c041dbba>] __sched_text_start+0x2ca/0x3c0
[<c010418a>] work_resched+0x5/0x25
[<ffffe410>] 0xffffe410
=======================
note: X[6941] exited with preempt_count 7
BUG: scheduling while atomic: X/6941/0x10000008
INFO: lockdep is turned off.
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c01158b2>] __schedule_bug+0x6e/0x75
[<c041dbba>] __sched_text_start+0x2ca/0x3c0
[<c01158da>] __cond_resched+0x21/0x3b
[<c041e30a>] cond_resched+0x2a/0x31
[<c0150469>] unmap_vmas+0x411/0x454
[<c0152d79>] exit_mmap+0x68/0xf6
[<c0116f62>] mmput+0x3f/0xdc
[<c011aaac>] exit_mm+0x75/0xd1
[<c011c101>] do_exit+0x14a/0x89a
[<c011c879>] do_group_exit+0x28/0x6e
[<c0123c61>] get_signal_to_deliver+0x298/0x45c
[<c01035cd>] do_notify_resume+0x89/0x758
[<c01041bd>] work_notifysig+0x13/0x1a
[<080c4b54>] 0x80c4b54
=======================
BUG: scheduling while atomic: X/6941/0x1000000a
INFO: lockdep is turned off.
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c01158b2>] __schedule_bug+0x6e/0x75
[<c041dbba>] __sched_text_start+0x2ca/0x3c0
[<c01158da>] __cond_resched+0x21/0x3b
[<c041e30a>] cond_resched+0x2a/0x31
[<c011aee2>] put_files_struct+0xbb/0xd3
[<c011c142>] do_exit+0x18b/0x89a
[<c011c879>] do_group_exit+0x28/0x6e
[<c0123c61>] get_signal_to_deliver+0x298/0x45c
[<c01035cd>] do_notify_resume+0x89/0x758
[<c01041bd>] work_notifysig+0x13/0x1a
[<080c4b54>] 0x80c4b54
=======================
BUG: scheduling while atomic: X/6941/0x1000000a
INFO: lockdep is turned off.
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c01158b2>] __schedule_bug+0x6e/0x75
[<c041dbba>] __sched_text_start+0x2ca/0x3c0
[<c01158da>] __cond_resched+0x21/0x3b
[<c041e30a>] cond_resched+0x2a/0x31
[<c011aee2>] put_files_struct+0xbb/0xd3
[<c011c142>] do_exit+0x18b/0x89a
[<c011c879>] do_group_exit+0x28/0x6e
[<c0123c61>] get_signal_to_deliver+0x298/0x45c
[<c01035cd>] do_notify_resume+0x89/0x758
[<c01041bd>] work_notifysig+0x13/0x1a
[<080c4b54>] 0x80c4b54
=======================

Attachments:

(No filename) (16.95 kB)
.config (43.01 kB)
Download all attachments

2007-09-18 22:03:41

2007-09-19 23:58:49

[permalink] [raw]

On Thursday, 20 September 2007 15:43, Thomas Gleixner wrote:
> On Thu, 2007-09-20 at 15:29 +0200, Rafael J. Wysocki wrote:
> > > > I haven't had the time to check if any special command line arguments help.
> > > > Will check tomorrow.
> > >
> > > Can you please disable the patches, which I sent Linus wards:
> > >
> > > timekeeping-access-rtc-outside-xtime-lock.patch
> > > xtime-supsend-resume-fixup.patch
> > > acpi-reevaluate-c-p-t-states.patch
> > > clockevents-enforce-broadcast-on-resume.patch
> > > clockevents-do-not-shutdown-broadcast-device-in-oneshot-mode.patch
> > > clockevents-prevent-stale-tick-update-on-offline-cpu.patch
> >
> > I have skipped all of them, but the resulting kernel behaves in the same
> > way (ie. doesn't boot).
> >
> > > Without those patches you get the state of rc4-mm1. It would be
> > > interesting to know which one interferes with the acpi stuff.
> >
> > It looks like something else went in between -rc4 and -rc6 that broke your
> > patch. I wonder what it might be ...
>
> Hmm. Can you please go back in the -hrt project history:
> http://tglx.de/projects/hrtimers/2.6.23-rc5/patch-2.6.23-rc5-hrt1.patches.tar.bz2
> http://tglx.de/projects/hrtimers/2.6.23-rc4/patch-2.6.23-rc4-hrt1.patches.tar.bz2

Sure, but it'll take some time. :-)

> Also, can you send me your .config file please ?

Attached is the one I'm using on 2.6.23-rc6 w/ your patches.

> Vs. the suspend / resume wreckage of rc6-mm1 / rc6-hrt2:

ie. the one on the Vaio (I assume).

> I'm still fishing in rather dark water. Depending on the added
> instrumentation points the problem mutates up to the point where it
> vanishes completely. The hang, which requires key strokes again, happens
> consistently at the same place:
>
> The notifier call in kernel/cpu.c::_cpu_up()
>
> ret = __raw_notifier_call_chain(&cpu_chain, CPU_UP_PREPARE | mod, hcpu,
> -1, &nr_calls);
>
> does not return, but _all_ registered notifiers are called and reach
> their return statement. This reminds me on:
>
> http://lkml.org/lkml/2007/5/9/46
>
> Sigh. I have no clue where to dig further.

Well, the above may affect SMP systems, but the Vaio is UP. Hmm?

Greetings,
Rafael

Attachments:

(No filename) (2.19 kB)
nx6325-failing-config (52.21 kB)
Download all attachments

2007-09-20 14:02:51

by Alan

[permalink] [raw]

Subject: Re: 2.6.23-rc6-mm1: Build failure on ppc64 drivers/ata/pata_scc.c

On Thu, 20 Sep 2007 14:13:15 +0100
[email protected] (Mel Gorman) wrote:

> PPC64 building allmodconfig fails to compile drivers/ata/pata_scc.c . It
> doesn't show up on other arches because this driver is specific to the
> architecture.
>
> drivers/ata/pata_scc.c: In function `scc_bmdma_status'

Its not been updated to match the libata core changes. Try something like
this. Whoever is maintaining it should also remove the prereset cable handling
code and use the proper cable detect method.

Signed-off-by: Alan Cox <[email protected]>

diff -u --exclude-from /usr/src/exclude --new-file --recursive linux.vanilla-2.6.23rc6-mm1/drivers/ata/pata_scc.c linux-2.6.23rc6-mm1/drivers/ata/pata_scc.c
--- linux.vanilla-2.6.23rc6-mm1/drivers/ata/pata_scc.c 2007-09-18 15:32:51.000000000 +0100
+++ linux-2.6.23rc6-mm1/drivers/ata/pata_scc.c 2007-09-20 14:23:32.879807760 +0100
@@ -731,7 +731,7 @@
void __iomem *mmio = ap->ioaddr.bmdma_addr;
u8 host_stat = in_be32(mmio + SCC_DMA_STATUS);
u32 int_status = in_be32(mmio + SCC_DMA_INTST);
- struct ata_queued_cmd *qc = ata_qc_from_tag(ap, ap->active_tag);
+ struct ata_queued_cmd *qc = ata_qc_from_tag(ap, ap->link.active_tag);
static int retry = 0;

/* return if IOS_SS is cleared */
@@ -860,10 +860,10 @@
* @deadline: deadline jiffies for the operation
*/

-static int scc_pata_prereset(struct ata_port *ap, unsigned long deadline)
+static int scc_pata_prereset(struct ata_link *link, unsigned long deadline)
{
- ap->cbl = ATA_CBL_PATA80;
- return ata_std_prereset(ap, deadline);
+ link->ap->cbl = ATA_CBL_PATA80;
+ return ata_std_prereset(link, deadline);
}

/**
@@ -874,8 +874,9 @@
* Note: Original code is ata_std_postreset().
*/

-static void scc_std_postreset (struct ata_port *ap, unsigned int *classes)
+static void scc_std_postreset (struct ata_link *link, unsigned int *classes)
{
+ struct ata_port *ap = link->ap;
DPRINTK("ENTER\n");

/* is double-select really necessary? */

2007-09-20 14:09:18

by Thomas Gleixner

[permalink] [raw]

Subject: Re: 2.6.23-rc6-mm1: failure to boot on HP nx6325, no sound when booted, USB-related WARNING

On Thu, 2007-09-20 at 16:12 +0200, Rafael J. Wysocki wrote:
> > Vs. the suspend / resume wreckage of rc6-mm1 / rc6-hrt2:
>
> ie. the one on the Vaio (I assume).
>
> > I'm still fishing in rather dark water. Depending on the added
> > instrumentation points the problem mutates up to the point where it
> > vanishes completely. The hang, which requires key strokes again, happens
> > consistently at the same place:
> >
> > The notifier call in kernel/cpu.c::_cpu_up()
> >
> > ret = __raw_notifier_call_chain(&cpu_chain, CPU_UP_PREPARE | mod, hcpu,
> > -1, &nr_calls);
> >
> > does not return, but _all_ registered notifiers are called and reach
> > their return statement. This reminds me on:
> >
> > http://lkml.org/lkml/2007/5/9/46
> >
> > Sigh. I have no clue where to dig further.
>
> Well, the above may affect SMP systems, but the Vaio is UP. Hmm?

My jinxed VAIO variant is SMP, but it looks like the same mysterious
error.

tglx

2007-09-20 14:19:19

On 2007-09-20 01:55, /me wrote:
> Rats. Sorry. I remember now. That's not the first time I am hit by
> that one. I had even made a resolution to try and find out the correct
> options to set. So what are they? CONFIG_RTC=y and CONFIG_RTC_DRV_CMOS=n?
> Guess I should try that combination in my next round of tests.

Did that now. It does get rid of the
"Duplicate file names "rtc" detected."
message. The other problems remain.

> So are all my other woes a consequence of that one?

Apparently not.

> Thanks,
> T.

--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)

Attachments:

signature.asc (253.00 B)
OpenPGP digital signature

2007-09-20 19:19:31

2007-09-21 17:18:21

On Fri, 21 Sep 2007 19:30:04 +0200, Jiri Slaby said:
> On 09/21/2007 07:16 PM, [email protected] wrote:
> > On Thu, 20 Sep 2007 17:06:05 CDT, Matt Mackall said:
> >> 2.6.23-rc3-mm1: solid lock on X shutdown (noticed when upgrading)
> >> -rc4-mm1: solid lock on X shutdown, random solid locks about
> >> once every four hours
> >> -rc6-mm1: solid lock on X startup
> >> +your patch: screen goes black, turns off and on a few times during
> >> startup, can reboot with sysrq-b
> >
> > Hmm.. maybe I'm chasing a different bug manifested by the same patch. For me,
> > it's been a solid lockup at X startup since -rc3-mm1, and this patch doesn't
> > change matters.
>
> This patch probably changes behaviour how the pages are queued on the list
> somehow. Maybe it's insane to suggest everybody with similar problem to try
> LIST_DEBUG, but just give it a try after having one of the patches applied ;).
> (Or have you tried yet?)

Haven't tried LIST_DEBUG yet. I'm spending most of the weekend camping, so
will likely be unable to test that until Monday-ish (unless I get lucky and can
get a test in during the next 2 hours)...

Attachments:

(No filename) (226.00 B)

2007-09-21 19:07:20

by Rafael J. Wysocki

[permalink] [raw]

Subject: Re: 2.6.23-rc6-mm1: failure to boot on HP nx6325, no sound when booted, USB-related WARNING

On Friday, 21 September 2007 18:27, Thomas Gleixner wrote:
> Rafael,
>
> On Fri, 2007-09-21 at 16:20 +0200, Rafael J. Wysocki wrote:
> > > > If you need any help from me with that, please let me know.
> > >
> > > I'm zooming in. It seems, that the ACPI idle code plays tricks with us.
> > > After debugging the swsusp_suspend() code path I figured out, that we
> > > end up in C2 or deeper power states while we run the suspend code. The
> > > same happens when we come back on resume. It looks like we disable stuff
> > > in the ACPI BIOS, which makes the C2 and deeper power states misbehave.
> >
> > Hm, can you please run the test I've suggested in another branch of the
> > thread, ie.
> >
> > # echo shutdown > /sys/power/disk
> > # echo disk > /sys/power/state
> >
> > without your debugging code in disk.c?
> >
> > This makes the hibernation code omit the major ACPI hooks, so if it works,
> > we'll know that these hooks are responsible for the problem.
>
> Yes, this works fine. We still go into C3, but this seems not longer to
> brick the box.
>
> > > I hacked the idle loop arch code to use halt() right before we call
> > > device_suspend() and switch back to the acpi idle code right after
> > > device_resume(). This solves the problem as well.
> >
> > Well, that seems less intrusive than changing the code ordering right before
> > the major kernel release, but I think we should do our best to understand what
> > _exactly_ is happening here.
>
> I found some other subtle thinko in the clock events code while I was
> heading down the swsusp_suspend code path. I wait for confirmation that
> it does not brick some endangered boxen, though. Still with this change
> in the clock events code, my VAIO goes into C2 or C3 and causes the box
> to wait for a helping keystroke.
>
> The correct solution would be, that the ACPI code ignores the lower
> C-states during suspend / resume.

Yes, certainly.

> I simply rmmod'ed the processor module before suspend and the problem is
> solved as well. The cpuidle patches make this problem more prominent due
> to the possible more direct switch into lower power states, when we wait for
> a long time on something.

So, perhaps we can add a .suspend()/.resume() routines to the processor driver
and use them to disable/enable the cpuidle functionality during a
suspend/resume?

> I think we really should not fiddle with the various cpu states during
> the critical parts of suspend / resume. Let's keep it simple. We have
> the same policy during boot and I think the suspend / resume critical
> parts have similar constraints.

I completely agree.

Greetings,
Rafael

2007-09-21 19:17:16

by Thomas Gleixner

[permalink] [raw]

Subject: Re: 2.6.23-rc6-mm1: failure to boot on HP nx6325, no sound when booted, USB-related WARNING

Rafael,

On Fri, 2007-09-21 at 21:20 +0200, Rafael J. Wysocki wrote:
> On Friday, 21 September 2007 18:27, Thomas Gleixner wrote:
> > I simply rmmod'ed the processor module before suspend and the problem is
> > solved as well. The cpuidle patches make this problem more prominent due
> > to the possible more direct switch into lower power states, when we wait for
> > a long time on something.
>
> So, perhaps we can add a .suspend()/.resume() routines to the processor driver
> and use them to disable/enable the cpuidle functionality during a
> suspend/resume?

http://tglx.de/private/tglx/p.diff

untested yet, but I'm on the way to do that :)

tglx

2007-09-21 19:25:26

by Rafael J. Wysocki

[permalink] [raw]

Subject: Re: 2.6.23-rc6-mm1: failure to boot on HP nx6325, no sound when booted, USB-related WARNING

Thomas,

On Friday, 21 September 2007 21:16, Thomas Gleixner wrote:
> Rafael,
>
> On Fri, 2007-09-21 at 21:20 +0200, Rafael J. Wysocki wrote:
> > On Friday, 21 September 2007 18:27, Thomas Gleixner wrote:
> > > I simply rmmod'ed the processor module before suspend and the problem is
> > > solved as well. The cpuidle patches make this problem more prominent due
> > > to the possible more direct switch into lower power states, when we wait for
> > > a long time on something.
> >
> > So, perhaps we can add a .suspend()/.resume() routines to the processor driver
> > and use them to disable/enable the cpuidle functionality during a
> > suspend/resume?
>
> http://tglx.de/private/tglx/p.diff
>
> untested yet, but I'm on the way to do that :)

Heh, I thought of the same thing. :-)

Greetings,
Rafael

2007-09-21 19:34:21

Hi Greg,

On Tue, 18 Sep 2007, Greg KH wrote:
>
> On Tue, Sep 18, 2007 at 03:04:48PM +0530, Satyam Sharma wrote:
> >
> > But wait ... isn't that a statically-allocated kobject, which were
> > supposed to be "naughty" in the first place?
>
> Yes it is, if you want to dynamically create it, please do.

Sorry for being late to reply, but do you still want such a patch (i.e.
convert static to dynamic allocation)?

I read elsewhere on this thread that you'd merge Kamalesh's patch and
fix it up to also use kobject_name() yourself. But it's a small/trivial
driver, so I think just converting it to dynamic allocation right now
itself (when we've noticed it already) is probably better (?)

[ BTW I don't see the fix in your git trees or quilt queue. So I'll
make a patch on top of 2.6.23-rc6-mm1 itself. ]

Thanks,

Satyam

2007-09-22 13:19:02

On Fri 2007-09-21 10:06:15, Thomas Gleixner wrote:
> On Fri, 2007-09-21 at 14:51 +1000, Paul Mackerras wrote:
> > Linus Torvalds writes:
> >
> > > It would indeed be nice if we could just take CPU's down early (while
> > > everything is working), and run the whole suspend code with just one CPU,
> > > rather than having to worry about the ordering between CPU and device
> > > takedown.
> >
> > That is certainly what we want to do on powerpc.
>
> I would have expected that we do it exactly this way and it took me by
> surprise, that we do not.

Well, we used to do that, but acpi spec forbids that, and it means
userspace sees plugs/unplugs.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html