Re: [current tinderbox] failure on alpha/alpha

2003-08-20 Thread Dag-Erling Smørgrav
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

2003-08-21 Thread Dag-Erling Smørgrav
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

2003-09-04 Thread Dag-Erling Smørgrav
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

2003-09-04 Thread Dag-Erling Smørgrav
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

2003-09-09 Thread Dag-Erling Smørgrav
[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

2003-09-09 Thread Dag-Erling Smørgrav
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

2003-09-10 Thread Dag-Erling Smørgrav
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

2003-09-10 Thread Dag-Erling Smørgrav
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

2003-09-10 Thread Dag-Erling Smørgrav
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

2003-09-11 Thread Dag-Erling Smørgrav
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

2003-09-13 Thread Dag-Erling Smørgrav
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

2003-09-16 Thread Dag-Erling Smørgrav
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

2003-09-17 Thread Dag-Erling Smørgrav
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

2003-09-17 Thread Dag-Erling Smørgrav
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

2003-09-17 Thread Dag-Erling Smørgrav
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

2003-09-17 Thread Dag-Erling Smørgrav
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

2003-09-19 Thread Dag-Erling Smørgrav
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

2003-09-19 Thread Dag-Erling Smørgrav
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)

2003-09-28 Thread Dag-Erling Smørgrav
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

2003-10-03 Thread Dag-Erling Smørgrav
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

2003-10-10 Thread Dag-Erling Smørgrav
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

2003-10-10 Thread Dag-Erling Smørgrav
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

2003-10-11 Thread Dag-Erling Smørgrav
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

2003-10-12 Thread Dag-Erling Smørgrav
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

2003-10-19 Thread Dag-Erling Smørgrav
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

2003-10-21 Thread Dag-Erling Smørgrav
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

2003-07-02 Thread Dag-Erling Smørgrav
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

2003-07-10 Thread Dag-Erling Smørgrav
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

2003-07-15 Thread Dag-Erling Smørgrav
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

2003-07-15 Thread Dag-Erling Smørgrav
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

2003-07-15 Thread Dag-Erling Smørgrav
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!

2003-07-18 Thread Dag-Erling Smørgrav
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

2003-07-18 Thread Dag-Erling Smørgrav
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

2003-07-21 Thread Dag-Erling Smørgrav
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

2003-07-21 Thread Dag-Erling Smørgrav
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?

2003-07-22 Thread Dag-Erling Smørgrav
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

2003-08-01 Thread Dag-Erling Smørgrav
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

2003-08-02 Thread Dag-Erling Smørgrav
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

2003-08-04 Thread Dag-Erling Smørgrav
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

2003-08-04 Thread Dag-Erling Smørgrav
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

2003-08-14 Thread Dag-Erling Smørgrav
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?

2003-03-16 Thread Dag-Erling Smørgrav
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

2003-03-20 Thread Dag-Erling Smørgrav
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?

2003-03-18 Thread Dag-Erling Smørgrav
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?

2003-03-18 Thread Dag-Erling Smørgrav
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

2003-03-19 Thread Dag-Erling Smørgrav
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?

2003-03-21 Thread Dag-Erling Smørgrav
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

2003-03-22 Thread Dag-Erling Smørgrav
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

2003-03-30 Thread Dag-Erling Smørgrav
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

2013-08-23 Thread Dag-Erling Smørgrav
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

2013-09-08 Thread Dag-Erling Smørgrav
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

2013-09-09 Thread Dag-Erling Smørgrav
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

2013-09-09 Thread Dag-Erling Smørgrav
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

2013-09-11 Thread Dag-Erling Smørgrav
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

2013-09-11 Thread Dag-Erling Smørgrav
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

2013-09-14 Thread Dag-Erling Smørgrav
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

2013-09-15 Thread Dag-Erling Smørgrav
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?

2013-09-16 Thread Dag-Erling Smørgrav
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

2013-09-23 Thread Dag-Erling Smørgrav
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?

2013-09-24 Thread Dag-Erling Smørgrav
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

2013-11-12 Thread Dag-Erling Smørgrav
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

2013-11-12 Thread Dag-Erling Smørgrav
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

2011-09-27 Thread Dag-Erling Smørgrav
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

2011-09-28 Thread Dag-Erling Smørgrav
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

2011-09-30 Thread Dag-Erling Smørgrav
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

2011-10-12 Thread Dag-Erling Smørgrav
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)

2011-10-13 Thread Dag-Erling Smørgrav
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

2011-10-13 Thread Dag-Erling Smørgrav
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)

2011-10-13 Thread Dag-Erling Smørgrav
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)

2011-10-13 Thread Dag-Erling Smørgrav
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)

2011-10-13 Thread Dag-Erling Smørgrav
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

2011-10-13 Thread Dag-Erling Smørgrav
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

2011-10-13 Thread Dag-Erling Smørgrav
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)

2011-10-14 Thread Dag-Erling Smørgrav
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

2011-10-19 Thread Dag-Erling Smørgrav
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

2011-10-21 Thread Dag-Erling Smørgrav
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

2012-07-14 Thread Dag-Erling Smørgrav
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?

2012-08-14 Thread Dag-Erling Smørgrav
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

2012-08-14 Thread Dag-Erling Smørgrav
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?

2012-08-14 Thread Dag-Erling Smørgrav
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

2012-08-16 Thread Dag-Erling Smørgrav
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?

2012-08-24 Thread Dag-Erling Smørgrav
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?

2012-08-24 Thread Dag-Erling Smørgrav
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?

2012-08-25 Thread Dag-Erling Smørgrav
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?

2012-08-27 Thread Dag-Erling Smørgrav
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

2012-10-19 Thread Dag-Erling Smørgrav
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

2012-10-19 Thread Dag-Erling Smørgrav
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

2011-12-18 Thread Dag-Erling Smørgrav
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?

2011-12-18 Thread Dag-Erling Smørgrav
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?

2012-01-05 Thread Dag-Erling Smørgrav
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

2012-01-09 Thread Dag-Erling Smørgrav
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

2012-01-09 Thread Dag-Erling Smørgrav
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

2012-01-09 Thread Dag-Erling Smørgrav
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?

2012-01-09 Thread Dag-Erling Smørgrav
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

2012-01-10 Thread Dag-Erling Smørgrav
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

2012-01-10 Thread Dag-Erling Smørgrav
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

2012-01-12 Thread Dag-Erling Smørgrav
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

2012-01-30 Thread Dag-Erling Smørgrav
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

2012-04-05 Thread Dag-Erling Smørgrav
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

2012-04-05 Thread Dag-Erling Smørgrav
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


  1   2   3   4   5   >