Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Jul 2010 10:08:33 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        freebsd-current@freebsd.org
Cc:        sbruno@freebsd.org, Boris Kochergin <spawk@acm.poly.edu>, Hans Petter Selasky <hselasky@c2i.net>
Subject:   Re: QEMU/KVM Panic on USB Mount
Message-ID:  <201007121008.33603.jhb@freebsd.org>
In-Reply-To: <4C37DAA2.6080102@acm.poly.edu>
References:  <1278695579.2436.27.camel@localhost.localdomain> <201007100016.29946.hselasky@c2i.net> <4C37DAA2.6080102@acm.poly.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, July 09, 2010 10:27:46 pm Boris Kochergin wrote:
> Hans Petter Selasky wrote:
> > On Friday 09 July 2010 19:12:59 Sean Bruno wrote:
> >   
> >> In order to come up with the most convoluted problem possible, I present
> >> to you screen shots of a panic from a FreeBSD VM running in QEMU
> >> emulation under RedHat's KVM infrastructure.
> >>
> >> I presented a perfectly functional USB partition from my host machine to
> >> the VM.  Then I attempted to mount the partition from FreeBSD and it
> >> generated the panics located here:
> >>
> >> http://people.freebsd.org/~sbruno/usb_panic1.png
> >> http://people.freebsd.org/~sbruno/usb_panic2.png
> >>
> >> This is 100% reproducible.  But not an emergency or anything.
> >>     
> >
> > It might be that there is a conflict that both the VM and the OS is accessing 
> > / loading drivers on the same USB device. The panic seems not directly related 
> > to USB.
> >
> > --HPS
> >
> >   
> I followed the code for a while and the cause of the panic appears to be 
> that ffs_vgetf() in /usr/src/sys/ufs/ffs/ffs_vfsops.c fails in one of 
> the several ways possible, causing in VFS_ROOT() in 
> /usr/src/sys/kern/vfs_mount.c to return a non-zero value and resulting 
> in the panic. I think the problem calls for someone with serious VFS chops.
> 
> The I/O errors from the USB device are suspicious (in that they may 
> cause the mount code to misbehave if they occur during its course).

Much of the filesystem code doesn't really handle I/O errors very gracefully.
I do think trasz@ did some work a year or so ago to improve this somewhat.

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201007121008.33603.jhb>