RFC 3514
Hello, I'd be glad if you revert the change in rev 1.23 of sys/netinet/ip.h unless there's some special reason you can't undo your rfc3514 implementation. Thanks. (Yes, I regret not having been subscribed to cvs-all list...:) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Linux emulation busted
On Tue, Mar 25, 2003 at 12:58:35AM +0900, [EMAIL PROTECTED] wrote: > On Mon, Mar 24, 2003 at 08:40:55AM -0700, M. Warner Losh wrote: > > I had a working Linux world on my laptop. I upgraded my kernel and > > acroread4 stopped working. Now all I get is: > > > > Exited with error code: 0x400e0009. > > > > after a whole lot of disk access when I try to run it. This worked on > > a December kernel for sure. I'm pretty sure it was working as late as > > a January 15th kernel. It hasn't worked on a March 1st and subsequent > > kernels. I'm not sure where it broke inbetween. Has anybody else > > seen this? > > I've also seen this on two versions of -STABLE, one built this morning, > and another built around February 24th. Ugh, I've found the fact that I was trying to start acrobat reader in Japanese mode (LANG set to ja_JP.eucJP) without installing Japanese font pack. After having installed ports/japanese/acroread5-jpnfont, acroread5 began to work without a problem. So maybe mine has nothing to do with what Warner was seeing. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation busted
Hi, On Mon, Mar 24, 2003 at 08:40:55AM -0700, M. Warner Losh wrote: > I had a working Linux world on my laptop. I upgraded my kernel and > acroread4 stopped working. Now all I get is: > > Exited with error code: 0x400e0009. > > after a whole lot of disk access when I try to run it. This worked on > a December kernel for sure. I'm pretty sure it was working as late as > a January 15th kernel. It hasn't worked on a March 1st and subsequent > kernels. I'm not sure where it broke inbetween. Has anybody else > seen this? I've also seen this on two versions of -STABLE, one built this morning, and another built around February 24th. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/net if_arcsubr.c if_atmsubr.c if_ef.c if_ethersubr.c if_faith.c if_fddisubr.c if_gif.c if_iso88025subr.c if_loop.c if_ppp.c if_sl.c if_spppsubr.c if_stf.c if_tun.c netisr.c netisr.h src/sys/netatalk aarp.c at_extern.h at_var.h ...
Hello. On Tue, Mar 04, 2003 at 03:19:55PM -0800, Jonathan Lemon wrote: > jlemon 2003/03/04 15:19:55 PST > > FreeBSD src repository > > Modified files: > sys/net if_arcsubr.c if_atmsubr.c if_ef.c > if_ethersubr.c if_faith.c if_fddisubr.c > if_gif.c if_iso88025subr.c if_loop.c > if_ppp.c if_sl.c if_spppsubr.c if_stf.c > if_tun.c netisr.c netisr.h [snip] After this commit, netgraph seems to be broken. Please Fix (TM:). I'm using mpd(ports/net/mpd) to speak PPPoE for my ADSL connection, and mpd relies on netgraph devices. The kernel built from the source checked out as env TZ=UTC cvs -R up -dPD'2003-03-04 23:19:00' seems to be OK, while the kernel from env TZ=UTC cvs -R up -dPD'2003-03-04 23:20:00' is NG. Actually, mpd running on the broken kernel displays the message saying the connection is established, but pinging to the peer receives nothing. Pinging to the peer while tcpdump'ing on ng0 shows the echo reply, but ping shows nothing. I've turned off any firewalling and NAT functions, so they are not the case. Pinging over other interfaces works just fine. Regards. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Request for info from SiS chipset owners
On Sat, Feb 01, 2003 at 12:02:05PM +0100, Soeren Schmidt wrote: > Just reply to this message with the output from pciconf -l and you > have helped me sort out the myriads of SiS chipsets out there. agp0@pci0:0:0: class=0x06 card=0x06481039 chip=0x06481039 rev=0x02 hdr=0x00 pcib1@pci0:1:0: class=0x060400 card=0x chip=0x00011039 rev=0x00 hdr=0x01 isab0@pci0:2:0: class=0x060100 card=0x chip=0x00081039 rev=0x04 hdr=0x00 atapci0@pci0:2:5: class=0x010180 card=0x55131039 chip=0x55131039 rev=0x00 hdr=0x00 none0@pci0:3:0: class=0x0c0310 card=0x70011039 chip=0x70011039 rev=0x0f hdr=0x00 none1@pci0:3:1: class=0x0c0310 card=0x70011039 chip=0x70011039 rev=0x0f hdr=0x00 none2@pci0:3:2: class=0x0c0310 card=0x70011039 chip=0x70011039 rev=0x0f hdr=0x00 none3@pci0:3:3: class=0x0c0320 card=0x50041458 chip=0x70021039 rev=0x00 hdr=0x00 dc0@pci0:11:0: class=0x02 card=0x03151025 chip=0x00191011 rev=0x30 hdr=0x00 xl0@pci0:12:0: class=0x02 card=0x chip=0x905010b7 rev=0x00 hdr=0x00 pcm0@pci0:13:0: class=0x040100 card=0x13711274 chip=0x13711274 rev=0x06 hdr=0x00 nvidia0@pci1:0:0: class=0x03 card=0x chip=0x017110de rev=0xa3 hdr=0x00 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is this a tool problem or source?
On Mon, Oct 14, 2002 at 11:26:55PM +1000, Bruce Evans wrote: > On Sun, 13 Oct 2002, Julian Elischer wrote: > > > ref3# make > > linking kernel.debug > > ld: target elf32-i386-freebsd not found > > *** Error code 1 > > > > Stop in /usr/src/sys/i386/compile/REF3. > > ref3# > > > > having done a new cvsup and a new config.. > > UPDATING has nothing relevant that I can see. > > Looks like you tried to build a current kernel under a release version > of FreeBSD. This fails because of spelling changes in binutils. The > target was spelled elf32-i386 but it is now spelled elf32-i386-freebsd. I got the same error trying to build a kernel from source code as of 2002-10-13(UTC) with world from 2002-10-06(UTC). Now I'm compiling the kernel with gcc just built from the same source, and it seems like it's going without problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic trying to chroot(2) on a script(?)
Hello. Last night I was trying to start an anonymous ftp server on my -current box for my local network. I made a mistake in vipw: ftp:*:4:4:Unprivileged user:/sbin/nologin:/home/mp3 i.e., wrote a path to a script where directory is needed, and directory where path to shell is needed. Without noticing, I started ftpd in standalone mode, and logged in as user ftp, when the box panicked: # /usr/libexec/ftpd -AD # ftp -4 localhost On 4.7-RC1 box, this just spewed an error message in /var/log/messages and didn't panic, and man 2 chroot doesn't state it should. If there's something other than the backtrace(attached), let me know it. Regards. Script started on Thu Oct 3 23:27:19 2002 qhwt@gzl$ gdb -k /usr/obj/kernel/kernel.debug vmcore.14 GNU gdb 5.2.0 (FreeBSD) 20020627 Copyright 2002 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-undermydesk-freebsd"... panic: bdwrite: buffer is not busy panic messages: --- panic: vrele: negative ref cnt syncing disks... panic: bdwrite: buffer is not busy Uptime: 5m31s Dumping 63 MB ata0: resetting devices .. ata0: mask=03 ostat0=50 ostat2=00 ad0: ATAPI 00 00 ata0-slave: ATAPI 00 00 ata0: mask=03 stat0=50 stat1=00 ad0: ATA 01 a5 ata0: devices=01 ad0: success setting PIO4 on generic chip done 16 32 48 --- #0 doadump () at /home/usr.src/sys/kern/kern_shutdown.c:223 223 dumping++; (kgdb) bt #0 doadump () at /home/usr.src/sys/kern/kern_shutdown.c:223 #1 0xc0198625 in boot (howto=260) at /home/usr.src/sys/kern/kern_shutdown.c:355 #2 0xc0198873 in panic () at /home/usr.src/sys/kern/kern_shutdown.c:508 #3 0xc01d725d in bdwrite (bp=0xc223edd0) at /home/usr.src/sys/kern/vfs_bio.c:952 #4 0xc0273d4b in ffs_update (vp=0xc13cb6f0, waitfor=0) at /home/usr.src/sys/ufs/ffs/ffs_inode.c:125 #5 0xc028702f in ffs_fsync (ap=0xc73a1ab0) at /home/usr.src/sys/ufs/ffs/ffs_vnops.c:309 #6 0xc0286b89 in VOP_FSYNC (vp=0x0, cred=0x0, waitfor=0, td=0x0) at vnode_if.h:612 #7 0xc0286014 in ffs_sync (mp=0xc0f9f800, waitfor=2, cred=0xc0726d80, td=0xc033e460) at /home/usr.src/sys/ufs/ffs/ffs_vfsops.c:1127 #8 0xc01ebd38 in sync (td=0xc033e460, uap=0x0) at /home/usr.src/sys/kern/vfs_syscalls.c:130 #9 0xc019820c in boot (howto=256) at /home/usr.src/sys/kern/kern_shutdown.c:264 #10 0xc0198873 in panic () at /home/usr.src/sys/kern/kern_shutdown.c:508 #11 0xc01e8618 in vrele (vp=0xc0fce4a0) at /home/usr.src/sys/kern/vfs_subr.c:2163 #12 0xc01eb7a9 in NDFREE (ndp=0xc73a1c78, flags=0) at /home/usr.src/sys/kern/vfs_subr.c:3590 ---Type to continue, or q to quit--- #13 0xc01ec8d3 in chroot (td=0xc142f0c0, uap=0x0) at /home/usr.src/sys/kern/vfs_syscalls.c:564 #14 0xc02de39a in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 126, tf_esi = -1077936868, tf_ebp = -1077939528, tf_isp = -952492684, tf_ebx = 0, tf_edx = -1, tf_ecx = 2, tf_eax = 61, tf_trapno = 0, tf_err = 2, tf_eip = 672269963, tf_cs = 31, tf_eflags = 514, tf_esp = -1077941908, tf_ss = 47}) at /home/usr.src/sys/i386/i386/trap.c:1050 #15 0xc02ce9bd in Xint0x80_syscall () at {standard input}:140 ---Can't read userspace from dump, or kernel process--- (kgdb) frame 11 #11 0xc01e8618 in vrele (vp=0xc0fce4a0) at /home/usr.src/sys/kern/vfs_subr.c:2163 2163panic("vrele: negative ref cnt"); (kgdb) print vp->v_usecount $1 = 0 (kgdb) print *vp $2 = {v_interlock = {mtx_object = {lo_class = 0xc0342920, lo_name = 0xc030b67b "vnode interlock", lo_type = 0xc030b67b "vnode interlock", lo_flags = 196608, lo_list = { tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 4, mtx_recurse = 0, mtx_blocked = {tqh_first = 0x0, tqh_last = 0xc0fce4c4}, mtx_contested = {le_next = 0x0, le_prev = 0x0}, mtx_acqtime = 0, mtx_filename = 0x0, mtx_lineno = 0}, v_iflag = 256, v_usecount = 0, v_numoutput = 0, v_vxproc = 0x0, v_holdcnt = 0, v_cleanblkhd = { tqh_first = 0x0, tqh_last = 0xc0fce4f8}, v_cleanblkroot = 0x0, v_dirtyblkhd = {tqh_first = 0x0, tqh_last = 0xc0fce504}, v_dirtyblkroot = 0x0, v_vflag = 8, v_writecount = 0, v_object = 0xc14522bc, v_lastw = 0, v_cstart = 0, v_lasta = 0, v_clen = 0, v_un = { vu_mountedhere = 0x0, vu_socket = 0x0, vu_spec = {vu_specinfo = 0x0, vu_specnext = {sle_next = 0x0}}, vu_fifoinfo = 0x0}, v_freelist = { tqe_next = 0x0, tqe_prev = 0xc13ca2f0}, v_nmntvnodes = {tqe_next = 0x0, tqe_prev = 0xc0fd2b10}, v_synclist = {le_next = 0x0, le_prev = 0xc0f6912c}, v_type = VREG, v_tag = 0xc0321a29
Re: Trouble Building CURRENT on STABLE, cpp seg. fault
On Sun, Sep 22, 2002 at 10:22:23PM +0900, I wrote: > On Sun, Sep 22, 2002 at 02:44:54PM +0300, Giorgos Keramidas wrote: > > On 2002-09-21 23:53, "Crist J. Clark" <[EMAIL PROTECTED]> wrote: > > > I've been unable to build CURRENT on STABLE for a few days. I made > > > sure to bring STABLE up to date. Is this just me? Is there a problem > > > with building CURRENT on STABLE at the moment? > > > > It isn't just you. The same error stopped my build of current 2-3 > > days ago on 4.6-RELEASE. > > > > > if [ -f .olddep ]; then mv .olddep .depend; fi > > > rm -f .newdep > > > make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES -V GEN_M_CFILES | MKDEP_CPP="cc >-E" CC="cc" xargs mkdep -a -f .newdep -O -pipe -march=pentium3 -Wall >-Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes >-Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. >-I/usr/src.CURRENT/sys -I/usr/src.CURRENT/sys/dev >-I/usr/src.CURRENT/sys/contrib/dev/acpica -I/usr/src.CURRENT/sys/contrib/ipfilter >-D_KERNEL -include opt_global.h -fno-common -mpreferred-stack-boundary=2 >-ffreestanding > > > cc: Internal error: Segmentation fault (program cpp0) > > > Please submit a full bug report. > > > See http://www.gnu.org/software/gcc/bugs.html> for instructions. > > > mkdep: compile failed > > > *** Error code 1 > > Try 'make depend && make' using cpp0 built from -CURRENT source > newer than the first import of gcc 3.2.1 prerelease: > > $ pushd /usr/src/gnu/usr.bin/cc > $ make obj && make depend && make > $ popd > $ GCC_EXEC_PREFIX=/usr/obj/usr/src/usr.bin/cc/cpp0/ make depend > $ GCC_EXEC_PREFIX=/usr/obj/usr/src/usr.bin/cc/cpp0/ make > > should work unless you are doing a cross-platform compiling. > The bug in cpp0 seems to me to have been fixed after the first > import of gcc 3.2.1-prerelease (2002-09-02(UTC)). Actually the bug seems to be not only in cpp0 but in some other tools under /usr/libexec, so even if make depend succeeds, you'll get another crash: cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstri ct-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fform at-extensions -ansi -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/u sr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/netkey/keysock.c In file included from /usr/src/sys/sys/systm.h:45, from /usr/src/sys/netkey/keysock.c:49: machine/atomic.h: In function `atomic_set_long': machine/atomic.h:253: internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://www.gnu.org/software/gcc/bugs.html> for instructions. *** Error code 1 So I had to build the world in advance, and use the tools under /usr/obj/usr/src/${ARCH}/usr/libexec/ . Also, it seems like it doesn't crash without -march= option, so NO_CPU_CFLAGS and NO_CPU_COPTFLAGS might help you. Anyway, I just managed to build the kernel from 2002-09-21(UTC) source, on another machine with world built from 2002-09-01(UTC). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Trouble Building CURRENT on STABLE, cpp seg. fault
On Sun, Sep 22, 2002 at 02:44:54PM +0300, Giorgos Keramidas wrote: > On 2002-09-21 23:53, "Crist J. Clark" <[EMAIL PROTECTED]> wrote: > > I've been unable to build CURRENT on STABLE for a few days. I made > > sure to bring STABLE up to date. Is this just me? Is there a problem > > with building CURRENT on STABLE at the moment? > > It isn't just you. The same error stopped my build of current 2-3 > days ago on 4.6-RELEASE. > > > if [ -f .olddep ]; then mv .olddep .depend; fi > > rm -f .newdep > > make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES -V GEN_M_CFILES | MKDEP_CPP="cc >-E" CC="cc" xargs mkdep -a -f .newdep -O -pipe -march=pentium3 -Wall >-Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes >-Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. >-I/usr/src.CURRENT/sys -I/usr/src.CURRENT/sys/dev >-I/usr/src.CURRENT/sys/contrib/dev/acpica -I/usr/src.CURRENT/sys/contrib/ipfilter >-D_KERNEL -include opt_global.h -fno-common -mpreferred-stack-boundary=2 >-ffreestanding > > cc: Internal error: Segmentation fault (program cpp0) > > Please submit a full bug report. > > See http://www.gnu.org/software/gcc/bugs.html> for instructions. > > mkdep: compile failed > > *** Error code 1 Try 'make depend && make' using cpp0 built from -CURRENT source newer than the first import of gcc 3.2.1 prerelease: $ pushd /usr/src/gnu/usr.bin/cc $ make obj && make depend && make $ popd $ GCC_EXEC_PREFIX=/usr/obj/usr/src/usr.bin/cc/cpp0/ make depend $ GCC_EXEC_PREFIX=/usr/obj/usr/src/usr.bin/cc/cpp0/ make should work unless you are doing a cross-platform compiling. The bug in cpp0 seems to me to have been fixed after the first import of gcc 3.2.1-prerelease (2002-09-02(UTC)). Cheers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: can't compile kernel?
On Thu, Sep 19, 2002 at 10:15:48PM +0900, I wrote: > On Wed, Sep 18, 2002 at 01:15:40PM -0500, Steve Ames wrote: > > > > New datapoint: > > > > If I compile the kernel in the old fashion (config SB; cd ../compile/SB; > > make depend all install) then the kernel compiles and installs fine. > > However I get the error below when doing a 'make kernel' from /usr/src. > > > > Also even after rebooting onto the new kernel bind9 and mysql-server > > are still exiting on signal6. > > I'm also getting cpp0 crashing while building new kernel. My world is from > 2002-09-01(UTC) source. It looks similar to yours, except that: > > - cpp0 exits with signal 11, not signal 6. > - I'm building my kernel in the old fashion with a slight modification > > $ config -d /usr/obj/kernel /path/to/CONFIGFILE && \ > cd /usr/obj/kernel && make depend && make > > but cpp0 still crashes at the first stage of 'make depend'. > > > > Thoughts? Anything I can provide to help narror this down further? > > Now I'm wondering where I can build a cpp0 with debug symbols enabled > so that I can post the backtrace... By the way, I've tracked down the first .c file that causes cpp0 to sig11. It's /usr/src/sys/netkey/keysock.c,rev 1.16(my source tree is placed under /home/usr.src and symlinked from /usr). $ MKDEP_CPP="cc -E" CC="cc" mkdep -a -f .newdep -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I/home/usr.src/sys -I/home/usr.src/sys/dev -I/home/usr.src/sys/contrib/dev/acpica -I/home/usr.src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding /home/usr.src/sys/netkey/keysock.c But if I remove '-march=pentiumpro', cpp0 doesn't crash. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: can't compile kernel?
Hi. On Wed, Sep 18, 2002 at 01:15:40PM -0500, Steve Ames wrote: > > New datapoint: > > If I compile the kernel in the old fashion (config SB; cd ../compile/SB; > make depend all install) then the kernel compiles and installs fine. > However I get the error below when doing a 'make kernel' from /usr/src. > > Also even after rebooting onto the new kernel bind9 and mysql-server > are still exiting on signal6. I'm also getting cpp0 crashing while building new kernel. My world is from 2002-09-01(UTC) source. It looks similar to yours, except that: - cpp0 exits with signal 11, not signal 6. - I'm building my kernel in the old fashion with a slight modification $ config -d /usr/obj/kernel /path/to/CONFIGFILE && \ cd /usr/obj/kernel && make depend && make but cpp0 still crashes at the first stage of 'make depend'. > > Thoughts? Anything I can provide to help narror this down further? Now I'm wondering where I can build a cpp0 with debug symbols enabled so that I can post the backtrace... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic: free: address 0xc1802270(0xc1802000) has not been allocated.
Hello. I've encountered this panic with kernel from source as of 2002.07.30.00.00.00 . I've seen this panic message in Julian's message in July <[EMAIL PROTECTED]>, but he said in another mail that it was a pilot error. I've searched the list archive and PR, but found none similar to this. The backtrace is attached. I was about to start racoon under supervise, but I doubt it's reproducible only by starting racoon. Regards. Script started on Sun Aug 4 05:55:36 2002 $ gdb -k /usr/obj/kernel/kernel.debug vmcore.5 GNU gdb 5.2.0 (FreeBSD) 20020627 Copyright 2002 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-undermydesk-freebsd"... panic: bdwrite: buffer is not busy panic messages: --- panic: free: address 0xc1802270(0xc1802000) has not been allocated. syncing disks... panic: bdwrite: buffer is not busy Uptime: 11h31m12s Dumping 63 MB ata0: resetting devices .. ata0: mask=03 ostat0=50 ostat2=00 ad0: ATAPI 00 00 ata0-slave: ATAPI 00 00 ata0: mask=03 stat0=50 stat1=00 ad0: ATA 01 a5 ata0: devices=01 ad0: success setting PIO4 on generic chip done 16 32 48 --- #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213 213 dumping++; (kgdb) bt #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213 #1 0xc0195038 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:345 #2 0xc019526b in panic () at /usr/src/sys/kern/kern_shutdown.c:493 #3 0xc01d2f9d in bdwrite (bp=0x104) at /usr/src/sys/kern/vfs_bio.c:947 #4 0xc026c7c8 in ffs_update (vp=0xc137c948, waitfor=0) at /usr/src/sys/ufs/ffs/ffs_inode.c:125 #5 0xc02814e2 in ffs_fsync (ap=0xc7b93a48) at /usr/src/sys/ufs/ffs/ffs_vnops.c:272 #6 0xc027ea98 in ffs_sync (mp=0xc1288800, waitfor=2, cred=0xc09ecd80, td=0xc0335580) at vnode_if.h:463 #7 0xc01e4d28 in sync (td=0xc0335580, uap=0x0) at /usr/src/sys/kern/vfs_syscalls.c:127 #8 0xc0194c2c in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:254 #9 0xc019526b in panic () at /usr/src/sys/kern/kern_shutdown.c:493 #10 0xc018898e in free (addr=0xc1802270, type=0xc0336c80) at /usr/src/sys/kern/kern_malloc.c:226 #11 0xc018e139 in pargs_free (pa=0x0) at /usr/src/sys/kern/kern_proc.c:1125 #12 0xc018e286 in pargs_drop (pa=0xc1802270) at /usr/src/sys/kern/kern_proc.c:1148 #13 0xc018e4a7 in sysctl_kern_proc_args (oidp=0xc033a000, arg1=0xc7b93ca8, arg2=1, req=0xc7b93bfc) at /usr/src/sys/kern/kern_proc.c:1191 #14 0xc019e966 in sysctl_root (oidp=0x0, arg1=0xc1802270, arg2=-944161796, req=0xc1802270) at /usr/src/sys/kern/kern_sysctl.c:1143 #15 0xc019ec3d in userland_sysctl (td=0x0, name=0xc7b93c9c, namelen=4, ---Type to continue, or q to quit--- old=0xc1802270, oldlenp=0xc1802270, inkernel=0, new=0xc7b93bfc, newlen=0, retval=0xc7b93c94) at /usr/src/sys/kern/kern_sysctl.c:1241 #16 0xc019ea6d in __sysctl (td=0x0, uap=0xc7b93d10) at /usr/src/sys/kern/kern_sysctl.c:1180 #17 0xc02d536d in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134541312, tf_esi = -1077939844, tf_ebp = -1077939896, tf_isp = -944161420, tf_ebx = 672297404, tf_edx = -1077939840, tf_ecx = 4, tf_eax = 202, tf_trapno = 22, tf_err = 2, tf_eip = 671861531, tf_cs = 31, tf_eflags = 663, tf_esp = -1077939940, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1050 #18 0xc02c62cd in Xint0x80_syscall () at {standard input}:140 ---Can't read userspace from dump, or kernel process--- (kgdb) frame 12 #12 0xc018e286 in pargs_drop (pa=0xc1802270) at /usr/src/sys/kern/kern_proc.c:1148 1148pargs_free(pa); (kgdb) print pa $1 = (struct pargs *) 0xc1802270 (kgdb) down #11 0xc018e139 in pargs_free (pa=0x0) at /usr/src/sys/kern/kern_proc.c:1125 1125FREE(pa, M_PARGS); (kgdb) list 1120 1121void 1122pargs_free(struct pargs *pa) 1123{ 1124 1125FREE(pa, M_PARGS); 1126} 1127 1128void 1129pargs_hold(struct pargs *pa) (kgdb) up #12 0xc018e286 in pargs_drop (pa=0xc1802270) at /usr/src/sys/kern/kern_proc.c:1148 1148pargs_free(pa); (kgdb) print *pa $2 = {ar_ref = 0, ar_length = 3246400112, ar_args = 0xc1802278 ""}
integer devide fault in dummynet_io
m_freem(m); 1226return ENOBUFS ; 1227} 1228 1229/* 1230 * Below, the rt_unref is only needed when (pkt->dn_dir == DN_TO_IP_OUT) 1231 * Doing this would probably save us the initial bzero of dn_pkt (kgdb) # hmm... (kgdb) print fs->weight $1 = 0 (kgdb) print action $2 = 42 (kgdb) print fwa->rule->cmd[fwa->rule->act_ofs].opcode $3 = O_LOG (kgdb) print *fs $4 = {next = 0x0, fs_nr = 0, flags_fs = 0, pipe = 0xc13cf100, parent_nr = 0, weight = 0, qsize = 50, plr = 0, flow_mask = {dst_ip = 0, src_ip = 0, dst_port = 0, src_port = 0, proto = 0 '\000', flags = 0 '\000'}, rq_size = 1, rq_elements = 1, rq = 0xc121c650, last_expired = 0, backlogged = 0, w_q = 0, max_th = 0, min_th = 0, max_p = 0, c_1 = 0, c_2 = 0, c_3 = 0, c_4 = 0, w_q_lookup = 0x0, lookup_depth = 0, lookup_step = 0, lookup_weight = 0, avg_pkt_size = 0, max_pkt_size = 0} (kgdb) qhwt@gzl$ exit
Re: panic at boot in ffs_valloc
Hi. On Wed, Jul 03, 2002 at 09:36:24PM +0200, Rasmus Skaarup wrote: > > I'm also suddenly having a panics - every 5 minutes actually, since my > latest cvsup a few hours ago. They seem to be related to some ufs > and ffs calls.. > > I'm not able to read my core dumps for some reason (gdb says "kernel > symbol 'cpuhead' not found.") and I don't have the time to scratch a > backtrace down by hand just now. > > The panicstring is: "bremfree: bp 0xc77e8670 not locked" > > Sincerely, > Rasmus Skaasrup > > On Wed, 3 Jul 2002, Andrew R. Reiter wrote: > > > :I cvsup'd and built world+kernel a few hours ago and was happy to see > > :KDE working again, but I got a spontaneous reboot while trying to track > > :down a segfault in a mozilla build component. I "boot -v"'ed and as > > :soon as the login prompt came up I hit a panic. I'm guessing the > > :backgorund fsck had something to do with it. I'll hand-copy the trace > > :here; any debugging info needed while my box is stuck at the debugger, > > :lemme know: > > > > > > I don't have the output to show people since I was trying to reproduce but > > couldnt, but i got essentially the same panic, but it came only from a > > syscall to open() that called ufs_create() -> ufs_makeinode -> > > ffs_valloc() -> panic. > > > > I can try and reproduce (tho, mine occured when just running cscope) and > > get a dump. same here, and I can reproduce the panic by: $ cd /tmp $ for i in `jot 300 1`; do touch $i; done this panics when $i reaches around 128 on my machine. However, the next one doesn't: $ mkdir /tmp/foo $ cd /tmp/foo $ for i in `jot 300 1`; do touch $i; done I have a 256Mbytes of swap-backed /tmp configured in /etc/rc.local as follows: $ cat /etc/rc.local mdmfs -p 1777 -s 256M md0 /tmp According to a post on an anonymous BBS in Japan, malloc-backed /tmp doesn't seem to trigger the panic. Regards. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: LOOKUP_SHARED is default now
Hi. On Tue, Apr 09, 2002 at 01:08:04AM -0400, Jeff Roberson wrote: > This patch has seriously reduced file system deadlocks for several people. > It also makes concurrent file system access much faster in certain cases. > Since I have only heard good reports and no bad reports I'm going to > enable it by default. If you do experience some file system deadlocks > please let me know. You may revert to the previous behavior with 'options > LOOKUP_EXCLUSIVE'. I will take this away after a month or so if there are > no problems. I've been struggling upgrading kernel since beginning of April, and finally found I have to add "options LOOKUP_EXCLUSIVE" to my kernel config file. Without LOOKUP_EXCLUSIVE, - some of the processes stall in "inode" state, and can't be killed by any signals - shutting down(and maybe unmounting) the system results in the panic: lockmgr: upgrade exclusive lock The stalling processes are all touching files under nullfs-mounted directories, so I think nullfs code is not yet LOOKUP_SHARED-safe. If anyone is interested, I can post the backtrace and my kernel config (after upgrading the world and rebuilding the panicking kernel). Regards. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/usr.sbin/ppp Makefile async.c async.h atm.cbundle.c ccp.c ccp.h chap.c chap.h chat.c command.c datalink.cdatalink.h defs.c defs.h ether.c exec.c i4b.c lcp.c lcp.h main.cmppe.c netgraph.c netgraph.h physical.c physical.h route.c tcp.c ...
Hello. > brian 2002/03/30 04:30:11 PST > Modified files: > usr.sbin/ppp Makefile async.c async.h atm.c bundle.c > ccp.c ccp.h chap.c chap.h chat.c > command.c datalink.c datalink.h defs.c > defs.h ether.c exec.c i4b.c lcp.c lcp.h > main.c mppe.c physical.c physical.h > route.c tcp.c tty.c udp.c : > 1.126 +13 -17src/usr.sbin/ppp/bundle.c In the 6th chunk, a decrement to bundle.unit after succeeding ID0kldload() is lost. This results in the unit number of tun device set to 1(tun1) instead of 0(tun0) when if_tun.ko is not yet kldload'ed() before ppp is invoked. If I exit from ppp and start it again, ppp uses tun0, leaving tun1 behind. After that and receiving a few megabytes, I've experienced a mysterious panic (getnewvnode: free vnode isn't). The panic itself, though, is something similar to that I'm always seeing whenever I didn't kill pccardd before doing acpiconf -s3, so it might be unrelated to this issue. Anyway, a patch is attached. Regards. Index: usr.sbin/ppp/bundle.c === RCS file: /home/cvs/freebsd/src/usr.sbin/ppp/bundle.c,v retrieving revision 1.127 diff -u -r1.127 bundle.c --- usr.sbin/ppp/bundle.c 30 Mar 2002 12:52:55 - 1.127 +++ usr.sbin/ppp/bundle.c 14 Apr 2002 05:46:37 - @@ -711,7 +711,8 @@ * Attempt to load the tunnel interface KLD if it isn't loaded * already. */ -loadmodules(LOAD_VERBOSLY, "if_tun", NULL); +if (loadmodules(LOAD_VERBOSLY, "if_tun", NULL) > 0) + bundle.unit--; continue; } #endif Index: usr.sbin/ppp/defs.c === RCS file: /home/cvs/freebsd/src/usr.sbin/ppp/defs.c,v retrieving revision 1.45 diff -u -r1.45 defs.c --- usr.sbin/ppp/defs.c 30 Mar 2002 12:30:09 - 1.45 +++ usr.sbin/ppp/defs.c 14 Apr 2002 05:46:13 - @@ -420,19 +420,26 @@ } } -void +/* return: number of modules kldload'ed */ +int loadmodules(int how, const char *module, ...) { #if defined(__FreeBSD__) && !defined(NOKLDLOAD) va_list ap; + int loaded = 0; va_start(ap, module); while (module != NULL) { -if (modfind(module) == -1 && ID0kldload(module) == -1 && -how == LOAD_VERBOSLY) - log_Printf(LogWARN, "%s: Cannot load module\n", module); +if (modfind(module) == -1) { + if (ID0kldload(module) == -1) { + if (how == LOAD_VERBOSLY) + log_Printf(LogWARN, "%s: Cannot load module\n", module); + } else + ++loaded; +} module = va_arg(ap, const char *); } va_end(ap); #endif + return loaded; } Index: usr.sbin/ppp/defs.h === RCS file: /home/cvs/freebsd/src/usr.sbin/ppp/defs.h,v retrieving revision 1.65 diff -u -r1.65 defs.h --- usr.sbin/ppp/defs.h 30 Mar 2002 12:30:09 - 1.65 +++ usr.sbin/ppp/defs.h 14 Apr 2002 05:31:00 - @@ -139,4 +139,4 @@ extern fd_set *mkfdset(void); extern void zerofdset(fd_set *); extern void Concatinate(char *, size_t, int, const char *const *); -extern void loadmodules(int, const char *, ...); +extern int loadmodules(int, const char *, ...);
Dhclient with non-writable /etc/resolv.conf
After having updated to the world past 2002-02-19, dhclient started very fast cycle of acquiring and releasing leases every time it was attached to the local network, like it's attacking the DHCP server. After all, it was /sbin/dhclient-script that failed trying to update /etc/resolv.conf which had schg turned on (I needed this to prevent ppp from replacing resolv.conf when my / was mounted read-write, until I found 'resolv readonly' option in in ppp(1) manual). The fix below also covers read-only root filesystem case. --- /usr/src/contrib/isc-dhcp/client/scripts/freebsdThu Mar 21 14:49:53 2002 +++ /usr/src/contrib/isc-dhcp/client/scripts/freebsdThu Mar 21 15:03:53 2002 @@ -9,7 +9,8 @@ fi make_resolv_conf() { - if [ "x$new_domain_name" != x ] && [ x"$new_domain_name_servers" != x ]; then + if [ "x$new_domain_name" != x ] && [ x"$new_domain_name_servers" != x ] && \ +[ -w /etc/resolv.conf -o -w /etc -a ! -e /etc/resolv.conf ]; then echo search $new_domain_name >/etc/resolv.conf for nameserver in $new_domain_name_servers; do echo nameserver $nameserver >>/etc/resolv.conf Regards. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Won't boot after the commits to timecounter code
On Thu, Mar 07, 2002 at 10:40:07AM +0900, I wrote: > > Apparently you have KTR enabled (not the default in GENERIC). I think > > WITNESS+KTR already caused nasty recursion from the mtx_lock_spin, and > > we now get an endless loop when nanotime() is called with an invalid > > timecounter in the following call chain: > > > > tc_init -> tc_windup -> tco_delta -> i8254_get_timecount -> mtx_foo -> > > witness_foo -> ktr_foo -> nanotime, > > > > just after nanotime has somehow recursed back into i8254_get_timecounter > > without causing endless recursion! > > Yes, I have the following KTR options enabled (I think I brought this from > NOTES about a year before): > options KTR > options KTR_EXTEND > options KTR_ENTRIES=1024 > options KTR_COMPILE=0x3f > options KTR_MASK=0x201208 > options KTR_CPUMASK=0x3 > > but WITNESS is commented out. > > > Try setting MTX_NOWITNESS in the initialization of clock_lock in > > i386/machdep.c. > > O.k., I'll try this(but does it affect a kernel without WITNESS?), then > try a kernel without KTR options. I've found the following: - KTR alone can make this happen; it locked solid with or without WITNESS. - Setting MTX_NOWITNESS in the initialization of clock_lock didn't work. - If I disable KTR, it just works fine without any patches. - If I enable KTR with KTR_LOCK in "options KTR_MASK", it freezes after Timecounter "i8254" frequency 1193182 Hz message. - If I enable KTR without KTR_LOCK in "options KTR_MASK", it boots but it locks solid the moment I inserted a pccard (I'm using OLDCARD). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Won't boot after the commits to timecounter code
On Thu, Mar 07, 2002 at 04:34:00AM +1100, Bruce Evans wrote: > On Wed, 6 Mar 2002 [EMAIL PROTECTED] wrote: > > > I inserted a pair of printf() inside mtx_lock_spin/mtx_unlock_spin in > > i8254_get_timecount() and it kept printing the message while tc_init() > > was blocked, so I think it's blocked at mtx_lock_spin in i8254_get_timecount() > > when called from tc_init(), but not when called from somewhere else. > > (maybe an interrupt handler?) > > Apparently you have KTR enabled (not the default in GENERIC). I think > WITNESS+KTR already caused nasty recursion from the mtx_lock_spin, and > we now get an endless loop when nanotime() is called with an invalid > timecounter in the following call chain: > > tc_init -> tc_windup -> tco_delta -> i8254_get_timecount -> mtx_foo -> > witness_foo -> ktr_foo -> nanotime, > > just after nanotime has somehow recursed back into i8254_get_timecounter > without causing endless recursion! Yes, I have the following KTR options enabled (I think I brought this from NOTES about a year before): options KTR options KTR_EXTEND options KTR_ENTRIES=1024 options KTR_COMPILE=0x3f options KTR_MASK=0x201208 options KTR_CPUMASK=0x3 but WITNESS is commented out. > Try setting MTX_NOWITNESS in the initialization of clock_lock in > i386/machdep.c. O.k., I'll try this(but does it affect a kernel without WITNESS?), then try a kernel without KTR options. Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Won't boot after the commits to timecounter code
On Wed, Mar 06, 2002 at 08:49:18AM +0100, Poul-Henning Kamp wrote: > > In message <20020306054514.GA395@gzl>, [EMAIL PROTECTED] writes: > > >Hello. > > >After upgrading to the kernel as of 2002-03-03 00:00:00(UTC), it stopped > > >booting just after the message: > > > > > >Timecounter "i8254" frequency 1193182 Hz > > > > > >With some debugging printf()'s inserted, I found it was tc->tc_get_timecount() > > >called from tco_delta() called just after the bcopy() in tc_windup(). > > >So maybe the next place I have to look at is i8254_get_timecount(), which is in > > >/sys/i386/isa/clock.c, but the last (effective) commit to this file is > > >revision 1.180(at the end of January). > > > > > >I couldn't even drop into DDB; no response other than to power button. > > >The last bootable(and stable so far) kernel is from 2002-02-24. > > >I don't think this is caused by some leftover in the work directory > > >since I always build kernels in a new empty directory under /usr/obj. > > > > > >Any (clue|fix)\? > > The only thing I know off right now is this thing from BDE which > I havn't been able to verify yet: > > > > > From:Bruce Evans <[EMAIL PROTECTED]> > Subject: dummy_timecounter broken; breaks booting with -d > To: <[EMAIL PROTECTED]> > Message-Id: <[EMAIL PROTECTED]> > Date:Tue, 05 Mar 2002 08:09:26 +1100 > > %%% > Index: kern_tc.c > === > RCS file: /home/ncvs/src/sys/kern/kern_tc.c,v > retrieving revision 1.116 > diff -u -2 -r1.116 kern_tc.c > --- kern_tc.c 26 Feb 2002 09:16:27 - 1.116 > +++ kern_tc.c 4 Mar 2002 21:08:03 - > @@ -192,4 +252,14 @@ > gen = tc->tc_generation; > bintime2timeval(&tc->tc_offset, tvp); > + /* > + * XXX dummy_timecounter is now broken. Its tc_get_timecount > + * needs to be called before it works, and that doesn't > + * always happen naturally. In particular, we spin forever > + * here after booting with -d unless we do an unnatural call > + * here, since the screen timeout code is always run on entry > + * to ddb, and it calls here. > + */ > + if (gen == 0 && timecounter == &dummy_timecounter) > + (void)tc->tc_get_timecount(tc); > } while (gen == 0 || gen != tc->tc_generation); > } > %%% > > Bruce Hmm, this doesn't seem to change the situation. I tried reverting the following files: /sys/sys/timetc.h:1.46 -> 1.45 /sys/kern/kern_tc.c: 1.116 -> 1.114 and managed to get into the single-user mode, but this of course doesn't solve the problem. I inserted a pair of printf() inside mtx_lock_spin/mtx_unlock_spin in i8254_get_timecount() and it kept printing the message while tc_init() was blocked, so I think it's blocked at mtx_lock_spin in i8254_get_timecount() when called from tc_init(), but not when called from somewhere else. (maybe an interrupt handler?) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Won't boot after the commits to timecounter code
Hello. After upgrading to the kernel as of 2002-03-03 00:00:00(UTC), it stopped booting just after the message: Timecounter "i8254" frequency 1193182 Hz With some debugging printf()'s inserted, I found it was tc->tc_get_timecount() called from tco_delta() called just after the bcopy() in tc_windup(). So maybe the next place I have to look at is i8254_get_timecount(), which is in /sys/i386/isa/clock.c, but the last (effective) commit to this file is revision 1.180(at the end of January). I couldn't even drop into DDB; no response other than to power button. The last bootable(and stable so far) kernel is from 2002-02-24. I don't think this is caused by some leftover in the work directory since I always build kernels in a new empty directory under /usr/obj. Any (clue|fix)\? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message