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@ 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)) {
                relock = 1;
        } else
                relock = 0;

            device->target->bus, device->target, device, async_arg);
        xpt_async_bcast(&device->asyncs, async_code, path, async_arg);

        if (relock) {

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[] =
                /* quirks */ CD_Q_BCD_TRACKS
+       },
+       {
+               { T_CDROM, SIP_MEDIA_REMOVABLE, "SAMSUNG", "CD-ROM","1.00"},
+               /* quirks */ CD_Q_NO_CHANGER

Alexander Motin
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to