On Thu, Sep 06, 2001 at 11:55:19AM -0700, John Baldwin wrote:
> Note that 3 of these are runnable (stat of 2 == SRUN).  In top, see if they are
> chewing up lots of time.

Top doesn't update after the first mozilla process has started. Its
trace is:

 --- syscall(93, .., select)

> > db> trace 517
> > mi_switch(0,cd193aa0,811f874,cd27cfa0,c02bead6) at mi_switch+0x1a0
> > _mtx_unlock_sleep(c039e860,0,c030b460,497) at _mtx_unlock_sleep+0x204
> > syscall(2f,2f,2f,811f874,1) at syscall+0x48a
> > syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
> > --- syscall (514), eip = 0x285a31a7, esp = 0x811f858, ebp = 0x811f9b4 ---
> Weird syscall number (514).  This one was blocked on a mutex that was just
> released.  I'm betting that 0xc039e860 is Giant?  Perhaps not though?

Rien ne va plus! It is Giant.

> > db> trace 520
> > mi_switch(cd193ee0) at mi_switch+0x1a0
> > userret(cd193ee0,cd257fa8,0,208,befffc00) at userret+0x395
> > syscall(2f,2f,2f,befffd24,befffc00) at syscall+0x3c9
> > syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
> > --- syscall (0, Linux ELF, nosys), eip = 0x285b8bd4, esp = 0xbefffb24, ebp =
> > 0xbefffbf4 ---
> Another instance of being preempted upon return to userland.  Possible that the
> regs in the trapframe are altered to hold return values and thus that the
> syscall number is invalid.  Hmmmmmm.

That certainly would explain it (see above).

> What locks do all these processes hold? 

No locks are hold by any of the processes. The question then is: what
are they waiting for?

I started playing with remote debugging let me look around for a bit.

BTW: Do we have handy functions for use in the remote debugger, such
as show_proc, show_vm or whatever, that dump important information
in a readable form?

 Marcel Moolenaar         USPA: A-39004          [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to