FreeBSD on MacBook Air 2013
Hi Has anyone managed to install FreeBSD on the latest MacBook Air? Be happy to hear any tips or pointers... Johannes Lundberg BRILLIANTSERVICE CO., LTD. http://www.brilliantservice.co.jp ___ 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
[net] protecting interfaces from races between control and data ?
i am slightly unclear of what mechanisms we use to prevent races between interface being reconfigured (up/down/multicast setting, etc, all causing reinitialization of the rx and tx rings) and i) packets from the host stack being sent out; ii) interrupts from the network card being processed. I think in the old times IFF_DRV_RUNNING was used for this purpose, but now it is not enough. Acquiring the core lock in the NIC does not seem enough, either, because newer drivers, especially multiqueue ones, have per-queue rx and tx locks. Does anyone know if there is a generic mechanism, or each driver reimplements its own way ? thanks luigi ___ 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: svn error during 'make buildkernel'?
On Sat, 3 Aug 2013 22:04:56 -0400 Glen Barber g...@freebsd.org wrote: On Sun, Aug 04, 2013 at 08:10:09AM +0800, Erich Dollansky wrote: doesn't this show again that svn came a bit early? No, it shows that people do not keep their third-party software up to date. Glen what about devel/subversion17? ;-) Why I _must_ update my svn client to 1.8.x ? I can do svn checkout/update/etc with 1.7 installed, BUT I also want to see svn revision when I run uname -a. We are talking about that some time ago on efnet. newvers.sh should check exit code. [tiger@laptop]:~/vcs/sysadm%svnversion svn: E155036: The working copy at '/usr/home/tiger/vcs/sysadm' is too old (format 29) to work with client version '1.8.1 (r1503906)' (expects format 31). You need to upgrade the working copy first. [tiger@laptop]:~/vcs/sysadm%echo $? 1 [tiger@laptop]:~/vcs/sysadm%svn upgrade Upgraded '.' [tiger@laptop]:~/vcs/sysadm%svnversion 13 [tiger@laptop]:~/vcs/sysadm%echo $? 0 -- wbr, tiger ___ 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: svn error during 'make buildkernel'?
On Sun, 4 Aug 2013 20:57:04 -0400 Glen Barber g...@freebsd.org wrote: On Sun, Aug 04, 2013 at 05:50:28PM -0700, Steve Kargl wrote: If you are disinclined to fix your commit, then consider this an official request to back out revision 252505. You are the first and only one to complain after this change was in effect for 2 months. that is not true. _same_ ML: Jul,14 'lost my r2x subversion id in uname kern.version' I am sorry that you do not keep your ports up to date. But this is -CURRENT, not -RELEASE. Change is expected, roads may be bumpy, etc. Glen -- wbr, tiger ___ 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: control of order of inet devices
Hello Brooks, On Wed, Apr 17, 2013 at 03:01:27PM -0500, Brooks Davis wrote: On Wed, Apr 17, 2013 at 04:27:44AM -0500, Joshua Isom wrote: On 4/17/2013 4:14 AM, Willy Offermans wrote: This is what I read in some of the articles or handbook as well. Can I reorder this linked list? Can I control the order by creating the kernel and reordering the inclusion of the device drivers? I am aware that the request sounds silly, but I have a third party program which checks its licence against the first inet device. Since I have added a new inet controller, the sequence has changed. Of course I ask for a new licence, but they want to charge me for that and I do not see any reason for that. Load old inet devices like normal, in loader.conf. Then load the new device driver before networking, after rc's started. If it'd because of probe order, then you might just have to control the probe order the hard way. If the program's calling ifconfig itself, you could write a wrapper to resort the output. And call a lawyer, getting a new ethernet card shouldn't void a license. It wouldn't be particularly hard to influence the sorting of the list if you're willing to modify the if_attach_internal() function and always insert devices with that name at the beginning. It just doesn't seem very general purpose so I'd have a hard time considering including it. -- Brooks I see und subscribe to your point. However it is not clear to me how the order is established. Maybe if I know that, I can influence the order. Can you comment on that? Where can I find the code for the if_attach_internal() function? Digging into the code might also elucidate a lot of things, so I need to ask less :). Maybe I will change the code a bit to suite my wishes. If that is the case, I will inform the list and show the code. Maybe it is useful. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 e-mail: wi...@offermans.rompen.nl ___ 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
Linux epoll(7) patch
There is the patch, suggested by Roman Divacky, implementing Linux epoll(7) functionality: http://rys.vlakno.cz/~rdivacky/patches/linux_epoll.patch This patch was suggested 5 years ago and was discussed on emulation@: http://lists.freebsd.org/pipermail/freebsd-emulation/2008-March/004409.html http://lists.freebsd.org/pipermail/freebsd-emulation/2008-March/004428.html Discussion stalled back then, and epoll is still unimplemented. Anybody can identify any issues with this patch? Are there any alternatives? Yuri ___ 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: svn error during 'make buildkernel'?
On Mon, Aug 5, 2013 at 12:08 PM, Sergey V. Dyatko sergey.dya...@gmail.com wrote: On Sun, 4 Aug 2013 20:57:04 -0400 Glen Barber g...@freebsd.org wrote: On Sun, Aug 04, 2013 at 05:50:28PM -0700, Steve Kargl wrote: If you are disinclined to fix your commit, then consider this an official request to back out revision 252505. You are the first and only one to complain after this change was in effect for 2 months. that is not true. _same_ ML: Jul,14 'lost my r2x subversion id in uname kern.version' Your problem is that don't really the UPDATING instructions. There are clear instructions on how you can stay with the 1.7 version of subversion. Nothing forces you to update to 1.8., that has been already established in this discussion. -Kimmo ___ 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: svn error during 'make buildkernel'?
On Mon, 5 Aug 2013 13:36:29 +0300 Kimmo Paasiala kpaas...@gmail.com wrote: On Mon, Aug 5, 2013 at 12:08 PM, Sergey V. Dyatko sergey.dya...@gmail.com wrote: On Sun, 4 Aug 2013 20:57:04 -0400 Glen Barber g...@freebsd.org wrote: On Sun, Aug 04, 2013 at 05:50:28PM -0700, Steve Kargl wrote: If you are disinclined to fix your commit, then consider this an official request to back out revision 252505. You are the first and only one to complain after this change was in effect for 2 months. that is not true. _same_ ML: Jul,14 'lost my r2x subversion id in uname kern.version' Your problem is that don't really the UPDATING instructions. There are clear instructions on how you can stay with the 1.7 version of I'm using fresh version of devel/subversion (1.8) and I forced to do svn upgrade for all my old checkouts. Now we are talking about another things subversion. Nothing forces you to update to 1.8., that has been already established in this discussion. wrong. newvers.sh use 1.8.x client from base. Yes, that is NOT fatal error, sure. Revision will not be listed in the `uname -a` output, that is not right! Steve have subversion 1.7 installed AND 1.7 checkout. `svnversion /usr/src/` output is correct for him, but NOT `svnliteversion /usr/src/` ;-) -Kimmo -- wbr, tiger ___ 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: Kernel Panic on FreeBSD 10.0-CURRENT #1 r253918
Can you try to update the kernel to r253950 or later? This is probably because one of my recent commits broke IPv6 temporary address timer on non-IPv6 interfaces. -- Hiroki I just built a kernel based on r253950, I will keep the list updated if the panic happens again -- Sam Fourman Jr. ___ 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: [net] protecting interfaces from races between control and data ?
On Aug 5, 2013, at 2:23 AM, Luigi Rizzo ri...@iet.unipi.it wrote: i am slightly unclear of what mechanisms we use to prevent races between interface being reconfigured (up/down/multicast setting, etc, all causing reinitialization of the rx and tx rings) and i) packets from the host stack being sent out; ii) interrupts from the network card being processed. I think in the old times IFF_DRV_RUNNING was used for this purpose, but now it is not enough. Acquiring the core lock in the NIC does not seem enough, either, because newer drivers, especially multiqueue ones, have per-queue rx and tx locks. Does anyone know if there is a generic mechanism, or each driver reimplements its own way ? I'll speak to the RX side of the question. Several years ago I modified the if_em driver to use a fast interrupt handler that would signal actual processing in a taskqueue thread. The result was a system with no more latency than the classic ithread model, but with the ability to allow RX processing to be halted, drained, and restarted via an explicit API. This in turn was extended to cause the RX processing to be safely paused during the control events that you described above. The system worked well on many fronts, but unfortunately I was unable to actively maintain it, and it was slowly garbage collected over time. I think that it could have been extended without much effort to cover TX-complete processing. TX dispatch is a different matter, but I don't think that it would be hard to have the if_transmit/if_start path respond to control synchronization events. Scott ___ 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: [net] protecting interfaces from races between control and data ?
- Original Message - i am slightly unclear of what mechanisms we use to prevent races between interface being reconfigured (up/down/multicast setting, etc, all causing reinitialization of the rx and tx rings) and i) packets from the host stack being sent out; ii) interrupts from the network card being processed. I think in the old times IFF_DRV_RUNNING was used for this purpose, but now it is not enough. Acquiring the core lock in the NIC does not seem enough, either, because newer drivers, especially multiqueue ones, have per-queue rx and tx locks. What I've done in my drivers is: * Lock the core mutex * Clear IFF_DRV_RUNNING * Lock/unlock each queue's lock The various Rx/Tx queue functions check for IFF_DRV_RUNNING after (re)acquiring their queue lock. See at vtnet_stop_rendezvous() at [1] for an example. Does anyone know if there is a generic mechanism, or each driver reimplements its own way ? We desperately need a saner ifnet/driver interface. I think andre@ had some previous work in this area (and additional plans as well?). IMO, there's a lot to like on what DragonflyBSD has done in this area. [1] - http://svnweb.freebsd.org/base/user/bryanv/vtnetmq/sys/dev/virtio/network/if_vtnet.c?revision=252451view=markup thanks luigi ___ 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 ___ 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: Linux epoll(7) patch
On 8/5/13 2:36 AM, Yuri wrote: There is the patch, suggested by Roman Divacky, implementing Linux epoll(7) functionality: http://rys.vlakno.cz/~rdivacky/patches/linux_epoll.patch This patch was suggested 5 years ago and was discussed on emulation@: http://lists.freebsd.org/pipermail/freebsd-emulation/2008-March/004409.html http://lists.freebsd.org/pipermail/freebsd-emulation/2008-March/004428.html Discussion stalled back then, and epoll is still unimplemented. Anybody can identify any issues with this patch? Are there any alternatives? Yuri The patch is small. I too am wondering why it's not committed, was there any push back? -- Alfred Perlstein ___ 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: Linux epoll(7) patch
On Mon, Aug 5, 2013, at 10:22, Alfred Perlstein wrote: The patch is small. I too am wondering why it's not committed, was there any push back? The glory days of the Linuxulator were around FreeBSD 6 when basically everything ran and often it ran much faster. We could really use a revival of this with the FreeBSD 10 release... ___ 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: make buildworld fails
Craig Rodrigues writes: On Sat, Jun 1, 2013 at 10:47 AM, Robert Huff roberth...@rcn.com wrote: cc -O -pipe -g -DNO_PWD_OVERRIDE -I/usr/src/usr.bin/bmake -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\.../share/mk:/usr/share/mk\ -I. -I/usr/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -static -o make arch.o buf.o compat.o cond.o dir.o for.o hash.o job.o main.o make.o make_malloc.o meta.o parse.o str.o strlist.o suff.o targ.o trace.o util.o var.o lstAppend.o lstAtEnd.o lstAtFront.o lstClose.o lstConcat.o lstDatum.o lstDeQueue.o lstDestroy.o lstDupl.o lstEnQueue.o lstFind.o lstFindFrom.o lstFirst.o lstForEach.o lstForEachFrom.o lstInit.o lstInsert.o lstIsAtEnd.o lstIsEmpty.o lstLast.o lstMember.o lstNext.o lstOpen.o lstPrev.o lstRemove.o lstReplace.o lstSucc.o stresep.o sh /usr/src/tools/install.sh -o root -g wheel -m 555 make \ /usr/obj/usr/src/make.amd64/make usage: make [-BeikNnqrstWX] [-C directory] [-D variable] [-d flags] [-f makefile] [-I directory] [-J private] [-j max_jobs] [-m directory] [-T file] [-V variable] [variable=value] [target ...] *** [buildworld] Error code 2 Stop in /usr/src. Without touching anything in your tree, can you provide some more information: (1) What is the output of /usr/bin/make -V MAKE_VERSION 10201205300 (2) What is the output of /usr/obj/usr/src/make.amd64/make -V MAKE_VERSION 20130520 (4) What is the GRN version of your tree? If you updated with svn directly, you can find out with svn info /usr/src Working Copy Root Path: /usr/src URL: svn://svn0.us-east.freebsd.org/base/head Repository Root: svn://svn0.us-east.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 251213 Node Kind: directory Schedule: normal Last Changed Author: np Last Changed Rev: 251213 Last Changed Date: 2013-05-31 22:07:37 -0400 (Fri, 31 May 2013) Thanks for providing the information. This looks related to the latest change to switch to bmake. I don't understand how all the pieces of the puzzle fit together to 100% diagnose the problem, but an you try the following: (1) Completely blow away the obj tree with: rm -fr /usr/obj (2) Update the source tree under /usr/src to the latest revision with svn update (3) Try again: make -d l buildworld Done; the results are appended. SVN info: Working Copy Root Path: /usr/src URL: svn://svn0.us-east.freebsd.org/base/head Relative URL: ^/head Repository Root: svn://svn0.us-east.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 253964 Node Kind: directory Schedule: normal Last Changed Author: mav Last Changed Rev: 253960 Last Changed Date: 2013-08-05 08:15:53 -0400 (Mon, 05 Aug 2013) Sorry for the delay. Robert Huff (cd /usr/src make bmake) echo echo -- -- echo Building an up-to-date make(1) Building an up-to-date make(1) echo -- -- cd /usr/src/usr.bin/bmake; MAKEOBJDIRPREFIX=/usr/obj/usr/src/make.amd64 DESTDIR= INSTALL=sh /usr/src/tools/install.sh make -D_UPGRADING -DNOMAN -DNO_MAN -DNOSHARED -DNO_SHARED -DNO_CPU_CFLAGS -DNO_WERROR obj MAKEOBJDIRPREFIX=/usr/obj/usr/src/make.amd64 DESTDIR= INSTALL=sh /usr/src/tools/install.sh make -D_UPGRADING -DNOMAN -DNO_MAN -DNOSHARED -DNO_SHARED -DNO_CPU_CFLAGS -DNO_WERROR depend MAKEOBJDIRPREFIX=/usr/obj/usr/src/make.amd64 DESTDIR= INSTALL=sh /usr/src/tools/install.sh make -D_UPGRADING -DNOMAN -DNO_MAN -DNOSHARED -DNO_SHARED -DNO_CPU_CFLAGS -DNO_WERROR all MAKEOBJDIRPREFIX=/usr/obj/usr/src/make.amd64 DESTDIR= INSTALL=sh /usr/src/tools/install.sh make -D_UPGRADING -DNOMAN -DNO_MAN -DNOSHARED -DNO_SHARED -DNO_CPU_CFLAGS -DNO_WERROR install DESTDIR=/usr/obj/usr/src/make.amd64 BINDIR= PROGNAME=bmake if ! test -d /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/; then mkdir -p /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake; if ! test -d /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/; then echo Unable to create /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake.; exit 1; fi; echo /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake created for /usr/src/usr.bin/bmake;
Re: Linux epoll(7) patch
On Mon, Aug 05, 2013 at 08:22:05AM -0700, Alfred Perlstein wrote: On 8/5/13 2:36 AM, Yuri wrote: There is the patch, suggested by Roman Divacky, implementing Linux epoll(7) functionality: http://rys.vlakno.cz/~rdivacky/patches/linux_epoll.patch This patch was suggested 5 years ago and was discussed on emulation@: http://lists.freebsd.org/pipermail/freebsd-emulation/2008-March/004409.html http://lists.freebsd.org/pipermail/freebsd-emulation/2008-March/004428.html Discussion stalled back then, and epoll is still unimplemented. Anybody can identify any issues with this patch? Are there any alternatives? Yuri The patch is small. I too am wondering why it's not committed, was there any push back? iirc the main problem with the patch is that it doesnt work over fork, I never got to implement that feature. Nevertheless it looks like the patch is useful even without that feature so maybe it should just be commited? Roman ___ 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: Linux epoll(7) patch
The glory days of the Linuxulator were around FreeBSD 6 when basically everything ran and often it ran much faster. We could really use a revival of this with the FreeBSD 10 release... ___ 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 epoll is needed to get the linux version of plex media server working in FreeNAS, however in the last month or so it looks as if a FreeBSD native app has been released also I believe Yuri is working on a Linuxulator refresh up to at least Fedora 19 -- Sam Fourman Jr. ___ 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: Linux epoll(7) patch
On Mon, Aug 05, 2013 at 05:25:56PM +0200, Roman Divacky wrote: On Mon, Aug 05, 2013 at 08:22:05AM -0700, Alfred Perlstein wrote: On 8/5/13 2:36 AM, Yuri wrote: There is the patch, suggested by Roman Divacky, implementing Linux epoll(7) functionality: http://rys.vlakno.cz/~rdivacky/patches/linux_epoll.patch This patch was suggested 5 years ago and was discussed on emulation@: http://lists.freebsd.org/pipermail/freebsd-emulation/2008-March/004409.html http://lists.freebsd.org/pipermail/freebsd-emulation/2008-March/004428.html Discussion stalled back then, and epoll is still unimplemented. Anybody can identify any issues with this patch? Are there any alternatives? Yuri The patch is small. I too am wondering why it's not committed, was there any push back? iirc the main problem with the patch is that it doesnt work over fork, I never got to implement that feature. Nevertheless it looks like the patch is useful even without that feature so maybe it should just be commited? What happens to fd after the fork? Is it closed or simply remains non-functional? If the former, I suggest the patch is altered to leave fd with badfdops in place so that epoll users get less surprised. -- Mateusz Guzik mjguzik gmail.com ___ 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: [net] protecting interfaces from races between control and data ?
On 5 August 2013 07:59, Bryan Venteicher bry...@daemoninthecloset.org wrote: What I've done in my drivers is: * Lock the core mutex * Clear IFF_DRV_RUNNING * Lock/unlock each queue's lock .. and I think that's the only sane way of doing it. I'm going to (soon) propose something similar for cxgbe/ixgbe as we use these NICs at work, then feed this experiment back into the network stack so we can have a unified way of doing this. You may also want to synchronize against the driver TX/RX/core locks and state when doing things like, say, halting DMA in preparation for multicast reprogramming on some hardware; or even doing a chip reset. I had to hand-roll this for ath(4) to make it completely correct - any kind of overlapping reset, reset during TX, reset during RX etc would cause all kinds of instability and random-crap-scribbled-everywhere issues. So yes, this is a larger scale issue that needs to be solved. -adrian ___ 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: Linux epoll(7) patch
On Mon, Aug 5, 2013, at 10:36, Sam Fourman Jr. wrote: epoll is needed to get the linux version of plex media server working in FreeNAS, however in the last month or so it looks as if a FreeBSD native app has been released I'm working closely with Elan (head of Plex) and expect to be committing a port to the tree soon. You can test the port here: https://github.com/felderado/plexmediaserver_port/ I believe the FreeBSD version at this time lacks the ability to auto-detect filesystem changes so manual scanning or notification from your download software will be required. Sickbeard and Couch Potato can do this, for example. ___ 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: [net] protecting interfaces from races between control and data ?
On Mon, Aug 5, 2013 at 5:46 PM, Adrian Chadd adr...@freebsd.org wrote: On 5 August 2013 07:59, Bryan Venteicher bry...@daemoninthecloset.org wrote: What I've done in my drivers is: * Lock the core mutex * Clear IFF_DRV_RUNNING * Lock/unlock each queue's lock .. and I think that's the only sane way of doing it. yeah, this was also the solution we had in mind, i was surprised not find this pattern in the drivers i have looked at. Also there are drivers (chelsio ?) which do not seem to have locks on the receive interrupt handlers ? Does anyone know how linux copes with the same problem ? They seem to have an rtnl_lock() which is a global lock for all configuration of netdevices (would replace our per-interface 'core lock' above), but i am totally unclear on how individual tx threads and interrupt handlers acknowledge that they have read the change in status. cheers luigi ___ 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: make buildworld fails
05.08.2013 19:33, Robert Huff пишет:
cd /usr/src; PATH=/sbin:/bin:/usr/sbin:/usr/bin `test -x
/usr/obj/usr/src/make.amd64/bmake echo /usr/obj/usr/src/make.amd64/bmake
|| echo make` -m /usr/src/share/mk -f Makefile.inc1 TARGET=amd64
TARGET_ARCH=amd64 buildworld
usage: bmake [-BeikNnqrstWwX]
[-C directory] [-D variable] [-d flags] [-f makefile]
[-I directory] [-J private] [-j max_jobs] [-m directory] [-T file]
[-V variable] [variable=value] [target ...]
*** [buildworld] Error code 2
This note from /usr/src/UPDATING may be relevant:
-
20130613:
Some people report the following error after the switch to bmake:
make: illegal option -- J
usage: make [-BPSXeiknpqrstv] [-C directory] [-D variable]
...
*** [buildworld] Error code 2
this likely due to an old instance of make in
${MAKEPATH} (${MAKEOBJDIRPREFIX}${.CURDIR}/make.${MACHINE})
which src/Makefile will use that blindly, if it exists, so if
you see the above error:
rm -rf `make -V MAKEPATH`
should resolve it.
-
--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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: Kernel Panic on FreeBSD 10.0-CURRENT #1 r253918
On Sun, 4 Aug 2013 18:59:56 -0400 Sam Fourman Jr. sfour...@gmail.com wrote: On Sun, Aug 4, 2013 at 6:52 PM, Craig Rodrigues rodr...@freebsd.org wrote: On Sun, Aug 4, 2013 at 12:33 PM, Sam Fourman Jr. sfour...@gmail.comwrote: hello list, could someone help me figure out why this machine kernel paniced? I have a full crashdump file if needed, this machine is configured as a Firewall and wifi hostap running pf in a small office here is a mailing list post to someone that had a similar problem a few years back http://lists.freebsd.org/pipermail/freebsd-bugs/2011-April/043985.html a backtrace, full dmesg, and kernel config are below kgdb /boot/kernel/kernel /var/crash/vmcore.0 #4 0x80bd6027 in trap_pfault (frame=0x0, usermode=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:699 #5 0x80bd5876 in trap (frame=0xff80002787c0) at /usr/src/sys/amd64/amd64/trap.c:463 #6 0x80bc06b2 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #7 0x809937a8 in in6_tmpaddrtimer (arg=0xfe00170fc0b6) at /usr/src/sys/netinet6/in6_ifattach.c:935 #8 0x8085140a in softclock_call_cc (c=0x81325210, cc=0x8131c700, direct=0) at /usr/src/sys/kern/kern_timeout.c:674 #9 0x80851704 in softclock (arg=value optimized out) at /usr/src/sys/kern/kern_timeout.c:802 #10 0x80815dc3 in intr_event_execute_handlers (p=value optimized out, ie=0xfe0014ab3400) at /usr/src/sys/kern/kern_intr.c:1263 #11 0x80816716 in ithread_loop (arg=0xfe0014a896e0) at /usr/src/sys/kern/kern_intr.c:1276 #12 0x80813b31 in fork_exit (callout=0x80816680 ithread_loop, arg=0xfe0014a896e0, frame=0xff8000278a40) at /usr/src/sys/kern/kern_fork.c:991 #13 0x80bc0bee in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:606 #14 0x in ?? () Current language: auto; currently minimal (kgdb) You have VIMAGE enabled in your kernel config. I have debugged a few of these VIMAGE problems before. Can you do the following for me: Craig, Thank you for getting back to me, I will get to work on this right away and get you what you need. but are we CERTAIN this panic could be from VIMAGE? I totally thought I had a # infront of that line when I built this kernel... if you notice I did post the kernel config at the bottom of that email, and VIMAGE is NOT included... but maybe I did something wrong and somehow built VIMAGE in anyway.. is there some sort of command I can run to ask the system if it does indeed have VIMAGE? kldstat -v maybe? Seems to list every module in the kernel. I don't have VIMAGE enabled so can't say whether it will really appear. -- Gary Jennejohn ___ 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: [net] protecting interfaces from races between control and data ?
On 08/05/13 09:15, Luigi Rizzo wrote: On Mon, Aug 5, 2013 at 5:46 PM, Adrian Chadd adr...@freebsd.org wrote: On 5 August 2013 07:59, Bryan Venteicher bry...@daemoninthecloset.org wrote: What I've done in my drivers is: * Lock the core mutex * Clear IFF_DRV_RUNNING * Lock/unlock each queue's lock .. and I think that's the only sane way of doing it. yeah, this was also the solution we had in mind, i was surprised not find this pattern in the drivers i have looked at. Also there are drivers (chelsio ?) which do not seem to have locks on the receive interrupt handlers ? This is correct. cxgbe(4) does not have any locks on rx, just a state for each rx queue that's maintained with atomic ops. Regards, Navdeep Does anyone know how linux copes with the same problem ? They seem to have an rtnl_lock() which is a global lock for all configuration of netdevices (would replace our per-interface 'core lock' above), but i am totally unclear on how individual tx threads and interrupt handlers acknowledge that they have read the change in status. cheers luigi ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ 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: [net] protecting interfaces from races between control and data ?
I'm travelling back to San Jose today; poke me tomorrow and I'll brain dump what I did in ath(4) and the lessons learnt. The TL;DR version - you don't want to grab an extra lock in the read/write paths as that slows things down. Reuse the same per-queue TX/RX lock and have: * a reset flag that is set when something is resetting; that says to the queue don't bother processing anything, just dive out; * 'i am doing Tx / Rx' flags per queue that is set at the start of TX/RX servicing and finishes at the end; that way the reset code knows if there's something pending; * have the reset path grab each lock, set the 'reset' flag on each, then walk each queue again and make sure they're all marked as 'not doing TX/RX'. At that point the reset can occur, then the flag cna be cleared, then TX/RX can resume. -adrian On 5 August 2013 10:13, Navdeep Parhar n...@freebsd.org wrote: On 08/05/13 09:15, Luigi Rizzo wrote: On Mon, Aug 5, 2013 at 5:46 PM, Adrian Chadd adr...@freebsd.org wrote: On 5 August 2013 07:59, Bryan Venteicher bry...@daemoninthecloset.org wrote: What I've done in my drivers is: * Lock the core mutex * Clear IFF_DRV_RUNNING * Lock/unlock each queue's lock .. and I think that's the only sane way of doing it. yeah, this was also the solution we had in mind, i was surprised not find this pattern in the drivers i have looked at. Also there are drivers (chelsio ?) which do not seem to have locks on the receive interrupt handlers ? This is correct. cxgbe(4) does not have any locks on rx, just a state for each rx queue that's maintained with atomic ops. Regards, Navdeep Does anyone know how linux copes with the same problem ? They seem to have an rtnl_lock() which is a global lock for all configuration of netdevices (would replace our per-interface 'core lock' above), but i am totally unclear on how individual tx threads and interrupt handlers acknowledge that they have read the change in status. cheers luigi ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ 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: [net] protecting interfaces from races between control and data ?
.. and I bet it's not a design pattern, and this is total conjecture on my part: * the original drivers weren't SMP safe; * noone really sat down and figured out how to correctly synchronise all of this stuff; * people did the minimum amount of work to keep the driver from immediately crashing, but didn't really think things through at a larger scale. Almost every driver is this way Luigi. :-) -adrian ___ 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: Kernel Panic on FreeBSD 10.0-CURRENT #1 r253918
On Sun, Aug 4, 2013 at 3:59 PM, Sam Fourman Jr. sfour...@gmail.com wrote: Craig, Thank you for getting back to me, I will get to work on this right away and get you what you need. but are we CERTAIN this panic could be from VIMAGE? I totally thought I had a # infront of that line when I built this kernel... if you notice I did post the kernel config at the bottom of that email, and VIMAGE is NOT included... but maybe I did something wrong and somehow built VIMAGE in anyway.. is there some sort of command I can run to ask the system if it does indeed have VIMAGE? On the booted an running system, if you type: sysctl kern.conftxt that will display the actual kernel config options used to build the running kernel. This is handy because once or twice when doing development, I edited a kernel config file and forgot to rebuild the kernel before installing it. It would still be useful if you could run through those steps which I gave you and provide the debugging output, just to double check. -- Craig ___ 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: [net] protecting interfaces from races between control and data ?
On Mon, Aug 5, 2013 at 7:17 PM, Adrian Chadd adr...@freebsd.org wrote: I'm travelling back to San Jose today; poke me tomorrow and I'll brain dump what I did in ath(4) and the lessons learnt. The TL;DR version - you don't want to grab an extra lock in the read/write paths as that slows things down. Reuse the same per-queue TX/RX lock and have: * a reset flag that is set when something is resetting; that says to the queue don't bother processing anything, just dive out; * 'i am doing Tx / Rx' flags per queue that is set at the start of TX/RX servicing and finishes at the end; that way the reset code knows if there's something pending; * have the reset path grab each lock, set the 'reset' flag on each, then walk each queue again and make sure they're all marked as 'not doing TX/RX'. At that point the reset can occur, then the flag cna be cleared, then TX/RX can resume. so this is slightly different from what Bryan suggested (and you endorsed) before, as in that case there was a single 'reset' flag IFF_DRV_RUNNING protected by the 'core' lock, then a nested round on all tx and rx locks to make sure that all customers have seen it. In both cases the tx and rx paths only need the per-queue lock. As i see it, having a per-queue reset flag removes the need for nesting core + queue locks, but since this is only in the control path perhaps it is not a big deal (and is better to have a single place to look at to tell whether or not we should bail out). cheers luigi ___ 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: [net] protecting interfaces from races between control and data ?
On Aug 5, 2013, at 11:20 AM, Adrian Chadd adr...@freebsd.org wrote: .. and I bet it's not a design pattern, and this is total conjecture on my part: * the original drivers weren't SMP safe; * noone really sat down and figured out how to correctly synchronise all of this stuff; * people did the minimum amount of work to keep the driver from immediately crashing, but didn't really think things through at a larger scale. Almost every driver is this way Luigi. :-) Yes, but let me expand. The original work to make NIC drivers SMP focused around just putting everything under 1 lock. The lock was acquired in if_start and held through the transmission of the packet, it was held in if_ioctl all the way through whatever action was taken, and it was held in the interrupt handler over all of the RX and TX-complete processing. This worked fine up until the RX path called if_input() with the netisr path set for direct dispatch. In this mode, the code could flow up the stack and then immediately back down into the if_start handler for the driver, where it would try to acquire the same lock again. Also, it meant that forwarding packets between to interfaces would have the lock from the RX context of one interface held into the TX context of the other interface. Obviously, this was a big mess, so the solution was to just drop the lock around the call to if_input(). No consideration was made for driver state that might change during the lock release, nor was any consideration made for the performance impact of dropping the lock on every packet and then having to contend with top-half TX threads to pick it back up. But this became the quick-fix pattern. As for the original question of why the RX path can operate unlocked, it's fairly easy. The RX machinery of most NICs is fairly separate from the TX machinery, so little synchronization is needed. When there's a state change in the driver, in terms of an interface going down, a queue size changing, or the driver being unloaded, it's up to the driver to pause and drain the RX processing prior to this state change. It worked well when I did it in if_em, and it appears to work well with cxgbe. Scott ___ 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: [net] protecting interfaces from races between control and data ?
Sigh, this ends up being ugly I'm afraid. I need some time to look at code and think about it. Jack On Mon, Aug 5, 2013 at 10:36 AM, Luigi Rizzo ri...@iet.unipi.it wrote: On Mon, Aug 5, 2013 at 7:17 PM, Adrian Chadd adr...@freebsd.org wrote: I'm travelling back to San Jose today; poke me tomorrow and I'll brain dump what I did in ath(4) and the lessons learnt. The TL;DR version - you don't want to grab an extra lock in the read/write paths as that slows things down. Reuse the same per-queue TX/RX lock and have: * a reset flag that is set when something is resetting; that says to the queue don't bother processing anything, just dive out; * 'i am doing Tx / Rx' flags per queue that is set at the start of TX/RX servicing and finishes at the end; that way the reset code knows if there's something pending; * have the reset path grab each lock, set the 'reset' flag on each, then walk each queue again and make sure they're all marked as 'not doing TX/RX'. At that point the reset can occur, then the flag cna be cleared, then TX/RX can resume. so this is slightly different from what Bryan suggested (and you endorsed) before, as in that case there was a single 'reset' flag IFF_DRV_RUNNING protected by the 'core' lock, then a nested round on all tx and rx locks to make sure that all customers have seen it. In both cases the tx and rx paths only need the per-queue lock. As i see it, having a per-queue reset flag removes the need for nesting core + queue locks, but since this is only in the control path perhaps it is not a big deal (and is better to have a single place to look at to tell whether or not we should bail out). cheers luigi ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ 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: [net] protecting interfaces from races between control and data ?
On Mon, Aug 5, 2013 at 7:49 PM, Jack Vogel jfvo...@gmail.com wrote: Sigh, this ends up being ugly I'm afraid. I need some time to look at code and think about it. actually the intel drivers seem in decent shape, especially if we reuse IFF_DRV_RUNNING as the reset flag and the core+queue lock in the control path. cheers luigi Jack On Mon, Aug 5, 2013 at 10:36 AM, Luigi Rizzo ri...@iet.unipi.it wrote: On Mon, Aug 5, 2013 at 7:17 PM, Adrian Chadd adr...@freebsd.org wrote: I'm travelling back to San Jose today; poke me tomorrow and I'll brain dump what I did in ath(4) and the lessons learnt. The TL;DR version - you don't want to grab an extra lock in the read/write paths as that slows things down. Reuse the same per-queue TX/RX lock and have: * a reset flag that is set when something is resetting; that says to the queue don't bother processing anything, just dive out; * 'i am doing Tx / Rx' flags per queue that is set at the start of TX/RX servicing and finishes at the end; that way the reset code knows if there's something pending; * have the reset path grab each lock, set the 'reset' flag on each, then walk each queue again and make sure they're all marked as 'not doing TX/RX'. At that point the reset can occur, then the flag cna be cleared, then TX/RX can resume. so this is slightly different from what Bryan suggested (and you endorsed) before, as in that case there was a single 'reset' flag IFF_DRV_RUNNING protected by the 'core' lock, then a nested round on all tx and rx locks to make sure that all customers have seen it. In both cases the tx and rx paths only need the per-queue lock. As i see it, having a per-queue reset flag removes the need for nesting core + queue locks, but since this is only in the control path perhaps it is not a big deal (and is better to have a single place to look at to tell whether or not we should bail out). cheers luigi ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org -- -+--- Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/. Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -+--- ___ 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: [net] protecting interfaces from races between control and data ?
No, brian said two things: * the flag, protected by the core lock * per-queue flags -adrian ___ 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: [net] protecting interfaces from races between control and data ?
What do you think about this change? Cheers, Jack On Mon, Aug 5, 2013 at 10:58 AM, Luigi Rizzo ri...@iet.unipi.it wrote: On Mon, Aug 5, 2013 at 7:49 PM, Jack Vogel jfvo...@gmail.com wrote: Sigh, this ends up being ugly I'm afraid. I need some time to look at code and think about it. actually the intel drivers seem in decent shape, especially if we reuse IFF_DRV_RUNNING as the reset flag and the core+queue lock in the control path. cheers luigi Jack On Mon, Aug 5, 2013 at 10:36 AM, Luigi Rizzo ri...@iet.unipi.it wrote: On Mon, Aug 5, 2013 at 7:17 PM, Adrian Chadd adr...@freebsd.org wrote: I'm travelling back to San Jose today; poke me tomorrow and I'll brain dump what I did in ath(4) and the lessons learnt. The TL;DR version - you don't want to grab an extra lock in the read/write paths as that slows things down. Reuse the same per-queue TX/RX lock and have: * a reset flag that is set when something is resetting; that says to the queue don't bother processing anything, just dive out; * 'i am doing Tx / Rx' flags per queue that is set at the start of TX/RX servicing and finishes at the end; that way the reset code knows if there's something pending; * have the reset path grab each lock, set the 'reset' flag on each, then walk each queue again and make sure they're all marked as 'not doing TX/RX'. At that point the reset can occur, then the flag cna be cleared, then TX/RX can resume. so this is slightly different from what Bryan suggested (and you endorsed) before, as in that case there was a single 'reset' flag IFF_DRV_RUNNING protected by the 'core' lock, then a nested round on all tx and rx locks to make sure that all customers have seen it. In both cases the tx and rx paths only need the per-queue lock. As i see it, having a per-queue reset flag removes the need for nesting core + queue locks, but since this is only in the control path perhaps it is not a big deal (and is better to have a single place to look at to tell whether or not we should bail out). cheers luigi ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org -- -+--- Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/. Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -+--- quiesce.diff Description: Binary data ___ 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: Linux epoll(7) patch
On 08/05/2013 08:39, Mateusz Guzik wrote: What happens to fd after the fork? Is it closed or simply remains non-functional? If the former, I suggest the patch is altered to leave fd with badfdops in place so that epoll users get less surprised. I will try to alter it this way. However, there is no easy way of testing such case, apart from compiling specially crafted linux program. Also forking after poll is a marginal case. Doubt it ever matters in practice. I found two more problems with the patch: epoll_wait treats timeout as if it was in microseconds, when it is in milliseconds. Also epoll_wait doesn't check for the special case of timeout=-1. I corrected both issues. Will do additional testing, and will submit PR with an updated patch when done. Yuri ___ 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: [net] protecting interfaces from races between control and data ?
On Mon, Aug 5, 2013 at 8:19 PM, Adrian Chadd adr...@freebsd.org wrote: No, brian said two things: * the flag, protected by the core lock * per-queue flags i see no mentions on per-queue flags on his email. This is the relevant part What I've done in my drivers is: * Lock the core mutex * Clear IFF_DRV_RUNNING * Lock/unlock each queue's lock The various Rx/Tx queue functions check for IFF_DRV_RUNNING after (re)acquiring their queue lock. See at vtnet_stop_rendezvous() at [1] for an example. [1] http://svnweb.freebsd.org/base/user/bryanv/vtnetmq/sys/dev/virtio/network/if_vtnet.c?revision=252451view=markup - -adrian -- -+--- Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/. Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -+--- ___ 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: [net] protecting interfaces from races between control and data ?
On 05.08.2013 16:59, Bryan Venteicher wrote: - Original Message - i am slightly unclear of what mechanisms we use to prevent races between interface being reconfigured (up/down/multicast setting, etc, all causing reinitialization of the rx and tx rings) and i) packets from the host stack being sent out; ii) interrupts from the network card being processed. I think in the old times IFF_DRV_RUNNING was used for this purpose, but now it is not enough. Acquiring the core lock in the NIC does not seem enough, either, because newer drivers, especially multiqueue ones, have per-queue rx and tx locks. What I've done in my drivers is: * Lock the core mutex * Clear IFF_DRV_RUNNING * Lock/unlock each queue's lock The various Rx/Tx queue functions check for IFF_DRV_RUNNING after (re)acquiring their queue lock. See at vtnet_stop_rendezvous() at [1] for an example. Does anyone know if there is a generic mechanism, or each driver reimplements its own way ? We desperately need a saner ifnet/driver interface. I think andre@ had some previous work in this area (and additional plans as well?). Yes. I have received a grant from the FF to look at this in depth, evaluate different approaches and to propose an implementation for the whole stack. -- Andre IMO, there's a lot to like on what DragonflyBSD has done in this area. [1] - http://svnweb.freebsd.org/base/user/bryanv/vtnetmq/sys/dev/virtio/network/if_vtnet.c?revision=252451view=markup thanks luigi ___ 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 ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ 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: [CFT] VMware vmxnet3 ethernet driver
On Sun, Aug 04, 2013 at 07:12:17PM -0500, Bryan Venteicher wrote: Hi, I've ported the OpenBSD vmxnet3 ethernet driver to FreeBSD. I did a lot of cleanup, bug fixes, new features, etc (+2000 new lines) along the way so there is not much of a resemblance left. The driver is in good enough shape I'd like additional testers. A patch against -CURRENT is at [1]. Alternatively, the driver and a Makefile is at [2]; this should compile at least as far back as 9.1. I can look at 8-STABLE if there is interest. Obviously, besides reports of 'it works', I'm interested performance vs the emulated e1000, and (for those using it) the VMware tools vmxnet3 driver. Hopefully it is no worse :) I have ~100 FreeBSD 8/9 VMs in my vSphere 5.1 environment, all using the VMware tools package from VMware. Everything has been running great for years. (we skipped vSphere 5.0). Why should I use this vmxnet driver instead of the VMware tools driver or the emulated e1000? -- Joel ___ 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: [net] protecting interfaces from races between control and data ?
On Mon, Aug 5, 2013 at 8:46 PM, Jack Vogel jfvo...@gmail.com wrote: What do you think about this change? looks good to me. but there is no need to rush, especially it will be nice if all interested parties agree on an approach and possibly even naming. I do not have any specific test case but the problem came up when an interface is in netmap mode and dispatches to the in-kernel VALE switch, and userland tries to move the interface back to regular mode. cheers luigi ___ 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
HEADS UP: s/time_second/time_uptime/ in sys/netinet6
Hi,
I just wanted to let you know that data structures in sys/netinet6
now uses time_uptime instead of time_second. This should not be
user-visible, but if you notice there is something wrong with IPv6
after r253970, please let me know. Please do not forget to update
rtsold(8), rtadvd(8), and ndp(8) together when you compile a new
kernel.
-- Hiroki
---BeginMessage---
Author: hrs
Date: Mon Aug 5 20:13:02 2013
New Revision: 253970
URL: http://svnweb.freebsd.org/changeset/base/253970
Log:
- Use time_uptime instead of time_second in data structures for
PF_INET6 in kernel. This fixes various malfunction when the wall time
clock is changed. Bump __FreeBSD_version to 141.
- Use clock_gettime(CLOCK_MONOTONIC_FAST) in userland utilities.
MFC after:1 month
Modified:
head/sys/netinet6/icmp6.c
head/sys/netinet6/in6.c
head/sys/netinet6/in6.h
head/sys/netinet6/ip6_forward.c
head/sys/netinet6/ip6_id.c
head/sys/netinet6/ip6_mroute.c
head/sys/netinet6/nd6.c
head/sys/netinet6/nd6_rtr.c
head/sys/sys/param.h
head/usr.sbin/ndp/ndp.c
head/usr.sbin/rtadvctl/rtadvctl.c
head/usr.sbin/rtadvd/config.c
head/usr.sbin/rtadvd/rrenum.c
head/usr.sbin/rtadvd/rtadvd.c
head/usr.sbin/rtadvd/rtadvd.h
head/usr.sbin/rtadvd/timer.c
head/usr.sbin/rtadvd/timer.h
head/usr.sbin/rtadvd/timer_subr.c
head/usr.sbin/rtadvd/timer_subr.h
head/usr.sbin/rtsold/dump.c
head/usr.sbin/rtsold/rtsol.c
head/usr.sbin/rtsold/rtsold.c
head/usr.sbin/rtsold/rtsold.h
Modified: head/sys/netinet6/icmp6.c
==
--- head/sys/netinet6/icmp6.c Mon Aug 5 19:42:03 2013(r253969)
+++ head/sys/netinet6/icmp6.c Mon Aug 5 20:13:02 2013(r253970)
@@ -1931,8 +1931,8 @@ ni6_store_addrs(struct icmp6_nodeinfo *n
ltime = ND6_INFINITE_LIFETIME;
else {
if (ifa6-ia6_lifetime.ia6t_expire
- time_second)
- ltime =
htonl(ifa6-ia6_lifetime.ia6t_expire - time_second);
+ time_uptime)
+ ltime =
htonl(ifa6-ia6_lifetime.ia6t_expire - time_uptime);
else
ltime = 0;
}
Modified: head/sys/netinet6/in6.c
==
--- head/sys/netinet6/in6.c Mon Aug 5 19:42:03 2013(r253969)
+++ head/sys/netinet6/in6.c Mon Aug 5 20:13:02 2013(r253970)
@@ -523,12 +523,12 @@ in6_control(struct socket *so, u_long cm
/* sanity for overflow - beware unsigned */
lt = ifr-ifr_ifru.ifru_lifetime;
if (lt-ia6t_vltime != ND6_INFINITE_LIFETIME
- lt-ia6t_vltime + time_second time_second) {
+ lt-ia6t_vltime + time_uptime time_uptime) {
error = EINVAL;
goto out;
}
if (lt-ia6t_pltime != ND6_INFINITE_LIFETIME
- lt-ia6t_pltime + time_second time_second) {
+ lt-ia6t_pltime + time_uptime time_uptime) {
error = EINVAL;
goto out;
}
@@ -632,12 +632,12 @@ in6_control(struct socket *so, u_long cm
/* for sanity */
if (ia-ia6_lifetime.ia6t_vltime != ND6_INFINITE_LIFETIME) {
ia-ia6_lifetime.ia6t_expire =
- time_second + ia-ia6_lifetime.ia6t_vltime;
+ time_uptime + ia-ia6_lifetime.ia6t_vltime;
} else
ia-ia6_lifetime.ia6t_expire = 0;
if (ia-ia6_lifetime.ia6t_pltime != ND6_INFINITE_LIFETIME) {
ia-ia6_lifetime.ia6t_preferred =
- time_second + ia-ia6_lifetime.ia6t_pltime;
+ time_uptime + ia-ia6_lifetime.ia6t_pltime;
} else
ia-ia6_lifetime.ia6t_preferred = 0;
break;
@@ -1140,7 +1140,7 @@ in6_update_ifa(struct ifnet *ifp, struct
ia-ia_ifa.ifa_addr = (struct sockaddr *)ia-ia_addr;
ia-ia_addr.sin6_family = AF_INET6;
ia-ia_addr.sin6_len = sizeof(ia-ia_addr);
- ia-ia6_createtime = time_second;
+ ia-ia6_createtime = time_uptime;
if ((ifp-if_flags (IFF_POINTOPOINT | IFF_LOOPBACK)) != 0) {
/*
* XXX: some functions expect that ifa_dstaddr is not
@@ -1167,7 +1167,7 @@ in6_update_ifa(struct ifnet *ifp, struct
}
/* update timestamp */
- ia-ia6_updatetime = time_second;
+ ia-ia6_updatetime = time_uptime;
/* set prefix mask */
Re: [net] protecting interfaces from races between control and data ?
- Original Message - On Mon, Aug 5, 2013 at 8:19 PM, Adrian Chadd adr...@freebsd.org wrote: No, brian said two things: * the flag, protected by the core lock * per-queue flags i see no mentions on per-queue flags on his email. This is the relevant part Right, I just use the IFF_DRV_RUNNING flag. I think Adrian meant 'per-queue locks' here? What I've done in my drivers is: * Lock the core mutex * Clear IFF_DRV_RUNNING * Lock/unlock each queue's lock The various Rx/Tx queue functions check for IFF_DRV_RUNNING after (re)acquiring their queue lock. See at vtnet_stop_rendezvous() at [1] for an example. [1] http://svnweb.freebsd.org/base/user/bryanv/vtnetmq/sys/dev/virtio/network/if_vtnet.c?revision=252451view=markup - -adrian -- -+--- Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/. Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -+--- ___ 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: [net] protecting interfaces from races between control and data ?
On 05.08.2013 19:36, Luigi Rizzo wrote: On Mon, Aug 5, 2013 at 7:17 PM, Adrian Chadd adr...@freebsd.org wrote: I'm travelling back to San Jose today; poke me tomorrow and I'll brain dump what I did in ath(4) and the lessons learnt. The TL;DR version - you don't want to grab an extra lock in the read/write paths as that slows things down. Reuse the same per-queue TX/RX lock and have: * a reset flag that is set when something is resetting; that says to the queue don't bother processing anything, just dive out; * 'i am doing Tx / Rx' flags per queue that is set at the start of TX/RX servicing and finishes at the end; that way the reset code knows if there's something pending; * have the reset path grab each lock, set the 'reset' flag on each, then walk each queue again and make sure they're all marked as 'not doing TX/RX'. At that point the reset can occur, then the flag cna be cleared, then TX/RX can resume. [picking a post at random to reply in this thread] so this is slightly different from what Bryan suggested (and you endorsed) before, as in that case there was a single 'reset' flag IFF_DRV_RUNNING protected by the 'core' lock, then a nested round on all tx and rx locks to make sure that all customers have seen it. In both cases the tx and rx paths only need the per-queue lock. As i see it, having a per-queue reset flag removes the need for nesting core + queue locks, but since this is only in the control path perhaps it is not a big deal (and is better to have a single place to look at to tell whether or not we should bail out). Ideally we don't want to have any locks in the RX and TX path at all. For the TX path this is not easy to achieve but for RX it isn't difficult at all provided the correct model is used. My upcoming stack/driver proposal is along these lines: RX with MSI-X: Every queue has its own separate RX interrupt vector which is serviced by a single dedicated ithread (or taskqueue) which does while(1) for work on the RX ring only going to sleep when it reaches the end of work on the ring. It is then woken up by an interrupt to resume work. To prevent a live-lock on the CPU it would periodically yield to allow other kernel and user-space threads to run in between. Each queue's ithread (taskqueue) can be pinned to a particular core or float with a certain stickiness. To reconfigure the card (when the RX ring is affected) the ithread (taskqueue) is terminated and after the changes restarted again. This is done by the control path and allows us to run RX completely lock free because there is only ever one ithread accessing the RX queue doing away with the need for further locking synchronization. RX with MSI or legacy interrupts: Here multi-queue is impeded because of some synchronization issues. Depending on the hardware synchronization model the ithreads again do while(1) but have to be made runnable by the interrupt handler when new work has been indicated. TX in general: This is a bit more tricky as we have the hard requirement of packet ordering for individual sessions (tcp and others). That means we must use the same queue for all packets of the same session. This makes running TX non-locked a bit tricky because when we pin a TX queue to a core we must switch to that core first before adding anything to the queue. If the packet was generated on that core there is no overhead, OTOH if not there is the scheduler over- head and some cache losses. Ensuring that a the entire TX path, possibly including user-space (write et al) happens on the same core is difficult and may have its own inefficiencies. The number of TX queue vs. number of cores is another point of contention. To make the 1:1 scheme work well, one must have as many queues as cores. A more scalable and generic approach doesn't bind TX queues to any particular core and is covers each by its own lock to protect the TX ring enqueue. To prevent false lock cache line sharing each TX structure should be on its own cache line. As each session has an affinity hash they become distributed across the TX queues significantly reducing contention. The TX complete handling freeing the mbuf(s) is done the same way as for the RX ring with a dedicated ithread (taskqueue) for each. Also bpf should hook in here (the packet has been sent) instead of at the TX enqueue time. The whole concept of IFF_DRV_RUNNING will go away along with the IFQ macros. Each driver then provides a direct TX function pointer which is put into a decoupled ifnet TX field for use by the stack. Under normal operation all interface TX goes directly into TX DMA ring. The particular multi-queue and locking model is decided by the driver. The kernel provides a couple of common optimized abstractions for use by all drivers that want/need it to avoid code and functionality duplication. When things like ALTQ are activated on an interface the ifnet TX function pointer is replaced with the appropriate intermediate function pointer which
Re: [net] protecting interfaces from races between control and data ?
On Mon, Aug 05, 2013 at 11:04:44PM +0200, Andre Oppermann wrote: On 05.08.2013 19:36, Luigi Rizzo wrote: ... [picking a post at random to reply in this thread] tell whether or not we should bail out). Ideally we don't want to have any locks in the RX and TX path at all. Ok i have read your proposal below but there are a few things I do not completely understand, below -- essentially I do not understand whether the removal of IFF_DRV_RUNNING (or equivalent) forces you to replace the ifp-new_tx_function() with something else when you want to do an ifconfig down Specifically, here are my doubts: - Considering that the rxq lock is rarely contended (only when the control path is active, which in your approach below requires killing and restarting the ithread), and is acquired/released only once per interrupt/batch, i am under the impression that the per-queue RX lock is not a performance problem and makes it easier to reason on the code (and does not require different approach for MSI-x and other cases). - in the tx datapath, do you want to acquire the txq lock before or after calling ifp-new_tx_function() ? (btw how it compares to ifp-if_start or ifp-if_transmit ?) If you do it within the tx handler then you lose the ability of replacing the handler when you do a reconfiguration, because grabbing the tx lock in the control path does not tell you whether anyone is in the handler. If you do it outside, then the driver should also expose the locks, or some locking function. Overall, it seems to me that keeping the IFF_DRV_RUNNING flag is a lot more practical, not to mention fewer modifications to the code. [description of Andre's proposal below, for reference] cheers luigi Every queue has its own separate RX interrupt vector which is serviced by a single dedicated ithread (or taskqueue) which does while(1) for work on the RX ring only going to sleep when it reaches the end of work on the ring. It is then woken up by an interrupt to resume work. To prevent a live-lock on the CPU it would periodically yield to allow other kernel and user-space threads to run in between. Each queue's ithread (taskqueue) can be pinned to a particular core or float with a certain stickiness. To reconfigure the card (when the RX ring is affected) the ithread (taskqueue) is terminated and after the changes restarted again. This is done by the control path and allows us to run RX completely lock free because there is only ever one ithread accessing the RX queue doing away with the need for further locking synchronization. ok I admit i did not think of killing and restarting the ithread, but i wonder how RX with MSI or legacy interrupts: Here multi-queue is impeded because of some synchronization issues. Depending on the hardware synchronization model the ithreads again do while(1) but have to be made runnable by the interrupt handler when new work has been indicated. TX in general: This is a bit more tricky as we have the hard requirement of packet ordering for individual sessions (tcp and others). That means we must use the same queue for all packets of the same session. This makes running TX non-locked a bit tricky because when we pin a TX queue to a core we must switch to that core first before adding anything to the queue. If the packet was generated on that core there is no overhead, OTOH if not there is the scheduler over- head and some cache losses. Ensuring that a the entire TX path, possibly including user-space (write et al) happens on the same core is difficult and may have its own inefficiencies. The number of TX queue vs. number of cores is another point of contention. To make the 1:1 scheme work well, one must have as many queues as cores. A more scalable and generic approach doesn't bind TX queues to any particular core and is covers each by its own lock to protect the TX ring enqueue. To prevent false lock cache line sharing each TX structure should be on its own cache line. As each session has an affinity hash they become distributed across the TX queues significantly reducing contention. The TX complete handling freeing the mbuf(s) is done the same way as for the RX ring with a dedicated ithread (taskqueue) for each. Also bpf should hook in here (the packet has been sent) instead of at the TX enqueue time. The whole concept of IFF_DRV_RUNNING will go away along with the IFQ macros. Each driver then provides a direct TX function pointer which is put into a decoupled ifnet TX field for use by the stack. Under normal operation all interface TX goes directly into TX DMA ring. The particular multi-queue and locking model is decided by the driver. The kernel provides a couple of common optimized abstractions for use by all drivers that want/need it to avoid code and functionality duplication. When things like ALTQ are activated on an interface the ifnet TX function pointer is replaced
Re: [CFT] VMware vmxnet3 ethernet driver
- Original Message - I have ~100 FreeBSD 8/9 VMs in my vSphere 5.1 environment, all using the VMware tools package from VMware. Everything has been running great for years. (we skipped vSphere 5.0). Why should I use this vmxnet driver instead of the VMware tools driver or the emulated e1000? They are out of tree and subject to rotting. I had to use the patches at [1] to even get them to compile on 9.1 and -current. I don't think VMware puts much engineering resources behind it; there was a compiler warning of a silly bug like: if (foo) ; do_something(); vmxnet3 has modern features LRO, IPv6 checksum offloading, etc that the emulated e1000 lacks. In my test setup, e1000 tops out at 30MB/sec but vmxnet3 goes to 50MB/sec. I'd like to hear other's experiences. [1] - http://ogris.de/vmware/ -- Joel ___ 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
LOR on head ...
Not sure if this is a known issue since I don't usually use UFS. Yesterday I put current on an acer laptop with an i3 processor/4GB RAM with UFS file system on a OCZ vertex 2 SSD and trim enabled via tunefs. Below is the dmesg along with the LOR message at the bottom. I can provide more information if it is helpful. Copyright (c) 1992-2013 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 10.0-CURRENT #0: Sun Aug 4 16:54:51 UTC 2013 r...@beam.macktronics.com:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Core(TM) i3-2370M CPU @ 2.40GHz (2394.61-MHz K8-class CPU) Origin = GenuineIntel Id = 0x206a7 Family = 0x6 Model = 0x2a Stepping = 7 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x1dbae3bfSSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,XSAVE,OSXSAVE,AVX AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 3785801728 (3610 MB) Event timer LAPIC quality 600 ACPI APIC Table: ACRSYS ACRPRDCT FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: ACRSYS ACRPRDCT on motherboard acpi0: Power Button (fixed) cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 950 Event timer HPET frequency 14318180 Hz quality 550 Event timer HPET1 frequency 14318180 Hz quality 440 Event timer HPET2 frequency 14318180 Hz quality 440 Event timer HPET3 frequency 14318180 Hz quality 440 Event timer HPET4 frequency 14318180 Hz quality 440 atrtc0: AT realtime clock port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer RTC frequency 32768 Hz quality 0 attimer0: AT timer port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 acpi_ec0: Embedded Controller: GPE 0x17 port 0x62,0x66 on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 vgapci0: VGA-compatible display port 0x2000-0x203f mem 0xc000-0xc03f,0xb000-0xbfff irq 16 at device 2.0 on pci0 agp0: SandyBridge mobile GT2 IG on vgapci0 agp0: aperture size is 256M, detected 131068k stolen memory pci0: simple comms at device 22.0 (no driver attached) ehci0: Intel Panther Point USB 2.0 controller mem 0xc0609000-0xc06093ff irq 16 at device 26.0 on pci0 usbus0: EHCI version 1.0 usbus0 on ehci0 hdac0: Intel Panther Point HDA Controller mem 0xc060-0xc0603fff irq 22 at device 27.0 on pci0 pcib1: ACPI PCI-PCI bridge irq 17 at device 28.0 on pci0 pci2: ACPI PCI bus on pcib1 bge0: Broadcom BCM57765 B0, ASIC rev. 0x57785100 mem 0xc043-0xc043,0xc044-0xc044 irq 16 at device 0.0 on pci2 bge0: CHIP ID 0x57785100; ASIC REV 0x57785; CHIP REV 0x577851; PCI-E miibus0: MII bus on bge0 brgphy0: BCM57765 1000BASE-T media interface PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: dc:0e:a1:b1:e8:d4 sdhci_pci0: Generic SD HCI mem 0xc040-0xc040 irq 17 at device 0.1 on pci2 sdhci_pci0: 1 slot(s) allocated pci2: base peripheral at device 0.2 (no driver attached) pci2: base peripheral at device 0.3 (no driver attached) pcib2: ACPI PCI-PCI bridge irq 16 at device 28.1 on pci0 pci3: ACPI PCI bus on pcib2 ath0: Atheros AR9485 mem 0xc050-0xc057 irq 17 at device 0.0 on pci3 ar9300_set_stub_functions: setting stub functions ar9300_set_stub_functions: setting stub functions ar9300_attach: calling ar9300_hw_attach ar9300_hw_attach: calling ar9300_eeprom_attach ar9300_flash_map: unimplemented for now Restoring Cal data from DRAM Restoring Cal data from EEPROM Restoring Cal data from Flash Restoring Cal data from Flash Restoring Cal data from OTP ar9300_hw_attach: ar9300_eeprom_attach returned 0 ath0: RX status length: 48 ath0: RX buffer size: 4096 ath0: TX descriptor length: 128 ath0: TX status length: 36 ath0: TX buffers per descriptor: 4 ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0
Re: LOR on head ...
I am going to respond to this before I forget I had the SAME exact LOR's with ath 9300 and I reported them, however I have since switched out motherboards and the LOR's have strangely diapered here is a full dmesg for a perfectly working system FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 CPU: AMD FX(tm)-4100 Quad-Core Processor (3600.30-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x600f12 Family = 0x15 Model = 0x1 Stepping = 2 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x1e98220bSSE3,PCLMULQDQ,MON,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AESNI,XSAVE,OSXSAVE,AVX AMD Features=0x2e500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM AMD Features2=0x1c9bfffLAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,XOP,SKINIT,WDT,LWP,FMA4,NodeId,Topology,b23,b24 TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 7868518400 (7504 MB) Event timer LAPIC quality 400 ACPI APIC Table: ALASKA A M I FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 17 cpu2 (AP): APIC ID: 18 cpu3 (AP): APIC ID: 19 ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has zero address or length: 0x/0x1 (20130725/tbfadt-630) ioapic0 Version 2.1 irqs 0-23 on motherboard ioapic1 Version 2.1 irqs 24-55 on motherboard kbd1 at kbdmux0 acpi0: ALASKA A M I on motherboard acpi0: Power Button (fixed) cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 attimer0: AT timer port 0x40-0x43 irq 0 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 atrtc0: AT realtime clock port 0x70-0x71 irq 8 on acpi0 Event timer RTC frequency 32768 Hz quality 0 hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 950 Event timer HPET frequency 14318180 Hz quality 450 Event timer HPET1 frequency 14318180 Hz quality 450 Event timer HPET2 frequency 14318180 Hz quality 450 Timecounter ACPI-safe frequency 3579545 Hz quality 850 acpi_timer0: 32-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_ec0: Embedded Controller: GPE 0xa port 0x62,0x66 on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: base peripheral at device 0.2 (no driver attached) pcib1: ACPI PCI-PCI bridge irq 52 at device 2.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display mem 0xfd00-0xfdff,0xc000-0xcfff,0xfc00-0xfcff irq 24 at device 0.0 on pci1 pcib2: ACPI PCI-PCI bridge irq 52 at device 4.0 on pci0 pci2: ACPI PCI bus on pcib2 re0: RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet port 0xe000-0xe0ff mem 0xd0004000-0xd0004fff,0xd000-0xd0003fff irq 44 at device 0.0 on pci2 re0: Using 1 MSI-X message re0: Chip rev. 0x4800 re0: MAC rev. 0x miibus0: MII bus on re0 rgephy0: RTL8169S/8110S/8211 1000BASE-T media interface PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 60:a4:4c:57:02:c4 pcib3: ACPI PCI-PCI bridge irq 52 at device 5.0 on pci0 pci3: ACPI PCI bus on pcib3 xhci0: ASMedia ASM1042 USB 3.0 controller mem 0xfe40-0xfe407fff irq 46 at device 0.0 on pci3 xhci0: 32 byte context size. usbus0 on xhci0 pcib4: ACPI PCI-PCI bridge irq 53 at device 7.0 on pci0 pci4: ACPI PCI bus on pcib4 xhci1: ASMedia ASM1042 USB 3.0 controller mem 0xfe30-0xfe307fff irq 50 at device 0.0 on pci4 xhci1: 32 byte context size. usbus1 on xhci1 pcib5: ACPI PCI-PCI bridge irq 53 at device 9.0 on pci0 pci5: ACPI PCI bus on pcib5 ath0: Atheros AR938x mem 0xfe20-0xfe21 irq 48 at device 0.0 on pci5 ar9300_set_stub_functions: setting stub functions ar9300_set_stub_functions: setting stub functions ar9300_attach: calling ar9300_hw_attach ar9300_hw_attach: calling ar9300_eeprom_attach ar9300_flash_map: unimplemented for now Restoring Cal data from DRAM Restoring Cal data from EEPROM ar9300_hw_attach: ar9300_eeprom_attach returned 0 ath0: RX status length: 48 ath0: RX buffer size: 4096 ath0: TX descriptor length: 128 ath0: TX status length: 36 ath0: TX buffers per descriptor: 4 ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0 ath0: ath_edma_setup_rxfifo: type=0, FIFO depth = 16 entries ath0: ath_edma_setup_rxfifo: type=1, FIFO depth = 128 entries ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 stream STBC transmit enabled ath0: [HT] 3 RX streams; 3 TX streams ath0: AR9380 mac 448.3 RF5110 phy 0.0 ath0: 2GHz radio: 0x; 5GHz radio: 0x ahci0: ATI IXP700 AHCI SATA controller port
Re: LOR on head ...
On Mon, Aug 5, 2013 at 4:24 PM, Sam Fourman Jr. sfour...@gmail.com wrote: I am going to respond to this before I forget I had the SAME exact LOR's with ath 9300 and I reported them, however I have since switched out motherboards and the LOR's have strangely diapered here is a full dmesg for a perfectly working system FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 CPU: AMD FX(tm)-4100 Quad-Core Processor (3600.30-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x600f12 Family = 0x15 Model = 0x1 Stepping = 2 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x1e98220bSSE3,PCLMULQDQ,MON,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AESNI,XSAVE,OSXSAVE,AVX AMD Features=0x2e500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM AMD Features2=0x1c9bfffLAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,XOP,SKINIT,WDT,LWP,FMA4,NodeId,Topology,b23,b24 TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 7868518400 (7504 MB) Event timer LAPIC quality 400 ACPI APIC Table: ALASKA A M I FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 17 cpu2 (AP): APIC ID: 18 cpu3 (AP): APIC ID: 19 ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has zero address or length: 0x/0x1 (20130725/tbfadt-630) ioapic0 Version 2.1 irqs 0-23 on motherboard ioapic1 Version 2.1 irqs 24-55 on motherboard kbd1 at kbdmux0 acpi0: ALASKA A M I on motherboard acpi0: Power Button (fixed) cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 attimer0: AT timer port 0x40-0x43 irq 0 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 atrtc0: AT realtime clock port 0x70-0x71 irq 8 on acpi0 Event timer RTC frequency 32768 Hz quality 0 hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 950 Event timer HPET frequency 14318180 Hz quality 450 Event timer HPET1 frequency 14318180 Hz quality 450 Event timer HPET2 frequency 14318180 Hz quality 450 Timecounter ACPI-safe frequency 3579545 Hz quality 850 acpi_timer0: 32-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_ec0: Embedded Controller: GPE 0xa port 0x62,0x66 on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: base peripheral at device 0.2 (no driver attached) pcib1: ACPI PCI-PCI bridge irq 52 at device 2.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display mem 0xfd00-0xfdff,0xc000-0xcfff,0xfc00-0xfcff irq 24 at device 0.0 on pci1 pcib2: ACPI PCI-PCI bridge irq 52 at device 4.0 on pci0 pci2: ACPI PCI bus on pcib2 re0: RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet port 0xe000-0xe0ff mem 0xd0004000-0xd0004fff,0xd000-0xd0003fff irq 44 at device 0.0 on pci2 re0: Using 1 MSI-X message re0: Chip rev. 0x4800 re0: MAC rev. 0x miibus0: MII bus on re0 rgephy0: RTL8169S/8110S/8211 1000BASE-T media interface PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 60:a4:4c:57:02:c4 pcib3: ACPI PCI-PCI bridge irq 52 at device 5.0 on pci0 pci3: ACPI PCI bus on pcib3 xhci0: ASMedia ASM1042 USB 3.0 controller mem 0xfe40-0xfe407fff irq 46 at device 0.0 on pci3 xhci0: 32 byte context size. usbus0 on xhci0 pcib4: ACPI PCI-PCI bridge irq 53 at device 7.0 on pci0 pci4: ACPI PCI bus on pcib4 xhci1: ASMedia ASM1042 USB 3.0 controller mem 0xfe30-0xfe307fff irq 50 at device 0.0 on pci4 xhci1: 32 byte context size. usbus1 on xhci1 pcib5: ACPI PCI-PCI bridge irq 53 at device 9.0 on pci0 pci5: ACPI PCI bus on pcib5 ath0: Atheros AR938x mem 0xfe20-0xfe21 irq 48 at device 0.0 on pci5 ar9300_set_stub_functions: setting stub functions ar9300_set_stub_functions: setting stub functions ar9300_attach: calling ar9300_hw_attach ar9300_hw_attach: calling ar9300_eeprom_attach ar9300_flash_map: unimplemented for now Restoring Cal data from DRAM Restoring Cal data from EEPROM ar9300_hw_attach: ar9300_eeprom_attach returned 0 ath0: RX status length: 48 ath0: RX buffer size: 4096 ath0: TX descriptor length: 128 ath0: TX status length: 36 ath0: TX buffers per descriptor: 4 ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0 ath0: ath_edma_setup_rxfifo: type=0, FIFO depth = 16 entries ath0: ath_edma_setup_rxfifo: type=1, FIFO depth = 128 entries ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 stream STBC transmit
Re: make buildworld fails
Boris Samorodov writes:
This note from /usr/src/UPDATING may be relevant:
-
20130613:
Some people report the following error after the switch to bmake:
make: illegal option -- J
usage: make [-BPSXeiknpqrstv] [-C directory] [-D variable]
...
*** [buildworld] Error code 2
this likely due to an old instance of make in
${MAKEPATH} (${MAKEOBJDIRPREFIX}${.CURDIR}/make.${MACHINE})
which src/Makefile will use that blindly, if it exists, so if
you see the above error:
rm -rf `make -V MAKEPATH`
should resolve it.
Would that it were so. :-(
1)
huff@ make -V MAKEPATH
huff@
2) After running the above, buildworld stops at the same place:
(cd /usr/src make bmake)
echo
echo --
--
echo Building an up-to-date make(1)
Building an up-to-date make(1)
echo --
--
cd /usr/src/usr.bin/bmake; MAKEOBJDIRPREFIX=/usr/obj/usr/src/make.amd64
DESTDIR= INSTALL=sh /usr/src/tools/install.sh make -D_UPGRADING -DNOMAN
-DNO_MAN -DNOSHARED -DNO_SHARED -DNO_CPU_CFLAGS -DNO_WERROR obj
MAKEOBJDIRPREFIX=/usr/obj/usr/src/make.amd64 DESTDIR= INSTALL=sh
/usr/src/tools/install.sh make -D_UPGRADING -DNOMAN -DNO_MAN -DNOSHARED
-DNO_SHARED -DNO_CPU_CFLAGS -DNO_WERROR depend
MAKEOBJDIRPREFIX=/usr/obj/usr/src/make.amd64 DESTDIR= INSTALL=sh
/usr/src/tools/install.sh make -D_UPGRADING -DNOMAN -DNO_MAN -DNOSHARED
-DNO_SHARED -DNO_CPU_CFLAGS -DNO_WERROR all
MAKEOBJDIRPREFIX=/usr/obj/usr/src/make.amd64 DESTDIR= INSTALL=sh
/usr/src/tools/install.sh make -D_UPGRADING -DNOMAN -DNO_MAN -DNOSHARED
-DNO_SHARED -DNO_CPU_CFLAGS -DNO_WERROR install
DESTDIR=/usr/obj/usr/src/make.amd64 BINDIR= PROGNAME=bmake
if ! test -d /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/; then mkdir -p
/usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake; if ! test -d
/usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/; then echo Unable to
create /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake.; exit 1; fi; echo
/usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake created for
/usr/src/usr.bin/bmake; fi
/usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake created for
/usr/src/usr.bin/bmake
set -e; for entry in unit-tests; do if test -d
/usr/src/usr.bin/bmake/${entry}.amd64; then echo === ${entry}.amd64 (obj);
edir=${entry}.amd64; cd /usr/src/usr.bin/bmake/${edir}; else echo ===
$entry (obj); edir=${entry}; cd /usr/src/usr.bin/bmake/${edir}; fi; make
obj DIRPRFX=$edir/; done
=== unit-tests (obj)
if ! test -d /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/unit-tests/;
then mkdir -p /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/unit-tests;
if ! test -d /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/unit-tests/;
then echo Unable to create
/usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/unit-tests.; exit 1; fi;
echo /usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/unit-tests created for
/usr/src/usr.bin/bmake/unit-tests; fi
/usr/obj/usr/src/make.amd64/usr/src/usr.bin/bmake/unit-tests created for
/usr/src/usr.bin/bmake/unit-tests
rm -f .depend
mkdep -f .depend -a-DNO_PWD_OVERRIDE -I/usr/src/usr.bin/bmake -DUSE_META
-DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DUSE_META -DMAKE_NATIVE
-DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\.../share/mk:/usr/share/mk\ -I.
-I/usr/src/contrib/bmake -DMAKE_NATIVE -std=gnu99
/usr/src/contrib/bmake/arch.c /usr/src/contrib/bmake/buf.c
/usr/src/contrib/bmake/compat.c /usr/src/contrib/bmake/cond.c
/usr/src/contrib/bmake/dir.c /usr/src/contrib/bmake/for.c
/usr/src/contrib/bmake/hash.c /usr/src/contrib/bmake/job.c
/usr/src/contrib/bmake/main.c /usr/src/contrib/bmake/make.c
/usr/src/contrib/bmake/make_malloc.c /usr/src/contrib/bmake/meta.c
/usr/src/contrib/bmake/parse.c /usr/src/contrib/bmake/str.c
/usr/src/contrib/bmake/strlist.c /usr/src/contrib/bmake/suff.c
/usr/src/contrib/bmake/targ.c /usr/src/contrib/bmake/trace.c
/usr/src/contrib/bmake/util.c /usr/src/contrib/bmake/var.c
/usr/src/contrib/bmake/lst.lib/lstAppend.c
/usr/src/contrib/bmake/lst.lib/lstAtEnd.c /usr/src/contrib/bmake/lst.
lib/lstAtFront.c /usr/src/contrib/bmake/lst.lib/lstClose.c
/usr/src/contrib/bmake/lst.lib/lstConcat.c
/usr/src/contrib/bmake/lst.lib/lstDatum.c
/usr/src/contrib/bmake/lst.lib/lstDeQueue.c
/usr/src/contrib/bmake/lst.lib/lstDestroy.c
/usr/src/contrib/bmake/lst.lib/lstDupl.c
/usr/src/contrib/bmake/lst.lib/lstEnQueue.c
/usr/src/contrib/bmake/lst.lib/lstFind.c
/usr/src/contrib/bmake/lst.lib/lstFindFrom.c
/usr/src/contrib/bmake/lst.lib/lstFirst.c
/usr/src/contrib/bmake/lst.lib/lstForEach.c
Re: LOR on head ...
On Mon, 5 Aug 2013, Davide Italiano wrote: The LOR is a false positive. See the comment in sys/ufs/ufs/ufs_dirhash.c Also, switching motherboards is not related to this in any way. You'll eventually hit that LOR report, unless you disabled WITNESS. Ah, thank you Davide; sorry for the noise ... I've been using only ZFS for so long that I haven't run across this yet. I'm also getting these too which appear to be the same sort of thing, no? lock order reversal: 1st 0xfe010157d418 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2099 2nd 0xff80ec37fa78 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:262 3rd 0xfe010157b9a0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2099 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xff81166cecb0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xff81166ced60 witness_checkorder() at witness_checkorder+0xd4f/frame 0xff81166cedf0 __lockmgr_args() at __lockmgr_args+0x6f2/frame 0xff81166cef20 ffs_lock() at ffs_lock+0x84/frame 0xff81166cef70 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xff81166cefa0 _vn_lock() at _vn_lock+0xab/frame 0xff81166cf010 vget() at vget+0x70/frame 0xff81166cf060 vfs_hash_get() at vfs_hash_get+0xf5/frame 0xff81166cf0b0 ffs_vgetf() at ffs_vgetf+0x41/frame 0xff81166cf140 softdep_sync_buf() at softdep_sync_buf+0x8fa/frame 0xff81166cf1f0 ffs_syncvnode() at ffs_syncvnode+0x258/frame 0xff81166cf270 ffs_truncate() at ffs_truncate+0x5ca/frame 0xff81166cf450 ufs_direnter() at ufs_direnter+0x891/frame 0xff81166cf510 ufs_makeinode() at ufs_makeinode+0x573/frame 0xff81166cf6d0 VOP_CREATE_APV() at VOP_CREATE_APV+0xea/frame 0xff81166cf700 vn_open_cred() at vn_open_cred+0x300/frame 0xff81166cf850 kern_openat() at kern_openat+0x1f5/frame 0xff81166cf9a0 amd64_syscall() at amd64_syscall+0x265/frame 0xff81166cfab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xff81166cfab0 --- syscall (5, FreeBSD ELF64, sys_open), rip = 0x80093d3ea, rsp = 0x7fffd758, rbp = 0x7fffd7b0 --- dan -- Dan Mack ___ 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: [CFT] VMware vmxnet3 ethernet driver
On Mon, Aug 05, 2013 at 05:52:01PM -0500, Bryan Venteicher wrote: - Original Message - I have ~100 FreeBSD 8/9 VMs in my vSphere 5.1 environment, all using the VMware tools package from VMware. Everything has been running great for years. (we skipped vSphere 5.0). Why should I use this vmxnet driver instead of the VMware tools driver or the emulated e1000? They are out of tree and subject to rotting. I had to use the patches at [1] to even get them to compile on 9.1 and -current. I don't think VMware puts much engineering resources behind it; Perhaps not, but they do support FreeBSD. I've started several support cases with FreeBSD-specific problems and they've fixed all so far. Are you aiming at completely replacing VMware tools, or just the device drivers? -- Joel ___ 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: Kernel Panic on FreeBSD 10.0-CURRENT #1 r253918
On Mon, 5 Aug 2013 10:29:23 -0700 Craig Rodrigues rodr...@freebsd.org wrote: On Sun, Aug 4, 2013 at 3:59 PM, Sam Fourman Jr. sfour...@gmail.com wrote: Craig, Thank you for getting back to me, I will get to work on this right away and get you what you need. but are we CERTAIN this panic could be from VIMAGE? I totally thought I had a # infront of that line when I built this kernel... if you notice I did post the kernel config at the bottom of that email, and VIMAGE is NOT included... but maybe I did something wrong and somehow built VIMAGE in anyway.. is there some sort of command I can run to ask the system if it does indeed have VIMAGE? On the booted an running system, if you type: sysctl kern.conftxt that will display the actual kernel config options used to build the running kernel. Not necessarily sysctl kern.conftxt sysctl: unknown oid 'kern.conftxt': No such file or directory -- Gary Jennejohn ___ 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
