Re: openbsd-current: cannot suspend -return from zzz-
I'm now using lastest BIOS: bios0: vendor American Megatrends Inc. version 1605 date 10/25/2012 exactly same behavior in all tests. On Sun, Apr 13, 2014 at 11:21 PM, Tomas Bodzar tomas.bod...@gmail.com wrote: On Sun, Apr 13, 2014 at 3:00 PM, Abel Abraham Camarillo Ojeda acam...@verlet.org wrote: On Tue, Apr 8, 2014 at 9:44 PM, Abel Abraham Camarillo Ojeda acam...@verlet.org wrote: well, I didn't mentioned it I already tried that -disable radeondrm- with -current, didn't work, will try again to provide log file... As soon as I can get home ... On Tue, Apr 8, 2014 at 5:46 PM, Mike Larkin mlar...@azathoth.net wrote: On Tue, Apr 08, 2014 at 05:30:59PM -0500, Abel Abraham Camarillo Ojeda wrote: will provide dmesg from 5.3, 'zzz' works in 5.3 -with or without serial console- 'zzz' dont works in 5.4 -with or without serial console- zzz dont works in 5.5~ with or without serial console zzz dont works in -current with or without serial console I was trying to build some kernels between 5.3 and 5.4 to see when this machine breaks, had no time to do it though... Thanks, this information is helpful. Can you try one test with disabled radeondrm? config -ef /bsd disable radeondrm quit -ml I still haven't got time to test 5.3 again - some of my disks died-, but when I push the power button in my desktop and have a serial console I can get a ddb prompt if I previously set ddb.console=1, now I inline -and attach- ddb's dmesg, ps and trace post -failed- resume. Disabling radeondrm* shows no changes -with radeondrm0 enabled I just don't get any output in screen (with or without serial console) after resuming (press power button in case)-. In current as april 3: The problems evidences in ddb's dmesg -but not in serial console directly-: ahci0: device on port 1 didn't come ready, TFD: 0x150 Any ideas how to further debug? Did you already tried with different BIOS? Because you have version 0901 on your motherboard, but there are others available... M5A97 BIOS 1102 1.Improve system stability. 2.Enhance compatibility with some USB devices. 3.Patch system hanged when use AM3 1090T or 1100T CPU. M5A97 BIOS 1208 Improve system stability. M5A97 BIOS 1503 1.Improve system stability. 2.Enhance compatibility with some USB devices. M5A97 BIOS 1605 Improve system stability. Thanks. (gmail will surely mangle the next text, see attached file for verbatim:) Script started on Sun Apr 13 07:34:05 2014 # cu -l cua01 Connected OpenBSD/amd64 BOOT 3.28 boot /bsd.sp -s \|/-\|/booting sr0a:/bsd.sp: -\|/-7690684\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|+2116940/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/+1096160-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|+0+612448 [100+554640/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-+368743\|/-\|/-\|/-\|/-\|/-\|/]=0xfde300 entry point at 0x10001e0 [7205c766, 3404, 24448b12, 4ca0a304] [ using 924320 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2014 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.5-current (GENERIC) #47: Thu Apr 3 16:28:31 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 17124126720 (16330MB) avail mem = 16659578880 (15887MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeed90 (55 entries) bios0: vendor American Megatrends Inc. version 0901 date 11/24/2011 bios0: ASUSTeK COMPUTER INC. M5A97 acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG HPET IVRS SSDT acpi0: wakeup devices SBAZ(S4) PS2K(S3) PS2M(S3) UAR1(S4) P0PC(S4) UHC1(S4) UHC2(S4) USB3(S4) UHC4(S4) USB5(S4) UHC6(S4) UHC7(S4) PE20(S4) PE21(S4) PE22(S4) PE23(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Phenom(tm) II X4 955 Processor, 3211.07 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,NODEID,ITSC cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache, 6MB
Re: mo junk mo problems
On Sun, Apr 13, 2014 at 06:34:17PM -0400, Ted Unangst wrote:
I took another look at the way junk works in malloc, and there's a few
improvements I'd like to make.
1. Remove the Z option. In general, I think malloc options should make
programs crash more, not less. This option is a bandaid, but looks
like something that makes things better. (Anecdotally, I've seen
people turn it on because it somehow sounded even better than J.
Incorrect.)
2. Default to something halfway to J. When we free a chunk, always
overwrite it. When we free a larger allocation, just overwrite the
front of it. This has the desirable property of wiping small freed
secrets and data structures, but won't have the performance impact of
wiping large buffers (or faulting in pages that weren't even touched).
J turns it up to junking on malloc() as before, and j turns it off.
I have't been able to build perl reliably with this diff, but haven't
ruled out the 5.18 update either.
Idea looks good...
Some remarks:
- always junk half a page? Maybe that's a tad over done, athough it
might be relatively cheap since your writing the page anyway.
- Chunks are now always completely junked on free, maybe a bit
overdone for malloc_junk = 1
- if we are freeing a large region, it does not end up in the cache,
so junking (part of) it is a waste of effort. (That already is the
case for current, you are not introducing that).
- What about 'j'? Do we want it to cancel a J or always disable
junking?
This need some timing/profiling on various archs to get some idea on
the costs.
-Otto
Index: malloc.3
===
RCS file: /cvs/src/lib/libc/stdlib/malloc.3,v
retrieving revision 1.73
diff -u -p -r1.73 malloc.3
--- malloc.3 18 Jul 2013 10:14:49 - 1.73
+++ malloc.3 13 Apr 2014 21:49:47 -
@@ -298,11 +298,6 @@ malloc_options = X;
.Pp
Note that this will cause code that is supposed to handle
out-of-memory conditions gracefully to abort instead.
-.It Cm Z
-.Dq Zero .
-Fill some junk into the area allocated (see
-.Cm J ) ,
-except for the exact length the user asked for, which is zeroed.
.It Cm
.Dq Half the cache size .
Decrease the size of the free page cache by a factor of two.
Index: malloc.c
===
RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v
retrieving revision 1.152
diff -u -p -r1.152 malloc.c
--- malloc.c 3 Apr 2014 16:18:11 - 1.152
+++ malloc.c 13 Apr 2014 21:05:11 -
@@ -167,7 +167,6 @@ struct malloc_readonly {
int malloc_move;/* move allocations to end of page? */
int malloc_realloc; /* always realloc? */
int malloc_xmalloc; /* xmalloc behaviour? */
- int malloc_zero;/* zero fill? */
size_t malloc_guard; /* use guard pages after allocations? */
u_int malloc_cache; /* free pages we cache */
#ifdef MALLOC_STATS
@@ -412,7 +411,7 @@ map(struct dir_info *d, size_t sz, int z
d-free_regions_size -= psz;
if (zero_fill)
memset(p, 0, sz);
- else if (mopts.malloc_junk
+ else if (mopts.malloc_junk == 2
mopts.malloc_freeunmap)
memset(p, SOME_FREEJUNK, sz);
return p;
@@ -431,7 +430,7 @@ map(struct dir_info *d, size_t sz, int z
d-free_regions_size -= psz;
if (zero_fill)
memset(p, 0, sz);
- else if (mopts.malloc_junk mopts.malloc_freeunmap)
+ else if (mopts.malloc_junk == 2 mopts.malloc_freeunmap)
memset(p, SOME_FREEJUNK, sz);
return p;
}
@@ -461,6 +460,7 @@ omalloc_init(struct dir_info **dp)
* Default options
*/
mopts.malloc_abort = 1;
+ mopts.malloc_junk = 1;
mopts.malloc_move = 1;
mopts.malloc_cache = MALLOC_DEFAULT_CACHE;
@@ -534,7 +534,7 @@ omalloc_init(struct dir_info **dp)
mopts.malloc_junk = 0;
break;
case 'J':
- mopts.malloc_junk = 1;
+ mopts.malloc_junk = 2;
break;
case 'n':
case 'N':
@@ -557,7 +557,8 @@ omalloc_init(struct dir_info **dp)
mopts.malloc_cache = MALLOC_DEFAULT_CACHE;
break;
case 'S':
- mopts.malloc_freeunmap = mopts.malloc_junk = 1;
+ mopts.malloc_freeunmap = 1;
+ mopts.malloc_junk =
Re: openbsd-current: cannot suspend -return from zzz-
On Mon, Apr 14, 2014 at 11:25 AM, Abel Abraham Camarillo Ojeda acam...@verlet.org wrote: I'm now using lastest BIOS: bios0: vendor American Megatrends Inc. version 1605 date 10/25/2012 exactly same behavior in all tests. These days machine without AHCI/ACPI is pretty useless so if you will disable it it may not panic, but will be pretty useless in many regards. You can try to collect details about ACPI on that particular machine with acpidump and either provide it directly to developer which is interested in that or post link to those outputs saved on some external service here in misc On Sun, Apr 13, 2014 at 11:21 PM, Tomas Bodzar tomas.bod...@gmail.com wrote: On Sun, Apr 13, 2014 at 3:00 PM, Abel Abraham Camarillo Ojeda acam...@verlet.org wrote: On Tue, Apr 8, 2014 at 9:44 PM, Abel Abraham Camarillo Ojeda acam...@verlet.org wrote: well, I didn't mentioned it I already tried that -disable radeondrm- with -current, didn't work, will try again to provide log file... As soon as I can get home ... On Tue, Apr 8, 2014 at 5:46 PM, Mike Larkin mlar...@azathoth.net wrote: On Tue, Apr 08, 2014 at 05:30:59PM -0500, Abel Abraham Camarillo Ojeda wrote: will provide dmesg from 5.3, 'zzz' works in 5.3 -with or without serial console- 'zzz' dont works in 5.4 -with or without serial console- zzz dont works in 5.5~ with or without serial console zzz dont works in -current with or without serial console I was trying to build some kernels between 5.3 and 5.4 to see when this machine breaks, had no time to do it though... Thanks, this information is helpful. Can you try one test with disabled radeondrm? config -ef /bsd disable radeondrm quit -ml I still haven't got time to test 5.3 again - some of my disks died-, but when I push the power button in my desktop and have a serial console I can get a ddb prompt if I previously set ddb.console=1, now I inline -and attach- ddb's dmesg, ps and trace post -failed- resume. Disabling radeondrm* shows no changes -with radeondrm0 enabled I just don't get any output in screen (with or without serial console) after resuming (press power button in case)-. In current as april 3: The problems evidences in ddb's dmesg -but not in serial console directly-: ahci0: device on port 1 didn't come ready, TFD: 0x150 Any ideas how to further debug? Did you already tried with different BIOS? Because you have version 0901 on your motherboard, but there are others available... M5A97 BIOS 1102 1.Improve system stability. 2.Enhance compatibility with some USB devices. 3.Patch system hanged when use AM3 1090T or 1100T CPU. M5A97 BIOS 1208 Improve system stability. M5A97 BIOS 1503 1.Improve system stability. 2.Enhance compatibility with some USB devices. M5A97 BIOS 1605 Improve system stability. Thanks. (gmail will surely mangle the next text, see attached file for verbatim:) Script started on Sun Apr 13 07:34:05 2014 # cu -l cua01 Connected OpenBSD/amd64 BOOT 3.28 boot /bsd.sp -s \|/-\|/booting sr0a:/bsd.sp: -\|/-7690684\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|+2116940/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/+1096160-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|+0+612448 [100+554640/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-+368743\|/-\|/-\|/-\|/-\|/-\|/]=0xfde300 entry point at 0x10001e0 [7205c766, 3404, 24448b12, 4ca0a304] [ using 924320 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2014 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.5-current (GENERIC) #47: Thu Apr 3 16:28:31 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 17124126720 (16330MB) avail mem = 16659578880 (15887MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeed90 (55 entries) bios0: vendor American Megatrends Inc. version 0901 date 11/24/2011 bios0: ASUSTeK COMPUTER INC. M5A97 acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG HPET IVRS SSDT acpi0: wakeup devices SBAZ(S4) PS2K(S3) PS2M(S3) UAR1(S4) P0PC(S4) UHC1(S4) UHC2(S4) USB3(S4) UHC4(S4) USB5(S4)
Re: openbsd-current: cannot suspend -return from zzz-
On Mon, Apr 14, 2014 at 6:02 AM, Tomas Bodzar tomas.bod...@gmail.com wrote: On Mon, Apr 14, 2014 at 11:25 AM, Abel Abraham Camarillo Ojeda acam...@verlet.org wrote: I'm now using lastest BIOS: bios0: vendor American Megatrends Inc. version 1605 date 10/25/2012 exactly same behavior in all tests. These days machine without AHCI/ACPI is pretty useless so if you will disable it it may not panic, but will be pretty useless in many regards. You can try to collect details about ACPI on that particular machine with acpidump and either provide it directly to developer which is interested in that or post link to those outputs saved on some external service here in misc disabling AHCI shows no improvement acpidump output attached as .tgz thanks. acpidump.tgz Description: GNU Zip compressed data
segfault in dhclient 5.4 please help
hello As far as i know, nothing change... but the machine is remote. v12-GW 14# /sbin/dhclient -l /run/dhclient.leases.trunk0 trunk0 DHCPDISCOVER on trunk0 to 255.255.255.255 port 67 interval 3 DHCPOFFER from 10.0.0.254 (96:4f:87:9c:ad:67) DHCPREQUEST on trunk0 to 255.255.255.255 port 67 DHCPACK from 10.0.0.254 (96:4f:87:9c:ad:67) Segmentation fault Apr 14 13:46:48 v12-GW dhclient[1810]: DHCPOFFER from 10.0.0.254 (96:4f:87:9c:ad:67) Apr 14 13:46:48 v12-GW dhclient[1810]: DHCPREQUEST on trunk0 to 255.255.255.255 port 67 Apr 14 13:46:48 v12-GW dhclient[1810]: DHCPACK from 10.0.0.254 (96:4f:87:9c:ad:67) Apr 14 13:46:48 v12-GW /bsd: arpresolve: 10.0.0.254: can't allocate llinfo ( i am using syslogc to read logs and the begining date is not in the buffer ) I work around setting ip statically on my trunk0 and unmonitor the trunk0 leases. everything s fine like this. Someone reboot the machine since, it didnt fix the problem. Of course because setting the ip manually works the 10.0.0.254 is in arp table. (i am setting trunk0 to the ip the dhcp server is giving 10.0.0.126) v12-GW 49# arp -a ? (10.0.0.1) at 16:00:40:da:39:d0 on trunk0 ? (10.0.0.254) at 96:4f:87:9c:ad:67 on trunk0 and the dhclient is getting leases on two other interfaces, no problem. As far as i understand dhclient does not like something about the mac address, i cannot do anymore test for a few hours (like ulimit -c unlimited and restart dhclient, wheres does it dump already ?) - - - - - OpenBSD 5.4 (GENERIC) #37: Tue Jul 30 12:05:01 MDT 2013 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Geode(TM) Integrated Processor by AMD PCS (AuthenticAMD 586-class) 499 MHz cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW real mem = 536408064 (511MB) avail mem = 516194304 (492MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 20/70/03, BIOS32 rev. 0 @ 0xfac40 pcibios0 at bios0: rev 2.0 @ 0xf/0x1 pcibios0: pcibios_get_intr_routing - function not supported pcibios0: PCI IRQ Routing information unavailable. pcibios0: PCI bus #1 is the last bus bios0: ROM list: 0xc8000/0xa800 cpu0 at mainbus0: (uniprocessor) amdmsr0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (bios) 0:20:0: io address conflict 0x6100/0x100 0:20:0: io address conflict 0x6200/0x200 pchb0 at pci0 dev 1 function 0 AMD Geode LX rev 0x33 glxsb0 at pci0 dev 1 function 2 AMD Geode LX Crypto rev 0x00: RNG AES vr0 at pci0 dev 6 function 0 VIA VT6105M RhineIII rev 0x96: irq 11, address 00:00:24:d0:8e:d0 ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr1 at pci0 dev 7 function 0 VIA VT6105M RhineIII rev 0x96: irq 5, address 00:00:24:d0:8e:d1 ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr2 at pci0 dev 8 function 0 VIA VT6105M RhineIII rev 0x96: irq 9, address 00:00:24:d0:8e:d2 ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr3 at pci0 dev 9 function 0 VIA VT6105M RhineIII rev 0x96: irq 12, address 00:00:24:d0:8e:d3 ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 ppb0 at pci0 dev 14 function 0 TI PCI2250 rev 0x02 pci1 at ppb0 bus 1 vr4 at pci1 dev 0 function 0 VIA VT6105M RhineIII rev 0x96: irq 10, address 00:00:24:cf:f5:a8 ukphy4 at vr4 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr5 at pci1 dev 1 function 0 VIA VT6105M RhineIII rev 0x96: irq 7, address 00:00:24:cf:f5:a9 ukphy5 at vr5 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr6 at pci1 dev 2 function 0 VIA VT6105M RhineIII rev 0x96: irq 10, address 00:00:24:cf:f5:aa ukphy6 at vr6 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr7 at pci1 dev 3 function 0 VIA VT6105M RhineIII rev 0x96: irq 7, address 00:00:24:cf:f5:ab ukphy7 at vr7 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 glxpcib0 at pci0 dev 20 function 0 AMD CS5536 ISA rev 0x03: rev 3, 32-bit 3579545Hz timer, watchdog, gpio, i2c gpio0 at glxpcib0: 32 pins iic0 at glxpcib0 pciide0 at pci0 dev 20 function 2 AMD CS5536 IDE rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 1: SanDisk SDCFH-4096 wd0: 1-sector PIO, LBA, 3825MB, 7835184 sectors wd0(pciide0:0:1): using PIO mode 4, DMA mode 2 pciide0: channel 1 ignored (disabled) ohci0 at pci0 dev 21 function 0 AMD CS5536 USB rev 0x02: irq 15, version 1.0, legacy support ehci0 at pci0 dev 21 function 1 AMD CS5536 USB rev 0x02: irq 15 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 AMD EHCI root hub rev 2.00/1.00 addr 1 isa0 at glxpcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console
malloc chunk info in region
Small tweak. Use a union, instead of casts. There's still casting for
the call to insert(), but I think this is a little better. Also use
the correct type for the insert() parameter.
Index: stdlib/malloc.c
===
RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v
retrieving revision 1.152
diff -u -p -r1.152 malloc.c
--- stdlib/malloc.c 3 Apr 2014 16:18:11 - 1.152
+++ stdlib/malloc.c 14 Apr 2014 17:37:21 -
@@ -94,7 +94,10 @@
struct region_info {
void *p;/* page; low bits used to mark chunks */
- uintptr_t size; /* size for pages, or chunk_info pointer */
+ union {
+ size_t size;/* size for pages */
+ struct chunk_info *info;/* chunk_info pointer */
+ };
#ifdef MALLOC_STATS
void *f;/* where allocated from */
#endif
@@ -737,7 +740,7 @@ alloc_chunk_info(struct dir_info *d, int
* non-MAP_FIXED mappings with hint 0 start at BRKSIZ.
*/
static int
-insert(struct dir_info *d, void *p, size_t sz, void *f)
+insert(struct dir_info *d, void *p, uintptr_t sz, void *f)
{
size_t index;
size_t mask;
@@ -985,7 +988,7 @@ free_bytes(struct dir_info *d, struct re
struct chunk_info *info;
int i;
- info = (struct chunk_info *)r-size;
+ info = r-info;
if (info-canary != d-canary1)
wrterror(chunk info corrupted, NULL);
cpsw device timeouts
I've been trying to track down what's causing the cpsw device timeouts on the
beaglebone and beaglebone black. As best I can tell disabling hardware
flow control does the trick. If you're able to recreate that issue
please test this diff and report your findings. Thanks.
cvs diff: Diffing sys/arch/armv7/omap/
Index: sys/arch/armv7/omap//if_cpsw.c
===
RCS file: /cvs/src/sys/arch/armv7/omap/if_cpsw.c,v
retrieving revision 1.21
diff -u -p -u -r1.21 if_cpsw.c
--- sys/arch/armv7/omap//if_cpsw.c 26 Nov 2013 20:33:11 -
1.21
+++ sys/arch/armv7/omap//if_cpsw.c 14 Apr 2014 17:37:27 -
@@ -816,6 +816,8 @@ cpsw_init(struct ifnet *ifp)
cpsw_write_4(sc, CPSW_CPDMA_SOFT_RESET, 1);
while(cpsw_read_4(sc, CPSW_CPDMA_SOFT_RESET) 1);
+
+ cpsw_write_4(sc, CPSW_SS_FLOW_CONTROL, 0);
for (i = 0; i 8; i++) {
cpsw_write_4(sc, CPSW_CPDMA_TX_HDP(i), 0);
Index: sys/arch/armv7/omap//if_cpswreg.h
===
RCS file: /cvs/src/sys/arch/armv7/omap/if_cpswreg.h,v
retrieving revision 1.5
diff -u -p -u -r1.5 if_cpswreg.h
--- sys/arch/armv7/omap//if_cpswreg.h 15 Nov 2013 14:31:52 -
1.5
+++ sys/arch/armv7/omap//if_cpswreg.h 14 Apr 2014 17:37:12 -
@@ -39,6 +39,7 @@
#define CPSW_SS_SOFT_RESET (CPSW_SS_OFFSET + 0x08)
#define CPSW_SS_STAT_PORT_EN (CPSW_SS_OFFSET + 0x0C)
#define CPSW_SS_PTYPE (CPSW_SS_OFFSET + 0x10)
+#define CPSW_SS_FLOW_CONTROl (CPSW_SS_OFFSET + 0x24)
#define CPSW_PORT_OFFSET 0x0100
#define CPSW_PORT_P_TX_PRI_MAP(p) (CPSW_PORT_OFFSET + 0x118 +
((p-1) * 0x100))
Re: malloc chunk info in region
On Mon, Apr 14, 2014 at 11:39 AM, Ted Unangst t...@tedunangst.com wrote:
Small tweak. Use a union, instead of casts. There's still casting for
the call to insert(), but I think this is a little better. Also use
the correct type for the insert() parameter.
Index: stdlib/malloc.c
===
RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v
retrieving revision 1.152
diff -u -p -r1.152 malloc.c
--- stdlib/malloc.c 3 Apr 2014 16:18:11 - 1.152
+++ stdlib/malloc.c 14 Apr 2014 17:37:21 -
@@ -94,7 +94,10 @@
struct region_info {
void *p;/* page; low bits used to mark chunks */
- uintptr_t size; /* size for pages, or chunk_info pointer */
+ union {
+ size_t size;/* size for pages */
+ struct chunk_info *info;/* chunk_info pointer */
+ };
#ifdef MALLOC_STATS
void *f;/* where allocated from */
#endif
@@ -737,7 +740,7 @@ alloc_chunk_info(struct dir_info *d, int
* non-MAP_FIXED mappings with hint 0 start at BRKSIZ.
*/
static int
-insert(struct dir_info *d, void *p, size_t sz, void *f)
+insert(struct dir_info *d, void *p, uintptr_t sz, void *f)
Doesn't it make sense for sz to stay a size_t in this case? it appears
to still be used as an offset in here, not a pointer. no?
{
size_t index;
size_t mask;
@@ -985,7 +988,7 @@ free_bytes(struct dir_info *d, struct re
struct chunk_info *info;
int i;
- info = (struct chunk_info *)r-size;
+ info = r-info;
if (info-canary != d-canary1)
wrterror(chunk info corrupted, NULL);
Re: segfault in dhclient 5.4 please help
On Mon, Apr 14, 2014 at 8:21 AM, sven falempin sven.falem...@gmail.com wrote: hello As far as i know, nothing change... but the machine is remote. v12-GW 14# /sbin/dhclient -l /run/dhclient.leases.trunk0 trunk0 DHCPDISCOVER on trunk0 to 255.255.255.255 port 67 interval 3 DHCPOFFER from 10.0.0.254 (96:4f:87:9c:ad:67) DHCPREQUEST on trunk0 to 255.255.255.255 port 67 DHCPACK from 10.0.0.254 (96:4f:87:9c:ad:67) Segmentation fault I am trying to get the core file of this priviledge separated daemon. # ulimit -c unlinited write to everyone on / and / sbin just during the test. i also change sysctl core nosuidcoredump to 0 (despair ..) I dont have gdb on the machine how to get the core of dhclient. I guess i will (try to) reproduce on a recent snashots, the dhcp server is dnsmasq. (i am using it to resolve local hostanmes) Apr 14 13:46:48 v12-GW dhclient[1810]: DHCPOFFER from 10.0.0.254 (96:4f:87:9c:ad:67) Apr 14 13:46:48 v12-GW dhclient[1810]: DHCPREQUEST on trunk0 to 255.255.255.255 port 67 Apr 14 13:46:48 v12-GW dhclient[1810]: DHCPACK from 10.0.0.254 (96:4f:87:9c:ad:67) Apr 14 13:46:48 v12-GW /bsd: arpresolve: 10.0.0.254: can't allocate llinfo ( i am using syslogc to read logs and the begining date is not in the buffer ) I work around setting ip statically on my trunk0 and unmonitor the trunk0 leases. everything s fine like this. Someone reboot the machine since, it didnt fix the problem. Of course because setting the ip manually works the 10.0.0.254 is in arp table. (i am setting trunk0 to the ip the dhcp server is giving 10.0.0.126) v12-GW 49# arp -a ? (10.0.0.1) at 16:00:40:da:39:d0 on trunk0 ? (10.0.0.254) at 96:4f:87:9c:ad:67 on trunk0 and the dhclient is getting leases on two other interfaces, no problem. As far as i understand dhclient does not like something about the mac address, i cannot do anymore test for a few hours (like ulimit -c unlimited and restart dhclient, wheres does it dump already ?) - - - - - OpenBSD 5.4 (GENERIC) #37: Tue Jul 30 12:05:01 MDT 2013 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Geode(TM) Integrated Processor by AMD PCS (AuthenticAMD 586-class) 499 MHz cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW real mem = 536408064 (511MB) avail mem = 516194304 (492MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 20/70/03, BIOS32 rev. 0 @ 0xfac40 pcibios0 at bios0: rev 2.0 @ 0xf/0x1 pcibios0: pcibios_get_intr_routing - function not supported pcibios0: PCI IRQ Routing information unavailable. pcibios0: PCI bus #1 is the last bus bios0: ROM list: 0xc8000/0xa800 cpu0 at mainbus0: (uniprocessor) amdmsr0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (bios) 0:20:0: io address conflict 0x6100/0x100 0:20:0: io address conflict 0x6200/0x200 pchb0 at pci0 dev 1 function 0 AMD Geode LX rev 0x33 glxsb0 at pci0 dev 1 function 2 AMD Geode LX Crypto rev 0x00: RNG AES vr0 at pci0 dev 6 function 0 VIA VT6105M RhineIII rev 0x96: irq 11, address 00:00:24:d0:8e:d0 ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr1 at pci0 dev 7 function 0 VIA VT6105M RhineIII rev 0x96: irq 5, address 00:00:24:d0:8e:d1 ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr2 at pci0 dev 8 function 0 VIA VT6105M RhineIII rev 0x96: irq 9, address 00:00:24:d0:8e:d2 ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr3 at pci0 dev 9 function 0 VIA VT6105M RhineIII rev 0x96: irq 12, address 00:00:24:d0:8e:d3 ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 ppb0 at pci0 dev 14 function 0 TI PCI2250 rev 0x02 pci1 at ppb0 bus 1 vr4 at pci1 dev 0 function 0 VIA VT6105M RhineIII rev 0x96: irq 10, address 00:00:24:cf:f5:a8 ukphy4 at vr4 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr5 at pci1 dev 1 function 0 VIA VT6105M RhineIII rev 0x96: irq 7, address 00:00:24:cf:f5:a9 ukphy5 at vr5 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr6 at pci1 dev 2 function 0 VIA VT6105M RhineIII rev 0x96: irq 10, address 00:00:24:cf:f5:aa ukphy6 at vr6 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr7 at pci1 dev 3 function 0 VIA VT6105M RhineIII rev 0x96: irq 7, address 00:00:24:cf:f5:ab ukphy7 at vr7 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 glxpcib0 at pci0 dev 20 function 0 AMD CS5536 ISA rev 0x03: rev 3, 32-bit 3579545Hz timer, watchdog, gpio, i2c gpio0 at glxpcib0: 32 pins iic0 at glxpcib0 pciide0 at pci0 dev 20 function 2 AMD CS5536 IDE rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 1: SanDisk SDCFH-4096 wd0: 1-sector PIO, LBA, 3825MB, 7835184 sectors wd0(pciide0:0:1):
Re: malloc chunk info in region
On Mon, Apr 14, 2014 at 11:54:32AM -0600, Bob Beck wrote:
On Mon, Apr 14, 2014 at 11:39 AM, Ted Unangst t...@tedunangst.com wrote:
Small tweak. Use a union, instead of casts. There's still casting for
the call to insert(), but I think this is a little better. Also use
the correct type for the insert() parameter.
Index: stdlib/malloc.c
===
RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v
retrieving revision 1.152
diff -u -p -r1.152 malloc.c
--- stdlib/malloc.c 3 Apr 2014 16:18:11 - 1.152
+++ stdlib/malloc.c 14 Apr 2014 17:37:21 -
@@ -94,7 +94,10 @@
struct region_info {
void *p;/* page; low bits used to mark chunks */
- uintptr_t size; /* size for pages, or chunk_info pointer */
+ union {
+ size_t size;/* size for pages */
+ struct chunk_info *info;/* chunk_info pointer */
+ };
#ifdef MALLOC_STATS
void *f;/* where allocated from */
#endif
@@ -737,7 +740,7 @@ alloc_chunk_info(struct dir_info *d, int
* non-MAP_FIXED mappings with hint 0 start at BRKSIZ.
*/
static int
-insert(struct dir_info *d, void *p, size_t sz, void *f)
+insert(struct dir_info *d, void *p, uintptr_t sz, void *f)
Doesn't it make sense for sz to stay a size_t in this case? it appears
to still be used as an offset in here, not a pointer. no?
Indeed, I don't see why you would change the type of the parameter here.
-Otto
{
size_t index;
size_t mask;
@@ -985,7 +988,7 @@ free_bytes(struct dir_info *d, struct re
struct chunk_info *info;
int i;
- info = (struct chunk_info *)r-size;
+ info = r-info;
if (info-canary != d-canary1)
wrterror(chunk info corrupted, NULL);
Re: cpsw device timeouts
whoops, small typo in the previous diff:
cvs diff: Diffing sys/arch/armv7/omap/
Index: sys/arch/armv7/omap//if_cpsw.c
===
RCS file: /cvs/src/sys/arch/armv7/omap/if_cpsw.c,v
retrieving revision 1.21
diff -u -p -u -r1.21 if_cpsw.c
--- sys/arch/armv7/omap//if_cpsw.c 26 Nov 2013 20:33:11 -
1.21
+++ sys/arch/armv7/omap//if_cpsw.c 14 Apr 2014 17:37:27 -
@@ -816,6 +816,8 @@ cpsw_init(struct ifnet *ifp)
cpsw_write_4(sc, CPSW_CPDMA_SOFT_RESET, 1);
while(cpsw_read_4(sc, CPSW_CPDMA_SOFT_RESET) 1);
+
+ cpsw_write_4(sc, CPSW_SS_FLOW_CONTROL, 0);
for (i = 0; i 8; i++) {
cpsw_write_4(sc, CPSW_CPDMA_TX_HDP(i), 0);
Index: sys/arch/armv7/omap//if_cpswreg.h
===
RCS file: /cvs/src/sys/arch/armv7/omap/if_cpswreg.h,v
retrieving revision 1.5
diff -u -p -u -r1.5 if_cpswreg.h
--- sys/arch/armv7/omap//if_cpswreg.h 15 Nov 2013 14:31:52 -
1.5
+++ sys/arch/armv7/omap//if_cpswreg.h 14 Apr 2014 18:08:52 -
@@ -39,6 +39,7 @@
#define CPSW_SS_SOFT_RESET (CPSW_SS_OFFSET + 0x08)
#define CPSW_SS_STAT_PORT_EN (CPSW_SS_OFFSET + 0x0C)
#define CPSW_SS_PTYPE (CPSW_SS_OFFSET + 0x10)
+#define CPSW_SS_FLOW_CONTROL (CPSW_SS_OFFSET + 0x24)
#define CPSW_PORT_OFFSET 0x0100
#define CPSW_PORT_P_TX_PRI_MAP(p) (CPSW_PORT_OFFSET + 0x118 +
((p-1) * 0x100))
Re: malloc chunk info in region
On Mon, Apr 14, 2014 at 20:09, Otto Moerbeek wrote: static int -insert(struct dir_info *d, void *p, size_t sz, void *f) +insert(struct dir_info *d, void *p, uintptr_t sz, void *f) Doesn't it make sense for sz to stay a size_t in this case? it appears to still be used as an offset in here, not a pointer. no? Indeed, I don't see why you would change the type of the parameter here. That is what the caller (with a chunk_info *) is casting it to.
Re: malloc chunk info in region
On Mon, Apr 14, 2014 at 02:21:27PM -0400, Ted Unangst wrote: On Mon, Apr 14, 2014 at 20:09, Otto Moerbeek wrote: static int -insert(struct dir_info *d, void *p, size_t sz, void *f) +insert(struct dir_info *d, void *p, uintptr_t sz, void *f) Doesn't it make sense for sz to stay a size_t in this case? it appears to still be used as an offset in here, not a pointer. no? Indeed, I don't see why you would change the type of the parameter here. That is what the caller (with a chunk_info *) is casting it to. there are two other calls with a size_t arg, and inside insert() the arg is directly stuffed into a field of the union which is size_t. -Otto
Re: segfault in dhclient 5.4 please help
On Mon, Apr 14, 2014 at 2:04 PM, sven falempin sven.falem...@gmail.com wrote: On Mon, Apr 14, 2014 at 8:21 AM, sven falempin sven.falem...@gmail.com wrote: hello As far as i know, nothing change... but the machine is remote. v12-GW 14# /sbin/dhclient -l /run/dhclient.leases.trunk0 trunk0 DHCPDISCOVER on trunk0 to 255.255.255.255 port 67 interval 3 DHCPOFFER from 10.0.0.254 (96:4f:87:9c:ad:67) DHCPREQUEST on trunk0 to 255.255.255.255 port 67 DHCPACK from 10.0.0.254 (96:4f:87:9c:ad:67) Segmentation fault I am trying to get the core file of this priviledge separated daemon. # ulimit -c unlinited write to everyone on / and / sbin just during the test. i also change sysctl core nosuidcoredump to 0 (despair ..) I dont have gdb on the machine how to get the core of dhclient. I guess i will (try to) reproduce on a recent snashots, the dhcp server is dnsmasq. (i am using it to resolve local hostanmes) Apr 14 13:46:48 v12-GW dhclient[1810]: DHCPOFFER from 10.0.0.254 (96:4f:87:9c:ad:67) Apr 14 13:46:48 v12-GW dhclient[1810]: DHCPREQUEST on trunk0 to 255.255.255.255 port 67 Apr 14 13:46:48 v12-GW dhclient[1810]: DHCPACK from 10.0.0.254 (96:4f:87:9c:ad:67) Apr 14 13:46:48 v12-GW /bsd: arpresolve: 10.0.0.254: can't allocate llinfo ( i am using syslogc to read logs and the begining date is not in the buffer ) I work around setting ip statically on my trunk0 and unmonitor the trunk0 leases. everything s fine like this. Someone reboot the machine since, it didnt fix the problem. Of course because setting the ip manually works the 10.0.0.254 is in arp table. (i am setting trunk0 to the ip the dhcp server is giving 10.0.0.126) v12-GW 49# arp -a ? (10.0.0.1) at 16:00:40:da:39:d0 on trunk0 ? (10.0.0.254) at 96:4f:87:9c:ad:67 on trunk0 and the dhclient is getting leases on two other interfaces, no problem. As far as i understand dhclient does not like something about the mac address, i cannot do anymore test for a few hours (like ulimit -c unlimited and restart dhclient, wheres does it dump already ?) - - - - - OpenBSD 5.4 (GENERIC) #37: Tue Jul 30 12:05:01 MDT 2013 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Geode(TM) Integrated Processor by AMD PCS (AuthenticAMD 586-class) 499 MHz cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW real mem = 536408064 (511MB) avail mem = 516194304 (492MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 20/70/03, BIOS32 rev. 0 @ 0xfac40 pcibios0 at bios0: rev 2.0 @ 0xf/0x1 pcibios0: pcibios_get_intr_routing - function not supported pcibios0: PCI IRQ Routing information unavailable. pcibios0: PCI bus #1 is the last bus bios0: ROM list: 0xc8000/0xa800 cpu0 at mainbus0: (uniprocessor) amdmsr0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (bios) 0:20:0: io address conflict 0x6100/0x100 0:20:0: io address conflict 0x6200/0x200 pchb0 at pci0 dev 1 function 0 AMD Geode LX rev 0x33 glxsb0 at pci0 dev 1 function 2 AMD Geode LX Crypto rev 0x00: RNG AES vr0 at pci0 dev 6 function 0 VIA VT6105M RhineIII rev 0x96: irq 11, address 00:00:24:d0:8e:d0 ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr1 at pci0 dev 7 function 0 VIA VT6105M RhineIII rev 0x96: irq 5, address 00:00:24:d0:8e:d1 ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr2 at pci0 dev 8 function 0 VIA VT6105M RhineIII rev 0x96: irq 9, address 00:00:24:d0:8e:d2 ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr3 at pci0 dev 9 function 0 VIA VT6105M RhineIII rev 0x96: irq 12, address 00:00:24:d0:8e:d3 ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 ppb0 at pci0 dev 14 function 0 TI PCI2250 rev 0x02 pci1 at ppb0 bus 1 vr4 at pci1 dev 0 function 0 VIA VT6105M RhineIII rev 0x96: irq 10, address 00:00:24:cf:f5:a8 ukphy4 at vr4 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr5 at pci1 dev 1 function 0 VIA VT6105M RhineIII rev 0x96: irq 7, address 00:00:24:cf:f5:a9 ukphy5 at vr5 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr6 at pci1 dev 2 function 0 VIA VT6105M RhineIII rev 0x96: irq 10, address 00:00:24:cf:f5:aa ukphy6 at vr6 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr7 at pci1 dev 3 function 0 VIA VT6105M RhineIII rev 0x96: irq 7, address 00:00:24:cf:f5:ab ukphy7 at vr7 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 glxpcib0 at pci0 dev 20 function 0 AMD CS5536 ISA rev 0x03: rev 3, 32-bit 3579545Hz timer, watchdog, gpio, i2c gpio0 at glxpcib0: 32 pins iic0 at glxpcib0 pciide0 at pci0 dev 20 function 2 AMD CS5536 IDE rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive
Re: segfault in dhclient 5.4 please help
On 4/14/14, sven falempin sven.falem...@gmail.com wrote: [..] OpenBSD 5.4 (GENERIC) #37: Tue Jul 30 12:05:01 MDT 2013 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC [...] so i got gdb back to the machine because i cannot reproduce outside of the box. gdb too old cannot gcore. The state is nasty, but i do get the trace of the dhcp transaction. [..] DHCPREQUEST on trunk0 to 255.255.255.255 port 67 DHCPACK from 10.0.0.254 (96:4f:87:9c:ad:67) Program received signal SIGSEGV, Segmentation fault. 0x1c005b26 in add_classless_static_routes (rdomain=13684944, classless_static_routes=0x0) at /usr/src/sbin/dhclient/dhclient.c:2408 2408/usr/src/sbin/dhclient/dhclient.c: No such file or directory. in /usr/src/sbin/dhclient/dhclient.c (gdb) bt #0 0x1c005b26 in add_classless_static_routes (rdomain=13684944, classless_static_routes=0x0) at /usr/src/sbin/dhclient/dhclient.c:2408 that rdomain value looks awful funny. You aren't by chance mixing binaries pre/post time_t change? But, don't mind me too much. Wait for someone with actual knowledge in this area. --patrick
