From: Anders K. <and...@me...> - 2001-04-23 19:17:53
|
Hello list, Previous e-mail detailed two problems I have found. Here is the second one in more detail. UML boots using hostfs for the root_fs directory which contains the installed system. ubd1 is a swap file, 16MB in size. The UML is started with the debug option and once I have given the continue command in gdb, it boots quite happily. I log in and issue the 'poweroff' command which shuts the system down. I seems to work quite happily, killing all processes, turning off swap, remounting filesystems read-only then trying to halt the system. The debugger kicks in and I get this backtrace from it. (gdb) bt #0 panic (fmt=3D0x10121d20 "Kernel mode fault at addr 0x%lx, ip 0x%lx") at panic.c:54 #1 0x100a2e7d in segv (address=3D1515870882, ip=3D268721935, is_write=3D0,= =20 is_user=3D0) at trap_kern.c:54 #2 0x100a384b in segv_handler (sig=3D11, sc=3D0x50f23998, usermode=3D0) at trap_user.c:303 #3 0x100a3928 in sig_handler (sig=3D11) at trap_user.c:342 #4 <signal handler called> #5 proc_kill_inodes (de=3D0x500f1dc4) at generic.c:389 #6 0x10046405 in remove_proc_entry (name=3D0x1011f989 "max_dgram_qlen",=20 parent=3D0x500f1d3c) at generic.c:573 #7 0x1001029e in unregister_proc_table (table=3D0x1013caec, root=3D0x500f1= d3c) at sysctl.c:671 #8 0x1001027a in unregister_proc_table (table=3D0x1013cb44, root=3D0x50056= c0c) at sysctl.c:659 #9 0x1001027a in unregister_proc_table (table=3D0x1013cb9c, root=3D0x5004f= dec) at sysctl.c:659 #10 0x1001010a in unregister_sysctl_table (header=3D0x500572bc) at sysctl.c= :585 #11 0x10098998 in unix_sysctl_unregister () at sysctl_net_unix.c:43 #12 0x10103749 in af_unix_exit () at af_unix.c:1882 #13 0x100a60f4 in do_exitcalls () at process_kern.c:788 #14 0x100a0ee0 in machine_power_off () at reboot.c:34 #15 0x100154e6 in sys_reboot (magic1=3D-18751827, magic2=3D672274793,=20 cmd=3D1126301404, arg=3D0x8049500) at sys.c:309 #16 0x100a1ce5 in execute_syscall (regs=3D{regs =3D {4276215469, 672274793,= =20 1126301404, 134518016, 4276215469, 3212836180, 4294967258, 43, 43, = 0,=20 0, 88, 1074622251, 35, 534, 3212836152, 43}}) at syscall_kern.c:348 #17 0x100a1e0a in syscall_handler (unused=3D0x0) at syscall_user.c:73 I then run a few other commands (from memory and the trouble shooting UML web page). (gdb) info symbol 0x100a2e7d segv + 317 in section .text (gdb) info symbol 0x100a384b segv_handler + 139 in section .text (gdb) info symbol 0x100a3928 sig_handler + 76 in section .text If there is anything else required, give me a shout as I can reproduce this very easily. Regards, --=20 Anders Karlsson Mean Solutions Ltd. e-mail: and...@me... Mobile: +44-7711-876270 *** PGP Encrypted E-Mail Is Prefered - PGP Key On Request *** |
From: Jeff D. <jd...@ka...> - 2001-04-23 20:48:43
|
and...@me... said: > VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a > nice day... These might be a bug in the generic kernel. There have been complaints about this on lkml for ext2, I think. You could put a breakpoint on that printk, and look at the inodes that were still hanging around. Figuring out what files they represent would be useful. The way that's done in hostfs is that the name is constructed by walking up the dentry tree. See dentry_name for the logic. The segfault is different. > #1 0x100a2e7d in segv (address=1515870882, ip=268721935, is_write=0, > is_user=0) at trap_kern.c:54 I want 'i sym 1515870882' and 'i line *1515870882' from this crash. The address is obviously bogus. The thing to do is figure out where it is currently, and then see if you can figure out when that address got stuck there. Jeff |
From: Anders K. <and...@me...> - 2001-04-24 08:21:01
|
On Mon, Apr 23, 2001 at 03:49:53PM -0400, Jeff Dike wrote: > and...@me... said: > > VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a > > nice day...=20 >=20 > These might be a bug in the generic kernel. There have been > complaints about this on lkml for ext2, I think. >=20 > You could put a breakpoint on that printk, and look at the inodes that we= re=20 > still hanging around. Figuring out what files they represent would > be useful. The way that's done in hostfs is that the name is > constructed by walking up the dentry tree. See dentry_name for the > logic.=20 Oookay.. I have tried to leech some sense out of this by putting a breakpoint on printk and stepping through until I got to the one I wanted, but I can not seem to find any symbol that matches 'dentry' or 'name' in any way. I do a 'info local' and get a list of local variables, and if I do 'info line <symbol>' I get lots of references to 'dev_mcast.c' at the point where it complains about busy inodes. The backtrace at this point is: -=3D- (gdb) bt #0 printk ( fmt=3D0x1010d300 "VFS: Busy inodes after unmount. Self-destruct in 5 se= conds. Have a nice day...\n") at printk.c:263 #1 0x1002e697 in kill_super (sb=3D0x50059800, umount_root=3D0) at super.c:= 914 #2 0x1002e8ad in kern_umount (mnt=3D0x5007d6dc) at super.c:1000 #3 0x101036e5 in exit_proc_fs () at procfs_syms.c:42 #4 0x100a60f4 in do_exitcalls () at process_kern.c:788 #5 0x100a0ee0 in machine_power_off () at reboot.c:34 #6 0x100154e6 in sys_reboot (magic1=3D-18751827, magic2=3D672274793,=20 cmd=3D1126301404, arg=3D0x8049500) at sys.c:309 #7 0x100a1ce5 in execute_syscall (regs=3D{regs =3D {4276215469, 672274793,= =20 1126301404, 134518016, 4276215469, 3212836180, 4294967258, 43, 43, = 0,=20 0, 88, 1074622251, 35, 534, 3212836152, 43}}) at syscall_kern.c:348 #8 0x100a1e0a in syscall_handler (unused=3D0x0) at syscall_user.c:73 -=3D- > The segfault is different. >=20 > > #1 0x100a2e7d in segv (address=3D1515870882, ip=3D268721935, is_write= =3D0,=20 > > is_user=3D0) at trap_kern.c:54=20 >=20 > I want 'i sym 1515870882' and 'i line *1515870882' from this crash. (gdb) i sym 1515870882 No symbol matches 1515870882. (gdb) i line *1515870882 No line number information available for address 0x5a5a5aa2 (gdb) i line *0x100a2e7d Line 54 of "trap_kern.c" starts at address 0x100a2e68 <segv+296> and ends at 0x100a2e80 <segv+320>. > The address is obviously bogus. The thing to do is figure out where it i= s=20 > currently, and then see if you can figure out when that address got stuck= =20 > there. >=20 Would the done thing be to start inserting some printk's in the code and print out various bits of information or should I run this in gdb only? If the printk way is better, I will need some pointers for which punction to stick them in, and what to print out. Regards, --=20 Anders Karlsson Mean Solutions Ltd. e-mail: and...@me... Mobile: +44-7711-876270 *** PGP Encrypted E-Mail Is Prefered - PGP Key On Request *** |
From: Jeff D. <jd...@ka...> - 2001-04-24 21:10:29
|
and...@me... said: > but I can not seem to find any symbol that matches 'dentry' or 'name' > in any way. Look at dentry_name() (and inode_name) in arch/um/fs/hostfs/hostfs_kern.c. They figure out the name of a hostfs file from its inode by starting from one of the inode dentrys, and working its way from there the the root, constructing the filename segment by segment. Knowing the filenames of the leftover inodes would be interesting. > > > #1 0x100a2e7d in segv (address=1515870882, ip=268721935, is_write=0, > > > is_user=0) at trap_kern.c:54 > > > > I want 'i sym 1515870882' and 'i line *1515870882' from this crash. > > (gdb) i sym 1515870882 > No symbol matches 1515870882. Rats, I gave you the wrong number. I want the symbol information from the ip (268721935), not the fault address. Jeff |
From: Anders K. <and...@me...> - 2001-04-29 21:11:16
|
On Tue, Apr 24, 2001 at 05:22:30PM -0500, Jeff Dike wrote: >=20 > Look at dentry_name() (and inode_name) in arch/um/fs/hostfs/hostfs_kern.c= . =20 > They figure out the name of a hostfs file from its inode by starting > from one of the inode dentrys, and working its way from there the > the root, constructing the filename segment by segment. Knowing the > filenames of the leftover inodes would be interesting. I will have a look and see if there is any way I can add some code there to printk filenames under certain circumstances. I am not good with C, but that could be within my scope. ;-) > > > I want 'i sym 1515870882' and 'i line *1515870882' from this crash. > >=20 > > (gdb) i sym 1515870882 > > No symbol matches 1515870882. >=20 > Rats, I gave you the wrong number. I want the symbol information > from the ip (268721935), not the fault address. Okay, I ran it again and here is what I got. (gdb) bt #0 0x1000abf0 in panic ( fmt=3D0x10121d20 "Kernel mode fault at addr 0x%lx, ip 0x%lx") at panic.= c:100 #1 0x100a2e7d in segv (address=3D1515870882, ip=3D268721935, is_write=3D0,= =20 is_user=3D0) at trap_kern.c:54 =2E =2E (gdb) i sym 268721935 proc_kill_inodes + 15 in section .text (gdb) i sym *268721935 No symbol matches *268721935. Regards, --=20 Anders Karlsson Mean Solutions Ltd. e-mail: and...@me... Mobile: +44-7711-876270 *** PGP Encrypted E-Mail Is Prefered - PGP Key On Request *** -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GIT/B d-(++) s: a- C++>$ UAL++++$ P+(++)>$ L+++>$ E(+++) W+(-) N+ !o !K w--- O- M- V- PS+ PE Y+ PGP++(+++) t+ 5(+) X+ R tv- b++ DI++ D G e* h---- r+++ y++++=20 ------END GEEK CODE BLOCK------ |