public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* 2.5.38-mm1 dbench 512 might sleep backtrace emitted
@ 2002-09-23  4:59 William Lee Irwin III
  2002-09-23  5:31 ` Andrew Morton
  0 siblings, 1 reply; 3+ messages in thread
From: William Lee Irwin III @ 2002-09-23  4:59 UTC (permalink / raw)
  To: linux-kernel

Trace; c01175f7 <__might_sleep+27/2b>
Trace; c0139764 <__alloc_pages+24/24c>
Trace; f8e74698 <END_OF_CODE+38ac8334/????>
Trace; c011300d <pte_alloc_one+41/118>
Trace; c012b89d <pte_alloc_map+4d/214>
Trace; c012da28 <vmtruncate+138/164>
Trace; c0133f68 <move_one_page+e8/328>
Trace; c0134091 <move_one_page+211/328>
Trace; c01341d9 <move_page_tables+31/7c>
Trace; c0134870 <do_mremap+64c/7cc>
Trace; c0134a40 <sys_mremap+50/73>
Trace; c010746f <syscall_call+7/b>


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: 2.5.38-mm1 dbench 512 might sleep backtrace emitted
  2002-09-23  4:59 2.5.38-mm1 dbench 512 might sleep backtrace emitted William Lee Irwin III
@ 2002-09-23  5:31 ` Andrew Morton
  2002-09-23  5:33   ` William Lee Irwin III
  0 siblings, 1 reply; 3+ messages in thread
From: Andrew Morton @ 2002-09-23  5:31 UTC (permalink / raw)
  To: William Lee Irwin III; +Cc: linux-kernel

William Lee Irwin III wrote:
> 
> Trace; c01175f7 <__might_sleep+27/2b>
> Trace; c0139764 <__alloc_pages+24/24c>
> Trace; f8e74698 <END_OF_CODE+38ac8334/????>
> Trace; c011300d <pte_alloc_one+41/118>
> Trace; c012b89d <pte_alloc_map+4d/214>
> Trace; c012da28 <vmtruncate+138/164>
> Trace; c0133f68 <move_one_page+e8/328>
> Trace; c0134091 <move_one_page+211/328>
> Trace; c01341d9 <move_page_tables+31/7c>
> Trace; c0134870 <do_mremap+64c/7cc>
> Trace; c0134a40 <sys_mremap+50/73>
> Trace; c010746f <syscall_call+7/b>

Well I can't immediately see any held locks on that path, can
you?  Odd.

Might be best to put a breakpoint on the printk in __might_sleep(),
get some more info if it bites again.

If there _are_ no locks held in that chain then there is
something wrong with in_atomic().  So check the current
task state with `task25' and `thread25' from my .gdbinit.


set editing on
set radix 0x0a

define rmt
set remotebaud 115200
target remote /dev/ttyS0
end

define comm25
p ((struct thread_info *)((int)$esp & ~0x1fff))->task->comm
end

define task25
p ((struct thread_info *)((int)$esp & ~0x1fff))->task
end

define thread25
p ((struct thread_info *)((int)$esp & ~0x1fff))
end

define reboot
	maintenance packet r
end


define page_states
printf "Dirty: %dK\n", (page_states[0].nr_dirty + page_states[1].nr_dirty + page_states[2].nr_dirty + page_states[3].nr_dirty) * 4
printf "Writeback: %dK\n", (page_states[0].nr_writeback + page_states[1].nr_writeback + page_states[2].nr_writeback + page_states[3].nr_writeback) * 4
printf "Pagecache: %dK\n", (page_states[0].nr_pagecache + page_states[1].nr_pagecache + page_states[2].nr_pagecache + page_states[3].nr_pagecache) * 4
printf "Page Table Pages: %d\n", (page_states[0].nr_page_table_pages + page_states[1].nr_page_table_pages + page_states[2].nr_page_table_pages + page_states[3].nr_page_table_pages) * 4
printf "nr_reverse_maps: %d\n", page_states[0].nr_reverse_maps + page_states[1].nr_reverse_maps + page_states[2].nr_reverse_maps + page_states[3].nr_reverse_maps
end


define offsetof
	set $off = &(((struct $arg0 *)0)->$arg1)
	printf "%d 0x%x\n", $off, $off
end

# list_entry list type member
define list_entry
	set $off = (int)&(((struct $arg1 *)0)->$arg2)
	set $addr = (int)$arg0
	set $res = $addr - $off
	printf "0x%x\n", $res
end

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: 2.5.38-mm1 dbench 512 might sleep backtrace emitted
  2002-09-23  5:31 ` Andrew Morton
@ 2002-09-23  5:33   ` William Lee Irwin III
  0 siblings, 0 replies; 3+ messages in thread
From: William Lee Irwin III @ 2002-09-23  5:33 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

William Lee Irwin III wrote:
>> Trace; c01175f7 <__might_sleep+27/2b>

On Sun, Sep 22, 2002 at 10:31:04PM -0700, Andrew Morton wrote:
> Well I can't immediately see any held locks on that path, can
> you?  Odd.
> Might be best to put a breakpoint on the printk in __might_sleep(),
> get some more info if it bites again.
> If there _are_ no locks held in that chain then there is
> something wrong with in_atomic().  So check the current
> task state with `task25' and `thread25' from my .gdbinit.

I squirted it out just in case someone (i.e. you) recognized it off the
bat. I'm looking into it myself also with methods similar to what's
suggested.


Cheers,
Bill

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-09-23  5:37 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-09-23  4:59 2.5.38-mm1 dbench 512 might sleep backtrace emitted William Lee Irwin III
2002-09-23  5:31 ` Andrew Morton
2002-09-23  5:33   ` William Lee Irwin III

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox