Hi,
I've been playing with user-mode linux (2.4.0-pre9). It works well on
one machine, but on my laptop I'm consistently getting stack overflows
just as init is started.
The backtrace (from a breakpoint at panic()):
(gdb) bt
#0 panic (fmt=0x10112e00 "Stack overflowed onto current_task page")
at panic.c:54
#1 0x100a244d in check_stack_overflow (ptr=0x5015ccc8) at process_kern.c:715
#2 0x1009ddc9 in set_signals (enable=0) at signal_user.c:50
#3 0x100050b0 in __wake_up (q=0x5014afc8, mode=35) at sched.c:714
#4 0x10020ea5 in end_buffer_io_sync (bh=0x5014af80, uptodate=1)
at /home/jeremy/uml/2.3/include/linux/locks.h:34
#5 0x100607a4 in end_that_request_first (req=0x500e8f00, uptodate=1,
name=0x1011390d "User-mode block device") at ll_rw_blk.c:1000
#6 0x100a3d48 in ubd_finish () at /home/jeremy/uml/2.3/include/linux/blk.h:396
#7 0x100a3dd5 in ubd_handler () at ubd.c:222
#8 0x100a3e00 in ubd_intr (irq=3, dev=0x1012c0a0, unused=0x5015cd88)
at ubd.c:229
#9 0x1009c6bf in handle_IRQ_event (irq=3, regs=0x5015cd88, action=0x500573c0)
at irq.c:148
#10 0x1009c85f in do_IRQ (irq=3, user_mode=0) at irq.c:313
#11 0x1009cf8d in sigio_handler (sig=29) at irq_user.c:53
#12 0x100a7318 in __restore ()
at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127
#13 0x1009de50 in set_signals (enable=3) at signal_user.c:65
#14 0x1005fb46 in generic_unplug_device (data=0x10160650) at ll_rw_blk.c:364
#15 0x100204ab in __wait_on_buffer (bh=0x5014af80)
at /home/jeremy/uml/2.3/include/linux/tqueue.h:120
#16 0x100212be in bread (dev=25088, block=92508, size=1024)
at /home/jeremy/uml/2.3/include/linux/locks.h:20
#17 0x10041a40 in ext2_get_block (inode=0x5013c0a0, iblock=288,
bh_result=0x5014ae00, create=0) at inode.c:250
#18 0x10021edd in block_read_full_page (page=0x50008b74,
get_block=0x10041978 <ext2_get_block>) at buffer.c:1613
#19 0x10042014 in ext2_readpage (file=0x500de1e0, page=0x50008b74)
at inode.c:659
#20 0x10013eb1 in read_cluster_nonblocking (file=0x500de1e0, offset=77,
filesize=78) at filemap.c:440
#21 0x1001525c in filemap_nopage (area=0x500d2c60, address=134832128,
no_share=2) at filemap.c:1391
#22 0x1001209d in do_no_page (mm=0x500d41c0, vma=0x500d2c60,
address=134832392, write_access=2, page_table=0x50159258) at memory.c:1150
#23 0x100121d4 in handle_mm_fault (mm=0x500d41c0, vma=0x500d2c60,
address=134832392, write_access=2) at memory.c:1207
#24 0x100a01b3 in segv (address=134832392, ip=268665530, is_write=2, is_user=0)
at trap_kern.c:89
#25 0x100a0902 in segv_handler (sig=11) at trap_user.c:258
#26 0x100a7318 in __restore ()
at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127
#27 0x100397d4 in load_elf_binary (bprm=0x5015db24, regs=0x0)
at binfmt_elf.c:714
#28 0x100287e8 in search_binary_handler (bprm=0x5015db24, regs=0x0)
at exec.c:809
#29 0x10038226 in load_script (bprm=0x5015db24, regs=0x0) at binfmt_script.c:92
#30 0x100287e8 in search_binary_handler (bprm=0x5015db24, regs=0x0)
at exec.c:809
#31 0x100289cd in do_execve (filename=0x500df000 "/etc/rc.d/rc.sysinit",
argv=0xbf7ffb14, envp=0x804f2c0, regs=0x0) at exec.c:902
#32 0x1009c3fc in execve1 (file=0x500df000 "/etc/rc.d/rc.sysinit",
argv=0xbf7ffb14, env=0x804f2c0) at exec_kern.c:77
#33 0x1009c474 in sys_execve (file=0xbf7ffa88 "", argv=0xbf7ffb14,
env=0x804f2c0) at exec_kern.c:101
#34 0x1009eab7 in execute_syscall (syscall=11, args=0x5015dcf8)
at syscall_kern.c:340
#35 0x1009eeb8 in syscall_handler (unused=0) at syscall_user.c:113
#36 0x1009bf03 in fork_handler (sig=10) at process.c:96
#37 0x100a7318 in __restore ()
at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127
This is a pretty deep stack, but there's nothing unexpected there.
I would guess that some kind of very fast disk drive would also cause
this kind of deep stack on real hardware, if it can complete the
I/O and interrupt before the reschedule.
I tried adding some inlines to make the stack use a little shallower, but
it didn't help.
Any suggestions on how to get this working?
Thanks,
J
This archive was generated by hypermail 2b29 : Sat Oct 07 2000 - 22:44:55 EDT