Re: Instant panic CAM or USB subsystem

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: <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_at_ 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)
_at__at_ -223,6 +223,10 _at__at_ 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