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:  at usbus3
umass1:  on usbus3
cd1 at umass-sim1 bus 1 scbus5 target 0 lun 0
cd1:  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=0x14
cd2 at umass-sim1 bus 1 scbus5 target 0 lun 1
cd2:  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=0x14

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:  at usbus3 (disconnected)
umass1: at uhub3, port 2, addr 2 (disconnected)
cd1 at umass-sim1 bus 1 scbus5 target 0 lun 0
cd1:  s/n 0002 detached
cd2 at umass-sim1 bus 1 scbus5 target 0 lun 1
cd2:  s/n 0002 detached
(cd2:umass-sim1:1:0:1): Periph destroyed
(cd1:umass-sim1:1:0:0): Periph destroyed
ugen3.2:  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 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:  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=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
___
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:  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=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.
> 

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=, 
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=)
at /usr/src/sys/cam/cam_xpt.c:5276
#20 0xc0723daf in fork_exit (callout=0xc047edb0 )
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=, 
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-curre

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"

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:  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=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'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 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 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:  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=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
___
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-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"

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:  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=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

(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=) 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=, code=-1056387128)
at /usr/src/sys/ddb/db_main.c:231
#5  0xc078a9f8 in kdb_trap (type=, code=, 
tf=) at /usr/src/sys/kern/subr_kdb.c:656
#6  0xc0a112f2 in trap (frame=) 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=) 
at cpufunc.h:71
#9  0xc07546c3 in vpanic (fmt=, ap=)
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=, 
file=0x12 , line=1309824) at 
/usr/src/sys/kern/kern_mutex.c:793
#12 0xc047333c in cam_periph_find (name=) at 
/usr/src/sys/cam/cam_periph.c:301
#13 0xc0491062 in cdregister (periph=, arg=0xc72ee22c)
at /usr/src/sys/cam/scsi/scsi_cd.c:1007
#14 0xc047313c in cam_periph_alloc (name=, 
path=0xc752d490, 
ac_callback=, code=) at 
/usr/src/sys/cam/cam_periph.c:249
#15 0xc04907cc in cdasync (callback_arg=, code=, 
arg=0xc78cd000) at /usr/src/sys/cam/scsi/scsi_cd.c:548
#16 0xc047d485 in xpt_async_process_dev (device=, 
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=) at 
/usr/src/sys/cam/cam_xpt.c:5274
#20 0xc07234df in fork_exit (callout=0xc047eb90 ) 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=0xbfebfbff
  Features2=0xe3bd
  AMD Features=0x2000
  AMD Features2=0x1
  TSC: P-state invariant, performance statistics
real memory  = 3221225472 (3072 MB)
avail memory = 3140329472 (2994 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: 
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  irqs 0-23 on motherboard
random:  initialized
kbd1 at kbdmux0
acpi0:  on motherboard
hpet0:  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:  on acpi0
cpu1:  on acpi0
atrtc0:  port 0x70-0x71,0x72-0x77 irq 8 on acpi0
Event timer "RTC" frequency 32768 Hz quality 0
attimer0:  port 0x40-0x43,0x50-0x53 irq 2 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
vgapci0:  port 0xefe8-0xefef mem 
0xfea0-0xfeaf,0xe000-0xefff irq 16 at device 2.0 on pci0
agp0:  on vgapci0
agp0: aperture size is 256M, detected 7676k stolen memory
drm0:  on vgapci0
info: [drm] MSI enabled 1 message(s)
info: [drm] AGP at 0xe000 256MB
info: [drm] Initialized i915 1.6.0 20080730
vg