Re: Resume broken in 8.3-PRERELEASE
On Tue, Aug 28, 2012 at 09:07:51AM +0700, Alexey Dokuchaev wrote: On Mon, Aug 27, 2012 at 05:34:54PM +0200, Hans Petter Selasky wrote: If the USB HC is feeding too many such IRQ's it will be stuck. However, if you see that uhub_read_port_status() is called, the kernel is at least running, though it might be that some IRQ is stuck, hence the 100% CPU usage. Could you try to get some IRQ stats? Before zzz'ing: db show intrcnt irq1: atkbd0 168 irq9: acpi0 8300 irc12: psm0 2 irq14: ata0 6301 irq16: bge0 uhci3 13 irq23: uhci0 ehci02 cpu0: timer 7306385 irq256: hdac0 30 After (within a minute after botched resume) db show intrcnt irq1: atkbd0 479 irq9: cdpi0 8379 Was the output pasted verbatim ? I am curious about the irq9 name mangling in the second paste. irc12: psm0 2 irq14: ata0 6377 irq16: bge0 uhci3 26 irq23: uhci0 ehci05 cpu0: timer 7731880 irq256: hdac0 34 Not too much difference. Anything else I might get from DDB? Unfortunately, I am yet unable to save crashdump for later gdb analysis. ./danfe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org pgpC7oJin9wVZ.pgp Description: PGP signature
Re: Problem with link aggregation + sshd
Hi Giulio, Just to clear things up: igb0: 192.168.9.60/24 lagg0: 192.168.12.21/24 What's the IP of the host you're trying ssh connections from ? Also, just in case, did you enable any firewall ? (PF, ipfw) On 27 August 2012 21:22, Giulio Ferro au...@zirakzigil.org wrote: Hi, thanks for the answer Here is what you asked for: # ifconfig igb0 igb0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=4401bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO ether ... inet 192.168.9.60 netmask 0xff00 broadcast 192.168.9.255 inet6 prefixlen 64 scopeid 0x1 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active # netstat -rn Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default192.168.9.1UGS 00 igb0 127.0.0.1 link#12UH 00lo0 192.168.9.0/24 link#1 U 0 14 igb0 192.168.9.60 link#1 UHS 00lo0 192.168.12.0/24link#13U 0 109 lagg0 192.168.12.21 link#13UHS 00lo0 Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 ::1 link#12 UH lo0 :::0.0.0.0/96 ::1 UGRS lo0 fe80::/10 ::1 UGRS lo0 fe80::%igb0/64link#1Uigb0 fe80::ea39:35ff:feb6:a0d4%igb0link#1UHS lo0 fe80::%igb1/64link#2Uigb1 fe80::ea39:35ff:feb6:a0d5%igb1link#2UHS lo0 fe80::%igb2/64link#3Uigb2 fe80::ea39:35ff:feb6:a0d6%igb2link#3UHS lo0 fe80::%igb3/64link#4Uigb3 fe80::ea39:35ff:feb6:a0d7%igb3link#4UHS lo0 fe80::%lo0/64 link#12 U lo0 fe80::1%lo0 link#12 UHS lo0 fe80::%lagg0/64 link#13 U lagg0 fe80::ea39:35ff:feb6:a0d5%lagg0 link#13 UHS lo0 ff01::%igb0/32fe80::ea39:35ff:feb6:a0d4%igb0 U igb0 ff01::%igb1/32fe80::ea39:35ff:feb6:a0d5%igb1 U igb1 ff01::%igb2/32fe80::ea39:35ff:feb6:a0d6%igb2 U igb2 ff01::%igb3/32fe80::ea39:35ff:feb6:a0d7%igb3 U igb3 ff01::%lo0/32 ::1 U lo0 ff01::%lagg0/32 fe80::ea39:35ff:feb6:a0d5%lagg0 U lagg0 ff02::/16 ::1 UGRS lo0 ff02::%igb0/32fe80::ea39:35ff:feb6:a0d4%igb0 U igb0 ff02::%igb1/32fe80::ea39:35ff:feb6:a0d5%igb1 U igb1 ff02::%igb2/32fe80::ea39:35ff:feb6:a0d6%igb2 U igb2 ff02::%igb3/32fe80::ea39:35ff:feb6:a0d7%igb3 U igb3 ff02::%lo0/32 ::1 U lo0 ff02::%lagg0/32 fe80::ea39:35ff:feb6:a0d5%lagg0 U lagg0 # netstat -aln | grep 22 tcp40 0 *.22 *.* LISTEN tcp60 0 *.22 *.* LISTEN Note that I already tried to only listen on igb0 interface (192.168.9.60) in sshd_config, but the results are exactly the same described below. On 08/25/2012 01:22 PM, Damien Fleuriot wrote: In the meantime kindly post: Ifconfig for your igb0 Netstat -rn Netstat -aln | grep 22 On 25 Aug 2012, at 13:18, Damien Fleuriot m...@my.gd wrote: I'll get back to you regarding link aggregation when I'm done with groceries. We use it here in production and it works flawlessly. On 25 Aug 2012, at 09:54, Giulio Ferro au...@zirakzigil.org wrote: No answer, so it seems that link aggregation doesn't really work in freebsd, this may help others with the same problem... I reverted back to one link for management and one for service, and ssh works as it should... On 08/21/2012 11:18 PM, Giulio Ferro wrote: Scenario : freebsd 9 stable (yesterday) amd64 on HP server with 4 nic (igb) 1 nic is connected standalone to the management switch, the 3 other nics are connected to a switch configured for aggregation. If I configure the first nic (igb0) there is no problem, I can operate as I normally do and sshd functions normally. The problems start when I configure the 3 other nics for
Re: Problem with link aggregation + sshd
No answer, so it seems that link aggregation doesn't really work in freebsd, this may help others with the same problem... I used to use LCAP a lot - this was a few years ago, but the critical point was that it only worked if all the cables went to the same logcial switch. Using a pair of switches for redundancy works fine, as long as they are of the type which stacvk and look like a single physical switch software-wise. Saying it doesnt really work in freebsd is, to be honest, not so far off the mark (if somewhat harshly phrased) - but it can be made to behave if you do it in a certain way, and when it does it runs very nicely. Note that I havent tried it since 2008, so it maye have been improved since then, or had regressions, but I suggest trying it into a single switch and seeing what happens. cheers, -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
ipv6 connection hang
Hi all, mwi1# uname -a FreeBSD mwi1.coffeenet.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #5 r239731: Mon Aug 27 09:53:18 CDT 2012 r...@mwi1.coffeenet.org:/usr/obj/usr/src/sys/GENERIC amd64 My ipv6 connections hang for several seconds when this scrub rule is enabled: scrub all reassemble tcp no-df random-id This really agitates my browser and email client making them nearly useless at times. Disabling that rule makes ipv6 connections respond instantly as expected. Is this a known regression? My network interface is using the re(4) driver. Thanks! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 9.1-RC1 Available...
Jim Pingle li...@pingle.org writes: On 8/23/2012 11:43 AM, Ian Lepore wrote: On Thu, 2012-08-23 at 11:17 -0400, Ken Menzel wrote: I found two good primers: http://mebsd.com/configure-freebsd-servers/update-freebsd-source-tree-using-subversion-svn.html http://www.freebsd.org/doc/en/articles/committers-guide/article.html#SUBVERSION-PRIMER The second primer in the committer handbook seems to indicate that it is difficult to run an SVN mirror. This appears to me to be the biggest drawback. I have been using CVS and perforce for years, but subversion is new to me. It may be difficult to run an svn mirror that allows you to commit locally and get those changes back to the project, but running a read-only mirror is trivial. The script I run nightly from cron to sync my local mirror is: #!/bin/sh # # svnsync to pull in changes from FreeBSD to my local mirror. # svnsync sync file:///local/vc/svn/base I can't remember how I initially created and populated the mirror, but it's likely I grabbed a snapshot of the mirror at work and brought it home on a thumb drive (just to avoid initial network DL time). I spent a little time today setting up an SVN mirror after reading this thread and wrote up a how-to for those looking to do the same. http://www.pingle.org/2012/08/24/freebsd-svn-mirror Comments/Flames/Corrections welcome... thanx; works out of the box for me (using the svnserve_enable path). That said : I glanced at a diff of a stable/8 checkout both from /home/ncvs repo and new /home/freebsd-svn one, and saw a (maybe well-known ..) 'feature' : diff ./src/contrib/amd/include/am_defs.h /raid1/bsd/8/src/contrib/amd/include/am_defs.h 42c42 * $FreeBSD: stable/8/contrib/amd/include/am_defs.h 174299 2007-12-05 16:03:52Z obrien $ --- * $FreeBSD: src/contrib/amd/include/am_defs.h,v 1.15.2.1 2009/08/03 08:13:06 kensmith Exp $ I wondered why the date (and commiter ...) in the expansion were different (from the svn log ): r196045 | kensmith | 2009-08-03 10:13:06 +0200 (Mon, 03 Aug 2009) | 4 lines Copy head to stable/8 as part of 8.0 Release cycle. Approved by:re (Implicit) r174299 | obrien | 2007-12-05 17:03:52 +0100 (Wed, 05 Dec 2007) | 3 lines So the 'Copy head' chain does not update the $FreeBSD tag, whereas the consequent svn to cvs chain does. FYI, Arno Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: IPv6 default route. Can't see the wood for the trees.
On 8/27/2012 12:27 PM, Christian Laursen wrote: On 08/27/12 21:03, John Hawkes-Reed wrote: On 27/08/2012 19:06, Christian Laursen wrote: On 08/27/12 18:49, John Hawkes-Reed wrote: rc.conf: (I'm not convinced that obfuscating the addresses is worth the confusion) ipv6_gateway_enable=YES ip6addrctl_verbose=YES rtadvd_enable=YES rtadvd_interfaces=rl0 ipv6_cpe_wanif=pcn0 ipv6_defaultrouter=2001:470:1f0a:b5a::1 gif_interfaces=gif0 gifconfig_gif0=192.168.1.100 216.66.80.30 ifconfig_gif0_ipv6=inet6 2001:470:1f0a:b5a::2 2001:470:1f0a:b5a::1 prefixlen 128 ifconfig_pcn0_ipv6=inet6 2001:470:1f0b:b5a::4 prefixlen 64 ifconfig_rl0_ipv6=inet6 2001:470:1f0b:b5a::3 prefixlen 64 -accept_rtadv It looks like you are trying to use the /64 used for your tunnel on the inside network. That's probably what causes the problem. You should use the Routed /64 on the inside. If you need more than one /64, you can request a /48. I think I am. The endpoints are ...:1f0A: and the /64 is ...:1f0B: Sorry, my bad. Are pcn0 and rl0 both connected to internal networks? Having the same /64 configured on both is probably bad. Why would it be? -- You can't have the exact same prefix on two different interfaces, there's no way to decide where to route traffic going to that prefix if there's two equal routes in the routing table. -Kimmo ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Building the kernel and userland with llvm/clang
Hi I've been reading some information about building my system, FreeBSD Stable/9, using llvm/clang; the site I've been looking at is http://wiki.freebsd.org/BuildingFreeBSDWithClang. I was wondering about the benefits of doing so and also - and probably more importantly - if there are potential problems that might mean it's not worthwhile doing. Having read it again today there doesn't seem to be any likely problems I'd appreciate any thoughts or advice about this if possible. There's no particular reason I am thinking of doing this, I'm a student and so I just like to try things out and tinker with my system. Best Wishes, Jamie. smime.p7s Description: S/MIME cryptographic signature
IPv4 vs. IPv6 Ethernet Performance
Hi, I'm using here a Gigabit Ethernet network and some UN*X machines, among others some Linux-based (Kernel 3.x) and one running FreeBSD 9.1-RC1. Using iperf (in TCP mode), the IPv6 bandwith between two Linux machines (directly attached to the same switch) is about 925 Mbit/s, IPv4 bandwith is about 935 Mbit/s. But now it gets exciting: The IPv6 bandwith between a Linux machine and the FreeBSD machine is around 450 Mbit/s (each direction). But the IPv4 bandwith between the same machines is 700 (Linux - FreeBSD) to 920 (FreeBSD - Linux) Mbit/s. Little table (values in Mbit/s): Configuration v6 v4 === Linux - Linux 925 935 # = This could be v6's 40B header # vs. v4's 20B Linux - FreeBSD450 700 FreeBSD - Linux455 920 === The FreeBSD-Linux value shows that the ethernet chip on the FreeBSD machine (it's Intel stuff on both sides, using the em(4) driver on FreeBSD) is able to send at full 1G speed. But why is IPv6 so slow? Regards, Norbert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Building the kernel and userland with llvm/clang
On Tue, Aug 28, 2012 at 04:32:03PM +0100, Jamie Paul Griffin wrote: Hi I've been reading some information about building my system, FreeBSD Stable/9, using llvm/clang; the site I've been looking at is http://wiki.freebsd.org/BuildingFreeBSDWithClang. I was wondering about the benefits of doing so and also - and probably more importantly - if there are potential problems that might mean it's not worthwhile doing. Having read it again today there doesn't seem to be any likely problems I'd appreciate any thoughts or advice about this if possible. ... I have been doing this (on a daily basis) with both head stable/9 on my home build machine and my laptop since 12 Jul 2012; I have seen no problems or issues. (I build my ports under stable/8 have /usr/local in common across all 4 slices on each machine.) Here's what's in my /etc/src.conf for stable/9: CC=clang CXX=clang++ CPP=clang-cpp WITH_LIBCPLUSPLUS=yes When I update my production machines at home from stable/8 to stable/9 (probably shortly after 9.1 is released), they will (by necessity) also migrate to FreeBSD built with llvm/clang (as they get installed what the build machine builds). Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpd6x2QDT35U.pgp Description: PGP signature
Re: IPv4 vs. IPv6 Ethernet Performance
I'd guess it has to do with incomplete offload code for ipv6, but I'm sure you'll see bz chiming in with details. :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
cdrtools port installation failure
Anyone else not able to get cdrtools to install on a Stable System? I have just recently synced my source and rebuilt world, and kernel, then installed. Now while trying to install the livecd port, the cdrtools dependency is failing to install. The port compiles fine (at least it doesn't stop reporting an error), but dies on the installation portion reporting a missing file. install: /usr/ports/sysutils/cdrtools/work/cdrtools-3.00/cdda2wav/OBJ/amd64-freebsd-cc/cdda2wav: No such file or directory *** [do-install] Error code 71 There is a cdda2wav.d and cdda2wav.o file in the directory its searching, however when I run this on my FreeBSD 9.0-RELEASE-p4 system, there is also a cdda2wav file with no extension. ls /usr/ports/sysutils/cdrtools/work/cdrtools-3.00/cdda2wav/OBJ/amd64-freebsd-cc/ Dnull Inull aifc.d aifc.o aiff.d aiff.o base64.d base64.o cd_misc.d cd_misc.o cdda2wav.d cdda2wav.o config.cache config.log config.status interface.d interface.o ioctl.d ioctl.o lconfig.h local.cnf parse.d parse.o raw.d raw.o resample.d resample.o ringbuff.d ringbuff.o scsi_cdr.d scsi_cdr.o scsi_cmds.d scsi_cmds.o scsi_scan.d scsi_scan.o semshm.d semshm.o setuid.d setuid.o sndconfig.d sndconfig.o sun.d sun.o toc.d toc.o wav.d wav.o -- Thanks, Dean E. Weimer http://www.dweimer.net/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Building the kernel and userland with llvm/clang
[ David Wolfskill wrote on Tue 28.Aug'12 at 8:46:21 -0700 ] On Tue, Aug 28, 2012 at 04:32:03PM +0100, Jamie Paul Griffin wrote: Hi I've been reading some information about building my system, FreeBSD Stable/9, using llvm/clang; the site I've been looking at is http://wiki.freebsd.org/BuildingFreeBSDWithClang. I was wondering about the benefits of doing so and also - and probably more importantly - if there are potential problems that might mean it's not worthwhile doing. Having read it again today there doesn't seem to be any likely problems I'd appreciate any thoughts or advice about this if possible. ... I have been doing this (on a daily basis) with both head stable/9 on my home build machine and my laptop since 12 Jul 2012; I have seen no problems or issues. (I build my ports under stable/8 have /usr/local in common across all 4 slices on each machine.) Here's what's in my /etc/src.conf for stable/9: CC=clang CXX=clang++ CPP=clang-cpp WITH_LIBCPLUSPLUS=yes When I update my production machines at home from stable/8 to stable/9 (probably shortly after 9.1 is released), they will (by necessity) also migrate to FreeBSD built with llvm/clang (as they get installed what the build machine builds). Peace, david Thanks David, that's helpful information. I'll likely give it a go. So does clang create better binaries and libraries, in terms of performance and such-like? I'm currently reading as much as I can find about clang and its associated tools; however, compilers are quite complex software and learning about them is, for me at least, a lot to take in. Best wishes, Jamie. smime.p7s Description: S/MIME cryptographic signature
Re: Building the kernel and userland with llvm/clang
On Tue, Aug 28, 2012 at 05:53:15PM +0100, Jamie Paul Griffin wrote: ... Thanks David, that's helpful information. Good; that was the intent. :-) I'll likely give it a go. So does clang create better binaries and libraries, in terms of performance and such-like? I'm currently reading as much as I can find about clang and its associated tools; however, compilers are quite complex software and learning about them is, for me at least, a lot to take in. I don't know that it creates better code, but I believe that at least some of its error/warning checking may be a bit better: it certainly whines about a fair bit of GNUish code, citing (e.g.) Tautological compares ... and that sort of thing seems as if it's something I'd want to know about if it were my code, so I could fix it. From the time (a few weeks) when I was building stable/9 with both gcc clang (on different slices, sources updated to the same GRN), I got the impression that clang was slower (to compile) than gcc was. I note that I've had no issues at all with interoperation of executables libraries built with gcc clang. I consider this a Good Thing. :-) As I understand the issues, FreeBSD uses a (somewhat modified) version of the last GPLv2-licensed version of gcc, and there is strong incentive to avoid tainting FreeBSD with a GPLv3-licensed version of gcc. Thus, if we want to be able to move forward with our system compiler, we have little choice but to use something other than gcc. clang appears to work, so I plan to exercise it report issues if I encounter them. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgp8JUeNybkZL.pgp Description: PGP signature
Re: Building the kernel and userland with llvm/clang
On Tue, Aug 28, 2012 at 10:13 AM, David Wolfskill da...@catwhisker.orgwrote: On Tue, Aug 28, 2012 at 05:53:15PM +0100, Jamie Paul Griffin wrote: ... Thanks David, that's helpful information. Good; that was the intent. :-) I'll likely give it a go. So does clang create better binaries and libraries, in terms of performance and such-like? I'm currently reading as much as I can find about clang and its associated tools; however, compilers are quite complex software and learning about them is, for me at least, a lot to take in. I don't know that it creates better code, but I believe that at least some of its error/warning checking may be a bit better: it certainly whines about a fair bit of GNUish code, citing (e.g.) Tautological compares ... and that sort of thing seems as if it's something I'd want to know about if it were my code, so I could fix it. From the time (a few weeks) when I was building stable/9 with both gcc clang (on different slices, sources updated to the same GRN), I got the impression that clang was slower (to compile) than gcc was. I note that I've had no issues at all with interoperation of executables libraries built with gcc clang. I consider this a Good Thing. :-) As I understand the issues, FreeBSD uses a (somewhat modified) version of the last GPLv2-licensed version of gcc, and there is strong incentive to avoid tainting FreeBSD with a GPLv3-licensed version of gcc. Thus, if we want to be able to move forward with our system compiler, we have little choice but to use something other than gcc. clang appears to work, so I plan to exercise it report issues if I encounter them. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. With respect to messages from FreeBSD mailing lists , my understanding about GPL issue is as follows : The GPL v3 has severe restrictions about use of its licensed software , especially Libraries . Some commercial companies supporting FreeBSD are using FreeBSD in their proprietary products . The GPL v3 is forcing them to legally in a difficult position . Their rescue from this legal threat is to remove GPL parts from the FreeBSD . The reason of switching to a permissive licensed compiler such as clang/LLVM is that . And reason to stay GPL v2 gcc compiler is that . This gcc compiler blocking is NOT permitting to follow new processor developments . Thank you very much . Mehmet Erol Sanliturk ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Thinkpad X61s cannot boot 9.1-BETA1
On Monday, August 27, 2012 4:07:26 pm Per olof Ljungmark wrote: On 2012-08-27 19:54, John Baldwin wrote: On Sunday, August 26, 2012 6:59:22 pm Martin Dieringer wrote: On Sun, 26 Aug 2012, Per olof Ljungmark wrote: On 08/26/12 18:37, Kurt Jaeger wrote: Hi! On our X61s's setting 'debug.acpi.disabled=hostres' does not change the inability to boot 9-BETA1, 9-RC1 or -current. I tested 9.1-RC1 on X61, and it worked without any troubles. Yes, it does on this one too if I install a mechanical disk. The problem is related to installing on a SSD drive, Kingston SSDNow SV200S37A/128G. This must be related to a change in the base system some time between 9.0-RELEASE and -BETA1 as 9.0 runs and installs fine. Perhaps someone could suggest anther SSD drive with equal capacity that works? debug.acpi.disabled=hostres fixed it for me on T61 and T410 with normal HD and (older) SSD (OCZ Summit) FreeBSD 9.1-PRERELEASE #16: Tue Aug 21 Can you get a verbose dmesg both with and without the hostres setting? OK, will post tomorrow, a quick check with debug.acpi.disabled=hostres yields same output excluding the ata0: reset ... lines. I don't think the hostres bit is relevant to your case (where a different SSD fixed your issue). I think that is related to the ATA driver in some way. I am curious about Martin's case where he reports that hostres does make a difference however. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Building the kernel and userland with llvm/clang
[ David Wolfskill wrote on Tue 28.Aug'12 at 10:13:11 -0700 ] As I understand the issues, FreeBSD uses a (somewhat modified) version of the last GPLv2-licensed version of gcc, and there is strong incentive to avoid tainting FreeBSD with a GPLv3-licensed version of gcc. Thus, if we want to be able to move forward with our system compiler, we have little choice but to use something other than gcc. clang appears to work, so I plan to exercise it report issues if I encounter them. Yes we're thinking along similar lines then. I will do that as well and hopefully that will benefit the project to move forward as you say. Thanks again for your time. Jamie smime.p7s Description: S/MIME cryptographic signature
Re: FreeBSD 9.1-RC1 Available...
On Thu, Aug 23, 2012 at 6:50 AM, Ken Smith kensm...@buffalo.edu wrote: The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 9.0-RELEASE can upgrade as follows: # freebsd-update upgrade -r 9.1-RC1 This has not been working for me on i386 for the last few days. It fails with: [root@mist /usr/home/andrnils]# freebsd-update upgrade -r 9.1-RC1 Looking up update.FreeBSD.org mirrors... 3 mirrors found. Fetching public key from update4.FreeBSD.org... failed. Fetching public key from update5.FreeBSD.org... failed. Fetching public key from update3.FreeBSD.org... failed. No mirrors remaining, giving up. Best regards Andreas ... -- Ken Smith - From there to here, from here to | kensm...@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 9.1-RC1 Available...
On 28/08/2012, Arno J. Klaassen a...@heho.snv.jussieu.fr wrote: Jim Pingle li...@pingle.org writes: On 8/23/2012 11:43 AM, Ian Lepore wrote: On Thu, 2012-08-23 at 11:17 -0400, Ken Menzel wrote: I found two good primers: http://mebsd.com/configure-freebsd-servers/update-freebsd-source-tree-using-subversion-svn.html http://www.freebsd.org/doc/en/articles/committers-guide/article.html#SUBVERSION-PRIMER The second primer in the committer handbook seems to indicate that it is difficult to run an SVN mirror. This appears to me to be the biggest drawback. I have been using CVS and perforce for years, but subversion is new to me. It may be difficult to run an svn mirror that allows you to commit locally and get those changes back to the project, but running a read-only mirror is trivial. The script I run nightly from cron to sync my local mirror is: #!/bin/sh # # svnsync to pull in changes from FreeBSD to my local mirror. # svnsync sync file:///local/vc/svn/base I can't remember how I initially created and populated the mirror, but it's likely I grabbed a snapshot of the mirror at work and brought it home on a thumb drive (just to avoid initial network DL time). I spent a little time today setting up an SVN mirror after reading this thread and wrote up a how-to for those looking to do the same. http://www.pingle.org/2012/08/24/freebsd-svn-mirror Comments/Flames/Corrections welcome... thanx; works out of the box for me (using the svnserve_enable path). That said : I glanced at a diff of a stable/8 checkout both from /home/ncvs repo and new /home/freebsd-svn one, and saw a (maybe well-known ..) 'feature' : diff ./src/contrib/amd/include/am_defs.h /raid1/bsd/8/src/contrib/amd/include/am_defs.h 42c42 * $FreeBSD: stable/8/contrib/amd/include/am_defs.h 174299 2007-12-05 16:03:52Z obrien $ --- * $FreeBSD: src/contrib/amd/include/am_defs.h,v 1.15.2.1 2009/08/03 08:13:06 kensmith Exp $ I wondered why the date (and commiter ...) in the expansion were different (from the svn log ): r196045 | kensmith | 2009-08-03 10:13:06 +0200 (Mon, 03 Aug 2009) | 4 lines Copy head to stable/8 as part of 8.0 Release cycle. Approved by:re (Implicit) r174299 | obrien | 2007-12-05 17:03:52 +0100 (Wed, 05 Dec 2007) | 3 lines So the 'Copy head' chain does not update the $FreeBSD tag, whereas the consequent svn to cvs chain does. That's because CVS does not consider tagging/branching a commit, whereas Subversion does. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Question About Tracking the Stable Branch
Hi I am following 9 Stable. I have read the handbook information and I am now subscribed to this list and the svn-src-stable-9@ list. Even after reading the handbook, what i'm not clear about is this: I see individual commits being submitted to the source tree; do I: - patch and update each individual commit, or; - rebuild world say once every couple of days or even each day to incorporate the changes, and; - does the kernel need to be rebuilt and reinstalled each time if using the first option. Obviously I would have to if rebuilding world (the second option). Am I right in thinking that it also depends on the type of change; i.e. if the change is to a kernel and/or a kernel module then clearly I need to rebuild the kernel. But, then would I need to rebuild the userland as well? I hope I am making sense and not asking dumb questions, I just want to be clear about the process. Essentially, I want to know if it's necessary to rebuild the entire userland and kernel sources just to incorporate a small number of changes. Obviously that's a lot of time compiling. Or, do I just patch the commited files and rebuild that bit of the sourse tree and the kernel if necessary due to the type of change made. I've not followed a FreeBSD stable branch before so just wanted to clarify those points. I'd like to be involved with testing things for the project, etc. Best wishes, Jamie. smime.p7s Description: S/MIME cryptographic signature
Re: FreeBSD 9.1-RC1 Available...
On 8/25/2012 4:33 AM, Harald Schmalzbauer wrote: But my real problem is that svn is not in the base system. And for example installing subversion package on my cvsup mirror failed because pkg-config-0-25_1 was installed and sqlite, a dependency of subversion, wants to install pkgconf-0.8.5. So I'm hit by the henn-egg problem. This is because pkg-config was removed and moved from devel/pkg-config to devel/pkgconf. To update or install any port, you'll need to deinstall pkg-config and install pkgconf. There is an associated UPDATING entry: 20120726: AFFECTS: users of devel/pkg-config AUTHOR: b...@freebsd.org devel/pkg-config has been replaced by devel/pkgconf # portmaster -o devel/pkgconf devel/pkg-config or # portupgrade -fo devel/pkgconf pkg-config-\* pkgng: # pkg set -o devel/pkg-config:devel/pkgconf # pkg install -f devel/pkgconf Bryan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: cdrtools port installation failure
On Tue, Aug 28, 2012 at 8:46 AM, dweimer dwei...@dweimer.net wrote: Anyone else not able to get cdrtools to install on a Stable System? I have just recently synced my source and rebuilt world, and kernel, then installed. Now while trying to install the livecd port, the cdrtools dependency is failing to install. The port compiles fine (at least it doesn't stop reporting an error), but dies on the installation portion reporting a missing file. install: /usr/ports/sysutils/cdrtools/work/cdrtools-3.00/cdda2wav/OBJ/amd64-freebsd-cc/cdda2wav: No such file or directory *** [do-install] Error code 71 There is a cdda2wav.d and cdda2wav.o file in the directory its searching, however when I run this on my FreeBSD 9.0-RELEASE-p4 system, there is also a cdda2wav file with no extension. ls /usr/ports/sysutils/cdrtools/work/cdrtools-3.00/cdda2wav/OBJ/amd64-freebsd-cc/ Dnull Inull aifc.d aifc.o aiff.d aiff.o base64.d base64.o cd_misc.d cd_misc.o cdda2wav.d cdda2wav.o config.cache config.log config.status interface.d interface.o ioctl.d ioctl.o lconfig.h local.cnf parse.d parse.o raw.d raw.o resample.d resample.o ringbuff.d ringbuff.o scsi_cdr.d scsi_cdr.o scsi_cmds.d scsi_cmds.o scsi_scan.d scsi_scan.o semshm.d semshm.o setuid.d setuid.o sndconfig.d sndconfig.o sun.d sun.o toc.d toc.o wav.d wav.o -- Thanks, Dean E. Weimer http://www.dweimer.net/ How odd! I can't replicate this at all. I just made cdrtools-3.00_2 and I have: cc -o OBJ/amd64-freebsd-cc/cdda2wav OBJ/amd64-freebsd-cc/cdda2wav.o OBJ/amd64-freebsd-cc/interface.o OBJ/amd64-freebsd-cc/semshm.o OBJ/amd64-freebsd-cc/resample.o OBJ/amd64-freebsd-cc/scsi_scan.o OBJ/amd64-freebsd-cc/toc.o OBJ/amd64-freebsd-cc/wav.o OBJ/amd64-freebsd-cc/sun.o OBJ/amd64-freebsd-cc/raw.o OBJ/amd64-freebsd-cc/setuid.o OBJ/amd64-freebsd-cc/ringbuff.o OBJ/amd64-freebsd-cc/sndconfig.o OBJ/amd64-freebsd-cc/scsi_cmds.o OBJ/amd64-freebsd-cc/aiff.o OBJ/amd64-freebsd-cc/aifc.o OBJ/amd64-freebsd-cc/scsi_cdr.o OBJ/amd64-freebsd-cc/cd_misc.o OBJ/amd64-freebsd-cc/ioctl.o OBJ/amd64-freebsd-cc/base64.o OBJ/amd64-freebsd-cc/parse.o -L../libs/amd64-freebsd-cc -L../libs/amd64-freebsd-cc -L/usr/local/lib -L/usr/local/lib -lscgcmd -lrscg -lscg -lparanoia -lcdrdeflt -ldeflt -lmdigest -lschily -lcam And, as I expected, I find it: # find work/cdrtools-3.00/ -name cdda2wav work/cdrtools-3.00/cdda2wav work/cdrtools-3.00/cdda2wav/OBJ/amd64-freebsd-cc/cdda2wav Look trough the log of your make and see if anything odd happened in that step. It should be at the end of the section : == MAKING DIRECTORY OBJ/amd64-freebsd-cc/Inull == CONFIGURING LOCAL RULES OBJ/amd64-freebsd-cc/local.cnf and just before: == MAKING all ON SUBDIRECTORY SRCROOT/cdrecord This was on a stable system updated on Aug. 16. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Question About Tracking the Stable Branch
On Tue, Aug 28, 2012 at 09:31:30PM +0100, Jamie Paul Griffin wrote:
Hi
I am following 9 Stable. I have read the handbook information and I am now
subscribed to this list and the svn-src-stable-9@ list.
Even after reading the handbook, what i'm not clear about is this:
I see individual commits being submitted to the source tree; do I:
- patch and update each individual commit, or;
- rebuild world say once every couple of days or even each day to
incorporate the changes, and;
- does the kernel need to be rebuilt and reinstalled each time if using
the first option. Obviously I would have to if rebuilding world (the second
option).
...
Errmmm... Well, here's what I do (briefly):
* I maintain /usr/src as an SVN working copy -- that is, I created it
by (the logical equivalent of):
* # cd /usr rm -fr src mkdir src chown david src
* $ cd /usr/src svn co ${repo}/stable/9 .
(where $repo is a URL for the SVN repo used).
Periodically (daily, in my case), after the repo that I use has been
updated, I issue:
* $ svn update /usr/src
and if there were updates, I rebuild.
If the only updates are to the kernel sources, I often only rebuild the
kernel. If any updates were not for the kernel, I rebuild both userland
and kernel.
See /usr/src/UPDATING; look for the string COMMON ITEMS (about 87% of
the way into the file). I use the To rebuild everything and install it
on the current system. with the variation that I usually specify
-DNOCLEAN, and I haven't actually needed to perform the reboot in
single user step in longer than I can remember.
I do all builds within a script(1) invocation (so I have a record), and
usually within screen(1), as well (just in case Something Weird
happens). I also usually specify a -j value, in order to take advantage
of multiple cores.
I hope that helps a bit.
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
pgp6bHA7qRJu5.pgp
Description: PGP signature
Re: Question About Tracking the Stable Branch
On Tue, Aug 28, 2012 at 1:31 PM, Jamie Paul Griffin ja...@kode5.net wrote: I am following 9 Stable. I have read the handbook information and I am now subscribed to this list and the svn-src-stable-9@ list. Even after reading the handbook, what i'm not clear about is this: I see individual commits being submitted to the source tree; do I: - patch and update each individual commit, or; - rebuild world say once every couple of days or even each day to incorporate the changes, and; - does the kernel need to be rebuilt and reinstalled each time if using the first option. Obviously I would have to if rebuilding world (the second option). Personally, I don't update -STABLE boxes unless a specific change that's useful for my setups comes through. And then I'll usually wait 1-2 days after the specific commit hits the tree in case there's a last-minute fix to that commit. If there's nothing I want to test, or that I need, though, I don't update. So, it all depends on your needs: - are you tracking -STABLE to do development? - are you tracking -STABLE to get updated drivers? - are you tracking -STABLE to get specific functionality? - are you tracking -STABLE to help with bug finding/fixing? - etc ... What your needs are will dictate how often you update the source tree, rebuild the world, and run with the latest bits. Am I right in thinking that it also depends on the type of change; i.e. if the change is to a kernel and/or a kernel module then clearly I need to rebuild the kernel. But, then would I need to rebuild the userland as well? Most commit logs will include information on whether it's kernel-only, userland-only, 1-module only, kernel+userland, multiple modules, etc. Depending on the speed of your machine, you can do a full buildworld cycle for every update. Or limit it to just the kernel/userland component that's updated. -- Freddie Cash fjwc...@gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Question About Tracking the Stable Branch
On Tue, Aug 28, 2012 at 1:31 PM, Jamie Paul Griffin ja...@kode5.net wrote:
Hi
I am following 9 Stable. I have read the handbook information and I am now
subscribed to this list and the svn-src-stable-9@ list.
Even after reading the handbook, what i'm not clear about is this:
I see individual commits being submitted to the source tree; do I:
- patch and update each individual commit, or;
- rebuild world say once every couple of days or even each day to
incorporate the changes, and;
- does the kernel need to be rebuilt and reinstalled each time if
using the first option. Obviously I would have to if rebuilding world (the
second option).
Am I right in thinking that it also depends on the type of change; i.e. if
the change is to a kernel and/or a kernel module then clearly I need to
rebuild the kernel. But, then would I need to rebuild the userland as well?
I hope I am making sense and not asking dumb questions, I just want to be
clear about the process.
Essentially, I want to know if it's necessary to rebuild the entire userland
and kernel sources just to incorporate a small number of changes. Obviously
that's a lot of time compiling. Or, do I just patch the commited files and
rebuild that bit of the sourse tree and the kernel if necessary due to the
type of change made.
I've not followed a FreeBSD stable branch before so just wanted to clarify
those points. I'd like to be involved with testing things for the project,
etc.
Most people DON'T try to update for every commit. Many will rebuild on
a daily basis. Many weekly or monthly. Some only when they see a need
(such as a fix for a problem they are experiencing) or just get around
to it. How you choose to do do it is entirely up to you.
Manually applying updates and just rebuilding things that use that
change is certainly possible, but requires careful insight as to what
a given patch will impact. Does it result in a new library that my, in
turn, require the rebuild of code that uses it? Kernel patches can be
integrated but it is far easier to just update modules if the patch is
to a part of the kernel that can be loaded as a module.
In all cases, if you rebuild the kernel, be sure that the old kernel
is saved to kernel.old so you can go back to it if there si a problem.
'make installkernel' does this) and, should you fix a problem and
re-link the kernel, be sure NOT to overwrite the working kernel ('make
reinstallkernel' does this.
Also, many kernel changes impact the KBI, so some userland tools that
use kernel structures (e.g. top) my fail after a kernel update that is
not accompanied by a userland rebuild.
In general, I update stable about once a month. I use 'svn up' to
update my source tree and then follow the standard instructions:
cd /usr/src
rm -rf /usr/obj/*
make -j6 -DNO_CLEAN buildworld
mergemaster -p (usually a no-op)
make -j6 buildkernel
make installkernel
shutdown -r now (to single user mode)
fsck -p
adjkerntz -i (if the hardware clock is not running UTC)
swapon -a
mount -a -t ufs
cd /usr/src/
make installworld
mergemaster -iPF (Use -U at your own risk. It saves time, but you
might miss something on rare occasion.)
make check-old
rm -rf any deleted directories (saves time)
make delete-old
reboot
--
R. Kevin Oberman, Network Engineer
E-mail: kob6...@gmail.com
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Question About Tracking the Stable Branch
On Tue, Aug 28, 2012 at 2:03 PM, Kevin Oberman kob6...@gmail.com wrote:
In all cases, if you rebuild the kernel, be sure that the old kernel
is saved to kernel.old so you can go back to it if there si a problem.
'make installkernel' does this) and, should you fix a problem and
re-link the kernel, be sure NOT to overwrite the working kernel ('make
reinstallkernel' does this.
It's not mentioned often on the lists, but KODIR and nextboot(8) are
wonderful things:
# make whatever options buildworld
# make KERNCONF=MYKERNEL whatever other options buildkernel
# make KERNCONF=MYKERNEL KODIR=/boot/MYKERNEL whatever other
options installkernel
# nextboot -k MYKERNEL
# shutdown -r now
That will install your new kernel into /boot/MYKERNEL, leaving
/boot/kernel alone. nextboot configures the boot process to use
/boot/MYKERNEL, again leaving /boot/kernel along. If anything goes
wrong, a simple reboot of the box returns you to using /boot/kernel as
before.
If the new kernel works correctly, then you can manually copy/moves
things around as needed:
# mv /boot/kernel /boot/kernel.old
# cp -Rvp /boot/MYKERNEL /boot/kernel
Especially useful when testing new kernels on remote systems, as hit
the reset switch on a locked up box puts things back to the way they
were before. No loader commands required. :)
--
Freddie Cash
fjwc...@gmail.com
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown
On 2012-08-27 21:35, Warren Block wrote: On Mon, 27 Aug 2012, Matt Smith wrote: Thank you for your help anyway, and your wonkity site, which I also once used for converting my procmail to maildrop. And thanks also to Erich and Stefan for your help. When I get some spare time I'll redo the filesystem and hope that it works. Please post a followup after that. Here is the followup! I have just rebuilt the server from scratch using a 9.1-RC1 amd64 memstick image. Used the GPT labels directly in the fstab and ignored glabel. And guess what? It works fine as you probably expected. So it was definitely user error and the glabel broke it. At least I've learnt a lot more about partitioning and filesystems than I knew before anyway! So once again, thank you for all your help. There is an open PR for this that I raised which is amd64/170646 , I don't think there is any way for me to close this myself is there? If somebody reads this who has the rights to do so then please close it with user is an idiot :) Matt. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [Solved, I think] IPv6 default route. Can't see the wood for the trees.
On 28/08/2012 02:23, Mark Andrews wrote: In message 503bcb0a.6000...@freebsd.org, Doug Barton writes: On 8/27/2012 12:27 PM, Christian Laursen wrote: On 08/27/12 21:03, John Hawkes-Reed wrote: On 27/08/2012 19:06, Christian Laursen wrote: On 08/27/12 18:49, John Hawkes-Reed wrote: rc.conf: (I'm not convinced that obfuscating the addresses is worth the confusion) ipv6_gateway_enable=YES ip6addrctl_verbose=YES rtadvd_enable=YES rtadvd_interfaces=rl0 ipv6_cpe_wanif=pcn0 ipv6_defaultrouter=2001:470:1f0a:b5a::1 gif_interfaces=gif0 gifconfig_gif0=192.168.1.100 216.66.80.30 ifconfig_gif0_ipv6=inet6 2001:470:1f0a:b5a::2 2001:470:1f0a:b5a::1 prefixlen 128 ifconfig_pcn0_ipv6=inet6 2001:470:1f0b:b5a::4 prefixlen 64 ifconfig_rl0_ipv6=inet6 2001:470:1f0b:b5a::3 prefixlen 64 -accept_rtadv It looks like you are trying to use the /64 used for your tunnel on the inside network. That's probably what causes the problem. You should use the Routed /64 on the inside. If you need more than one /64, you can request a /48. I think I am. The endpoints are ...:1f0A: and the /64 is ...:1f0B: Sorry, my bad. Are pcn0 and rl0 both connected to internal networks? Having the same /64 configured on both is probably bad. Why would it be? Unless you bridge the two interface, yes. Which interface do you start ND on? For the OP, here is my ipv6 configuration. tx0 is the internal net and is running with ULA as well as the /64 from HE. sis0 is the external cable connection. gif0 is the tunneled connection back to HE. sft0 sends 6to4 reply traffic directly it is out bound only. % ifconfig -a inet6 tx0: flags=28943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 inet6 fe80::2e0:29ff:fe19:c02d%tx0 prefixlen 64 scopeid 0x1 inet6 2001:470:1f00:820:2e0:29ff:fe19:c02d prefixlen 64 inet6 2001:470:1f00:820:: prefixlen 64 anycast inet6 fd92:7065:b8e:0:2e0:29ff:fe19:c02d prefixlen 64 inet6 fd92:7065:b8e:: prefixlen 64 anycast sis0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet6 fe80::209:5bff:fe1e:e13e%sis0 prefixlen 64 scopeid 0x2 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 gif0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1280 tunnel inet 211.30.172.21 -- 64.71.128.82 inet6 fe80::2e0:29ff:fe19:c02d%gif0 prefixlen 64 scopeid 0x8 inet6 2001:470:1f00:::5a1 -- 2001:470:1f00:::5a0 prefixlen 128 stf0: flags=1001UP,LINK0 mtu 1280 inet6 2002:d31e:ac15:: prefixlen 16 anycast Not hand-configuring the external i/f seems to be the fix. In that I have spent a cheerful few hours chopping stuff from rc.conf and rebooting, and that appeared to toggle the failure. Thank you all for your patience. -- JH-R ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Question About Tracking the Stable Branch
[ Freddie Cash wrote on Tue 28.Aug'12 at 14:12:10 -0700 ]
On Tue, Aug 28, 2012 at 2:03 PM, Kevin Oberman kob6...@gmail.com wrote:
In all cases, if you rebuild the kernel, be sure that the old kernel
is saved to kernel.old so you can go back to it if there si a problem.
'make installkernel' does this) and, should you fix a problem and
re-link the kernel, be sure NOT to overwrite the working kernel ('make
reinstallkernel' does this.
It's not mentioned often on the lists, but KODIR and nextboot(8) are
wonderful things:
# make whatever options buildworld
# make KERNCONF=MYKERNEL whatever other options buildkernel
# make KERNCONF=MYKERNEL KODIR=/boot/MYKERNEL whatever other
options installkernel
# nextboot -k MYKERNEL
# shutdown -r now
That will install your new kernel into /boot/MYKERNEL, leaving
/boot/kernel alone. nextboot configures the boot process to use
/boot/MYKERNEL, again leaving /boot/kernel along. If anything goes
wrong, a simple reboot of the box returns you to using /boot/kernel as
before.
If the new kernel works correctly, then you can manually copy/moves
things around as needed:
# mv /boot/kernel /boot/kernel.old
# cp -Rvp /boot/MYKERNEL /boot/kernel
Especially useful when testing new kernels on remote systems, as hit
the reset switch on a locked up box puts things back to the way they
were before. No loader commands required. :)
OK, thanks for each response, some really useful info for me.
I've always updated my -RELEASE systems using the traditional method so it
seems it's no different other than perhaps updating more frequently and
deciding whether or not both kernel code and userland code needs to be rebuilt
together.
It certainly seems a bad idea for me as someone with a lot to learn, to patch
specific parts of the source tree and rebuild those parts as something is bound
to go wrong at some point for me.
I want to be able to test the new code and report issues to help in that way
with a view to adding code fixes to the project.
Jamie.
smime.p7s
Description: S/MIME cryptographic signature
Re: Question About Tracking the Stable Branch
On Tue, 28 Aug 2012, Jamie Paul Griffin wrote: I've always updated my -RELEASE systems using the traditional method so it seems it's no different other than perhaps updating more frequently and deciding whether or not both kernel code and userland code needs to be rebuilt together. It certainly seems a bad idea for me as someone with a lot to learn, to patch specific parts of the source tree and rebuild those parts as something is bound to go wrong at some point for me. In addition to what others have suggested, the devel/ccache port can seriously reduce world and kernel compilation time by caching results. Stuff that hasn't changed comes out of cache rather than from a recompile. A buildworld every few days usually takes only about a fourth of the time it would take without ccache. Unfortunately, so far it only has this extreme an effect with gcc, not so much with clang. I usually use 4G of cache space; haven't tested to see how much is actually needed. Setting CCACHE_COMPRESS=yes fits more files in the cache. In my tests, there was no speed penalty. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Question About Tracking the Stable Branch
[ Warren Block wrote on Tue 28.Aug'12 at 17:28:15 -0600 ] On Tue, 28 Aug 2012, Jamie Paul Griffin wrote: I've always updated my -RELEASE systems using the traditional method so it seems it's no different other than perhaps updating more frequently and deciding whether or not both kernel code and userland code needs to be rebuilt together. It certainly seems a bad idea for me as someone with a lot to learn, to patch specific parts of the source tree and rebuild those parts as something is bound to go wrong at some point for me. In addition to what others have suggested, the devel/ccache port can seriously reduce world and kernel compilation time by caching results. Stuff that hasn't changed comes out of cache rather than from a recompile. A buildworld every few days usually takes only about a fourth of the time it would take without ccache. Unfortunately, so far it only has this extreme an effect with gcc, not so much with clang. I usually use 4G of cache space; haven't tested to see how much is actually needed. Setting CCACHE_COMPRESS=yes fits more files in the cache. In my tests, there was no speed penalty. Great suggestion, I'll look into that. Although, I am planning a rebuild using clang in the next few days but from what you say it could still be a useful addition. Jamie ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
