Re: FreeBSD current, apache and php4 woes
Claus Guttesen wrote: 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 You'll either want to raise the size of the kmem_map pool (this is where kernel malloc and UMA get their allocations), or decrease the maximum number of vnodes allowed (vnodes get allocated out of the kmem_map and are likely depleating it in your case). I run into this constantly; we worked on fixing it last spring by making the maxvnodes auto-tune itself better, but that seems to no longer be enough. Add one of the two lines to /boot/loader.conf: kern.vn.kmem.size=35000 or kern.maxvnodes=15 The first one is probably the better choice for you since the very nature of what you are doing demands that you touch a lot of vnodes. Scott ___ [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
On Sat, Nov 15, 2003 at 11:17:00PM -0700, M. Warner Losh wrote: > 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. There isn't even a major version number. There's only strcmp(). -- 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: HEADS-UP new statfs structure
In message: <[EMAIL PROTECTED]> Daniel Eischen <[EMAIL PROTECTED]> writes: : 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 : ... Please no. ELF libraries have no minor numbers and a scheme like this would likely cause no end of problems. For FreeBSD 6.x we should keep the same API and actively pursue people that want to break it with large pointy sticks. 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
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]"
[current tinderbox] failure on alpha/alpha
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 -I/vol/vol0/users/des/tinderbox/CURRENT/alpha
Re: HEADS-UP new statfs structure
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]"
Re: HEADS-UP new statfs structure
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: panic: Assertion TD_IS_RUNNING(td) failed at /a/asami/portbuild/amd64/src-client/sys/kern/subr_turnstile.c:687
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
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: HEADS-UP new statfs structure
On Sat, 15 Nov 2003, Garance A Drosihn wrote: > 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. The API and ABI are frozen when we make 5.x-STABLE and branch 6.x. Until then it's open to change. This was decided up front. Cheers, Jeff > > -- > 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]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
HEADS UP: /bin and /sbin are now dynamically linked
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: kernel panic with todays source
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
Re: kernel panic with todays source
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
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
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]"
kernel panic with todays source
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 Serve
Re: HEADS-UP new statfs structure
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]"
Re: ifconfig bug
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: dc still reporting collisions
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: HEADS-UP new statfs structure
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: DIAGNOSTIC LOR in softclock
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: Who needs these silly statfs changes...
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: Who needs these silly statfs changes...
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]"
[current tinderbox] failure on sparc64/sparc64
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: named pipes memory leak?
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]"
Re: HEADS-UP new statfs structure condidered harmful
:> 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: cardbus no longer working with -CURRENT and ACPI
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: at device 10.0 on pci0 : cardbus0: 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: Who needs these silly statfs changes...
[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
Re: dc still reporting collisions
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=8843 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 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 5347 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]"
[current tinderbox] failure on ia64/ia64
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: HEADS-UP new statfs structure condidered harmful
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]"
Re: FreeBSD current, apache and php4 woes
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: NFSv4 Client code committed.
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: /etc/rc.d/ipsec starts not in time
Hajimu UMEMOTO wrote: > > Kostyuk Oleg <[EMAIL PROTECTED]> said: > > cub>Problem is in order of starting /etc/rc.d/ipsec. > cub>It must start BEFORE any network interaction, > cub>may be even before configuring interfaces. > cub>But 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: HEADS-UP new statfs structure
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: FreeBSD current, apache and php4 woes
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: dc still reporting collisions
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=8843 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 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 5347 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: HEADS-UP new statfs structure
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: xscreensaver bug?
"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
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: Who needs these silly statfs changes...
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: Who needs these silly statfs changes...
(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]"
panic: recursed on non-recursive lock (vnode interlock)
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]"
cbb cardbus activation failed
Hello, I have a Compaq armada 7800 with a noname pccard ethernet adapter which used to be detected as: rl0: port 0x1100-0x11ff mem 0x8800-0x880001ff irq 11 at device 0.0 on cardbus0 rl0: Ethernet address: 00:10:60:58:60:b8 miibus0: on rl0 rlphy0: 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: 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]"
moused(8) broken
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]"
[current tinderbox] failure on i386/pc98
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]"
Re: Who needs these silly statfs changes...
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]"
Re: HEADS-UP new statfs structure condidered harmful
: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: HEADS-UP new statfs structure condidered harmful
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: checking stopevent 2!
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]"
cardbus no longer working with -CURRENT and ACPI
List, Running -CURRENT now gives the following problem on a Compaq Pressario 1600- XL144 laptop: [...] cbb0: at device 10.0 on pci0 cardbus0: 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]"
[current tinderbox] failure on i386/i386
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]"
Re: dc still reporting collisions
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=8843 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 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 5347 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]"
Re: dc still reporting collisions
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 00:00:e8:89:b9:6626463 026737 13253 225301 > > Fwiw, I'm seeing the same with tx(4): > > lizzy:~% ifconfig tx0 > tx0: flags=8843 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 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 5347 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: cvs commit: src/sys/dev/acpica acpi_cpu.c src/share/man/man4 acpi.4 src/sys/conf files src/sys/modules/acpi Makefile
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]"
TWE driver IOCTL's
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: ifconfig bug
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
Re: checking stopevent 2!
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
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!
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: NFSv4 Client code committed.
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
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: checking stopevent 2!
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]"
ifconfig bug
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: exclusive sleep mutex
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]"
Re: checking stopevent 2!
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: cdrom mounting problems
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=0x183f9ff AMD Features=0xc044 real memory = 402587648 (383 MB) avail memory = 385548288 (367 MB) Pentium Pro MTRR support enabled acpi0: 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: on acpi0 acpi_tz0: port 0x530-0x537 on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 pci0: 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: mem 0xd000-0xd7ff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib0: slot 1 INTA is routed to irq 10 pcib1: slot 0 INTA is routed to irq 10 pci1: 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: 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: on xl1 xlphy1: <3Com internal media interface> on miibus1 xlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: at device 17.0 on pci0 isa0: on isab0 atapci0: 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: port 0xb000-0xb01f irq 11 at device 17.2 on pci0 usb0: 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: port 0xb400-0xb41f irq 11 at device 17.3 on pci0 usb1: 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: port 0xb800-0xb81f irq 11 at device 17.4 on pci0 usb2: 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: port 0xbc00-0xbcff irq 5 at device 17.5 on pci0 pcm0: fdc0: 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: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 npx0: [FAST] npx0: on motherboard npx0: INT 16 interface orm0: at iomem 0xc-0xcbfff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: 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, default to deny, logging disabled acpi_cpu: throttling enabled, 2 steps (100% to 50.0%), currently 100.0% GEOM: create disk ad0 dp=0xc372e570 ad0: 38166MB [77545/16/63] at ata0-master UDMA100 acd0: CDROM at ata1-master PIO4 Mounting root from ufs:/dev/ad0s2a WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted /usr: mount pending error: blocks 124 files 1 WARNING: /var was not properly dismounted drm0: port 0x9000-0x90ff mem 0xe100-0xe100,0xd800-0xdfff irq 10 at device 0.0 on pci1 info: [drm] AGP at 0xd000 128MB info: [drm] Initialized radeon 1.9.0 20020828 on minor 0 drm0: [M
Re: NFSv4 Client code committed.
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
cdrom mounting problems
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]"
kern/59233: patch to soundcard.h to include an ioctl and a constant for midi
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]"
Re: dc still reporting collisions
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=8843 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 ) > status: active > > > netstat -i > NameMtu Network Address Ipkts IerrsOpkts Oerrs Coll > dc01500 00:00:e8:89:b9:6626463 026737 13253 225301 > dc01500 172.22.2/28 team226044 -26636 - - > lo0 16384 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]"
AW: AW: 5.1. does not boot afte installation
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: NFSv4 Client code committed.
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]"
DIAGNOSTIC LOR in softclock
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=51 error=4 acd0: CDROM <665A> at ata2-slave BIOSPIO acd1: CDROM 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]"
panic: Assertion td->td_turnstile != NULL failed
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 to continue, or q 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=0xc078f4
[current tinderbox] failure on alpha/alpha
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/modul
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: signal 12's everywhere on Current with update this morning.
> 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]"
Re: checking stopevent 2!
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: upgraded to CURRENT = system is dead
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]"
FreeBSD current, apache and php4 woes
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: Unattended reboot was Re: signal 12's everywhere on Current with update this morning.
"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]"
Re: upgraded to CURRENT = system is dead
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: checking stopevent 2!
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 hummer kernel: checking stopevent 2 with the following
> > non-sleepable locks held:
> > Nov 15 16:05:44 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 hummer kernel: checking stopevent 2 with the following
> > non-sleepable locks held:
> > Nov 15 16:05:44 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 hummer kernel: checking stopevent 2 with the following
> > non-sleepable locks held:
> > Nov 15 16:05:45 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 hummer kernel: checking stopevent 2 with the following
> > non-sleepable locks held:
> > Nov 15 16:05:45 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 hummer kernel: checking stopevent 2 with the following
> > non-sleepable locks held:
> > Nov 15 16:05:45 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 hummer kernel: checking stopevent 2 with the following
> > non-sleepable locks held:
> > Nov 15 16:05:45 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 hummer kernel: checking stopevent 2 with the following
> > non-sleepable locks held:
> > Nov 15 16:05:45 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 hummer kernel: checking stopevent 2 with the following
> > non-sleepable locks held:
> > Nov 15 16:05:46 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 hummer kernel: checking stopevent 2 with the following
> > non-sleepable locks held:
> > Nov 15 16:05:46 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 hummer kernel: checking stopevent 2 with the following
> > non-sleepable locks held:
> > Nov 15 16:05:46 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 hummer kernel: checking stopevent 2 with the following
> > non-sleepable locks held:
> > Nov 15 16:05:46 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
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]"
stopevents?
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]"
5.2-RELEASE TODO
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 | |
Re: checking stopevent 2!
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 hummer kernel: checking stopevent 2 with the following
> non-sleepable locks held:
> Nov 15 16:05:44 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 hummer kernel: checking stopevent 2 with the following
> non-sleepable locks held:
> Nov 15 16:05:44 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 hummer kernel: checking stopevent 2 with the following
> non-sleepable locks held:
> Nov 15 16:05:45 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 hummer kernel: checking stopevent 2 with the following
> non-sleepable locks held:
> Nov 15 16:05:45 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 hummer kernel: checking stopevent 2 with the following
> non-sleepable locks held:
> Nov 15 16:05:45 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 hummer kernel: checking stopevent 2 with the following
> non-sleepable locks held:
> Nov 15 16:05:45 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 hummer kernel: checking stopevent 2 with the following
> non-sleepable locks held:
> Nov 15 16:05:45 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 hummer kernel: checking stopevent 2 with the following
> non-sleepable locks held:
> Nov 15 16:05:46 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 hummer kernel: checking stopevent 2 with the following
> non-sleepable locks held:
> Nov 15 16:05:46 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 hummer kernel: checking stopevent 2 with the following
> non-sleepable locks held:
> Nov 15 16:05:46 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 hummer kernel: checking stopevent 2 with the following
> non-sleepable locks held:
> Nov 15 16:05:46 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]"
Re: HEADS UP: the midi driver will be removed for a while
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
HEADS UP: the midi driver will be removed for a while
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]"
devfs rule
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]"
Re: signal 12's everywhere on Current with update this morning.
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]"
Re: Using Geom to mirror root partitions?
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]"
[current tinderbox] failure on sparc64/sparc64
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=1500
Re: upgraded to CURRENT = system is dead
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]"
Re: /etc/rc.d/ipsec starts not in time
Hi, > On Sun, 02 Nov 2003 15:49:35 +0200 > Kostyuk Oleg <[EMAIL PROTECTED]> said: cub>Problem is in order of starting /etc/rc.d/ipsec. cub>It must start BEFORE any network interaction, cub>may be even before configuring interfaces. cub>But 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]"
[current tinderbox] failure on ia64/ia64
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/freeb
Re: console freezes
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 i386/pc98
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: Using Geom to mirror root partitions?
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]"
Re: Two processes with PID == 0
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]"
