Re: Help with issue with mpt(4) driver

[Chuck Silvers <chuq%chuq.com@localhost>]

On Mon, Jan 14, 2013 at 10:04:24PM -0800, Brian Buhrow wrote:
>       Hello.  I'm working on some patches to make the LSI Fusion SCSI driver
> (mpt(4)) more robust.  I'm making good progress, but I've run into a n
> issue that has momentarily baffled me.  If I get a bunch of concurrent jobs
> running on a filesystem mounted on a raid set  using disks across two
> mpt(4) instances, they get into a state where they become deadlocked and
> all but one of the processes is stuck in tstile, and the other remaining
> process is in uvn_fp2.  All the processes are trying to read the same file
> in the filesystem, not write it, but read it.  I have a debug version of
> the kernel, and the machine is running, and other operations against the
> filesystem work fine and complete successfully. I'm assuming the problem is
> something I've introduced into the mpt(4) driver, though I'm not sure how
> at the moment, sinceI've not been able to reproduce it In an alternative
> environment.
>       When a process gets into uvn_fp2 state, it's waiting for something to
> find it pages.  Is there  a way to figure out what it's waiting for and
> which underlying kernel process the uvn_fp2 call is  expecting to wake it
> up?

uvn_fp2 means that the thread wants to lock a page that is already locked.
if you don't see a thread that is stuck in biowait then most likely
the page is being read asynchronously, so there won't be any specific thread
that's involved with that.  you could try looking through the I/O requests
that are pending for that disk device (either in the disk's bufq or in the
mpt driver itself) to see if you can find the request there.  finding the
physical pages involved in a particular I/O requires a couple lookups...
call pmap_extract() on each virtual page address in the range referenced by
bp->b_data / bp->b_bcount, then PHYS_TO_VM_PAGE() on the resulting paddr_t.
you should find a struct vm_page address that matches l_wchan of the thread
that's stuck in uvn_fp2.

-Chuck