mount_newnfs & mount_nullfs problem.
Dear all, In short: If I export the filesystem /export/homes, and mount it through nfsv4 on a fbsd8-stable box in the folder /mnt, and then use mount_nullfs /mnt/ /path1/path2/path3, then I have the following-wrong behaviour. If I use vi /path1/path2/path3/mamalos/newfile to write a file, the file is saved in /path1/path2, instead (!!?!). Which is on my local filesystem tree. If I echo "mytestfile" > /path1/path2/path3/mamalos/one, then the file is correctly written in /path1/path2/path3/mamalos/one. In my jail environment, I use a similar approach to that of freebsd-handbook for application jails (paragraph 15.6). So in my setup, mount command shows: solaris:/export/homes on /mnt (newnfs) /jails/j/mroot on /jails/j/postfix (nullfs, local, read-only) /jails/s/postfix on /jails/j/postfix/s (nullfs, local, read-only) /jails/t/postfix on /jails/j/postfix/t (nullfs, local) /mnt on /jails/j/postfix/t/home (nullfs) where we see my imported filesystem, the path where my postfix jail starts (/jails/j/postfix) along with two other filesystems mounted on it (/jails/j/postfix/s and /jails/j/postfix/t). On top of the latter's folder "home" I mount /mnt. If I jexec to that jail, and try to create a file using vi, then vi /home/mamalos/myfile is written in /jails/t/postfix (which is the same as /jails/j/postfix/t) What I suspect is that there must be a problem with nfs4 root-directory (which is two subfolders deep -> /export/homes) and mount_nullfs. The thing is that information is finally stored in my local filesystem instead of the imported one, which is very strange... I will look to it more thoroughly, so as to provide more feedback about the issue. Hopefully, someone with more knowledge on the source code will find an answer. FBSD-box: # uname -a FreeBSD fbsd 8.0-STABLE FreeBSD 8.0-STABLE #2: Fri Feb 19 19:30:00 EET 2010 r...@filesrv.ee.auth.gr:/usr/obj/usr/src/sys/MYKERNEL amd64 # mount_newnfs -o nfsv4,rw solaris:/export/homes /mnt/ OpenSolaris: # uname -a SunOS opensolaris 5.11 snv_111b i86pc i386 i86pc Solaris # share -F nfs -o sec=sys,rw,ro...@192.168.100.12 /export/homes 192.168.100.12 where 192.168.100.12 is fbsd-box's IP. Thank you all. -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mbuf leakage with nfs
On 28-2-2010 18:55, Gerrit Kühn wrote: On Sun, 28 Feb 2010 12:21:28 + "Robert N. M. Watson" wrote about Re: mbuf leakage with nfs/zfs? : RNMW> It's almost certainly one or a small number of very specific RPCs RNMW> that are triggering it -- maybe OpenBSD does an extra lookup, or RNMW> stat, or something, on a name that may not exist anymore, or does it RNMW> sooner than the other clients. Hard to say, other than to wave hands RNMW> at the possibilities. RNMW> RNMW> And it may well be we're looking at two bugs: Danny may see one bug, RNMW> perhaps triggered by a race condition, but it may be different from RNMW> the OpenBSD client-triggered bug (to be clear: it's definitely a RNMW> FreeBSD bug, although we might only see it when an OpenBSD client is RNMW> used because perhaps OpenBSD also has a bug or feature). In my case it is the Linux client causing the problems (cannot tell yet if it is only with udp, but I would think so). If I understand Daniel correctly his latest testes were performed with FreeBSD client and udp. So it may very well be a generel issue with udp?! Would this help narrowing down the problem? I'm off 'till thursday. At which time I'm willing to run more tests. Got plenty of boxes here. Both FreeBSD and Linux. And otherwise will boot more in VirtualBox. --WjW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related)
Broadcom 5714 5715 - no problems. 2010/2/22 Denis Lamanov : > Yes, PCIX BCM5704 > FreeBSD vpn2 8.0-STABLE FreeBSD 8.0-STABLE #1 r204028: Thu Feb 18 08:29:42 > EET 2010 ad...@vpn2:/usr/obj/usr/src/sys/GENERIC i386 > > 2010/2/22 Pyun YongHyeon > >> On Mon, Feb 22, 2010 at 03:17:17PM +0200, Denis Lamanov wrote: >> > I see same trouble (lost packets after 4 day uptime and reboot) :( >> > >> > dev.bge.0.stats.rx.FCSErrors: 18 >> > >> >> You also have PCIX BCM5704 controller? What FreeBSD version do you >> use? >> >> > 2010/2/19 Slawa Olhovchenkov >> > >> > > On Fri, Feb 19, 2010 at 12:06:47PM -0800, Pyun YongHyeon wrote: >> > > >> > > > >> > > > > dev.bge.1.stats.rx.Fragments: 1 >> > > > >> > > > You received a frame that is less than 64 bytes with a bad FCS. >> > > > >> > > > > dev.bge.1.stats.rx.UcastPkts: 2956515 >> > > > > dev.bge.1.stats.rx.MulticastPkts: 0 >> > > > > dev.bge.1.stats.rx.FCSErrors: 18 >> > > > >> > > > You have a lot of FCS errors here. >> > > > Please double check cabling. If the statistics counter is right, >> > > > sender is guilty or you have bad cabling issues here. >> > > >> > > 1. lost packets much more 18. I think hundreds, or thousands. >> > > 2. packets lost on both (bge0 & bge1) interfaces >> > > 3. packets don't lost on sources at Aug'09 >> > > ___ >> > > freebsd-stable@freebsd.org mailing list >> > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> > > To unsubscribe, send any mail to " >> freebsd-stable-unsubscr...@freebsd.org" >> > > >> > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mbuf leakage with nfs
On Mon, 01 Mar 2010 12:52:32 +0100 Willem Jan Withagen wrote about Re: mbuf leakage with nfs: WJW> > In my case it is the Linux client causing the problems (cannot tell WJW> > yet if it is only with udp, but I would think so). If I understand WJW> > Daniel correctly his latest testes were performed with FreeBSD WJW> > client and udp. So it may very well be a generel issue with udp?! WJW> > Would this help narrowing down the problem? WJW> WJW> I'm off 'till thursday. WJW> At which time I'm willing to run more tests. Got plenty of boxes here. WJW> Both FreeBSD and Linux. And otherwise will boot more in VirtualBox. I finally too an axe and restarted nfsd without "-u". Now my mbuf usage is flat as it should be. I guess some people using computers with udp mounts will complian, but this can be fixed easily by converting their connections to tcp. However, I am still interested in having the issue fixed, so I will be following the thread and contribute if possible. cu Gerrit ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ipfw & natd with recent MFC of firewall_coscripts functionality
Hi. Similar problem. Now updated to 7.3-PRERELEASE. rc script natd said he did not know parameter quietstart. Now migrate to use kernel nat. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS and sh(1) panic: spin lock [lock addr] (smp rendezvous) held by [sh(1) proc tid] too long
On Sat, Feb 20, 2010 at 4:19 PM, Attilio Rao wrote: > 2010/1/27 Brandon Gooch : >> The machine, a Dell Optiplex 755, has been locking up recently. The >> situation usually occurs while using VirtualBox (running a 64-bit >> Windows 7 instance) and doing anything else in another xterm (such as >> rebuilding a port). I've been unable to reliably reproduce it (I'm in >> an X session and the machine will not panic "properly"). >> >> However, while rebuilding Xorg today at ttyv0 and runnning >> VBoxHeadless on ttyv1, I managed to trigger what I believe is the >> lockup. >> >> I've attached a textdump in hopes that someone may be able to take a >> look and provide clues or instruction on debugging this. > > I think that jhb@ saw a similar problem while working on nVidia driver > or the like. > Not sure if he made any progress to debug this. > The situation has improved slightly, although attempting to run two VirtualBox guests at the same time inevitably leads to a lock-up. I've just taken to running one at a time. Not ideal, but until more debugging can be done, it's the only option I have. I ran into this using nvidia and radeon both. I can't really find a pattern, but I do see it when Windows is trying to draw a new window, or dim the screen when UAC kicks in... BTW, anyone know how to get a good dump when running Xorg? I'm not sure I've ever been able to, even when I panic on something non related to X or video drivers. -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.0 on new hardware and a few errors, should I be worried?
On Saturday 27 February 2010 8:28:48 pm Dan Naumov wrote: > Hello > > I've very recently finished installing 8.0-RELEASE on some new > hardware and I noticed a few error messages that make me a bit uneasy. > This is a snip from my dmesg: > > -- > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of fee0, 1000 (3) failed > acpi0: reservation of 0, a (3) failed > acpi0: reservation of 10, bf60 (3) failed > -- > > What do these mean and should I worry about it? The full DMESG can be > viewed here: http://jago.pp.fi/temp/dmesg.txt You can ignore them. FreeBSD creates two psuedo-devices on x86 called apic0 and ram0. Their sole job is to reserve the memory ranges used by APIC devices and system RAM to prevent those address ranges being reused by anything else (such as PCI BARs). Many systems also reserve those ranges as a system resource via ACPI (or PnPBIOS for the non-ACPI case). What is happening is that the ACPI system resource driver isn't able to reserve these ranges because they are already claimed by apic0 and ram0. The important point is that some device claims them. It doesn't really matter which one does. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
stable-8 regression: time stands still
Hi, After upgrading my 7.2-PRERELEASE system to 8-stable I encountered some very strange problems, most obvious: - startup would hang on starting devd, only continuing after a ^C - reboot would hang, but reboot -q would work. - nfs clients would report strange locking problems. Now I've found that probably the real problem here is that NO TIME IS PASSING (!!). Successively calling 'date' will allways give me the exact same time to the second. A 'sleep 1' will hang indefinetely. The BIOS is OK. After (and only after) a reboot, time will be updated to the time of reboot, but stay there forever after. Before I go back to 7.2 (tested there are still no problems there with a livecd) maybe someone want to shed some light on this. I've attached dmesg.boot. cheers, Ruben Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-RELEASE-p2 #6: Sun Feb 21 15:45:07 CET 2010 r...@malenfant.lan:/usr/obj/usr/src/sys/MALENFANT module_register: module g_label already exists! Module g_label failed to register: 17 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5200+ (2700.11-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x60fb2 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 1958805504 (1868 MB) ACPI APIC Table: <090908 APIC1020> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <090908 RSDT1020> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of ffb8, 8 (3) failed acpi0: reservation of fff0, 10 (3) failed acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 77f0 (3) failed ACPI HPET table warning: Sequence is non-zero (2) Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xc000-0xc0ff mem 0xf000-0xf7ff,0xfe9f-0xfe9f,0xfe80-0xfe8f irq 18 at device 5.0 on pci1 pcib2: at device 5.0 on pci0 pci2: on pcib2 re0: port 0xd800-0xd8ff mem 0xfeaff000-0xfeaf irq 17 at device 0.0 on pci2 re0: Using 1 MSI messages re0: Chip rev. 0x3400 re0: MAC rev. 0x miibus0: on re0 rlphy0: PHY 1 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re0: Ethernet address: 00:1f:e2:6a:ac:35 re0: [FILTER] atapci0: port 0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f mem 0xfe7ff800-0xfe7ffbff irq 22 at device 18.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI v1.10 controller with 4 3Gbps ports, PM supported ata2: on atapci0 ata2: port is not ready (timeout 0ms) tfd = 01d0 ata2: software reset clear timeout ata2: [ITHREAD] ata3: on atapci0 ata3: port is not ready (timeout 0ms) tfd = 01d0 ata3: software reset clear timeout ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ohci0: mem 0xfe7fe000-0xfe7fefff irq 16 at device 19.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0xfe7fd000-0xfe7fdfff irq 17 at device 19.1 on pci0 ohci1: [ITHREAD] usbus1: on ohci1 ohci2: mem 0xfe7fc000-0xfe7fcfff irq 18 at device 19.2 on pci0 ohci2: [ITHREAD] usbus2: on ohci2 ohci3: mem 0xfe7fb000-0xfe7fbfff irq 17 at device 19.3 on pci0 ohci3: [ITHREAD] usbus3: on ohci3 ohci4: mem 0xfe7fa000-0xfe7fafff irq 18 at device 19.4 on pci0 ohci4: [ITHREAD] usbus4: on ohci4 ehci0: mem 0xfe7ff000-0xfe7ff0ff irq 19 at device 19.5 on pci0 ehci0: [ITHREAD] usbus5: EHCI version 1.0 usbus5: on ehci0 pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] hdac0: mem 0xfe7f4000-0xfe7f7fff irq 16 at device 20.2 on pci0 hdac0: HDA Driver Revision: 20090624_0136 hdac0: [ITHREAD] isab0: at device 20.3 on pci0 isa0: on isab0 pcib3: at device 20.4 on pci0 pci3: on pcib3 ath0: mem 0xfebf-0xfebf irq 20 at device 0.0 on pci3 ath0: [ITHREAD] ath0: AR2413 mac 7.9 RF2413 phy 4.5 rl0: port 0xe800-0xe8ff mem 0xfebefc00-0xfebefcff irq 21 at device 1.0 on pci3 miibus1: on rl0 rlphy1: PHY 0 on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:0e:2e:55:b1:9b rl0: [ITHREAD] acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags
Re: stable-8 regression: time stands still
Forgot to mention. The kernel is GENERIC + IPFIREWALL* and IPDIVERT options; nothing else. I also build a RELEASE_8_0 kernel and it shows the same problems, so it's not just a recent -stable issue. On Mon, Mar 01, 2010 at 09:34:50PM +0100, Ruben de Groot typed: > > Hi, > > After upgrading my 7.2-PRERELEASE system to 8-stable I encountered > some very strange problems, most obvious: > > - startup would hang on starting devd, only continuing after a ^C > > - reboot would hang, but reboot -q would work. > > - nfs clients would report strange locking problems. > > Now I've found that probably the real problem here is that NO TIME > IS PASSING (!!). Successively calling 'date' will allways give me > the exact same time to the second. > A 'sleep 1' will hang indefinetely. > > > The BIOS is OK. After (and only after) a reboot, time will be updated to > the time of reboot, but stay there forever after. > > Before I go back to 7.2 (tested there are still no problems > there with a livecd) maybe someone want to shed some light on this. > I've attached dmesg.boot. > > cheers, > Ruben > > Copyright (c) 1992-2009 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 8.0-RELEASE-p2 #6: Sun Feb 21 15:45:07 CET 2010 > r...@malenfant.lan:/usr/obj/usr/src/sys/MALENFANT > module_register: module g_label already exists! > Module g_label failed to register: 17 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5200+ (2700.11-MHz 686-class > CPU) > Origin = "AuthenticAMD" Id = 0x60fb2 Stepping = 2 > > Features=0x178bfbff > Features2=0x2001 > AMD Features=0xea500800 > AMD Features2=0x11f > TSC: P-state invariant > real memory = 2147483648 (2048 MB) > avail memory = 1958805504 (1868 MB) > ACPI APIC Table: <090908 APIC1020> > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > acpi0: <090908 RSDT1020> on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of ffb8, 8 (3) failed > acpi0: reservation of fff0, 10 (3) failed > acpi0: reservation of 0, a (3) failed > acpi0: reservation of 10, 77f0 (3) failed > ACPI HPET table warning: Sequence is non-zero (2) > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > acpi_hpet0: iomem 0xfed0-0xfed003ff on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 900 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > vgapci0: port 0xc000-0xc0ff mem > 0xf000-0xf7ff,0xfe9f-0xfe9f,0xfe80-0xfe8f irq 18 at > device 5.0 on pci1 > pcib2: at device 5.0 on pci0 > pci2: on pcib2 > re0: port 0xd800-0xd8ff mem > 0xfeaff000-0xfeaf irq 17 at device 0.0 on pci2 > re0: Using 1 MSI messages > re0: Chip rev. 0x3400 > re0: MAC rev. 0x > miibus0: on re0 > rlphy0: PHY 1 on miibus0 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > re0: Ethernet address: 00:1f:e2:6a:ac:35 > re0: [FILTER] > atapci0: port > 0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f mem > 0xfe7ff800-0xfe7ffbff irq 22 at device 18.0 on pci0 > atapci0: [ITHREAD] > atapci0: AHCI v1.10 controller with 4 3Gbps ports, PM supported > ata2: on atapci0 > ata2: port is not ready (timeout 0ms) tfd = 01d0 > ata2: software reset clear timeout > ata2: [ITHREAD] > ata3: on atapci0 > ata3: port is not ready (timeout 0ms) tfd = 01d0 > ata3: software reset clear timeout > ata3: [ITHREAD] > ata4: on atapci0 > ata4: [ITHREAD] > ata5: on atapci0 > ata5: [ITHREAD] > ohci0: mem 0xfe7fe000-0xfe7fefff irq 16 at > device 19.0 on pci0 > ohci0: [ITHREAD] > usbus0: on ohci0 > ohci1: mem 0xfe7fd000-0xfe7fdfff irq 17 at > device 19.1 on pci0 > ohci1: [ITHREAD] > usbus1: on ohci1 > ohci2: mem 0xfe7fc000-0xfe7fcfff irq 18 at > device 19.2 on pci0 > ohci2: [ITHREAD] > usbus2: on ohci2 > ohci3: mem 0xfe7fb000-0xfe7fbfff irq 17 at > device 19.3 on pci0 > ohci3: [ITHREAD] > usbus3: on ohci3 > ohci4: mem 0xfe7fa000-0xfe7fafff irq 18 at > device 19.4 on pci0 > ohci4: [ITHREAD] > usbus4: on ohci4 > ehci0: mem 0xfe7ff000-0xfe7ff0ff irq 19 > at device 19.5 on pci0 > ehci0: [ITHREAD] > usbus5: EHCI version 1.0 > usbus5: on ehci0 > pci0: at device 20.0 (no driver attached) > atapci1: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 > ata0: on atapci1 > ata0: [ITHREAD] > hdac0: mem 0xfe7f4000-0xfe7f7fff > irq 16 at device 20.2 on pci0 > hdac0: HDA Driver Revision: 20090624_0136 > hdac0: [ITHREAD] > isab0: at device 20.3 on pci0
Re: ipfw & natd with recent MFC of firewall_coscripts functionality
On Mon, Mar 01, 2010 at 08:24:54PM +0300, hizel wrote: > Hi. Similar problem. Now updated to 7.3-PRERELEASE. rc script natd said he > did not know parameter quietstart. Now migrate to use kernel nat. I was able to confirm that simply changing "quietstart" and "quietstop" in the /etc/rc.d/ipfw script to "start" and "stop", respectively, fixes the problem. > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- Bob Willcox The shifts of Fortune test the reliability of friends. b...@immure.com-- Marcus Tullius Cicero Austin, TX ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ipfw & natd with recent MFC of firewall_coscripts functionality
On Mon, Mar 01, 2010 at 03:25:54PM -0600, Bob Willcox wrote: > On Mon, Mar 01, 2010 at 08:24:54PM +0300, hizel wrote: > > Hi. Similar problem. Now updated to 7.3-PRERELEASE. rc script natd said he > > did not know parameter quietstart. Now migrate to use kernel nat. > > I was able to confirm that simply changing "quietstart" and "quietstop" in the > /etc/rc.d/ipfw script to "start" and "stop", respectively, fixes the problem. Adding committer + submitter + those who reviewed the change/commit to the CC list: http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/rc.d/ipfw -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: stable-8 regression: time stands still
Hi Ruben, Some shots in the dark. - Do you run powerd? Try to disable it. - What is your output of 'sysctl kern.timecounter'? Maybe try setting another timecounter. - Maybe you shouldn't name your computer 'ill child' in french. :-) Ronald. On Mon, 01 Mar 2010 22:14:41 +0100, Ruben de Groot wrote: Forgot to mention. The kernel is GENERIC + IPFIREWALL* and IPDIVERT options; nothing else. I also build a RELEASE_8_0 kernel and it shows the same problems, so it's not just a recent -stable issue. On Mon, Mar 01, 2010 at 09:34:50PM +0100, Ruben de Groot typed: Hi, After upgrading my 7.2-PRERELEASE system to 8-stable I encountered some very strange problems, most obvious: - startup would hang on starting devd, only continuing after a ^C - reboot would hang, but reboot -q would work. - nfs clients would report strange locking problems. Now I've found that probably the real problem here is that NO TIME IS PASSING (!!). Successively calling 'date' will allways give me the exact same time to the second. A 'sleep 1' will hang indefinetely. The BIOS is OK. After (and only after) a reboot, time will be updated to the time of reboot, but stay there forever after. Before I go back to 7.2 (tested there are still no problems there with a livecd) maybe someone want to shed some light on this. I've attached dmesg.boot. cheers, Ruben Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-RELEASE-p2 #6: Sun Feb 21 15:45:07 CET 2010 r...@malenfant.lan:/usr/obj/usr/src/sys/MALENFANT module_register: module g_label already exists! Module g_label failed to register: 17 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5200+ (2700.11-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x60fb2 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 1958805504 (1868 MB) ACPI APIC Table: <090908 APIC1020> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <090908 RSDT1020> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of ffb8, 8 (3) failed acpi0: reservation of fff0, 10 (3) failed acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 77f0 (3) failed ACPI HPET table warning: Sequence is non-zero (2) Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xc000-0xc0ff mem 0xf000-0xf7ff,0xfe9f-0xfe9f,0xfe80-0xfe8f irq 18 at device 5.0 on pci1 pcib2: at device 5.0 on pci0 pci2: on pcib2 re0: port 0xd800-0xd8ff mem 0xfeaff000-0xfeaf irq 17 at device 0.0 on pci2 re0: Using 1 MSI messages re0: Chip rev. 0x3400 re0: MAC rev. 0x miibus0: on re0 rlphy0: PHY 1 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re0: Ethernet address: 00:1f:e2:6a:ac:35 re0: [FILTER] atapci0: port 0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f mem 0xfe7ff800-0xfe7ffbff irq 22 at device 18.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI v1.10 controller with 4 3Gbps ports, PM supported ata2: on atapci0 ata2: port is not ready (timeout 0ms) tfd = 01d0 ata2: software reset clear timeout ata2: [ITHREAD] ata3: on atapci0 ata3: port is not ready (timeout 0ms) tfd = 01d0 ata3: software reset clear timeout ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ohci0: mem 0xfe7fe000-0xfe7fefff irq 16 at device 19.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0xfe7fd000-0xfe7fdfff irq 17 at device 19.1 on pci0 ohci1: [ITHREAD] usbus1: on ohci1 ohci2: mem 0xfe7fc000-0xfe7fcfff irq 18 at device 19.2 on pci0 ohci2: [ITHREAD] usbus2: on ohci2 ohci3: mem 0xfe7fb000-0xfe7fbfff irq 17 at device 19.3 on pci0 ohci3: [ITHREAD] usbus3: on ohci3 ohci4: mem 0xfe7fa000-0xfe7fafff irq 18 at device 19.4 on pci0 ohci4: [ITHREAD] usbus4: on ohci4 ehci0: mem 0xfe7ff000-0xfe7ff0ff irq 19 at device 19.5 on pci0 ehci0: [ITHREAD] usbus5: EHCI version 1.0 usbus5: on ehci0 pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] hdac0: mem 0xfe7f4000-0xfe7f7fff irq 16 at device 20.2 on pci0 hdac0: HDA Driver
Re: mbuf leakage with nfs/zfs?
On Sat, 27 Feb 2010, Jeremy Chadwick wrote:
I concur.
Everything in my network is now on TCP, and there is no mbuf leakage.
I just don't get over the 5500 mark, no matter what I throw at it.
I do feel that TCP is not as well performing on a local net with Linux,
hence the choice for UDP. But TCP is workable as next best.
NFS; Rick Macklem would be a better choice, but as reported, he's MIA.
Not exactly MIA, but only able to read email from time to time at this
point. I don't know when I'll be able to do more than that.
So, it does sound like it is UDP specific. Robert mentioned one scenario,
which was an infrequently executed code path that is being tickled and it
has a missing m_freem().
One thing someone could try is switching to the experimental nfs server
("-e" on both mountd and nfsd) and see if the leak goes away. If it does
go away, it is almost certainly the above in the regular nfs server code.
If it doesn't go away, the problem is more likely in the krpc or the
generic udp code. (When I looked at svc_dg.c, I could only spot one
possible leak and you've already determined that patch doesn't help.
The other big difference when using udp on the FreeBSD8 krpc is the
reply cache code. I seem to recall it's an lru cache with a fixed upper
bound, but it might be broken and leaking.
If you change the server to set sp_rcache = NULL in the initialization
function in sys/nfsserver/nfs_srvkrpc.c, I think that disables the replay
cache. You wouldn't want to run this way in production, but it would
determine if the leak is in it.
Change the 3 lines in nfsrv_init() to:
nfsrv_pool->sp_rcache = NULL;
nfsrv_pool->sp_assign = NULL;
nfsrv_pool->sp_done = NULL;
and I think the krpc replay cache will be disabled.
Good luck with it and please report back if you get to try the above.
I'll get back to committing etc one of these days, rick
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Cannot write to nfsv4 share
On Sat, 27 Feb 2010, al...@ulgsm.ru wrote: try to mount /exp/distfiles ]>mount /exp/distfiles ]> try to write ]>touch /exp/distfiles/t touch: /exp/distfiles/t: Permission denied ls and read files ok. When writes fail for me, it's usually a uid, gid vs user/group name mapping problem. Does "ls -lg" report correctuser and group names? (If you see "nobody", it is usually the "domain" for nfsuserd not being set to the same thing. It should default to the domain part of "hostname", but can be overridden by the "-domain xx.yy" flag for nfsuserd.) If the user and group names look ok for "ls -lg", then it might be a name<-># mapping issue. When using AUTH_SYS, the numbers are in the authentication header and the names are in the open/create and they need to match up. (Also, the NFSv4 client normally specifies a group to be set, so it must be a group that the user is allowed to set it to. ie. a group in the user's group list on the client.) Looking at the packets via wireshark will show where the server is reporting the error and might hint at the problem. Good luck with it, rick ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[releng_8 tinderbox] failure on powerpc/powerpc
TB --- 2010-03-01 21:31:46 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-01 21:31:46 - starting RELENG_8 tinderbox run for powerpc/powerpc TB --- 2010-03-01 21:31:46 - cleaning the object tree TB --- 2010-03-01 21:31:59 - cvsupping the source tree TB --- 2010-03-01 21:31:59 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/powerpc/powerpc/supfile TB --- 2010-03-01 21:32:29 - building world TB --- 2010-03-01 21:32:29 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-01 21:32:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-01 21:32:29 - TARGET=powerpc TB --- 2010-03-01 21:32:29 - TARGET_ARCH=powerpc TB --- 2010-03-01 21:32:29 - TZ=UTC TB --- 2010-03-01 21:32:29 - __MAKE_CONF=/dev/null TB --- 2010-03-01 21:32:29 - cd /src TB --- 2010-03-01 21:32:29 - /usr/bin/make -B buildworld >>> World build started on Mon Mar 1 21:32:29 UTC 2010 >>> 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 Mon Mar 1 22:28:45 UTC 2010 TB --- 2010-03-01 22:28:45 - generating LINT kernel config TB --- 2010-03-01 22:28:45 - cd /src/sys/powerpc/conf TB --- 2010-03-01 22:28:45 - /usr/bin/make -B LINT TB --- 2010-03-01 22:28:45 - building LINT kernel TB --- 2010-03-01 22:28:45 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-01 22:28:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-01 22:28:45 - TARGET=powerpc TB --- 2010-03-01 22:28:45 - TARGET_ARCH=powerpc TB --- 2010-03-01 22:28:45 - TZ=UTC TB --- 2010-03-01 22:28:45 - __MAKE_CONF=/dev/null TB --- 2010-03-01 22:28:45 - cd /src TB --- 2010-03-01 22:28:45 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Mar 1 22:28:45 UTC 2010 >>> 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/cam/cam_queue.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/cam/cam_sim.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/cam/cam_xpt.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/cam/ata/ata_all.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fn
gptzfsboot dell r510 fails
Hi All, Dell r510 24GB RAM 8 disks in the following order 0-1 - 25gb ssd sas 2-7 - 136gb sas http://svn.freebsd.org/base/releng/8...@203057 which does not include http://svn.freebsd.org/viewvc/base?view=revision&revision=199714 so following http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ2 [/etc/src.conf: ZFS_LOADER_SUPPORT=true] which I've gotten to work on 500+ dell machines on the above fbsd version. [860,1435sc,1950,2950,2970,r710] So I've setup the zpools via the livefs as zroot (mirror) /dev/gpt/disk0 -> mfid2[p3] /dev/gpt/disk1 -> mfid3[p3] zmysql (raidz1) /dev/mfid[4567] cache /dev/mfid[01] I've selected the 3rd device in the perc h700 bios [mfid2] to be the 'bios boot device' which amazingly to me actually worked. During the boot I get to the standard ROOT MOUNT ERROR: set vfs.root.mountfrom.options=rw Loader variables: vfs.root.mountfrom=zfs:zroot vfs.root.mountfrom.options Manual root filesystem specification: . Is this setup even possible, or will I need to relocate the order of the disks ? For my next attempt, I'm going to try to move the ssds to slots 6,7 so the boot devices are '0,1' which I know should work. Failing that, I'll do hardware raid-1 on 0-1 and just a ZFS fs on them on top. -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 VP Apache Infrastructure; Member, Apache Software Foundation Committer,FreeBSD Foundation Consultant, P6M7G8 Inc. Sr. System Admin, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: gptzfsboot dell r510 fails
On 03/02/10 01:56, Philip M. Gollucci wrote: For my next attempt, I'm going to try to move the ssds to slots 6,7 so the boot devices are '0,1' which I know should work. This actually works. That leads me to believe that the vdev probes in zfsload.c are not quite right. Or its finding them incorrectly (too soon). -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 VP Apache Infrastructure; Member, Apache Software Foundation Committer,FreeBSD Foundation Consultant, P6M7G8 Inc. Sr. System Admin, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Fatal Trap with NAT and 8.0-STABLE
Hi guys.. I'm having trouble configuring NAT on a FreeBSD 8.0-STABLE. where the active pf or ipfw (ipfw add nat ...) I get a message "FATAL TRAP" (url of the image below) http://www.luizgustavo.pro.br/blog/wp-content/uploads/2010/03/nat_problem_8.png someone help me? i have one freebsd with specifications: [r...@goldengate] ~# uname -a FreeBSD goldengate.world-unix.com 8.0-STABLE FreeBSD 8.0-STABLE #0: Sun Feb 28 17:58:04 BRT 2010 r...@goldengate.world-unix.com:/usr/obj/usr/src/sys/WORLD-UNIX amd64 [r...@goldengate] ~# cat /usr/src/sys/amd64/conf/WORLD-UNIX include GENERIC ident SMP-WORLD_UNIX # To make an SMP kernel, the next line is needed options SMP # Symmetric MultiProcessor Kernel device pf device pflog device pfsync options DEVICE_POLLING device carp options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ options LIBALIAS options IPFIREWALL options IPFIREWALL_NAT options IPFIREWALL_FORWARD options IPFIREWALL_DEFAULT_TO_ACCEPT options DUMMYNET options HZ=1000 # VIMAGE options VIMAGE nooptions SCTP thanks ! -- Luiz Gustavo Costa (Powered by BSD) *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ mundoUnix - Consultoria em Software Livre http://www.mundounix.com.br ICQ: 2890831 / MSN: cont...@mundounix.com.br Blog: http://www.luizgustavo.pro.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Fatal Trap with NAT and 8.0-STABLE
On Mon, Mar 1, 2010 at 11:09 PM, Luiz Gustavo < luizgust...@luizgustavo.pro.br> wrote: > Hi guys.. > > I'm having trouble configuring NAT on a FreeBSD 8.0-STABLE. > > where the active pf or ipfw (ipfw add nat ...) I get a message "FATAL > TRAP" (url of the image below) > > http://www.luizgustavo.pro.br/blog/wp-content/uploads/2010/03/nat_problem_8.png > > someone help me? > > i have one freebsd with specifications: > > [r...@goldengate] ~# uname -a > FreeBSD goldengate.world-unix.com 8.0-STABLE FreeBSD 8.0-STABLE #0: Sun > Feb 28 17:58:04 BRT 2010 > r...@goldengate.world-unix.com:/usr/obj/usr/src/sys/WORLD-UNIX amd64 > > [r...@goldengate] ~# cat /usr/src/sys/amd64/conf/WORLD-UNIX > include GENERIC > > ident SMP-WORLD_UNIX > > # To make an SMP kernel, the next line is needed > options SMP # Symmetric MultiProcessor > Kernel > > device pf > device pflog > device pfsync > > options DEVICE_POLLING > > device carp > > options ALTQ > > options ALTQ_CBQ > options ALTQ_RED > options ALTQ_RIO > options ALTQ_HFSC > options ALTQ_CDNR > options ALTQ_PRIQ > > options LIBALIAS > options IPFIREWALL > options IPFIREWALL_NAT > options IPFIREWALL_FORWARD > options IPFIREWALL_DEFAULT_TO_ACCEPT > > options DUMMYNET > options HZ=1000 > > > # VIMAGE > options VIMAGE > nooptions SCTP > > thanks ! > PF is not compatible with VIMAGE, also why are you putting 2 firewalls in the kernel? -- Adam Vande More ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[releng_8 tinderbox] failure on i386/i386
TB --- 2010-03-02 06:12:42 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-02 06:12:42 - starting RELENG_8 tinderbox run for i386/i386 TB --- 2010-03-02 06:12:42 - cleaning the object tree TB --- 2010-03-02 06:13:04 - cvsupping the source tree TB --- 2010-03-02 06:13:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/i386/supfile TB --- 2010-03-02 06:13:41 - building world TB --- 2010-03-02 06:13:41 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-02 06:13:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-02 06:13:41 - TARGET=i386 TB --- 2010-03-02 06:13:41 - TARGET_ARCH=i386 TB --- 2010-03-02 06:13:41 - TZ=UTC TB --- 2010-03-02 06:13:41 - __MAKE_CONF=/dev/null TB --- 2010-03-02 06:13:41 - cd /src TB --- 2010-03-02 06:13:41 - /usr/bin/make -B buildworld >>> World build started on Tue Mar 2 06:13:42 UTC 2010 >>> 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 [...] gzip -cn /src/share/man/man4/man4.i386/apm.4 > apm.4.gz gzip -cn /src/share/man/man4/man4.i386/ce.4 > ce.4.gz gzip -cn /src/share/man/man4/man4.i386/cp.4 > cp.4.gz gzip -cn /src/share/man/man4/man4.i386/CPU_ELAN.4 > CPU_ELAN.4.gz gzip -cn /src/share/man/man4/man4.i386/cs.4 > cs.4.gz gzip -cn /src/share/man/man4/man4.i386/ct.4 > ct.4.gz gzip -cn /src/share/man/man4/man4.i386/ctau.4 > ctau.4.gz make: don't know how to make dpms.4. Stop *** Error code 2 Stop in /src/share/man/man4. *** Error code 1 Stop in /src/share/man. *** Error code 1 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-02 07:05:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-02 07:05:32 - ERROR: failed to build world TB --- 2010-03-02 07:05:32 - 2355.96 user 470.50 system 3170.26 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-i386.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[releng_8 tinderbox] failure on i386/pc98
TB --- 2010-03-02 06:36:21 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-02 06:36:21 - starting RELENG_8 tinderbox run for i386/pc98 TB --- 2010-03-02 06:36:21 - cleaning the object tree TB --- 2010-03-02 06:36:41 - cvsupping the source tree TB --- 2010-03-02 06:36:41 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/pc98/supfile TB --- 2010-03-02 06:37:42 - building world TB --- 2010-03-02 06:37:42 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-02 06:37:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-02 06:37:42 - TARGET=pc98 TB --- 2010-03-02 06:37:42 - TARGET_ARCH=i386 TB --- 2010-03-02 06:37:42 - TZ=UTC TB --- 2010-03-02 06:37:42 - __MAKE_CONF=/dev/null TB --- 2010-03-02 06:37:42 - cd /src TB --- 2010-03-02 06:37:42 - /usr/bin/make -B buildworld >>> World build started on Tue Mar 2 06:37:43 UTC 2010 >>> 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 [...] gzip -cn /src/share/man/man4/man4.i386/apm.4 > apm.4.gz gzip -cn /src/share/man/man4/man4.i386/ce.4 > ce.4.gz gzip -cn /src/share/man/man4/man4.i386/cp.4 > cp.4.gz gzip -cn /src/share/man/man4/man4.i386/CPU_ELAN.4 > CPU_ELAN.4.gz gzip -cn /src/share/man/man4/man4.i386/cs.4 > cs.4.gz gzip -cn /src/share/man/man4/man4.i386/ct.4 > ct.4.gz gzip -cn /src/share/man/man4/man4.i386/ctau.4 > ctau.4.gz make: don't know how to make dpms.4. Stop *** Error code 2 Stop in /src/share/man/man4. *** Error code 1 Stop in /src/share/man. *** Error code 1 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-02 07:29:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-02 07:29:30 - ERROR: failed to build world TB --- 2010-03-02 07:29:30 - 2350.91 user 483.04 system 3188.59 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-pc98.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
