Date: Tue, 28 Jan 2014 11:58:42 -0800 From: Steve Kargl <sgk@troutmask.apl.washington.edu> To: John Baldwin <jhb@freebsd.org> Cc: Alexander Motin <mav@freebsd.org>, freebsd-current@freebsd.org, scsi@freebsd.org Subject: Re: Instant panic CAM or USB subsystem Message-ID: <20140128195842.GA83173@troutmask.apl.washington.edu> In-Reply-To: <201401281232.21958.jhb@freebsd.org> References: <20140125172106.GA67590@troutmask.apl.washington.edu> <201401281232.21958.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 28, 2014 at 12:32:21PM -0500, John Baldwin wrote:
> On Saturday, January 25, 2014 12:21:06 pm Steve Kargl wrote:
> > If I plug my Samsung Intensity II cellphone into a usb port,
> > I get an instant panic. This is 100% reproducible. I have
> > the core and kernel for further debugging. Dmesg.boot follows
> > my sig.
> >
> > % kgdb /boot/kernel/kernel /vmcore.0
> >
> > Unread portion of the kernel message buffer:
> > cd1 at umass-sim1 bus 1 scbus4 target 0 lun 0
> > cd1: <SAMSUNG CD-ROM 1.00> Removable CD-ROM SCSI-2 device
> > cd1: Serial Number 000000000002
> > cd1: 1.000MB/s transfers
> > cd1: cd present [3840000 x 512 byte records]
> > cd1: quirks=0x10<10_BYTE_ONLY>
> > panic: mutex CAM device lock not owned at /usr/src/sys/cam/cam_periph.c:301
> > cpuid = 0
> > KDB: enter: panic
>
> scsi@ might work better for this. It looks like when cdasync() calls
> cam_periph_alloc() it doesn't have its associated xpt_path locked. All the
> other async xpt callbacks I looked at don't lock the xpt path either. It
> seems they expect it to be locked by the caller when they are invoked. It
> seems xpt_async_process_dev() doesn't always lock xpt_lock, but sometimes
> locks the device instead:
>
> /*
> * If async for specific device is to be delivered to
> * the wildcard client, take the specific device lock.
> * XXX: We may need a way for client to specify it.
> */
> if ((device->lun_id == CAM_LUN_WILDCARD &&
> path->device->lun_id != CAM_LUN_WILDCARD) ||
> (device->target->target_id == CAM_TARGET_WILDCARD &&
> path->target->target_id != CAM_TARGET_WILDCARD) ||
> (device->target->bus->path_id == CAM_BUS_WILDCARD &&
> path->target->bus->path_id != CAM_BUS_WILDCARD)) {
> mtx_unlock(&device->device_mtx);
> xpt_path_lock(path);
> relock = 1;
> } else
> relock = 0;
>
> (*(device->target->bus->xport->async))(async_code,
> device->target->bus, device->target, device, async_arg);
> xpt_async_bcast(&device->asyncs, async_code, path, async_arg);
>
> if (relock) {
> xpt_path_unlock(path);
> mtx_lock(&device->device_mtx);
> }
>
> Maybe try going up to this frame (16) in your dump and do
> 'p *device->target'? However, someone with more CAM knowledge needs to look
> at this to see what is actually broken.
>
> It seems a bit odd that it thinks your phone is a CD player.
Thanks for the follow-up. I poked around a bit, but don't
recall looking at *device->target. Under Windows, 3
filesystems show up, and the one causing problems is listed
as CDFS.
I'm travaling this week for owrk, so may not be able to
follow-up with more info until Sunday.
--
Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140128195842.GA83173>