question about pkgng
Hi, I updated my laptop to: # uname -a FreeBSD akira.waitman.net 11.0-CURRENT FreeBSD 11.0-CURRENT #1: Sun Feb 2 21:45:49 PST 2014 r...@akira.waitman.net:/usr/obj/usr/src/sys/AKIRA amd64 Then updated ports to: # svn info Path: . Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 342366 Node Kind: directory Schedule: normal Last Changed Author: eadler Last Changed Rev: 342366 Last Changed Date: 2014-02-02 12:48:28 -0800 (Sun, 02 Feb 2014) Then I ran 'pkg update' and 'pkg upgrade' But when I went to install a new port I received errors about boost, I used pkgng to update boost. # pkg install boost-all Updating repository catalogue The following 5 packages will be installed: Upgrading icu: 4.8.1.1_1 - 50.1.2 Installing boost-jam: 1.52.0_1 Installing boost-docs: 1.52.0 Upgrading boost-libs: 1.48.0_1 - 1.52.0_2 Installing boost-all: 1.52.0 The installation will require 190 MB more space 23 MB to be downloaded Proceed with installing packages [y/N]: y ... 1) Why didn't pkg upgrade bring boost from 1.48 to 1.52 ? 2) are other packages/ports suspect on this system? Things look different, but everything is great. Thank you, -- Waitman Gobble San Jose California USA +1.510-830-7975 ___ 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
RFC: deprecation of nve(4) in 10-STABLE and removal from 11-CURRENT
Hi, for some time now we have had two drivers for NVIDIA NForce/MCP network chips, namely nve(4) and nfe(4). The former came first and is based on a binary blob. The latter was later ported from OpenBSD and is blob-free. nfe(4) supports all chips nve(4) supports, in addition to all the newer hardware. In essence, nfe(4) has been the de-facto standard driver for a long time. nve(4) has been commented out in GENERIC since 2007. For this reason I propose deprecating nve(4) in 10-STABLE and removing it from HEAD. Does anyone see a reason not to do this? Cheers, Christian (wearing my best asbestos suit) signature.asc Description: OpenPGP digital signature
Re: RFC: deprecation of nve(4) in 10-STABLE and removal from 11-CURRENT
On 02/03/2014 07:56 AM, Christian Brueffer wrote: Hi, for some time now we have had two drivers for NVIDIA NForce/MCP network chips, namely nve(4) and nfe(4). The former came first and is based on a binary blob. The latter was later ported from OpenBSD and is blob-free. nfe(4) supports all chips nve(4) supports, in addition to all the newer hardware. In essence, nfe(4) has been the de-facto standard driver for a long time. nve(4) has been commented out in GENERIC since 2007. For this reason I propose deprecating nve(4) in 10-STABLE and removing it from HEAD. Does anyone see a reason not to do this? Cheers, Christian (wearing my best asbestos suit) If you're going to be so very polite about it, how do you expect us to have a 2000 email chain fight examining every possible implication of your proposal ... :) -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ 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
installworld recreating unwanted dirs
I don't understand what I'm doing wrong here. I've added a lot of WITHOUT directives to my src.conf, but installworld seems to be ignoring them and recreating directories that make delete-old make delete-old-libs removes. Have I missed something obvious here? src.conf: WITHOUT_AMD=y WITHOUT_APM=y WITHOUT_CALENDAR=y WITHOUT_CAPSICUM=y WITHOUT_CASPER=y WITHOUT_CDDL=y WITHOUT_EXAMPLES=y WITHOUT_FLOPPY=y WITHOUT_FREEBSD_UPDATE=y WITHOUT_GAMES=y WITHOUT_GPIB=y WITHOUT_GPIO=y WITHOUT_HTML=y WITHOUT_IPFILTER=y WITHOUT_IPFW=y WITHOUT_IPX=y WITHOUT_KERBEROS=y WITHOUT_LIB32=y WITHOUT_LPR=y WITHOUT_NDIS=y WITHOUT_NETGRAPH=y WITHOUT_NIS=y WITHOUT_PC_SYSINSTALL=y WITHOUT_PMC=y WITHOUT_PPP=y WITHOUT_RCMDS=y WITHOUT_RCS=y WITHOUT_RESCUE=y WITHOUT_SHAREDOCS=y WITHOUT_SYSINSTALL=y WITHOUT_USB=y WITHOUT_WIRELESS=y # make -s installworld -- Making hierarchy -- ./etc/bluetooth missing (created) ./etc/ppp missing (created) ./games missing (created) ./lib/dtrace missing (created) ./lib32/dtrace missing (created) ./libexec/lpr missing (created) ./libexec/lpr/ru missing (created) ./share/calendar missing (created) ./share/calendar/de_AT.ISO_8859-15 missing (created) ./share/calendar/de_DE.ISO8859-1 missing (created) ./share/calendar/fr_FR.ISO8859-1 missing (created) ./share/calendar/hr_HR.ISO8859-2 missing (created) ./share/calendar/hu_HU.ISO8859-2 missing (created) ./share/calendar/pt_BR.ISO8859-1 missing (created) ./share/calendar/pt_BR.UTF-8 missing (created) ./share/calendar/ru_RU.KOI8-R missing (created) ./share/calendar/ru_RU.UTF-8 missing (created) ./share/calendar/uk_UA.KOI8-U missing (created) ./share/doc/atm missing (created) ./share/doc/smm/07.lpd missing (created) ./share/examples/hostapd missing (created) ./share/examples/ipfilter missing (created) ./share/examples/pc-sysinstall missing (created) ./share/games missing (created) ./share/games/fortune missing (created) ./share/pc-sysinstall missing (created) ./share/pc-sysinstall/backend missing (created) ./share/pc-sysinstall/backend-partmanager missing (created) ./share/pc-sysinstall/backend-query missing (created) ./share/pc-sysinstall/conf missing (created) ./share/pc-sysinstall/conf/license missing (created) ./share/pc-sysinstall/doc missing (created) ./dev/ieee488 missing (created) ./gpib missing (created) ./kadm5 missing (created) ./krb5 missing (created) ./netgraph/bluetooth missing (created) ./netgraph/bluetooth/include missing (created) ./netnatm/api missing (created) ./netnatm/msg missing (created) ./netnatm/saal missing (created) ./netnatm/sig missing (created) ___ 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: 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: installworld recreating unwanted dirs
On Mon, Feb 3, 2014 at 8:25 AM, Sean Bruno sean_br...@yahoo.com wrote: I don't understand what I'm doing wrong here. I've added a lot of WITHOUT directives to my src.conf, but installworld seems to be ignoring them and recreating directories that make delete-old make delete-old-libs removes. Have I missed something obvious here? The mtree based directory creation is (for the most part) unaware of with/without flags. There was some mtree partitioning for things like bind and those were only created if bind was enabled. But for the most part, delete-old will prune things that aren't used. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV Yes, I know, gmail sucks now. If you see this then I forgot. Habits are hard to break. ___ 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: installworld recreating unwanted dirs
On Mon, Feb 03, 2014 at 08:25:48AM -0800, Sean Bruno wrote: I don't understand what I'm doing wrong here. I've added a lot of WITHOUT directives to my src.conf, but installworld seems to be ignoring them and recreating directories that make delete-old make delete-old-libs removes. Have I missed something obvious here? Directories are created by mtree using the files in etc/mtree and the process is all or nothing. Currently only groff and sendmail have their own mtree files to allow their directories not be created. With the current file format I don't think it would be a good idea to split the mtree files to support not creating these directories. Once we switch to the new format where each directory is specified on a single line it might be practical to break up the mtree files accordingly, but that feels hard to maintain for a pretty limited benefit. -- Brooks src.conf: WITHOUT_AMD=y WITHOUT_APM=y WITHOUT_CALENDAR=y WITHOUT_CAPSICUM=y WITHOUT_CASPER=y WITHOUT_CDDL=y WITHOUT_EXAMPLES=y WITHOUT_FLOPPY=y WITHOUT_FREEBSD_UPDATE=y WITHOUT_GAMES=y WITHOUT_GPIB=y WITHOUT_GPIO=y WITHOUT_HTML=y WITHOUT_IPFILTER=y WITHOUT_IPFW=y WITHOUT_IPX=y WITHOUT_KERBEROS=y WITHOUT_LIB32=y WITHOUT_LPR=y WITHOUT_NDIS=y WITHOUT_NETGRAPH=y WITHOUT_NIS=y WITHOUT_PC_SYSINSTALL=y WITHOUT_PMC=y WITHOUT_PPP=y WITHOUT_RCMDS=y WITHOUT_RCS=y WITHOUT_RESCUE=y WITHOUT_SHAREDOCS=y WITHOUT_SYSINSTALL=y WITHOUT_USB=y WITHOUT_WIRELESS=y # make -s installworld -- Making hierarchy -- ./etc/bluetooth missing (created) ./etc/ppp missing (created) ./games missing (created) ./lib/dtrace missing (created) ./lib32/dtrace missing (created) ./libexec/lpr missing (created) ./libexec/lpr/ru missing (created) ./share/calendar missing (created) ./share/calendar/de_AT.ISO_8859-15 missing (created) ./share/calendar/de_DE.ISO8859-1 missing (created) ./share/calendar/fr_FR.ISO8859-1 missing (created) ./share/calendar/hr_HR.ISO8859-2 missing (created) ./share/calendar/hu_HU.ISO8859-2 missing (created) ./share/calendar/pt_BR.ISO8859-1 missing (created) ./share/calendar/pt_BR.UTF-8 missing (created) ./share/calendar/ru_RU.KOI8-R missing (created) ./share/calendar/ru_RU.UTF-8 missing (created) ./share/calendar/uk_UA.KOI8-U missing (created) ./share/doc/atm missing (created) ./share/doc/smm/07.lpd missing (created) ./share/examples/hostapd missing (created) ./share/examples/ipfilter missing (created) ./share/examples/pc-sysinstall missing (created) ./share/games missing (created) ./share/games/fortune missing (created) ./share/pc-sysinstall missing (created) ./share/pc-sysinstall/backend missing (created) ./share/pc-sysinstall/backend-partmanager missing (created) ./share/pc-sysinstall/backend-query missing (created) ./share/pc-sysinstall/conf missing (created) ./share/pc-sysinstall/conf/license missing (created) ./share/pc-sysinstall/doc missing (created) ./dev/ieee488 missing (created) ./gpib missing (created) ./kadm5 missing (created) ./krb5 missing (created) ./netgraph/bluetooth missing (created) ./netgraph/bluetooth/include missing (created) ./netnatm/api missing (created) ./netnatm/msg missing (created) ./netnatm/saal missing (created) ./netnatm/sig missing (created) pgp16OQWZ_fAf.pgp Description: PGP signature
Re: RFC: deprecation of nve(4) in 10-STABLE and removal from 11-CURRENT
On 03 Feb 2014, at 15:23, Tim Daneliuk tun...@tundraware.com wrote: On 02/03/2014 07:56 AM, Christian Brueffer wrote: Hi, for some time now we have had two drivers for NVIDIA NForce/MCP network chips, namely nve(4) and nfe(4). The former came first and is based on a binary blob. The latter was later ported from OpenBSD and is blob-free. nfe(4) supports all chips nve(4) supports, in addition to all the newer hardware. In essence, nfe(4) has been the de-facto standard driver for a long time. nve(4) has been commented out in GENERIC since 2007. For this reason I propose deprecating nve(4) in 10-STABLE and removing it from HEAD. Does anyone see a reason not to do this? Cheers, Christian (wearing my best asbestos suit) If you're going to be so very polite about it, how do you expect us to have a 2000 email chain fight examining every possible implication of your proposal ... :) in other words, just do it [tm]. -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ 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 -- /\ Best regards, | re...@freebsd.org \ / Remko Lodder | remko@EFnet Xhttp://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: Message signed with OpenPGP using GPGMail
[head tinderbox] failure on arm/arm
TB --- 2014-02-04 02:10:23 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-02-04 02:10:23 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-02-04 02:10:23 - starting HEAD tinderbox run for arm/arm TB --- 2014-02-04 02:10:23 - cleaning the object tree TB --- 2014-02-04 02:10:23 - /usr/local/bin/svn stat /src TB --- 2014-02-04 02:10:28 - At svn revision 261451 TB --- 2014-02-04 02:10:29 - building world TB --- 2014-02-04 02:10:29 - CROSS_BUILD_TESTING=YES TB --- 2014-02-04 02:10:29 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-04 02:10:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-04 02:10:29 - SRCCONF=/dev/null TB --- 2014-02-04 02:10:29 - TARGET=arm TB --- 2014-02-04 02:10:29 - TARGET_ARCH=arm TB --- 2014-02-04 02:10:29 - TZ=UTC TB --- 2014-02-04 02:10:29 - __MAKE_CONF=/dev/null TB --- 2014-02-04 02:10:29 - cd /src TB --- 2014-02-04 02:10:29 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Tue Feb 4 02:10:38 UTC 2014 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Tue Feb 4 05:13:11 UTC 2014 TB --- 2014-02-04 05:13:11 - generating LINT kernel config TB --- 2014-02-04 05:13:11 - cd /src/sys/arm/conf TB --- 2014-02-04 05:13:11 - /usr/bin/make -B LINT TB --- 2014-02-04 05:13:11 - cd /src/sys/arm/conf TB --- 2014-02-04 05:13:11 - /usr/sbin/config -m LINT TB --- 2014-02-04 05:13:11 - building LINT kernel TB --- 2014-02-04 05:13:11 - CROSS_BUILD_TESTING=YES TB --- 2014-02-04 05:13:11 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-04 05:13:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-04 05:13:11 - SRCCONF=/dev/null TB --- 2014-02-04 05:13:11 - TARGET=arm TB --- 2014-02-04 05:13:11 - TARGET_ARCH=arm TB --- 2014-02-04 05:13:11 - TZ=UTC TB --- 2014-02-04 05:13:11 - __MAKE_CONF=/dev/null TB --- 2014-02-04 05:13:11 - cd /src TB --- 2014-02-04 05:13:11 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Tue Feb 4 05:13:11 UTC 2014 stage 1: configuring the kernel -- cd /src/sys/arm/conf; PATH=/obj/arm.arm/src/tmp/legacy/usr/sbin:/obj/arm.arm/src/tmp/legacy/usr/bin:/obj/arm.arm/src/tmp/legacy/usr/games:/obj/arm.arm/src/tmp/legacy/bin:/obj/arm.arm/src/tmp/usr/sbin:/obj/arm.arm/src/tmp/usr/bin:/obj/arm.arm/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /obj/arm.arm/src/sys/LINT /src/sys/arm/conf/LINT WARNING: duplicate option `GEOM_PART_BSD' encountered. WARNING: duplicate option `GEOM_PART_MBR' encountered. WARNING: duplicate option `DEV_MEM' encountered. WARNING: duplicate device `mem' encountered. WARNING: duplicate option `CAM_DEBUG_DELAY' encountered. standard entry arm/econa/ehci_ebus.c has optional inclusion specifier ehci! *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-02-04 05:13:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-04 05:13:12 - ERROR: failed to build LINT kernel TB --- 2014-02-04 05:13:12 - 8746.76 user 1635.26 system 10968.73 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full ___ 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: question about pkgng
On Sun, February 2, 2014 4:58 pm, Waitman Gobble wrote: Hi, I updated my laptop to: # uname -a FreeBSD akira.waitman.net 11.0-CURRENT FreeBSD 11.0-CURRENT #1: Sun Feb 2 21:45:49 PST 2014 r...@akira.waitman.net:/usr/obj/usr/src/sys/AKIRA amd64 Scratch this question, it turned out to be faster to just wipe out /usr/local and start fresh, in this case. Thanks -- Waitman Gobble San Jose California USA +1.510-830-7975 ___ 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: 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
