Re: cardbus panic: end address is not aligned
On 07/03/2011 03:05, Adrian Chadd wrote: The obvious question - can you bisect kernel versions to find out when it broke? Sorry, I thought the answer to that was obvious from my message. I have no idea how far back the breakage goes since I don't use the cards often. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: My problems with stability on -current
On 05/11/2011 04:33, Alexander Motin wrote:
On 11.05.2011 08:17, Doug Barton wrote:
I had an interesting result doing nothing but switching from HPET to
LAPIC ... no crash. Still on the same version of -current (r221566) the
only thing I've done is to add kern.eventtimer.timer=LAPIC to
/boot/loader.conf, and so far I haven't been able to get it to crash no
matter how much I compile, or how much other stuff I do in the
background. I _can_ get the system heavily loaded enough so that the
mouse can drag across the screen, windows take visible time to repaint,
etc. That happens with a load average of 4+ on this core 2 duo. But
other than that (which is not altogether unreasonable) the system has
been very stable for a couple of days now.
Does that suggest a next step in terms of what to test?
The fact that LAPIC is working fine can mean that problem is either HPET
specific or non-per-CPU timers specific. To check that you could try to
use i8254 timer in one-shot mode:
hint.attimer.0.timecounter=0
kern.eventtimer.timer=i8254
, or use HPET in per-CPU mode:
hint.atrtc.0.clock=0
hint.attimer.0.clock=0
hint.hpet.X.legacy_route=1
But the most informative would be to see what's going on with HPET
interrupts during the freezes. With HPET hardware it is very easy to
loose interrupt. And the lost interrupt means problem for many things.
There are some workarounds made for that, but I can't be sure. For that
case you could experiment with this patch:
--- acpi_hpet.c.prev 2010-12-25 11:28:45.0 +0200
+++ acpi_hpet.c 2011-05-11 14:30:59.0 +0300
@@ -190,7 +190,7 @@ restart:
bus_write_4(sc-mem_res, HPET_TIMER_COMPARATOR(t-num),
t-next);
}
- if (fdiv 5000) {
+ if (1 || fdiv 5000) {
bus_read_4(sc-mem_res, HPET_TIMER_COMPARATOR(t-num));
now = bus_read_4(sc-mem_res, HPET_MAIN_COUNTER);
FYI, I have been running this patch since you sent it, and haven't
crashed under high load since.
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: named crashes on assertion in rbtdb.c o? sparc64/SMP
On 06/28/2011 08:58, Marius Strobl wrote: Uhm, we once fixed a problem in the MD atomic implementation which still seems to present in the ISC copy. Could you please test whether the following patch makes a difference? http://people.freebsd.org/~marius/sparc64_isc_atomic.h.diff I haven't seen any verification from the OP that this patch solved the problem, however it did pass 'make universe' on both 9-current and RELENG_8, so I've committed it to those 2 branches along with the recent update. I'll also submit it upstream. Thanks, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cardbus panic: end address is not aligned
On 07/07/2011 14:20, John Baldwin wrote:
On Sunday, July 03, 2011 1:39:18 am Doug Barton wrote:
I have 2 ath-based pc-card adapters. If I put either one of them in the
slot while the system is up, or if I try booting with them in the slot,
I get an instant panic. The cards previously worked in -current, and
continue to work in 8-stable and windows xp. I don't have any other
pc-cards to compare with. Full core.txt.0 file is in my home directory
on freefall.
This problem persists on r223732 but happened to me for the first time a
week or 2 ago (haven't had time to report it previously, apologies). It
likely originated a while before though, I don't use these cards very
often.
panic: end address is not aligned
#1 0x80426a8a in kern_reboot (howto=260)
at /home/svn/head/sys/kern/kern_shutdown.c:430
#2 0x80426521 in panic (fmt=Variable fmt is not available.
)
at /home/svn/head/sys/kern/kern_shutdown.c:604
#3 0x8032c648 in pcib_grow_window (sc=0xfe0002603400,
w=0xfe0002603498, type=3, start=0, end=4294967295, count=65536,
flags=Variable flags is not available.
The line is here:
KASSERT((w-limit ((1ul w-step) - 1)) == (1ul w-step) - 1,
(end address is not aligned));
Can you run kgdb and do 'frame 3' and 'p/x *w'?
(kgdb) frame 3
#3 0x8032c648 in pcib_grow_window (sc=0xfe0002603400,
w=0xfe0002603498, type=3, start=0, end=4294967295, count=65536,
flags=Variable flags is not available.
)
at /home/svn/head/sys/dev/pci/pci_pci.c:1018
1018KASSERT((w-limit ((1ul w-step) - 1)) == (1ul w-step)
- 1,
(kgdb) p/x *w
$1 = {base = 0x8000, limit = 0x8800, rman = {rm_list = {
tqh_first = 0xfe0002702a00, tqh_last = 0xfe0002702a98},
rm_mtx = 0xfe00024e20e0, rm_link = {tqe_next = 0xfe0002603520,
tqe_prev = 0xfe0002603448}, rm_start = 0x0, rm_end = 0x,
rm_type = 0x2, rm_descr = 0xfe0002608060}, res =
0xfe0002702b00,
reg = 0x20, valid = 0x1, mask = 0x2, step = 0x14, name =
0x8071b77c}
Also, can you boot your machine, then do 'sysctl debug.bootverbose=1', insert
the card and record the messages in dmesg when it does? (You can likely get
those out of kgdb.)
The system panics instantly when I insert the cards. Would a verbose
dmesg entry from 8.2-stable work? I can do that on the same hardware.
If not I can try it on -current and see if anything gets logged.
Thanks for taking a look!
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cardbus panic: end address is not aligned
On 07/08/2011 06:19, John Baldwin wrote: Hmm, well that's odd. It didn't grow it enough it seems. Also, can you boot your machine, then do 'sysctl debug.bootverbose=1', insert the card and record the messages in dmesg when it does? (You can likely get those out of kgdb.) I tried your patch, and got some odd results. The good news is, no crash. However it did not actually enable the cards, with or without if_ath being loaded before inserting them. Here is the dmesg output with debug.bootverbose=1. This is with inserting and removing first one card, then the other. pcib5: attempting to grow memory window for (0x8800-0x,0x1) back candidate range: 0x8800-0x8800 pcib5: grew memory window to 0x8000-0x880f pcib5: allocated memory range (0x8800-0x8800) for rid 10 of pci0:4:0:0 found- vendor=0x168c, dev=0x0023, revid=0x01 domain=0, bus=4, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=18 cardbus0: network at device 0.0 (no driver attached) map[10]: type Memory, range 32, base 0, size 16, memory disabled pcib5: allocated memory range (0x8800-0x8800) for rid 10 of pci0:4:0:0 found- vendor=0x168c, dev=0x0023, revid=0x01 domain=0, bus=4, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=18 cardbus0: network at device 0.0 (no driver attached) pcib5: allocated memory range (0x8800-0x8800) for rid 10 of pci0:4:0:0 unknown: Lazy allocation of 0x1 bytes rid 0x10 type 3 at 0x8800 cbb0: Opening memory: cbb0: Normal: 0x8800-0x8800 cbb0: Opening memory: cbb0: Opening memory: cbb0: Normal: 0x8800-0x8800 cbb0: Opening memory: found- vendor=0x168c, dev=0x0013, revid=0x01 domain=0, bus=4, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0002, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0a (2500 ns), maxlat=0x1c (7000 ns) intpin=a, irq=18 powerspec 2 supports D0 D3 current D0 cardbus0: network, ethernet at device 0.0 (no driver attached) pci0:4:0:0: Transition from D0 to D3 The real messages I will want to see are in the dmesg. Also, getting the output of 'devinfo -r' before you insert the card would also be helpful so I can see what it is growing from. Attached. Thanks for looking into this, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ nexus0 apic0 ram0 I/O memory addresses: 0x0-0x9efff 0x10-0x7fe813ff acpi0 Interrupt request lines: 9 I/O ports: 0x20-0x21 0x2e-0x2f 0x4e-0x4f 0x86 0x92 0xa0-0xa1 0xb2 0xb3 0x4d0-0x4d1 0x809 0x910-0x91f 0x920-0x92f 0x930-0x97f 0xc80-0xcaf 0xcbc-0xcbf 0xcc0-0xcff 0x1000-0x1005 0x1006-0x1007 0x1008-0x1059 0x1060-0x107f 0x1080-0x10bf 0x10c0-0x10df 0xf400-0xf4fe I/O memory addresses: 0x9fc00-0x9 0xc-0xc 0xe-0xf 0x7fe81400-0x7fef 0x7ff0-0x7fff 0xf000-0xf3ff 0xf400-0xf4003fff 0xf4004000-0xf4004fff 0xf4005000-0xf4005fff 0xf4006000-0xf4006fff 0xf4008000-0xf400bfff 0xfec0-0xfec0 0xfed2-0xfed3 0xfed45000-0xfed9 0xfee0-0xfee0 0xffa8-0xffa83fff 0xffb0-0x cpu0 ACPI I/O ports: 0x1014 0x1016 est0 acpi_perf0 cpufreq0 coretemp0 cpu1 ACPI I/O ports: 0x1014 0x1016 est1 acpi_perf1 cpufreq1 coretemp1 acpi_acad0 battery0 battery1 acpi_lid0 acpi_button0 acpi_button1 acpi_sysresource0 pcib0 pci0 hostb0 pcib1 I/O memory addresses: 0xd000-0xdfff 0xed00-0xefef pci1 vgapci0 Interrupt request lines: 16 pcib1 memory window: 0xed00-0xedff 0xee00-0xeeff pcib1 prefetch window: 0xd000-0xdfff vgapm0 nvidia0 hdac0
Re: cardbus panic: end address is not aligned
On 07/12/2011 07:22, John Baldwin wrote: On Monday, July 11, 2011 9:29:19 pm Doug Barton wrote: On 07/08/2011 06:19, John Baldwin wrote: Hmm, well that's odd. It didn't grow it enough it seems. Also, can you boot your machine, then do 'sysctl debug.bootverbose=1', insert the card and record the messages in dmesg when it does? (You can likely get those out of kgdb.) I tried your patch, and got some odd results. The good news is, no crash. However it did not actually enable the cards, with or without if_ath being loaded before inserting them. Here is the dmesg output with debug.bootverbose=1. This is with inserting and removing first one card, then the other. Hmm, can you try without NEW_PCIB just as a test? (You'll need to add 'nooption NEW_PCIB' to your kernel config file.) Yes, but not any sooner than this evening. I see you committed the patch you sent me, so I'll update my srcs to the latest HEAD, add the option you suggested, and rebuild ASAP. Thanks again, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cardbus panic: end address is not aligned
On 07/12/2011 07:22, John Baldwin wrote: On Monday, July 11, 2011 9:29:19 pm Doug Barton wrote: On 07/08/2011 06:19, John Baldwin wrote: Hmm, well that's odd. It didn't grow it enough it seems. Also, can you boot your machine, then do 'sysctl debug.bootverbose=1', insert the card and record the messages in dmesg when it does? (You can likely get those out of kgdb.) I tried your patch, and got some odd results. The good news is, no crash. However it did not actually enable the cards, with or without if_ath being loaded before inserting them. Here is the dmesg output with debug.bootverbose=1. This is with inserting and removing first one card, then the other. Hmm, can you try without NEW_PCIB just as a test? (You'll need to add 'nooption NEW_PCIB' to your kernel config file.) No change. Still no panic, but the cards were not recognized with or without if_ath loaded in advance. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cardbus panic: end address is not aligned
On 07/14/2011 11:39, John Baldwin wrote: On Thursday, July 14, 2011 6:27:20 am Adrian Chadd wrote: Don't forget if_ath_pci. Which I think is a bug for this very reason if it turns out to be the cause. I have MODULES_OVERRIDE=ath ... in src.conf and I have an if_ath module, but no if_ath_pci module. There is no directory in /sys/modules for either, and no Makefile in /sys/dev/ath. Looking in GENERIC it seems I'm going to need ath_hal as well? Do _pci and _hal need to be compiled into the kernel unconditionally in order to use if_ath? Or am I missing something? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cardbus panic: end address is not aligned
On 07/14/2011 12:55, Doug Barton wrote: On 07/14/2011 11:39, John Baldwin wrote: On Thursday, July 14, 2011 6:27:20 am Adrian Chadd wrote: Don't forget if_ath_pci. Which I think is a bug for this very reason if it turns out to be the cause. I have MODULES_OVERRIDE=ath ... in src.conf and I have an if_ath module, but no if_ath_pci module. There is no directory in /sys/modules for either, and no Makefile in /sys/dev/ath. Looking in GENERIC it seems I'm going to need ath_hal as well? Do _pci and _hal need to be compiled into the kernel unconditionally in order to use if_ath? Or am I missing something? Adrian set me straight on /sys/modules/ath[_pci] being the proper places to build the modules, and with if_ath_pci kldload'ed the cards are recognized. There is a minor issue with one of the cards but I have some other things to poke before I am sure it's FreeBSD at fault this time. So it's likely this issue is closed. Thanks again John and Adrian for your help. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: named crashes on assertion in rbtdb.c on sparc64/SMP
On 07/14/2011 16:21, Marius Strobl wrote: On Thu, Jul 14, 2011 at 09:53:42AM +0400, KOT MATPOCKuH wrote: 2011/7/11 KOT MATPOCKuH matpoc...@gmail.com: Oops, sorry, I forgot to revert the previous patch when test-compiling. Please re-fetch sparc64_isc_atomic.h.diff2 and try again. I started named from ports (dns/bind96) at Sat Jul ?9 10:08:41 MSD, and it worked properly till Sun Jul 10 22:25:41 MSD. At 22:25:41 I restarted bind from base system with your sparc64_isc_atomic.h.diff2. From this moment till today, 15:57:05 he crashed 3 times: Jul 10 23:19:19 sunrise kernel: pid 45352 (named), uid 53: exited on signal 6 Jul 11 14:52:20 sunrise kernel: pid 52032 (named), uid 53: exited on signal 6 Jul 11 15:14:15 sunrise kernel: pid 71300 (named), uid 53: exited on signal 6 To make to ensure proper operation of bind from ports, I ran it again at 15:57:05, and, I think, we need to wait several days. And from that time till now bind from ports never died and works properly... Okay. Doug, could you please disable the use of atomic operations for sparc64 in the in-tree BIND via the following patch in order to match what the vendor source does? http://people.freebsd.org/~marius/sparc64_isc_disable_atomic.diff If you use the port and do 'make configure' are the values in config.h the same as the ones in your patch? If so, that's likely to be the right answer, and I'll go ahead and apply your patch. Thanks, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
HEADS UP: BIND 9.8 imported to HEAD
Howdy, I wanted to let everyone know that BIND 9.8.0-P4 has just been imported to 9-current, and will be part of the 9.0-RELEASE. The 9.8 branch has many nice new features vs. 9.6.x, especially in the area of DNSSEC. You can read more about the new features in the README file included in /usr/share/doc/bind9. I also encourage you to browse through the ARM, either in HTML or PDF format as there are other interesting features for both authoritative and resolving name servers. The good news is that zone files and server configurations that work with BIND 9.6.x should work without modification in 9.8.x so migration should be painless. If you have any problems or questions feel free to follow up here on -current. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: named crashes on assertion in rbtdb.c on sparc64/SMP
On 07/15/2011 01:40, Marius Strobl wrote: The generated config.h and platform.h for sparc64 are these: http://people.freebsd.org/~marius/bind96_config.h http://people.freebsd.org/~marius/bind96_platform.h Marius, Thanks again for all your help on this. During the work to upgrade to BIND 9.8 in HEAD I first tried your patch but I got some odd errors on some of the non-mainstream archs, so I ultimately went with something similar to what you sent but much more conservative. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
sys/boot/i386/boot2 build failure with clang
Howdy, Trying to build r224125 with clang, and got this (using no -j): === boot2 (all) objcopy -S -O binary boot1.out boot1 dd if=/dev/zero of=boot2.ldr bs=512 count=1 1+0 records in 1+0 records out 512 bytes transferred in 0.40 secs (12782641 bytes/sec) clang -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mregparm=3 -DUSE_XREAD -DUFS1_AND_UFS2 -DFLAGS=0x80 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/home/svn/head/sys/boot/i386/boot2/../../common -I/home/svn/head/sys/boot/i386/boot2/../btx/lib -I. -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -mllvm -stack-alignment=8 -mllvm -inline-threshold=3 -mllvm -enable-load-pre=false -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32 -march=i386 -g -std=gnu99 -S -o boot2.s.tmp /home/svn/head/sys/boot/i386/boot2/boot2.c clang: warning: the clang compiler does not support '-fno-unit-at-a-time' clang: warning: argument unused during compilation: '-fno-guess-branch-probability' clang: warning: argument unused during compilation: '-mno-align-long-strings' clang: warning: argument unused during compilation: '--param max-inline-insns-single=100' clang: warning: argument unused during compilation: '-mpreferred-stack-boundary=2' In file included from /home/svn/head/sys/boot/i386/boot2/boot2.c:172: /home/svn/head/sys/boot/i386/boot2/../../common/ufsread.c:232:17: warning: cast from 'char *' to 'struct ufs1_dinode *' increases required alignment from 1 to 4 [-Wcast-align] memcpy(dp1, (struct ufs1_dinode *)blkbuf + n, ^~~~ /home/svn/head/sys/boot/i386/boot2/../../common/ufsread.c:235:17: warning: cast from 'char *' to 'struct ufs2_dinode *' increases required alignment from 1 to 4 [-Wcast-align] memcpy(dp2, (struct ufs2_dinode *)blkbuf + n, ^~~~ /home/svn/head/sys/boot/i386/boot2/boot2.c:224:1: warning: no previous prototype for function 'main' [-Wmissing-prototypes] main(void) ^ /home/svn/head/sys/boot/i386/boot2/boot2.c:352:4: warning: cast from 'caddr_t' (aka 'char *') to 'Elf32_Word *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] *(Elf32_Word *)p = es[i].sh_size; ^~~ /home/svn/head/sys/boot/i386/boot2/boot2.c:611:8: warning: cast from 'caddr_t' (aka 'char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] t1 = *(uint32_t *)PTOV(0x46c); ^~~ 5 warnings generated. sed -e '/align/d' -e '/nop/d' boot2.s.tmp boot2.s rm -f boot2.s.tmp as --32 -o boot2.o boot2.s boot2.s: Assembler messages: boot2.s:4073: Error: unknown pseudo-op: `.cfi_sections' *** Error code 1 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sys/boot/i386/boot2 build failure with clang
I have DEBUG_FLAGS+= -g in my /etc/make.conf. Commenting that out allows this to work. Doug On 07/17/2011 03:11, Doug Barton wrote: Howdy, Trying to build r224125 with clang, and got this (using no -j): === boot2 (all) objcopy -S -O binary boot1.out boot1 dd if=/dev/zero of=boot2.ldr bs=512 count=1 1+0 records in 1+0 records out 512 bytes transferred in 0.40 secs (12782641 bytes/sec) clang -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mregparm=3 -DUSE_XREAD -DUFS1_AND_UFS2 -DFLAGS=0x80 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/home/svn/head/sys/boot/i386/boot2/../../common -I/home/svn/head/sys/boot/i386/boot2/../btx/lib -I. -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -mllvm -stack-alignment=8 -mllvm -inline-threshold=3 -mllvm -enable-load-pre=false -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32 -march=i386 -g -std=gnu99 -S -o boot2.s.tmp /home/svn/head/sys/boot/i386/boot2/boot2.c clang: warning: the clang compiler does not support '-fno-unit-at-a-time' clang: warning: argument unused during compilation: '-fno-guess-branch-probability' clang: warning: argument unused during compilation: '-mno-align-long-strings' clang: warning: argument unused during compilation: '--param max-inline-insns-single=100' clang: warning: argument unused during compilation: '-mpreferred-stack-boundary=2' In file included from /home/svn/head/sys/boot/i386/boot2/boot2.c:172: /home/svn/head/sys/boot/i386/boot2/../../common/ufsread.c:232:17: warning: cast from 'char *' to 'struct ufs1_dinode *' increases required alignment from 1 to 4 [-Wcast-align] memcpy(dp1, (struct ufs1_dinode *)blkbuf + n, ^~~~ /home/svn/head/sys/boot/i386/boot2/../../common/ufsread.c:235:17: warning: cast from 'char *' to 'struct ufs2_dinode *' increases required alignment from 1 to 4 [-Wcast-align] memcpy(dp2, (struct ufs2_dinode *)blkbuf + n, ^~~~ /home/svn/head/sys/boot/i386/boot2/boot2.c:224:1: warning: no previous prototype for function 'main' [-Wmissing-prototypes] main(void) ^ /home/svn/head/sys/boot/i386/boot2/boot2.c:352:4: warning: cast from 'caddr_t' (aka 'char *') to 'Elf32_Word *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] *(Elf32_Word *)p = es[i].sh_size; ^~~ /home/svn/head/sys/boot/i386/boot2/boot2.c:611:8: warning: cast from 'caddr_t' (aka 'char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] t1 = *(uint32_t *)PTOV(0x46c); ^~~ 5 warnings generated. sed -e '/align/d' -e '/nop/d' boot2.s.tmp boot2.s rm -f boot2.s.tmp as --32 -o boot2.o boot2.s boot2.s: Assembler messages: boot2.s:4073: Error: unknown pseudo-op: `.cfi_sections' *** Error code 1 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sys/boot/i386/boot2 build failure with clang
On 07/17/2011 07:03, Dimitry Andric wrote: In any case, I have committed a fix in r224131, let me know how that works out for you. A clean /usr/obj got me all the way through buildworld to the point where it was building the 32-bit compat libs, and got this: clang -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -isystem /usr/obj/home/svn/head/lib32/usr/include/ -L/usr/obj/home/svn/head/lib32/usr/lib32 -B/usr/obj/home/svn/head/lib32/usr/lib32 -O2 -pipe -g -I/home/svn/head/lib/libc/include -I/home/svn/head/lib/libc/../../include -I/home/svn/head/lib/libc/i386 -DNLS -D__DBINTERFACE_PRIVATE -I/home/svn/head/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/local/obj/lib32/home/svn/head/lib/libc -I/home/svn/head/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -no-integrated-as -I/home/svn/head/lib/libc/../../contrib/tzcode/stdtime -I/home/svn/head/lib/libc/stdtime -I/home/svn/head/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/home/svn/head/lib/libc/rpc -DNS_CACHING -DSYMBOL_VERSIONING -g -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /home/svn/head/lib/libc/stdlib/malloc.c clang: warning: argument unused during compilation: '-mfancy-math-387' clang: warning: argument unused during compilation: '-L/usr/obj/home/svn/head/lib32/usr/lib32' /tmp/.root/cc-ysEysz.s: Assembler messages: /tmp/.root/cc-ysEysz.s:31589: Error: unknown pseudo-op: `.cfi_sections' clang: error: assembler command failed with exit code 1 (use -v to see invocation) *** Error code 1 Thanks, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ichwd0: unable to reserve GCS registers
I'm getting this with recent HEAD: isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer ichwd0: Intel ICH7M watchdog timer at port 0x1030-0x1037,0x1060-0x107f on isa0 isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer pcib0: allocated type 4 (0x1030-0x1037) for rid 0 of ichwd0 pcib0: allocated type 4 (0x1060-0x107f) for rid 1 of ichwd0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 pcib0: allocated type 4 (0x2f8-0x2ff) for rid 0 of uart1 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sys/boot/i386/boot2 build failure with clang
On 07/18/2011 13:11, Dimitry Andric wrote: On 2011-07-18 09:42, Doug Barton wrote: .. A clean /usr/obj got me all the way through buildworld to the point where it was building the 32-bit compat libs, and got this: ... /tmp/.root/cc-ysEysz.s:31589: Error: unknown pseudo-op: `.cfi_sections' clang: error: assembler command failed with exit code 1 (use -v to see This should now really be fixed with r224201. Can you please confirm? :) Confirmed! Thanks. :) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ichwd0: unable to reserve GCS registers
On 07/18/2011 10:08, John Baldwin wrote: On Monday, July 18, 2011 4:26:49 am Doug Barton wrote: I'm getting this with recent HEAD: isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer ichwd0: Intel ICH7M watchdog timer at port 0x1030-0x1037,0x1060-0x107f on isa0 isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer pcib0: allocated type 4 (0x1030-0x1037) for rid 0 of ichwd0 pcib0: allocated type 4 (0x1060-0x107f) for rid 1 of ichwd0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 pcib0: allocated type 4 (0x2f8-0x2ff) for rid 0 of uart1 Can you get devinfo -r output while booting with 'debug.acpi.disabled=hostres'? I escaped to the loader prompt and type 'set debug..' and then booted. The devinfo output is attached. Doing the kldload with debug.bootverbose I now get this: isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer ichwd0: detached ichwd0 failed to probe at port 0x1030-0x1037,0x1060-0x107f on isa0 isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer ichwd0: Intel ICH7M watchdog timer at port 0x1030-0x1037,0x1060-0x107f on isa0 isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer ichwd0: Intel ICH7M watchdog timer (ICH7 or equivalent) ichwd0: timer disabled ichwd0: timer enabled ichwd0: timeout set to 28 ticks ichwd0: timer reloaded (repeats infinitely) Thanks, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ nexus0 apic0 ram0 I/O memory addresses: 0x0-0x9efff 0x10-0x7fe813ff acpi0 Interrupt request lines: 9 I/O ports: 0x20-0x21 0x2e-0x2f 0x4e-0x4f 0x86 0x92 0xa0-0xa1 0xb2 0xb3 0x4d0-0x4d1 0x809 0x910-0x91f 0x920-0x92f 0x930-0x97f 0xc80-0xcaf 0xcbc-0xcbf 0xcc0-0xcff 0x1000-0x1005 0x1006-0x1007 0x1008-0x1059 0x1060-0x107f 0x1080-0x10bf 0x10c0-0x10df 0xf400-0xf4fe I/O memory addresses: 0x9fc00-0x9 0xc-0xc 0xe-0xf 0x7fe81400-0x7fef 0x7ff0-0x7fff 0xf000-0xf3ff 0xf400-0xf4003fff 0xf4004000-0xf4004fff 0xf4005000-0xf4005fff 0xf4006000-0xf4006fff 0xf4008000-0xf400bfff 0xfec0-0xfec0 0xfed2-0xfed3 0xfed45000-0xfed9 0xfee0-0xfee0 0xffa8-0xffa83fff 0xffb0-0x cpu0 ACPI I/O ports: 0x1014 0x1016 acpi_perf0 est0 cpufreq0 coretemp0 cpu1 ACPI I/O ports: 0x1014 0x1016 acpi_perf1 est1 cpufreq1 coretemp1 acpi_acad0 battery0 battery1 acpi_lid0 acpi_button0 acpi_button1 acpi_sysresource0 pcib0 pci0 hostb0 pcib1 I/O memory addresses: 0xd000-0xdfff 0xed00-0xefef pci1 vgapci0 Interrupt request lines: 16 pcib1 memory window: 0xed00-0xedff 0xee00-0xeeff pcib1 prefetch window: 0xd000-0xdfff vgapm0 nvidia0 hdac0 Interrupt request lines: 256 I/O memory addresses: 0xefffc000-0xefff pcm0 pcib2 pci11 pcib3 I/O memory addresses: 0xecf0-0xecff pci12 wpi0 Interrupt request lines: 17 pcib3 memory window: 0xecfff000-0xecff pcib4 I/O memory addresses: 0xece0-0xecef pci9 uhci0 Interrupt request lines: 20 I/O ports: 0xbf80-0xbf9f usbus0 uhub0 uhci1 Interrupt request lines: 21 I/O ports: 0xbf60-0xbf7f usbus1 uhub1 uhci2 Interrupt request lines: 22 I/O ports: 0xbf40-0xbf5f usbus2 uhub2 ums0 uhci3 Interrupt request lines: 23 I/O ports: 0xbf20-0xbf3f usbus3 uhub3 ehci0 Interrupt request lines
Re: ichwd0: unable to reserve GCS registers
On 07/30/2011 05:34, John Baldwin wrote: On Saturday, July 30, 2011 02:49:52 AM Andriy Gapon wrote: on 19/07/2011 18:16 John Baldwin said the following: Hmm, can you get devinfo -r output from a working kernel with ichwd loaded? You might be able to just build the kernel with 'nooptions NEW_PCIB'. So is this still relevant? I'm sorry I haven't had a chance to get this done, but I may be able to this weekend if you still think it's useful. Doug I believe that I've got a similar problem with amdsbwd(4). It needs some resources (I/O ports) that belong to ACPI. The problem is that the driver attaches to isa bus which is under isab-pci-pcib and those particular resources are not assigned to the Host-PCI bridge. I think that you already made a suggestion that perhaps isa bus should directly attach to acpi bus when acpi is available. Not sure if there are any alternative approaches. Actually, my suggestion was the other way around (we should move certain ACPI devices down behind isab so they are behind the Host-PCI bridge as they are in hardware). In this case the BIOS clearly does not list the reosurces for the GCS as valid resources for the Host-PCI bridge. This is part of the reason that I added the 'debug.acpi.disable=hostres'. One thing we may be able to do is allow non-wildcard requests that are outside the range to still pass if they are in ACPI's system resource range perhaps. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ichwd0: unable to reserve GCS registers
On 07/30/2011 19:35, John Baldwin wrote: On 7/30/11 7:55 PM, Doug Barton wrote: On 07/30/2011 05:34, John Baldwin wrote: On Saturday, July 30, 2011 02:49:52 AM Andriy Gapon wrote: on 19/07/2011 18:16 John Baldwin said the following: Hmm, can you get devinfo -r output from a working kernel with ichwd loaded? You might be able to just build the kernel with 'nooptions NEW_PCIB'. So is this still relevant? I'm sorry I haven't had a chance to get this done, but I may be able to this weekend if you still think it's useful. No, I was able to get that info from someone else with the same issue. Awesome. Let me know if there is anything else I can not do to help. :) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ichwd0: unable to reserve GCS registers
On 08/02/2011 15:06, John Baldwin wrote:
On Saturday, July 30, 2011 2:49:52 am Andriy Gapon wrote:
on 19/07/2011 18:16 John Baldwin said the following:
Hmm, can you get devinfo -r output from a working kernel with ichwd loaded?
You might be able to just build the kernel with 'nooptions NEW_PCIB'.
I believe that I've got a similar problem with amdsbwd(4).
It needs some resources (I/O ports) that belong to ACPI.
The problem is that the driver attaches to isa bus which is under
isab-pci-pcib and those particular resources are not assigned to the
Host-PCI
bridge.
I think that you already made a suggestion that perhaps isa bus should
directly
attach to acpi bus when acpi is available. Not sure if there are any
alternative approaches.
Can you try this:
Not so much. :) the first and last patches I can apply to HEAD by hand,
but /sys/dev/acpica/acpi_pcib_acpi.c is only 387 lines long, so I'm not
even sure where to start.
Any chance you could diff against HEAD?
Doug
--- //depot/projects/pci/sys/dev/acpica/acpi.c2011-06-25
12:05:19.0
+++ //depot/projects/pci/sys/dev/acpica/acpi.c2011-08-02
20:21:42.0
@@ -1238,7 +1238,6 @@
struct resource_list_entry *rle;
struct resource_list *rl;
struct resource *res;
-struct rman *rm;
int isdefault = (start == 0UL end == ~0UL);
/*
@@ -1291,15 +1290,29 @@
} else
res = BUS_ALLOC_RESOURCE(device_get_parent(bus), child, type, rid,
start, end, count, flags);
-if (res != NULL || start + count - 1 != end)
- return (res);
/*
* If the first attempt failed and this is an allocation of a
* specific range, try to satisfy the request via a suballocation
- * from our system resource regions. Note that we only handle
- * memory and I/O port system resources.
+ * from our system resource regions.
*/
+if (res == NULL start + count - 1 == end)
+ res = acpi_alloc_sysres(child, type, rid, start, end, count, flags);
+return (res);
+}
+
+/*
+ * Attempt to allocate a specific resource range from the system
+ * resource ranges. Note that we only handle memory and I/O port
+ * system resources.
+ */
+struct resource *
+acpi_alloc_sysres(device_t child, int type, int *rid, u_long start, u_long
end,
+u_long count, u_int flags)
+{
+struct rman *rm;
+struct resource *res;
+
switch (type) {
case SYS_RES_IOPORT:
rm = acpi_rman_io;
@@ -1311,6 +1324,7 @@
return (NULL);
}
+KASSERT(start + count - 1 == end, (wildcard resource range));
res = rman_reserve_resource(rm, start, end, count, flags ~RF_ACTIVE,
child);
if (res == NULL)
--- //depot/projects/pci/sys/dev/acpica/acpi_pcib_acpi.c 2011-07-22
18:19:55.0
+++ //depot/projects/pci/sys/dev/acpica/acpi_pcib_acpi.c 2011-08-02
20:21:42.0
@@ -541,6 +541,7 @@
{
#ifdef NEW_PCIB
struct acpi_hpcib_softc *sc;
+struct resource *res;
#endif
#if defined(__i386__) || defined(__amd64__)
@@ -549,8 +550,11 @@
#ifdef NEW_PCIB
sc = device_get_softc(dev);
-return (pcib_host_res_alloc(sc-ap_host_res, child, type, rid, start,
end,
- count, flags));
+res = pcib_host_res_alloc(sc-ap_host_res, child, type, rid, start, end,
+ count, flags);
+if (res == NULL start + count - 1 == end)
+ res = acpi_alloc_sysres(child, type, rid, start, end, count, flags);
+return (res);
#else
return (bus_generic_alloc_resource(dev, child, type, rid, start, end,
count, flags));
--- //depot/projects/pci/sys/dev/acpica/acpivar.h 2011-06-22
16:25:39.0
+++ //depot/projects/pci/sys/dev/acpica/acpivar.h 2011-08-02
20:21:42.0
@@ -382,6 +382,8 @@
struct resource *res, ACPI_RESOURCE *acpi_res);
ACPI_STATUS acpi_parse_resources(device_t dev, ACPI_HANDLE handle,
struct acpi_parse_resource_set *set, void *arg);
+struct resource *acpi_alloc_sysres(device_t child, int type, int *rid,
+ u_long start, u_long end, u_long count, u_int flags);
/* ACPI event handling */
UINT32 acpi_event_power_button_sleep(void *context);
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: resolvconf script overwrites entries in resolv.conf - RDNSS/DNSSL related
On 08/04/2011 22:59, Mattia Rossi wrote: Hi all, I've finally patched my 8.2 IPv6 gateway with the RDNSS/DNSSL patches and I'm distributing DNS servers that way now. Works fine, my box running CURRENT picks up the DNS servers and search domains and writes them into /etc/resolv.conf using the resolvconf script. The script anyhow overwrites my previous manual entries in /etc/resolv.conf which I need for my manual IPv4 setup... I think it's an easily fixable bug - haven't looked into it that close atm., but given that the resolvconf script is going to be rewritten/enhanced anyways, that's something to keep in mind. I think that manual entries should always be preferred. Check 'man resolvconf.conf' for information on name_servers_append. It would probably be nice if there was a _prepend equivalent. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: svn commit: r224659 - head/etc
Ed,
First off, thanks for taking a look at this. I've always been
uncomfortable with our default nsswitch.conf file because most users do
not use nis, and although everything works with our (previous) default
it produces errors in the logs that are very non-obvious.
That said, I think the approach you have here needs some tweaking. You
only posted it to -current yesterday, and I hadn't even gotten past
thinking Ok, that's a good direction to start looking before it was
committed already. :) I know deadlines are tight prior to the release,
but I don't think they are _that_ tight.
I have 2 suggestions. The first is that if we go this way that we tweak
the sed statements to comment out the _compat entries rather than
deleting them. This will accomplish the same thing but be slightly less
confusing for users who eventually want to implement nis. This can be
accomplished like this:
-e 's/.*_compat:/# /' -e 's/compat$/files/'
The other issue is that due to the way that mergemaster works by default
users who have existing /etc/nsswitch.conf files (which should be pretty
close to 100%) won't see this change because it doesn't affect the
$FreeBSD$ tag. If we decide to keep things this way then I would suggest
adding a comment to that file so that it will get picked up.
However, I would much rather see us actually change the default file.
Users who are going to enable nis will already know that this file needs
to be tweaked, and by using more sensible defaults we'll be more
relevant to the majority of our userbase. So I propose the attached
(along with reverting your change obviously).
hth,
Doug
On 08/05/2011 10:33, Ed Schouten wrote:
Author: ed
Date: Fri Aug 5 17:33:12 2011
New Revision: 224659
URL: http://svn.freebsd.org/changeset/base/224659
Log:
Remove NIS entries from /etc/nsswitch.conf for WITHOUT_NIS.
We already modify various configuration files in /etc based on build
configuration. This is not done for nsswitch.conf right now when setting
WITHOUT_NIS. This breaks various utilities, including crond, that depend
on working databases.
Approved by:re (kib)
MFC after: 1 month
Modified:
head/etc/Makefile
Modified: head/etc/Makefile
==
--- head/etc/Makefile Fri Aug 5 17:15:46 2011(r224658)
+++ head/etc/Makefile Fri Aug 5 17:33:12 2011(r224659)
@@ -256,6 +256,10 @@ distribution:
${DESTDIR}/boot/device.hints
.endif
.endif
+.if ${MK_NIS} == no
+ sed -i -e '/_compat:/d' -e 's/compat/files/' \
+ ${DESTDIR}/etc/nsswitch.conf
+.endif
distrib-dirs:
mtree -eU ${MTREE_FOLLOWS_SYMLINKS} -f ${.CURDIR}/mtree/BSD.root.dist
-p ${DESTDIR}/
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
#
# $FreeBSD: head/etc/nsswitch.conf 158266 2006-05-03 15:14:47Z ume $
#
# To enable NIS the commented entries should replace their uncommented
# equivalents. See nsswitch.conf(5) for more information.
#
group: files
#group_compat: nis
#group: compat
passwd: files
#passwd_compat: nis
#passwd: compat
services: files
#services_compat: nis
#services: compat
hosts: files dns
networks: files
shells: files
protocols: files
rpc: files
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: svn commit: r224659 - head/etc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/05/2011 23:07, Ed Schouten wrote: Hi Doug, * Doug Barton do...@freebsd.org, 20110806 02:07: However, I would much rather see us actually change the default file. Users who are going to enable nis will already know that this file needs to be tweaked, and by using more sensible defaults we'll be more relevant to the majority of our userbase. So I propose the attached (along with reverting your change obviously). I'm fine either way. Feel free to commit it (after re approval). :-) Done, thanks. :) - -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJOPQrhAAoJEFzGhvEaGryESC0H/i90aqFTDOUduBD7zSterzC2 rUtgvj/7Pcw52jeROhn6lIutjhG4iZU1rtdSYn01y6mDppQ+Liwr7BBJQYki0u5d sPcTGZS8FfSOBTnbUq1YSTpmjQVONAA42dSYZ6pAZzlcwr0rQRbImDI7SgOkjwxR eRIY7ESMo42jq5nMnHTpgUOpp6V9nVtbJyZkQWHlOJopZLAiRmSGPYnl5qn7VUrG pKntJwK20H1mRwbf60yQNKzuoufZo4xMwhjZKLE109zkD/A8GsanM1Jyo6IZI7ZQ 8hWBjprUco3RnFIcPscK6ckAhH9zIuo86zEoqRmkqtelIhLHj/I9BGkCTTq22f8= =1nQA -END PGP SIGNATURE- ___ 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: New installation script
On 08/06/2011 07:52, Nathan Whitehorn wrote: This is, to some extent, a deliberate design decision. The idea is that if you are installing onto an existing partition with the right type, then you really do just want to use it without newfs. Actually, if I am reinstalling I really do want to newfs the system partitions because that's how I can guarantee that no old cruft is left over. I generally do not want to newfs things like /home. I think my use case here is fairly typical. There should at minimum be an option to newfs the partitions one is installing the OS to. Ideally that option should default to whatever sysinstall does now (which IIRC is 'on'). Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ghost files
On 08/06/2011 23:08, deeptec...@gmail.com wrote: i'd note that the hard drive is kind of old (7 years), and i recently had the power cut during port build operations twice, although the (UFS) filesystem is fsck-clean. Have you actually booted single user and run 'fsck -y'? That should probably be your next step. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: nroff -mandoc | more no longer works
The proper way to do this atm is 'man ./foo.1'. I had the same set of commands under the fingers as well, but doing it the new way has many benefits. Not the least of which is that you will see the page the same way man will render it when it's installed. Doug (change is hard) On 8/14/2011 12:08 PM, Julian Elischer wrote: I also use this line for testing man page edits. It will be a very sad thing if it's been broken in 9.0. On 8/14/11 8:29 AM, Robert Watson wrote: I'm guessing this relates to nroff/groff tweaks, but I was a bit unhappy to learn that the command I've used for the last decade to render man pages while editing them (nroff -mandoc foo.1 | more) no longer works (output below). It seems likely this has to do with teaching groff to use ANSI escape codes that more, by default, rejects. I'm aware there are lots of other command lines I could use, but it seems unfortunate that this is broken -- possibly more should accept more escape codes in its default configuration, or nroff should generate fewer of them? (I'd love to see this fixed for 9.0) Robert N M Watson Computer Laboratory University of Cambridge -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
periodic weekly catman - perl problem
I have the catman option enabled for periodic/weekly and get the following errors: Reformatting manual pages: catman: /usr/local/lib/perl5/5.12.4/man/cat3: mkdir: Permission denied catman: /usr/local/lib/perl5/5.12.4/perl/man/cat3: mkdir: Permission denied It seems that the cat3 directories are not created because the man directories are owned by root, and the cat* directories are owned by man, which is what the 330.catman script operates as. Creating those directories with the proper permissions allows the catman periodic script to do its thing. So my question is, is this something that the catman periodic script should be doing, or should the perl port be doing it? Doug ___ 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: Well, there goes Windows!
On Mon, 22 Aug 2011 12:23:43 +0800 Adrian Chadd adr...@freebsd.org wrote: However, an installer is user-facing (here), as well as system-facing. As much as I understand the logic behind it, it is still going to surprise people to find that their partition tables are modified at any point before that final commit. +1 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: periodic weekly catman - perl problem
On 08/22/2011 09:41, Andrej Zverev wrote: On Mon, Aug 22, 2011 at 11:59 AM, Doug Barton do...@freebsd.org mailto:do...@freebsd.org wrote: I have the catman option enabled for periodic/weekly and get the following errors: Reformatting manual pages: catman: /usr/local/lib/perl5/5.12.4/man/cat3: mkdir: Permission denied catman: /usr/local/lib/perl5/5.12.4/perl/man/cat3: mkdir: Permission denied It seems that the cat3 directories are not created because the man directories are owned by root, and the cat* directories are owned by man, which is what the 330.catman script operates as. Creating those directories with the proper permissions allows the catman periodic script to do its thing. So my question is, is this something that the catman periodic script should be doing, or should the perl port be doing it? Hello, Doug. I couldn't find which way is correct in this situation but I can propose the following patch: http://sunner.semmy.ru/~az/perl-man.txt if this solve issue when you can knock-knock at skv's (perl maintainer) door. Thanks for looking at this, but you're solving the wrong problem. :) It's the cat* directories that need to be owned by man. Having thought about this more, I think it's the 330.catman script that needs to ensure that these directories exist, likely with 'install -d'. I'll try to get to it, but if someone else is quicker ... Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ichwd attach failure
John was working on this, haven't seen an update recently though. Doug On 08/26/2011 14:24, Mike Tancsa wrote: Got a newish Intel board in and decided to give it a spin. Trying to load the watchdog, I get this error below on CURRENT. Anyone able to get ichwd working on such a motherboard ? full dmesg and devinfo at http://www.tancsa.com/intel.txt and http://www.tancsa.com/intel-asl.txt isab0: found ICH10 or equivalent chipset: Intel Cougar Point watchdog timer ichwd0: Intel Cougar Point watchdog timer on isa0 isab0: found ICH10 or equivalent chipset: Intel Cougar Point watchdog timer pcib0: allocated type 4 (0x430-0x437) for rid 0 of ichwd0 pcib0: allocated type 4 (0x460-0x47f) for rid 1 of ichwd0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 ppc0: cannot reserve I/O port range pcib0: allocated type 4 (0x2f8-0x2ff) for rid 0 of uart1 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: LOR 9.0 beta1
On 8/23/2011 7:48 AM, Garrett Cooper wrote: On Tue, Aug 23, 2011 at 4:29 AM, Holger Kipp holger.k...@alogis.com wrote: Maybe already seen... This is within Parallels 6.0 VM on a Mac with OS 10.6.8 ... This is a well known LOR. There are a lot of well-known LORs in HEAD. This is a bug. They make witness basically useless, and cause users to waste a bunch of time reporting things that are already well known. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Unusually high LA without any load at FreeBSD9-BETA2
On 09/06/2011 10:05, Garrett Cooper wrote: On Tue, Sep 6, 2011 at 9:30 AM, Alex Kozlov s...@rm-rf.kiev.ua wrote: Hi, current I see an unusually high LA for more than 10 hours without slightest load. Any ideas? What is LA? Load Average. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Screwy behavior in ports framework
First, this should be on freebsd-po...@freebsd.org. If you still have problems later please start a new thread there. On 09/13/2011 02:45, Thomas Mueller wrote: I quote my /etc/make.conf from BETA2: WRKDIR=workb2 That's guaranteed to break things. What you want is to remove that and set: WRKDIRPREFIX= /full/path/to/valid/location Make sure you set the *full* path. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Experiences with FreeBSD 9.0-BETA2
On 09/26/2011 15:38, Benjamin Kaduk wrote: This perception that ZFS is most of the future probably contributed to the lack of strong opinions regarding the default UFS partition scheme. Can we please stop saying that there were no contrary opinions stated? I personally expressed a preference (call it strong if that helps) for split partition scheme, as did several other people, all with worked examples. Nathan chose to go one big partition in spite of that input. Given that he was the one doing the work on the installer I personally decided to take a step back and see how it played out. But let's not pretend that this wasn't Nathan's decision. Meanwhile, if based on feedback from early adopters we need to tweak the layout, that's not life threatening. There is still time. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 9-Beta3 on X300 problems.
On 09/26/2011 16:02, crsnet.pl wrote: 2. Kadu/Gnu Gadu. I dont know why, but when i run kadu / gnu gadu and try to connect to Gadu-Gadu network software segments ;/ Kadu with signal 6, GnuGadu with signal 11. I try to use old gadulib, or recompie it. But this doesn't help ;/ I run portmaster -y --no-confirm --packages-if-newer -m 'BATCH=yes' -d -a The -y option is meaningless in that context, FYI. And... its works;) I'm glad to hear that at least. :) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
On 09/26/2011 17:59, Fbsd8 wrote: Your solution is very un-professional. Good thing we're all volunteers. :) What your solution purposes to do is do nothing. I think your judgment is flawed and a larger group of your peers need to review your judgment in this case. Ok, done. Eitan is right. burncd has been part of the system utilities included in the basic release since release 4.0 and cdrecord is a port. The professional solution is to remove burncd from the 9.0 system release and add the cdrecord command to the basic release as the replacement for burncd. Then add release notes entry of the change. I think you misunderstand the situation. So here are a few hopefully helpful facts: 1. The fact that something is in the base, or in the ports, has absolutely no bearing on whether one piece of software is fundamentally more useful or valuable than another. 2. burncd has only ever worked with a subset of the legacy ATA hardware. 3. ATA-CAM is on by default in FreeBSD 9 (which means that rather than acd0 as an ATA device you'll have cd0 as a SCSI device). 4. However, ATA-CAM is not mandatory, which means that leaving burncd in the base for those that want to continue using the legacy ATA interface is a perfectly reasonable course of action. 5. For those that wish to use the default ATA-CAM interface the cdrecord port provides a mature, full-featured solution. Even if it were possible to import it into the base, doing so would be a step in the wrong direction. You do not knowingly leave a non-working utility in the system, period, That makes sense, however see above. or not provide a included replacement for a popular utility as this one. The alternative already exists. The fact that it's not in the base has no relevance. I hope this clears up your confusion. If you have any further questions please direct them to freebsd-questi...@freebsd.org only. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
On 09/26/2011 18:43, Craig Rodrigues wrote: On Mon, Sep 26, 2011 at 6:28 PM, Doug Barton do...@freebsd.org wrote: burncd has been part of the system utilities included in the basic release since release 4.0 and cdrecord is a port. The professional solution is to remove burncd from the 9.0 system release and add the cdrecord command to the basic release as the replacement for burncd. Then add release notes entry of the change. I think you misunderstand the situation. So here are a few hopefully helpful facts: 1. The fact that something is in the base, or in the ports, has absolutely no bearing on whether one piece of software is fundamentally more useful or valuable than another. Hi, I have used burncd on many releases of FreeBSD, on many machines without problem. I can see the fact that burncd suddenly failing to work on ATAPI hardware could annoy and confused end-users. It doesn't fail to work on ATAPI hardware. It fails to work on cd0 which is a SCSI device. The fact that it's emulated doesn't matter. Can we modify burncd to somehow detect if ATAPI-CAM is enabled, and print out a more useful error message? Sure, as soon as someone volunteers to create that patch. No one is *trying* to annoy users, but things change around here because people are interested in changing them. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Experiences with FreeBSD 9.0-BETA2
On 09/27/2011 14:24, Peter Jeremy wrote: On 2011-Sep-26 21:29:18 -0700, Kevin Oberman kob6...@gmail.com wrote: MBR allows 4 slices (which Windows and most of the world call partitions). Windows also allows the creation of Extended Partitions, but FreeBSD does not support these. They result in device named with an 's' for slice. E.g. da0s1. To be pedantic, the FreeBSD bootcode does not support _booting_ off extended partitions. Once it is booted, FreeBSD has no problems accessing them. Correct. (I don't know if alternative bootcode such as grub can boot FreeBSD within an extended partition). Well the installer won't even look there, so you'd have to do a fair bit of gymnastics to even get it there in the first place. And given the difficulty that grub sometimes has with booting it from primary partitions I wouldn't be hopeful, even if the FreeBSD late-stage boot loader could do it, which I highly doubt. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: ports/ and 10.0-CURRENT
On 09/28/2011 12:39, Hartmann, O. wrote: The mess started to happen when I tried to repair a non CLANG compiling port math/gotoblas with portmaster -vf amth/gotoblas. Since this build binutils and even gettext and libiconv, I guess they got broken. Last I saw was a successful installation report from portmaster. But the libiconv.so.3 wasn't there anymore when I checked! This is a catastrophy ... I'm on FreeBSD 10.0-CURRENT r225844 It's been widely reported on the ports list that you can't do fresh ports compiles on 10-current, and won't be able to until well after 9.0-RELEASE. The primary reason is that auto* stuff doesn't understand the 2-digit release version. Solutions are to set UNAME_r=9.0-CURRENT in your environment, and/or twiddle the version in newvers.sh and rebuild/reinstall your kernel. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: ports/ and 10.0-CURRENT
On 09/28/2011 13:45, Beech Rintoul wrote: On Wednesday 28 September 2011 12:18:47 Doug Barton wrote: On 09/28/2011 12:39, Hartmann, O. wrote: The mess started to happen when I tried to repair a non CLANG compiling port math/gotoblas with portmaster -vf amth/gotoblas. Since this build binutils and even gettext and libiconv, I guess they got broken. Last I saw was a successful installation report from portmaster. But the libiconv.so.3 wasn't there anymore when I checked! This is a catastrophy ... I'm on FreeBSD 10.0-CURRENT r225844 It's been widely reported on the ports list that you can't do fresh ports compiles on 10-current, and won't be able to until well after 9.0-RELEASE. The primary reason is that auto* stuff doesn't understand the 2-digit release version. Solutions are to set UNAME_r=9.0-CURRENT in your environment, and/or twiddle the version in newvers.sh and rebuild/reinstall your kernel. hth, Doug So if I change /usr/src/sys/conf/newvers.sh to something like vers 9.9 I'm not going to shoot myself in the foot if I try and update? I would really like to avoid downgrading this box.I've altready been bitten once today and had to build packages on my tindy and force install. That should be the case, yes. I haven't tested it yet myself. If you do, and it works, let us know and I'll write the UPDATING entry if no one else does. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: portsnap5 problem, portsnap error handling
On 10/04/2011 03:32, Andriy Gapon wrote: Not sure which list would be best for this Given that it's a ports issue, freebsd-ports@ comes to mind ... -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
On 10/06/2011 01:41, Thomas Mueller wrote: Anyway, from what I read, csup is better, and I think I can use the same supfile and same server that I would use for cvsup? Yes. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: subversion-freebsd dependencies
On 10/06/2011 03:34, Andre Oppermann wrote: On a newly installed development machine I installed subversion-freebsd from ports and ended up with a huge dependency chain. If you're just using it for FreeBSD you can un-check all the OPTIONS. If you might want to use the http:// protocol to check something out the neon option works well and is fairly painless. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: subversion-freebsd dependencies
On 10/06/2011 12:58, Lev Serebryakov wrote: Hello, Doug. You wrote 6 октября 2011 г., 23:37:26: On a newly installed development machine I installed subversion-freebsd from ports and ended up with a huge dependency chain. If you're just using it for FreeBSD you can un-check all the OPTIONS. If you might want to use the http:// protocol to check something out the neon option works well and is fairly painless. It doesn't help to remove tcl build dependency, as sqlite3 is unconditional dependency :( 'portmaster --packages-build' does help with that stuff though, possibly with --delete-build-only if you're tight on space. Doug PS, I just noticed that this is on the wrong list ... freebsd-ports@ would be more appropriate. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvs commit: ports/security/cyrus-sasl2 Makefile ports/security/cyrus-sasl2/files patch-plugins::gssapi.c
In case anyone wants to take this on, this port fails to install on 10.0 because it uses its own version of libtool. I took a quick look but there wasn't a solution obvious enough for me. :) Doug On 10/07/2011 09:15, Hajimu UMEMOTO wrote: ume 2011-10-07 16:15:47 UTC FreeBSD ports repository Modified files: security/cyrus-sasl2 Makefile Added files: security/cyrus-sasl2/files patch-plugins::gssapi.c Log: Fix GSSAPI client crash, NULL ptr dereference. Submitted by: Phil Pennock cyrus-sasl-phil__at__spodhuis.org Obtained from: http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2011-October/002358.html Revision ChangesPath 1.148 +1 -1 ports/security/cyrus-sasl2/Makefile 1.5 +22 -0 ports/security/cyrus-sasl2/files/patch-plugins::gssapi.c (new) http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/security/cyrus-sasl2/Makefile.diff?r1=1.147r2=1.148f=h http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/security/cyrus-sasl2/files/patch-plugins::gssapi.c -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: flash for 9-beta3
On 10/08/2011 14:53, Warren Block wrote: nspluginwrapper needs to be run as the end user. The pkg-message tells them to do that. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Patch for ports on 10-current
Until the pointy-haireds come up with a better solution, here is a patch that incorporates work that others have done into a manageable form so that those interested in working with ports on 10-current have some tools to work with: http://dougbarton.us/bam.patch You need to do the equivalent of 'portmaster -o devel/libtool-fixed libtool' to get the fixed version. In addition to the OSVERSION check I added knobs to selectively disable the 2 parts of the fix to aid in development and testing. Also, make sure that you have the latest /usr/share/mk/bsd.port.mk with the similar fix backed out. Hopefully there will be a better fix soon, but until there is, I hope that this helps. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Patch for ports on 10-current
On 10/10/2011 15:00, Nali Toja wrote:
Doug Barton do...@freebsd.org writes:
Until the pointy-haireds come up with a better solution, here is a patch
that incorporates work that others have done into a manageable form so
that those interested in working with ports on 10-current have some
tools to work with:
http://dougbarton.us/bam.patch
[...]
+.if ${OSVERSION} = 100 !defined(NO_LIBTOOL_FIXED)
The issue does not lie in OSVERSION but in OSREL. So, why not be smarter
and detect if a user has UNAME_r workaround in environment
Because by doing it the way I did it the user can apply both fixes, or
either fix individually by using the right combination of knobs.
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvs commit: ports/security/cyrus-sasl2 Makefile ports/security/cyrus-sasl2/files patch-plugins::gssapi.c
On 10/09/2011 09:29, Hajimu UMEMOTO wrote: Hi, On Fri, 07 Oct 2011 16:48:52 -0700 Doug Barton do...@freebsd.org said: dougb In case anyone wants to take this on, this port fails to install on 10.0 dougb because it uses its own version of libtool. I took a quick look but dougb there wasn't a solution obvious enough for me. :) I didn't have 10-current box, yet. So, I've just upgraded my 9-current box to today's current, and tried to rebuild cyrus-sasl2 port on it. However, I couldn't reproduce the problem. It built just fine, here. Any thought? So I was able to confirm that the patch which had previously been in /usr/share/mk/bsd.port.mk was what caused it to fail. Hopefully that information will be helpful to those working on improving the generic fix. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 9.0-BETA3 Available...
On 10/12/2011 06:47, Ken Smith wrote: On Wed, 2011-10-12 at 14:39 +0100, Bruce Cran wrote: On 29/09/2011 02:42, Ken Smith wrote: MD5 (FreeBSD-9.0-BETA3-amd64-bootonly.iso) = 2ce7b93d28fd7ff37965893f1af3f7fc MD5 (FreeBSD-9.0-BETA3-amd64-dvd1.iso) = 4affc701f2052edc548274f090e49235 MD5 (FreeBSD-9.0-BETA3-amd64-memstick.img) = e260f2f2122326cb9a93ac83eb006c1c The -dvd1.iso files seem to be less than a CD, at 610MB. Are they expected to contain more data over time, or could 'dvd' be removed? I was planning on them having package sets. The new installer doesn't support installing packages like sysinstall had but if I provide Gnome, KDE, and perhaps a small set of other stuff it would be useful to people with crummy network connectivity. They could install the packages from the DVD instead of needing to have everything downloaded. Is there still going to be a CD-sized installer? I find this really useful both at home, and also for virtualized installs. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fixed: ichwd failure to attach
On 10/12/2011 08:20, Michael Butler wrote: SVN r226302 solves the ichwd failure to attach issue .. Still failing for me: ichwd0: Intel ICH10DO watchdog timer on isa0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 r226340, smp, amd64 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fixed: ichwd failure to attach
On 10/14/2011 10:35, Xin LI wrote: On 10/14/11 04:35, John Baldwin wrote: On Thursday, October 13, 2011 6:26:26 pm Doug Barton wrote: On 10/12/2011 08:20, Michael Butler wrote: SVN r226302 solves the ichwd failure to attach issue .. Still failing for me: ichwd0: Intel ICH10DO watchdog timer on isa0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 Yes, it can only fix it if the BIOS decides to list it as a system resource in ACPI. However, using 'debug.acpi.disabled=hostres' should still be working as a workaround for lying BIOSes yes? As I reported previously, that didn't work for me. I'll try it again next time I reboot JIC. FYI, I also have a Dell system, Optiplex 960. I do have debug.acpi.disabled=hostres but it doesn't seem help in my case (Dell Latitude D630): ichwd0: Intel ICH8M watchdog timer on isa0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 ichwd0: Intel ICH8M watchdog timer at port 0x1030-0x1037,0x1060-0x107f on isa0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 Is there something I should look at or additional information needed? Cheers, -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fixed: ichwd failure to attach
On 10/14/2011 12:03, Xin LI wrote: Hmm, is your isab device behind a PCI-PCI bridge? Me either: isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 9.0-beta3 preferring ipv4 over ipv6 with ipv6_activate_all_interfaces=YES
On 10/14/2011 10:38, Hajimu UMEMOTO wrote: AFAIK, recent Firefox implements Happy Eyeballs. So, I suspect it doesn't obey RFC 3484, anymore. My understanding is that they added it, then turned it off because it didn't work as expected. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sys/conf/newvers.sh vs. subversion-1.7
On 10/21/2011 17:51, Craig Rodrigues wrote: Can you come up with a patch which invoke svn info . (if the svn binary exists)? This is slightly faster than svnversion. If svn info . doesn't error out, you can assume that the directory is under SVN control. Doesn't svnversion error out pretty quickly in the same circumstance? My brief testing seems to indicate that it does. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: IPv6 accept_rtadv + bfe0
On 10/19/2011 00:29, Hiroki Sato wrote: Mattia Rossi mro...@swin.edu.au wrote in 4e9dfe11.2070...@swin.edu.au: mr So the _ipv6 bit doesn't take care of passing inet6 to ifconfig mr automatically? No. You always need to add the inet6 keyword wherever needed. That seems redundant, and contrary to how the IPv4 equivalents work. And obviously it's confusing to users. From what I can see looking at some 7.x and 8.x systems it also seems to be a POLA violation. Perhaps this is something that you should reconsider? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sys/conf/newvers.sh vs. subversion-1.7
On 10/21/2011 22:42, Craig Rodrigues wrote: Hi, I tried following: (1) Run svnversion in non-svn directory: return status == 0 Return status isn't everything. :) prints out exported In my case (1.7) it says Unversioned directory But my point (which perhaps I should have made more explicit) is that given the fact that svnversion handles non-svn directories gracefully it's faster (simpler, etc.) to just run foo=`svnversion` and then make sure that $foo is rational than it is to run 2 commands. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sys/conf/newvers.sh vs. subversion-1.7
On 10/22/2011 08:29, Garrett Cooper wrote:
$(svn info | awk '/^Revision:/ {print $2}')
2 subshells and a pipe for this, vs. only 1 subshell for just running
svnversion.
Anyone else want to propose a more complex solution when a simple and
more effective one already exists? :)
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sys/conf/newvers.sh vs. subversion-1.7
On 10/22/2011 12:07, Boris Samorodov wrote:
22.10.2011 22:12, Doug Barton пишет:
On 10/22/2011 08:29, Garrett Cooper wrote:
$(svn info | awk '/^Revision:/ {print $2}')
2 subshells and a pipe for this, vs. only 1 subshell for just running
svnversion.
Anyone else want to propose a more complex solution when a simple and
more effective one already exists? :)
I'm not an exert here, so I'm not sure which one and why did you call
simple and more effective:
Please read the rest of this thread, where the fact that svnversion does
more than what 'svn info' does, and that people find the more that it
does to be useful.
So simpler is one command, not 2 or more, and more effective is
provides more information, and people find that extra information
useful. :)
hth,
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sys/conf/newvers.sh vs. subversion-1.7
On 10/24/2011 10:14, Craig Rodrigues wrote: On Fri, Oct 21, 2011 at 10:47 PM, Doug Barton do...@freebsd.org wrote: On 10/21/2011 22:42, Craig Rodrigues wrote: Hi, I tried following: (1) Run svnversion in non-svn directory: return status == 0 Return status isn't everything. :) prints out exported In my case (1.7) it says Unversioned directory But my point (which perhaps I should have made more explicit) is that given the fact that svnversion handles non-svn directories gracefully it's faster (simpler, etc.) to just run foo=`svnversion` and then make sure that $foo is rational than it is to run 2 commands. Doug Hi, What logic can we use to make sure svnversion returns a rational value? Make sure that the response starts with a number. It looks like the output of svnversion for non-svn directories is inconsistent between versions of Subversion. The non-svn responses vary, the svn responses don't. :) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sys/conf/newvers.sh vs. subversion-1.7
On 10/25/2011 12:43, Craig Rodrigues wrote:
I know that Doug disagreed with me on this,
I didn't disagree with you. I pointed out that there is absolutely no
reason to run 2 separate commands. To put it more bluntly, I pointed out
why your suggestion is a bad idea.
I'm sorry to be so blunt but I'm getting really tired of people who
can't let go of bad ideas even when it's demonstrated conclusively why
they are bad. :)
The alternative would be to run ${dir}/svnversion, and check the output
of that command, making sure that the output starts with a number.
The attached implements that, and is almost certainly the right way to
go. It would be nice if someone could test it, and better if someone
else could commit it. I swore after the last time that I'd stay away
from that file precisely because of all the bikeshed stupidity that this
issue creates.
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
Index: newvers.sh
===
--- newvers.sh (revision 226474)
+++ newvers.sh (working copy)
@@ -88,7 +88,7 @@
i=`${MAKE:-make} -V KERN_IDENT`
for dir in /bin /usr/bin /usr/local/bin; do
- if [ -d ${SYSDIR}/.svn -a -x ${dir}/svnversion ] ; then
+ if [ -x ${dir}/svnversion ] ; then
svnversion=${dir}/svnversion
break
fi
@@ -99,8 +99,12 @@
done
if [ -n $svnversion ] ; then
-echo $svnversion
- svn= r`cd ${SYSDIR} $svnversion`
+ echo $svnversion
+ svn=`cd ${SYSDIR} $svnversion`
+ case $svn in
+ [0-9]*) svn= r${svn} ;;
+ *) unset svn ;;
+ esac
fi
if [ -n $git_cmd ] ; then
___
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: sys/conf/newvers.sh vs. subversion-1.7
On 10/25/2011 13:23, Craig Rodrigues wrote:
On Tue, Oct 25, 2011 at 1:07 PM, Doug Barton do...@freebsd.org wrote:
I didn't disagree with you. I pointed out that there is absolutely no
reason to run 2 separate commands. To put it more bluntly, I pointed out
why your suggestion is a bad idea.
Hmmm, sounds like a disagreement to me.
Disagreement implies that you and I both have equally valid ideas, and
that we cannot agree on which one to use.
I have read your concerns, but I don't fully
understand why invoking svn info ${SRCDIR}/sys,
ignoring the output of svn info, and then just
checking its return status is a bad idea.
As I tried to explain previously, running one command, testing the
outcome, and then running another command if the first succeeded is a
bad idea if you can simply run the command you need to run in the first
place and parse *its* output. Obviously running 'svn info' first isn't
overwhelmingly expensive, so this isn't the most horrible idea ever
suggested for FreeBSD. However as a general principle we should be
trying to do the best we can, not only for its own sake, but as an
example to those who read and copy the code.
BTW, the rest of my analysis in my previous post is relevant here too.
If a bare 'svnversion' took a long time to return in a non-svn directory
then obviously we'd have to give your solution a better look. However,
given that it returns nearly instantaneously, there's no point.
Using svnversion further down in the script
if svn info succeeds is all that I was recommending.
Yes, I understood what you were suggesting. :)
Anyways, I am fine with the patch which you propose.
Awesome!
The only possible issue could be in future,
if svn switches from using decimal revision numbers
to numbers which are in hexadecimal, base64, etc.
However, that is not currently the case, and if
it does happen in future, we can change the script
accordingly.
Actually hex would still work since 0x would match. :)
In any case I just tested the svn case, and it worked. If someone else
could test the non-svn case then we can get this fixed and move on.
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sys/conf/newvers.sh vs. subversion-1.7
On 10/25/2011 14:45, Craig Rodrigues wrote: On Tue, Oct 25, 2011 at 1:54 PM, Doug Barton Actually hex would still work since 0x would match. :) Yes, but if in the future, a revision number format is ever chosen that doesn't include 0x at the beginning, and is something like: a23728ea7d592acc69b36875a482cdf3fd5c8d then this check would fail. However, none of this exists yet in SVN, so it is not worth worry about right now. Yes, that was what the smiley at the end of my sentence above was intending to convey. Sorry I wasn't more clear. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sys/conf/newvers.sh vs. subversion-1.7
On 10/27/2011 12:05, Craig Rodrigues wrote: On Tue, Oct 25, 2011 at 1:07 PM, Doug Barton do...@freebsd.org wrote: The attached implements that, and is almost certainly the right way to go. It would be nice if someone could test it, and better if someone else could commit it. I swore after the last time that I'd stay away from that file precisely because of all the bikeshed stupidity that this issue creates. Hi, I tested your patch and it works. I am attaching vers.c files which I generated in trees which were under svn control, and not under svn control. Thanks for testing the non-svn case. I just committed the patch. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Upgrade from source to RC1: problems with /etc : lost users and dbus
On 10/28/2011 01:43, Thomas Mueller wrote: How does one run mergemaster without running roughshod over existing configuration? Carefully? :) Seriously ... always use the -P option, and/or add PRESERVE_FILES in your mergemaster rc file. Watch the changes carefully. If you have to, do the updates in more than one pass using the -r option for subsequent runs. Do the simple ones first, then go back and do the ones that you have to think harder about. I recommend against using the -U option. It's not rocket science, it's just like any other system administration task, it requires careful attention. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Upgrade from source to RC1: problems with /etc : lost users and dbus
On 10/28/2011 07:57, kama wrote: On Fri, 28 Oct 2011, John Baldwin wrote: On Thursday, October 27, 2011 7:14:51 am Ed Schouten wrote: * Tom Evans tevans...@googlemail.com, 20111027 13:06: I have had this happen before, the PEBKAC. When running mergemaster, it will prompt you to install new passwd, master.passwd and group files - if you have added local users you must not say yes to this, you must either merge the changes in or keep your local one. It would have been so awesome if our /etc/master.passwd and /etc/group included an #include directive. I do agree with this. Or if you could have /etc/passwd.d and /etc/group.d directories that can contain files that are auto-included. Agreed. Another idea is to let mergemaster call pw(8) to add remove users and groups instead of merging the files. I definitely would not be inclined to do it this way. The manner in which mergemaster works now is fine, it just requires the sysadmin to pay attention when doing the merge. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Upgrade from source to RC1: problems with /etc : lost users and dbus
On 10/28/2011 20:09, Kevin Oberman wrote: On Fri, Oct 28, 2011 at 6:34 PM, Doug Barton do...@freebsd.org wrote: On 10/28/2011 01:43, Thomas Mueller wrote: How does one run mergemaster without running roughshod over existing configuration? Carefully? :) Seriously ... always use the -P option, and/or add PRESERVE_FILES in your mergemaster rc file. Watch the changes carefully. If you have to, do the updates in more than one pass using the -r option for subsequent runs. Do the simple ones first, then go back and do the ones that you have to think harder about. I recommend against using the -U option. It's not rocket science, it's just like any other system administration task, it requires careful attention. I agree that just running mergemaster CAREFULLY does the job. The only time I was ever burned was when I was in a BIG hurry and ended up wasting a LOT of time. (I think I also learned.) Of course, I also remember merging /etc before we had mergemaster. Yeah, me too, that's why I wrote it. :) I am a bit curious why you recommend against -U, though. I've been using it since it was added and have never had a problems. It's saved me quite a bit of time. Is thee a corner case that I'm missing? The case where there are relevant changes in configuration or other files that you miss because you install them without examination. That said, I realize that what people *want* is an upgrade process that they don't have to look at and/or think about. As soon as I figure out how to make mergemaster telepathic I'll be sure to add that patch. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Upgrade from source to RC1: problems with /etc : lost users and dbus
On 10/28/2011 20:44, Kevin Oberman wrote: On Fri, Oct 28, 2011 at 8:24 PM, Doug Barton do...@freebsd.org wrote: On 10/28/2011 20:09, Kevin Oberman wrote: On Fri, Oct 28, 2011 at 6:34 PM, Doug Barton do...@freebsd.org wrote: On 10/28/2011 01:43, Thomas Mueller wrote: How does one run mergemaster without running roughshod over existing configuration? Carefully? :) Seriously ... always use the -P option, and/or add PRESERVE_FILES in your mergemaster rc file. Watch the changes carefully. If you have to, do the updates in more than one pass using the -r option for subsequent runs. Do the simple ones first, then go back and do the ones that you have to think harder about. I recommend against using the -U option. It's not rocket science, it's just like any other system administration task, it requires careful attention. I agree that just running mergemaster CAREFULLY does the job. The only time I was ever burned was when I was in a BIG hurry and ended up wasting a LOT of time. (I think I also learned.) Of course, I also remember merging /etc before we had mergemaster. Yeah, me too, that's why I wrote it. :) I am a bit curious why you recommend against -U, though. I've been using it since it was added and have never had a problems. It's saved me quite a bit of time. Is thee a corner case that I'm missing? The case where there are relevant changes in configuration or other files that you miss because you install them without examination. That said, I realize that what people *want* is an upgrade process that they don't have to look at and/or think about. As soon as I figure out how to make mergemaster telepathic I'll be sure to add that patch. An obvious problem that I managed overlook all of this time. Well people try very hard not to introduce POLA'ish problems, but sometimes it's necessary, and sometimes it happens in spite of our best efforts (as Garrett pointed out). And thanks for all of your shell code. Between mergemaster and portmaster you have saved many, many man-years of painful and error-prone effort. You're welcome. :) Do you dream in sh? Well I probably will NOW, thanks a lot! Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: request: merging if_ath_tx branch to HEAD
On 10/31/2011 14:17, Adrian Chadd wrote: Hi all, I'd like to merge the if_ath_tx code into -HEAD so it gets some wider testing. This includes a couple of net80211 changes but it overwhelmingly is if_ath driver changes. The code is a bit messy and it's still a work in progress but I'd rather tidy it up in -HEAD. Otherwise I'm stuck in the unfortunate situation of having to keep merging between the if_ath_tx branch and -HEAD. Is this work that is planned to be migrated to 9.0-RELEASE? If not, shouldn't it wait till after the release? -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: request: merging if_ath_tx branch to HEAD
On 10/31/2011 17:22, Adrian Chadd wrote: On 31 October 2011 14:52, Doug Barton do...@freebsd.org wrote: The code is a bit messy and it's still a work in progress but I'd rather tidy it up in -HEAD. Otherwise I'm stuck in the unfortunate situation of having to keep merging between the if_ath_tx branch and -HEAD. Is this work that is planned to be migrated to 9.0-RELEASE? If not, shouldn't it wait till after the release? Well, it depends on how long 9.0-RELEASE is going to take. If it's going to take days, then sure I can wait. But if it's going to take weeks, I'll likely _have_ the rest of the if_ath_tx missing pieces done and ready for merge into 9.0. In any case, I do want to merge the ath 11n stuff into -9, so even if it's not done by 9.0, it'll be done shortly after. Given that RC1 is already out, you should probably check with re@ first. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /sys/amd64/conf/DEFAULTS
On 11/08/2011 09:33, Scott Long wrote: On Nov 8, 2011, at 7:52 AM, O. Hartmann wrote: Am 11/08/11 14:31, schrieb Chuck Burns: On Tuesday, November 08, 2011 02:12:58 PM Niclas Zeising wrote: From my understanding of things, the DEFAULTS kernel configuration file is automatically included into the build by config(8). There is no need to include it into the generic using the include statement. It was first added 6 years ago, on October 27 2005. Regards! Not sure if you already know this, or not but another thing to keep in mind, if a module is not mentioned, or is commented out, then it will still be built, just not included into the monolithic kernel. If you were already aware of this, then my apologies. Chuck Hello. well, I'm aware of that, but it doesn't matter. As long as I do not use a broken or commented out module, it is all right. I was a little bit surprised having options already set I never set in the usual config file named after the host's name or GENERIC. And for FBSD 10.0/amd64, it has been started to use a VFS-option for loading thread safe filesystems. I've never liked that DEFAULTS is magically invisible. I know that the intention was to keep users from shooting their feet off by accidentally excluding it from their configs, but I think it creates more confusion that it solves. +1 on both counts -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: /etc/group chkgrp invalid character @
If you want to start a new thread please don't reply to an old one and change the subject line, please create a whole new message instead. That way those of us who read our mail threaded won't miss your new topic because it is hidden under an old one. -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on i386/i386
Adrian, This has been going on for a while. Are you subscribed to -current? Any plans to fix this? Doug On 11/09/2011 23:05, FreeBSD Tinderbox wrote: TB --- 2011-11-10 02:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-10 02:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-11-10 02:10:00 - cleaning the object tree TB --- 2011-11-10 02:10:52 - cvsupping the source tree TB --- 2011-11-10 02:10:52 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-11-10 02:11:03 - building world TB --- 2011-11-10 02:11:03 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 02:11:03 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 02:11:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 02:11:03 - SRCCONF=/dev/null TB --- 2011-11-10 02:11:03 - TARGET=i386 TB --- 2011-11-10 02:11:03 - TARGET_ARCH=i386 TB --- 2011-11-10 02:11:03 - TZ=UTC TB --- 2011-11-10 02:11:03 - __MAKE_CONF=/dev/null TB --- 2011-11-10 02:11:03 - cd /src TB --- 2011-11-10 02:11:03 - /usr/bin/make -B buildworld World build started on Thu Nov 10 02:11:03 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Nov 10 04:22:28 UTC 2011 TB --- 2011-11-10 04:22:28 - generating LINT kernel config TB --- 2011-11-10 04:22:28 - cd /src/sys/i386/conf TB --- 2011-11-10 04:22:28 - /usr/bin/make -B LINT TB --- 2011-11-10 04:22:28 - cd /src/sys/i386/conf TB --- 2011-11-10 04:22:28 - /usr/sbin/config -m LINT-NOINET TB --- 2011-11-10 04:22:28 - building LINT-NOINET kernel TB --- 2011-11-10 04:22:28 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 04:22:28 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 04:22:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 04:22:28 - SRCCONF=/dev/null TB --- 2011-11-10 04:22:28 - TARGET=i386 TB --- 2011-11-10 04:22:28 - TARGET_ARCH=i386 TB --- 2011-11-10 04:22:28 - TZ=UTC TB --- 2011-11-10 04:22:28 - __MAKE_CONF=/dev/null TB --- 2011-11-10 04:22:28 - cd /src TB --- 2011-11-10 04:22:28 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Thu Nov 10 04:22:28 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET completed on Thu Nov 10 04:53:09 UTC 2011 TB --- 2011-11-10 04:53:09 - cd /src/sys/i386/conf TB --- 2011-11-10 04:53:09 - /usr/sbin/config -m LINT-NOINET6 TB --- 2011-11-10 04:53:09 - building LINT-NOINET6 kernel TB --- 2011-11-10 04:53:09 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 04:53:09 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 04:53:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 04:53:09 - SRCCONF=/dev/null TB --- 2011-11-10 04:53:09 - TARGET=i386 TB --- 2011-11-10 04:53:09 - TARGET_ARCH=i386 TB --- 2011-11-10 04:53:09 - TZ=UTC TB --- 2011-11-10 04:53:09 - __MAKE_CONF=/dev/null TB --- 2011-11-10 04:53:09 - cd /src TB --- 2011-11-10 04:53:09 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 Kernel build for LINT-NOINET6 started on Thu Nov 10 04:53:09 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET6 completed on Thu Nov 10 05:23:36 UTC 2011 TB --- 2011-11-10 05:23:36 - cd /src/sys/i386/conf TB --- 2011-11-10 05:23:36 - /usr/sbin/config -m LINT-NOIP TB --- 2011-11-10 05:23:36 - building LINT-NOIP kernel TB --- 2011-11-10 05:23:36 - CROSS_BUILD_TESTING=YES TB --- 2011-11-10 05:23:36 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-10 05:23:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-10 05:23:36 - SRCCONF=/dev/null TB --- 2011-11-10 05:23:36 - TARGET=i386 TB --- 2011-11-10 05:23:36 - TARGET_ARCH=i386 TB --- 2011-11-10 05:23:36 - TZ=UTC TB --- 2011-11-10 05:23:36 - __MAKE_CONF=/dev/null TB --- 2011-11-10 05:23:36 - cd /src TB --- 2011-11-10 05:23:36 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP Kernel build for LINT-NOIP started on Thu Nov 10 05:23:36 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOIP completed on Thu Nov 10 05:52:09 UTC 2011 TB --- 2011-11-10 05:52:09 - cd /src/sys/i386/conf TB --- 2011-11-10 05:52:09 - /usr/sbin/config -m LINT-VIMAGE TB --- 2011-11-10 05:52:09 - building LINT-VIMAGE kernel TB --- 2011-11-10 05:52:09 -
Re: Use of newest version number such as 10.0 instead of current
On 11/11/2011 04:29, Mehmet Erol Sanliturk wrote: pkg_add -r * is giving error about directory not found . This is preventing testing and / or using efforts . I see your perspective on this, but package support for HEAD (N-current) is always done on a best effort basis, and is incredibly likely to be broken during a new major branch release cycle no matter what. Also, because HEAD is a rapidly moving target the preferred way to deal with ports is to compile the ports, not to use packages at all. Or, to use packages when they exist, but compile everything else. The PACKAGESITE environment variable can help with that. Your point that it should be easier is well taken, I think moreso for the RCs than for HEAD. There has been some discussion about how to update the logic for pkg_add, but I'm not sure that symlinks are going to be the answer. Doug -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Use of newest version number such as 10.0 instead of current
On 11/11/2011 14:23, George Kontostanos wrote: BTW I follow both stable and current lists. I have noticed that people still ask questions in current regarding 9-RC(*) problems. Maybe if it was clear that current is now 10 this would not happen. Actually up until the actual release we encourage users to ask about the new branch on -current, for a variety of reasons. -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ixgbe and fast interrupts
On 11/18/2011 09:54, Luigi Rizzo wrote: One more thing (i am mentioning it here for archival purposes, as i keep forgetting to test it). Is entropy harvesting expensive ? No. It was designed to be inexpensive on purpose. :) -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: rc.conf changes IPV6
Looping Hiroki Sato in since he's the architect of the most recent changes here. Doug On 11/21/2011 12:11, Stefan Bethke wrote: Am 21.11.2011 um 20:25 schrieb Dan The Man: I notice we have changed way IPV6 is done in rc.conf now. I assume someone will update: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-ipv6.html My question now concerns aliases, and what the norm will end up being. Here is example below: Here we have the new layout with IPV6, the below works fine, however since the ifconfig lines for IPV4 and IPV6 are essentially the same other than the actual inet and inet6, will it be ok to start with alias0 for both IPV4 and IPV6, or should I in this example be starting at alias4 for IPV6? I would like idea to keep it way it is each protocal starting at alias0. #GATEWAY defaultrouter=67.159.46.233 hostname=sunsaturn.com #IPV4 ifconfig_em1=inet 67.159.46.238 netmask 255.255.255.248 ifconfig_em1_alias0=inet 67.159.46.234 netmask 255.255.255.248 ifconfig_em1_alias1=inet 67.159.46.235 netmask 255.255.255.248 ifconfig_em1_alias2=inet 67.159.46.236 netmask 255.255.255.248 ifconfig_em1_alias3=inet 67.159.46.237 netmask 255.255.255.248 #IPV6 ipv6_activate_all_interfaces=YES ipv6_network_interfaces=em1 ipv6_defaultrouter=2001:49f0:4004:::::0001 ifconfig_em1_ipv6=inet6 2001:49f0:4004:::::0002 prefixlen 48 ifconfig_em1_alias0=inet6 2001:49f0:4004:::::0003 prefixlen 48 ifconfig_em1_alias1=inet6 2001:49f0:4004:::::0004 prefixlen 48 Remember that rc.conf follows shell syntax and sematics, so the second _alias0 and _alias1 will overwrite the previous ones. In 9.0 you can use the ipv4_addrs_ifname variable to set both the IPv4 main address as well as alias addresses, see rc.conf(5). There doesn't seem to be an equivalent IPv6 option, as best as I can tell. Stefan ___ 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: rc.conf changes IPV6
On 11/21/2011 17:39, Dan The Man wrote: On Mon, 21 Nov 2011, Stefan Bethke wrote: Am 21.11.2011 um 20:25 schrieb Dan The Man: I notice we have changed way IPV6 is done in rc.conf now. I assume someone will update: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-ipv6.html My question now concerns aliases, and what the norm will end up being. Here is example below: Here we have the new layout with IPV6, the below works fine, however since the ifconfig lines for IPV4 and IPV6 are essentially the same other than the actual inet and inet6, will it be ok to start with alias0 for both IPV4 and IPV6, or should I in this example be starting at alias4 for IPV6? I would like idea to keep it way it is each protocal starting at alias0. #GATEWAY defaultrouter=67.159.46.233 hostname=sunsaturn.com #IPV4 ifconfig_em1=inet 67.159.46.238 netmask 255.255.255.248 ifconfig_em1_alias0=inet 67.159.46.234 netmask 255.255.255.248 ifconfig_em1_alias1=inet 67.159.46.235 netmask 255.255.255.248 ifconfig_em1_alias2=inet 67.159.46.236 netmask 255.255.255.248 ifconfig_em1_alias3=inet 67.159.46.237 netmask 255.255.255.248 #IPV6 ipv6_activate_all_interfaces=YES ipv6_network_interfaces=em1 ipv6_defaultrouter=2001:49f0:4004:::::0001 ifconfig_em1_ipv6=inet6 2001:49f0:4004:::::0002 prefixlen 48 ifconfig_em1_alias0=inet6 2001:49f0:4004:::::0003 prefixlen 48 ifconfig_em1_alias1=inet6 2001:49f0:4004:::::0004 prefixlen 48 Remember that rc.conf follows shell syntax and sematics, so the second _alias0 and _alias1 will overwrite the previous ones. In 9.0 you can use the ipv4_addrs_ifname variable to set both the IPv4 main address as well as alias addresses, see rc.conf(5). There doesn't seem to be an equivalent IPv6 option, as best as I can tell. You would assume so Stefan, that the duplicate alias0 would overwrite, but it seems since ifconfig separates the namespace for IPV4/IPV6 it actually works. I don't see how that could possibly be true, how have you tested it? Doug -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: WITHOUT_PROFILE=yes by default
On 11/28/2011 02:38, Max Khon wrote: Are there any compelling reasons for having profiled libs to be built by default? Nope. It's been one of the first things I disable after I install a new system for at least a decade. Ideally we could do this for 9.0. Doug -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: WITHOUT_PROFILE=yes by default
On 11/28/2011 16:33, Poul-Henning Kamp wrote: In message 4ed4222e.5010...@freebsd.org, Doug Barton writes: On 11/28/2011 02:38, Max Khon wrote: Are there any compelling reasons for having profiled libs to be built by default? Nope. It's been one of the first things I disable after I install a new system for at least a decade. Ideally we could do this for 9.0. Can we at least keep one (small) library compiled for profiling, so that compiling for profiling doesn't get broken by accident ? I think WITH_PROFILE is probably a good idea for the tinderbox? -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Remove debug echo
On 11/29/2011 13:07, John Baldwin wrote:
Any objections to this?
Nope. I wondered why it was there myself, but didn't care enough to ask. :)
It removes a weird line during 'make -s buildworld'
output and I think it was debugging accidentally left in in 213077 by Warner:
Index: newvers.sh
===
--- newvers.sh(revision 228074)
+++ newvers.sh(working copy)
@@ -99,7 +99,6 @@ for dir in /bin /usr/bin /usr/local/bin; do
done
if [ -n $svnversion ] ; then
- echo $svnversion
svn=`cd ${SYSDIR} $svnversion`
case $svn in
[0-9]*) svn= r${svn} ;;
--
We could put the whole Internet into a book.
Too practical.
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: WITHOUT_PROFILE=yes by default
What does dtrace have to do with profiled libs? On 11/29/2011 17:14, Paul Ambrose wrote: I think dtrace for freebsd userland is close to complete( after r227290, at least no more kernel panic). but is not suitable for a daily use now. 在 2011年11月30日 上午5:42，Sevan / Venture37 ventur...@gmail.com 写道： I assume every who responded so far doesn't use dtrace? -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: WITHOUT_PROFILE=yes by default
On 12/01/2011 22:41, Steve Kargl wrote: Having a set of profiled libraries in-sync with the static and shared libraries allows one to run the profiler on their code when someone changes a library and that change causes a dramatic change in the performance of one's code. And as Max pointed out in his OP, that only applies to a tiny fraction of our users, or even our developers. If you want to use them, turn the knob. PS: David was not complaining about fixing a 17 year old bug. He was stating that a single day of discussion changing a 17 year old practice seems a little too brief. If it's a good idea, it's a good idea no matter how many different ways we flog it. :) Doug -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: WITHOUT_PROFILE=yes by default
On 12/01/2011 23:23, Steve Kargl wrote: On Thu, Dec 01, 2011 at 10:59:59PM -0800, Doug Barton wrote: On 12/01/2011 22:41, Steve Kargl wrote: Having a set of profiled libraries in-sync with the static and shared libraries allows one to run the profiler on their code when someone changes a library and that change causes a dramatic change in the performance of one's code. And as Max pointed out in his OP, that only applies to a tiny fraction of our users, or even our developers. If you want to use them, turn the knob. Not only do I want to use them, I do use use profiled libraries. All those changes to libm that I've submitted over the years have been run through the profile. I'm glad that you find them useful. How does changing the default affect your ability to do that? More importantly, we are discussion freebsd-current. I would hope that the other developers profile their changes to system before committing. I'd be happy if our developers would stop breaking the build. PS: David was not complaining about fixing a 17 year old bug. He was stating that a single day of discussion changing a 17 year old practice seems a little too brief. If it's a good idea, it's a good idea no matter how many different ways we flog it. :) I think it is a horrible idea. Perhaps, we should discuss the technical issues before you start yet another bikeshed (see your recent posts concerning the ports repo for your hypocricy). Um, you did see the smiley, right? -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CVS removal from the base
On 12/02/2011 04:35, Adrian Chadd wrote: I think you're missing the point a little. The point is, you have to keep in mind how comfortable people feel about things, and progress sometimes makes people uncomfortable. I think you should leave these changes bake for a while and let people get comfortable with the changing status quo. The fact that we have so many people who are radically change-averse, no matter how rational the change; is a bug, not a feature. This particular bug is complicated dramatically by the fact that the majority view seems to lean heavily towards If I use it, it must be the default and/or in the base rather than seeing ports as part of the overall operating SYSTEM. Doug -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CVS removal from the base
On 12/3/2011 5:03 AM, sth...@nethelp.no wrote: The fact that we have so many people who are radically change-averse, no matter how rational the change; is a bug, not a feature. This particular bug is complicated dramatically by the fact that the majority view seems to lean heavily towards If I use it, it must be the default and/or in the base rather than seeing ports as part of the overall operating SYSTEM. I don't think of myself as change-averse. I've been using FreeBSD since 1996, and there have been lots of changes since that time. But two of the most important reasons I still use FreeBSD are: - Stability: Both in the sense of stays up basically forever, and in the sense of changes to interfaces and commands are carefully thought through and not applied indiscriminately. For instance, I like very much the fact that the ifconfig command can configure VLANs etc - while Linux has introduced new commands to do this. Agreed. - The base system is a *system* and comes with most of what I need, for instance tcpdump and BIND. For me the fact that I don't need to install lots of packages to have a usable system is a *good* thing. So 2 things here that I really wish people would think about. 1. If you're using *any* ports/packages then you're already participating in the larger operating *system* that I described, so installing a few more won't hurt. (Seriously, it won't.) 2. In (the very few) areas where integration of 3rd party apps into the base makes sense, no problem. But at this point the fact that a lot of 3rd party stuff is changing more rapidly than it used to, and often in incompatible ways and/or at incompatible schedules with our release process, means that we have to re-think how we do this. You mentioned BIND, which is a great example of 2. above. I'll have more to say about this soon, but my plan is to remove it from the base for 10.x because the current situation is unmanageable. The FOSS world has changed a lot in the last 20 years, and decisions that were made in the early days, while appropriate at the time, need to be reexamined. I use CVS (or rather csup) to keep the base system up to date. The point has been made before, but you do realize that cvs and csup are 2 completely different things, and that noone is recommending removal of csup from the base, right? Doug -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CVS removal from the base
On 12/3/2011 1:21 AM, Roman Kurakin wrote: Doug Barton wrote: [...] The fact that we have so many people who are radically change-averse, no matter how rational the change; is a bug, not a feature. This particular bug is complicated dramatically by the fact that the majority view seems to lean heavily towards If I use it, it must be the default and/or in the base rather than seeing ports as part of the overall operating SYSTEM. You are right in general, except one small factor. We are talking about bootstrap. You realize that you just 100% demonstrated the truth of what I wrote above, right? :) CVS is used by many as the one of the ways to get the sources to the freshly installed system to recompile to the last available source. It will become inconvenient to do it through the process of installing some ports for that. Especially if corresponding ports would require some other ports as dependences. I want to ask some serious questions here, because I genuinely want to understand your thought process. 1. Do you install *any* ports/packages on a new system before you update the source? 2. If so, why is installing one more unthinkable? 3. Why is it a problem if the port/package you need to install in the early stages has dependencies? Thanks, Doug -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CVS removal from the base
On 12/4/2011 12:19 PM, Julian Elischer wrote: I propose we create a companion directory to src in SVN and cal it sysports it uses the ports infrastructure in organization (though may be more hierarchical) but is populated with items that have come out of the 'src' tree. it is shipped along with src and revisioned WITH src. basically a privileged set of primary packages. both ports and src maintainers have access to them and they are tested as part of the release engineering process. Julian, You've proposed this before, and the more I've thought about it the more I like it. :) In fact, the other day a bunch of us in #bsdports were kicking it around and the idea was generally well received. (I think we slightly preferred the category system, but that's an implementation detail.) My (personal) plan is to start pushing for this after the 9.0-RELEASE, and after the ports repo svn conversion. That's one of the reasons that I want to start socializing the idea now. In regards to having this new category be supported as part of the release process, we've already received tentative support from the release engineering team for the idea of having a small number of critical packages on the install medium and offered to the user as options at install time. So the seeds have been planted for this idea, and I'm hoping to see it grow in the coming months. Doug -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
PORTS_MODULES
Howdy, This is an FYI to let people know about a really nice feature for those that have ports installed which include kernel modules. You can place a list in /etc/src.conf like this: PORTS_MODULES= emulators/virtualbox-ose-kmod sysutils/fusefs-kmod x11/nvidia-driver which will cause those modules to be built and installed with all the proper matching stuff at the same time as buildkernel and installkernel. This feature has existed for a while, but has had issues. Thanks to a team effort it's a lot more robust now, and ready for prime time (in HEAD, and the -STABLE branches for now, soon to be in 9.1-RELEASE). Enjoy, Doug -- This .signature sanitized for your protection ___ 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: PORTS_MODULES fix
On 06/09/2012 16:51, Doug Barton wrote: Ok, never mind the last one ... this patch I've actually tested. :) Committed to HEAD and MFC'ed. Thanks everyone for the feedback and help. Doug -- This .signature sanitized for your protection ___ 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: mountd starts to early when exporting fs marked as late (patch included)
On 06/24/2012 16:07, Steven Hartland wrote: We added some new mount points recently and on reboot they failed to come up after investigating we found that mountd runs too early in the boot process to be able export filesystems that are marked as late in /etc/fstab. Our fix was simply to mark mountd as requiring mountlate and all was well. I can't think of any reason why this would cause problems so would like the patch to be considered. The PR has all the details and the patch. http://www.freebsd.org/cgi/query-pr.cgi?pr=169373 I re-routed that PR to freebsd-rc@. -- This .signature sanitized for your protection ___ 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: [HEADS-UP] BSD sort is the default sort in -CURRENT
On 06/26/2012 11:04 PM, Gabor Kovesdan wrote: Hi Folks, as I announced before, the default sort in -CURRENT has been changed to BSD sort. Has this been performance tested vs. the old one? If so, where are the results? Since the import, the reported minor bugs have been fixed and BSD sort has passed the portbuild test. If you encounter any problems or incompatibility with the old GNU version, please report. Has this been thoroughly regression-tested against the old version, option by option? Doug ___ 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: [HEADS-UP] BSD sort is the default sort in -CURRENT
On 06/26/2012 11:48 PM, Oleg Moskalenko wrote: -Original Message- From: Doug Barton [mailto:do...@freebsd.org] Sent: Tuesday, June 26, 2012 11:18 PM To: Gabor Kovesdan Cc: FreeBSD Current; Oleg Moskalenko Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT On 06/26/2012 11:04 PM, Gabor Kovesdan wrote: Hi Folks, as I announced before, the default sort in -CURRENT has been changed to BSD sort. Has this been performance tested vs. the old one? If so, where are the results? Of course it was performance-tested. Great, can you post the results somewhere? I understand what you're saying below that there are situations where worse performance may need explanation, but it would be helpful if we had the data to look at. As this is a totally different program with different algorithms, it has totally different performance profile on different tests, comparing to the old sort. In the default compilation mode (single thread sort) the performance is on the same level as the old sort (sometimes faster, sometimes slower). The new sort is often significantly faster in numeric sort tests. In experimental multi-threading mode, the new sort is much faster than the old sort on multi-CPU systems. This sounds encouraging. Is there a knob to enable the threaded build? The sort speed comparison is not actually fair because the old sort cuts some corners and has a number of bugs. Understood, but the existing sort is what we're changing away from, so that's what we have to test against. What we don't want is a situation where we are switching to the new sort by default without understanding what the tradeoffs are. (IOW, we don't want a repeat of the situation with grep.) The concrete figures do not have much sense because you change the sort file and you get a totally different performance ratio. I'm assuming that you'd run the performance tests on various different input files, and report the different results. Has this been thoroughly regression-tested against the old version, option by option? Of course we have the regression tests. We have an overnight test that runs through probably 17 millions various sort option combinations. This sounds great, but ... But we actually had to compare the new sort against a fresh GNU sort implementation (version 8.15), because the old BSD GNU sort is very buggy and testing against the old GNU sort has no sense. ... this not so much. The existing sort is what people have now, and what they rely on, particularly for scripts. Comparing apples to oranges doesn't help us understand how things are going to be different with the new version. Doug ___ 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: [HEADS-UP] BSD sort is the default sort in -CURRENT
On 06/27/2012 02:09 AM, Oleg Moskalenko wrote: Doug, I'll post some performance figures, probably tomorrow. That's great, thanks. But I do not agree with you that we have to reproduce the old sort bugs. It makes no sense and I am not going to do that. Absolutely not. That isn't what I said. What I asked is for you to *test* the existing sort vs. the new one, and to report where the behavior is different. That's a very basic part of any sort of replace a core utility project such as this one. If some old scripts are relying on buggy behavior (and I hope they are not) then the old scripts must be fixed. Period. With respect, that's not your decision (or mine for that matter). We first need the data, then as a project we decide how many old bugs we want to be compatible with, if any. The system cannot grow replicating the old bugs. And the project cannot grow if we lose users due to gratuitous differences in core utilities. All system scripts that I've seen are using pretty basic sort features. The system scripts are only a tiny fraction of how FreeBSD users use sort. In the basic area, the old sort and the new sort are 100% compatible. The incompatibilities are in more complex areas (numeric sorts and unusual key-based sorts). So here's one to add to your regression test. I use the following to sort IPv4 addresses in a list: sort -n -t . -k 1,1 -k 2,2 -k 3,3 -k 4,4 When used with GNU sort that will sort a list of IPv4 addresses into a humanly-recognizable numeric order. Please ensure that this works the same way with the new sort. I am actually tested the new sort against the old GNU sort. There are some incompatibilities. All of them are due to the bugs of the old GNU sort. Please list all of those explicitly. The new BSD sort program is compatible with the new GNU sort, a much cleaner program than the old GNU sort. That's good, but not really relevant to the users of what we have in the base now. I realize that these questions may seem discouraging, but they need to be answered. It would have been nice if Gabor had posted a we think we're ready to make the new sort the default, any last concerns? message, but deal with where we are at and move forward. thanks, Doug ___ 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: [HEADS-UP] BSD sort is the default sort in -CURRENT
On 06/27/2012 03:02 AM, Daniel Gerzo wrote: On 27.06.2012 10:43, Doug Barton wrote: On 06/27/2012 02:09 AM, Oleg Moskalenko wrote: Doug, I'll post some performance figures, probably tomorrow. That's great, thanks. But I do not agree with you that we have to reproduce the old sort bugs. It makes no sense and I am not going to do that. Absolutely not. That isn't what I said. What I asked is for you to *test* the existing sort vs. the new one, and to report where the behavior is different. That's a very basic part of any sort of replace a core utility project such as this one. [ snip ] Doug, are you implying that if we were about to import a new version of GNU sort, you would be asking for the same data? If the compatibility with the existing version were so dramatically different as Oleg claims, then yes, that would be a basic element of the replacement project. I believe we do not make this kind of work with any vendor code that is being updated in the base; Au contraire, we frequently avoid updating the old versions of things we have in the base precisely because they are not bug-for-bug compatible with existing behaviors that we count on. I do not really understand why should Oleg or anyone else do this work when the bsdsort is compatible with a recent version of GNU sort. The first question is, where is it not compatible with the existing sort that's already in the base. The second question is, how well does it perform vs. the existing sort. I think those are perfectly reasonable questions to ask, and frankly they should have been answered before the switch was made. We already went through this with BSD grep, I hope we can avoid a repeat. Doug ___ 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: [HEADS-UP] BSD sort is the default sort in -CURRENT
On 06/27/2012 07:30 AM, Pedro Giffuni wrote: --- Mer 27/6/12, Doug Barton do...@freebsd.org ha scritto: ... I believe we do not make this kind of work with any vendor code that is being updated in the base; Au contraire, we frequently avoid updating the old versions of things we have in the base precisely because they are not bug-for-bug compatible with existing behaviors that we count on. Really?? I guess you are speaking for bind, Nope. because the idea behind updating and piece of software is precisely shaking bugs. Nope. I would think only the maintainer of the package has the authority to make any request in the lines of being bug-for-bug compatible You have a seriously wrong idea of maintainer. The community owns the software, it's up to the community to decide how it should work. Historically we have looked at the maintainer as the person who volunteers to take care of code, not the person who has the exclusive lock on it. and in the case of GNU sort and GNU grep they are both unmaintained and replacements are welcome. Actually both are maintained, it's just that we don't want to import the new GNU versions. And yes, having BSD versions of these core tools is a nice goal, but it's not one we should pursue for its own sake. Please let's stop being an obstacle towards people bringing real progress to FreeBSD! In the case of grep, there were a fairly large number of people who agreed that a BSD grep with orders of magnitude worse performance than the previous version was not something we, as a project, were willing to stomach. Sufficiently such that the default was switched back. So can we please stop pretending that it's me who's the problem, and start looking at these things rationally? Doug ___ 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: [HEADS-UP] BSD sort is the default sort in -CURRENT
I officially withdraw from the discussion. I hope it all works out well. ___ 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: [HEADS-UP] BSD sort is the default sort in -CURRENT
On 06/29/2012 01:50 PM, Oleg Moskalenko wrote: 5) NBSD adds several of its own new proprietary options: --mergesort --qsort --heapsort --radixsort --nthreads=... (multi-threaded build only) Oleg, First, thank you very much for providing both the performance numbers, and the breakdown in the differences in command line options. Everything looks great, my only concern is the above. Are there similar/identical options in NGNU that correspond to the options above? If so, I would be hesitant to add new names for them because it hurts portability between platforms. If these are totally new features then my assumption is that you have clearly marked them as non-portable in the man page? Once again, I really appreciate you addressing my concerns, and your hard work on this project. Doug ___ 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: [HEADS-UP] BSD sort is the default sort in -CURRENT
Sounds great, thanks again! Doug On 06/29/2012 02:20 PM, Oleg Moskalenko wrote: Doug, --nthreads option corresponds to --parallel option of NGNU and it will be renamed. The other four proprietary options will be marked as non-portable in the man page. After nthreads==parallel renaming, NBSD will support all NGNU options. Thank you for the suggestion. Oleg -Original Message- From: Doug Barton [mailto:do...@freebsd.org] Sent: Friday, June 29, 2012 2:02 PM To: Oleg Moskalenko Cc: FreeBSD Current Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT On 06/29/2012 01:50 PM, Oleg Moskalenko wrote: 5) NBSD adds several of its own new proprietary options: --mergesort --qsort --heapsort --radixsort --nthreads=... (multi-threaded build only) Oleg, First, thank you very much for providing both the performance numbers, and the breakdown in the differences in command line options. Everything looks great, my only concern is the above. Are there similar/identical options in NGNU that correspond to the options above? If so, I would be hesitant to add new names for them because it hurts portability between platforms. If these are totally new features then my assumption is that you have clearly marked them as non-portable in the man page? Once again, I really appreciate you addressing my concerns, and your hard work on this project. Doug ___ 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
