From owner-freebsd-current@FreeBSD.ORG Tue Jan 28 17:35:32 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF5FCB0C; Tue, 28 Jan 2014 17:35:32 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 951121506; Tue, 28 Jan 2014 17:35:32 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7DC71B9DB; Tue, 28 Jan 2014 12:35:31 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: Instant panic CAM or USB subsystem Date: Tue, 28 Jan 2014 12:32:21 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <20140125172106.GA67590@troutmask.apl.washington.edu> In-Reply-To: <20140125172106.GA67590@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201401281232.21958.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 28 Jan 2014 12:35:31 -0500 (EST) Cc: Alexander Motin , Steve Kargl , scsi@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 17:35:32 -0000 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: 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. -- John Baldwin