[current tinderbox] failure on amd64/amd64

2003-11-15 Thread Tinderbox
TB --- 2003-11-15 06:02:11 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org
TB --- 2003-11-15 06:02:11 - starting CURRENT tinderbox run for amd64/amd64
TB --- 2003-11-15 06:02:11 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-11-15 06:04:25 - building world
TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything..
[...]
cc -O -pipe-o from from.o 
gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/usr.bin/from/from.1  
from.1.gz
=== usr.bin/fstat
cc -O -pipe   -c 
/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/usr.bin/fstat/cd9660.c
cc -O -pipe   -c 
/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/usr.bin/fstat/fstat.c
In file included from 
/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/usr.bin/fstat/fstat.c:75:
/home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/include/nfsclient/nfsnode.h:129:
 error: field `n_rfc' has incomplete type
/home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/include/nfsclient/nfsnode.h:130:
 error: field `n_wfc' has incomplete type
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/usr.bin/fstat.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/usr.bin.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src.
TB --- 2003-11-15 06:57:45 - TB --- /usr/bin/make returned exit code  1 
TB --- 2003-11-15 06:57:45 - TB --- ERROR: failed to build world
TB --- 2003-11-15 06:57:45 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dc still reporting collisions

2003-11-15 Thread Jos Backus
On Sat, Nov 15, 2003 at 04:52:14PM +1000, Andy Farkas wrote:
 The dc(4) driver is still reporting collisions on 100 Mbit full-duplex
 links:
[snip]
  netstat -i
 NameMtu Network   Address  Ipkts IerrsOpkts Oerrs  Coll
 dc01500 Link#1  00:00:e8:89:b9:6626463 026737 13253 225301

Fwiw, I'm seeing the same with tx(4):

lizzy:~% ifconfig tx0
tx0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
inet 10.0.0.2 netmask 0xff00 broadcast 10.0.0.255
inet 10.0.0.10 netmask 0x broadcast 10.0.0.10
ether 00:e0:29:09:e4:1a
media: Ethernet autoselect (10baseT/UTP)
status: active
lizzy:~% netstat -i
NameMtu Network   Address  Ipkts IerrsOpkts Oerrs  Coll
tx01500 Link#1  00:e0:29:09:e4:1a   154423 1   118093 0   253
tx01500 10/24 lizzy   159162 -   122841 - -
tx01500 10.0.0.10/32  lizzy-proxy 28 -   28 - -
lo0   16384 Link#25347 0 5347 0 0
lo0   16384 your-net  localhost  442 -  442 - -
lizzy:~% 

It's gotten so bad that I can no longer transfer files from a Windows system
to this FreeBSD system (both are on the same 10BaseT hub). I only rarely used
to see collisions before, and filetransfers have always worked just fine. Last
time I know for sure this worked was October 17th.

-- 
Jos Backus   _/  _/_/_/  Sunnyvale, CA
_/  _/   _/
   _/  _/_/_/
  _/  _/  _/_/
jos at catnook.com_/_/   _/_/_/  require 'std/disclaimer'
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dc still reporting collisions

2003-11-15 Thread Andy Farkas
Jos Backus wrote:

 Fwiw, I'm seeing the same with tx(4):

Looks like a different problem.

 lizzy:~% ifconfig tx0
 tx0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
 inet 10.0.0.2 netmask 0xff00 broadcast 10.0.0.255
 inet 10.0.0.10 netmask 0x broadcast 10.0.0.10
 ether 00:e0:29:09:e4:1a
 media: Ethernet autoselect (10baseT/UTP)
 status: active
 lizzy:~% netstat -i
 NameMtu Network   Address  Ipkts IerrsOpkts Oerrs  Coll
 tx01500 Link#1  00:e0:29:09:e4:1a   154423 1   118093 0   253
 tx01500 10/24 lizzy   159162 -   122841 - -
 tx01500 10.0.0.10/32  lizzy-proxy 28 -   28 - -
 lo0   16384 Link#25347 0 5347 0 0
 lo0   16384 your-net  localhost  442 -  442 - -
 lizzy:~%

The dc(4) driver currently has an almost 1:1 ratio of packets:collisions.
Your tx0 is quite low.

Seishi Hiragushi [EMAIL PROTECTED] reported this 1.5 months ago:

Message-Id: [EMAIL PROTECTED]


--

 :{ [EMAIL PROTECTED]

Andy Farkas
System Administrator
   Speednet Communications
 http://www.speednet.com.au/


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dc still reporting collisions

2003-11-15 Thread Andy Farkas
Andy Farkas replies to himself:

 The dc(4) driver currently has an almost 1:1 ratio of packets:collisions.
 Your tx0 is quite low.


Ack! I can't count. Or my numerical recognition system is failing

NameMtu Network   Address  Ipkts IerrsOpkts Oerrs  Coll
dc01500 Link#1  00:00:e8:89:b9:6626463 026737 13253 225301

Ipkts + Opkts  collisions  :(

--

 :{ [EMAIL PROTECTED]

Andy Farkas
System Administrator
   Speednet Communications
 http://www.speednet.com.au/


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


[current tinderbox] failure on i386/i386

2003-11-15 Thread Tinderbox
TB --- 2003-11-15 06:57:46 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org
TB --- 2003-11-15 06:57:46 - starting CURRENT tinderbox run for i386/i386
TB --- 2003-11-15 06:57:46 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/i386/i386
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-11-15 07:00:02 - building world
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything..
[...]
cc -O -pipe -mcpu=pentiumpro   -o from from.o 
gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.bin/from/from.1  
from.1.gz
=== usr.bin/fstat
cc -O -pipe -mcpu=pentiumpro  -c 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.bin/fstat/cd9660.c
cc -O -pipe -mcpu=pentiumpro  -c 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.bin/fstat/fstat.c
In file included from 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.bin/fstat/fstat.c:75:
/home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include/nfsclient/nfsnode.h:129:
 error: field `n_rfc' has incomplete type
/home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include/nfsclient/nfsnode.h:130:
 error: field `n_wfc' has incomplete type
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.bin/fstat.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.bin.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src.
TB --- 2003-11-15 07:52:02 - TB --- /usr/bin/make returned exit code  1 
TB --- 2003-11-15 07:52:02 - TB --- ERROR: failed to build world
TB --- 2003-11-15 07:52:02 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Two processes with PID == 0

2003-11-15 Thread Dorin H
FWIW: I don't know exactly why/what is happening, but
I've seen it once. In my case, the process (script
foo.log  make install clean  exit) failed abruptly
and the process entry was not correctly cleared. You
see that your second process with pid 0 (xbattbar) is
a zombie (Z), swapped out (W).  I was unable to unlog
also from the terminal due to that ( I was remotely
SSH connected). I brutly closed the SSH window and
upon relogin, the entry dissapeared.

I run -current from 10/29 and SCHED_4BSD.
/Dorin

--- Munehiro Matsuda [EMAIL PROTECTED] wrote:
 Hi all,
 
 I have wierd problem with -current from Fri Nov 14
 19:58:02 JST and
 with SCHED_4BSD scheduler.
 
 There are two processes that have the same PID as
 0!!
 Here's snippest from 'ps axl' output:
 
   UID   PID  PPID CPU PRI NI   VSZ  RSS MWCHAN STAT 
 TT   TIME COMMAND
 0 0 0   0 -16  0 04 sched  DLs  
 ??0:00.35  (swapper)
   123 0   560   0 -84  0 00 -  ZW   
 v00:00.00  (xbattbar)
 0   560   554  17  98  0  5128 3292 select I
 v00:00.56 xterm -C -sb
 
 The xbattbar process was started with the following
 ~/.xinitrc script
 that I use to star X Window.
 

---8-8-8-8-8-8-8-8-8-8-8--
 if [ -f /usr/X11R6/bin/xbattbar ]; then
 nice -20 xbattbar -t 1 -p 20 top 
 fi
 
 if [ -f /usr/X11R6/bin/unclutter ]; then
 unclutter -jitter 5 
 fi
 
 twm 
 # xclock -geometry 80x80+0-0 
 xclock -d -geometry 160x18+900+1 -padding 3 -bg
 maroon -fg gray85 -update 3 
 kterm -sb -rw -km euc -geometry 80x24+3+25 -sl 1000
 
 kterm -sb -rw -km euc -geometry 80x24+3+392 -sl 1000
 
 sleep 1
 exec xterm -C -sb -rw -geometry 80x49+0+1 -name
 login -iconic \#+0+1

---8-8-8-8-8-8-8-8-8-8-8--
 
 Anybody have any idea what has happend?
 
 Thanks,
  Haro

=--
_ _Munehiro (haro) Matsuda
  -|- /_\  |_|_|   Internet Solution Dept., Kubota
 Graphics Technologies Inc.
  /|\ |_|  |_|_|   2-8-8 Shinjuku Shinjuku-ku Tokyo
 160-0022, Japan
   Tel: +81-3-3225-0767  Fax:
 +81-3-3225-0740
   Email: [EMAIL PROTECTED]
 ___
 [EMAIL PROTECTED] mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to
[EMAIL PROTECTED]


__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Using Geom to mirror root partitions?

2003-11-15 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Josef Karthauser writes:

What's the best way to prepare for this?  Should I leave some
unallocated space at the beginning of the disk so that any magic geom
bits can be inserted later?

Rather:  leave a bit free at the end.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


[current tinderbox] failure on i386/pc98

2003-11-15 Thread Tinderbox
TB --- 2003-11-15 07:52:03 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org
TB --- 2003-11-15 07:52:03 - starting CURRENT tinderbox run for i386/pc98
TB --- 2003-11-15 07:52:03 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/i386/pc98
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-11-15 07:54:28 - building world
TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything..
[...]
cc -O -pipe -mcpu=pentiumpro   -o from from.o 
gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/usr.bin/from/from.1  
from.1.gz
=== usr.bin/fstat
cc -O -pipe -mcpu=pentiumpro  -c 
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/usr.bin/fstat/cd9660.c
cc -O -pipe -mcpu=pentiumpro  -c 
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/usr.bin/fstat/fstat.c
In file included from 
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/usr.bin/fstat/fstat.c:75:
/home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include/nfsclient/nfsnode.h:129:
 error: field `n_rfc' has incomplete type
/home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include/nfsclient/nfsnode.h:130:
 error: field `n_wfc' has incomplete type
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/usr.bin/fstat.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/usr.bin.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src.
TB --- 2003-11-15 08:50:04 - TB --- /usr/bin/make returned exit code  1 
TB --- 2003-11-15 08:50:04 - TB --- ERROR: failed to build world
TB --- 2003-11-15 08:50:04 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: console freezes

2003-11-15 Thread Soren Schmidt
It seems Andy Farkas wrote:
 
 When messages are sent to console rapidly, console becomes unavailable :(

That is an oold problem, at least its been do for months...

 My previous email complains of messages being spewed to the console. These
 messages stop after a few minutes and the console is dead.
 
 On another box of mine, same thing happens. Different messages get spewed
 to console and it locks up (I am preparing another email about it,
 messages are ATA related)

Please include dmesg and pciconf -l output there as well.

-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


[current tinderbox] failure on ia64/ia64

2003-11-15 Thread Tinderbox
TB --- 2003-11-15 08:50:05 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org
TB --- 2003-11-15 08:50:05 - starting CURRENT tinderbox run for ia64/ia64
TB --- 2003-11-15 08:50:05 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-11-15 08:54:09 - building world
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything..
TB --- 2003-11-15 10:02:47 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
 Kernel build for GENERIC started on Sat Nov 15 10:02:47 GMT 2003
 Kernel build for GENERIC completed on Sat Nov 15 10:18:56 GMT 2003
TB --- 2003-11-15 10:18:56 - generating LINT kernel config
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src/sys/ia64/conf
TB --- /usr/bin/make -B LINT
TB --- 2003-11-15 10:18:57 - building LINT kernel
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src
TB --- /usr/bin/make buildkernel KERNCONF=LINT
 Kernel build for LINT started on Sat Nov 15 10:18:57 GMT 2003
[...]
cc -c -O -pipe  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99  -nostdinc -I-  -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing 
-fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata 
-ffreestanding -Werror  
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/netinet/in_rmx.c
cc -c -O -pipe  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99  -nostdinc -I-  -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing 
-fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata 
-ffreestanding -Werror  
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/netinet/ip_divert.c
cc -c -O -pipe  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99  -nostdinc -I-  -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing 
-fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata 
-ffreestanding -Werror  
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/netinet/ip_dummynet.c
cc -c -O -pipe  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99  -nostdinc -I-  -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd 

Re: /etc/rc.d/ipsec starts not in time

2003-11-15 Thread Hajimu UMEMOTO
Hi,

 On Sun, 02 Nov 2003 15:49:35 +0200
 Kostyuk Oleg [EMAIL PROTECTED] said:

cubProblem is in order of starting /etc/rc.d/ipsec.
cubIt must start BEFORE any network interaction,
cubmay be even before configuring interfaces.
cubBut I not sure in case with diskless mashines.

cub-# BEFORE:  DAEMON
cub+# BEFORE:  NETWORK

It is not sufficient.  There is setkey(8) in /usr/sbin.  It means that
we cannot protect NFS exported /usr by IPsec.  If there is no
objection, I wish to move setkey(8) into /sbin like NetBSD did.

Sincerely,

--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED]  [EMAIL PROTECTED]  [EMAIL PROTECTED],jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: upgraded to CURRENT = system is dead

2003-11-15 Thread Antoine Jacoutot
Selon long [EMAIL PROTECTED]:
 reboot
 make world
 single user mode, make installworld
 reboot
 
 and it's up and running... no more sig12 or anything like that...

Yes, but no !

I don't have any sig12 error...
I have: /libexec/ld-elf.so.1: Shared object libedit.so.4 not found
And I can't even mount anything :(
I followed everything that was in UPDATING...

So my box is really dead... right ?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


[current tinderbox] failure on sparc64/sparc64

2003-11-15 Thread Tinderbox
TB --- 2003-11-15 10:30:12 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org
TB --- 2003-11-15 10:30:12 - starting CURRENT tinderbox run for sparc64/sparc64
TB --- 2003-11-15 10:30:12 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-11-15 10:32:39 - building world
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything..
TB --- 2003-11-15 11:27:28 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
 Kernel build for GENERIC started on Sat Nov 15 11:27:28 GMT 2003
 Kernel build for GENERIC completed on Sat Nov 15 11:36:48 GMT 2003
TB --- 2003-11-15 11:36:48 - generating LINT kernel config
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf
TB --- /usr/bin/make -B LINT
TB --- 2003-11-15 11:36:48 - building LINT kernel
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src
TB --- /usr/bin/make buildkernel KERNCONF=LINT
 Kernel build for LINT started on Sat Nov 15 11:36:48 GMT 2003
[...]
cc -c -O -pipe  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99  -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd
 -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing 
-fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror  
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/netinet/in_rmx.c
cc -c -O -pipe  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99  -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd
 -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing 
-fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror  
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/netinet/ip_divert.c
cc -c -O -pipe  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99  -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd
 -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing 
-fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror  
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/netinet/ip_dummynet.c
cc -c -O -pipe  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99  -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd
 -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing 
-fno-builtin 

Re: Using Geom to mirror root partitions?

2003-11-15 Thread Alexander Leidinger
On Fri, 14 Nov 2003 22:51:27 +
Josef Karthauser [EMAIL PROTECTED] wrote:

 I've been a bit out of touch with developments recently.  I was
 wondering whether it's possible to mirror root partitions across two
 drives yet?  I seem to remember that this was something that geom could
 help with, but I've no idea as to whether it's a reality yet.

vinum is able to do it on 4.9 (and maybe 4.8) and on 5.x. Joerg did it.
I think there's also a chapter in the handbook. If not either ask me (I
will look up where the information is) or ask joerg.

Bye,
Alexander.

-- 
   Press every key to continue.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: signal 12's everywhere on Current with update this morning.

2003-11-15 Thread Peter Schultz
Richard Coleman wrote:
Andy Farkas wrote:

Richard Coleman wrote:



1. make buildworld
2. make buildkernel KERNCONF=NAME_OF_KERNEL_FILE
3. make installkernel KERNCONF=NAME_OF_KERNEL_FILE
4. shutdown -r now
5. boot into single user mode
6. fsck -p
7. mount -u /
8. mount -a -t ufs
9. swapon -a


 9.5 adjkerntz -i


Yep, forgot that part.  I keep all my system clocks on UTC so I never do 
this step when building world.

Running -CURRENT, I've gotten into the pattern of always building and 
installing a new /usr/include, just to be extra safe.

10a. cd /usr; mv include inc.old; mkdir include; cd /usr/src; make includes

10. make installworld
11. mergemaster
12. reboot

Pete...
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


devfs rule

2003-11-15 Thread Sven Esbjerg
Adding a rule to devfs on current seems broken or at least not in touch with
the man page.

# devfs rule add path acpi mode 660
devfs rule: ioctl DEVFSIO_RADD: Input/output error

Sven Esbjerg
-- 
http://www.usenet.dk/netikette - på forhånd tak.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


HEADS UP: the midi driver will be removed for a while

2003-11-15 Thread Seigo Tanimura
Mathew Kanner has developed the new version of the midi framework,
based on kobj(9) and buildable as a module.  As the first step to
replace the midi driver, the conventional one is removed from the
kernel in a minute.

Mathew will soon be starting a work to merge his driver.

-- 
Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: HEADS UP: the midi driver will be removed for a while

2003-11-15 Thread Kris Kennaway
On Sat, Nov 15, 2003 at 10:42:44PM +0900, Seigo Tanimura wrote:
 Mathew Kanner has developed the new version of the midi framework,
 based on kobj(9) and buildable as a module.  As the first step to
 replace the midi driver, the conventional one is removed from the
 kernel in a minute.
 
 Mathew will soon be starting a work to merge his driver.

Please coordinate with re@ since the freeze will be beginning shortly.

kris


pgp0.pgp
Description: PGP signature


Re: checking stopevent 2!

2003-11-15 Thread Robert Watson

On Sat, 15 Nov 2003, Andy Farkas wrote:

 These messages spew onto my console and into syslogd once every second:

Heh.  Sounds like your box is having a really bad day, we'll see if we
can't get it fixed up over the next couple of weeks as things settle out
:-).

I think John has this one in his sights already, we talked about the
sigacts locking during the release engineering telecon yesterday (CC'd
gratuitously in this message).  Basically, every place where a debugger
can stop a process there's a call to STOPEVENT(), which may sleep
indefinitely waiting to be restarted by the process performing the
debugging.  The problem appears to be that recent changes pushed a
STOPEVENT() call inside code holding a mutex, so the locking of that piece
of code needs to be changed slightly to make sure that doesn't happen.  IT
would probably be useful if you could drop to DDB and generate a trace for
the event.

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories


 
 ...
 Nov 15 16:05:44 kern.crit hummer kernel: checking stopevent 2 with the following 
 non-sleepable locks held:
 Nov 15 16:05:44 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0 
 (0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/kern_condvar.c:289
 Nov 15 16:05:44 kern.crit hummer kernel: checking stopevent 2 with the following 
 non-sleepable locks held:
 Nov 15 16:05:44 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0 
 (0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
 Nov 15 16:05:44 kern.crit hummer kernel: checking stopevent 2 with the following 
 non-sleepable locks held:
 Nov 15 16:05:45 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0 
 (0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
 Nov 15 16:05:45 kern.crit hummer kernel: checking stopevent 2 with the following 
 non-sleepable locks held:
 Nov 15 16:05:45 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0 
 (0xc4663aa8) locked @ /hummer/src-current/src/sys/kern/kern_synch.c:293
 Nov 15 16:05:45 kern.crit hummer kernel: checking stopevent 2 with the following 
 non-sleepable locks held:
 Nov 15 16:05:45 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0 
 (0xc4663aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
 Nov 15 16:05:45 kern.crit hummer kernel: checking stopevent 2 with the following 
 non-sleepable locks held:
 Nov 15 16:05:45 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0 
 (0xc4663aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
 Nov 15 16:05:45 kern.crit hummer kernel: checking stopevent 2 with the following 
 non-sleepable locks held:
 Nov 15 16:05:45 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0 
 (0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/kern_condvar.c:289
 Nov 15 16:05:45 kern.crit hummer kernel: checking stopevent 2 with the following 
 non-sleepable locks held:
 Nov 15 16:05:46 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0 
 (0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
 Nov 15 16:05:46 kern.crit hummer kernel: checking stopevent 2 with the following 
 non-sleepable locks held:
 Nov 15 16:05:46 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0 
 (0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/kern_condvar.c:289
 Nov 15 16:05:46 kern.crit hummer kernel: checking stopevent 2 with the following 
 non-sleepable locks held:
 Nov 15 16:05:46 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0 
 (0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
 Nov 15 16:05:46 kern.crit hummer kernel: checking stopevent 2 with the following 
 non-sleepable locks held:
 Nov 15 16:05:46 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0 
 (0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
 ...
 
 
 
 This is latest -current (cvsup'd a few hours ago)
 
 
 --
 
  :{ [EMAIL PROTECTED]
 
 Andy Farkas
 System Administrator
Speednet Communications
  http://www.speednet.com.au/
 
 
 ___
 [EMAIL PROTECTED] mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to [EMAIL PROTECTED]
 

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


5.2-RELEASE TODO

2003-11-15 Thread Robert Watson
This is an automated bi-weekly mailing of the FreeBSD 5.2 open issues list.
The live version of this list is available at:

http://www.FreeBSD.org/releases/5.2R/todo.html

Automated mailing of this list will continue through the release of
FreeBSD 5.2.


  FreeBSD 5.2 Open Issues

Open Issues

 This is a list of open issues that need to be resolved for FreeBSD 5.2. If
 you have any updates for this list, please e-mail [EMAIL PROTECTED]

Show stopper defects for 5.2-RELEASE

 ++
 |   Issue| Status | Responsible |Description |
 |++-+|
 | Panic when || | The panic reported in PR   |
 | rebuilding | -- | --  | kern/58228 must be fixed.  |
 | ata-raid arrays|| ||
 |++-+|
 ||| | Kris Kennaway reports that |
 ||| | Alpha packages builds are  |
 | pipe/VM corruption | -- | --  | being silently corrupted   |
 | on Alpha   || | and suspects pipe and vm   |
 ||| | issues. This must be   |
 ||| | investigated and resolved. |
 |++-+|
 ||| | The panic reported in PR   |
 | Lingering PSE  | -- | --  | kern/58787 is likely   |
 | instability|| | related to PSE problems|
 ||| | and must be fixed. |
 ++

Required features for 5.2-RELEASE

 ++
 |  Issue  |Status|  Responsible  |  Description  |
 |-+--+---+---|
 | |  |   | Kernel and userland   |
 | |  |   | bits are implemented  |
 | KSE support for | In progress  | Jake  | but untested and  |
 | sparc64 |  | Burkholder| known to be   |
 | |  |   | incomplete. Required  |
 | |  |   | for 5.2-RELEASE.  |
 |-+--+---+---|
 | |  |   | Userland bits |
 | KSE support for |  | Marcel| implemented, kernel   |
 | alpha   | In progress. | Moolenaar | bits not implemented. |
 | |  |   | Required for  |
 | |  |   | 5.2-RELEASE.  |
 |-+--+---+---|
 | |  |   | Significant parts of  |
 | |  |   | the network stack |
 | |  |   | (especially IPv4 and  |
 | |  |   | IPv6) now have|
 | |  |   | fine-grained locking  |
 | |  |   | of their data |
 | |  |   | structures. However,  |
 | |  |   | it is not yet |
 | |  |   | possible for the  |
 | |  |   | netisr threads to run |
 | Fine-grained|  |   | without Giant, due to |
 | network stack   |  |   | dependencies on   |
 | locking without | In progress  | Sam Leffler   | sockets, routing, |
 | Giant   |  |   | etc. A 5.2-RELEASE|
 | |  |   | goal is to have the   |
 | |  |   | network stack running |
 | |  |   | largely without   |
 | |  |   | Giant, which should   |
 | |  |   | substantially improve |
 | |  |   | performance of the|
 | |  |   | stack, as well as |
 | |  |   | other system  |
 | |  |   | components by |
 |  

stopevents?

2003-11-15 Thread Alfred Perlstein
anyone else seeing this:

checking stopevent 2 with the following non-sleepable locks held:
exclusive sleep mutex sigacts r = 0 (0xc6b51aa8) locked @ kern/subr_trap.c:260
checking stopevent 2 with the following non-sleepable locks held:
exclusive sleep mutex sigacts r = 0 (0xc6b51aa8) locked @ kern/subr_trap.c:260
checking stopevent 2 with the following non-sleepable locks held:
exclusive sleep mutex sigacts r = 0 (0xc6b51aa8) locked @ kern/kern_condvar.c:457
checking stopevent 2 with the following non-sleepable locks held:
exclusive sleep mutex sigacts r = 0 (0xc6b51aa8) locked @ kern/subr_trap.c:260
checking stopevent 2 with the following non-sleepable locks held:
exclusive sleep mutex sigacts r = 0 (0xc6b51aa8) locked @ kern/subr_trap.c:260

?


-- 
- Alfred Perlstein
- Research Engineering Development Inc.
- email: [EMAIL PROTECTED] cell: 408-480-4684
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: upgraded to CURRENT = system is dead

2003-11-15 Thread Antoine Jacoutot
Selon Dylan Wylie [EMAIL PROTECTED]:
 The idea is that you need to build a new kernel with the new sources before
 you install 
 world.
 You built your kernel before building the sources, so your kernel is based on
 old source.
 
 Quoting from another message:
  make buildworld
  make buildkernel
  make installkernel
  reboot
  make installworld

-- yes... but I get this during the installworld:
/libexec/ld-elf.so.1: Shared object libedit.so.4 not found
Stop in /usr/src

:(
I just tried it again from scratch but got the same error... !

If anyone has an idea...

Antoine
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: checking stopevent 2!

2003-11-15 Thread Cosmin Stroe
On Sat, Nov 15, 2003 at 09:38:37AM -0500, Robert Watson wrote:
 
 On Sat, 15 Nov 2003, Andy Farkas wrote:
 
 would probably be useful if you could drop to DDB and generate a trace for
 the event.
 

I've done that, in this email message:

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=2157067+0+current/freebsd-current

  
  ...
  Nov 15 16:05:44 kern.crit hummer kernel: checking stopevent 2 with the following 
  non-sleepable locks held:
  Nov 15 16:05:44 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0 
  (0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/kern_condvar.c:289
  Nov 15 16:05:44 kern.crit hummer kernel: checking stopevent 2 with the following 
  non-sleepable locks held:
  Nov 15 16:05:44 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0 
  (0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
  Nov 15 16:05:44 kern.crit hummer kernel: checking stopevent 2 with the following 
  non-sleepable locks held:
  Nov 15 16:05:45 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0 
  (0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
  Nov 15 16:05:45 kern.crit hummer kernel: checking stopevent 2 with the following 
  non-sleepable locks held:
  Nov 15 16:05:45 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0 
  (0xc4663aa8) locked @ /hummer/src-current/src/sys/kern/kern_synch.c:293
  Nov 15 16:05:45 kern.crit hummer kernel: checking stopevent 2 with the following 
  non-sleepable locks held:
  Nov 15 16:05:45 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0 
  (0xc4663aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
  Nov 15 16:05:45 kern.crit hummer kernel: checking stopevent 2 with the following 
  non-sleepable locks held:
  Nov 15 16:05:45 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0 
  (0xc4663aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
  Nov 15 16:05:45 kern.crit hummer kernel: checking stopevent 2 with the following 
  non-sleepable locks held:
  Nov 15 16:05:45 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0 
  (0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/kern_condvar.c:289
  Nov 15 16:05:45 kern.crit hummer kernel: checking stopevent 2 with the following 
  non-sleepable locks held:
  Nov 15 16:05:46 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0 
  (0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
  Nov 15 16:05:46 kern.crit hummer kernel: checking stopevent 2 with the following 
  non-sleepable locks held:
  Nov 15 16:05:46 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0 
  (0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/kern_condvar.c:289
  Nov 15 16:05:46 kern.crit hummer kernel: checking stopevent 2 with the following 
  non-sleepable locks held:
  Nov 15 16:05:46 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0 
  (0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
  Nov 15 16:05:46 kern.crit hummer kernel: checking stopevent 2 with the following 
  non-sleepable locks held:
  Nov 15 16:05:46 kern.crit hummer kernel: exclusive sleep mutex sigacts r = 0 
  (0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
  ...
  
  
  
  This is latest -current (cvsup'd a few hours ago)
  
  
  --
  
   :{ [EMAIL PROTECTED]
  
  Andy Farkas
  System Administrator
 Speednet Communications
   http://www.speednet.com.au/
  
  
  ___
  [EMAIL PROTECTED] mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-current
  To unsubscribe, send any mail to [EMAIL PROTECTED]
  
 
 ___
 [EMAIL PROTECTED] mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to [EMAIL PROTECTED]


Cosmin Stroe
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: upgraded to CURRENT = system is dead

2003-11-15 Thread Aron Håkanson
Lör 2003-11-15 klockan 16.30 skrev Antoine Jacoutot:
 Selon Dylan Wylie [EMAIL PROTECTED]:
  The idea is that you need to build a new kernel with the new sources 
  before you install 
  world.
  You built your kernel before building the sources, so your kernel is based 
  on old source.
  
  Quoting from another message:
   make buildworld
   make buildkernel
   make installkernel
   reboot
   make installworld
 
 -- yes... but I get this during the installworld:
 /libexec/ld-elf.so.1: Shared object libedit.so.4 not found
 Stop in /usr/src
 
 :(
 I just tried it again from scratch but got the same error... !
 
 If anyone has an idea...
 
 Antoine

If you are looking for a fast and temporary solution, just to finish the
installworld process, you can export the following value to the
LD_LIBRARY_PATH variable: $LD_LIBRARY_PATH:/lib:/usr/lib

Aron
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Unattended reboot was Re: signal 12's everywhere on Current with update this morning.

2003-11-15 Thread Dag-Erling Smørgrav
masta [EMAIL PROTECTED] writes:
 I found that if I put /rescue in my PATH before all the normal stuff,
 things tend to work (like ls).  For me I got caught doing the:
 make buildworld
 make buildkernel KERNCONF=FOO
 make installkernel
 mergemaster
 make installworld

 BAM! installworld fails, and the signal 12's start to manifest.

Reboot and run installworld.  Your new kernel will run both old and
new binaries just fine.

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


FreeBSD current, apache and php4 woes

2003-11-15 Thread Claus Guttesen
Hi.

I'm getting a bit desperate here. I recently moved our
web-servers from Linux, php4 4.1 and apache 1.3.20 to
FreeBSD 5.1 (mostly frozen branch), php 4.3.4 and
apache 1.3.29.

My problem is that the web-servers keep rebooting for
no apperant reason. They are up for about 20-24 hours
and then go down and up, with no message in the
message-log (other than that the filesystems weren't
unmounted properly etc.

The two web-servers are Dell Poweredge 1750 with dual
Xeon @ 3 Ghz. One is running the frozen 5.1 and the
other is running current as of Nov. 9'th. They are
performing well, the latter a bit faster than the
former. Both have 2 GB RAM.

The two other web-servers are based on an ASUS
motherboard and have dual Xeons @ 2.4 Ggz. One is
running frozen branch and one is running current as of
Oct. 30'th. The first has 2 GB RAM and the latter 1
GB.

The server with Oct. 30'th source appears to be the
most stable having been up for a couple of days.

After a draft to this mail was written I was lucky
to get some output to the screen (which is the first
time since we migrated):

panic: kmem_malloc(4096): kmem_map too small:
275251200 total allocated cpuid = 0; lapic.id =


Searching the archives indicated that the thread
http://www.freebsd.org/cgi/getmsg.cgi?fetch=717480+728561+/usr/local/www/db/text/2003/freebsd-current/20031005.freebsd-current
was very like my situation.

We are using php and imagemagick and are getting a lot
of empty files related to our web-pages. So /tmp and
/var/tmp is often used.

I have a crontjob which clean files older than 12
hours.

The two Dell-servers rebooted last nigth at three
o'clock in the morning indicating that the
/etc/periodic/daily scripts were running. I have also
been able to provoke a reboot finding and deleting
lots of tmp-files.

The problems did not show up while we tested them
internally.

How do I change system/kernel-parameters so I can
avoid the reboots? If I had the time I could have
investigated more on my own but my FreeBSD-migration
is on a thin line at work.

Disabling SMP is not an option.

I made the transition from Linux to FreeBSD arguing
that 1) it was at least as stable as Linux 2) I was
the one going to maintain the servers. So FreeBSD is
(unfortunately) _not_ very hot @ work.

A dmesg can be supplied if needed.

Regards
Claus


Yahoo! Mail (http://dk.mail.yahoo.com) - Gratis: 6 MB lagerplads, spamfilter og 
virusscan
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: upgraded to CURRENT = system is dead

2003-11-15 Thread Antoine Jacoutot
Selon Aron Håkanson [EMAIL PROTECTED]:
 If you are looking for a fast and temporary solution, just to finish the
 installworld process, you can export the following value to the
 LD_LIBRARY_PATH variable: $LD_LIBRARY_PATH:/lib:/usr/lib

Hey :)
Thanks a lot... I'll try that.

Antoine
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: checking stopevent 2!

2003-11-15 Thread Sven Esbjerg
On Sat, Nov 15, 2003 at 09:38:37AM -0500, Robert Watson wrote:
 On Sat, 15 Nov 2003, Andy Farkas wrote:
  These messages spew onto my console and into syslogd once every second:

I'm seeing the same on a recently upgraded dual cpu machine.

Also when I run the reboot command the errors get mixed on the console as if
the process writing to the console wasn't locking the device.

A verbose dmesg can be found at 
http://xbsd.net/~esbjerg/enzo.verb.dmesg
and a kernel conf
http://xbsd.net/~esbjerg/ENZO


I might add that the recent changes has totally hosed the USB support...

regards
Sven Esbjerg

-- 
http://www.usenet.dk/netikette - på forhånd tak.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: signal 12's everywhere on Current with update this morning.

2003-11-15 Thread Kevin Oberman
 Date: Sat, 15 Nov 2003 09:51:40 +1000 (EST)
 From: Andy Farkas [EMAIL PROTECTED]
 Sender: [EMAIL PROTECTED]
 
 Richard Coleman wrote:
 
0. mergemaster -p
  1. make buildworld
  2. make buildkernel KERNCONF=NAME_OF_KERNEL_FILE
  3. make installkernel KERNCONF=NAME_OF_KERNEL_FILE
2 and 3  may be combined into 'make kernel KERNCONF=NAME_OF_KERNEL_FILE'
  4. shutdown -r now
  5. boot into single user mode
  6. fsck -p
  7. mount -u /
This is redundant. Since V4 days 'mount -a -t ufs' will make root (and
any other devices listed as RW in fstab) RW.
  8. mount -a -t ufs
  9. swapon -a
 
   9.5 adjkerntz -i
 
  10. make installworld
  11. mergemaster
  12. reboot
 
 
 ___
 [EMAIL PROTECTED] mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to [EMAIL PROTECTED]
 
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


[current tinderbox] failure on alpha/alpha

2003-11-15 Thread Tinderbox
TB --- 2003-11-15 17:00:01 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org
TB --- 2003-11-15 17:00:01 - starting CURRENT tinderbox run for alpha/alpha
TB --- 2003-11-15 17:00:01 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-11-15 17:02:29 - building world
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything..
TB --- 2003-11-15 18:06:50 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
 Kernel build for GENERIC started on Sat Nov 15 18:06:50 GMT 2003
[...]
=== osf1
cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee  -D_KERNEL -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline 
-Wcast-qual  -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I-   -include 
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC/opt_global.h
 -I. -I@ -I@/../include -finline-limit=15000 -fno-common -g -mno-fp-regs -ffixed-8 
-Wa,-mev6 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99 -c 
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/osf1/osf1_ioctl.c
cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee  -D_KERNEL -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline 
-Wcast-qual  -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I-   -include 
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC/opt_global.h
 -I. -I@ -I@/../include -finline-limit=15000 -fno-common -g -mno-fp-regs -ffixed-8 
-Wa,-mev6 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99 -c 
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/osf1/osf1_misc.c
cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee  -D_KERNEL -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline 
-Wcast-qual  -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I-   -include 
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC/opt_global.h
 -I. -I@ -I@/../include -finline-limit=15000 -fno-common -g -mno-fp-regs -ffixed-8 
-Wa,-mev6 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99 -c 
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/osf1/osf1_signal.c
cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee  -D_KERNEL -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline 
-Wcast-qual  -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I-   -include 
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC/opt_global.h
 -I. -I@ -I@/../include -finline-limit=15000 -fno-common -g -mno-fp-regs -ffixed-8 
-Wa,-mev6 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99 -c 
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/osf1/osf1_sysent.c
cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee  -D_KERNEL -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline 
-Wcast-qual  -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I-   -include 
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC/opt_global.h
 -I. -I@ -I@/../include -finline-limit=15000 -fno-common -g -mno-fp-regs -ffixed-8 
-Wa,-mev6 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99 -c 
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/osf1/osf1_mount.c
In file included from 
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/osf1/osf1_mount.c:62:
@/nfsclient/nfsmount.h:55: error: field `nm_rpcclnt' has incomplete type
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/modules/osf1.
*** Error code 1

Stop in 

panic: Assertion td-td_turnstile != NULL failed

2003-11-15 Thread Stefan Farfeleder
Hi,

this panic just happened on an i386 SMP box that was idle except for
generating tons of checking stopevent 2 with the following
non-sleepable locks held messages.  Its sources are are just a few
hours old.

%%
checking stopevent 2 with the following non-sleepable locks held:   
exclusive sleep mutex sigacts r = 0 (0xc6b6caa8) locked @ 
/freebsd/frog/src/sys/kern/subr_trap.c:260
panic: Assertion td-td_turnstile != NULL failed at 
/freebsd/frog/src/sys/kern/subr_turnstile.c:437
cpuid = 0;  
Debugger(panic)   
Stopped at  Debugger+0x4e:  xchgl   %ebx,in_Debugger.0  
db t   
Debugger(c070b63e,0,c070ab4a,e041ca58,100) at Debugger+0x4e
panic(c070ab4a,c070e631,c070e401,1b5,c0793a40) at panic+0x148
turnstile_wait(c6938240,c078f4a0,c68bc140,1cc,c078f4a0) at turnstile_wait+0x29c
_mtx_lock_sleep(c078f4a0,0,c0723748,df,c29a8b04) at _mtx_lock_sleep+0x111
_mtx_lock_flags(c078f4a0,0,c0723748,df,bf80) at _mtx_lock_flags+0x98
vm_fault(c078be80,0,2,8,c29a9780) at vm_fault+0x5a
trap_pfault(e041cc2c,0,0,e041cc1c,0) at trap_pfault+0xf6
trap(18,10,10,0,e041cca8) at trap+0x2f3
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0xc06babb3, esp = 0xe041cc6c, ebp = 0xe041cc90 ---
intr_execute_handlers(c07782a4,e041cca8,e041ccec,c06ccc4e,7) at 
intr_execute_handlers+0x23
atpic_handle_intr(7) at atpic_handle_intr+0x41
Xatpic_intr7() at Xatpic_intr7+0x1e
--- interrupt, eip = 0xc06befe5, esp = 0xe041ccec, ebp = 0xe041ccec ---
cpu_idle_default(e041cd14,c0528bcc,c078f4a0,2,c07092f6) at cpu_idle_default+0x5
cpu_idle(c078f4a0,2,c07092f6,53,c0528b90) at cpu_idle+0x28
idle_proc(0,e041cd48,c070919e,311,0) at idle_proc+0x3c
fork_exit(c0528b90,0,e041cd48) at fork_exit+0xb4
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xe041cd7c, ebp = 0 ---
db call doadump
Dumping 1023 MB
 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 
384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704 
720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008
Dump complete
0xf
db r
cpu_reset called on cpu#0
%%

GDB tells this:

%%
GNU gdb 5.2.1 (FreeBSD)
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: Assertion td-td_turnstile != NULL failed at 
/freebsd/frog/src/sys/kern/subr_turnstile.c:437
panic messages:
---
panic: Assertion td-td_turnstile != NULL failed at 
/freebsd/frog/src/sys/kern/subr_turnstile.c:437
cpuid = 0; 
Dumping 1023 MB
 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 
384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704 
720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008
---
#0  doadump () at /freebsd/frog/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0  doadump () at /freebsd/frog/src/sys/kern/kern_shutdown.c:240
#1  0xc046ea8d in db_fncall (dummy1=1016, dummy2=0, dummy3=331, 
dummy4=0xe041c894 ) at /freebsd/frog/src/sys/ddb/db_command.c:548
#2  0xc046e82a in db_command (last_cmdp=0xc077c140, cmd_table=0x0, 
aux_cmd_tablep=0xc072fe2c, aux_cmd_tablep_end=0xc072fe30)
at /freebsd/frog/src/sys/ddb/db_command.c:346
#3  0xc046e938 in db_command_loop ()
at /freebsd/frog/src/sys/ddb/db_command.c:472
#4  0xc0471679 in db_trap (type=3, code=0)
at /freebsd/frog/src/sys/ddb/db_trap.c:73
#5  0xc06b5343 in kdb_trap (type=3, code=0, regs=0xe041c9d4)
at /freebsd/frog/src/sys/i386/i386/db_interface.c:171
#6  0xc06c9eae in trap (frame=
  {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1066357942, tf_esi = 1, tf_ebp = 
-532559328, tf_isp = -532559360, tf_ebx = 0, tf_edx = 0, tf_ecx = 1, tf_eax = 18, 
tf_trapno = 3, tf_err = 0, tf_eip = -1066707410, tf_cs = 8, tf_eflags = 134, tf_esp = 
-1066237866, tf_ss = -1066355138})
at /freebsd/frog/src/sys/i386/i386/trap.c:580
#7  0xc06b6c48 in calltrap () at {standard input}:94
#8  0xc053cd18 in panic (fmt=0xc070ab4a Assertion %s failed at %s:%d)
at /freebsd/frog/src/sys/kern/kern_shutdown.c:534
#9  0xc0561a6c in turnstile_wait (ts=0xc6938240, lock=0xc078f4a0, 
owner=0xc68bc140) at /freebsd/frog/src/sys/kern/subr_turnstile.c:469
---Type return to continue, or q return to quit---
#10 0xc05338a1 in _mtx_lock_sleep (m=0xc078f4a0, opts=0, 
file=0xc0723748 /freebsd/frog/src/sys/vm/vm_fault.c, line=223)
at /freebsd/frog/src/sys/kern/kern_mutex.c:476
#11 0xc0533458 in _mtx_lock_flags (m=0xc078f4a0, 

DIAGNOSTIC LOR in softclock

2003-11-15 Thread Poul-Henning Kamp

This looks slightly different if I use SCHED_ULE, but the effect is
the same.

Off the top of my head, I have not been able to find any places
where softclock would call schedcpu directly.

Suspect locking foobar.

Suggest more people us DIAGNOSTIC

Poul-Henning


ata2-slave: FAILURE - SETFEATURES status=51READY,DSC,ERROR error=4ABORTED
acd0: CDROM 665A at ata2-slave BIOSPIO
acd1: CDROM SAMSUNG SC-148P at ata3-master PIO4
lock order reversal
 1st 0xc072dca0 callout_dont_sleep (callout_dont_sleep) @ kern/kern_timeout.c:223
 2nd 0xc072d080 allproc (allproc) @ kern/sched_4bsd.c:257
Stack backtrace:
backtrace(c06d148d,c072d080,c06cd881,c06cd881,c06cf38b) at backtrace+0x17
witness_lock(c072d080,0,c06cf38b,101,c5061c3c) at witness_lock+0x672
_sx_slock(c072d080,c06cf382,101,8,c06cf0a0) at _sx_slock+0xae
schedcpu(0,0,c06cf097,df,c1183140) at schedcpu+0x3f
softclock(0,0,c06cbce6,23a,c1189388) at softclock+0x1fb
ithread_loop(c1180400,c5061d48,c06cbb54,311,558b0424) at ithread_loop+0x192
fork_exit(c050b090,c1180400,c5061d48) at fork_exit+0xb5
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xc5061d7c, ebp = 0 ---


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: NFSv4 Client code committed.

2003-11-15 Thread Andrzej Tobola

On Fri, Nov 14, 2003 at 05:32:31PM -0800, Alfred Perlstein wrote:
 The Citi project over at the University of Michegan has been nice
 enough to provide us with an initial implementation of a NFSv4
 client.  We still need locking, delegations and cypto.
 
 If anyone who's crypto friendly wants to help with the integration
 that would be really useful.  Please email me.
 
 NFSv4 shares some code with nfs2 and nfs3, and required some minor
 modifications of the v2 and v3 sources so let me know if you
 experience breakage.
 
 Have a great weekend!

Just cvsuped.

kldload nfsclient is now not working:
 link_elf: symbol nfs4_writebp undefined

Did you tested it with nfsclient dynamically loaded ?

-a
PS
dmesg -a

Starting devd.
link_elf: symbol nfs4_writebp undefined
kldload:
can't load nfsclient
:
No such file or directory
/etc/rc: WARNING: nfs mount  requested, but no nfs client in kernel return 1
Mounting NFS file systems:
link_elf: symbol nfs4_writebp undefined
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


AW: AW: 5.1. does not boot afte installation

2003-11-15 Thread Hutterer Robert
Yes I tried. 
Still No reboot

-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag
von Lowell Gilbert
Gesendet: Samstag, 15. November 2003 18:49
An: Hutterer Robert
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Betreff: Re: AW: 5.1. does not boot afte installation


I'm moving this to -CURRENT, as 5.x is *not* the stable branch. Also, please
don't top-post.

Hutterer Robert [EMAIL PROTECTED] writes:

 Disabling ACPI in BIOS has no effect. Still no reboot Disabling in the 
 /boot/loader.conf also. No reboot Disabling in BIOS and loader.conf. 
 No reboot

Did you try all of the suggestions in the release errata?

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dc still reporting collisions

2003-11-15 Thread Dan Nelson
In the last episode (Nov 15), Andy Farkas said:
 The dc(4) driver is still reporting collisions on 100 Mbit full-duplex
 links:
  ifconfig -a
 dc0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
 inet 172.22.2.12 netmask 0xfff0 broadcast 172.22.2.15
 ether 00:00:e8:89:b9:66
 media: Ethernet autoselect (100baseTX full-duplex)
 status: active
 
  netstat -i
 NameMtu Network   Address  Ipkts IerrsOpkts Oerrs  Coll
 dc01500 Link#1  00:00:e8:89:b9:6626463 026737 13253 225301
 dc01500 172.22.2/28   team226044 -26636 - -
 lo0   16384 Link#2  73 0   73 0 0
 lo0   16384 your-net  localhost   73 -   73 - -

Are you sure your kernel, /usr/include/sys, and netstat are all
up-to-date?

-- 
Dan Nelson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


kern/59233: patch to soundcard.h to include an ioctl and a constant for midi

2003-11-15 Thread Mathew Kanner
Hello All,
I'm sorry to be a pain, but I think it's important this PR be
commited before any branch.  
http://www.freebsd.org/cgi/query-pr.cgi?pr=59233
It's vital to build current midi software and it has been in
other OSes for a while.

Thanks,

--Mat
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


cdrom mounting problems

2003-11-15 Thread oleg dashevskii
Hello.

If I boot my box with a cd disc already inserted, it mounts ok. But if
I eject the tray on a booted system, insert a disc and then try to mount it, 
there occurs a system panic.

% uname -a
FreeBSD becho.home 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Mon Nov 10
20:39:27 NOVT 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/BECHO
i386

--
be9
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: NFSv4 Client code committed.

2003-11-15 Thread Lars Eggert
Andrzej Tobola wrote:
Just cvsuped.

kldload nfsclient is now not working:
 link_elf: symbol nfs4_writebp undefined
Did you tested it with nfsclient dynamically loaded ?
Same here. Is there a way to fall back to the old code?

Lars
--
Lars Eggert [EMAIL PROTECTED]   USC Information Sciences Institute


smime.p7s
Description: S/MIME Cryptographic Signature


Re: cdrom mounting problems

2003-11-15 Thread oleg dashevskii
Damn, I've forgotten to include `dmesg` output. Attached.

--
be9
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.1-CURRENT #0: Mon Nov 10 20:39:27 NOVT 2003
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/BECHO
Preloaded elf kernel /boot/kernel/kernel at 0xc07f5000.
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: AMD Athlon(tm) processor (1003.40-MHz 686-class CPU)
  Origin = AuthenticAMD  Id = 0x642  Stepping = 2
  
Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR
  AMD Features=0xc044RSVD,AMIE,DSP,3DNow!
real memory  = 402587648 (383 MB)
avail memory = 385548288 (367 MB)
Pentium Pro MTRR support enabled
acpi0: VIA694 AWRDACPI on motherboard
pcibios: BIOS version 2.10
Using $PIR table, 7 entries at 0xc00fdca0
acpi0: Power Button (fixed)
Timecounter ACPI-fast frequency 3579545 Hz quality 1000
acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0
acpi_cpu0: CPU on acpi0
acpi_tz0: Thermal Zone port 0x530-0x537 on acpi0
acpi_button0: Power Button on acpi0
acpi_button1: Sleep Button on acpi0
pcib0: ACPI Host-PCI bridge port 
0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pcib0: slot 9 INTA is routed to irq 12
pcib0: slot 10 INTA is routed to irq 5
pcib0: slot 11 INTA is routed to irq 11
pcib0: slot 17 INTD is routed to irq 11
pcib0: slot 17 INTD is routed to irq 11
pcib0: slot 17 INTD is routed to irq 11
pcib0: slot 17 INTC is routed to irq 5
agp0: VIA Generic host to PCI bridge mem 0xd000-0xd7ff at device 0.0 on pci0
pcib1: PCI-PCI bridge at device 1.0 on pci0
pci1: PCI bus on pcib1
pcib0: slot 1 INTA is routed to irq 10
pcib1: slot 0 INTA is routed to irq 10
pci1: display, VGA at device 0.0 (no driver attached)
sio0: 3COM PCI FaxModem port 0xa000-0xa007 irq 12 at device 9.0 on pci0
sio0: moving to sio4
sio4: type 16550A
xl0: 3Com 3c905B-TX Fast Etherlink XL port 0xa400-0xa47f mem 0xe300-0xe37f 
irq 5 at device 10.0 on pci0
xl0: Ethernet address: 00:a0:24:53:63:96
miibus0: MII bus on xl0
xlphy0: 3Com internal media interface on miibus0
xlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
xl1: 3Com 3c905B-TX Fast Etherlink XL port 0xa800-0xa87f mem 0xe3001000-0xe300107f 
irq 11 at device 11.0 on pci0
xl1: Ethernet address: 00:a0:24:53:f4:fd
miibus1: MII bus on xl1
xlphy1: 3Com internal media interface on miibus1
xlphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
isab0: PCI-ISA bridge at device 17.0 on pci0
isa0: ISA bus on isab0
atapci0: VIA 8233 UDMA100 controller port 0xac00-0xac0f at device 17.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata0: [MPSAFE]
ata1: at 0x170 irq 15 on atapci0
ata1: [MPSAFE]
uhci0: VIA 83C572 USB controller port 0xb000-0xb01f irq 11 at device 17.2 on pci0
usb0: VIA 83C572 USB controller on uhci0
usb0: USB revision 1.0
uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
ums0: Logitech USB Mouse, rev 1.10/6.20, addr 2, iclass 3/1
ums0: 3 buttons and Z dir.
uhci1: VIA 83C572 USB controller port 0xb400-0xb41f irq 11 at device 17.3 on pci0
usb1: VIA 83C572 USB controller on uhci1
usb1: USB revision 1.0
uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhub1: port error, restarting port 1
uhub1: port error, giving up port 1
uhci2: VIA 83C572 USB controller port 0xb800-0xb81f irq 11 at device 17.4 on pci0
usb2: VIA 83C572 USB controller on uhci2
usb2: USB revision 1.0
uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
pcm0: VIA VT8233 (pre) port 0xbc00-0xbcff irq 5 at device 17.5 on pci0
pcm0: Avance Logic ALC200 AC97 Codec
fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f2-0x3f5 
irq 6 drq 2 on acpi0
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1440-KB 3.5 drive on fdc0 drive 0
sio0 port 0x3f8-0x3ff irq 4 on acpi0
sio0: type 16550A
sio1 port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
ppc0 port 0x778-0x77b,0x378-0x37f irq 7 on acpi0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
ppbus0: Parallel port bus on ppc0
plip0: PLIP network interface on ppbus0
lpt0: Printer on ppbus0
lpt0: Interrupt-driven port
ppi0: Parallel I/O on ppbus0
atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0
atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
npx0: [FAST]
npx0: math processor on motherboard
npx0: INT 16 interface
orm0: Option ROM at iomem 0xc-0xcbfff on isa0
pmtimer0 on isa0
sc0: System console at flags 0x100 on isa0
sc0: VGA 16 virtual consoles, flags=0x300
vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0
Timecounter TSC frequency 1003399454 Hz quality 800
Timecounters tick every 10.000 msec
ipfw2 initialized, divert enabled, rule-based forwarding enabled, 

Re: checking stopevent 2!

2003-11-15 Thread Robert Watson
On Sat, 15 Nov 2003, Sven Esbjerg wrote:

 On Sat, Nov 15, 2003 at 09:38:37AM -0500, Robert Watson wrote:
  On Sat, 15 Nov 2003, Andy Farkas wrote:
   These messages spew onto my console and into syslogd once every second:
 
 I'm seeing the same on a recently upgraded dual cpu machine. 
 
 Also when I run the reboot command the errors get mixed on the console
 as if the process writing to the console wasn't locking the device. 
 
 A verbose dmesg can be found at 
 http://xbsd.net/~esbjerg/enzo.verb.dmesg
 and a kernel conf
 http://xbsd.net/~esbjerg/ENZO
 
 I might add that the recent changes has totally hosed the USB support... 

Could you be more specific about the USB problems?

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: exclusive sleep mutex

2003-11-15 Thread Eric Brunner-Williams in Portland Maine
This morning's cvsup.

checking stopevent 2 with the following non-sleepable locks held:
exclusive sleep mutex sigacts r = 0 (0xc6b8baa8) locked @ 
/space1s1/freebsd/FreeBSD/branches/-current/src/sys/kern/subr_trap.c:260

Eric
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


ifconfig bug

2003-11-15 Thread Lars Eggert
Hi,

shouldn't this work?

# ifconfig em0 inet 128.9.168.58 netmask 255.255.240.0 \
ether 00:07:e9:0a:26:52
ifconfig: ether: bad value
This is with today's -current, but this may have been around longer - I 
hadn't tried it before today. Using two commands to set MAC and IP 
addresses works fine, but it needs to be one command for rc.conf.

Thanks,
Lars
--
Lars Eggert [EMAIL PROTECTED]   USC Information Sciences Institute


smime.p7s
Description: S/MIME Cryptographic Signature


Re: checking stopevent 2!

2003-11-15 Thread Don Lewis
On 15 Nov, Robert Watson wrote:
 
 On Sat, 15 Nov 2003, Andy Farkas wrote:
 
 These messages spew onto my console and into syslogd once every second:
 
 Heh.  Sounds like your box is having a really bad day, we'll see if we
 can't get it fixed up over the next couple of weeks as things settle out
 :-).

Mine is worse.  If I try to boot it multiuser, it pegs its serial
console with these messages.  It seems to bring up the network to the
point where it can be pinged, but the ping latency averages about
200 ms, and even after a half an hour it still hadn't gotten sshd
started.

I can't drop back to the old kernel because I just did an installworld
with the new version of statfs.

I hope the fix isn't too extensive, since I'll probably be typing it in
by hand in single user mode ...
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: NFSv4 Client code committed.

2003-11-15 Thread M. Warner Losh
In message: [EMAIL PROTECTED]
Andrzej Tobola [EMAIL PROTECTED] writes:
: Did you tested it with nfsclient dynamically loaded ?

I can't load nfs4client.ko either.  If you put all the files/paths in
nfsclient, it will load and work.

I load nfsclient.ko in my boot loader, so I couldn't boot at all due
to the unresolved symbols. :-(

Warner

P.S.  Here's what I have in p4 to make it work.

.PATH: ${.CURDIR}/../../nfsclient ${.CURDIR}/../../nfs4client \
${.CURDIR}/../../nfs ${.CURDIR}/../../rpc

KMOD=   nfsclient
SRCS=   vnode_if.h \
nfs_bio.c nfs_lock.c nfs_node.c nfs_socket.c nfs_subs.c nfs_nfsiod.c \
nfs_vfsops.c nfs_vnops.c nfs_common.c \
opt_inet.h opt_nfs.h opt_bootp.h opt_nfsroot.h
SRCS+=  nfs4_dev.c nfs4_idmap.c nfs4_socket.c nfs4_subs.c \
nfs4_vfs_subs.c  nfs4_vfsops.c nfs4_vn_subs.c nfs4_vnops.c
SRCS+=  opt_inet6.h

NFS_INET?=  1   # 0/1 - requires INET to be configured in kernel
NFS_INET6?= 1   # 0/1 - requires INET6 to be configured in kernel

# USE THE RPCCLNT:
CFLAGS+= -DRPCCLNT_DEBUG
SRCS+= rpcclnt.c

# USE THE NEW IDMAPPER
CFLAGS+= -DUSE_NEW_IDMAPPER

opt_inet.h:
touch ${.TARGET}
.if ${NFS_INET}  0
echo #define INET 1  ${.TARGET}
.endif

.if ${NFS_INET6}  0
opt_inet6.h:
echo #define INET6 1  ${.TARGET}
.endif

.include bsd.kmod.mk

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: checking stopevent 2!

2003-11-15 Thread M. Warner Losh
In message: [EMAIL PROTECTED]
Don Lewis [EMAIL PROTECTED] writes:
: I hope the fix isn't too extensive, since I'll probably be typing it in
: by hand in single user mode ...

You could do what I did: remove the two lines that jhb added.  You'll
get no more warnings.  Sure, the problems are still there, but jhb
likely will fix them, at which time you'll be able to run stock proc.h
again.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: ifconfig bug

2003-11-15 Thread Stefan Farfeleder
On Sat, Nov 15, 2003 at 11:54:20AM -0800, Lars Eggert wrote:

 shouldn't this work?
 
 # ifconfig em0 inet 128.9.168.58 netmask 255.255.240.0 \
   ether 00:07:e9:0a:26:52
 ifconfig: ether: bad value
 
 This is with today's -current, but this may have been around longer - I 
 hadn't tried it before today. Using two commands to set MAC and IP 
 addresses works fine, but it needs to be one command for rc.conf.

ifconfig accepts only one value for the address family per invocation,
you can't mix inet and ether.

Cheers,
Stefan
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: checking stopevent 2!

2003-11-15 Thread Robert Watson

On Sat, 15 Nov 2003, M. Warner Losh wrote:

 In message: [EMAIL PROTECTED]
 Don Lewis [EMAIL PROTECTED] writes:
 : I hope the fix isn't too extensive, since I'll probably be typing it in
 : by hand in single user mode ...
 
 You could do what I did: remove the two lines that jhb added.  You'll
 get no more warnings.  Sure, the problems are still there, but jhb
 likely will fix them, at which time you'll be able to run stock proc.h
 again. 

Maybe we should just go ahead and commit that change until John has a
chance to merge the actual fix?  I talked with him a bit about it on
Friday, but I'm not sure whether he's working on it this weekend, or plans
to address it on Monday.  He may not have realized the problem was quite
so debilitating as the problem apparently turns out to be... 

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: ifconfig bug

2003-11-15 Thread Lars Eggert
Bruce M Simpson wrote:

On Sat, Nov 15, 2003 at 11:54:20AM -0800, Lars Eggert wrote:

shouldn't this work?

# ifconfig em0 inet 128.9.168.58 netmask 255.255.240.0 \
ether 00:07:e9:0a:26:52
ifconfig: ether: bad value
This is with today's -current, but this may have been around longer - I 
hadn't tried it before today. Using two commands to set MAC and IP 
addresses works fine, but it needs to be one command for rc.conf.


This issue is already known about and the behaviour you are seeing is in
accordance with how ifconfig should currently behave.
I suggest patching rc scripts until it can be solved the right way round.
Thanks for the explanations! I'll work around this with a start_if.em0 
script then.

Lars
--
Lars Eggert [EMAIL PROTECTED]   USC Information Sciences Institute


smime.p7s
Description: S/MIME Cryptographic Signature


TWE driver IOCTL's

2003-11-15 Thread Eduard Martinescu
Hello,

I looking to extend the smartmontools support
(/usr/ports/sysutils/smartmontools) to include support for drives behind
a TWE device.

I looked at the source for the TWE driver, and it seems to support what
I neednot sure yet, as the linux version use the ATA Passthru
IOCTL.  At any rate, there does not appear to be any twe.h include files
installed into /usr/include anywhere for my program to be able to pick
the correct definitions.  Is this just an oversight? Or did I miss
something?

Thanks,
Ed

-- 
Eduard Martinescu [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: cvs commit: src/sys/dev/acpica acpi_cpu.c src/share/man/man4 acpi.4 src/sys/conf files src/sys/modules/acpi Makefile

2003-11-15 Thread Nate Lawson
The default value of this driver is to use C1 (HLT), which is equivalent
to previous behavior.  To use lower idle states, set hw.acpi.cpu.cx_lowest
to the index of the desired state.  See sysctl hw.acpi.cpu output to get
an idea of the values.  Here is the result on my IBM T23:

hw.acpi.cpu.cx_supported: C1/0 C2/84 C3/120
hw.acpi.cpu.cx_lowest: 2
hw.acpi.cpu.cx_history: 1996/0 0/0 43011/82

This means I have 3 idle states.  C1 = HLT (at index 0).  The lowest is C3
(index 2).  The cx_history is a summary of long/short sleeps for each
supported state.  The lower idle states use less power but also add more
latency so you will probably see some decrease in IO benchmarks if you
enable them.

Please test this to be sure that it boots ok on your machine, especially
SMP boxes.  Throttling should still work ok also.

Thanks,
Nate

-- Forwarded message --
Date: Sat, 15 Nov 2003 11:26:41 -0800 (PST)

njl 2003/11/15 11:26:06 PST

  FreeBSD src repository

  Modified files:
sys/dev/acpica   acpi_cpu.c
share/man/man4   acpi.4
sys/conf files
sys/modules/acpi Makefile
  Log:
  Implement Cx CPU idle states and updated throttling support.

  * Use the cpu_idle_hook() to do idling for C1-C3.
  * Use both _CST and the FADT to detect Cx states.
  * Use both _PTC and P_CNT for controlling throttling.
  * Add a notify handler to detect changes in _CST and _PSS
  * Call the _INI function for each processor if present.  This will be
done by ACPI-CA in the future.
  * Fix a bug on SMP systems where CPUs will attach multiple times if the
bus is rescan.
  * Document new sysctls for controlling idling.

  Revision  ChangesPath
  1.17  +25 -7 src/share/man/man4/acpi.4
  1.853 +1 -0  src/sys/conf/files
  1.19  +784 -162  src/sys/dev/acpica/acpi_cpu.c
  1.32  +2 -1  src/sys/modules/acpi/Makefile

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dc still reporting collisions

2003-11-15 Thread Ceri Davies
On Fri, Nov 14, 2003 at 11:14:36PM -0800, Jos Backus wrote:
 On Sat, Nov 15, 2003 at 04:52:14PM +1000, Andy Farkas wrote:
  The dc(4) driver is still reporting collisions on 100 Mbit full-duplex
  links:
 [snip]
   netstat -i
  NameMtu Network   Address  Ipkts IerrsOpkts Oerrs  Coll
  dc01500 Link#1  00:00:e8:89:b9:6626463 026737 13253 225301
 
 Fwiw, I'm seeing the same with tx(4):
 
 lizzy:~% ifconfig tx0
 tx0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
 inet 10.0.0.2 netmask 0xff00 broadcast 10.0.0.255
 inet 10.0.0.10 netmask 0x broadcast 10.0.0.10
 ether 00:e0:29:09:e4:1a
 media: Ethernet autoselect (10baseT/UTP)
 status: active
 lizzy:~% netstat -i
 NameMtu Network   Address  Ipkts IerrsOpkts Oerrs  Coll
 tx01500 Link#1  00:e0:29:09:e4:1a   154423 1   118093 0   253
 tx01500 10/24 lizzy   159162 -   122841 - -
 tx01500 10.0.0.10/32  lizzy-proxy 28 -   28 - -
 lo0   16384 Link#25347 0 5347 0 0
 lo0   16384 your-net  localhost  442 -  442 - -
 lizzy:~% 
 
 It's gotten so bad that I can no longer transfer files from a Windows system
 to this FreeBSD system (both are on the same 10BaseT hub). I only rarely used
 to see collisions before, and filetransfers have always worked just fine. Last
 time I know for sure this worked was October 17th.

These probably are actual collisions though.  The OP's point is that collisions
are supposed to be impossible on a full duplex link, whereas in your situation
they aren't.

Ceri
-- 


pgp0.pgp
Description: PGP signature


Re: dc still reporting collisions

2003-11-15 Thread Jos Backus
On Sat, Nov 15, 2003 at 05:23:08PM +1000, Andy Farkas wrote:
 Jos Backus wrote:
 
  Fwiw, I'm seeing the same with tx(4):
 
 Looks like a different problem.
 
Probably. I was commenting on the (relatively) high collision count I'm
seeing. This is a hub (DSL router) with 2 PC's on it. I have never seen this
many collisions happening before. Plus I can no longer transfer files from the
Windows system to the FreeBSD system (even using FTP), something that worked
flawlessly at least until October 17th. So something is broken. You think it
could be hardware?

Thanks,
Jos

  lizzy:~% ifconfig tx0
  tx0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
  inet 10.0.0.2 netmask 0xff00 broadcast 10.0.0.255
  inet 10.0.0.10 netmask 0x broadcast 10.0.0.10
  ether 00:e0:29:09:e4:1a
  media: Ethernet autoselect (10baseT/UTP)
  status: active
  lizzy:~% netstat -i
  NameMtu Network   Address  Ipkts IerrsOpkts Oerrs  Coll
  tx01500 Link#1  00:e0:29:09:e4:1a   154423 1   118093 0   253
  tx01500 10/24 lizzy   159162 -   122841 - -
  tx01500 10.0.0.10/32  lizzy-proxy 28 -   28 - -
  lo0   16384 Link#25347 0 5347 0 0
  lo0   16384 your-net  localhost  442 -  442 - -
  lizzy:~%
 
 The dc(4) driver currently has an almost 1:1 ratio of packets:collisions.
 Your tx0 is quite low.
 
 Seishi Hiragushi [EMAIL PROTECTED] reported this 1.5 months ago:
 
 Message-Id: [EMAIL PROTECTED]
 
 
 --
 
  :{ [EMAIL PROTECTED]
 
 Andy Farkas
 System Administrator
Speednet Communications
  http://www.speednet.com.au/
 
 
 
 
 !DSPAM:3fb5d46c649171139613270!
 
 

-- 
Jos Backus   _/  _/_/_/  Sunnyvale, CA
_/  _/   _/
   _/  _/_/_/
  _/  _/  _/_/
jos at catnook.com_/_/   _/_/_/  require 'std/disclaimer'
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


[current tinderbox] failure on i386/i386

2003-11-15 Thread Tinderbox
TB --- 2003-11-15 19:25:16 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org
TB --- 2003-11-15 19:25:16 - starting CURRENT tinderbox run for i386/i386
TB --- 2003-11-15 19:25:16 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/i386/i386
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-11-15 19:27:13 - building world
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything..
TB --- 2003-11-15 20:25:33 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
 Kernel build for GENERIC started on Sat Nov 15 20:25:33 GMT 2003
 Kernel build for GENERIC completed on Sat Nov 15 20:40:33 GMT 2003
TB --- 2003-11-15 20:40:33 - generating LINT kernel config
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf
TB --- /usr/bin/make -B LINT
TB --- 2003-11-15 20:40:33 - building LINT kernel
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src
TB --- /usr/bin/make buildkernel KERNCONF=LINT
 Kernel build for LINT started on Sat Nov 15 20:40:33 GMT 2003
[...]
cc -O -pipe -mcpu=pentiumpro  -D_KERNEL -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I-   -include 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/LINT/opt_global.h
 -I. -I@ -I@/../include -finline-limit=15000 -fno-common  -mno-align-long-strings 
-mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -c 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/fs/ntfs/ntfs_iconv.c
ld  -d -warn-common -r -d -o ntfs_iconv.kld ntfs_iconv.o
touch 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/LINT/modules/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/modules/ntfs_iconv/export_syms
awk -f 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/modules/ntfs_iconv/../../conf/kmod_syms.awk
 ntfs_iconv.kld  
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/LINT/modules/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/modules/ntfs_iconv/export_syms
 |  xargs -J% objcopy % ntfs_iconv.kld
ld -Bshareable  -d -warn-common -o ntfs_iconv.ko ntfs_iconv.kld
=== nullfs
cc -O -pipe -mcpu=pentiumpro  -D_KERNEL -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I-   -include 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/LINT/opt_global.h
 -I. -I@ -I@/../include -finline-limit=15000 -fno-common  -mno-align-long-strings 
-mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -c 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/fs/nullfs/null_subr.c
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/fs/nullfs/null_subr.c:311:21: 
opt_ddb.h: No such file or directory
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/modules/nullfs.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/modules.
*** Error code 1

Stop in 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/LINT.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src.
TB --- 2003-11-15 20:55:10 - TB --- /usr/bin/make returned exit code  1 
TB --- 2003-11-15 20:55:10 - TB --- ERROR: failed to build lint kernel
TB --- 2003-11-15 20:55:10 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


cardbus no longer working with -CURRENT and ACPI

2003-11-15 Thread Dylan Wylie
List,

Running -CURRENT now gives the following problem on a Compaq Pressario 1600-
XL144 laptop:

[...]
cbb0: TI1211 PCI-CardBus Bridge  at device 10.0 on pci0
cardbus0: CardBus bus on cbb0
pccard0: 16-bit PCCard bus on cbb0
pcib0: _PRS resource entry has unsupported type 0
cbb: Unable to map IRQ...
device_probe_and_attach: cbb0 attache returned 12
[...]

Disabeling ACPI makes it work again.
However, I'm then getting the 'watchdog time-out, reseting card' thing now, so no net 
for 
now.
tried the hw.pci._allow_usupported_io_range=1 option, but doesn't help.

Everything was fine before the 'update'.
Can't go back to previous kernel due to the statfs structure changes.

Any sugestions.

Dylan
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: checking stopevent 2!

2003-11-15 Thread Andy Farkas
Robert Watson wrote:
 On Sat, 15 Nov 2003, Andy Farkas wrote:

  These messages spew onto my console and into syslogd once every second:

 Heh.  Sounds like your box is having a really bad day, we'll see if we
 can't get it fixed up over the next couple of weeks as things settle out
 :-).

As you've probably noticed, this problem is pretty wide-spread. A fix
better get in before 5.2-release please :)

I've managed to stop the message flooding by not running ntpd.

 IT would probably be useful if you could drop to DDB and generate a
 trace for the event.

Do you still want me to do this?  I thought the messages themselves were
supposed to useful:

locked @ /hummer/src-current/src/sys/kern/kern_condvar.c:289
locked @ /hummer/src-current/src/sys/kern/kern_synch.c:293
locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260

# ident /hummer/src-current/src/sys/kern/kern_condvar.c
/hummer/src-current/src/sys/kern/kern_condvar.c:
 $FreeBSD: src/sys/kern/kern_condvar.c,v 1.44 2003/11/09 09:17:24 tanimura Exp $
# ident /hummer/src-current/src/sys/kern/kern_synch.c
/hummer/src-current/src/sys/kern/kern_synch.c:
 $FreeBSD: src/sys/kern/kern_synch.c,v 1.237 2003/10/29 15:23:09 bde Exp $
# ident /hummer/src-current/src/sys/kern/subr_trap.c
/hummer/src-current/src/sys/kern/subr_trap.c:
 $FreeBSD: src/sys/kern/subr_trap.c,v 1.261 2003/09/05 22:15:26 peter Exp $


--

 :{ [EMAIL PROTECTED]

Andy Farkas
System Administrator
   Speednet Communications
 http://www.speednet.com.au/


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: HEADS-UP new statfs structure condidered harmful

2003-11-15 Thread Terry Lambert
Matt Smith wrote:
 Marco Wertejuk wrote:
  Just for a short note: cfsd (ports/security/cfs) should be
  recompiled as well after those statfs changes.
 
 And mail/postfix and devel/gnomevfs2 (ones's i've found so far)
 
 postfix did this every time it received a mail until I recompiled it:
 
 pid 4049 (smtpd), uid 1003: exited on signal 11
 
 And gnomevfs was something I saw in another headsup. There are bound to
 be others, I'm just keeping an eye on my /var/log/messages to see if
 anything else sig 11 or 12's! So far so good though.

Expect to have to recompile the entire fricking world for a change
this fundamental.

Really, what should have appened is that the system call interface
for stat should have been retired as ostat, a new system call
interface introduced, and the libc version number bumped, given a
change this fundamental.

Effectively, this will destroy binary backward compatability for
everything in the world.

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: HEADS-UP new statfs structure condidered harmful

2003-11-15 Thread Matthew Dillon
:Expect to have to recompile the entire fricking world for a change
:this fundamental.
:
:Really, what should have appened is that the system call interface
:for stat should have been retired as ostat, a new system call
:interface introduced, and the libc version number bumped, given a
:change this fundamental.
:
:Effectively, this will destroy binary backward compatability for
:everything in the world.
:
:-- Terry
:___
:[EMAIL PROTECTED] mailing list

I recommend that instead of rolling these sorts of system calls over
and over again (how many versions of stat do we have now?  A lot!),
that instead you make a system call which returns a capability buffer
and then have libc load the capabilities it understands into the
structure.  That way you don't have to worry about forwards and 
backwards kernel compatibility.

This is what I plan to do with DragonFly for *stat(), *statfs*(), 
various sysctls that return structures, and so forth.  Wherever it makes
sense to do it.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Who needs these silly statfs changes...

2003-11-15 Thread Terry Lambert
Peter Edwards wrote:
 On Wed, Nov 12, 2003 at 06:04:00PM -0800, Kris Kennaway wrote:
 ...my sparc machine reports that my i386 nfs server has 15 exabytes of
 free space!

[ ... ]

 The NFS protocols have unsigned fields where statfs has signed
 equivalents: NFS can't represent negative available disk space ( Without
 the knowledge of the underlying filesystem on the server, negative free
 space is a little nonsensical anyway, I suppose)
 
 The attached patch stops the NFS server assigning negative values to
 unsigned fields in the statfs response, and works against my local
 solaris box.  Seem reasonable?

I disagree.

The intent of the negative number from df is to subtract the amount
used from the total amount available, in order to get the amount
remaining.

When this results in a negative number, what it's saying is that
you are using up space from the free reserve.

This is an artifact of implementation on the server, and should
not be second-guessed by the client.

The problem in this case is on the client, not the server, in not
doing the conversion as an unsigned operation.  The place for the
subtraction to occur is in the df program.  In other words, the
statfs-f_bavail should be recalculated locally from the values
of statfs-f_blocks and statfs-f_bfree, not used directly out of
the (unsigned) NFS values... or the values should be converted to
signed values coming out of NFS prior to their sign extension to
the size type.


On a slightly related note, the standards mandated interfaces say
that the values should be fsblkcnt_t, which must be an unsigned
integer type.  This coordinates well with my point of the sign
conversion on legacy interface needing to happen at presentation
time.

Also, if you read the ISO C99 standard, you'll see that on an
ILP32 system, there is no way to legitimately define an integer
type in excess of 32 bits, unless long is larger than 32 bits
(see section 3.6), so defining these things as 64 bits without
compiler changes is wrong anyway.

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


[current tinderbox] failure on i386/pc98

2003-11-15 Thread Tinderbox
TB --- 2003-11-15 20:55:11 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org
TB --- 2003-11-15 20:55:11 - starting CURRENT tinderbox run for i386/pc98
TB --- 2003-11-15 20:55:11 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/i386/pc98
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-11-15 20:57:44 - building world
TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything..
TB --- 2003-11-15 21:56:01 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
 Kernel build for GENERIC started on Sat Nov 15 21:56:01 GMT 2003
 Kernel build for GENERIC completed on Sat Nov 15 22:08:20 GMT 2003
TB --- 2003-11-15 22:08:20 - generating LINT kernel config
TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src/sys/pc98/conf
TB --- /usr/bin/make -B LINT
TB --- 2003-11-15 22:08:20 - building LINT kernel
TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src
TB --- /usr/bin/make buildkernel KERNCONF=LINT
 Kernel build for LINT started on Sat Nov 15 22:08:21 GMT 2003
[...]
cc -O -pipe -mcpu=pentiumpro -DPC98  -D_KERNEL -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline 
-Wcast-qual  -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I-   -include 
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/LINT/opt_global.h
 -I. -I@ -I@/../include -finline-limit=15000 -fno-common  -mno-align-long-strings 
-mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -c 
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/fs/ntfs/ntfs_iconv.c
ld  -d -warn-common -r -d -o ntfs_iconv.kld ntfs_iconv.o
touch 
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/LINT/modules/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/modules/ntfs_iconv/export_syms
awk -f 
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/modules/ntfs_iconv/../../conf/kmod_syms.awk
 ntfs_iconv.kld  
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/LINT/modules/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/modules/ntfs_iconv/export_syms
 |  xargs -J% objcopy % ntfs_iconv.kld
ld -Bshareable  -d -warn-common -o ntfs_iconv.ko ntfs_iconv.kld
=== nullfs
cc -O -pipe -mcpu=pentiumpro -DPC98  -D_KERNEL -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline 
-Wcast-qual  -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I-   -include 
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/LINT/opt_global.h
 -I. -I@ -I@/../include -finline-limit=15000 -fno-common  -mno-align-long-strings 
-mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -c 
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/fs/nullfs/null_subr.c
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/fs/nullfs/null_subr.c:311:21: 
opt_ddb.h: No such file or directory
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/modules/nullfs.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/modules.
*** Error code 1

Stop in 
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/LINT.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src.
TB --- 2003-11-15 22:21:02 - TB --- /usr/bin/make returned exit code  1 
TB --- 2003-11-15 22:21:02 - TB --- ERROR: failed to build lint kernel
TB --- 2003-11-15 22:21:02 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


moused(8) broken

2003-11-15 Thread Francois Tigeot
Hi,

On a system without kernel modules moused fails to start with the
following message :

moused: unable to load USB mouse driver: No such file or directory

The hardware is a Via C3 mini-itx PC with an USB mouse.

The system was compiled today; it worked on the 13th.

Even though the ums driver is compiled in the kernel and /dev/ums0 is
present it seems moused tries to load a kernel module and fails if
this is not possible.

I have verified the problem to be caused by revision 1.61 of
src/usr.sbin/moused/moused.c

-- 
François Tigeot| AFNIC
http://www.nic.fr/ | mailto:[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


cbb cardbus activation failed

2003-11-15 Thread Philippe Charnier
Hello,

I have a Compaq armada 7800 with a noname pccard ethernet adapter
which used to be detected as:

rl0: RealTek 8139 10/100BaseTX port 0x1100-0x11ff mem 0x8800-0x880001ff irq 11 
at device 0.0 on cardbus0
rl0: Ethernet address: 00:10:60:58:60:b8
miibus0: MII bus on rl0
rlphy0: RealTek internal media interface on miibus0
rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
rl0: bpf attached

After revision 1.222 of src/sys/pci/if_rl.c, the card is not detected
anymore and I get:

cardbus0: network, ethernet at device 0.0 (no driver attached)
cbb0: CardBus card activation failed

in place of the above message.

revision 1.222 was

 DRIVER_MODULE(rl, pci, rl_driver, rl_devclass, 0, 0);
-DRIVER_MODULE(rl, cardbus, rl_driver, rl_devclass, 0, 0);
 DRIVER_MODULE(miibus, rl, miibus_driver, miibus_devclass, 0, 0);

Adding the removed line makes the card work again.
 
---- 
Philippe Charnier  [EMAIL PROTECTED],free.fr,FreeBSD.org}

``a PC not running FreeBSD is like a venusian with no tentacles'' 

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


panic: recursed on non-recursive lock (vnode interlock)

2003-11-15 Thread Marcel Moolenaar
Gang,

I don't know if this is a known issue or not, but:

lock order reversal
 1st 0xe0002843d7a0 vnode interlock (vnode interlock) @ 
/q/src/sys/ufs/ufs/ufs_ihash.c:128
 2nd 0xe4685300 ufs ihash (ufs ihash) @ /q/src/sys/ufs/ufs/ufs_ihash.c:124
Stack backtrace:
recursed on non-recursive lock (sleep mutex) vnode interlock @ 
/q/src/sys/ufs/ufs/ufs_ihash.c:128
first acquired @ /q/src/sys/ufs/ufs/ufs_ihash.c:128
panic: recurse
panic
Stopped at  Debugger+0x31:  [M1]nop.m 0x0
db trace
Debugger(0xe453a528, 0xe4245d60, 0x814, 0xa0002037aec8) at 
Debugger+0x30
panic(0xe453eb20, 0xe4551b18, 0x80, 0xe4551b18, 0x80, 
0xe4551b18) at panic+0x210
witness_lock(0xe0002843d7a0, 0x8, 0xe4551b18, 0x80) at witness_lock+0x950
_mtx_lock_flags(0xe0002843d7a0, 0x0, 0xe4551b18, 0x80) at 
_mtx_lock_flags+0x130
ufs_ihashget(0xe4631308, 0x131cb, 0x12, 0xa0002037afd0, 0x10012) at 
ufs_ihashget+0x160
ffs_vget(0xe0f4ec00, 0x131cb, 0x12, 0xa0002037afd0, 0x2000, 
0xe09b9400) at ffs_vget+0x50
ufs_lookup(0xa0002037b010) at ufs_lookup+0x1b40
ufs_vnoperate(0xa0002037b010, 0xe42ee9e0, 0x690) at ufs_vnoperate+0x80
vfs_cache_lookup(0xe000395509d8) at vfs_cache_lookup+0x850
ufs_vnoperate(0xa0002037b030, 0xe42f9540, 0xb1a, 0xe4607d28) at 
ufs_vnoperate+0x80
lookup(0xa0002037b2b0, 0xa0002037b2d8, 0xe000395509d8, 0xe8350c02) 
at lookup+0x970
namei(0xa0002037b2b0, 0xef93ac58, 0xe000395509d8) at namei+0x610
vn_open_cred(0xa0002037b2b0, 0xa0002037b3ec, 0x0, 0xefceac00, 0x4) at 
vn_open_cred+0x4e0
vn_open(0xa0002037b2b0, 0xa0002037b3ec, 0x0, 0x4, 0xe43100f0, 0x591) 
at vn_open+0x50
kern_open(0xedc14000, 0x400d5f48, 0x0, 0xef93ac00, 0x0) at 
kern_open+0x160
open(0xedc14000, 0xa0002037b4e8, 0xe44fdcd0, 0x610) at open+0x40
syscall(0xa0002037b400, 0xe0002997a3d0, 0xe455cf38, 
0xe0002997a308, 0xedc14000, 0xa0002037b4e8, 0x5, 0xe45e66b8) 
at syscall+0x470
epc_syscall() at epc_syscall+0x180
db 

This is on:
FreeBSD pluto1.freebsd.org 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Wed Nov 12 04:49:46 PST 
2003 [EMAIL PROTECTED]:/p/obj/p/src/sys/PLUTO1  ia64

-- 
 Marcel Moolenaar USPA: A-39004  [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Who needs these silly statfs changes...

2003-11-15 Thread peter . edwards

(CC's trimmed, I'm sure I'm boring people at this stage.)
Peter Edwards wrote:
 On Wed, Nov 12, 2003 at 06:04:00PM -0800, Kris Kennaway wrote:
 ...my sparc machine reports that my i386 nfs server has 15 exabytes
of
 free space!

[ ... ]

 The NFS protocols have unsigned fields where statfs has signed
 equivalents: NFS can't represent negative available disk space ( Without
 the knowledge of the underlying filesystem on the server, negative free
 space is a little nonsensical anyway, I suppose)

 The attached patch stops the NFS server assigning negative values to
 unsigned fields in the statfs response, and works against my local
 solaris box.  Seem reasonable?

I disagree.

The intent of the negative number from df is to subtract the amount
used from the total amount available, in order to get the amount
remaining.

I just don't see how you can possibly infer from the NFS spec that
abytes is anything other than an unsigned quantity. I just think
assuming the client will interpret a massive value as probably
negative is a bit of a leap of faith.

This is an artifact of implementation on the server, and should
not be second-guessed by the client.

If the server tells the client that there are 2^64 - 1 bytes
remaining on the server, it's not second guessing anything by
presenting that to the user.


The problem in this case is on the client, not the server, in not
doing the conversion as an unsigned operation.  The place for the
subtraction to occur is in the df program.  In other words, the
statfs-f_bavail should be recalculated locally from the values
of statfs-f_blocks and statfs-f_bfree, not used directly out of
the (unsigned) NFS values... or the values should be converted to
signed values coming out of NFS prior to their sign extension to
the size type.

(Note that NFS also gives a fbytes, indicating the number of free
bytes, as opposed to available to a particular user)

bavail can really only be worked out by the server. The server
is reserving a percentage for non-root user. The client can't work
out what that reserve percentage is.



On a slightly related note, the standards mandated interfaces say
that the values should be fsblkcnt_t, which must be an unsigned
integer type.  This coordinates well with my point of the sign
conversion on legacy interface needing to happen at presentation
time.


Maybe we're talking across each other. That's my main point: the
server shouldn't put huge values in an unsigned field and
expect the client to interpret them in a way that the spec sets
no precedent for.

Also, if you read the ISO C99 standard, you'll see that on an
ILP32 system, there is no way to legitimately define an integer
type in excess of 32 bits, unless long is larger than 32 bits
(see section 3.6), so defining these things as 64 bits without
compiler changes is wrong anyway.

As far as implementing NFS is concerned, that's probably not
relevant: It doesn't have to be implemented in ISO C. The FreeBSD
compiler provides a 64-bit integer type that its implementation
is free to use :-)


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Who needs these silly statfs changes...

2003-11-15 Thread Terry Lambert
Bruce Evans wrote:
 I just got around to testing the patch in that reply:
[ ... ]
 This seems to work.  On a 2TB-epsilon ffs1 file system (*) on an md malloc
 disk (**):

Try it again.  This time, take the remote FS below its free reserve
as the root user, and see what the client machine reports.  Compare
the results to an identical local FS.

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: HEADS-UP new statfs structure

2003-11-15 Thread Terry Lambert
Daniel Eischen wrote:
 On Fri, 14 Nov 2003, Andrew Gallatin wrote:
  Can't we bump the libc version so that dynamically linked, non-system
  binaries can continue to work?   Having things like postfix and gnome
  dumping core seems excessivly bumpy.  Upgrading all ports is a pain.
 
 I don't think that's a good idea.  I've also got changes in
 mind that require a libc version bump, but they aren't ready
 now.  I was saving them for 6.0.  Other folks may also have
 similar changes in mind.  Do we really want to have yet another
 version bump?

No, we want a minor version bump to add a new interface, but
since we got rid of minor version numbers on libraries, this is
no longer possible.  8-).

 For 6.0, can we start off libc at libc.so.MMDD and move it
 back to libc.so.6 for the first release?  That way we can bump
 it whenever we want to avoid the bumpy rides for -current
 folk.

This is a great idea!

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: xscreensaver bug?

2003-11-15 Thread Terry Lambert
Eugene M. Kim wrote:
 Validating a root password is possible with other means in many cases,
 if not always.  OpenSSH sshd is a good example.  Even with
 PermitRootLogin set to no, the attacker can differentiate whether the
 password has been accepted or not.

That's because the software in question sucks, not because it's a
natural property of all such software.


 If attacker is able enough, he could also run a hacked version of Xnest
 on port 6000+N and the real xscreensaver on :N.0 for a suitable N.
 Attacker would feed the real xscreensaver with the captured password and
 see if the real xscreensaver releases the server grab.

Yeah, and any user on the system could put up a trojan that put up
a window that pretended to be the login screen instead of a screen
saverm since that would be much asier, and harvest passwords that
way, instead, after pretending the first login failed.

I don't really see your point... any time you have more than one
user using the same console, it's possible to create a trojan.

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: HEADS-UP new statfs structure

2003-11-15 Thread Terry Lambert
Robert Watson wrote:
 What's going on is the following: while we have a compatibility system
 call in place, it only affects applications linked against non-current
 libc.  As soon as you recompile libc, applications expecting the old
 statfs() ABI get the new statfs(), and depending on where their smaller
 struct statfs is located, may stomp on memory they're using for something
 else (like critical data structures).  This means that any application
 using statfs() and linked against libc.so.5 may start having problems.
 Not only that, but as you begin to compile new programs, they start
 expecting the new statfs() API, so if you keep the old libc, they'll start
 expecting to see extended struct statfs information in a structure that's
 too small.  This is almost certainly a less harmful failure mode than the
 former.  However, it turns out statfs() is used in a fair number of
 applications (and libraries)...

I recently ran into a similar need to break the API without
breaking the ABI.  The easiest way to do this is to add a new
system call, with a different name, and scope the changeover
to compile time.

At some later point, when you bump the libc version, you can
change the name to the new name, and deprecate the old.  For
the statfs case, here's the example:

% nm /usr/lib/libc.a | grep T _statfs
0008 T _statfs
0008 T _statfs_new

% grep statfs /usr/include/sys/mount.h
#define statfs statfs_new
int statfs(const char *, struct statfs *);

Viola!  Recompile, get the new, don't recompile, get the old.

The only place this breaks is sucky programs that define the structure
without including the header file to get the prototype and #define in
scope as well.

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dc still reporting collisions

2003-11-15 Thread Doug White
On Sat, 15 Nov 2003, Jos Backus wrote:

 On Sat, Nov 15, 2003 at 05:23:08PM +1000, Andy Farkas wrote:
  Jos Backus wrote:
 
   Fwiw, I'm seeing the same with tx(4):
 
  Looks like a different problem.

 Probably. I was commenting on the (relatively) high collision count I'm
 seeing. This is a hub (DSL router) with 2 PC's on it. I have never seen this
 many collisions happening before. Plus I can no longer transfer files from the
 Windows system to the FreeBSD system (even using FTP), something that worked
 flawlessly at least until October 17th. So something is broken. You think it
 could be hardware?

If its a real hub, hubs aren't full duplex.

If its a switch, the switch and PC might not have negoatiated full duplex
properly. Try unplug/replug the cable, or switch to autoselect.


 Thanks,
 Jos

   lizzy:~% ifconfig tx0
   tx0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
   inet 10.0.0.2 netmask 0xff00 broadcast 10.0.0.255
   inet 10.0.0.10 netmask 0x broadcast 10.0.0.10
   ether 00:e0:29:09:e4:1a
   media: Ethernet autoselect (10baseT/UTP)
   status: active
   lizzy:~% netstat -i
   NameMtu Network   Address  Ipkts IerrsOpkts Oerrs  Coll
   tx01500 Link#1  00:e0:29:09:e4:1a   154423 1   118093 0   253
   tx01500 10/24 lizzy   159162 -   122841 - -
   tx01500 10.0.0.10/32  lizzy-proxy 28 -   28 - -
   lo0   16384 Link#25347 0 5347 0 0
   lo0   16384 your-net  localhost  442 -  442 - -
   lizzy:~%
 
  The dc(4) driver currently has an almost 1:1 ratio of packets:collisions.
  Your tx0 is quite low.
 
  Seishi Hiragushi [EMAIL PROTECTED] reported this 1.5 months ago:
 
  Message-Id: [EMAIL PROTECTED]
 
 
  --
 
   :{ [EMAIL PROTECTED]
 
  Andy Farkas
  System Administrator
 Speednet Communications
   http://www.speednet.com.au/
 
 
 
 
  !DSPAM:3fb5d46c649171139613270!
 
 



-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: FreeBSD current, apache and php4 woes

2003-11-15 Thread Doug White
On Sat, 15 Nov 2003, [iso-8859-1] Claus Guttesen wrote:

 After a draft to this mail was written I was lucky
 to get some output to the screen (which is the first
 time since we migrated):

 panic: kmem_malloc(4096): kmem_map too small:
 275251200 total allocated cpuid = 0; lapic.id =
 

man tuning

You probably need to reset maxusers to 128 or so manually since the
auto-tuning is doing the wrong thing. Although this is usually a problem
on 4GB systems.

You aren't running any wierd nmbclusters/nmbufs values, are you?

-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: HEADS-UP new statfs structure

2003-11-15 Thread Marcel Moolenaar
On Sat, Nov 15, 2003 at 02:45:57PM -0800, Terry Lambert wrote:
 
  For 6.0, can we start off libc at libc.so.MMDD and move it
  back to libc.so.6 for the first release?  That way we can bump
  it whenever we want to avoid the bumpy rides for -current
  folk.
 
 This is a great idea!

Provided that we
1. keep the major number to allow concurrent development of different
   (major) library versions, and
2. replace the date with a convenient sequence number, which we can
   call the minor version number, and
3. Do not reset the version number when we release.

E.g.: libc.so.6.0, libc.so.6.1, and (first release) libc.so.6.2...

-- 
 Marcel Moolenaar USPA: A-39004  [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: /etc/rc.d/ipsec starts not in time

2003-11-15 Thread Terry Lambert
Hajimu UMEMOTO wrote:
  Kostyuk Oleg [EMAIL PROTECTED] said:
 
 cubProblem is in order of starting /etc/rc.d/ipsec.
 cubIt must start BEFORE any network interaction,
 cubmay be even before configuring interfaces.
 cubBut I not sure in case with diskless mashines.
 
 cub-# BEFORE:  DAEMON
 cub+# BEFORE:  NETWORK
 
 It is not sufficient.  There is setkey(8) in /usr/sbin.  It means that
 we cannot protect NFS exported /usr by IPsec.  If there is no
 objection, I wish to move setkey(8) into /sbin like NetBSD did.

This type of order inversion is common.

Can we simply delay exportation until later in the boot process?
Wouldn't this have the same effect?

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: NFSv4 Client code committed.

2003-11-15 Thread Lars Eggert
M. Warner Losh wrote:

In message: [EMAIL PROTECTED]
Andrzej Tobola [EMAIL PROTECTED] writes:
: Did you tested it with nfsclient dynamically loaded ?
I can't load nfs4client.ko either.  If you put all the files/paths in
nfsclient, it will load and work.
I load nfsclient.ko in my boot loader, so I couldn't boot at all due
to the unresolved symbols. :-(
Warner

P.S.  Here's what I have in p4 to make it work.
FYI, your Makefile fixes things for me, too.

Lars
--
Lars Eggert [EMAIL PROTECTED]   USC Information Sciences Institute


smime.p7s
Description: S/MIME Cryptographic Signature


Re: FreeBSD current, apache and php4 woes

2003-11-15 Thread Claus Guttesen
Hi.

  panic: kmem_malloc(4096): kmem_map too small:
  275251200 total allocated cpuid = 0; lapic.id =
  
 
 man tuning
 
 You probably need to reset maxusers to 128 or so
 manually since the
 auto-tuning is doing the wrong thing. Although this
 is usually a problem
 on 4GB systems.
 

I'll try to adjust it manually.

 You aren't running any wierd nmbclusters/nmbufs
 values, are you?
 

Just a straight install and custom-kernel reg. NIC and
SCSI.

Claus


Yahoo! Mail (http://dk.mail.yahoo.com) - Gratis: 6 MB lagerplads, spamfilter og 
virusscan
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: HEADS-UP new statfs structure condidered harmful

2003-11-15 Thread Terry Lambert
Matthew Dillon wrote:
 I recommend that instead of rolling these sorts of system calls over
 and over again (how many versions of stat do we have now?  A lot!),
 that instead you make a system call which returns a capability buffer
 and then have libc load the capabilities it understands into the
 structure.  That way you don't have to worry about forwards and
 backwards kernel compatibility.
 
 This is what I plan to do with DragonFly for *stat(), *statfs*(),
 various sysctls that return structures, and so forth.  Wherever it makes
 sense to do it.

How do you propose to achieve POSIX compliance?  At the library
level?  Or not at all?

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


[current tinderbox] failure on ia64/ia64

2003-11-15 Thread Tinderbox
TB --- 2003-11-15 22:21:03 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org
TB --- 2003-11-15 22:21:03 - starting CURRENT tinderbox run for ia64/ia64
TB --- 2003-11-15 22:21:03 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-11-15 22:24:06 - building world
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything..
TB --- 2003-11-15 23:29:04 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
 Kernel build for GENERIC started on Sat Nov 15 23:29:04 GMT 2003
 Kernel build for GENERIC completed on Sat Nov 15 23:45:16 GMT 2003
TB --- 2003-11-15 23:45:16 - generating LINT kernel config
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src/sys/ia64/conf
TB --- /usr/bin/make -B LINT
TB --- 2003-11-15 23:45:16 - building LINT kernel
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src
TB --- /usr/bin/make buildkernel KERNCONF=LINT
 Kernel build for LINT started on Sat Nov 15 23:45:16 GMT 2003
[...]
cc -O -pipe   -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99 -DKLD_MODULE -nostdinc -I-   -include 
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/LINT/opt_global.h
 -I. -I@ -I@/../include -finline-limit=15000 -fno-common  -ffixed-r13 
-mfixed-range=f32-f127 -mno-sdata -ffreestanding -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline 
-Wcast-qual  -fformat-extensions -std=c99 -c 
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/fs/ntfs/ntfs_iconv.c
ld  -d -warn-common -r -d -o ntfs_iconv.kld ntfs_iconv.o
touch 
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/LINT/modules/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/modules/ntfs_iconv/export_syms
awk -f 
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/modules/ntfs_iconv/../../conf/kmod_syms.awk
 ntfs_iconv.kld  
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/LINT/modules/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/modules/ntfs_iconv/export_syms
 |  xargs -J% objcopy % ntfs_iconv.kld
ld -Bshareable  -d -warn-common -o ntfs_iconv.ko ntfs_iconv.kld
=== nullfs
cc -O -pipe   -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99 -DKLD_MODULE -nostdinc -I-   -include 
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/LINT/opt_global.h
 -I. -I@ -I@/../include -finline-limit=15000 -fno-common  -ffixed-r13 
-mfixed-range=f32-f127 -mno-sdata -ffreestanding -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline 
-Wcast-qual  -fformat-extensions -std=c99 -c 
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/fs/nullfs/null_subr.c
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/fs/nullfs/null_subr.c:311:21: 
opt_ddb.h: No such file or directory
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/modules/nullfs.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/modules.
*** Error code 1

Stop in 
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/LINT.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src.
TB --- 2003-11-16 00:01:56 - TB --- /usr/bin/make returned exit code  1 
TB --- 2003-11-16 00:01:56 - TB --- ERROR: failed to build lint kernel
TB --- 2003-11-16 00:01:56 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dc still reporting collisions

2003-11-15 Thread Jos Backus
On Sat, Nov 15, 2003 at 03:09:27PM -0800, Doug White wrote:
 On Sat, 15 Nov 2003, Jos Backus wrote:
 
  On Sat, Nov 15, 2003 at 05:23:08PM +1000, Andy Farkas wrote:
   Jos Backus wrote:
  
Fwiw, I'm seeing the same with tx(4):
  
   Looks like a different problem.
 
  Probably. I was commenting on the (relatively) high collision count I'm
  seeing. This is a hub (DSL router) with 2 PC's on it. I have never seen this
  many collisions happening before. Plus I can no longer transfer files from the
  Windows system to the FreeBSD system (even using FTP), something that worked
  flawlessly at least until October 17th. So something is broken. You think it
  could be hardware?
 
 If its a real hub, hubs aren't full duplex.
 
Yeah, I know (believe it or not, but my job description says Network
Engineer :-).

 If its a switch, the switch and PC might not have negoatiated full duplex
 properly. Try unplug/replug the cable, or switch to autoselect.
 
Thanks for the advice, but this setup has been working unchanged for years
now. All that's really changed is FreeBSD on this machine. It could be broken
hardware though. I'm going to try booting 4.9-RELEASE and see if I can get FTP
to work (5.1-RELEASE just hangs during root mount).

Cheers,
Jos

  Thanks,
  Jos
 
lizzy:~% ifconfig tx0
tx0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
inet 10.0.0.2 netmask 0xff00 broadcast 10.0.0.255
inet 10.0.0.10 netmask 0x broadcast 10.0.0.10
ether 00:e0:29:09:e4:1a
media: Ethernet autoselect (10baseT/UTP)
status: active
lizzy:~% netstat -i
NameMtu Network   Address  Ipkts IerrsOpkts Oerrs  Coll
tx01500 Link#1  00:e0:29:09:e4:1a   154423 1   118093 0   253
tx01500 10/24 lizzy   159162 -   122841 - -
tx01500 10.0.0.10/32  lizzy-proxy 28 -   28 - -
lo0   16384 Link#25347 0 5347 0 0
lo0   16384 your-net  localhost  442 -  442 - -
lizzy:~%
  
   The dc(4) driver currently has an almost 1:1 ratio of packets:collisions.
   Your tx0 is quite low.
  
   Seishi Hiragushi [EMAIL PROTECTED] reported this 1.5 months ago:
  
   Message-Id: [EMAIL PROTECTED]
  
  
   --
  
:{ [EMAIL PROTECTED]
  
   Andy Farkas
   System Administrator
  Speednet Communications
http://www.speednet.com.au/
  
  
  
  
   
  
  
 
 
 
 -- 
 Doug White|  FreeBSD: The Power to Serve
 [EMAIL PROTECTED]  |  www.FreeBSD.org
 
 

-- 
Jos Backus   _/  _/_/_/  Sunnyvale, CA
_/  _/   _/
   _/  _/_/_/
  _/  _/  _/_/
jos at catnook.com_/_/   _/_/_/  require 'std/disclaimer'
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Who needs these silly statfs changes...

2003-11-15 Thread Terry Lambert
[EMAIL PROTECTED] wrote:
 I disagree.
 
 The intent of the negative number from df is to subtract the amount
 used from the total amount available, in order to get the amount
 remaining.
 
 I just don't see how you can possibly infer from the NFS spec that
 abytes is anything other than an unsigned quantity. I just think
 assuming the client will interpret a massive value as probably
 negative is a bit of a leap of faith.

I'm not.  I'm saying that the value needs to be zero on the server,
if it's zero.

In reality, the negative value that's being stuffed is wrong; it's
possible to be root over NFS to a server that supports the idea
of a free reserve.  If you represent the free reserve over the wire,
then you have the problem; if you don't represent the free reserve
over the wire, then you don't.

The problem here is that you are taking the reported value for the
available bytes *after* the local free reserve (if any) is taken
into account, and exporting it over the wire.


 This is an artifact of implementation on the server, and should
 not be second-guessed by the client.
 
 If the server tells the client that there are 2^64 - 1 bytes
 remaining on the server, it's not second guessing anything by
 presenting that to the user.

The server can't tell the client that, because that's outside the
range that's representable witin the NFS protocol.  Now if you
were willing to limit yourself to sizeof(abytes), then you have a
valid argument.

 The problem in this case is on the client, not the server, in not
 doing the conversion as an unsigned operation.  The place for the
 subtraction to occur is in the df program.  In other words, the
 statfs-f_bavail should be recalculated locally from the values
 of statfs-f_blocks and statfs-f_bfree, not used directly out of
 the (unsigned) NFS values... or the values should be converted to
 signed values coming out of NFS prior to their sign extension to
 the size type.
 
 (Note that NFS also gives a fbytes, indicating the number of free
 bytes, as opposed to available to a particular user)
 
 bavail can really only be worked out by the server. The server
 is reserving a percentage for non-root user. The client can't work
 out what that reserve percentage is.

Sure, fine, work it out.  And report 0 if the value is negative
on the server after you work it out.

In theory, it's not possible for this value to be less than 0 on
the server, unlss you are doing your calculations wrong, since
you can't assume the credential to be used by the client user, the
state of the -maproot option globally, for all mounts, or that the
client is familiar with the concept of a free reserve.

So the only server problem, if there is one, is that the server
should report the number of unallocated bytes, ignoring the
free reserve.


 On a slightly related note, the standards mandated interfaces say
 that the values should be fsblkcnt_t, which must be an unsigned
 integer type.  This coordinates well with my point of the sign
 conversion on legacy interface needing to happen at presentation
 time.
 
 Maybe we're talking across each other. That's my main point: the
 server shouldn't put huge values in an unsigned field and
 expect the client to interpret them in a way that the spec sets
 no precedent for.

It depends; are these values huge because they're huge, or are
they huge because that's what you get when you convert a negative
signed value to an unsigned value as bits, without clamping negative
values to 0?

I think Bruce Evans' post on type conversion is relevent here.

The largest value you should ever stuff in it is MAX_UINT (or
whatever sized type maps to sizeof(abytes), and the smallest is
0.

If you do that, the value is absolutely correct when going over
the wire, and whether or not remote(MAX_UNIT)  signed local
representation is a problem for the client.


 Also, if you read the ISO C99 standard, you'll see that on an
 ILP32 system, there is no way to legitimately define an integer
 type in excess of 32 bits, unless long is larger than 32 bits
 (see section 3.6), so defining these things as 64 bits without
 compiler changes is wrong anyway.
 
 As far as implementing NFS is concerned, that's probably not
 relevant: It doesn't have to be implemented in ISO C. The FreeBSD
 compiler provides a 64-bit integer type that its implementation
 is free to use :-)

You misunderstand: statfs/fstatfs is not a standard interface.  It
may be time to deprecate it in favor of statvfs/fstatvfs.  If we
did that, the values become unsigned, and we could (maybe) ignore
the problem (everywhere except the traditional reporting of negative
blocks available in df, which could be handled by an unsigned
compare and a %c that got ' ' or '-').

Alternately, we ned to acknowledge that the interface that's being
tried for is outside the scope of standards entirely.  Doing this
is a real pain, though, since idiots will use it to get more
resolution, and it will proagate.

Probably the best thing would be to 

Re: cardbus no longer working with -CURRENT and ACPI

2003-11-15 Thread M. Warner Losh
In message: [EMAIL PROTECTED]
Dylan Wylie [EMAIL PROTECTED] writes:
: List,
: 
: Running -CURRENT now gives the following problem on a Compaq Pressario 1600-
: XL144 laptop:
: 
: [...]
: cbb0: TI1211 PCI-CardBus Bridge  at device 10.0 on pci0
: cardbus0: CardBus bus on cbb0
: pccard0: 16-bit PCCard bus on cbb0
: pcib0: _PRS resource entry has unsupported type 0
: cbb: Unable to map IRQ...
: device_probe_and_attach: cbb0 attache returned 12
: [...]
: 
: Disabeling ACPI makes it work again.
: However, I'm then getting the 'watchdog time-out, reseting card' thing now, so no 
net for 
: now.
: tried the hw.pci._allow_usupported_io_range=1 option, but doesn't help.
: 
: Everything was fine before the 'update'.
: Can't go back to previous kernel due to the statfs structure changes.

When was the previous kernel?

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: HEADS-UP new statfs structure condidered harmful

2003-11-15 Thread Matthew Dillon

: sense to do it.
:
:How do you propose to achieve POSIX compliance?  At the library
:level?  Or not at all?
:
:-- Terry

I don't understand the question.  All that happens is that functions like
fstat() and statfs() become libc functions rather then direct syscalls.
The userland program doesn't know the difference, it uses fstat() and 
statfs() just like it always has.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: named pipes memory leak?

2003-11-15 Thread Don Lewis
On 11 Nov, Lukas Ertl wrote:
 On Tue, 11 Nov 2003, Lukas Ertl wrote:
 
 Unfortunately, we are still seeing a problem here: we are running uvscan
 (virus scanner), and while running it we are still seeing increasing unpcb
 usage and orphaned unix domain sockets.

 We added some debug printfs to the fifo routines and found out that
 fifo_cleanup is called from fifo_close with a vnode which has v_usecount
 == 2 so the socket close calls aren't reached.
 
 Sorry, I probably missed an important part: we're creating the FIFOs on
 nullfs mounts - the test script works great on plain UFS mounts, but the
 null layer seems to VREF the vnode once again, so v_usecount is 2, thus it
 is missong the check in fifo_cleanup().

I just committed a fix for this.  Fifo_vnops.c 1.91 should not leak
memory and sockets when used with nullfs.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


[current tinderbox] failure on sparc64/sparc64

2003-11-15 Thread Tinderbox
TB --- 2003-11-16 00:01:57 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org
TB --- 2003-11-16 00:01:57 - starting CURRENT tinderbox run for sparc64/sparc64
TB --- 2003-11-16 00:01:57 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-11-16 00:04:11 - building world
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything..
TB --- 2003-11-16 00:59:07 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
 Kernel build for GENERIC started on Sun Nov 16 00:59:08 GMT 2003
 Kernel build for GENERIC completed on Sun Nov 16 01:08:30 GMT 2003
TB --- 2003-11-16 01:08:30 - generating LINT kernel config
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf
TB --- /usr/bin/make -B LINT
TB --- 2003-11-16 01:08:30 - building LINT kernel
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src
TB --- /usr/bin/make buildkernel KERNCONF=LINT
 Kernel build for LINT started on Sun Nov 16 01:08:30 GMT 2003
[...]
cc -O -pipe   -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99 -DKLD_MODULE -nostdinc -I-   -include 
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT/opt_global.h
 -I. -I@ -I@/../include -finline-limit=15000 -fno-common  -mcmodel=medlow -msoft-float 
-ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99 -c 
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/fs/ntfs/ntfs_iconv.c
ld  -d -warn-common -r -d -o ntfs_iconv.kld ntfs_iconv.o
touch 
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT/modules/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/ntfs_iconv/export_syms
awk -f 
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/ntfs_iconv/../../conf/kmod_syms.awk
 ntfs_iconv.kld  
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT/modules/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/ntfs_iconv/export_syms
 |  xargs -J% objcopy % ntfs_iconv.kld
ld -Bshareable  -d -warn-common -o ntfs_iconv.ko ntfs_iconv.kld
=== nullfs
cc -O -pipe   -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99 -DKLD_MODULE -nostdinc -I-   -include 
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT/opt_global.h
 -I. -I@ -I@/../include -finline-limit=15000 -fno-common  -mcmodel=medlow -msoft-float 
-ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99 -c 
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/fs/nullfs/null_subr.c
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/fs/nullfs/null_subr.c:311:21:
 opt_ddb.h: No such file or directory
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/nullfs.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/modules.
*** Error code 1

Stop in 
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src.
TB --- 2003-11-16 01:19:51 - TB --- /usr/bin/make returned exit code  1 
TB --- 2003-11-16 01:19:51 - TB --- ERROR: failed to build lint kernel
TB --- 2003-11-16 01:19:51 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Who needs these silly statfs changes...

2003-11-15 Thread Bruce Evans
On Sat, 15 Nov 2003, Terry Lambert wrote:

 Bruce Evans wrote:
  I just got around to testing the patch in that reply:
 [ ... ]
  This seems to work.  On a 2TB-epsilon ffs1 file system (*) on an md malloc
  disk (**):

 Try it again.  This time, take the remote FS below its free reserve
 as the root user, and see what the client machine reports.  Compare
 the results to an identical local FS.

Er, that is the main thing that the test did.

Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Who needs these silly statfs changes...

2003-11-15 Thread Bruce Evans
On Fri, 14 Nov 2003 [EMAIL PROTECTED] wrote:

  Bruce Evans wrote:
   ...
   I just got around to testing the patch in that reply:
   ...
 
  Your patch to nfs_vfsops won't apply to my Solaris kernel :-)
  The protocol says abytes is unsigned, so the server shouldn't be lying
  by sending a huge positive value for available space on a full
  filesystem. No?
 
 Possibly not, but the protocol is broken if it actually requires that.

 What makes you say that? I would think the utility of negative counts
 for disk sizes and available spaces is marginal. Solaris, POSIX, and
 NFS seem to get on fine without it. What am I (and they) missing?

Well, the f_bavail field (not to mention all the other fields (until
recently, sigh)) has always been signed and does go negative in BSD's
statfs, so the protocol is broken if it can't support negative values
in it.

 The type pun to negative values is in most versions of BSD:
  [snip code snippets and bug]

 That's great for interacting with other BSDs, but it still abusing
 the protocol. As filesystems with approaching 2^64 bytes become possible
 it probably has more of an impact.

2^63 won't be needed any time soon.  This problem was more serious with
nfsv2 when file systems reached 2^31 bytes not so long ago.

The current problem is actually more with non-BSD clients and a BSD server.
The BSD server will send the negative values and the non-BSD client may
convert them to huge positive ones.  Non-BSD servers presumably won't send
negative values.

Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: DIAGNOSTIC LOR in softclock

2003-11-15 Thread Bruce Evans
On Sat, 15 Nov 2003, Poul-Henning Kamp wrote:

 This looks slightly different if I use SCHED_ULE, but the effect is
 the same.

 Off the top of my head, I have not been able to find any places
 where softclock would call schedcpu directly.

schedcpu() is a timeout routine, so it is always called indirectly from
softclock.

 lock order reversal
  1st 0xc072dca0 callout_dont_sleep (callout_dont_sleep) @ kern/kern_timeout.c:223
  2nd 0xc072d080 allproc (allproc) @ kern/sched_4bsd.c:257
 Stack backtrace:
 backtrace(c06d148d,c072d080,c06cd881,c06cd881,c06cf38b) at backtrace+0x17
 witness_lock(c072d080,0,c06cf38b,101,c5061c3c) at witness_lock+0x672
 _sx_slock(c072d080,c06cf382,101,8,c06cf0a0) at _sx_slock+0xae
 schedcpu(0,0,c06cf097,df,c1183140) at schedcpu+0x3f
 softclock(0,0,c06cbce6,23a,c1189388) at softclock+0x1fb
 ithread_loop(c1180400,c5061d48,c06cbb54,311,558b0424) at ithread_loop+0x192
 fork_exit(c050b090,c1180400,c5061d48) at fork_exit+0xb5
 fork_trampoline() at fork_trampoline+0x8
 --- trap 0x1, eip = 0, esp = 0xc5061d7c, ebp = 0 ---

I'm sure this is known.  schedcpu() always calls sx_lock(allproc_lock),
so the above always occurs if sx_lock() happens to block.

Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: HEADS-UP new statfs structure

2003-11-15 Thread David O'Brien
On Sat, Nov 15, 2003 at 03:16:03PM -0800, Marcel Moolenaar wrote:
 Provided that we
 2. replace the date with a convenient sequence number, which we can
call the minor version number, and
.. 
 E.g.: libc.so.6.0, libc.so.6.1, and (first release) libc.so.6.2...

Please no -- it wouldn't be easy to see a.out libs from ELF ones.
(yes I still have some a.out binaries)
 
-- 
-- David  ([EMAIL PROTECTED])
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dc still reporting collisions

2003-11-15 Thread Peter Jeremy
On Sat, Nov 15, 2003 at 08:27:44PM +, Ceri Davies wrote: These
probably are actual collisions though.  The OP's point is that
collisions are supposed to be impossible on a full duplex link,
whereas in your situation they aren't.

The collision mechanism is used for flow control on full-duplex links.
A very high collision rate would normally indicate a half/full duplex
mismatch.  A low collision rate would normally indicate that the switch
can't handle the load and is throttling back your system.  (Other options
are broken NICs and/or cables).

Peter
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: ifconfig bug

2003-11-15 Thread Bruce M Simpson
On Sat, Nov 15, 2003 at 11:54:20AM -0800, Lars Eggert wrote:
 shouldn't this work?
 
 # ifconfig em0 inet 128.9.168.58 netmask 255.255.240.0 \
   ether 00:07:e9:0a:26:52
 ifconfig: ether: bad value
 
 This is with today's -current, but this may have been around longer - I 
 hadn't tried it before today. Using two commands to set MAC and IP 
 addresses works fine, but it needs to be one command for rc.conf.

This issue is already known about and the behaviour you are seeing is in
accordance with how ifconfig should currently behave.

I suggest patching rc scripts until it can be solved the right way round.

Regards,
BMS
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: HEADS-UP new statfs structure

2003-11-15 Thread Garance A Drosihn
At 6:20 PM -0800 11/15/03, David O'Brien wrote:
On Sat, Nov 15, 2003 at 03:16:03PM -0800, Marcel Moolenaar wrote:
 Provided that we
  2. replace the date with a convenient sequence number,
 which we can call the minor version number, and
..
  E.g.: libc.so.6.0, libc.so.6.1, and (first release) libc.so.6.2...
Please no -- it wouldn't be easy to see a.out libs from ELF ones.
(yes I still have some a.out binaries)
Maybe:
   libc.so.6.e0, libc.so.6.e1, and (first release) libc.so.6.e2...
I have no idea what would be best to do, but I do think we
(developers and users alike) would be much better off if
we had some way to handle all these changes which come in.
Or maybe the real problem is that we claim that there will
be no API/ABI changes after X.0-RELEASE, and we've really
missed that mark with 5.0-RELEASE, for a variety of reasons.
If we're going to keep missing that mark with the 6.x-series,
then we should plan to do something to make life a little
less painful.  Right now it's getting more painful, if for
no other reason than we have more developers, and thus more
major-changes in the pipeline.
--
Garance Alistair Drosehn=   [EMAIL PROTECTED]
Senior Systems Programmer   or  [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor  [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


kernel panic with todays source

2003-11-15 Thread Harald Schmalzbauer
Hi,

I saw that something has changed on ULE and wanted to give it a try but with 
sources from ~ So 16 Nov 2003 04:00 UTC I get the following kernel panic just 
before disk/geom and after Timecounter TSC frequency 1095341787 Hz quality 
800:

Fatal trap 12   :page fault while in kernel mode
fault virtual address   =0x24
fault code  =supervisor read, page not present
instruction pointer =0x8:0xc056c706
stack pointer   =0x10:0xcdca4ca4
frame pointer   =0x10:0xcdca4ca4
code segment=base 0x0, limit 0xf, type 0x1b
=DPL 0, pres 1, def32 1, gran 1
processor eflags=resume, IOPL=0
current process =11 (idle)
trap number =12
panic: page fault

I do have compiled the kernel with makeoptions debug but I don't have a serial 
terminal nor firewire.

Let me know if I can help.

Attached my kernel config

Thanks,

-Harry

## Kernel for ASUS CUSL2 ##


## Generic Config
#---
machine i386
cpu I686_CPU
options PQ_CACHESIZE=256# color for 512k/16k cache
ident   CALE
makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols
options SCHED_4BSD  #4BSD scheduler
#optionsSCHED_ULE
options PROCFS  #Process filesystem (requires PSEUDOFS)
options COMPAT_43   #Compatible with BSD 4.3 [KEEP THIS!]
options COMPAT_FREEBSD4
options KTRACE  #ktrace(1) support
options SYSVSHM #SYSV-style shared memory
options SYSVMSG #SYSV-style message queues
options SYSVSEM #SYSV-style semaphores
options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions
options CLK_USE_I8254_CALIBRATION
options CLK_USE_TSC_CALIBRATION
options HZ=2000
options PERFMON
#options MAC
#options MAC_BIBA
#options MAC_BSDEXTENDED
#options MAC_DEBUG
#options MAC_IFOFF
#options MAC_LOMAC
#options MAC_MLS
#options MAC_NONE
#options MAC_PARTITION
#options MAC_PORTACL
#options MAC_SEEOTHERUIDS
#options MAC_TEST

## Buses
#--
#options SMP
device  apic
options NO_MIXED_MODE
device  acpi
device  npx
device  isa
device  pci
#device agp

## ISA-Controller
#
device  atkbdc  # AT keyboard controller
device  sio # 8250, 16[45]50 based serial ports
device  pmtimer

## PCI-Controller
#--
device  ata
device  uhci# UHCI PCI-USB interface
device  ohci# OHCI PCI-USB interface

## Devices with their options
#
#+ IDE ++
device  atadisk # ATA disk drives
device  atapicd # ATAPI CDROM drives
options ATA_STATIC_ID   #Static device numbering
options FFS #Berkeley Fast Filesystem
options UDF
options UFS_ACL #Support for access control lists
options UFS_DIRHASH #Improve performance on big directories
options SOFTUPDATES #Enable FFS soft updates support
options GEOM_BDE
options UFS_EXTATTR
options UFS_EXTATTR_AUTOSTART
options QUOTA   #enable disk quotas
#options SUIDDIR
#+ SCSI +
device  scbus   # SCSI bus (required)
device  da  # Direct Access (disks)
device  pass# Passthrough device (direct SCSI access)
#device atapicam
#+ Eingabe +
device  atkbd   # AT keyboard
device  psm # PS/2 mouse
#+ Ausgabe ++
device  vga # VGA video card driver
options VESA
device  splash  # Splash screen and screen saver support
device  sc
options MAXCONS=12
options SC_DISABLE_REBOOT
options SC_PIXEL_MODE
options SC_HISTORY_SIZE=1000
device  pcm
#+ USB +
device  usb # USB Bus (required)
device  ugen# Generic
device  uhid# Human Interface Devices
device  ukbd# Keyboard
device  umass   # Disks/Mass storage - Requires scbus and da
device  ums # Mouse
#+ Netzwerk +
device  miibus  # MII bus support
device  fxp
options DEVICE_POLLING
options INET#InterNETworking
options NFSCLIENT   #Network Filesystem Client
options NFSSERVER   #Network Filesystem Server

Re: kernel panic with todays source

2003-11-15 Thread Robert Watson

On Sun, 16 Nov 2003, Harald Schmalzbauer wrote:

 Fatal trap 12   :page fault while in kernel mode
 fault virtual address   =0x24
 fault code  =supervisor read, page not present
 instruction pointer =0x8:0xc056c706
 stack pointer   =0x10:0xcdca4ca4
 frame pointer   =0x10:0xcdca4ca4
 code segment=base 0x0, limit 0xf, type 0x1b
 =DPL 0, pres 1, def32 1, gran 1
 processor eflags=resume, IOPL=0
 current process =11 (idle)
 trap number =12
 panic: page fault
 
 I do have compiled the kernel with makeoptions debug but I don't have a
 serial terminal nor firewire. 

Could you show the output from running the following command in gdb -k
kernel.debug:

  l *0xc056c706

This will tell us where in the kernel the instruction pointer in question
was.  For whatever reason, your kernel panic doesn't seem to have dropped
you into DDB (at least, the output looks that way).  If you did get into
ddb, the results of the trace command would be very helpful.  As you
have no serial console, it's probably sufficient to just transcript the
offsets at the end of each line in the trace (functioname+0xOFFSET) 
without the argument entries. 

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: kernel panic with todays source

2003-11-15 Thread Harald Schmalzbauer
On Sunday 16 November 2003 05:34, Robert Watson wrote:
 On Sun, 16 Nov 2003, Harald Schmalzbauer wrote:
  Fatal trap 12   :page fault while in kernel mode
  fault virtual address   =0x24
  fault code  =supervisor read, page not present
  instruction pointer =0x8:0xc056c706
  stack pointer   =0x10:0xcdca4ca4
  frame pointer   =0x10:0xcdca4ca4
  code segment=base 0x0, limit 0xf, type 0x1b
  =DPL 0, pres 1, def32 1, gran 1
  processor eflags=resume, IOPL=0
  current process =11 (idle)
  trap number =12
  panic: page fault
 
  I do have compiled the kernel with makeoptions debug but I don't have a
  serial terminal nor firewire.

 Could you show the output from running the following command in gdb -k
 kernel.debug:

   l *0xc056c706

 This will tell us where in the kernel the instruction pointer in question
 was.  For whatever reason, your kernel panic doesn't seem to have dropped
 you into DDB (at least, the output looks that way).  If you did get into
 ddb, the results of the trace command would be very helpful.  As you
 have no serial console, it's probably sufficient to just transcript the

I think for this I need to set options DDB in my kernel, don't I? But 
without serial terminal this is pretty useless I think.
But I'll do if you can get needed information which was otherwise not 
accessable.

Thanks,

-Harry

 offsets at the end of each line in the trace (functioname+0xOFFSET)
 without the argument entries.

 Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
 [EMAIL PROTECTED]  Network Associates Laboratories


pgp0.pgp
Description: signature


Re: kernel panic with todays source

2003-11-15 Thread Harald Schmalzbauer
On Sunday 16 November 2003 05:40, Craig Rodrigues wrote:
 On Sun, Nov 16, 2003 at 05:32:03AM +0100, Harald Schmalzbauer wrote:
  instruction pointer =0x8:0xc056c706
  stack pointer   =0x10:0xcdca4ca4
  frame pointer   =0x10:0xcdca4ca4

 Do you have a file:
 /usr/obj/usr/src/sys/CALE/kernel.debug ?

 If so, if you do:

 gdb -k /usr/obj/usr/src/sys/CALE/kernel.debug

 What do you see if you do:
 l *0xc056c706

(kgdb) l *0xc056c706
0xc056c706 is in vsscanf (/usr/src/sys/kern/subr_scanf.c:224).
219
220 case '[':
221 fmt = __sccl(ccltab, fmt);
222 flags |= NOSKIP;
223 c = CT_CCL;
224 break;
225
226 case 'c':
227 flags |= NOSKIP;
228 c = CT_CHAR;

 l *0xcdca4ca4

(kgdb) l *0xcdca4ca4
No source file for address 0xcdca4ca4

 l *0xcdca4ca4

Sorry, perhaps I mistyped that address. If it helps, I could reboot with the 
faulty kernel and look for the address again.

Thanks,

-Harry




pgp0.pgp
Description: signature


Re: kernel panic with todays source

2003-11-15 Thread Harald Schmalzbauer
On Sunday 16 November 2003 05:49, Harald Schmalzbauer wrote:
 On Sunday 16 November 2003 05:34, Robert Watson wrote:
  On Sun, 16 Nov 2003, Harald Schmalzbauer wrote:
   Fatal trap 12   :page fault while in kernel mode
   fault virtual address   =0x24
   fault code  =supervisor read, page not present
   instruction pointer =0x8:0xc056c706
   stack pointer   =0x10:0xcdca4ca4
   frame pointer   =0x10:0xcdca4ca4
   code segment=base 0x0, limit 0xf, type 0x1b
   =DPL 0, pres 1, def32 1, gran 1
   processor eflags=resume, IOPL=0
   current process =11 (idle)
   trap number =12
   panic: page fault
  
   I do have compiled the kernel with makeoptions debug but I don't have a
   serial terminal nor firewire.
 
  Could you show the output from running the following command in gdb -k
  kernel.debug:
 
l *0xc056c706

Sorry, forgot to mention that I answered this in Craig Rodrigues mail. But 
while I'm here:

(kgdb) l *0xc056c706
0xc056c706 is in vsscanf (/usr/src/sys/kern/subr_scanf.c:224).
219
220 case '[':
221 fmt = __sccl(ccltab, fmt);
222 flags |= NOSKIP;
223 c = CT_CCL;
224 break;
225
226 case 'c':
227 flags |= NOSKIP;
228 c = CT_CHAR;

Thanks,

-Harry

 
  This will tell us where in the kernel the instruction pointer in question
  was.  For whatever reason, your kernel panic doesn't seem to have dropped
  you into DDB (at least, the output looks that way).  If you did get into
  ddb, the results of the trace command would be very helpful.  As you
  have no serial console, it's probably sufficient to just transcript the

 I think for this I need to set options DDB in my kernel, don't I? But
 without serial terminal this is pretty useless I think.
 But I'll do if you can get needed information which was otherwise not
 accessable.

 Thanks,

 -Harry

  offsets at the end of each line in the trace (functioname+0xOFFSET)
  without the argument entries.
 
  Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
  [EMAIL PROTECTED]  Network Associates Laboratories


pgp0.pgp
Description: signature


HEADS UP: /bin and /sbin are now dynamically linked

2003-11-15 Thread Gordon Tetlow
I just committed a patch to change /bin and /sbin from statically to
dynamically linked. If you don't like the idea of using a dynamically
linked /bin and /sbin, now is the time to define NO_DYNAMICROOT in your
make.conf.

The reasons for doing so have been hashed over lots of times. But the
short of it:

1) Much smaller /bin and /sbin. On i386, /bin and /sbin are 33 MB static.
   Dynamically linked, they are only 4 MB.
2) Proper support for NSS. This will finally allow you to use NSS modules
   and get things like usernames in ls -l working for modules that are
   dynamically loaded.

-gordon


pgp0.pgp
Description: PGP signature


Re: HEADS-UP new statfs structure

2003-11-15 Thread Kris Kennaway
On Sat, Nov 15, 2003 at 11:05:51PM -0500, Garance A Drosihn wrote:

 Or maybe the real problem is that we claim that there will
 be no API/ABI changes after X.0-RELEASE, and we've really
 missed that mark with 5.0-RELEASE, for a variety of reasons.

Where do we claim that?

All I'm aware of is the policy of not trying to break compatibility in
-STABLE, although that isn't strictly adhered to in practise.

Kris


pgp0.pgp
Description: PGP signature


Re: panic: Assertion TD_IS_RUNNING(td) failed at /a/asami/portbuild/amd64/src-client/sys/kern/subr_turnstile.c:687

2003-11-15 Thread Kris Kennaway
On Sat, Nov 15, 2003 at 06:36:17PM -0800, Kris Kennaway wrote:
 hammer02 died after a few minutes of idling with:
 
 panic: Assertion TD_IS_RUNNING(td) failed at 
 /a/asami/portbuild/amd64/src-client/sys/kern/subr_turnstile.c:687
 Debugger(panic)
 Stopped at  Debugger+0x4b:  xchgl   %ebx,0x317b8f
 db trace
 Debugger() at Debugger+0x4b
 panic() at panic+0x169
 turnstile_unpend() at turnstile_unpend+0x322
 _mtx_unlock_sleep() at _mtx_unlock_sleep+0xa0
 _mtx_unlock_flags() at _mtx_unlock_flags+0xb0
 ithread_loop() at ithread_loop+0x1ac
 fork_exit() at fork_exit+0xbd
 fork_trampoline() at fork_trampoline+0xe
 --- trap 0, rip = 0, rsp = 0x986bad30, rbp = 0 ---
 db

Another one:

panic: Assertion TD_IS_RUNNING(td) failed at 
/a/asami/portbuild/amd64/src-client/sys/kern/subr_turnstile.c:687
Debugger(panic)
Stopped at  Debugger+0x4b:  xchgl   %ebx,0x317b8f
db trace
Debugger() at Debugger+0x4b
panic() at panic+0x169
turnstile_unpend() at turnstile_unpend+0x322
_mtx_unlock_sleep() at _mtx_unlock_sleep+0xa0
_mtx_unlock_flags() at _mtx_unlock_flags+0xb0
bufdonebio() at bufdonebio+0x4f
biodone() at biodone+0x66
g_dev_done() at g_dev_done+0x7c
biodone() at biodone+0x66
g_io_schedule_up() at g_io_schedule_up+0x85
g_up_procbody() at g_up_procbody+0x40
fork_exit() at fork_exit+0xbd
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0x98694d30, rbp = 0 ---
db

pgp0.pgp
Description: PGP signature


Re: HEADS-UP new statfs structure

2003-11-15 Thread Daniel Eischen
On Sat, 15 Nov 2003, Marcel Moolenaar wrote:

 On Sat, Nov 15, 2003 at 02:45:57PM -0800, Terry Lambert wrote:
  
   For 6.0, can we start off libc at libc.so.MMDD and move it
   back to libc.so.6 for the first release?  That way we can bump
   it whenever we want to avoid the bumpy rides for -current
   folk.
  
  This is a great idea!
 
 Provided that we
 1. keep the major number to allow concurrent development of different
(major) library versions, and
 2. replace the date with a convenient sequence number, which we can
call the minor version number, and
 3. Do not reset the version number when we release.
 
 E.g.: libc.so.6.0, libc.so.6.1, and (first release) libc.so.6.2...

I don't care so much about naming conventions.  It would just be
nice to be able to bump the version in development as often as
you like without usurping release version ids (major or minor).
You can still use minor numbers while still not throwing some away:

6.0 Branch - libc.so.6.1000
libc bump - libc.so.6.1001
libc bump - libc.so.6.1002
6.0-Release - libc.so.6.0
libc bump - libc.so.6.1003
6.1-Release - libc.so.6.1
...

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: HEADS-UP new statfs structure

2003-11-15 Thread M. Warner Losh
In message: [EMAIL PROTECTED]
David O'Brien [EMAIL PROTECTED] writes:
: On Sat, Nov 15, 2003 at 03:16:03PM -0800, Marcel Moolenaar wrote:
:  Provided that we
:  2. replace the date with a convenient sequence number, which we can
: call the minor version number, and
: .. 
:  E.g.: libc.so.6.0, libc.so.6.1, and (first release) libc.so.6.2...
: 
: Please no -- it wouldn't be easy to see a.out libs from ELF ones.
: (yes I still have some a.out binaries)

And there is no such thing as a minor version number on elf anyway.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


[current tinderbox] failure on alpha/alpha

2003-11-15 Thread Tinderbox
TB --- 2003-11-16 05:00:02 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org
TB --- 2003-11-16 05:00:02 - starting CURRENT tinderbox run for alpha/alpha
TB --- 2003-11-16 05:00:02 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-11-16 05:01:59 - building world
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything..
TB --- 2003-11-16 06:06:21 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
 Kernel build for GENERIC started on Sun Nov 16 06:06:21 GMT 2003
[...]
=== osf1
cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee  -D_KERNEL -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline 
-Wcast-qual  -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I-   -include 
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC/opt_global.h
 -I. -I@ -I@/../include -finline-limit=15000 -fno-common -g 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC
 -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline 
-Wcast-qual  -fformat-extensions -std=c99 -c 
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/osf1/osf1_ioctl.c
cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee  -D_KERNEL -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline 
-Wcast-qual  -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I-   -include 
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC/opt_global.h
 -I. -I@ -I@/../include -finline-limit=15000 -fno-common -g 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC
 -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline 
-Wcast-qual  -fformat-extensions -std=c99 -c 
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/osf1/osf1_misc.c
cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee  -D_KERNEL -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline 
-Wcast-qual  -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I-   -include 
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC/opt_global.h
 -I. -I@ -I@/../include -finline-limit=15000 -fno-common -g 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC
 -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline 
-Wcast-qual  -fformat-extensions -std=c99 -c 
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/osf1/osf1_signal.c
cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee  -D_KERNEL -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline 
-Wcast-qual  -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I-   -include 
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC/opt_global.h
 -I. -I@ -I@/../include -finline-limit=15000 -fno-common -g 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC
 -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline 
-Wcast-qual  -fformat-extensions -std=c99 -c 
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/osf1/osf1_sysent.c
cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee  -D_KERNEL -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline 
-Wcast-qual  -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I-   -include 
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC/opt_global.h
 -I. -I@ -I@/../include -finline-limit=15000 -fno-common -g 

Re: HEADS-UP new statfs structure

2003-11-15 Thread M. Warner Losh
In message: [EMAIL PROTECTED]
Garance A Drosihn [EMAIL PROTECTED] writes:
: At 6:20 PM -0800 11/15/03, David O'Brien wrote:
: On Sat, Nov 15, 2003 at 03:16:03PM -0800, Marcel Moolenaar wrote:
:   Provided that we
:2. replace the date with a convenient sequence number,
:   which we can call the minor version number, and
: ..
:E.g.: libc.so.6.0, libc.so.6.1, and (first release) libc.so.6.2...
: 
: Please no -- it wouldn't be easy to see a.out libs from ELF ones.
: (yes I still have some a.out binaries)
: 
: Maybe:
: libc.so.6.e0, libc.so.6.e1, and (first release) libc.so.6.e2...
: 
: I have no idea what would be best to do, but I do think we
: (developers and users alike) would be much better off if
: we had some way to handle all these changes which come in.
: 
: Or maybe the real problem is that we claim that there will
: be no API/ABI changes after X.0-RELEASE, and we've really
: missed that mark with 5.0-RELEASE, for a variety of reasons.
: If we're going to keep missing that mark with the 6.x-series,
: then we should plan to do something to make life a little
: less painful.  Right now it's getting more painful, if for
: no other reason than we have more developers, and thus more
: major-changes in the pipeline.

Actually, 5.x is an anomaly.  We'd planned on freezing the 5.0 ABI at
5.0, but we missed that mark and are waiting for 5.3 to freeze the
ABI, treaing 5.0, 5.1 and 5.2 as if they were pre-releases.  For 6.0
we'll be back to having libc.so.6.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


  1   2   >