Re: Instant panic CAM or USB subsystem
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
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
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
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
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
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
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
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
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