Re: Help wanted: loadable SMBFS

2001-07-31 Thread Sheldon Hearn


[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

2001-07-31 Thread John Baldwin


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

2001-07-29 Thread Sheldon Hearn


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

2001-07-29 Thread Sheldon Hearn



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