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: 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"
[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: RFC: deprecation of nve(4) in 10-STABLE and removal from 11-CURRENT
On 03 Feb 2014, at 15:23, Tim Daneliuk 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
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: installworld recreating unwanted dirs
On Mon, Feb 3, 2014 at 8:25 AM, 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? 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: 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
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: 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"
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
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"