Re: Help wanted: loadable SMBFS
[Aside: problems getting crashdumps resolved, see message with ] [Message-ID [EMAIL PROTECTED] sent to -current] [with subject Re: -current lockups. ] On Mon, 30 Jul 2001 00:00:53 +0200, Sheldon Hearn wrote: I got a little help from some folks on IRC who helped me with a disassembly that confirms a null pointer dereference in the STAILQ_REMOVE(). Hi John, So now that I have crashdumps working (thanks!), I've got a populated ktr_buf in my crashdump. Sadly, I don't understand much of what's in it. Is there a magic look for this to find where 90rql (the smbfs request lock) got accidentally removed from all_locks, or does this require intelligence? If so, do I send you the output of Greg Lehy's ktr GDB macro? What's standard procedure with these things? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Help wanted: loadable SMBFS
On 31-Jul-01 Sheldon Hearn wrote: [Aside: problems getting crashdumps resolved, see message with ] [Message-ID [EMAIL PROTECTED] sent to -current] [with subject Re: -current lockups. ] On Mon, 30 Jul 2001 00:00:53 +0200, Sheldon Hearn wrote: I got a little help from some folks on IRC who helped me with a disassembly that confirms a null pointer dereference in the STAILQ_REMOVE(). Hi John, So now that I have crashdumps working (thanks!), I've got a populated ktr_buf in my crashdump. Sadly, I don't understand much of what's in it. Is there a magic look for this to find where 90rql (the smbfs request lock) got accidentally removed from all_locks, or does this require intelligence? If so, do I send you the output of Greg Lehy's ktr GDB macro? What's standard procedure with these things? If it works. :) It may need updating to work right. Basically the KTR buffer is kind of like a printf buffer. Various points in the code stuff messages into it when an event happens (such as getting a lock, releasing a lock, etc.) There should be an event right at the end about the lock in question being destroyed for example (if you had KTR_LOCK turned on). You might then look in the logs to see where else the same lock was messed with. Ciao, Sheldon. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Help wanted: loadable SMBFS
I have an update on this one. (John, lemme know if you want access to the crashdump). On Wed, 25 Jul 2001 21:30:49 +0200, Sheldon Hearn wrote: Log: Add build infrastructure for a libiconv loadable kernel module. This should allow the use of the smbfs module without the requirement to rebuild the kernel with LIBICONV. I haven't connected this to the modules build because I can't test that it works. Sure, it loads fine, but I get a reproducible kernel mode page fault in the rl(4) interrupt handler when I actually try to use it. The kernel mode page fault isn't in the if_rl interrupt handler. That was a weird red herring. It took a while to get a working crashdump. I would type panic and press enter, coming right back to the prompt. If I pressed enter or typed panic and pressed enter at the prompt, I'd get this: panic: Lock (sx) allproc not locked. [...] kern_synch.c:297 Eventually, I got a crashdump as follows: panic trace panic Weird. So here's what's actually going wrong for me: #10 0xc0271480 in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -881182336, tf_esi = -1053397736, tf_ebp = -852845520, tf_isp = -852845552, tf_ebx = -1070565552, tf_edx = 0, tf_ecx = -881182336, tf_eax = -1070717408, tf_trapno = 12, tf_err = 0, tf_eip = -1071939473, tf_cs = 8, tf_eflags = 66071, tf_esp = -1053397736, tf_ss = -1054244352}) at /usr/src/sys/i386/i386/trap.c:410 410 (void) trap_pfault(frame, FALSE, eva); #11 0xc01b806f in witness_destroy (lock=0xc1366d18) at /usr/src/sys/kern/subr_witness.c:395 #12 0xc0191b8b in mtx_destroy (m=0xc1366d18) at /usr/src/sys/kern/kern_mutex.c:680 #13 0xc134827d in smb_iod_destroy (iod=0xc1366d00) at /usr/src/sys/modules/smbfs/../../netsmb/smb_iod.c:692 [...] Looking inside frame #11... (kgdb) frame 11 #11 0xc01b806f in witness_destroy (lock=0xc1366d18) at /usr/src/sys/kern/subr_witness.c:395 395 STAILQ_REMOVE(all_locks, lock, lock_object, lo_list); (kgdb) print *lock-lo_witness $34 = {w_name = 0xc029dbc6 (dead), w_class = 0xc02e0380, w_list = { stqe_next = 0xc0307778}, w_typelist = {stqe_next = 0xc0307778}, w_children = 0x0, w_file = 0xc029dbc6 (dead), w_line = 0, w_level = 1, w_refcount = 0, w_Giant_squawked = 0 '\000', w_other_squawked = 0 '\000', w_same_squawked = 0 '\000'} I'm absolutely stumped. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Help wanted: loadable SMBFS
On Sun, 29 Jul 2001 22:18:51 +0200, Sheldon Hearn wrote: (kgdb) frame 11 #11 0xc01b806f in witness_destroy (lock=0xc1366d18) at /usr/src/sys/kern/subr_witness.c:395 395 STAILQ_REMOVE(all_locks, lock, lock_object, lo_list); I got a little help from some folks on IRC who helped me with a disassembly that confirms a null pointer dereference in the STAILQ_REMOVE(). So I started walking all_locks. It's a boring process. Isn't there a faster way to find out whether lock's address is the value of an lo_list-stqe_next member of any entry in all_locks before the list-terminating NULL? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message