Chad Mynhier wrote: > Hi, James, > Thanks for the response, but I'm a little bit confused:
Yeah, it's not quite as simple as on sparc, that's for sure! > On 8/23/06, James C. McPherson <James.C.McPherson at gmail.com> wrote: >> Chad Mynhier wrote: >> > Would someone be wiling to verify that I'm doing the right thing in >> > the following? >> > >> > I have a kernel crash dump from an x64 server with the following >> backtrace: >> > >> >> $C >> > fffffe800017fc30 strcmp() >> > fffffe800017fc90 vfs_setmntopt_nolock+0x147() >> > fffffe800017fce0 vfs_parsemntopts+0x96() >> > fffffe800017fe10 domount+0xc87() >> > fffffe800017fe90 mount+0x105() >> > fffffe800017fed0 syscall_ap+0x97() >> > fffffe800017ff20 sys_syscall32+0xef() >> > 00000000080b2b80 0xfe45a0cc() >> >> >> > >> > What I'd like to do is print the contents of the vnode_t that is the >> > third argument to domount(). domount() moves %rdx to %r15 (with no >> > intervening overwrite), and vfs_parsemntopts() pushes %r15 onto the >> > stack: >> > >> >> vfs_parsemntopts::dis >> > vfs_parsemntopts: pushq %rbp >> > vfs_parsemntopts+1: movq %rsp,%rbp >> > vfs_parsemntopts+4: pushq %r15 >> > [ ... ] >> >> Were you aware of the ::findstack dcmd, particularly with the -v option? > > I'm not clear on how this would help me in this case. I have a stack > trace from the thread I'm interested in, the one that panicked the > kernel, via $C. Am I missing something? (Which isn't to say that > ::findstack isn't useful, I'm just having trouble understanding what > more it could give me in this particular case. It might be worth > noting that I only have kernel pages in this core dump, in case what > I'm missing has to do with userland.) You know, I was sure that I'd given an example of how this is useful. My mistake, sorry. Adding the "-v" argument to ::findstack allows you to see what the function call setup has saved for you in the between- thread/function space. (I was looking for the specific bug reference but I couldn't find it). As Frank mentioned, this is the "-save_args" option that was integrated a while ago (and for which you can thank Sherry Moore, btw). So here's an example: > *panic_thread::findstack -v stack pointer for thread fffffe8000b0cc80: fffffe8000b0c4f0 fffffe8000b0c5e0 panic+0x9e() fffffe8000b0c670 die+0xf5(e, fffffe8000b0c7b0, 1000e8, 0) fffffe8000b0c7a0 trap+0x1734(fffffe8000b0c7b0, 1000e8, 0) fffffe8000b0c7b0 _cmntrap+0x201() fffffe8000b0c8d0 i2c_del_adapter+0x44() fffffe8000b0c8f0 saa713x_i2c_unregister+0x4c() fffffe8000b0c910 saa713x_finidev+0x11b() fffffe8000b0c930 saa713x_detach+0x54() fffffe8000b0c9a0 devi_detach+0xa3(ffffffff82e15c00, 0) fffffe8000b0c9e0 detach_node+0x136(ffffffff82e15c00, 8000000) fffffe8000b0ca40 i_ndi_unconfig_node+0x139(ffffffff82e15c00, 4, 8000000) fffffe8000b0ca80 i_ddi_detachchild+0x60(ffffffff82e15c00, 8000000) fffffe8000b0cae0 devi_detach_node+0xb0(ffffffff82e15c00, 8000000) fffffe8000b0cb60 unconfig_immediate_children+0x304(ffffffff82e19a00, 0, 8000000, 4c) fffffe8000b0cbd0 devi_unconfig_common+0x127(ffffffff82e19a00, 0, 8000000, 4c, 0) fffffe8000b0cc60 mt_config_thread+0xba(ffffffff8dcb36c0) fffffe8000b0cc70 thread_start+8() Best regards, James C. McPherson
