RFC 3514

2003-04-02 Thread qhwt 
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

2003-03-25 Thread qhwt 
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

2003-03-24 Thread qhwt 
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 ...

2003-03-08 Thread qhwt 
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

2003-02-01 Thread qhwt 
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?

2002-10-14 Thread qhwt 

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(?)

2002-10-03 Thread qhwt 

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 return to continue, or q return 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 ufs, 
  v_data = 0xc14b9800, v_lock = {lk_interlock = 0xc036f728, lk_flags = 64

Re: Trouble Building CURRENT on STABLE, cpp seg. fault

2002-09-22 Thread qhwt 

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 URL: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: Trouble Building CURRENT on STABLE, cpp seg. fault

2002-09-22 Thread qhwt 

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 URL: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 URL: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: can't compile kernel?

2002-09-19 Thread qhwt 

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

Re: can't compile kernel?

2002-09-19 Thread qhwt 

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

panic: free: address 0xc1802270(0xc1802000) has not been allocated.

2002-08-03 Thread qhwt 

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 return to continue, or q return 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

2002-07-16 Thread qhwt 
 * 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

2002-07-15 Thread qhwt 

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

2002-05-06 Thread qhwt 

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 ...

2002-04-14 Thread qhwt 

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

2002-03-22 Thread qhwt 

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

2002-03-14 Thread qhwt 

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

2002-03-06 Thread qhwt 

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

Re: Won't boot after the commits to timecounter code

2002-03-06 Thread qhwt 

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

Won't boot after the commits to timecounter code

2002-03-05 Thread qhwt 

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