From owner-freebsd-current@FreeBSD.ORG Tue Feb 4 07:39:42 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 30C01A29; Tue, 4 Feb 2014 07:39:42 +0000 (UTC) Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 65F091C1F; Tue, 4 Feb 2014 07:39:40 +0000 (UTC) Received: by mail-ee0-f41.google.com with SMTP id e51so1935040eek.28 for ; Mon, 03 Feb 2014 23:39:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=63JPcyGQBiTBLad94svl/IPeP2Dhluug8kcL3MhloBI=; b=lo4du05u/+Ny5joYVWxyACv33yJ2Lxe/6QE7D4a6cE+JzLAlR8ZuWUyyD4jbIdQjRW gW7ubPNX9sCSdxN5yjcQBAD9xDMuCsan+gWLZ2r9xuact0kKCG0ralz8OZiKuq9MOAey mizK1o2LHv5FcChcDhCNM9g+dlcmuNuvDd6CAzItcTf9t582MpI8pYPil4T/D1oDZpCE 5P1TGMe3rFqENKDtn2dxMpa1YY8k3dCsj1LtXbEPfSQiUK+v26vo1vAi0sdm7n45WOnM GbakhJE2bQKqxW34uHmBCLk/JhOLMDchwDlHQW56qH02dWTWZb1ZJeiEjJni0EUEFJn1 ZTaA== X-Received: by 10.14.29.6 with SMTP id h6mr1034131eea.84.1391499544433; Mon, 03 Feb 2014 23:39:04 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([134.249.139.101]) by mx.google.com with ESMTPSA id m9sm71924582eeh.3.2014.02.03.23.39.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Feb 2014 23:39:03 -0800 (PST) Sender: Alexander Motin Message-ID: <52F09914.5040202@FreeBSD.org> Date: Tue, 04 Feb 2014 09:39:00 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Steve Kargl , John Baldwin Subject: Re: Instant panic CAM or USB subsystem References: <20140125172106.GA67590@troutmask.apl.washington.edu> <201401281232.21958.jhb@freebsd.org> <20140128195842.GA83173@troutmask.apl.washington.edu> In-Reply-To: <20140128195842.GA83173@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, 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, 04 Feb 2014 07:39:42 -0000 On 28.01.2014 21:58, Steve Kargl wrote: > 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: 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 guess problem may be not that phone is reported as CD, but that it is reported as several CDs on one target. Note that you already see cd1 reported, but another one was still trying to allocate when system panicked. I think that CAM CD driver incorrectly assumes that your device is CD changer. I've pulled real 5-disk SCSI CD changer from my depths of my table and got panic very much like yours just on boot. It seems that respective changer code was not properly re-locked during recent CAM locking project. I am going to analyze this case deeper to fix in properly, while for your case I can propose such quick quirk: --- scsi_cd.c (revision 261448) +++ scsi_cd.c (working copy) @@ -223,6 +223,10 @@ static struct cd_quirk_entry cd_quirk_table[] = { { T_CDROM, SIP_MEDIA_REMOVABLE, "CHINON", "CD-ROM CDS-535","*"}, /* quirks */ CD_Q_BCD_TRACKS + }, + { + { T_CDROM, SIP_MEDIA_REMOVABLE, "SAMSUNG", "CD-ROM","1.00"}, + /* quirks */ CD_Q_NO_CHANGER } }; -- Alexander Motin