Re: Instant panic CAM or USB subsystem

2014-02-04 Thread Steve Kargl
On Tue, Feb 04, 2014 at 09:39:00AM +0200, Alexander Motin wrote:
 
 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.

Good guess see below.

 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.

If you come up with a patch, I can test it for you.

 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
  }
   };
 

With your quirk, the laptop booted and plugging in the cellphone
does not cause a panic.  :-)  

dmesg shows

ugen3.2: Qualcomm, Incorporated at usbus3
umass1: Qualcomm, Incorporated USB MMC Storage, class 0/0, rev 1.10/0.00,\
 addr 2 on usbus3
cd1 at umass-sim1 bus 1 scbus5 target 0 lun 0
cd1: SAMSUNG CD-ROM 1.00 Removable CD-ROM SCSI-2 device 
cd1: Serial Number 0002
cd1: 1.000MB/s transfers
cd1: cd present [384 x 512 byte records]
cd1: quirks=0x14NO_CHANGER,10_BYTE_ONLY
cd2 at umass-sim1 bus 1 scbus5 target 0 lun 1
cd2: SAMSUNG CD-ROM 1.00 Removable CD-ROM SCSI-2 device 
cd2: Serial Number 0002
cd2: 1.000MB/s transfers
cd2: cd present [1084 x 512 byte records]
cd2: quirks=0x14NO_CHANGER,10_BYTE_ONLY

After a few seconds, the cellphone display shows

 Sync Music to Phone
 Sync Music to Card
 Copy/Move Files

and the following appears in dmesg

ugen3.2: Qualcomm, Incorporated at usbus3 (disconnected)
umass1: at uhub3, port 2, addr 2 (disconnected)
cd1 at umass-sim1 bus 1 scbus5 target 0 lun 0
cd1: SAMSUNG CD-ROM 1.00 s/n 0002 detached
cd2 at umass-sim1 bus 1 scbus5 target 0 lun 1
cd2: SAMSUNG CD-ROM 1.00 s/n 0002 detached
(cd2:umass-sim1:1:0:1): Periph destroyed
(cd1:umass-sim1:1:0:0): Periph destroyed
ugen3.2: SAMSUNG Electronics Bo.,Ltd. at usbus3

This is fine with me as I only use the laptop as a charging station.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Instant panic CAM or USB subsystem

2014-02-03 Thread Steve Kargl
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 0002
  cd1: 1.000MB/s transfers
  cd1: cd present [384 x 512 byte records]
  cd1: quirks=0x1010_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.
 

I finally have time to look at this again.  Here's kgdb for frame 16
as you suggested and then frame 17.


Script started on Mon Feb  3 08:16:32 2014
% kgdb /dsk1/obj/usr/src/sys/MOBILE/kernel.debug vmcore.0

Unread portion of the kernel message buffer:
panic: mutex CAM device lock not owned at /usr/src/sys/cam/cam_periph.c:301
cpuid = 1
KDB: enter: panic

#16 0xc047d6a5 in xpt_async_process_dev (device=value optimized out, 
arg=0xc70aa800) at /usr/src/sys/cam/cam_xpt.c:4208
#17 0xc047b346 in xpt_async_process (periph=0x0, ccb=0xc70aa800)
at /usr/src/sys/cam/cam_xpt.c:4173
#18 0xc047bd15 in xpt_done_process (ccb_h=0xc70aa800)
at /usr/src/sys/cam/cam_xpt.c:5249
#19 0xc047ef14 in xpt_done_td (arg=value optimized out)
at /usr/src/sys/cam/cam_xpt.c:5276
#20 0xc0723daf in fork_exit (callout=0xc047edb0 xpt_done_td)
at /usr/src/sys/kern/kern_fork.c:977
#21 0xc09fb3e4 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:278
Current language:  auto; currently minimal
(kgdb) frame 16
#16 0xc047d6a5 in xpt_async_process_dev (device=value optimized out, 
arg=0xc70aa800) at /usr/src/sys/cam/cam_xpt.c:4208
4208cur_entry-callback(cur_entry-callback_arg,
(kgdb) p *device
Cannot access memory at address 0x0
(kgdb) up 1
#17 0xc047b346 in xpt_async_process (periph=0x0, ccb=0xc70aa800)
at /usr/src/sys/cam/cam_xpt.c:4173
4173xpt_async_process_dev(xpt_periph-path-device, ccb);
(kgdb) p *xpt_periph-path-device-target
$2 = {ed_entries = {tqh_first = 0xc6f4b800, tqh_last = 0xc6f4b80c}, links = {
tqe_next = 0x0, tqe_prev = 0xc6eaaa00}, bus = 0xc6eaaa00, 
  target_id = 4294967295, refcount = 2, generation = 1, last_reset = {
tv_sec = 0, tv_usec = 0}, rpl_size = 0, luns = 0x0, luns_mtx = {
lock_object = {lo_name = 0xc0a3f9bc CAM LUNs lock, lo_flags = 16973824, 
  lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}}
(kgdb) p *xpt_periph-path-device-target-bus
$3 = {et_entries = {tqh_first = 0xc6eaa980, tqh_last = 0xc6eaa988}, links = {
tqe_next = 0x0, tqe_prev = 0xc7690008}, path_id = 4294967295, 
  sim = 0xc6eaaa80, last_reset = {tv_sec = 0, tv_usec = 0}, flags = 0, 
  refcount = 3, generation = 3, parent_dev = 0x0, xport = 0xc0b2f568, 
  eb_mtx = {lock_object = {lo_name = 0xc0a3f85a CAM bus lock, 
  lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}}
(kgdb) quit
% exit
exit

Script done on Mon Feb  3 08:20:44 2014

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to 

Re: Instant panic CAM or USB subsystem

2014-02-03 Thread Alexander Motin

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 0002
cd1: 1.000MB/s transfers
cd1: cd present [384 x 512 byte records]
cd1: quirks=0x1010_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
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Instant panic CAM or USB subsystem

2014-01-28 Thread John Baldwin
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 0002
 cd1: 1.000MB/s transfers
 cd1: cd present [384 x 512 byte records]
 cd1: quirks=0x1010_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
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Instant panic CAM or USB subsystem

2014-01-28 Thread John-Mark Gurney
John Baldwin wrote this message on Tue, Jan 28, 2014 at 12:32 -0500:
 It seems a bit odd that it thinks your phone is a CD player.

I've seen a phone that acts like that, they use it to present software
(like sync) for install on the desktop...

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Instant panic CAM or USB subsystem

2014-01-28 Thread Steve Kargl
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 0002
  cd1: 1.000MB/s transfers
  cd1: cd present [384 x 512 byte records]
  cd1: quirks=0x1010_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
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Instant panic CAM or USB subsystem

2014-01-28 Thread Steve Kargl
On Tue, Jan 28, 2014 at 09:53:52AM -0800, John-Mark Gurney wrote:
 John Baldwin wrote this message on Tue, Jan 28, 2014 at 12:32 -0500:
  It seems a bit odd that it thinks your phone is a CD player.
 
 I've seen a phone that acts like that, they use it to present software
 (like sync) for install on the desktop...
 

Yes, that appears to be the problem.  Under Windows, the phone
shows 3 filesystems and the problematic one reports CDFS.  I 
should note that I've plugged this phone into this laptop
for a few years without any issues.  I unfortunately updated
a circa Aug 2013 freebsd-current to a week old -current.  It
has not been a pleasant experience.  Unzipping or untarring
a large compressed archive onto a USB mounted hard drive
renders the system unusable for minutes at a time. unzip
and bsdtar are stuck in getblk or wdrain for 30 to 60
seconds.  System recovers for a few seconds then get stuck
again.  Rinse and repeat.  I'm not sure if it is a UFS2
or USB or some other change.
 
-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Instant panic CAM or USB subsystem

2014-01-25 Thread Steve Kargl
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 0002
cd1: 1.000MB/s transfers
cd1: cd present [384 x 512 byte records]
cd1: quirks=0x1010_BYTE_ONLY
panic: mutex CAM device lock not owned at /usr/src/sys/cam/cam_periph.c:301
cpuid = 0
KDB: enter: panic

(kgdb) bt
#0  doadump (textdump=0) at pcpu.h:233
#1  0xc04cf211 in db_dump (dummy=-1065835907, dummy2=0, dummy3=-1, 
dummy4=0xe2af25e4 )
at /usr/src/sys/ddb/db_command.c:543
#2  0xc04cecd7 in db_command (cmd_table=value optimized out) at 
/usr/src/sys/ddb/db_command.c:449
#3  0xc04cea10 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502
#4  0xc04d12a2 in db_trap (type=value optimized out, code=-1056387128)
at /usr/src/sys/ddb/db_main.c:231
#5  0xc078a9f8 in kdb_trap (type=value optimized out, code=value optimized 
out, 
tf=value optimized out) at /usr/src/sys/kern/subr_kdb.c:656
#6  0xc0a112f2 in trap (frame=value optimized out) at 
/usr/src/sys/i386/i386/trap.c:711
#7  0xc09fa8cc in calltrap () at /usr/src/sys/i386/i386/exception.s:169
#8  0xc078a27d in kdb_enter (why=0xc0ad8ea3 panic, msg=value optimized out) 
at cpufunc.h:71
#9  0xc07546c3 in vpanic (fmt=value optimized out, ap=value optimized out)
at /usr/src/sys/kern/kern_shutdown.c:752
#10 0xc0754702 in panic (fmt=0xc0ad6b73 mutex %s not owned at %s:%d)
at /usr/src/sys/kern/kern_shutdown.c:688
#11 0xc07401d9 in __mtx_assert (c=0x35db, what=value optimized out, 
file=0x12 Address 0x12 out of bounds, line=1309824) at 
/usr/src/sys/kern/kern_mutex.c:793
#12 0xc047333c in cam_periph_find (name=value optimized out) at 
/usr/src/sys/cam/cam_periph.c:301
#13 0xc0491062 in cdregister (periph=value optimized out, arg=0xc72ee22c)
at /usr/src/sys/cam/scsi/scsi_cd.c:1007
#14 0xc047313c in cam_periph_alloc (name=value optimized out, 
path=0xc752d490, 
ac_callback=value optimized out, code=value optimized out) at 
/usr/src/sys/cam/cam_periph.c:249
#15 0xc04907cc in cdasync (callback_arg=value optimized out, code=value 
optimized out, 
arg=0xc78cd000) at /usr/src/sys/cam/scsi/scsi_cd.c:548
#16 0xc047d485 in xpt_async_process_dev (device=value optimized out, 
arg=0xc78cd800)
at /usr/src/sys/cam/cam_xpt.c:4206
#17 0xc047b126 in xpt_async_process (periph=0x0, ccb=0xc78cd800) at 
/usr/src/sys/cam/cam_xpt.c:4171
#18 0xc047baf5 in xpt_done_process (ccb_h=0xc78cd800) at 
/usr/src/sys/cam/cam_xpt.c:5247
#19 0xc047ecf4 in xpt_done_td (arg=value optimized out) at 
/usr/src/sys/cam/cam_xpt.c:5274
#20 0xc07234df in fork_exit (callout=0xc047eb90 xpt_done_td) at 
/usr/src/sys/kern/kern_fork.c:977
#21 0xc09fa944 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:278
Current language:  auto; currently minimal
(kgdb) quit
laptop-kargl:root[202] exit
exit

Script done on Sat Jan 25 09:11:35 2014

-- 
Steve

Copyright (c) 1992-2014 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-CURRENT #1 r260692: Wed Jan 15 14:10:51 PST 2014
ka...@laptop-kargl.apl.washington.edu:/dsk1/obj/usr/src/sys/MOBILE i386
FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
CPU: Intel(R) Core(TM)2 Duo CPU T7250  @ 2.00GHz (1995.04-MHz 686-class CPU)
  Origin=GenuineIntel  Id=0x6fd  Family=0x6  Model=0xf  Stepping=13
  
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
  AMD Features=0x2000LM
  AMD Features2=0x1LAHF
  TSC: P-state invariant, performance statistics
real memory  = 3221225472 (3072 MB)
avail memory = 3140329472 (2994 MB)
Event timer LAPIC quality 400
ACPI APIC Table: DELL   M08
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ioapic0: Changing APIC ID to 2
ioapic0 Version 2.0 irqs 0-23 on motherboard
random: Software, Yarrow initialized
kbd1 at kbdmux0
acpi0: DELL M08 on motherboard
hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0
Timecounter HPET frequency 14318180 Hz quality 950
Event timer HPET frequency 14318180 Hz quality 450
Event timer HPET1 frequency 14318180 Hz quality 440
Event timer HPET2 frequency 14318180 Hz quality 440
acpi0: reservation of 0, 9f000 (3) failed
acpi0: reservation of 10, bf5c0400 (3) failed
cpu0: ACPI CPU on acpi0
cpu1: ACPI CPU on acpi0
atrtc0: AT realtime clock port 0x70-0x71,0x72-0x77 irq 8 on acpi0
Event 

Re: Instant panic CAM or USB subsystem

2014-01-25 Thread Steve Kargl
On Sat, Jan 25, 2014 at 09:21:06AM -0800, 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.

Panic occurs with a kernel compiled with either clang or gcc.

-- 
steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org