Re: [current tinderbox] failure on alpha/alpha
Andrew Gallatin [EMAIL PROTECTED] writes: cc1: error: invalid option `tune=ev5' cc1: error: invalid option `ieee' cc1: error: bad value (ev4) for -mcpu= switch I assume that this is a crossbuild problem? No, the filesystem it was running on got yanked away in the middle of the run. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [current tinderbox] failure on i386/i386
Tinderbox [EMAIL PROTECTED] writes: [nothing] The tinderbox is failing to start because it tries to acquire a lock file in the sandbox, which is currently on an NFS partition. I've therefore disabled it while John is working on getting more local disk space online for the tinderbox to use. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: config(8) KERNEL setting
John Birrell [EMAIL PROTECTED] writes: It would make more sense to me if kern.pre.mk contained this: KERNEL?= kernel KERNEL_KO?= ${KERNEL} KODIR?= /boot/${KERNEL} Comments? I have Index: kern.pre.mk === RCS file: /home/ncvs/src/sys/conf/kern.pre.mk,v retrieving revision 1.34 diff -u -r1.34 kern.pre.mk --- kern.pre.mk 22 Aug 2003 15:41:44 - 1.34 +++ kern.pre.mk 29 Aug 2003 21:06:02 - @@ -9,7 +9,8 @@ # Can be overridden by makeoptions or /etc/make.conf KERNEL_KO?=kernel KERNEL?= kernel -KODIR?=/boot/${KERNEL} +KODIR?=/boot/${KERN_IDENT} +BOOTKODIR?=/boot/${KERNEL} M= ${MACHINE_ARCH} and in /boot/loader.conf: kernel=dwp_smp #kernel=dwp_up For old times' sake, I also have /boot/kernel as a symlink to /boot/dwp_smp. I used to have a more extensive patch which created that symlink at kernel install time so you wouldn't need to modify loader.conf, and the system would boot whichever kernel you installed last. I removed that part because I couldn't be bothered to make it work correctly with all combinations of make install / make reinstall and pre-existing /boot/kernel directory or symlink. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Entropy harvesting: interrupts ethernet point_to_point
Putinas [EMAIL PROTECTED] writes: on the recent src with custom compiled kernel ( generic minus some stuff what I don't need ) with firewall compiled in kernel , system infinitely hangs on boot unless I press ctrl-c at this point: Entropy harvesting: interrupts ethernet point_to_point Same things happens on two different computers with nearly similar custom kernel configuration Could you tell me, what's causing the problem ? Try adding 'set -x' at the top of /etc/rc (not before the #!/bin/sh line, though), and you should see what command is executed before the script hangs. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
weird text size
[EMAIL PROTECTED] /home/des# ps -opid,vsize,tsiz,command -p$$ PID VSZ TSIZ COMMAND 4712 23804 zsh How can the text size for zsh be only 4 kB? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI problems on MSI K7D
Nate Lawson [EMAIL PROTECTED] writes: Please report the dmesg from boot -v as that should help figure out why pci_cfgregopen() fails. Full log attached, both with and without ACPI. Also, I think the following should be \_S3: Name (\SS3, Package (0x04) That shouldn't have any impact on my problem though, should it? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS 640kB/523200kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 ([EMAIL PROTECTED], Mon Sep 1 18:48:59 CEST 2003) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x1eaadc data=0x22608+0x44e34 syms=[0x4+0x2cfa0+0x4+0x372f6] /boot/kernel/snd_ich.ko text=0x31e4 data=0x284 syms=[0x4+0x960+0x4+0x964] loading required module 'snd_pcm' /boot/kernel/snd_pcm.ko text=0x1412c data=0x24d8+0x1124 syms=[0x4+0x2a20+0x4+0x2e0d] /boot/kernel/usb.ko text=0x1fad0 data=0xc4c+0x168 syms=[0x4+0x2c70+0x4+0x33ce] /boot/kernel/ums.ko text=0x22e0 data=0x168+0x4 syms=[0x4+0x5f0+0x4+0x52f] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 3 seconds... Type '?' for a list of commands, 'help' for more detailed help. OK boot -v /boot/kernel/acpi.ko text=0x3aa2c data=0x170c+0xec0 syms=[0x4+0x5bf0+0x4+0x7a42] SMAP type=01 base= len=000a SMAP type=02 base=000f len=0001 SMAP type=02 base=fec0 len=0140 SMAP type=01 base=0010 len=1fef SMAP type=03 base=1fff3000 len=d000 SMAP type=04 base=1fff len=3000 Copyright (c) 1992-2003 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 5.1-CURRENT #9: Mon Sep 1 19:06:40 CEST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/meali Preloaded elf kernel /boot/kernel/kernel at 0xc0453000. Preloaded elf module /boot/kernel/snd_ich.ko at 0xc04531d8. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc0453284. Preloaded elf module /boot/kernel/usb.ko at 0xc0453330. Preloaded elf module /boot/kernel/ums.ko at 0xc04533d8. Preloaded elf module /boot/kernel/acpi.ko at 0xc0453480. Calibrating clock(s) ... i8254 clock: 1193232 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1363433775 Hz CPU: AMD Athlon(tm) MP 1500+ (1363.43-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x681 Stepping = 1 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc048MP,AMIE,DSP,3DNow! Data TLB: 32 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 536805376 (511 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0047d000 - 0x1f6c9fff, 522506240 bytes (127565 pages) avail memory = 516714496 (492 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040010, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040010, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 bios32: Found BIOS32 Service Directory header at 0xc00fac90 bios32: Entry = 0xfb100 (c00fb100) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xb130 pnpbios: Found PnP BIOS data at 0xc00fbb30 pnpbios: Entry = f:bb60 Rev = 1.0 Other BIOS signatures found: null: null device, zero device mem: memory I/O Pentium Pro MTRR support enabled random: entropy source SMP: CPU0 bsp_apic_configure(): lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff npx0: math processor on motherboard npx0: INT 16 interface acpi0: AMD2P AWRDACPI on motherboard pci_open(1):mode 1 addr port (0x0cf8) is 0x80ff003c pci_open(2):mode 2 enable port (0x0cf8) is 0xff panic: AcpiOsDerivePciId unable to initialize pci bus cpuid = 0; lapic.id = Debugger(panic) Stopped at Debugger+0x4e: xchgl %ebx,in_Debugger.0 db where Debugger(c02d384b,0,c0441336,c04757c4,100) at Debugger+0x4e panic(c0441336,c042c47c,c400e940,c043db4a,1) at panic+0x151 AcpiOsDerivePciId(c3f60b40,c3f60940,c0475804,168,0) at AcpiOsDerivePciId+0x2d AcpiEvPciConfigRegionSetup(c3fa6280,0,0,c047585c,c4004680) at AcpiEvPciConfigRegionSetup+0x224 AcpiEvAddressSpaceDispatch(c3fa6280,0,56,0,8) at AcpiEvAddressSpaceDispatch+0x86 AcpiExAccessRegion(c400e780,0,c047590c,0,c401ae00) at AcpiExAccessRegion+0x70 AcpiExFieldDatumIo(c400e780,0,c047590c,0,14f) at AcpiExFieldDatumIo+0x157
Re: ufs related panic with latest current
Tomi Vainio - Sun Finland [EMAIL PROTECTED] writes: First maxusers was 0 then when changed it to 8. That's a regression. Keep it at 0. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ufs related panic with latest current
Tomi Vainio - Sun Finland [EMAIL PROTECTED] writes: Dag-Erling Smørgrav writes: Tomi Vainio - Sun Finland [EMAIL PROTECTED] writes: First maxusers was 0 then when changed it to 8. That's a regression. Keep it at 0. I understood that there is a bug on new kmem allocator and this was an attempt to reduce kmem allocations but it didn't help. Do you know if this is going to fixed somehow or should people just install more memory to get system stay up? Well, reducing maxusers isn't going to help much as it only controls a small part of kernel memory, and setting it too low may render the system unusable. The backtrace you showed seems to indicate that the panic happened somewhere in the softupdates code, but IIRC that code has a fairly conservative built-in limit on memory consumption and degrades gracefully when it hits that limit. It's likely that something else gobbled up all available kernel memory, and the mallloc() call from softupdates was simply the straw that broke the camel's back. If you have a serial console hooked up, you could try running while :; do vmstat -m ; sleep 1 ; done on the serial console while doing whatever it is you do that causes the problem. This will tell you how much kernel memory was in use at the time of the panic and what it was used for. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ufs related panic with latest current
Tomi Vainio - Sun Finland [EMAIL PROTECTED] writes: Second trace didn't have anything to do with fs only fork system calls there so your expanation sounds reasonable. We probably don't see this problem again because system now has enough memory (256M). It would be really useful to know where the fault lies. We might even (God forbid!) figure out a way to fix it. You can easily force the system to boot with less than the full amount of memory by setting hw.physmem to e.g. 64m in /boot/loader.conf or at the loader prompt. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ufs related panic with latest current
Tomi Vainio - Sun Finland [EMAIL PROTECTED] writes: If you could just give instructions what you wanna get when system panics I might be able to persuade the other that we should crash our system once more. I already have. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng - delay probing for non-existent drive
Bryan Liesner [EMAIL PROTECTED] writes: The last change to ata-lowlevel (rev 1.11) causes a 10-15 second delay probing for a drive that's not there: [...] Same symptoms here... DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Release Engineering Status Report
David Rhodus [EMAIL PROTECTED] writes: Right, say if still the OpenSSH did or still comes out to be real. Ops, now thats right, we don't have 3.6.1 in STABLE, why ? It was released on April 1, does that not give one enough time to merge this in ? Is there a specific problem with OpenSSH 3.5 which requires an update to 3.6.1? Or do you just want me to update it to make the numbers look pretty on your screen? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Release Engineering Status Report
Mike Jakubik [EMAIL PROTECTED] writes: Is there a specific problem with OpenSSH 3.5 which requires an update to 3.6.1? Or do you just want me to update it to make the numbers look pretty on your screen? Apparently, yes. No. 3.6.1 has the same bug, and 3.7 isn't out yet. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Release Engineering Status Report
David Rhodus [EMAIL PROTECTED] writes: On Tuesday, September 16, 2003, at 11:54 AM, Dag-Erling Smørgrav wrote: Is there a specific problem with OpenSSH 3.5 which requires an update to 3.6.1? Or do you just want me to update it to make the numbers look pretty on your screen? Umm, yeah, so after today are we going to get a new import into RELENG_4 before 4.9 is pushed out the door ? No, OpenSSH 3.7 will not be ready in time for 4.9. Both -CURRENT and -STABLE have already been patched, BTW, so you needn't worry. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng hangs with kernel from september 15
Soren Schmidt [EMAIL PROTECTED] writes: Well, the ATA driver has just grown more standard compliant :) You *must* hang around for 31secs to wait for slow devices to come ready, according to the ATA specs. Now I've gone to great length before to get around this by using clever heuristics, and I'm getting there again, but there are *so* many crappy devices out there that it takes time to accomodate them all. Is there any way you can postpone the device initialization so you can do them in paralell? Or make the length of the wait configurable, like SCSI_DELAY? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Release Engineering Status Report
Jeremy Messenger [EMAIL PROTECTED] writes: On Wed, 17 Sep 2003 10:57:58 +0200, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: No. 3.6.1 has the same bug, and 3.7 isn't out yet. http://www.mindrot.org/pipermail/openssh-unix-announce/2003-September/64.html We use OpenSSH-portable, which lags a little behind. 3.7.1p1 seems to have been released late last evening, but it hasn't hit the mirrors yet. In any case, 3.7.1p1 will not hit -STABLE until it has spent at least a month in -CURRENT. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [current tinderbox] failure on alpha/alpha
Scott Long [EMAIL PROTECTED] writes: Sam is pretty sure that he already fixed this. Is it possible that the tinderbox machine is no longer getting cvs updates? It would seem so. Revision 1.69 of src/sys/net/bridge.c (which fixes this particular problem) is not in the repo on the RTP cluster. John, is something wrong with cvsup on the RTP cluster? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [current tinderbox] failure on ia64/ia64
Tinderbox [EMAIL PROTECTED] writes: /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/net/bridge.c: In function `bridge_in': /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/net/bridge.c:857: warning: cast from pointer to integer of different size *** Error code 1 Please ignore. It seems the RTP cluster's CVS repo is no longer being updated; I've disabled the tinderbox until this is resolved. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: more panics from current (partII)
Tomi Vainio - Sun Finland [EMAIL PROTECTED] writes: After adding more disks to this system it dies continously. Last two traces look quite the same. Tomppa ---clipclip--- login: kernel trap 19 with interrupts disabled NMI ... going to debugger An NMI almost certainly indicates a hardware failure. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/sh terminated abnormally
Kris Kennaway [EMAIL PROTECTED] writes: Yes, since you have run installworld you have now installed a 5.x /bin/sh binary, which cannot run on the 4.x kernel you are running. He *hasn't* run installworld; installworld would have installed the new loader. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [releng_5_1 tinderbox] failure on sparc64/sparc64
Tinderbox [EMAIL PROTECTED] writes: [nothing] argh! /me fix DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Seeing system-lockups on recent current
Doug White [EMAIL PROTECTED] writes: On Fri, 10 Oct 2003, Garance A Drosihn wrote: For the past week or so, I have been having a frustrating time with my freebsd-current/i386 system. It is a dual Athlon system. [...] It would be useful to isolate exactly what day the problem started occuring. I experienced similar problems on a dual Athlon system (MSI K7D Master-L motherboard, AMD 760MPX chipset, dual Athlon MP 2200+) which is barely a couple of months old. I ended up reverting to RELENG_5_1. With -CURRENT, both UP and SMP kernels will crash with symptoms which suggest hardware trouble. With RELENG_5_1, UP is rock solid (knock on wood) while SMP crashes within minutes of booting. I've run out of patience with this system, so I'll keep running RELENG_5_1 on it until someone manages to convince me that -CURRENT will run properly on AMD hardware (maybe around 5.3 or so...) Now, my shiny new 2.4 GHz P4, on the other hand... *drool* DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Seeing system-lockups on recent current
Don Lewis [EMAIL PROTECTED] writes: My Athlon XP 1900+/AMD 761 UP box is happily running a late October 6th version of -current. XP != MP DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: pmap_zero_page: CMAP3 busy
Joe Marcus Clarke [EMAIL PROTECTED] writes: See my previous email dated Sat, 11 Oct 2003 01:39:20 -0400 on the subject. It looks like the problem may have to do with CPU type (PIII in my case). My P4 laptop has the same -CURRENT, and does not experience the problem. It may also be noteworthy that I have CPU_ENABLE_SSE on my PIII as well. My new P4 consistently panics at boot (immediately before, or while, starting init) with pmap_zero_page: CMAP3 busy with both SMP and UP kernels built from fresh sources. It boots fine with a three days old SMP kernel. CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2411.67-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf29 Stepping = 9 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Hyperthreading: 2 logical CPUs DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help saving my system
Scott M. Likens [EMAIL PROTECTED] writes: Comments anyone? Yes: you're an idiot. Go play somewhere else. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld fails in 5.1-CURRENT in wall
M. Warner Losh [EMAIL PROTECTED] writes: find /usr/obj -name .depend or better yet rm -rf /usr/obj/* *ahem* the correct incantation is: # cd /usr/src # make cleandir # make cleandir DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [-CURRENT tinderbox] failure on ia64/ia64
Ruslan Ermilov [EMAIL PROTECTED] writes: mkinit is the bin/sh's build-tool, and should have been built for the native architecture, i386. The above means that mkinit was rebuilt for ia64, and the resulting binary was then ran on i386. If you don't have other explanations to the above, please check that the date and time are set on the building box correctly, and that source files do not have modification time in the future. I don't think that's it. I'm getting the same error in the powerpc build (which runs on a different machine). I've verified that both machines have a reasonably correct clock. Besides, if the clock was a problem, it should also affect the other builds, but out of the six builds that run on cueball, only ia64 and sparc64 fail. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 3D graphic cards
Julian St. [EMAIL PROTECTED] writes: is there any list that provides information about what graphic cards on FreeBSD have supported 3D acceleration? (I need only X-Video support in particular, but it seems tied to 3D acceleration). http://people.freebsd.org/~anholt/dri/ Radeon-based cards (up to 8500) are fairly cheap and work well. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [-CURRENT tinderbox] failure on sparc64/sparc64
Harti Brandt [EMAIL PROTECTED] writes: Is there any specific reason that the sparc64 tinderbox permanently dumps core? I have no problem here to build world on my sparcs. Remember, this is a cross-build... DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [-CURRENT tinderbox] failure on sparc64/sparc64
Marcel Moolenaar [EMAIL PROTECTED] writes: It needs to be analyzed because cross-builds should not fail. Do we have a machine problem? What exactly is dumping core? Is it gzip or some binary started immediately after it? If it's gzip, is there a relation with the recent compiler warning about strncmp? It's not a machine problem if it only happens to the sparc64 build - the same machine runs all the other -CURRENT tinderboxen except powerpc. There doesn't seem to be anything wrong with the sources either. There's not much more I can say about it until I see the full log from the next run; the last one broke at a different point. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [-CURRENT tinderbox] failure on sparc64/sparc64
Marcel Moolenaar [EMAIL PROTECTED] writes: It does not only happen to sparc64. I've seen it fail for all but i386 and pc98, I think. Interestingly, the latest sparc64 tinderbox succeeded. The first question is: what process is dumping core. I think you'll find that with dmesg(8). [EMAIL PROTECTED] ~% bzgrep dumped /var/log/messages* /var/log/messages:Jul 15 14:04:24 cueball kernel: pid 6864 (make), uid 722: exited on signal 4 (core dumped) /var/log/messages.0.bz2:Jul 14 07:53:19 cueball kernel: pid 44991 (make), uid 722: exited on signal 10 (core dumped) /var/log/messages.1.bz2:Jul 12 05:49:04 cueball kernel: pid 6340 (make), uid 722: exited on signal 10 (core dumped) /var/log/messages.1.bz2:Jul 12 13:31:23 cueball kernel: pid 69880 (make), uid 722: exited on signal 11 (core dumped) /var/log/messages.1.bz2:Jul 12 14:14:47 cueball kernel: pid 57456 (make), uid 722: exited on signal 11 (core dumped) /var/log/messages.2.bz2:Jul 9 14:08:23 cueball kernel: pid 4991 (make), uid 722: exited on signal 10 (core dumped) /var/log/messages.2.bz2:Jul 10 07:34:54 cueball kernel: pid 36133 (make), uid 722: exited on signal 10 (core dumped) /var/log/messages.3.bz2:Jul 6 18:08:46 cueball kernel: pid 43705 (make), uid 722: exited on signal 11 (core dumped) /var/log/messages.3.bz2:Jul 6 18:48:30 cueball kernel: pid 11632 (make), uid 722: exited on signal 11 (core dumped) /var/log/messages.3.bz2:Jul 7 19:29:31 cueball kernel: pid 94081 (make), uid 722: exited on signal 11 (core dumped) /var/log/messages.4.bz2:Jul 4 16:39:11 cueball kernel: pid 43256 (make), uid 722: exited on signal 11 (core dumped) /var/log/messages.4.bz2:Jul 5 15:09:59 cueball kernel: pid 24880 (make), uid 722: exited on signal 11 (core dumped) /var/log/messages.4.bz2:Jul 5 15:50:31 cueball kernel: pid 3662 (make), uid 722: exited on signal 11 (core dumped) /var/log/messages.4.bz2:Jul 6 03:26:28 cueball kernel: pid 45681 (make), uid 722: exited on signal 11 (core dumped) /var/log/messages.4.bz2:Jul 6 04:09:28 cueball kernel: pid 24332 (make), uid 722: exited on signal 11 (core dumped) /var/log/messages.5.bz2:Jul 3 16:13:22 cueball kernel: pid 7543 (make), uid 722: exited on signal 10 (core dumped) [EMAIL PROTECTED] ~% id uid=722(des) gid=722(des) groups=722(des) DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Annoucning DragonFly BSD!
Julian Stacey [EMAIL PROTECTED] writes: Periodicaly someone masquerades as Matt Dilllon. Those targeted by trolls need to work extra hard to establish credibility of poster's address, to avoid suspicion of troll at work (phone number maybe?). Trolls of course need to work extra hard too, to also convince us. Maybe this time the poster is the real Matthew Dillon, but I doubt it. Idiot. $ whois dragonflybsd.org [...] Registrant: Matthew Dillon 41 Vicente Rd Berkeley, CA 94705 US Registrar: DOTSTER Domain Name: DRAGONFLYBSD.ORG Created on: 14-JUL-03 Expires on: 15-JUL-05 Last Updated on: 14-JUL-03 Administrative, Technical Contact: Dillon, Matthew [EMAIL PROTECTED] 41 Vicente Rd Berkeley, CA 94705 US 510 848 9745 Domain servers in listed order: APOLLO.BACKPLANE.COM NS.IDIOM.COM NS2.IDIOM.COM End of Whois Information DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc-3.3 issues
Michael Nottebrock [EMAIL PROTECTED] writes: There was one report of kdelibs' configure failing because of the weirdness of the new cc (3.3), that leads to errors instead of warnings with certain combinations of -W* and -pedantic options. gcc 3.3 is a lot stricter about some errors which earlier versions recovered from gracefully. Note that these are real errors, i.e. patently incorrect code which earlier versions of gcc happened to accept (sometimes by design, sometimes by mistake). DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [-CURRENT tinderbox] failure on i386/i386
Peter Wemm [EMAIL PROTECTED] writes: Tinderbox wrote: gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/nls/catgets.3 catgets.3.gz Segmentation fault (core dumped) *** Error code 139 These false alarms are wearing a bit thin. Is there a problem with the tinderbox build machine perhaps? No, the failures are too systematic for that. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [-CURRENT tinderbox] failure on i386/i386
Peter Wemm [EMAIL PROTECTED] writes: Hmm. I thought it was gzip that was dying. Looks like its make instead, and is rather consistent. told you so So, who has been messing with make(1) lately? I believe that the problem is in the kernel, not in make(1); it just happens to be triggered by make(1) because it is a big (if not the biggest) vfork(2) consumer. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Does linux-sun-jdk_1.4.2 work?
Adam [EMAIL PROTECTED] writes: Perhaps you should try working with Java 1.4.x on FreeBSD before you assume something about me that's highly inaccurate. I think you'll find very quickly that it doesn't work nicely unless the process is running as root. I use it daily and have never had any trouble (except for the broken Xalan in 1.4.1). DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [current tinderbox] failure on sparc64/sparc64
Tinderbox [EMAIL PROTECTED] writes: TB --- mkdir /home/des/tinderbox TB --- mkdir /home/des/tinderbox/CURRENT TB --- mkdir /home/des/tinderbox/CURRENT/sparc64 TB --- mkdir /home/des/tinderbox/CURRENT/sparc64/sparc64 Sorry about that, I was a bit too hasty moving some directories around. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [current tinderbox] failure on i386/i386
Scott Long [EMAIL PROTECTED] writes: Anyone know what is up with this? I'm not getting it on my LINT builds. revision 1.41 date: 2003/08/01 17:00:49; author: obrien; state: Exp; lines: +1 -1 Fix kernel build -- 'c' was the unused var, not 'lines'. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [current tinderbox] failure on amd64/amd64
Tinderbox [EMAIL PROTECTED] writes: TB --- mkdir /home/des/tinderbox/CURRENT Disk failure on the tinderbox machine. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buildworld broken after installworld
Ruslan Ermilov [EMAIL PROTECTED] writes: For example, this result is right and not the bug (but wrong tr usage): env LANG=de_DE.ISO8859-1 tr '[a-z]' '[A-Z]' vi_zero WI_]ERO Clearly this is a useless construct then. The correct construct is tr '[:lower:]' '[:upper:]' DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: warnpassword and warnexpire in 5.1 login.conf
David Schultz [EMAIL PROTECTED] writes: On Tue, Aug 05, 2003, Mats Larsson wrote: And the following varning when password is old: Aug 5 12:27:38 marvin sshd[55386]: error: PAM: OK Aug 5 12:27:40 marvin sshd[55390]: fatal: PAM: chauthtok not supprted with privsep Is there perhaps a better PAM way of doing this things now?? Hmm... Apparently you can't change an expired password with a privilege-separated OpenSSH. I don't know whether that can be fixed, but perhaps des@ has some insight. It can be done, but not without cheating. You have to have the PAM support code do chauthtok as part of the authentication sequence. I've been meaning to do it for a while but haven't gotten around to it yet. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why did INVARIANTS hide the geom bug?
walt [EMAIL PROTECTED] writes: If inclusion of INVARIANTS serves to disguise bugs in the kernel, I wonder if kernel committers should be using this option routinely? It doesn't serve to disguise bugs; quite to the contrary, it serves to expose bugs and reveal their causes. However, INVARIANTS is slightly invasive; it adds code to the kernel, and in some cases changes data structures a little, and these changes have subtle side effects which may cause a bug to go into hiding. Such bugs are called heisenbugs (because the presence of the observer affects the outcome of the experiment...) and are generally caused by using a stack variable before its initialization, or dereferencing a pointer after freeing the memory it points to, etc. I recently fixed a bug in pkg_delete which had gone undetected for years because it depended on whether the stack had been used before the function the bug was in got called, and even if it had the garbage on the stack would in most cases be recognized as an incorrect value and ignored, but once in a while pkg_delete thought it was a valid file name and ended up doing the weirdest things. Running pkg_delete with kernel tracing enabled (which would have shown me exactly what pkg_delete was trying to do) caused the bug to magically disappear - I never quite figured out why - so I had a hell of a time tracking it down. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildkernel and gcc2
RMH [EMAIL PROTECTED] writes: It isn't a problem to export an extra variable and make it known to bsd.kern.mk; the question is, do we want GCC2 to be a supported compiler for -CURRENT or not? No. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Anyone working on fsck?
Julian Elischer [EMAIL PROTECTED] writes: [fsck is impossibly slow on multi-TB filesystems] Let's rather work on getting a working log-structured filesystem committed so we don't *need* fsck for filesystems that large. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Why did INVARIANTS hide the geom bug?
walt [EMAIL PROTECTED] writes: Looking at the code thru my amateur eyes it appears that defining INVARIANTS allows the programmer to add whatever code he wishes with an ifdef statement. That covers a lot of territory. Looking thru sys/geom I don't see any such ifdefs in your code, so I still don't know why the recent geom bug was hidden by INVARIANTS. On the contrary, there is a lot on INVARIANTS-specific code in GEOM: [EMAIL PROTECTED] /sys/geom% grep -r KASSERT . | wc -l 120 DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pkg_add segfault
Mike Makonnen [EMAIL PROTECTED] writes: is this ok with you? Ugh, yes. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IP over IEEE1394?
Rossam Souza Silva [EMAIL PROTECTED] writes: Hi, I don't know about the Mac's implementation, but yes, Windows has IP over Firewire, like NetBSD. The good reason for IP over Firewire: because it's a standard, you can connect Macs, Win Boxes and BSDs! :) Gee, well, I guess we can all get rid of that nasty non-standard Ethernet hardware now! DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Need ALSA
Peter Schultz [EMAIL PROTECTED] writes: Having a port of ALSA would sure round out 5.2 nicely, and would get you MIDI support: http://www.alsa-project.org/ This can easily happen if we get behind a developer. Not so. ALSA is poorly designed (there is no hardware abstraction layer below the driver layer) and would represent a significant challenge to port, not to mention maintain once ported. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Peter Wemm [EMAIL PROTECTED] writes: Mike Barcroft wrote: stage 4: building everything.. -- === share/man/man9 make: don't know how to make bus_Activate_resource.9. Stop *** Error code 2 This looks like a single bit memory error to me. Turn off bit 5 and a lowercase a turns into an uppercase A. nice try, but check rev 1.179 of src/share/man/man9/Makefile. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: patch to improve AES-NI performance
John-Mark Gurney j...@funkthat.com writes: Mike Tancsa m...@sentex.net writes: John-Mark Gurney j...@funkthat.com writes: My patch would only effect userland applications that use /dev/crypto... For me its ssh which I think does, no ? It looks like it uses OpenSSL for it's crypto, not /dev/crypto... It uses OpenSSL engines, which use /dev/crypto. This is why we had to turn off sandbox mode - a CRIOGET ioctl fails because the sandbox code sets RLIMIT_NOFILES to 0. (trimming security@ from the cc: list as it's an alias for secteam@ which is not the appropriate venue for this discussion.) DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: random(4) update causes mips compile fail | mips boot fail
Glen Barber g...@freebsd.org writes: The correct workaround (which now I see I should have done before locking head/) is to revert this commit so it can be properly fixed. Glen, to be fair, the mips boot fails because they're trying to use a device before it's ready. It just so happens that this device is implemented entirely in software, not in hardware, but it's no different from trying to read from an empty optical drive. The only thing that has changed, in practical terms, is that previously if they tried to read from an empty drive (to continue the analogy) we'd nod and smile and feed them zeroes, whereas now we wait for someone to insert a disc. So Mark didn't really break anything here (apart from the build breakage which has already been fixed), he just made an existing bug visible. And he's already reverted the *one* line of code that did this, so mips is now almost as broken as it was before (only almost, because the first commit also fixed some serious harvesting / entropy estimation bugs). Anyway, on platforms that support tunables, this should help: Index: sys/dev/random/randomdev_soft.c === --- sys/dev/random/randomdev_soft.c (revision 255371) +++ sys/dev/random/randomdev_soft.c (working copy) @@ -102,6 +102,8 @@ #endif +TUNABLE_INT(kern.random.sys.seeded, random_context.seeded); + /* List for the dynamic sysctls */ static struct sysctl_ctx_list random_clist; On platforms that don't, we need to figure out a better solution; possibly Pawel's early harvesting patch, which, while not perfect, at least introduces a minimum of entropy into Yarrow before boot. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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] mtree should not output size if the file is not a regular file
Xin Li delp...@delphij.net writes: I think it doesn't make sense to emit size information for non-regular files like directories, symlinks, etc. although both our and NetBSD's mtree would emit it. I agree. The size of a directory will vary from filesystem to filesystem, while the size of a symlink is simply the length of its target. There is no need for it, and in the case of a directory, including it causes spurious diffs between mtree descriptions of identical trees on different systems. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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] mtree should not output size if the file is not a regular file
Christos Zoulas chris...@zoulas.com writes: Xin Li delp...@delphij.net writes: I think it doesn't make sense to emit size information for non-regular files like directories, symlinks, etc. although both our and NetBSD's mtree would emit it. We could change that, but what's the harm? Roll a large tarball (e.g. a complete FreeBSD installation). Copy it to different machines with different filesystems. Untar and run mtree on the result. Notice that you get different output on each machine because they report different sizes for directories; one might report the actual on-disk size (which might vary depending on past contents) while the other might report the number of entries. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: OpenSSH with DNSSEC support in 10
OpenSSH in FreeBSD 10 is now built with DNSSEC support, unless you disable LDNS in src.conf. If DNSSEC is enabled, the default setting for VerifyHostKeyDNS is yes. This means that OpenSSH will silently trust DNSSEC-signed SSHFP records. I consider this a lesser evil than ask (aka train the user to type 'yes' and hit enter) and no (aka train the user to type 'yes' and hit enter without even the benefit of a second opinion). DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: OpenSSH with DNSSEC support in 10
Ian Lepore i...@freebsd.org writes: So what happens when there is no dns server to consult? Will every ssh connection have to wait for a long dns query timeout? What if the machine is configured to use only /etc/hosts? If there is no DNS server, no query will be sent. What if a DNS server is configured but doesn't respond? The DNS request will time out. In the vast majority of cases, you will either have no DNS at all (so no query will be sent), or you will have a functioning DNS server. In a slightly less vast majority of cases, you will not be able to resolve the server's IP address without DNS anyway. For that matter, I just realized I'm a bit unclear on who is querying DNS for this info, the ssh client or the sshd? The client - and you can override this in your ~/.ssh/config or on the command line (-oVerifyHostKeyDNS=no). DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: OpenSSH with DNSSEC support in 10
Ian Lepore i...@freebsd.org writes: I just ran into a build error related to this: [...] I find that the attached patch fixes it for me. [...] @@ -1468,7 +1468,7 @@ lib/libcxxrt__L: gnu/lib/libgcc__L lib/libradius lib/libsbuf lib/libtacplus \ ${_cddl_lib_libumem} ${_cddl_lib_libnvpair} \ ${_cddl_lib_libzfs_core} \ - lib/libutil ${_lib_libypclnt} lib/libz lib/msun \ + lib/libutil ${_lib_libypclnt} lib/libldns lib/libz lib/msun \ ${_secure_lib_libcrypto} ${_secure_lib_libssh} \ ${_secure_lib_libssl} That's not going to work, because libldns requires libcrypto. You should try the following: @@ -1470,8 +1470,8 @@ ${_cddl_lib_libumem} ${_cddl_lib_libnvpair} \ ${_cddl_lib_libzfs_core} \ lib/libutil ${_lib_libypclnt} lib/libz lib/msun \ - ${_secure_lib_libcrypto} ${_secure_lib_libssh} \ - ${_secure_lib_libssl} + ${_secure_lib_libcrypto} ${_lib_libldns} \ + ${_secure_lib_libssh} ${_secure_lib_libssl} .if ${MK_ATF} != no _lib_atf_libatf_c= lib/atf/libatf-c Oh, wait, that's actually an excerpt from the commit that enabled LDNS in OpenSSH. What a coincidence! DES -- Dag-Erling Smørgrav - d...@des.no ___ 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 r255597 breaks -current with GCC
Michael Butler i...@protected-networks.net writes: As below .. Yep, working on it, thanks. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: unbound? -- Conf file?
Nathan Whitehorn nwhiteh...@freebsd.org writes: A related note: it seems like the /etc bits for unbound have not been hooked up. There is no default config (this post) but also no RC script, for example. ...yet. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: error build world
Alexander Panyushkin vsi...@gmail.com writes: I do not need kerberos. Why option WITHOUT_KERBEROS = YES does not work? My mistake. Comment out every line that mentions KRB5, HEIMDAL or GSSAPI in crypto/openssh/config.h and you should be fine (they are not needed, as the Makefile defines all the required macros if MK_KERBEROS=yes). DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: unbound: start BEFORE ntpd?
Larry Rosenman l...@lerctr.org writes: When I rebooted my box today after the latest rc.d changes for unbound, I noted that ntpd started BEFORE unbound therefore could NOT look up hosts. Are there more tweaks needed here? Yes - I forgot to commit this: Index: NETWORKING === --- NETWORKING (revision 255837) +++ NETWORKING (working copy) @@ -6,7 +6,7 @@ # PROVIDE: NETWORKING NETWORK # REQUIRE: netif netoptions routing ppp ipfw stf faith # REQUIRE: defaultroute routed mrouted route6d mroute6d resolv bridge -# REQUIRE: static_arp static_ndp +# REQUIRE: static_arp static_ndp local_unbound # This is a dummy dependency, for services which require networking # to be operational before starting. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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-version(1) enchancement
Kimmo Paasiala kpaas...@gmail.com writes: Would it make sense to also include the svnversion(1) of the system sources in the version output? No. It is not available in the most important use case for freebsd-version(1), i.e. freebsd-update builds. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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-version(1) enchancement
Kimmo Paasiala kpaas...@gmail.com writes: Dag-Erling Smørgrav d...@des.no writes: Kimmo Paasiala kpaas...@gmail.com writes: Would it make sense to also include the svnversion(1) of the system sources in the version output? No. It is not available in the most important use case for freebsd-version(1), i.e. freebsd-update builds. I didn't express myself well enough I guess. I understood you perfectly, but the svn revision number is not available to the freebsd-update build, nor to users who build from a git checkout. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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
Passive FTP
I keep forgetting that fetch(1) defaults to active FTP, because login.conf(5) sets the FTP_PASSIVE_MODE environment variable, but every once in a while I try to pkg_add -r in single-user mode or using sudo(1) and it breaks. I have therefore flipped the switch and made passive FTP the default. Those who still want active FTP (what on earth for?) can set FTP_PASSIVE_MODE=NO in their environment. This overrides both the default setting and fetch(1)'s -p command-line option. I'd like to merge this to stable/9 before 9.0 ships, so I'd appreciate prompt feedback if anyone runs into any trouble. I currently do *not* plan to merge this to stable/8 or any older branches. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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
9 hangs with idletick = 0
I have a box running a GENERIC kernel from September 25th that freezes completely for a few seconds, up to a minute or so, at random intervals. Sooner or later it freezes permanently (or at least longer than I am willing to wait for it to unfreeze) and must be power-cycled, as it does not respond to Ctrl+Alt+Esc. Network activity (such as downloading ISO images over a 6 Mbps DSL line) seems to aggravate the issue. The problem goes away if I enable idletick. I had the same problems with a slightly customized kernel (basically GENERIC with unused drivers removed) built from September 10th sources; I switched to GENERIC to eliminate the possibility that my kernel config was to blame. Prior to that, the machine ran a kernel with the same custom config built from April 27th sources without any trouble whatsoever, so the issue must have been introduced sometime between April 27th and September 10th. The machine is an Intel Core 2 Duo E6600 with 4 GB RAM. Relevant sysctls: kern.eventtimer.choice: HPET(450) HPET1(440) HPET2(440) LAPIC(400) i8254(100) RTC(0) kern.eventtimer.et.LAPIC.flags: 15 kern.eventtimer.et.LAPIC.frequency: 0 kern.eventtimer.et.LAPIC.quality: 400 kern.eventtimer.et.HPET.flags: 3 kern.eventtimer.et.HPET.frequency: 14318180 kern.eventtimer.et.HPET.quality: 450 kern.eventtimer.et.HPET1.flags: 3 kern.eventtimer.et.HPET1.frequency: 14318180 kern.eventtimer.et.HPET1.quality: 440 kern.eventtimer.et.HPET2.flags: 3 kern.eventtimer.et.HPET2.frequency: 14318180 kern.eventtimer.et.HPET2.quality: 440 kern.eventtimer.et.i8254.flags: 1 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.i8254.quality: 100 kern.eventtimer.et.RTC.flags: 17 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.RTC.quality: 0 kern.eventtimer.periodic: 0 kern.eventtimer.timer: HPET kern.eventtimer.idletick: 1 kern.eventtimer.singlemul: 2 kern.timecounter.tick: 1 kern.timecounter.choice: TSC-low(1000) i8254(0) HPET(950) ACPI-fast(900) dummy(-100) kern.timecounter.hardware: TSC-low kern.timecounter.stepwarnings: 0 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 6800584 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 3991486344 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 27169 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.TSC-low.mask: 4294967295 kern.timecounter.tc.TSC-low.counter: 4021161618 kern.timecounter.tc.TSC-low.frequency: 9375191 kern.timecounter.tc.TSC-low.quality: 1000 kern.timecounter.smp_tsc: 1 kern.timecounter.invariant_tsc: 1 Let me know if you need anything else. I can try to bisect, but it will take time since the freezes are tricky to reproduce. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Passive FTP
Peter Jeremy peterjer...@acm.org writes: Dag-Erling Smørgrav d...@des.no writes: This overrides both the default setting and fetch(1)'s -p command-line option. I'm less happy with this - my gut feeling in that command-line options should override evnironment variables. This was already the case, just in the other direction. The environment variable overrode the absence of -p, and there was no reverse option, neither on the fetch(1) command line nor in the fetchGetFTP(3) arguments. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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 hangs with idletick = 0
Alexander Motin m...@freebsd.org writes: If short freezes you've descrived happens often enough, you may try to log them down with enabling KTR_SPARE2 ktr event type and disabling logging within few seconds after such freeze happened. I've been working with adri to try to isolate it. We've eliminated nfs and zfs as possible sources. I definitely think it's network-related, because I can trigger it by downloading a large file to /dev/null. Interestingly, it looks like serial console activity wakes it up - not immediately, but when I hooked up the console, it woke up within seconds after being frozen for almost ten minutes. I've just built a kernel with KTR support, and with KTR_SPARE2, KTR_INTR and KTR_SCHED enabled by default. I'll see what turns up. I'm also going to try machdep.idle=hlt with kern.eventtimer.idletick=0, and using a PCI re(4) instead of the on-board msk(4) while running with default settings. BTW, can I suggest appropriating one of KTR_SPARE[234] and renaming it to KTR_CLOCK? I don't see why cxgb should use them, let alone all three; it should use KTR_DEV or KTR_NET instead. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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
incorrect use of pidfile(3)
I looked at some of the programs that use pidfile(3) in base, and they pretty much all get it wrong. Consider these two scenarios: 1) common case process A process B main() pidfile_open() - success perform_initialization() daemon() pidfile_write() - success perform_work() main() pidfile_open() - EEXIST exit() 2) very unlikely but still possible case process A process B main() pidfile_open() - success main() perform_initialization()pidfile_open() - EAGAIN daemon()perform_initialization() pidfile_write() - successdaemon() perform_work() perform_work() The problem is that most of them (at least the ones I checked) ignore a pidfile_open() failure unless errno == EEXIST. How do we fix this? My suggestion is to loop until pidfile_open() succeeds or errno != EAGAIN. Does anyone have any objections to that approach? DES -- Dag-Erling Smørgrav - d...@des.no ___ 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 hangs with idletick = 0
Dag-Erling Smørgrav d...@des.no writes: I've just built a kernel with KTR support, and with KTR_SPARE2, KTR_INTR and KTR_SCHED enabled by default. I'll see what turns up. I'm also going to try machdep.idle=hlt with kern.eventtimer.idletick=0, and using a PCI re(4) instead of the on-board msk(4) while running with default settings. Great, the bug does not occur when KTR is enabled. The machine has been up for 14+ hours without crashing, despite plenty of network activity, which usually triggers a freeze within minutes. It looks like there may still be short freezes (a few seconds at a time). I'm thinking of instrumenting fetch(1) to record any instances of fread() taking more than, say, half a second. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: incorrect use of pidfile(3)
Pawel Jakub Dawidek p...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no writes: How do we fix this? My suggestion is to loop until pidfile_open() succeeds or errno != EAGAIN. Does anyone have any objections to that approach? I think we already do that internally in pidfile_open(). Can you take a look at the source and confirm that this is what you mean? No, it doesn't; pidfile_open(3) returns NULL with errno == EAGAIN if the pidfile is locked but empty, as is the case in the window between a successful pidfile_open(3) and the first pidfile_write(3). This is documented in the man page: [EAGAIN] Some process already holds the lock on the given pid‐ file, but the file is truncated. Most likely, the existing daemon is writing new PID into the file. I have a patch that adds a pidfile to dhclient(8), where I do this: for (;;) { pidfile = pidfile_open(path_dhclient_pidfile, 0600, otherpid); if (pidfile != NULL || errno != EAGAIN) break; sleep(1); } if (pidfile == NULL) { if (errno == EEXIST) error(dhclient already running, pid: %d., otherpid); warning(Cannot open or create pidfile: %m); } I'm not sure I agree with the common idiom (which I copied here) of ignoring all other errors than EEXIST, but that's a different story. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: incorrect use of pidfile(3)
After discussing this with pjd@ on IRC, I arrived at the attached patch, which increases the length of time pidfile_open() itself waits (I hadn't noticed that it already looped) and sets *pidptr to -1 if it fails to read a pid. DES -- Dag-Erling Smørgrav - d...@des.no Index: lib/libutil/pidfile.c === --- lib/libutil/pidfile.c (revision 226271) +++ lib/libutil/pidfile.c (working copy) @@ -118,22 +118,19 @@ */ fd = flopen(pfh-pf_path, O_WRONLY | O_CREAT | O_TRUNC | O_NONBLOCK, mode); - if (fd == -1) { - count = 0; + if (fd == -1 errno == EWOULDBLOCK pidptr != NULL) { + *pidptr = -1; + count = 20; rqtp.tv_sec = 0; rqtp.tv_nsec = 500; - if (errno == EWOULDBLOCK pidptr != NULL) { - again: + for (;;) { errno = pidfile_read(pfh-pf_path, pidptr); - if (errno == 0) -errno = EEXIST; - else if (errno == EAGAIN) { -if (++count = 3) { - nanosleep(rqtp, 0); - goto again; -} - } + if (errno != EAGAIN || --count == 0) +break; + nanosleep(rqtp, 0); } + if (errno == 0) + errno = EEXIST; free(pfh); return (NULL); } ___ 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: incorrect use of pidfile(3)
Pawel Jakub Dawidek p...@freebsd.org writes: I'm still in opinion that EWOULDBLOCK and EAGAIN (which is the same value on FreeBSD) should be converted to EEXIST on pidfile_open() return. The historical (and documented) behavior is to return EAGAIN. Also if we now have for loop, why not to put count in there? Because if we do, there will be a nanosleep after the last pidfile_read() attempt. We need to break the loop after pidfile_read() failed but before nanosleep(). I'm not very happy about touching pidptr in case of error other than EEXIST. This is not documented, but a bit unexpected anyway. Well, it was your idea, I just moved it to before the loop :) DES -- Dag-Erling Smørgrav - d...@des.no ___ 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 hangs with idletick = 0
Poul-Henning Kamp p...@phk.freebsd.dk writes: For what it's worth, I regularly (=every 10-12 days or so) see all timer activity in the system die and have to use the 4-sec power-switch to get the system down. Could you check if network activity (e.g. downloading an ISO) triggers it, and if so, if it goes away when you set the kern.eventtimer.idletick sysctl to 0? DES -- Dag-Erling Smørgrav - d...@des.no ___ 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 hangs with idletick = 0
Adrian Chadd adr...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no writes: Could you check if network activity (e.g. downloading an ISO) triggers it, and if so, if it goes away when you set the kern.eventtimer.idletick sysctl to 0? Don't you mean 'set it to 1' ? Uh, yes :) DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: incorrect use of pidfile(3)
Pawel Jakub Dawidek p...@freebsd.org writes: After proposed changes it would look like this, what do you think? http://people.freebsd.org/~pjd/patches/pidfile.3.patch Looks OK to me, but you should also remove the paragraph about EAGAIN in the man page. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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/ls' broken by SVN r226509
Michael Butler i...@protected-networks.net writes: When running 'configure' for, say, the latest clamav update, '/bin/ls' dumps core with a floating point exception. Thanks for the report. Try r226546. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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/ls' broken by SVN r226509
Daniel O'Connor docon...@gsoft.com.au writes: This is the crunched binary and is pretty big (unlikely to be an issue on a modern system though). You can do.. cd /usr/src/bin/ls make all install I think you missed the point. Reinstalling ls from broken sources wasn't going to help. He needed subversion to update his tree so he could build a working ls, but he needed a working ls to build subversion. The simplest solution would have been either # export PATH=/rescue:$PATH or # ln -f /rescue/ls /bin/ls which would have allowed him to build subversion. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: PAM passwdqc, strict aliasing, and WARNS
Justin T. Gibbs gi...@freebsd.org writes: Someone who has yet to confess added -Werror to the global CFLAGS (via /etc/make.conf) for one of our systems at work. Before I figured out that this was the cause of builds failing, I hacked up pam_passwdc to resolve the problem. This gets the module to WARNS=2, but to go farther, the logically const issues with this code will need to be sorted out. Is this change worth committing? Is this the best way to resolve the strict aliasing issues in this code? I really don't like that sort of game. If you look at other PAM consumer code, you'll see that the common idiom is what Jilles suggested, i.e. use a temporary variable of the appropriate type. That being said, pam_passwdqc should probably be either updated or removed. The version we have is ten years old. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Time to bump default VM_SWZONE_SIZE_MAX?
Colin Percival cperc...@freebsd.org writes: If I'm understanding things correctly, the maxswzone value -- set by the kern.maxswzone loader tunable or to VM_SWZONE_SIZE_MAX by default -- should be approximately 9 MiB per GiB of swap space. Far less, in fact. As mentioned in loader(8), the default 32 MB limit is enough for slightly more than 7 GB of swap space - assuming 100% efficient use of swblocks. The man page recommends not using more than half the theoretical limit, or, with 16 pages per swblock, 1 maxswzone x s --- x --- 2 16 where s = 276 on 32-bit systems and 288 on 64-bit systems. The current default for VM_SWZONE_SIZE_MAX was set in August 2002 to 32 MiB; meaning that anyone who wants to use more than ~ 3.5 GB of swap space ought to set kern.maxswzone in /boot/loader.conf. Is it time to increase this default on amd64? (I understand that keeping the value low on i386 is important due to KVA limitations, but amd64 has far more address space available...) There is no reason to keep this limit at all. The algorithm used to size the zone is physpages / 2 * sizeof(struct swblock) or maxswzone, whichever is smaller where maxswzone == VM_SWZONE_SIZE_MAX unless kern.maxswzone was set in loader.conf. On amd64, the cutoff point is slightly below 1 GB of physical memory (233,016 4,096-byte pages), so the limit doesn't help machines that actually need to conserve memory, and it hurts machines that have plenty of it and therefore also plenty of swap (assuming the user followed the old twice the amount of RAM rule of thumb). DES -- Dag-Erling Smørgrav - d...@des.no Index: sys/boot/common/loader.8 === --- sys/boot/common/loader.8 (revision 238711) +++ sys/boot/common/loader.8 (working copy) @@ -615,14 +615,16 @@ Limits the amount of KVM to be used to hold swap meta information, which directly governs the maximum amount of swap the system can support. -This value is specified in bytes of KVA space -and defaults to 32MBytes on i386 and amd64. +This value is specified in bytes of KVA space. +If no value is provided, the system allocates +enough memory to handle an amount of swap +that corresponds to eight times the amount of +physical memory present in the system. +.Pp Care should be taken to not reduce this value such that the actual -amount of configured swap exceeds 1/2 the -kernel-supported swap. -The default of 32MB allows -the kernel to support a maximum of ~7GB of swap. +amount of configured swap exceeds the amount +supported by the kernel. Only change this parameter if you need to greatly extend the KVM reservation for other resources such as the Index: sys/amd64/include/param.h === --- sys/amd64/include/param.h (revision 238711) +++ sys/amd64/include/param.h (working copy) @@ -123,14 +123,6 @@ #define KSTACK_GUARD_PAGES 1 /* pages of kstack guard; 0 disables */ /* - * Ceiling on amount of swblock kva space, can be changed via - * the kern.maxswzone /boot/loader.conf variable. - */ -#ifndef VM_SWZONE_SIZE_MAX -#define VM_SWZONE_SIZE_MAX (32 * 1024 * 1024) -#endif - -/* * Mach derived conversion macros */ #define round_page(x) unsigned long)(x)) + PAGE_MASK) ~(PAGE_MASK)) Index: sys/i386/include/param.h === --- sys/i386/include/param.h (revision 238711) +++ sys/i386/include/param.h (working copy) @@ -123,14 +123,6 @@ #define KSTACK_GUARD_PAGES 1 /* pages of kstack guard; 0 disables */ /* - * Ceiling on amount of swblock kva space, can be changed via - * the kern.maxswzone /boot/loader.conf variable. - */ -#ifndef VM_SWZONE_SIZE_MAX -#define VM_SWZONE_SIZE_MAX (32 * 1024 * 1024) -#endif - -/* * Ceiling on size of buffer cache (really only effects write queueing, * the VM page cache is not effected), can be changed via * the kern.maxbcache /boot/loader.conf variable. ___ 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: swp_pager_meta_build DoS printf
Sergey Kandaurov pluk...@gmail.com writes: What about this patch? It enables to ratelimit the printf. I have a different patch that just prints one message when swzone is exhausted and another when more space becomes available. However, we might want to combine the two, so that it periodically prints a message as long as swzone is exhausted. DES -- Dag-Erling Smørgrav - d...@des.no Index: sys/vm/swap_pager.c === --- sys/vm/swap_pager.c (revision 238711) +++ sys/vm/swap_pager.c (working copy) @@ -1804,6 +1804,7 @@ static void swp_pager_meta_build(vm_object_t object, vm_pindex_t pindex, daddr_t swapblk) { + static volatile int exhausted; struct swblock *swap; struct swblock **pswap; int idx; @@ -1847,7 +1848,9 @@ mtx_unlock(swhash_mtx); VM_OBJECT_UNLOCK(object); if (uma_zone_exhausted(swap_zone)) { -printf(swap zone exhausted, increase kern.maxswzone\n); +if (atomic_cmpset_rel_int(exhausted, 0, 1)) + printf(swap zone exhausted, + increase kern.maxswzone\n); vm_pageout_oom(VM_OOM_SWAPZ); pause(swzonex, 10); } else @@ -1856,6 +1859,9 @@ goto retry; } + if (atomic_cmpset_rel_int(exhausted, 1, 0)) + printf(swap zone ok\n); + swap-swb_hnext = NULL; swap-swb_object = object; swap-swb_index = pindex ~(vm_pindex_t)SWAP_META_MASK; ___ 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: Time to bump default VM_SWZONE_SIZE_MAX?
Slightly better patch (improved documentation) DES -- Dag-Erling Smørgrav - d...@des.no Index: sys/boot/common/loader.8 === --- sys/boot/common/loader.8 (revision 239239) +++ sys/boot/common/loader.8 (working copy) @@ -613,17 +613,26 @@ for details. .It Va kern.maxswzone Limits the amount of KVM to be used to hold swap -meta information, which directly governs the -maximum amount of swap the system can support. -This value is specified in bytes of KVA space -and defaults to 32MBytes on i386 and amd64. -Care should be taken -to not reduce this value such that the actual -amount of configured swap exceeds 1/2 the -kernel-supported swap. -The default of 32MB allows -the kernel to support a maximum of ~7GB of swap. -Only change +metadata, which directly governs the +maximum amount of swap the system can support, +at the rate of approximately 200 MB of swap space +per 1 MB of metadata. +This value is specified in bytes of KVA space. +If no value is provided, the system allocates +enough memory to handle an amount of swap +that corresponds to eight times the amount of +physical memory present in the system. +.Pp +Note that swap metadata can be fragmented, +which means that the system can run out of +space before it reaches the theoretical limit. +Therefore, care should be taken to not configure +more swap than approximately half of the +theoretical maximum. +.Pp +Running out of space for swap metadata can leave +the system in an unrecoverable state. +Therefore, you should only change this parameter if you need to greatly extend the KVM reservation for other resources such as the buffer cache or Index: sys/amd64/include/param.h === --- sys/amd64/include/param.h (revision 239239) +++ sys/amd64/include/param.h (working copy) @@ -123,14 +123,6 @@ #define KSTACK_GUARD_PAGES 1 /* pages of kstack guard; 0 disables */ /* - * Ceiling on amount of swblock kva space, can be changed via - * the kern.maxswzone /boot/loader.conf variable. - */ -#ifndef VM_SWZONE_SIZE_MAX -#define VM_SWZONE_SIZE_MAX (32 * 1024 * 1024) -#endif - -/* * Mach derived conversion macros */ #define round_page(x) unsigned long)(x)) + PAGE_MASK) ~(PAGE_MASK)) Index: sys/i386/include/param.h === --- sys/i386/include/param.h (revision 239239) +++ sys/i386/include/param.h (working copy) @@ -123,14 +123,6 @@ #define KSTACK_GUARD_PAGES 1 /* pages of kstack guard; 0 disables */ /* - * Ceiling on amount of swblock kva space, can be changed via - * the kern.maxswzone /boot/loader.conf variable. - */ -#ifndef VM_SWZONE_SIZE_MAX -#define VM_SWZONE_SIZE_MAX (32 * 1024 * 1024) -#endif - -/* * Ceiling on size of buffer cache (really only effects write queueing, * the VM page cache is not effected), can be changed via * the kern.maxbcache /boot/loader.conf variable. ___ 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: swp_pager_meta_build DoS printf
John Baldwin j...@freebsd.org writes: I think DES has a newer variant of this now? Committed, along with an additional patch that warns you if you configure more swap than the pager can handle. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Time to bump default VM_SWZONE_SIZE_MAX?
John Baldwin j...@freebsd.org writes: Hmm, this is not true on i386 where the problem is not just the physical RAM required, but also address space. (The swap zone is all mapped into KVA even if it isn't used.) This is why Alan's e-mail specifically mentioned amd64, ia64, etc. but not i386 in his list. I think i386 still needs this limit, and I think your commit jumped the gun a bit. How about we reinstate the limit on i386, but increase it to 64 MB? That would increase the theoretical maximum to ~15 GB. People with 8 GB swap would get a warning, but would be unlikely to run into trouble. (or we could increase the limit to 72351744 bytes, which is the precise amount required to support 16 GB) DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Time to bump default VM_SWZONE_SIZE_MAX?
John Baldwin j...@freebsd.org writes: Note that on i386 you can't get more than 4GB of RAM without PAE, and if you have any modern x86 box with 4GB of RAM, you are most likely running amd64 on it, not i386. I think i386 would be fine to just keep the limit it had. The limit we had was insufficient for 8 GB of swap. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Time to bump default VM_SWZONE_SIZE_MAX?
John Baldwin j...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no writes: The limit we had was insufficient for 8 GB of swap. In absolute or practical terms? This whole thing started because I have a machine with 8 GB swap that ran out of swzone. At this point i386 is going to be used on smaller systems (e.g. netbooks, etc.), not servers that have lots of swap. I don't think it's unreasonable for an i386 box to be maxed out on RAM (4 GB) and have twice that amount of swap. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Time to bump default VM_SWZONE_SIZE_MAX?
Dag-Erling Smørgrav d...@des.no writes: (or we could increase the limit to 72351744 bytes, which is the precise amount required to support 16 GB) Correction, 36175872 - there are actually 32 pages per entry, not 16. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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
Removing firewire support from GENERIC
Firewire is - a significant security risk - an obstacle to functining suspend / resume on many systems - rapidly becoming obsolete - available as a module The attached patch removes it from GENERIC across the board. Any serious objections before I commit it to head? DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Removing firewire support from GENERIC
Once more, with patch. DES -- Dag-Erling Smørgrav - d...@des.no Index: amd64/conf/GENERIC === --- amd64/conf/GENERIC (revision 241722) +++ amd64/conf/GENERIC (working copy) @@ -317,15 +317,6 @@ device ukbd # Keyboard device umass # Disks/Mass storage - Requires scbus and da -# FireWire support -device firewire # FireWire bus code -# sbp(4) works for some systems but causes boot failure on others -#device sbp # SCSI over FireWire (Requires scbus and da) -device fwe # Ethernet over FireWire (non-standard!) -device fwip # IP over FireWire (RFC 2734,3146) -device dcons # Dumb console driver -device dcons_crom # Configuration ROM for dcons - # Sound support device sound # Generic sound driver (required) device snd_cmi # CMedia CMI8338/CMI8738 Index: i386/conf/GENERIC === --- i386/conf/GENERIC (revision 241722) +++ i386/conf/GENERIC (working copy) @@ -331,15 +331,6 @@ device ukbd # Keyboard device umass # Disks/Mass storage - Requires scbus and da -# FireWire support -device firewire # FireWire bus code -# sbp(4) works for some systems but causes boot failure on others -#device sbp # SCSI over FireWire (Requires scbus and da) -device fwe # Ethernet over FireWire (non-standard!) -device fwip # IP over FireWire (RFC 2734,3146) -device dcons # Dumb console driver -device dcons_crom # Configuration ROM for dcons - # Sound support device sound # Generic sound driver (required) device snd_cmi # CMedia CMI8338/CMI8738 Index: ia64/conf/GENERIC === --- ia64/conf/GENERIC (revision 241722) +++ ia64/conf/GENERIC (working copy) @@ -77,7 +77,6 @@ options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones # Various busses -device firewire # FireWire bus code device miibus # MII bus support (Ethernet) device pci # PCI bus support device scbus # SCSI bus (required for ATA/SCSI) Index: pc98/conf/GENERIC === --- pc98/conf/GENERIC (revision 241722) +++ pc98/conf/GENERIC (working copy) @@ -270,7 +270,6 @@ #device zyd # ZyDAS zd1211/zd1211b wireless NICs # FireWire support -#device firewire # FireWire bus code #device sbp # SCSI over FireWire (Requires scbus and da) #device fwe # Ethernet over FireWire (non-standard!) Index: powerpc/conf/GENERIC === --- powerpc/conf/GENERIC (revision 241722) +++ powerpc/conf/GENERIC (working copy) @@ -180,12 +180,6 @@ options IEEE80211_SUPPORT_MESH options AH_SUPPORT_AR5416 -# FireWire support -device firewire # FireWire bus code -# sbp(4) works for some systems but causes boot failure on others -device sbp # SCSI over FireWire (Requires scbus and da) -device fwe # Ethernet over FireWire (non-standard!) - # Misc device iicbus # I2C bus code device kiic # Keywest I2C Index: sparc64/conf/GENERIC === --- sparc64/conf/GENERIC (revision 241722) +++ sparc64/conf/GENERIC (working copy) @@ -238,15 +238,6 @@ device ukbd # Keyboard device umass # Disks/Mass storage - Requires scbus and da -# FireWire support -device firewire # FireWire bus code -# sbp(4) works for some systems but causes boot failure on others -#device sbp # SCSI over FireWire (Requires scbus and da) -device fwe # Ethernet over FireWire (non-standard!) -device fwip # IP over FireWire (RFC 2734,3146) -device dcons # Dumb console driver -device dcons_crom # Configuration ROM for dcons - # Sound support device sound # Generic sound driver (required) device snd_audiocs # Crystal Semiconductor CS4231 ___ 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 sparc64/sparc64
FreeBSD Tinderbox tinder...@freebsd.org writes: In file included from /src/sys/dev/e1000/if_em.c:400: /src/sys/dev/netmap/if_em_netmap.h: In function 'em_netmap_rxsync': /src/sys/dev/netmap/if_em_netmap.h:332: warning: dereferencing 'void *' pointer /src/sys/dev/netmap/if_em_netmap.h:332: error: request for member 'dt_mt' in something not a structure or union *** Error code 1 I made a mistake when I added support for additional LINT kernels (e.g. LINT-NOINET) so the additional kernels got built, but plain LINT didn't. As a result, this error has gone unnoticed by the tinderbox, even though it's been there for quite a while (or so I've been told). DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: openpam oddity?
Michael Butler i...@protected-networks.net writes: Any ideas why courier-authdaemon is now reporting .. authdaemond: in openpam_dynamic(): No error: 0 authdaemond: in openpam_load_module(): no pam_unix.so found I've recompiled libpam and courier from scratch :-( Can you ktrace courier-authdaemon? # env LD_UTRACE /usr/local/etc/rc.d/courier-authdaemond restart # ktrace -di -tcntu -p $(cat /var/run/authdaemond/pid) then reproduce the error, then # /usr/local/etc/rc.d/courier-authdaemond restart to stop the trace, and # kdump courier-authdaemond-trace.txt to translate it to human-readable form. The trace will *not* include any passwords, just a list of system calls, filename lookups and linker operations. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Is it possible to make subr_acl_nfs4 and subr_acl_posix1e disabled?
Adrian Chadd adr...@freebsd.org writes: Since I'm not using NFS or UFS_ACL, I wondered if that code required. It turns out I can just build a kernel with those two disabled. Would it be possible to remove them from standard and make them optional? Or is there a reason to keep it in base? I would be very annoyed if it were no longer possible to netboot GENERIC... DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: couldn't log on to my -CURRENT machine after upgrade to latest PAM
Don Lewis truck...@freebsd.org writes: The documentation says that /etc/pam.conf is only used if /etc/pam.d/service-name isn't found, and the code appears to agree with that, however this doesn't seem to be working as expected after the latest import of PAM. The culprit was this commit: http://trac.des.no/openpam/changeset/487/trunk/lib/openpam_configure.c However, I'm not confident that simply reverting this commit is the right way to go. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: couldn't log on to my -CURRENT machine after upgrade to latest PAM
Don Lewis truck...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no writes: The culprit was this commit: http://trac.des.no/openpam/changeset/487/trunk/lib/openpam_configure.c However, I'm not confident that simply reverting this commit is the right way to go. Thanks for the detective work. It looks to me like the bug is caused by the change in the openpam_parse_chain() return value. In the previous code it returned the value of count, which I would guess was greater than zero if it found something. In that case, the for loop in openpam_load_chain() would be terminated because r != 0. In the new code, openpam_parse_chain() will return PAM_SUCCESS if it found something, and the loop in openpam_load_chain() will go through another iteration because ret == PAM_SUCCESS. Thank you, Captain Obvious. I am still not confident that simply reverting this commit is the right way to go, because it discards valuable information when an error occurs, especially if an error occurs while parsing an include. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: couldn't log on to my -CURRENT machine after upgrade to latest PAM
Don Lewis truck...@freebsd.org writes: After staring at the code a lot more, I see your point about the loss of information. The problem is that openpam_parse_chain() returns PAM_SUCCESS whether or not if found anything, but we want the loop to terminate when either an error is detected or if openpam_parse_chain() actually found something. Maybe changing the loop exit to something like this would work: if (ret != PAM_SUCCESS || pamh-chains[facility] != NULL) return (ret); The simplest fix for now is probably to revert r487; it applies cleanly except for the first hunk, which is easy to apply manually. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Is it possible to make subr_acl_nfs4 and subr_acl_posix1e disabled?
Adrian Chadd adr...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no writes: I would be very annoyed if it were no longer possible to netboot GENERIC... I don't want to break that. :) I Just don't want to compile it in unless I'm using NFS/ZFS, and on my 4MB flash boards I'm not booting w/ NFS compiled in statically.. Sorry, I just realized that I read the text of your message but not the subject; I thought you were proposing to remove NFS from GENERIC. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: couldn't log on to my -CURRENT machine after upgrade to latest PAM
If at any point in this conversation I seemed to make _no sense at all_, it was because I conflated it with a completely different OpenPAM issue (error reporting in openpam_dynamic.c) which has been on my mind lately. Sorry about that. I will attempt to address both issues in the next release, which I intend to roll in February. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: couldn't log on to my -CURRENT machine after upgrade to latest PAM
Could you please try this: # cd /usr/src/contrib # mv openpam openpam.orig # svn export svn://svn.des.no/openpam/trunk@526 openpam # cd ../lib/libpam # make depend make all make install In addition to the pam.conf issue, the major changes relative to head are reduced log spam, improved log messages in certain error conditions, and a different default password prompt for remote logins. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: couldn't log on to my -CURRENT machine after upgrade to latest PAM
Don Lewis truck...@freebsd.org writes: building shared library libpam.so.5 make: don't know how to make openpam.3. Stop *** Error code 2 Ah, yes, the man pages are generated during the release process, so you either have to copy them over from the original contrib/openpam directory (or export the new sources on top of the existing directory) or build with -DNO_MAN. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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
Retiring non-mpsafe filesystems (was: Re: svn commit: r227333 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/kern sys/mips/conf sys/pc98/conf sys/powerpc/conf sys/sp
Attilio Rao atti...@freebsd.org writes: In one month I'm going to disable VFS_ALLOW_NONMPSAFE by defaults in order to see how well the users do with this option down. At the present times this means that from 1st March you won't be able to mount smbfs or ntfs volumes, for example. Hmm, wasn't there a GSoC project to reimplement NTFS? DES -- Dag-Erling Smørgrav - d...@des.no ___ 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 mips/mips
Mike Tancsa m...@sentex.net writes: Doug Barton do...@freebsd.org writes: Thanks for confirming. I also forgot to mention that all the related changes were made in the same commit, so I'm not sure what the issue could have been. The logs / progress are visible at http://tinderbox.freebsd.org/ It looks like pc98 i386 built just fine recently. Not sure why the mips build keeps failing so much. des from .no would know :) I don't know the details, but ISTR being told on IRC that it was a known binutils bug, and that the patch for it is under GPL3. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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 mips/mips
Garrett Cooper yaneg...@gmail.com writes: From what I saw it seems to be localized to the tinderbox host environment because I don't run into this issue with a copy of CURRENT compiled from r233913 sources. There is nothing special about the tinderbox host environment, it's a quad-core Phenom running 8.3-STABLE and you can see the exact commands and environment variables used at the top of the log. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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