On Wed, 2005-08-17 at 08:47 +0200, Ingo Molnar wrote:
>
> unfortunately the space of "patches that break the kernel" is infinitely
> larger (and infinitely easier to generate) than the space of "patches
> that improve the kernel" - so i'll skip your patch for now ;-)
Yeah, I took out my "bad" fix and it still locks up. Since I got the NMI
working I was able to get output. Unfortunately, the laptop doesn't have
a serial (damn vendors getting rid of the very useful _for us_ uart).
And so far the netconsole doesn't seem to be working yet.
Here's the output (typed from screen).
Freeing unused kernel memory: 296k freed
NMI watchdog detected lockup on CPU#1 (50000/50000)
Pid: 796, comm: hotplug
EIP: 0060:[<c0331662>] CPU: 1
EIP is at _raw_spin_lock+0x72/0xa0
EFLAGS: 00000002 Not tainted (2.6.13-rc6-rt6)
EXI: 00000001 EBX: .... (I'm not about to type all the registers out).
[...]
try_to_wake_up+0x4e
__reacquire_kernel_lock+0x2d
pick_new_owner+0x6b
wake_up_process+0x30
rt_up+0x290
chrdev_open+0xfd
lock_kernel+0x28
chrdev_open+0xfd
tty_open+0x0
chrdev_open+0xfd
file_move+0x20
dentry_open+0x17a
filp_open+0x68
_spin_lock+0x23
get_unused_fd+0xa2
sys_open+0x4f
syscall_call+0x7
----
preempt count: 3
3-level deep critical section nesting:
----
rt_up+0x2c
add_preempt_count+0x1a
add_preempt_count+0x1a
----
showing all locks held by: (hotplug/796 [...])
- No locks where shown.
>
> how come it is stopping the machine during bootup? Or does the lockup
> occur during shutdown? changing the local_irq_disable() to
> raw_local_irq_disable() looks wrong because sooner or later we hit
> complete(). You are probably locking up earlier than that though,
> perhaps in stopmachine_set_state()?
This is on bootup. The stopmachine is used in sys_init_module.
>
> but stop_machine() looks quite preempt-unsafe to begin with. The
> local_irq_disable() would not be needed at all if prior the
> for_each_online_cpu() loop we'd use set_cpus_allowed. The current method
> of achieving 'no preemption' is simply racy even during normal
> CONFIG_PREEMPT.
I guess I'll need to look into this further.
-- Steve
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |