sysctl segfaulting
I have a strange problem on one of my computers: sysctl segfaults when querying kern.clockrate (and more annoyingly when trying to print kern.clockrate when run with -a). I cannot tell for sure when this problem appeared, the last things I did to the system was putting in an sata harddisk and enabling geli, which required me to rebuild the kernel to add a few kernel modules (crypto cryptodev geom/geom_eli zlib). [EMAIL PROTECTED]:0:~ sysctl -a kern.ostype: FreeBSD kern.osrelease: 6.2-RELEASE kern.osrevision: 199506 kern.version: FreeBSD 6.2-RELEASE #4: Sat Feb 17 09:23:50 CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LOFI.4BSD kern.maxvnodes: 35372 kern.maxproc: 4004 kern.maxfiles: 102400 kern.argmax: 262144 kern.securelevel: -1 kern.hostname: lofi.dyndns.org kern.hostid: 0 kern.clockrate: Segmentation fault (core dumped) I've attached the ktrace output of 'sysctl kern.clockrate' to this message. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org 3167 ktrace RET ktrace 0 3167 ktrace CALL execve(0xbfbfe670,0xbfbfebb4,0xbfbfebc0) 3167 ktrace NAMI /sbin/sysctl 3167 ktrace NAMI /libexec/ld-elf.so.1 3167 sysctl RET execve 0 3167 sysctl CALL mmap(0,0xf40,0x3,0x1000,0x,0,0,0) 3167 sysctl RET mmap 671563776/0x28074000 3167 sysctl CALL munmap(0x28074000,0xf40) 3167 sysctl RET munmap 0 3167 sysctl CALL __sysctl(0xbfbfe958,0x2,0x28070b58,0xbfbfe954,0,0) 3167 sysctl RET __sysctl 0 3167 sysctl CALL mmap(0,0x8000,0x3,0x1002,0x,0,0,0) 3167 sysctl RET mmap 671563776/0x28074000 3167 sysctl CALL issetugid 3167 sysctl RET issetugid 0 3167 sysctl CALL open(0x2806ac48,0,0x1b6) 3167 sysctl NAMI /etc/libmap.conf 3167 sysctl RET open 3 3167 sysctl CALL fstat(0x3,0xbfbfe070) 3167 sysctl RET fstat 0 3167 sysctl CALL read(0x3,0x28078000,0x1000) 3167 sysctl GIO fd 3 read 124 bytes # /etc/libmap.conf # # candidate mapping # libpthread.so.2 libthr.so.2 # Everything uses libthr libpthread.so libthr.so 3167 sysctl RET read 124/0x7c 3167 sysctl CALL read(0x3,0x28078000,0x1000) 3167 sysctl GIO fd 3 read 0 bytes 3167 sysctl RET read 0 3167 sysctl CALL close(0x3) 3167 sysctl RET close 0 3167 sysctl CALL open(0x28069ea0,0,0) 3167 sysctl NAMI /var/run/ld-elf.so.hints 3167 sysctl RET open 3 3167 sysctl CALL read(0x3,0xbfbfe920,0x80) 3167 sysctl GIO fd 3 read 128 bytes 0x 4568 6e74 0100 8000 b300 |Ehnt..| 0x0012 b200 |..| 0x0024 |..| 0x0036 |..| 0x0048 |..| 0x005a |..| 0x006c |..| 0x007e |..| 3167 sysctl RET read 128/0x80 3167 sysctl CALL lseek(0x3,0,0x80,0,0) 3167 sysctl RET lseek 128/0x80 3167 sysctl CALL read(0x3,0x28076100,0xb3) 3167 sysctl GIO fd 3 read 179 bytes /lib:/usr/lib:/usr/lib/compat:/usr/X11R6/lib:/usr/local/lib:/usr/local/lib/c\ ompat/pkg:/usr/local/lib/compat:/usr/local/lib/mysql:/usr/local/lib/courier-\ authlib:/usr/local/lib/pth\0 3167 sysctl RET read 179/0xb3 3167 sysctl CALL close(0x3) 3167 sysctl RET close 0 3167 sysctl CALL access(0x2807a000,0) 3167 sysctl NAMI /lib/libc.so.6 3167 sysctl RET access 0 3167 sysctl CALL open(0x280750c0,0,0) 3167 sysctl NAMI /lib/libc.so.6 3167 sysctl RET open 3 3167 sysctl CALL fstat(0x3,0xbfbfe960) 3167 sysctl RET fstat 0 3167 sysctl CALL read(0x3,0x2806faa0,0x1000) 3167 sysctl GIO fd 3 read 4096 bytes 0x 7f45 4c46 0101 0109 0300 |.ELF..| 0x0012 0300 0100 80ea 0100 3400 7c0f 0e00 |..4...|...| 0x0024 3400 2000 0300 2800 1e00 1d00 0100 |4. ...(...| 0x0036 f28e 0c00 |..| 0x0048 f28e 0c00 0500 0010 0100 0090 |..| 0x005a 0c00 0090 0c00 0090 0c00 7050 a4b7 0100 |..pP..| 0x006c 0600 0010 0200 c4cc 0c00 c4cc |..| 0x007e 0c00 c4cc 0c00 a800 a800 0600 |..| 0x0090 0400 0508 210b 8105 3108
Re: sysctl segfaulting
Hi Michael, On Sat, Feb 17, 2007 at 09:47:45AM +0100, Michael Nottebrock wrote: I've attached the ktrace output of 'sysctl kern.clockrate' to this message. Hmm, could you try to rebuild sysctl manually and give that one a try? Maybe there's not something in sync. Something like: # cd /usr/src/sbin/sysctl # make # ./sysctl kern.clockrate Would work. If this fails, could you build a debugging version (eg. make CFLAGS=-g) and use gdb(1) to find out exactly where it crashes? Thanks, -- Rink P.W. Springer- http://rink.nu It is such a quiet thing, to fall. But yet a far more terrible thing, to admit it.- Darth Traya smime.p7s Description: S/MIME cryptographic signature
Re: sysctl segfaulting
On Saturday, 17. February 2007 10:09, Rink Springer wrote: Hi Michael, On Sat, Feb 17, 2007 at 09:47:45AM +0100, Michael Nottebrock wrote: I've attached the ktrace output of 'sysctl kern.clockrate' to this message. Hmm, could you try to rebuild sysctl manually and give that one a try? Maybe there's not something in sync. Something like: # cd /usr/src/sbin/sysctl # make # ./sysctl kern.clockrate Would work. If this fails, could you build a debugging version (eg. make CFLAGS=-g) and use gdb(1) to find out exactly where it crashes? I already tried both, but to little avail, which is why I went with ktrace in my initional mail instead. But for reference: [EMAIL PROTECTED]:0:/usr/src/sbin/sysctl # make clean make depend env CFLAGS=-g make make install rm -f sysctl sysctl.o sysctl.8.gz sysctl.8.cat.gz cc -g -c /usr/src/sbin/sysctl/sysctl.c cc -g-o sysctl sysctl.o gzip -cn /usr/src/sbin/sysctl/sysctl.8 sysctl.8.gz install -s -o root -g wheel -m 555 sysctl /sbin install -o root -g wheel -m 444 sysctl.8.gz /usr/share/man/man8 [EMAIL PROTECTED]:0:/usr/src/sbin/sysctl # cd [EMAIL PROTECTED]:1:~ # exit [EMAIL PROTECTED]:1:~ rm sysct [EMAIL PROTECTED]:1:~ gdb sysctl GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd...(no debugging symbols found)... (gdb) set args kern.clockrate (gdb) run Starting program: /sbin/sysctl kern.clockrate (no debugging symbols found)...(no debugging symbols found)...kern.clockrate: Program received signal SIGSEGV, Segmentation fault. 0x08049696 in ?? () (gdb) bt #0 0x08049696 in ?? () #1 0xbfbfe238 in ?? () #2 0x28050b29 in _rtld_bind_start () from /libexec/ld-elf.so.1 #3 0x28077000 in ?? () #4 0x0118 in ?? () #5 0x0010 in ?? () #6 0x0010 in ?? () #7 0x0002 in ?? () #8 0xbfbfeba4 in ?? () #9 0x0804e000 in ?? () #10 0xbfbfe238 in ?? () #11 0x0804a5f2 in ?? () #12 0x0014 in ?? () #13 0x0804e000 in ?? () #14 0x0804b133 in ?? () #15 0xbfbfd990 in ?? () #16 0x0001 in ?? () #17 0x0012 in ?? () #18 0x28052863 in find_symdef () from /libexec/ld-elf.so.1 Previous frame inner to this frame (corrupt stack?) (gdb) -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgpGoNjvozGd3.pgp Description: PGP signature
Re: sysctl segfaulting
I experimented some more and found something even more funny: A sysctl binary copied over from a FreeBSD 5.5 machine works (the FreeBSD 6 box with the segfaulting sysctl has the 5.x compat libraries installed). So I tried recompiling libc with debug cflags (-g3 -O -pipe), but this only makes the backtrace in gdb much longer, but still without any function names. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgp5J1t6Ustx3.pgp Description: PGP signature
Re: sysctl segfaulting
Hi Michael, On Sat, Feb 17, 2007 at 11:36:46AM +0100, Michael Nottebrock wrote: So I tried recompiling libc with debug cflags (-g3 -O -pipe), but this only makes the backtrace in gdb much longer, but still without any function names. Hmm, 'make install' appears to strip the debugging info. Please try gdb-ing /usr/obj/usr/src/sbin/sysctl/sysctl instead (assuming you use default the /usr/obj path like I do) -- Rink P.W. Springer- http://rink.nu It is such a quiet thing, to fall. But yet a far more terrible thing, to admit it.- Darth Traya smime.p7s Description: S/MIME cryptographic signature
Re: Very slow umass in 6.2-RC2
Has anyone ever managed to get some USB 2.0 - like speeds out of ehci anyway? I'm not seeing quite such abysmal performance as Kevin did, but I don't even need to benchmark to be certain that Windows does *much* better with the devices I own. Here are some numbers: First up, the controller: ehci0: VIA VT6202 USB 2.0 controller mem 0xdfffbd00-0xdfffbdff irq 21 at device 16.4 on pci0 usb4: VIA VT6202 USB 2.0 controller on ehci0 usb4: USB revision 2.0 To be sure the umass device is actually a child of the ehci device: dev.umass.0.%parent: uhub4 dev.uhub.4.%parent: usb4 This is a Panasonic Pro High Speed series 512mb SD-CARD, which theoretically supports burst transfer rates up to 20MB/s on a USB 2.0 multi card reader: da2 at umass-sim0 bus 0 target 0 lun 2 da2: Hama CardReaderMMC/SD 1.9C Removable Direct Access SCSI-0 device da2: 40.000MB/s transfers da2: 472MB (967680 512 byte sectors: 64H 32S/T 472C) vmstat while running bonnie -s 472 (I don't have bonnie results, since it would have taken forever to finish): Disks ad0 ad4 da0 da1 da2 da3 pass0 KB/t 16.00 0.00 0.00 0.00 12.01 0.00 0.00 tps 1 0 0 0 154 0 0 MB/s 0.02 0.00 0.00 0.00 1.80 0.00 0.00 % busy0 0 0 099 0 0 This is a Trekstor Vibez portable music player, which comes with an 8GB microdrive and an USB 2.0 interface, again with bonnie: umass0: TrekStor vibez, rev 2.00/1.10, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: TrekStor vibez 2 Removable Direct Access SCSI-4 device da0: 40.000MB/s transfers da0: 7613MB (15592237 512 byte sectors: 255H 63S/T 970C) Disks ad0 ad4 da0 pass0 KB/t 12.73 0.00 4.00 0.00 tps 2 0 339 0 MB/s 0.03 0.00 1.32 0.00 % busy1 0 100 0 -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgp7ZOpyYyZxU.pgp Description: PGP signature
Re: sysctl segfaulting
On Saturday, 17. February 2007 11:39, Rink Springer wrote:
Hi Michael,
On Sat, Feb 17, 2007 at 11:36:46AM +0100, Michael Nottebrock wrote:
So I tried recompiling libc with debug cflags (-g3 -O -pipe), but this
only makes the backtrace in gdb much longer, but still without any
function names.
Hmm, 'make install' appears to strip the debugging info.
Duh, I keep forgetting that.
Please try
gdb-ing /usr/obj/usr/src/sbin/sysctl/sysctl instead (assuming you use
default the /usr/obj path like I do)
I recompiled/reinstalled both sysctl and libc with CFLAGS=-g3 and STRIP= and
now I get:
[EMAIL PROTECTED]:0:~ gdb /sbin/sysctl
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd...
(gdb) set args kern.clockrate
(gdb) run
Starting program: /sbin/sysctl kern.clockrate
kern.clockrate:
Program received signal SIGSEGV, Segmentation fault.
0x08049696 in S_clockinfo (l2=20, p=0x804e000)
at /usr/src/sbin/sysctl/sysctl.c:333
333 printf(hflag ? { hz = %'d, tick = %'d, profhz = %'d, stathz
= %'d } :
(gdb) bt
#0 0x08049696 in S_clockinfo (l2=20, p=0x804e000)
at /usr/src/sbin/sysctl/sysctl.c:333
#1 0x0804a5f2 in show_var (oid=0xbfbfea80, nlen=2)
at /usr/src/sbin/sysctl/sysctl.c:690
#2 0x08049093 in parse (string=0xbfbfecb1 kern.clockrate)
at /usr/src/sbin/sysctl/sysctl.c:208
#3 0x08048e77 in main (argc=0, argv=0xbfbfeba0)
at /usr/src/sbin/sysctl/sysctl.c:152
(gdb) list
328 struct clockinfo *ci = (struct clockinfo*)p;
329 if (l2 != sizeof(*ci)) {
330 warnx(S_clockinfo %d != %d, l2, sizeof(*ci));
331 return (0);
332 }
333 printf(hflag ? { hz = %'d, tick = %'d, profhz = %'d, stathz
= %'d } :
334 { hz = %d, tick = %d, profhz = %d, stathz = %d },
335 ci-hz, ci-tick, ci-profhz, ci-stathz);
336 return (0);
337 }
(gdb) print ci-hz
Error accessing memory address 0x804e000: Bad address.
(gdb) print ci-tick
Error accessing memory address 0x804e004: Bad address.
(gdb) print ci-profhz
Error accessing memory address 0x804e010: Bad address.
(gdb) print ci-stathz
Error accessing memory address 0x804e00c: Bad address.
(gdb) print ci
$1 = (struct clockinfo *) 0x804e000
(gdb) print p
$2 = (void *) 0x804e000
(gdb) print l2
$3 = 20
--
,_, | Michael Nottebrock | [EMAIL PROTECTED]
(/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org
\u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org
pgpwU6wvpf7d9.pgp
Description: PGP signature
Re: Very slow umass in 6.2-RC2
Michael Nottebrock schrieb: Has anyone ever managed to get some USB 2.0 - like speeds out of ehci anyway? I'm not seeing quite such abysmal performance as Kevin did, but I don't even need to benchmark to be certain that Windows does *much* better with the devices I own. Actually let me backpedal just a bit there - the SD-Card doesn't do much better, looks like the crappy card reader is the bottleneck (or Panasonic rigged their highspeed cards to require special readers for true high speed). But the Vibez flies - 6-7 MB/s on Windows 2000. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org signature.asc Description: OpenPGP digital signature
Recent libxine update seems to cause ICE on 6-STABLE/amd64
On Thursday, libxine was updated in the ports collection to version 1.1.4 Unfortunately, this seems to cause some kind of compiler-suite error on 6.2-STABLE/amd64. dsputil.c:3826: error: unrecognizable insn: (insn 62 10 12 0 (set (reg:SI 0 ax [61]) (subreg:SI (plus:DI (subreg:DI (reg:SI 7 sp) 0) (const_int -4 [0xfffc])) 0)) -1 (nil) (nil)) dsputil.c:3826: internal compiler error: in extract_insn, at recog.c:2083 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. gmake[5]: *** [dsputil.lo] Error 1 gmake[5]: Leaving directory `/usr/ports/multimedia/libxine/work/xine-lib-1.1.4/src/libffmpeg/libavcodec' Please see PR ports/109213 (raised by another person) for slightly more context to the error. It's bitten two of us so far, apparently in identical way. I'm not sure this should be a ports PR, maybe it should go to the compiler suite? Andy -- Andy Fawcett | [EMAIL PROTECTED] | [EMAIL PROTECTED] In an open world without walls and fences, | [EMAIL PROTECTED] we wouldn't need Windows and Gates. -- anon | [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADSUP] New unionfs merged to RELENG_6 (stable)
Hi, I feel the mount_union manpage isn't 100% correct anymore, especially the the BUGS section ? Or do the things there still apply ? Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- On Wed, 14 Feb 2007, Craig Rodrigues wrote: Hi, I have merged the new unionfs implementation from CURRENT to RELENG_6 (stable branch). This code was submitted by Daichi GOTO and Masanori OZAWA. Many, many thanks to GOTO-san and OZAWA-san for their work. This code solves a lot of crashing problems that the old unionfs implementation had. Reports from people running SMP systems would be appreciated. There probably is some room for performance optimization on SMP systems. Also, thanks a lot to Kostik Belousov, who recently fixed some deadlock problems in vfs_lookup.c, which helps a lot with unionfs. -- Craig Rodrigues [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
SFF supported computers
Hi, I'm looking for a recommendation on a small form factor system. I've looked at some of the models from AOpen , Shuttle and Microstar. I'd like an AMD 64 (or dual core) box (lower cost) with SATA/EIDE disk support. I plan on running FreeBSD mostly and occasionally Red Hat or Fedora for customer projects. If someone can recommend a system/motherboard combination and perhaps an agp video card. I write lamp/perl things and need a box for development. Thanks, BE - It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
