freebsd stable - Jan 2010 - ZFS and sh(1) panic: spin lock [lock addr] (smp rendezvous) held by [sh(1) proc tid] too long

The machine, a Dell Optiplex 755, has been locking up recently. The
situation usually occurs while using VirtualBox (running a 64-bit
Windows 7 instance) and doing anything else in another xterm (such as
rebuilding a port).  I've been unable to reliably reproduce it (I'm in
an X session and the machine will not panic "properly").

However, while rebuilding Xorg today at ttyv0 and runnning
VBoxHeadless on ttyv1, I managed to trigger what I believe is the
lockup.

I've attached a textdump in hopes that someone may be able to take a
look and provide clues or instruction on debugging this.

Thanks!

-Brandon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: textdump.tar.0
Type: application/octet-stream
Size: 70144 bytes
Desc: not available
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100127/ce4cb22b/textdump.tar.obj

2010/1/27 Brandon Gooch
<jamesbrandongooch@gmail.com>:
> The machine, a Dell Optiplex 755, has been locking up recently. The
> situation usually occurs while using VirtualBox (running a 64-bit
> Windows 7 instance) and doing anything else in another xterm (such as
> rebuilding a port). ?I've been unable to reliably reproduce it (I'm
in
> an X session and the machine will not panic "properly").
>
> However, while rebuilding Xorg today at ttyv0 and runnning
> VBoxHeadless on ttyv1, I managed to trigger what I believe is the
> lockup.
>
> I've attached a textdump in hopes that someone may be able to take a
> look and provide clues or instruction on debugging this.
I think that jhb@ saw a similar problem while working on nVidia driver
or the like.
Not sure if he made any progress to debug this.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein

On Sat, Feb 20, 2010 at 4:19 PM, Attilio Rao <attilio@freebsd.org>
wrote:
> 2010/1/27 Brandon Gooch <jamesbrandongooch@gmail.com>:
>> The machine, a Dell Optiplex 755, has been locking up recently. The
>> situation usually occurs while using VirtualBox (running a 64-bit
>> Windows 7 instance) and doing anything else in another xterm (such as
>> rebuilding a port). ?I've been unable to reliably reproduce it
(I'm in
>> an X session and the machine will not panic "properly").
>>
>> However, while rebuilding Xorg today at ttyv0 and runnning
>> VBoxHeadless on ttyv1, I managed to trigger what I believe is the
>> lockup.
>>
>> I've attached a textdump in hopes that someone may be able to take
a
>> look and provide clues or instruction on debugging this.
>
> I think that jhb@ saw a similar problem while working on nVidia driver
> or the like.
> Not sure if he made any progress to debug this.
>
The situation has improved slightly, although attempting to run two
VirtualBox guests at the same time inevitably leads to a lock-up. I've
just taken to running one at a time. Not ideal, but until more
debugging can be done, it's the only option I have.

I ran into this using nvidia and radeon both. I can't really find a
pattern, but I do see it when Windows is trying to draw a new window,
or dim the screen when UAC kicks in...

BTW, anyone know how to get a good dump when running Xorg? I'm not
sure I've ever been able to, even when I panic on something non
related to X or video drivers.

-Brandon