In article <local.mail.freebsd-current/[EMAIL PROTECTED]> you 
>On Fri, 17 Nov 2000 10:30:02 -0800 (PST), John Baldwin <[EMAIL PROTECTED]> said:
>    > what the WITNESS code does is perform extra checks on mutex
>    > enter's and exit's to ensure that we aren't handling mutexes in
>    > such a way that a deadlock is possible. Thus, it verifies that
>    > you don't grab mutexes out of order, or that you don't grab
>    > sleep mutexes with interrupts disabled, etc.
>Is this code meaningful on UP machines? Having been a victim of these
>seemingly random freezes since SMPng started, as others have noted, I
>decided to compile it in earlier this week. Twice now I've been dumped
>into the debugger with this output:
>lock order reversal
>1st dc0 last acquired @ ../../pci/if_dc.c:2717
>2nd 0xc0acdb3c dc1 @ ../../pci/if_dc.c: 2717
>3rd 0xc0acab3c dc0 @ ../../pci/if_dc.c: 2929

This is on a UP machine?  This looks like you're taking an interrupt
on dc1 and then trying to call the dc0 start routine, which shouldn't
be possible.  (Unless I'm misunderstanding the witness code)

What version of if_dc.c are you using?  line 2929 doesn't correspond
to an instance of "DC_LOCK" in my copy.

this should be released before anything else 

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

Reply via email to