Re: Makefile Problem of FreeBSD-Current
On Sun, May 11, 2014 at 9:39 AM, Sean Bruno sbr...@ignoranthack.me wrote:
On Sun, 2014-05-11 at 20:49 +0800, bycn82 wrote:
As you can see below . it still did not find the src.opts.mk
root@FB10Head:/usr/src/sbin/ipfw # make
make: /usr/src/sbin/ipfw/Makefile line 3: Could not find src.opts.mk
make: /usr/src/sbin/ipfw/Makefile line 9: Malformed conditional
(${MK_PF} != no)
make: /usr/src/sbin/ipfw/../Makefile.inc line 4: Could not find
src.opts.mk
make: /usr/src/sbin/ipfw/../Makefile.inc line 9: Malformed conditional
(${MK_DYNAMICROOT} == no)
make: Fatal errors encountered -- cannot continue
make: stopped in /usr/src/sbin/ipfw
root@FB10Head:/usr/src/sbin/ipfw # uname -a
FreeBSD FB10Head 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r265868: Sun May
11 11:44:35 UTC 2014 root@FB10Head:/usr/obj/usr/src/sys/GENERIC
amd64
___
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
I suspect you are seeing the same issue as described in the thread
delete-old issue with src.opts.mk on -current.
I successfully built -CURRENT 265866 last night and did not run into this
problem. However, I ran -DNO_CLEAN and had no need to rebuild ipfw from my
previous build(s). If I now go into the /usr/src/sbin/ipfw directory and
simply do a 'make', I can duplicate this error.
The /usr/src/sbin/ipfw/Makefile includes an .include for src.opts.mk:
# $FreeBSD: head/sbin/ipfw/Makefile 265420 2014-05-06 04:22:01Z imp $
.include src.opts.mk
PROG= ipfw
SRCS= ipfw2.c dummynet.c ipv6.c main.c nat.c
WARNS?= 2
...
Maybe it should not?
-Tom
___
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: Makefile Problem of FreeBSD-Current
On Sun, May 11, 2014 at 11:14 AM, Warner Losh i...@bsdimp.com wrote: From UPDATING: 20140505: /etc/src.conf now affects only builds of the FreeBSD src tree. In the past, it affected all builds that used the bsd.*.mk files. The old behavior was a bug, but people may have relied upon it. To get this behavior back, you can .include /etc/src.conf from /etc/make.conf (which is still global and isn't changed). This also changes the behavior of incremental builds inside the tree of individual directories. Set MAKESYSPATH to .../share/mk to do that. Although this has survived make universe and some upgrade scenarios, other upgrade scenarios may have broken. At least one form of temporary breakage was fixed with MAKESYSPATH settings for buildworld as well... Since you are building inside the tree, did you set MAKESYSPATH as outlined in UPDATING? Thanks for this clarification. Setting MAKESYSPATH resolves the issue. I am indeed guilty of _not_ regularly checking /usr/src/UPDATING. My bad. -Tom ___ 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
delete-old issue with src.opts.mk
The other night I built a new -CURRENT at r265728. At delete-old it asked me if I wanted to remove /usr/share/mk/src.opts.mk? I said yes. Subsequently an upgrade attempt for virtualbox-ose-4.3.10_1 failed with a missing src.opts.mk http://src.opt.mk error. Last night I built a new -CURRENT at 265793. At delete-old it asked me if I wanted to remove /usr/share/mk/src.opts.mk?again. I said no. Subsequently an upgrade for virtualbox-ose-4.3.10_1 succeded. Three questions: 1. Why is delete-old repeatedly asking me if I want to remove /usr/share/mk/ src.opts.mk? 2. Why is delete-old asking me if I want to remove something that is required to build ports, well at least one port? I did not try to build any other ports, so maybe it was just a virtualbox-ose issue? 3. Should I keep src.opts.mk at delete-old or remove it? I saw some discussion about src.opts.mk, but it centered around the use of WITHOUT_NIS, which is not my issue. Thanks. -Tom ___ 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: delete-old issue with src.opts.mk
On Sat, May 10, 2014 at 3:54 PM, Warner Losh i...@bsdimp.com wrote: On May 10, 2014, at 9:45 AM, Thomas Hoffmann trh...@gmail.com wrote: The other night I built a new -CURRENT at r265728. At delete-old it asked me if I wanted to remove /usr/share/mk/src.opts.mk? I said yes. Subsequently an upgrade attempt for virtualbox-ose-4.3.10_1 failed with a missing src.opts.mk http://src.opt.mk error. I’ve fixed that. Last night I built a new -CURRENT at 265793. At delete-old it asked me if I wanted to remove /usr/share/mk/src.opts.mk?again. I said no. Subsequently an upgrade for virtualbox-ose-4.3.10_1 succeded. You should say yes. Three questions: 1. Why is delete-old repeatedly asking me if I want to remove /usr/share/mk/ src.opts.mk? It seems to keep getting installed. It shouldn’t be now that I’ve got things ironed out. 2. Why is delete-old asking me if I want to remove something that is required to build ports, well at least one port? I did not try to build any other ports, so maybe it was just a virtualbox-ose issue? It isn’t required to build ports. Well, it was for a couple of days due to a bug, but I’ve fixed that bug. 3. Should I keep src.opts.mk at delete-old or remove it? Remove it. It should ask you at most one more time. I saw some discussion about src.opts.mk, but it centered around the use of WITHOUT_NIS, which is not my issue. Yea. I understand. The WITHOUT_NIS was a different, and subtle, bug that I fixed as well. My advise: update to the tip of head, buildworld, install world, delete-old (making sure you say ‘yes’) and then try virtualbox-ose build again. It should just work. If it doesn’t then send in a bug report since I missed something when I fixed nvidia and cuse builds. Thanks for the report. I hope I can get this all ironed out for you. I think I have already, but the build system is rather fragile, I’m coming to discover, and used in several non-obvious use cases that seem obvious after the bug report comes in… Sorry these slipped through the cracks in my testing... Warner Thanks for the response. I'll follow your advice above when I build -CURRENT again tonight. No apology necessary. I build a new -CURRENT nearly every night and expect to run into a glitch every now and again. -Tom ___ 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: ZFS bug or feature
In /boot/loader.conf: kern.geom.label.disk_ident.enable=0 will disable the use of disk ids. -Tom ___ 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 delete-old/delete-old-libs issue after r264673 build
On Sat, Apr 19, 2014 at 1:05 AM, Jung-uk Kim j...@freebsd.org wrote: On 2014-04-18 23:46:46 -0400, Thomas Hoffmann wrote: After building at -CURRENT amd64 r264673, I got the following errors running 'make delete-old' and 'make delete-old-libs': ... This should be fixed in r264674. Jung-uk Kim With r264674, I no longer see those errors reported at delete-old or delete-old-libs, however, I now see those errors reported at the beginning of buildworld, buildkernel, installkernel, and installworld. With r264673 I only saw the errors at delete-old and delete-old-libs. -Tom ___ 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 delete-old/delete-old-libs issue after r264673 build
On Sat, Apr 19, 2014 at 2:27 AM, Jung-uk Kim j...@freebsd.org wrote: On 2014-04-19 02:14:58 -0400, Thomas Hoffmann wrote: On Sat, Apr 19, 2014 at 1:05 AM, Jung-uk Kim j...@freebsd.org mailto:j...@freebsd.org wrote: On 2014-04-18 23:46:46 -0400, Thomas Hoffmann wrote: After building at -CURRENT amd64 r264673, I got the following errors running 'make delete-old' and 'make delete-old-libs': ... This should be fixed in r264674. Jung-uk Kim With r264674, I no longer see those errors reported at delete-old or delete-old-libs, however, I now see those errors reported at the beginning of buildworld, buildkernel, installkernel, and installworld. With r264673 I only saw the errors at delete-old and delete-old-libs. I can't reproduce it. Do you have the bsd.mkopt.mk in /usr/share/mk, i.e., did you do installworld? Jung-uk Kim Had I taken a bit more time to think on it before my last post, I would have realized that what I was seeing is exactly what I should have expected. In order to reproduce my problem, you would have had to build at r264673 and then again at r264674. When I built at r264673, I was using the last good *.mk installed from r264633. That is why I did not see the errors for buildworld, buildkernel, installkernel and installworld. But, since installworld at r264673 installed the bad *.mk, that is why I saw the errors for the subsequent delete-old and delete-old-libs. When I re-built at r264674, I was still using the bad *.mk installed from r264673. That is why I saw the errors for buildworld, buildkernel, installkernel and installworld. But, since installworld at r264674 installed the good (i.e., fixed) *.mk, that is why I no longer saw the errors for the subsequent delete-old and delete-old-libs. My apologies for not realizing this earlier. -Tom ___ 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 delete-old/delete-old-libs issue after r264673 build
On Sat, Apr 19, 2014 at 9:29 PM, Warner Losh i...@bsdimp.com wrote: bad mk files? jkim@ resolved this for me w/ r264674. ___ 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
make delete-old/delete-old-libs issue after r264673 build
After building at -CURRENT amd64 r264673, I got the following errors
running 'make delete-old' and 'make delete-old-libs':
# make delete-old
make[2]: /usr/share/mk/bsd.opts.mk line 239: Could not find bsd.mkopt.mk
make[2]: /usr/share/mk/bsd.opts.mk line 262: Malformed conditional
(${MK_LIBPTHREAD} == no)
make[2]: /usr/share/mk/bsd.opts.mk line 266: Malformed conditional
(${MK_LDNS} == no)
make[2]: /usr/share/mk/bsd.opts.mk line 271: Malformed conditional
(${MK_SOURCELESS} == no)
make[2]: /usr/share/mk/bsd.opts.mk line 276: Malformed conditional
(${MK_CDDL} == no)
make[2]: /usr/share/mk/bsd.opts.mk line 281: Malformed conditional
(${MK_CRYPT} == no)
make[2]: /usr/share/mk/bsd.opts.mk line 287: Malformed conditional
(${MK_CXX} == no)
make[2]: /usr/share/mk/bsd.opts.mk line 292: Malformed conditional
(${MK_MAIL} == no)
make[2]: /usr/share/mk/bsd.opts.mk line 298: Malformed conditional
(${MK_NETGRAPH} == no)
make[2]: /usr/share/mk/bsd.opts.mk line 303: Malformed conditional
(${MK_OPENSSL} == no)
make[2]: /usr/share/mk/bsd.opts.mk line 308: Malformed conditional
(${MK_PF} == no)
make[2]: /usr/share/mk/bsd.opts.mk line 312: Malformed conditional
(${MK_TEXTPROC} == no)
make[2]: /usr/share/mk/bsd.opts.mk line 316: Malformed conditional
(${MK_CROSS_COMPILER} == no)
make[2]: /usr/share/mk/bsd.opts.mk line 322: Malformed conditional
(${MK_TOOLCHAIN} == no)
make[2]: /usr/share/mk/bsd.opts.mk line 329: Malformed conditional
(${MK_CLANG} == no)
make[2]: /usr/share/mk/bsd.opts.mk line 352: Malformed conditional
(defined(WITHOUT_${:UBZIP2}_SUPPORT) || ${MK_${:UBZIP2}} == no)
make[2]: /usr/share/mk/bsd.opts.mk line 352: Malformed conditional
(defined(WITHOUT_${:UGNU}_SUPPORT) || ${MK_${:UGNU}} == no)
make[2]: /usr/share/mk/bsd.opts.mk line 352: Malformed conditional
(defined(WITHOUT_${:UINET}_SUPPORT) || ${MK_${:UINET}} == no)
make[2]: /usr/share/mk/bsd.opts.mk line 352: Malformed conditional
(defined(WITHOUT_${:UINET6}_SUPPORT) || ${MK_${:UINET6}} == no)
make[2]: /usr/share/mk/bsd.opts.mk line 352: Malformed conditional
(defined(WITHOUT_${:UKERBEROS}_SUPPORT) || ${MK_${:UKERBEROS}} == no)
make[2]: /usr/share/mk/bsd.opts.mk line 352: Malformed conditional
(defined(WITHOUT_${:UKVM}_SUPPORT) || ${MK_${:UKVM}} == no)
make[2]: /usr/share/mk/bsd.opts.mk line 352: Malformed conditional
(defined(WITHOUT_${:UNETGRAPH}_SUPPORT) || ${MK_${:UNETGRAPH}} == no)
make[2]: /usr/share/mk/bsd.opts.mk line 352: Malformed conditional
(defined(WITHOUT_${:UPAM}_SUPPORT) || ${MK_${:UPAM}} == no)
make[2]: /usr/share/mk/bsd.opts.mk line 352: Malformed conditional
(defined(WITHOUT_${:UWIRELESS}_SUPPORT) || ${MK_${:UWIRELESS}} == no)
make[2]: /usr/share/mk/bsd.own.mk line 129: Malformed conditional
(${MK_CTF} != no)
make[2]: /usr/share/mk/bsd.own.mk line 137: Malformed conditional
(${MK_INSTALL_AS_USER} != no)
make[2]: Fatal errors encountered -- cannot continuemake[1]:
/usr/src/Makefile.inc1 line 135: warning: make -C /usr/src/release -V
REVISION returned non-zero status
make[2]: /usr/share/mk/bsd.opts.mk line 239: Could not find bsd.mkopt.mk
Maybe r26466{1|2|3|4} could be the source?
-Tom
___
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: r264391 breaks buildworld for -CURRENT amd64
On Sun, Apr 13, 2014 at 2:24 AM, Nathan Whitehorn nwhiteh...@freebsd.orgwrote: Thanks for the report. It should be fixed now. Apologies for the breakage! -Nathan Thanks for the fix. No apology necessary. Any bump(s) related to getting efi boot for amd64 working in HEAD get a free pass with me! -Tom ___ 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
r264391 breaks buildworld for -CURRENT amd64
Reference: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=9766061+0+current/svn-src-head An attempt to make buildworld on -CURRENT amd64 at r264394 failed with the following error: === lib/liby (depend) --- sys.depend__D --- make[6]: make[6]: don't know how to make reloc.c. Stop make[6]: stopped in /usr/src/sys/boot/amd64/boot1.efi *** [depend] Error code 2 Reverting to r264390 resolves the issue. -Tom ___ 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: File not found in ftp repository
On Sun, Mar 16, 2014 at 11:56 PM, Nilton Jose Rizzo ri...@i805.com.brwrote: Em Mon, 17 Mar 2014 00:03:29 -0300, Nilton Jose Rizzo escreveu Em Sun, 16 Mar 2014 11:31:58 -0400, Thomas Hoffmann escreveu On Sun, Mar 16, 2014 at 9:38 AM, Nilton Jose Rizzo ri...@i805.com.br wrote: root@valfenda:/home2/rizzo # wget ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/xfce4/xfce4-equake- plugin-1.3.4.tar.bz2 --2014-03-16 10:34:32-- ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/xfce4/xfce4-equake- plugin-1.3.4.tar.bz2 = 'xfce4-equake-plugin-1.3.4.tar.bz2' Resolvendo ftp.freebsd.org (ftp.freebsd.org)... 204.152.184.73, 2001:4f8:0:2::e Conectando-se a ftp.freebsd.org (ftp.freebsd.org )|204.152.184.73|:21... conectado. Acessando como anonymous ... Acesso autorizado! ( Access grant) == SYST ... feito. == PWD ... feito. == TYPE I ... feito. == CWD (1) /pub/FreeBSD/ports/distfiles/xfce4 ... feito. == SIZE xfce4-equake-plugin-1.3.4.tar.bz2 ... feito. == PASV ... feito. == RETR xfce4-equake-plugin-1.3.4.tar.bz2 ... O arquivo 'xfce4-equake-plugin-1.3.4.tar.bz2' não foi encontrado. (file not found) this file was required by xfce4 and not found in any repository where can I found it? Rizzo Does this get you what you need: http://archive.xfce.org/src/panel-plugins/xfce4-equake-plugin/1.3/ -Tom Thankx Tom Hey Tom, look this, root@valfenda:/usr/ports/science/xfce4-equake-plugin # make build deinstall reinstall pkg-static: PACKAGESITE in pkg.conf is deprecated. Please create a repository configuration file === License GPLv3 accepted by the user === xfce4-equake-plugin-1.3.4 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by xfce4-equake-plugin-1.3.4 for building === Extracting for xfce4-equake-plugin-1.3.4 = SHA256 Checksum mismatch for xfce4/xfce4-equake-plugin-1.3.4.tar.bz2. === Refetch for 1 more times files: xfce4/xfce4-equake-plugin-1.3.4.tar.bz2 pkg-static: PACKAGESITE in pkg.conf is deprecated. Please create a repository configuration file === License GPLv3 accepted by the user === xfce4-equake-plugin-1.3.4 depends on file: /usr/local/sbin/pkg - found = xfce4-equake-plugin-1.3.4.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/xfce4. = Attempting to fetch http://mirror.perldude.de/archive.xfce.org/src/panel-plugins/xfce4-equake-plugin/1.3/xfce4-equake-plugin-1.3.4.tar.bz2 fetch: http://mirror.perldude.de/archive.xfce.org/src/panel-plugins/xfce4-equake-plugin/1.3/xfce4-equake-plugin-1.3.4.tar.bz2 : size mismatch: expected 385454, actual 385283 The size of file is grater than origi, and the make try to download other file to replace. Rizzo Rizzo I would change the SIZE in science/xfce4-equake-plugin/distinfo to match the size of the file you fetched (i.e., 385283) from the xfce site and see what happens. ___ 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
Newcons with Nvidia
The newcons wiki page shows that newcons with Nvidia as UNKNOWN. That may or may not change after this report. I'm running -CURRENT r263278 amd64 with an Nvidia GeForce 8800M GTS using the nv driver from x11-drivers/xorg-driver. I built/booted a newcons kernel, applied the vidcontrol-for-vt-2014-03-11patch and installed the /usr/share/vt/fonts/gallant.fnt font. With syscons, I would start with an 80x24 text console for the boot and then switch to a 1920x1200 (240x75 - 8x16) virtual terminal once allscreens_flags got processed in /etc/rc.conf. With newcons, there were four changes of note: 1) a new console font (gallant maybe?) for the 80x24 text console; 2) no mode switch to 1920x1200 with allscreens_flags. The message vidcontrol: Setting video mode: inappropriate ioctl for device was written to the console/terminal, ostensibly when it tried to process allscreens_flags. 3) The message Configuring syscons: blanktimevt4_mode = 1; allscreensvt4_mode = 1 was written to the console around the time (I think) /etc/rc.conf was being processed. Not sure what these mean. 4) vidcontrol -i mode shows no usable modes (all show x) or fonts (all show 0x0). So, some questions: 1) Is what I am seeing expected given the current state of newcons development and the Nvidia card/driver? 2) Is there a way to get back to a 1920x1200 video mode for my virtual terminals with newcons? Or even get it early in the boot process? 3) Are there any tests I can run that would be of value to the newcons team -OR- 4) Should I just take my newcons kernel and Nvidia card and go away :))) I'll admit I spend so little time using virtual terminals I almost don't care what mode newcons gives me. As long as X gives me 1920x1200, and it still does, I'll be happy. Thanks for all your efforts on newcons. -Tom ___ 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: File not found in ftp repository
On Sun, Mar 16, 2014 at 9:38 AM, Nilton Jose Rizzo ri...@i805.com.brwrote: root@valfenda:/home2/rizzo # wget ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/xfce4/xfce4-equake-plugin-1.3.4.tar.bz2 --2014-03-16 10:34:32-- ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/xfce4/xfce4-equake-plugin-1.3.4.tar.bz2 = 'xfce4-equake-plugin-1.3.4.tar.bz2' Resolvendo ftp.freebsd.org (ftp.freebsd.org)... 204.152.184.73, 2001:4f8:0:2::e Conectando-se a ftp.freebsd.org (ftp.freebsd.org)|204.152.184.73|:21... conectado. Acessando como anonymous ... Acesso autorizado! ( Access grant) == SYST ... feito. == PWD ... feito. == TYPE I ... feito. == CWD (1) /pub/FreeBSD/ports/distfiles/xfce4 ... feito. == SIZE xfce4-equake-plugin-1.3.4.tar.bz2 ... feito. == PASV ... feito. == RETR xfce4-equake-plugin-1.3.4.tar.bz2 ... O arquivo 'xfce4-equake-plugin-1.3.4.tar.bz2' não foi encontrado. (file not found) this file was required by xfce4 and not found in any repository where can I found it? Rizzo Does this get you what you need: http://archive.xfce.org/src/panel-plugins/xfce4-equake-plugin/1.3/ -Tom ___ 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: [PATCH] PCI bus number management
On Thu, Feb 6, 2014 at 2:37 PM, John Baldwin j...@freebsd.org wrote: I have a patch to teach the PCI bus code and PCI-PCI bridge driver to manage PCI bus numbers. The approach is somewhat similar to how NEW_PCIB manages I/O windows for briges. Each bridge creates an rman to manage the bus numbers for all buses and bridges that live below it. Each bus allocates a bus resource from its parent bridge, and child bridges allocate their ranges from their parent devices. At the top of the PCI tree, the Host-PCI bridges allocate their respective bus ranges from their PCI domain/segment. There isn't really a device node for PCI domains, so I created a helper API that basically auto- creates a PCI bus rman for each domain on first use and then sub-allocates from that for Host-PCI bridges. The current patch (with some extra debugging) is at http://people.FreeBSD.org/~jhb/patches/pci_bus_rman.3.patch I would like to commit this to HEAD soon but thought I would post it for some pre-commit testing for the brave. :) If you are really brave, try booting with 'hw.pci.clear_buses=1' which will force the kernel to renumber all buses in the system. If you are really, really brave, try booting with 'hw.pci.clear_bars=1', 'hw.pci.clear_buses=1', and 'hw.pci.clear_pcib=1'. (My laptop survives with all those set) Note that the patch only enables bus number management on amd64 and i386. I believe ia64 just needs to define PCI_RES_BUS for this to work since it mandates ACPI. Porting this to other platforms requires handling PCI_RES_BUS rseources for Host-PCI bridges in bus_alloc_resource(), bus_adjust_resource(), and bus_release_resource(). -- John Baldwin I get a 404 - Not Found trying to follow the link. ___ 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: [PATCH] PCI bus number management
On Thu, Feb 6, 2014 at 2:47 PM, Thomas Hoffmann trh...@gmail.com wrote: On Thu, Feb 6, 2014 at 2:37 PM, John Baldwin j...@freebsd.org wrote: I have a patch to teach the PCI bus code and PCI-PCI bridge driver to manage PCI bus numbers. The approach is somewhat similar to how NEW_PCIB manages I/O windows for briges. Each bridge creates an rman to manage the bus numbers for all buses and bridges that live below it. Each bus allocates a bus resource from its parent bridge, and child bridges allocate their ranges from their parent devices. At the top of the PCI tree, the Host-PCI bridges allocate their respective bus ranges from their PCI domain/segment. There isn't really a device node for PCI domains, so I created a helper API that basically auto- creates a PCI bus rman for each domain on first use and then sub-allocates from that for Host-PCI bridges. The current patch (with some extra debugging) is at http://people.FreeBSD.org/~jhb/patches/pci_bus_rman.3.patch I would like to commit this to HEAD soon but thought I would post it for some pre-commit testing for the brave. :) If you are really brave, try booting with 'hw.pci.clear_buses=1' which will force the kernel to renumber all buses in the system. If you are really, really brave, try booting with 'hw.pci.clear_bars=1', 'hw.pci.clear_buses=1', and 'hw.pci.clear_pcib=1'. (My laptop survives with all those set) Note that the patch only enables bus number management on amd64 and i386. I believe ia64 just needs to define PCI_RES_BUS for this to work since it mandates ACPI. Porting this to other platforms requires handling PCI_RES_BUS rseources for Host-PCI bridges in bus_alloc_resource(), bus_adjust_resource(), and bus_release_resource(). -- John Baldwin I get a 404 - Not Found trying to follow the link. Got it by backing up one level on the link and selecting form the list. ___ 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
libelf.so.1 missing after -CURRENT update
Did my weekly update of -CURRENT today to r261350 from r261236. After the upgrade when I tried to run 'pkg' I got the error: libelf.so.1 required by libpkg.so.1 So, I reinstalled 'pkg', which fixed the problem. Then I ran pkg_libchk to see if any other libs were missing and got: glib -2.36.3_1: /usr/local/bin/gresource misses libelf.so.1 So i re-installed glib and re-ran pkg_libchk against it. No more missing libelf.so.1. Anyway, I'm wondering if I inadvertently deleted libelf.so.1 during the 'make delete-old' or 'make delete-old-libs' steps of the rebuild. Unfortunately, these are the only two steps of the build process (mergemaster excepted) that I do not 'script' the output, so I cannot go back to see if that is the case. Obviously I need to begin script'ing these two steps on future builds. Anyone else seen this or that can confirm an inadvertent delete of libelf.so.1 on my part? Thanks. -Tom ___ 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: libelf.so.1 missing after -CURRENT update
On Sat, Feb 1, 2014 at 3:55 PM, Glen Barber g...@freebsd.org wrote: On Sat, Feb 01, 2014 at 03:52:32PM -0500, Thomas Hoffmann wrote: Did my weekly update of -CURRENT today to r261350 from r261236. After the upgrade when I tried to run 'pkg' I got the error: libelf.so.1 required by libpkg.so.1 So, I reinstalled 'pkg', which fixed the problem. Then I ran pkg_libchk to see if any other libs were missing and got: glib -2.36.3_1: /usr/local/bin/gresource misses libelf.so.1 So i re-installed glib and re-ran pkg_libchk against it. No more missing libelf.so.1. Anyway, I'm wondering if I inadvertently deleted libelf.so.1 during the 'make delete-old' or 'make delete-old-libs' steps of the rebuild. Unfortunately, these are the only two steps of the build process (mergemaster excepted) that I do not 'script' the output, so I cannot go back to see if that is the case. Obviously I need to begin script'ing these two steps on future builds. Anyone else seen this or that can confirm an inadvertent delete of libelf.so.1 on my part? r261246 updates libelf.so to version 2. Glen Okay, so I wasn't stupid, just negligent. I usually run pkg_libchk immediately after my builds to pick up these types of changes and to know what ports I need to rebuild. Got distracted today and did not do this immediately. Thanks. -Tom ___ 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: Problem updating bootcode on ZFS on root system with MBR
On Sun, Jan 26, 2014 at 3:46 AM, Scot Hetzel swhet...@gmail.com wrote: On Tue, Jan 21, 2014 at 3:11 PM, Thomas Hoffmann trh...@gmail.com wrote: On Tue, Jan 21, 2014 at 10:47 AM, Andriy Gapon a...@freebsd.org wrote: on 21/01/2014 13:18 Andrey V. Elsukov said the following: On 21.01.2014 14:45, Andriy Gapon wrote: What do I need to do to get the boot2 code written to /dev/ada0s1a? # dd if=/boot/zfsboot of=/dev/ada0s1a skip=1 seek=1024 dd: /dev/ada0s1a: Operation not permitted Thanks for the responses. My apologies for going silent, but I had to step away from the problem for a bit. I was able to resolve my problem by doing the following: After upgrading my zpools and after my aborted attempt to update the bootcode as reported above, I copied /boot/zfsboot (or more precisely /bootpool/boot/zfsboot) to a USB thumb drive. I attempted to reboot my system, which failed due to unsupported zfs features. This was expected, but I thought, hey, I might get lucky. I then booted into a Live CD, mounted my USB thumb drive on /tmp/usb and executed: sysctl kern.geom.debugflags=0x10 dd if=/tmp/usb/zfsboot of=/dev/ada0s1 count=1 dd if=/tmp/usb/zfsboot of=/dev/ada0s1d skip=1 seek=1024 Then I rebooted and all is well. All zpools support all features. While this procedure was not tedious, it would still be nice if, as Andriy stated, FreeBSD contained a native way do this zfs bootcode update for MBR schemes that is as simple as for the GPT schemes. In your original message, you were trying to write the boot code to ada0s1a, but you made it work by using ada0s1d. Do you have an ada0s1a? If you do, is it your ZFS partition or is it ada0s1d? I can see why you are confused. In between the original problem and the solution I did a fresh install of FreeBSD-10.0-REL, which creates a bootpool on ada0s1a, swap on ada0s1b and the zfs partition on ada0s1d. So that is why the discrepancy between the original problem and solution. The original system had the zfs partition on ada0s1a and swap on ada0s1b. In retrospect I should have been more clear on this in my postings. BTW, I got the [definitive] update process for zfs bootcode on MBR partitioned systems from you a while back. So thanks for that. I actually understand what I'm doing now when I update the zfs bootcode. -Tom -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. ___ 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: lock order reversals w/ backtrace
On Fri, Jan 24, 2014 at 11:47 PM, Thomas Hoffmann trh...@gmail.com wrote: On Fri, Jan 24, 2014 at 9:52 AM, Thomas Hoffmann trh...@gmail.com wrote: On Thu, Jan 23, 2014 at 11:49 AM, Hans Petter Selasky hans.petter.sela...@bitfrost.no wrote: Hi, Can you see if you can snap some keywords of the backtraces, like usb_xxx usbdx_xxx cam scsi or something like that. Else I believe there are some sysctl options to prevent the final reboot somehow so that you can write down the messages. --HPS -Original message- From:Thomas Hoffmann trh...@gmail.com Sent: Thursday 23rd January 2014 17:15 To: freebsd-current freebsd-current@freebsd.org Subject: lock order reversals w/ backtrace A few days ago I started running 11.0-CURRENT at r260971 for the first time. The last couple of times I shutdown my system I noticed 2 or 3 short lock order reversal messages with accompanying backtraces scroll by. Do these messages represent a problem that I should report or can I ignore them as debug in nature? If I should report them, how or where do these messages get logged? I can find no reference to them in syslog or anywhere else upon my subsequent reboot. I also had a couple of these messages pop up the other day while mounting/umounting USB thumb drives. I did not think anything of them at the time as the mounts/umounts completed successfully. Please advise. Thanks. -Tom I managed to snap a photo of my screen during shutdown. Here is the full text of the first of two lock order reversals I got last night during system shutdown, both of which are zfs-related to (it appears?) unmounts. A few lines got chopped as they were out-of-frame when I took the photo: shutting down local daemons: lock order reversal: 1st 0xf801194f67c8 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1237 2nd 0xf801194f6420 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:22[..chopped...] KDB: stack backtrace: db_trace_self_wrapper() at db_trace_delf_wrapper+0x2b/frame 0xfe01ac78[...chopped...] kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe01ac784650 witness_checkorder() at witness_checkorder+0xd23/frame 0xfe01ac7846e0 __lockmgr_args() __lockmgr_args+0x878/frame 0xfe01ac784810 vop_stdlock() at vop_stdlock+0x3c/frame 0xfe01ac784830 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xfe01ac784860 _vn_lock() at _vn_lock+0xab/frame 0xfe01ac7848d0 vputx() at vputx+0x240/frame 0xfe01ac784930 dounmount at dounmount+0x327/frame 0xfe01ac7849b0 sys_unmount() at sys_unmount+0x356/frame 0xfe01ac784ac0 amd64_syscall() at amd64_syscall+0x265/frame 0xfe01ac784bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe01ac784bf0 --- syscall (22, FreeBSD ELF64, sys_unmount, rip = 0x80191c72a, rsp[...chopped...] I have a zpool on an external USB HDD that I export at shutdown via rc.shutdown.local. Don't know if that is contributing to this or not. When I get a chance to bring down the system I will manually export it before shutdown to see if that makes any difference. Was able to capture the full text of the lock order reversal I've been experiencing at shutdown. Turns out to be associated with the export of one of my zpools that is hosted on an external USB HDD. Normally I export the zpool from rc.shutdown.local, but tonight I exported it manually before I shutdown and got the following. lock order reversal: : 1st 0xf8011952b5f0 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1237 : 2nd 0xf8011952b068 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2212 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe01add6e5a0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe01add6e650 witness_checkorder() at witness_checkorder+0xd23/frame 0xfe01add6e6e0 __lockmgr_args() at __lockmgr_args+0x878/frame 0xfe01add6e810 vop_stdlock() at vop_stdlock+0x3c/frame 0xfe01add6e830 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xfe01add6e860 _vn_lock() at _vn_lock+0xab/frame 0xfe01add6e8d0 vputx() at vputx+0x240/frame 0xfe01add6e930 dounmount() at dounmount+0x327/frame 0xfe01add6e9b0 sys_unmount() at sys_unmount+0x356/frame 0xfe01add6eae0 amd64_syscall() at amd64_syscall+0x265/frame 0xfe01add6ebf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe01add6ebf0 --- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x80191c72a, rsp = 0x7fffc4c8, rbp = 0x7fffc960 --- When imported and mounted, the zpool reports no errors and I have not experienced any anomalies reading or writing to the zpool. Should I be concerned? Hmm, seems like I'm the only one interested in this. I think I have resolved the problem with the zpool on the external USB HDD. I copied off the data, destroyed the datasets and zpool, recreated the zpool and datasets and restored the data. I have executed several exports on the zpool and have received no lock order
Re: lock order reversals w/ backtrace
On Thu, Jan 23, 2014 at 11:49 AM, Hans Petter Selasky hans.petter.sela...@bitfrost.no wrote: Hi, Can you see if you can snap some keywords of the backtraces, like usb_xxx usbdx_xxx cam scsi or something like that. Else I believe there are some sysctl options to prevent the final reboot somehow so that you can write down the messages. --HPS -Original message- From:Thomas Hoffmann trh...@gmail.com Sent: Thursday 23rd January 2014 17:15 To: freebsd-current freebsd-current@freebsd.org Subject: lock order reversals w/ backtrace A few days ago I started running 11.0-CURRENT at r260971 for the first time. The last couple of times I shutdown my system I noticed 2 or 3 short lock order reversal messages with accompanying backtraces scroll by. Do these messages represent a problem that I should report or can I ignore them as debug in nature? If I should report them, how or where do these messages get logged? I can find no reference to them in syslog or anywhere else upon my subsequent reboot. I also had a couple of these messages pop up the other day while mounting/umounting USB thumb drives. I did not think anything of them at the time as the mounts/umounts completed successfully. Please advise. Thanks. -Tom I managed to snap a photo of my screen during shutdown. Here is the full text of the first of two lock order reversals I got last night during system shutdown, both of which are zfs-related to (it appears?) unmounts. A few lines got chopped as they were out-of-frame when I took the photo: shutting down local daemons: lock order reversal: 1st 0xf801194f67c8 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1237 2nd 0xf801194f6420 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:22[..chopped...] KDB: stack backtrace: db_trace_self_wrapper() at db_trace_delf_wrapper+0x2b/frame 0xfe01ac78[...chopped...] kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe01ac784650 witness_checkorder() at witness_checkorder+0xd23/frame 0xfe01ac7846e0 __lockmgr_args() __lockmgr_args+0x878/frame 0xfe01ac784810 vop_stdlock() at vop_stdlock+0x3c/frame 0xfe01ac784830 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xfe01ac784860 _vn_lock() at _vn_lock+0xab/frame 0xfe01ac7848d0 vputx() at vputx+0x240/frame 0xfe01ac784930 dounmount at dounmount+0x327/frame 0xfe01ac7849b0 sys_unmount() at sys_unmount+0x356/frame 0xfe01ac784ac0 amd64_syscall() at amd64_syscall+0x265/frame 0xfe01ac784bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe01ac784bf0 --- syscall (22, FreeBSD ELF64, sys_unmount, rip = 0x80191c72a, rsp[...chopped...] I have a zpool on an external USB HDD that I export at shutdown via rc.shutdown.local. Don't know if that is contributing to this or not. When I get a chance to bring down the system I will manually export it before shutdown to see if that makes any difference. ___ 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: lock order reversals w/ backtrace
On Fri, Jan 24, 2014 at 9:52 AM, Thomas Hoffmann trh...@gmail.com wrote: On Thu, Jan 23, 2014 at 11:49 AM, Hans Petter Selasky hans.petter.sela...@bitfrost.no wrote: Hi, Can you see if you can snap some keywords of the backtraces, like usb_xxx usbdx_xxx cam scsi or something like that. Else I believe there are some sysctl options to prevent the final reboot somehow so that you can write down the messages. --HPS -Original message- From:Thomas Hoffmann trh...@gmail.com Sent: Thursday 23rd January 2014 17:15 To: freebsd-current freebsd-current@freebsd.org Subject: lock order reversals w/ backtrace A few days ago I started running 11.0-CURRENT at r260971 for the first time. The last couple of times I shutdown my system I noticed 2 or 3 short lock order reversal messages with accompanying backtraces scroll by. Do these messages represent a problem that I should report or can I ignore them as debug in nature? If I should report them, how or where do these messages get logged? I can find no reference to them in syslog or anywhere else upon my subsequent reboot. I also had a couple of these messages pop up the other day while mounting/umounting USB thumb drives. I did not think anything of them at the time as the mounts/umounts completed successfully. Please advise. Thanks. -Tom I managed to snap a photo of my screen during shutdown. Here is the full text of the first of two lock order reversals I got last night during system shutdown, both of which are zfs-related to (it appears?) unmounts. A few lines got chopped as they were out-of-frame when I took the photo: shutting down local daemons: lock order reversal: 1st 0xf801194f67c8 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1237 2nd 0xf801194f6420 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:22[..chopped...] KDB: stack backtrace: db_trace_self_wrapper() at db_trace_delf_wrapper+0x2b/frame 0xfe01ac78[...chopped...] kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe01ac784650 witness_checkorder() at witness_checkorder+0xd23/frame 0xfe01ac7846e0 __lockmgr_args() __lockmgr_args+0x878/frame 0xfe01ac784810 vop_stdlock() at vop_stdlock+0x3c/frame 0xfe01ac784830 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xfe01ac784860 _vn_lock() at _vn_lock+0xab/frame 0xfe01ac7848d0 vputx() at vputx+0x240/frame 0xfe01ac784930 dounmount at dounmount+0x327/frame 0xfe01ac7849b0 sys_unmount() at sys_unmount+0x356/frame 0xfe01ac784ac0 amd64_syscall() at amd64_syscall+0x265/frame 0xfe01ac784bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe01ac784bf0 --- syscall (22, FreeBSD ELF64, sys_unmount, rip = 0x80191c72a, rsp[...chopped...] I have a zpool on an external USB HDD that I export at shutdown via rc.shutdown.local. Don't know if that is contributing to this or not. When I get a chance to bring down the system I will manually export it before shutdown to see if that makes any difference. Was able to capture the full text of the lock order reversal I've been experiencing at shutdown. Turns out to be associated with the export of one of my zpools that is hosted on an external USB HDD. Normally I export the zpool from rc.shutdown.local, but tonight I exported it manually before I shutdown and got the following. lock order reversal: : 1st 0xf8011952b5f0 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1237 : 2nd 0xf8011952b068 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2212 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe01add6e5a0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe01add6e650 witness_checkorder() at witness_checkorder+0xd23/frame 0xfe01add6e6e0 __lockmgr_args() at __lockmgr_args+0x878/frame 0xfe01add6e810 vop_stdlock() at vop_stdlock+0x3c/frame 0xfe01add6e830 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xfe01add6e860 _vn_lock() at _vn_lock+0xab/frame 0xfe01add6e8d0 vputx() at vputx+0x240/frame 0xfe01add6e930 dounmount() at dounmount+0x327/frame 0xfe01add6e9b0 sys_unmount() at sys_unmount+0x356/frame 0xfe01add6eae0 amd64_syscall() at amd64_syscall+0x265/frame 0xfe01add6ebf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe01add6ebf0 --- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x80191c72a, rsp = 0x7fffc4c8, rbp = 0x7fffc960 --- When imported and mounted, the zpool reports no errors and I have not experienced any anomalies reading or writing to the zpool. Should I be concerned? ___ 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: Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD i386 10.0 Release.
On Thu, Jan 23, 2014 at 9:56 AM, Warren Block wbl...@wonkity.com wrote: Using -DNOCLEAN with an existing /usr/obj can go even faster than ccache: less than two minutes for a buildworld on my frequently updated i5/SSD system, sometimes less than one minute. Can you elaborate on this, please? I always clear my /usr/obj before starting a buildworld, which takes 2 hours to run on my system. Are you saying if I do make -DNOCLEAN buildworld I do not have to clear /usr/obj first AND my buildworld will run faster (AND with no downside)? Thanks. -Tom ___ 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
lock order reversals w/ backtrace
A few days ago I started running 11.0-CURRENT at r260971 for the first time. The last couple of times I shutdown my system I noticed 2 or 3 short lock order reversal messages with accompanying backtraces scroll by. Do these messages represent a problem that I should report or can I ignore them as debug in nature? If I should report them, how or where do these messages get logged? I can find no reference to them in syslog or anywhere else upon my subsequent reboot. I also had a couple of these messages pop up the other day while mounting/umounting USB thumb drives. I did not think anything of them at the time as the mounts/umounts completed successfully. Please advise. Thanks. -Tom ___ 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: Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD i386 10.0 Release.
On Thu, Jan 23, 2014 at 11:52 AM, Warren Block wbl...@wonkity.com wrote: On Thu, 23 Jan 2014, Kevin Oberman wrote: On Thu, Jan 23, 2014 at 7:47 AM, Thomas Hoffmann trh...@gmail.com wrote: On Thu, Jan 23, 2014 at 9:56 AM, Warren Block wbl...@wonkity.com wrote: Using -DNOCLEAN with an existing /usr/obj can go even faster than ccache: less than two minutes for a buildworld on my frequently updated i5/SSD system, sometimes less than one minute. Can you elaborate on this, please? I always clear my /usr/obj before starting a buildworld, which takes 2 hours to run on my system. Are you saying if I do make -DNOCLEAN buildworld I do not have to clear /usr/obj first Yes. Removing /usr/obj is a faster way of doing 'make clean', mostly. AND my buildworld will run faster Yes, because make will see that many/most files have already been built. (AND with no downside)? Well... mostly. :) I noticed that after 10.0-RELEASE, uname on my system still said PRERELEASE. That code had not been rebuilt because make did not see it as needing a rebuild. You can still delete /usr/obj and run a full buildworld from scratch every so often. I should give credit to bdrewery@ for reminding me about -DNOCLEAN when I was whining about ccache not working on 10.0. It turned out to be a better solution. Hmm, I particularly like your suggestion of running a full buildworld periodically. With two hour buildworlds (from scratch) I was planning on rebuilding every couple of weeks. If using -DNOCLEAN can significantly reduce my buildworld time, I'll rebuild weekly and do a full build every fourth week. I'm anxious to give this approach a go and see how much time I can save on the buildworlds. Thanks for the info and tips. -Tom ___ 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: Fw: Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD i386 10.0 Release.
On Thu, Jan 23, 2014 at 2:15 PM, Matthew Rezny matt...@reztek.cz wrote: Forwarded because my attempt to reply on list was rejected by heavy-handed and oblivious moderation: The freebsd-current mailing list is for issues involving FreeBSD-CURRENT, not FreeBSD-STABLE. Neither FreeBSD 9.x nor 10.x is current -- CURRENT became FreeBSD 11.x as of Thu Oct 10 18:05:13 2013 UTC. Feel free to forward on to the list if you feel this is valuable to others. Apparently list owner looked only at the topic, ignore the fact it's a reply several levels deep, and did NOT look at the content. Begin forwarded message: Date: Thu, 23 Jan 2014 18:22:50 +0100 From: Matthew Rezny matt...@reztek.cz To: freebsd-current@freebsd.org Subject: Re: Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD i386 10.0 Release. On Thu, Jan 23, 2014 at 9:56 AM, Warren Block wblock at wonkity.com wrote: Using -DNOCLEAN with an existing /usr/obj can go even faster than ccache: less than two minutes for a buildworld on my frequently updated i5/SSD system, sometimes less than one minute. Can you elaborate on this, please? I always clear my /usr/obj before starting a buildworld, which takes 2 hours to run on my system. Are you saying if I do make -DNOCLEAN buildworld I do not have to clear /usr/obj first AND my buildworld will run faster (AND with no downside)? Thanks. -Tom If you always clear your /usr/obj, you can safely add -DNOCLEAN to the build and it will shave off a minute or two (depending on drive speed) that would have been spent attempting to delete thousands of non- existent files and directories. I've never actually benchmarked, but rm -rf /usr/obj followed by make -DNOCLEAN buildworld should take slightly less time than a regular buildworld (unless perhaps you use a tmpfs backed /usr/obj). Yes, you can safely do a make -DNOCLEAN bulidworld without first clearing out /usr/obj iff conditions are right. If you change anything in src.conf or make.conf, then you must clean. If you switch what branch you are checking out from then you must clean. If you are tracking -STABLE or -CURRENT with regularity (as Warren does) then you can usually get away with not cleaning. If you go too long between updates to your /usr/src then you might have to clean. If there is a disruptive commit, you might have to clean. Sometimes it will be obvious because the buildworld won't complete without error, but sometimes it will finish with apparent success however some binaries will be bad. So, if you get some rather strange behavior shortly after installworld, go clean it and build again. If you are doing your own local development, then you can safely use -DNOCLEAN throughout the process. Only if you make a disruptive change yourself or possibly if you merge changes from svn would you need to clean the build. This is good to know, especially the info on when using -DNOCLEAN might cause problems and how they might manifest themselves. Thanks. -Tom ___ 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: Problem updating bootcode on ZFS on root system with MBR
On Tue, Jan 21, 2014 at 10:47 AM, Andriy Gapon a...@freebsd.org wrote:
on 21/01/2014 13:18 Andrey V. Elsukov said the following:
On 21.01.2014 14:45, Andriy Gapon wrote:
What do I need to do to get the boot2 code written to /dev/ada0s1a?
This will work only if ada0s1a isn't in use. The debugflags trick works
only for whole disk, i.e. for geoms with rank=1. Another way is
calculate needed offset and write bootcode directly to ada0.
And ultimately we should extend our ZFS interface with an ioctl to
write a blob
to a boot code area of a specified ZFS leaf vdev. This would the right
way to
install zfsboot.
Hi Andriy,
do you have some patches to test? :-)
I don't, but the following patch can serve as a very good example.
It adds an ioctl that serves a slightly different but quite similar
purpose:
commit 54802d6659ec134fd221c3daaa8fdf9cee985d39
Author: Andriy Gapon a...@icyb.net.ua
Date: Fri Sep 14 23:15:43 2012 +0300
[wip] zfs: add a new ioctl that allows to place text data into pad2
area
The data is placed into Pad2 area of the first vdev label of a given
vdev in a given pool.
diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h
b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h
index fb30ea9..4a46cc2 100644
--- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h
+++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h
@@ -162,6 +162,8 @@ typedef enum {
extern int vdev_label_init(vdev_t *vd, uint64_t txg, vdev_labeltype_t
reason);
+extern int vdev_label_write_pad2(vdev_t *vd, const char *buf, size_t
size);
+
#ifdef __cplusplus
}
#endif
diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c
b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c
index c7dd3ad..55c87d8 100644
--- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c
+++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c
@@ -855,6 +855,44 @@ retry:
return (error);
}
+int
+vdev_label_write_pad2(vdev_t *vd, const char *buf, size_t size)
+{
+ spa_t *spa = vd-vdev_spa;
+ zio_t *zio;
+ char *pad2;
+ int flags = ZIO_FLAG_CONFIG_WRITER | ZIO_FLAG_CANFAIL;
+ int error;
+
+ if (size VDEV_PAD_SIZE)
+ return (EINVAL);
+
+ if (!vd-vdev_ops-vdev_op_leaf)
+ return (ENODEV);
+ if (vdev_is_dead(vd))
+ return (ENXIO);
+
+ ASSERT(spa_config_held(spa, SCL_ALL, RW_WRITER) == SCL_ALL);
+
+ pad2 = zio_buf_alloc(VDEV_PAD_SIZE);
+ bzero(pad2, VDEV_PAD_SIZE);
+ memcpy(pad2, buf, size);
+
+retry:
+ zio = zio_root(spa, NULL, NULL, flags);
+ vdev_label_write(zio, vd, 0, pad2,
+ offsetof(vdev_label_t, vl_pad2),
+ VDEV_PAD_SIZE, NULL, NULL, flags);
+ error = zio_wait(zio);
+ if (error != 0 !(flags ZIO_FLAG_TRYHARD)) {
+ flags |= ZIO_FLAG_TRYHARD;
+ goto retry;
+ }
+
+ zio_buf_free(pad2, VDEV_PAD_SIZE);
+ return (error);
+}
+
/*
*
==
* uberblock load/sync
diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
index e208ed8..ff90839 100644
--- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
+++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
@@ -3404,6 +3404,53 @@ zfs_ioc_log_history(const char *unused, nvlist_t
*innvl,
nvlist_t *outnvl)
return (error);
}
+#ifdef __FreeBSD__
+static int
+zfs_ioc_nextboot(const char *unused, nvlist_t *innvl, nvlist_t *outnvl)
+{
+ char name[MAXNAMELEN];
+ spa_t *spa;
+ vdev_t *vd;
+ char *command;
+ uint64_t pool_guid;
+ uint64_t vdev_guid;
+ int error;
+
+ if (nvlist_lookup_uint64(innvl,
+ ZPOOL_CONFIG_POOL_GUID, pool_guid) != 0)
+ return (EINVAL);
+ if (nvlist_lookup_uint64(innvl,
+ ZPOOL_CONFIG_GUID, vdev_guid) != 0)
+ return (EINVAL);
+ if (nvlist_lookup_string(innvl,
+ command, command) != 0)
+ return (EINVAL);
+
+ mutex_enter(spa_namespace_lock);
+ spa = spa_by_guid(pool_guid, vdev_guid);
+ if (spa != NULL)
+ strcpy(name, spa_name(spa));
+ mutex_exit(spa_namespace_lock);
+ if (spa == NULL)
+ return (ENOENT);
+
+ if ((error = spa_open(name, spa, FTAG)) != 0)
+ return (error);
+ spa_vdev_state_enter(spa, SCL_ALL);
+ vd = spa_lookup_by_guid(spa, vdev_guid, B_TRUE);
+ if (vd == NULL) {
+ (void) spa_vdev_state_exit(spa, NULL, ENXIO);
+ spa_close(spa, FTAG);
+ return (ENODEV);
+ }
+ error =
Re: panic: mtx_lock_spin: recursed on non-recursive mutex uart_hwmtx...
On Mon, Jan 20, 2014 at 11:37 AM, Konstantin Belousov kostik...@gmail.comwrote: On Mon, Jan 20, 2014 at 07:36:15AM -0800, David Wolfskill wrote: Jan 20 07:02:16 freebeast syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...2 4 4 4 3 3 3 2 1 1 0 0 0 0 done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done All buffers synced. lock order reversal: 1st 0xc7336c68 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1237 2nd 0xc76846dc devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1412 KDB: stack backtrace: db_trace_self_wrapper(c112d57c,a3231,e1fb9888,c0b1bfe7,1,...) at db_trace_self_wrapper+0x2d/frame 0xe1fb9828 kdb_backtrace(c1131131,c76846dc,c1124024,c6dad2d0,c1162dc1,...) at kdb_backtrace+0x30/frame 0xe1fb9890 witness_checkorder(c76846dc,9,c1162dc1,584,0,...) at witness_checkorder+0xc8a/frame 0xe1fb98e0 __lockmgr_args(c76846dc,80400,c76846fc,0,0,0,c1162dc1,584) at __lockmgr_args+0x844/frame 0xe1fb99b4 vop_stdlock(e1fb9a28,c6dad3a0,c6dad408,c169bc38,e1fb9a4c,...) at vop_stdlock+0x4d/frame 0xe1fb99e4 VOP_LOCK1_APV(c13828dc,e1fb9a28,0,0,c13cded0,...) at VOP_LOCK1_APV+0x104/frame 0xe1fb9a10 _vn_lock(c76846a8,80400,c1162dc1,584,c1393aac,...) at _vn_lock+0xa1/frame 0xe1fb9a50 ffs_flushfiles(c753f000,a,c6f0a310,e1fb9b38,c0d416e3,...) at ffs_flushfiles+0x14c/frame 0xe1fb9a9c softdep_flushfiles(c753f000,2,c6f0a310,0,0,...) at softdep_flushfiles+0x6e/frame 0xe1fb9af0 ffs_unmount(c753f000,8,e1fb9b70,518,c6f0a310,...) at ffs_unmount+0x194/frame 0xe1fb9b38 dounmount(c753f000,8,c6f0a310,0,e1db3eb0,...) at dounmount+0x4dc/frame 0xe1fb9b98 vfs_unmountall(e1db4058,0,c112895a,144,c6d8b1a0,...) at vfs_unmountall+0x4e/frame 0xe1fb9bb8 kern_reboot(4008,0,c112895a,c3,0,...) at kern_reboot+0x5af/frame 0xe1fb9c20 sys_reboot(c6f0a310,e1fb9cc8,14,c112b5b7,7a2,...) at sys_reboot+0x6f/frame 0xe1fb9c40 syscall(e1fb9d08) at syscall+0x2de/frame 0xe1fb9cfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe1fb9cfc --- syscall (55, FreeBSD ELF32, sys_reboot), eip = 0x805a9df, esp = 0xbfbfd88c, ebp = 0xbfbfd960 --- Uptime: 4m28s panic: mtx_lock_spin: recursed on non-recursive mutex uart_hwmtx @ /usr/src/sys/dev/uart/uart_cpu.h:94 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c112d57c,2f727375,2f637273,2f737973,2f766564,...) at db_trace_self_wrapper+0x2d/frame 0xe1fb9a60 kdb_backtrace(c12ec1f3,0,c11269a2,e1fb9b38,e1fb9b08,...) at kdb_backtrace+0x30/frame 0xe1fb9ac8 vpanic(c140d0c8,100,c11269a2,e1fb9b38,e1fb9b38,...) at vpanic+0x11f/frame 0xe1fb9b08 kassert_panic(c11269a2,c10f66d8,c10f6758,5e,8,...) at kassert_panic+0xea/frame 0xe1fb9b2c __mtx_lock_spin_flags(c7291830,0,c10f6758,5e,c137d684,...) at __mtx_lock_spin_flags+0x190/frame 0xe1fb9b5c ns8250_bus_grab(c7291800,c7062b28,c137d684,5e,c140b9a4,...) at ns8250_bus_grab+0x40/frame 0xe1fb9b78 uart_grab(c13fd070) at uart_grab+0x83/frame 0xe1fb9b9c uart_cngrab(c137d69c,8889,e1fb9c20,c0ac7d43,c1128e43,...) at uart_cngrab+0x12/frame 0xe1fb9ba8 cngrab(c1128e43,1c,c112895a,144,c6d8b1a0,...) at cngrab+0x33/frame 0xe1fb9bb8 kern_reboot(4008,0,c112895a,c3,0,...) at kern_reboot+0x6d3/frame 0xe1fb9c20 sys_reboot(c6f0a310,e1fb9cc8,14,c112b5b7,7a2,...) at sys_reboot+0x6f/frame 0xe1fb9c40 syscall(e1fb9d08) at syscall+0x2de/frame 0xe1fb9cfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe1fb9cfc --- syscall (55, FreeBSD ELF32, sys_reboot), eip = 0x805a9df, esp = 0xbfbfd88c, ebp = 0xbfbfd960 --- KDB: enter: panic [ thread pid 1 tid 12 ] Stopped at kdb_enter+0x3d: movl$0,kdb_why db show locks exclusive sleep mutex Giant (Giant) r = 0 (0xc1724910) locked @ /usr/src/sys/vm/swap_pager.c:2365 db When I issued reset, the machine came back up normally (in slice 1 -- stable/9). I then rebooted to slice 4 (head), and issued the same commands I usually do to set the default boot slice back to 1, then shutdown -p now -- and re-created the panic. I can leave the machine up for a while if anyone has suggestions for me to poke around. I have a local private mirror of the FreeBSD SVN repos and a spare bootable slice; I'm williing to try patches. The machine isn't especially fast, but it's generally OK. If it would be worthwhile, I could reboot my laptop to slice 4 (head) attempt the same reset-to-slice-1-default power-off. This definitely did not happen @r260875, and it appears to be quite repeatable @r260904 You do not have option WITNESS_SKIPSPIN in your kernel config, do you ? My recent source upgrade from 10.0-RELEASE r260689 to 11.0-CURRENT r260850 left me with a GENERIC kernel with the following defined: options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed why? -Tom
Problem updating bootcode on ZFS on root system with MBR
I am running 11.0-CURRENT (r260850) with zfs on root with MBR. After upgrading my 10.0-RELEASE (r260669) system to 11.0-CURRENT (r260850) my zpools reported that they needed to be upgraded. So, I upgraded my zpools and I am attempting to update the bootcode (as required). I managed to get the boot1 stage code updated, but cannot get the boot2 stage code updated. Here is what I have done: # sysctl kern.geom.debugflags=0x10 kern.geom.debugflags: 0 - 16 # dd if=/boot/zfsboot of=/tmp/zfsboot1 count=1 1+0 records in 1+0 records out 512 bytes transferred in 0.014996 secs (34142 bytes/sec) # gpart bootcode -b /tmp/zfsboot1 /dev/ada0s1 bootcode written to ada0s1 # dd if=/boot/zfsboot of=/dev/ada0s1a skip=1 seek=1024 dd: /dev/ada0s1a: Operation not permitted The final dd statement fails with operation not permitted. In all my research, understood the initial sysctl command I ran would prevent this particular error from happening. What do I need to do to get the boot2 code written to /dev/ada0s1a? Thanks. -Tom ___ 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: FreeBSD 10.0-RC3 Now Available
All the examples I've seen for updating bootcode assume GPT. If one has MBR (as I do) and assuming the following basic scheme: gpart show ada0 = 63 976773105 ada0 MBR (466G) 63 976773105 1 freebsd [active] (466G) gpart show ada0s1 =0 976773105 ada0s1 BSD (466G) 0 943218736 1 freebsd-zfs (450G) 943218736 33554369 2 freebsd-swap (16G) would the equivalent bootcode statement be: gpart bootcode -b /boot/pmbr -p /boot/zfsboot ada0s1 where the boot code is /boot/zfsboot (rather than /boot/gptzfsboot) and ada0s1 is the slice on which FreeBSD is installed? Thanks. On Fri, Dec 27, 2013 at 9:33 AM, Mathieu Arnold m...@freebsd.org wrote: +--On 27 décembre 2013 12:26:49 +0100 Zenny garbytr...@gmail.com wrote: | On 12/27/13, Mathieu Arnold m...@freebsd.org wrote: | +--On 27 décembre 2013 00:42:36 +0100 Zenny garbytr...@gmail.com | wrote: | | Much awaited release, thanks!. However, does the freebsd-update from | | the earlier version bork in case of ZFS on Root? Or is there a safe | | way to upgrade without borking. I had a very bad experience when I | | upgraded from FreeBSD-10B3 to RC1. Thanks! | | I upgraded from 9.2 to 10.0-RC1, 10.0-RC2 and 10.0-RC3 with | freebsd-update using zfs only boxes, never had any problem. The only | thing is, if you run zpool upgrade, do remember to do what it tells you | about updating the bootcode. | | | In my case, I didn't receive any instructions to update the bootcode | and the bug was acknowledged by the developer. | | However, can you tell me exactly what did you do exactly to update the | bootcode? Appreciate it! Well, when you run : # zpool upgrade yourpool it will not print a lot of things, but it will end with : If you boot from pool 'yourpool', don't forget to update boot code. Assuming you use GPT partitioning and da0 is your boot disk the following command will do it: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 All you have to do is adapt it to run your particular setup, replacing da0 with the correct disk (and running it for each disk where your pool is, in my case, it was mfid0 and mfid1.) -- Mathieu Arnold ___ 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: FreeBSD 10.0-RC3 Now Available
After I posted, it occurred to me to check out the ../bsdinstall/scripts/zfsboot script to see how the boot code was laid down when the MBR was created. It shows only: dd if=/boot/zfsboot of=/dev/ada0s1 count =1 But, adding to my confusion, the FreeBSD wiki for ZFS on root (MBR-style) shows something very close to what Mathieu suggested. Unfortunately, I'm using an iMac with FreeBSD as the only OS. MBR is the only way I can get it to boot after an install. Looks like I've got some testing (and possible system restores) ahead of me. Thanks. On Fri, Dec 27, 2013 at 11:08 AM, Warren Block wbl...@wonkity.com wrote: On Fri, 27 Dec 2013, Mathieu Arnold wrote: +--On 27 décembre 2013 10:28:07 -0500 Thomas Hoffmann trh...@gmail.com wrote: | All the examples I've seen for updating bootcode assume GPT. If one has | MBR (as I do) and assuming the following basic scheme: | | gpart show ada0 | = 63 976773105 ada0 MBR (466G) | 63 976773105 1 freebsd [active] (466G) | | gpart show ada0s1 | =0 976773105 ada0s1 BSD (466G) | 0 943218736 1 freebsd-zfs (450G) | 943218736 33554369 2 freebsd-swap (16G) | | would the equivalent bootcode statement be: | | gpart bootcode -b /boot/pmbr -p /boot/zfsboot ada0s1 No, the PMBR is for GPT partitioning only. | where the boot code is /boot/zfsboot (rather than /boot/gptzfsboot) and | ada0s1 is the slice on which FreeBSD is installed? Hum, no, if you're using MBR and not GPT, you can't use gpart, Why not? gpart is not GPT-specific. It handles MBR and BSDlabel bootcode correctly. you have to do something aweful like this : # dd if=/boot/zfsboot of=/dev/ada0 count=1 That will overwrite the MBR partition table. # sysctl kern.geom.debugflags=0x10 # dd if=/boot/zfsboot of=/dev/ada0 skip=1 seek=1024 That seems dangerous. I have not tried with zfsboot, but this should be close: # gpart bootcode -b /boot/zfsboot ada0 # gpart bootcode -b /boot/zfsboot ada0s1 Untested! The first one may need to use /boot/mbr. A better way to do this, provided the system does not have a broken BIOS, would be to backup, repartition with GPT, and restore, avoiding the complication of multiple partitioning schemes. ___ 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: FreeBSD 10.0-RC3 Now Available
On Fri, Dec 27, 2013 at 12:15 PM, Scot Hetzel swhet...@gmail.com wrote: The correct way to install/update ZFS Boot code on an MBR disk is: Install boot Manager (required on first install) # gpart bootcode -b /boot/boot0 ad0 Note: /boot/mbr could also be used if you are not multibooting Install ZFS boot1 stage # sysctl kern.geom.debugflags=0x10 # dd if=/boot/zfsboot of=/dev/ada0s1 count=1 or # dd if=/boot/zfsboot of=/tmp/zfsboot1 count=1 # gpart bootcode -b /tmp/zfsboot1 /dev/ada0s1 Install ZFS boot2 stage # dd if=/boot/zfsboot of=/dev/ada0s1a skip=1 seek=1024 This ties everything together nicely for me, especially the part about the first bootcode install, which had me really confused. Thanks. ___ 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
