Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
On Sun, Jun 15, 2003 at 08:43:15PM -0400, Chris Shenton wrote: I've been running qmail for years and like it, installed pretty much per www.LifeWithQmail.org. My main system was running FreeBSD 5.0-RELEASE and -CURRENT and qmail was fine. When I just upgraded to 5.1-CURRENT a couple days back, the qmail-send process started using all CPU. This looks like a bug in the named pipe code. Reverting sys/fs/fifofs/fifo_vnops.c to the RELENG_5_0 version makes the problem go away. I haven't tracked down exactly what change between RELENG_5_0 and RELENG_5_1 caused the problem. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
Hi, On Mon, 15 Jun 2003, Chris Shenton wrote: [...] qmail is run under daemontools and all work fine (the configuration is 2 years old!), but when I delivery the first mail (localy or remote) the qmail-send process fire up to 100% of CPU infinitely All other mail are right delivery, and the CPU use is the only problem, I see in qmail-send.c that select() function, after the first message, allways return 1 same here too. I don't know what it could be - perhaps a problem with named pipes (lock/trigger)? You can find my ktrace output here: http://cs.so36.net/~ths/kdump.txt Would be nice if anyone have an idea :) A truss shows me it's running in a tight loop over this code: close(9) = 0 (0x0) select(0x9,0xbfbffcbc,0xbfbffc3c,0x0,0xbfbffc24) = 1 (0x1) Anyone else seen this or know what in FreeBSD-5.1 might have changed to cause this? Any thoughts on how I might go about diagnosing this any better? greetings, thorsten ___ [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-06-16 05:15:09 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-06-16 05:15:09 - 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-06-16 05:16:59 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-06-16 06:10:14 - 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 Mon Jun 16 06:10:15 GMT 2003 Kernel build for GENERIC completed on Mon Jun 16 06:23:48 GMT 2003 TB --- 2003-06-16 06:23:48 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- /usr/bin/make -B LINT TB --- 2003-06-16 06:23:48 - 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 Mon Jun 16 06:23:48 GMT 2003 [...] /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/en/midway.c:1502: increment of pointer to unknown structure /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/en/midway.c:1502: arithmetic on pointer to an incomplete type /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/en/midway.c: In function `en_ioctl': /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/en/midway.c:1591: `SIOCATMGETVCCS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/en/midway.c:1600: `SIOCATMGVCCS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/en/midway.c:1606: dereferencing pointer to incomplete type /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/en/midway.c:1607: dereferencing pointer to incomplete type /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/en/midway.c:1607: dereferencing pointer to incomplete type *** 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-06-16 06:28:36 - /usr/bin/make returned exit code 1 TB --- 2003-06-16 06:28:36 - ERROR: failed to build lint kernel TB --- 2003-06-16 06:28:36 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
On 16 Jun, Thorsten Schroeder wrote: Hi, On Mon, 15 Jun 2003, Chris Shenton wrote: [...] qmail is run under daemontools and all work fine (the configuration is 2 years old!), but when I delivery the first mail (localy or remote) the qmail-send process fire up to 100% of CPU infinitely All other mail are right delivery, and the CPU use is the only problem, I see in qmail-send.c that select() function, after the first message, allways return 1 same here too. I don't know what it could be - perhaps a problem with named pipes (lock/trigger)? You can find my ktrace output here: http://cs.so36.net/~ths/kdump.txt Would be nice if anyone have an idea :) A truss shows me it's running in a tight loop over this code: close(9) = 0 (0x0) select(0x9,0xbfbffcbc,0xbfbffc3c,0x0,0xbfbffc24) = 1 (0x1) Anyone else seen this or know what in FreeBSD-5.1 might have changed to cause this? Any thoughts on how I might go about diagnosing this any better? Which version of fifo_vnops.c? If the problem is present in 5.1-RELEASE, then the problem is likely to be the change made in 1.79 and 1.85. If the problem didn't show up until after the 5.1-RELEASE, then the problem could be the changes in 1.87 or 1.88. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
On Mon, Jun 16, 2003 at 04:09:51PM +1000, Tim Robbins wrote: On Sun, Jun 15, 2003 at 08:43:15PM -0400, Chris Shenton wrote: I've been running qmail for years and like it, installed pretty much per www.LifeWithQmail.org. My main system was running FreeBSD 5.0-RELEASE and -CURRENT and qmail was fine. When I just upgraded to 5.1-CURRENT a couple days back, the qmail-send process started using all CPU. This looks like a bug in the named pipe code. Reverting sys/fs/fifofs/fifo_vnops.c to the RELENG_5_0 version makes the problem go away. I haven't tracked down exactly what change between RELENG_5_0 and RELENG_5_1 caused the problem. Looks like revision 1.86 works, but it stops working with 1.87. Moving the soclose() calls to fifo_inactive() may have caused it. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
Hi, On Sun, 15 Jun 2003, Don Lewis wrote: I don't know what it could be - perhaps a problem with named pipes (lock/trigger)? You can find my ktrace output here: http://cs.so36.net/~ths/kdump.txt Which version of fifo_vnops.c? If the problem is present in 5.1-RELEASE, then the problem is likely to be the change made in 1.79 and 1.85. If the problem didn't show up until after the 5.1-RELEASE, then the problem could be the changes in 1.87 or 1.88. FreeBSD 5.1-CURRENT #1: Thu Jun 5 19:29:29 CEST 2003 fifo_vnops.c: $FreeBSD: src/sys/fs/fifofs/fifo_vnops.c,v 1.87 2003/06/01 06:24:32 truckman Exp $ bye, thorsten ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Compiling under 5.x for 4.x releases?
On Sat, Jun 14, 2003 at 01:04:52PM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Karl Denninger [EMAIL PROTECTED] writes: : Thanks; I guess that means that for now I keep the production build machine : is 4.8-STABLE, and I keep 5.x as a play environment until people move : over. I think, but am not positive, that 4.8-stable boxes can build tip of current again. Until recently, it was possible to cross-build 4.x on 5.x; and this only additionally required installing the Perl port. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
On 16 Jun, Tim Robbins wrote: On Mon, Jun 16, 2003 at 04:09:51PM +1000, Tim Robbins wrote: On Sun, Jun 15, 2003 at 08:43:15PM -0400, Chris Shenton wrote: I've been running qmail for years and like it, installed pretty much per www.LifeWithQmail.org. My main system was running FreeBSD 5.0-RELEASE and -CURRENT and qmail was fine. When I just upgraded to 5.1-CURRENT a couple days back, the qmail-send process started using all CPU. This looks like a bug in the named pipe code. Reverting sys/fs/fifofs/fifo_vnops.c to the RELENG_5_0 version makes the problem go away. I haven't tracked down exactly what change between RELENG_5_0 and RELENG_5_1 caused the problem. Looks like revision 1.86 works, but it stops working with 1.87. Moving the soclose() calls to fifo_inactive() may have caused it. This is an interesting observation, but I'm not sure why it would make a difference. I haven't looked at the qmail source, but it looks like it is doing a non-blocking open on the fifo, calling select() on the fd, and hoping that select() waits for a writer to open the fifo before returning with an indication that the descriptor is readable. It looks like the select code is calling the soreadable() macro to determine if the fifo descriptor is readable, and the soreadable() macro returns a true value if the SS_CANTRCVMORE socket flag is set, which would indicate an EOF condition. I might believe that I accidentally changed the setting of this flag, but I just compared fifo_vnops.c rev 1.78 with 1.87 and I believe this flag should be set the same way in both versions. In both versions, fifo_close() always calls socantrcvmore(), which sets SS_CANTRCVMORE when the writer count drops to zero. Prior to 1.87, fifo_close() also destroyed the sockets when the reference count dropped to zero, which caused fifo_open() to recreate the sockets when the fifo was opened again, and when it did, fifo_open() set the SS_CANTRCVMORE flag again. The posted qmail syscall trace looks like what I would expect to see in the present implementation. I can't explain why it would behave any differently prior to 1.87 ... ___ [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-06-16 06:28:37 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-06-16 06:28:37 - 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-06-16 06:31:43 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-06-16 07:28:55 - 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 Mon Jun 16 07:28:56 GMT 2003 Kernel build for GENERIC completed on Mon Jun 16 07:40:17 GMT 2003 TB --- 2003-06-16 07:40:17 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src/sys/pc98/conf TB --- /usr/bin/make -B LINT TB --- 2003-06-16 07:40:17 - 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 Mon Jun 16 07:40:17 GMT 2003 [...] /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/en/midway.c:1502: increment of pointer to unknown structure /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/en/midway.c:1502: arithmetic on pointer to an incomplete type /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/en/midway.c: In function `en_ioctl': /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/en/midway.c:1591: `SIOCATMGETVCCS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/en/midway.c:1600: `SIOCATMGVCCS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/en/midway.c:1606: dereferencing pointer to incomplete type /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/en/midway.c:1607: dereferencing pointer to incomplete type /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/en/midway.c:1607: dereferencing pointer to incomplete type *** 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-06-16 07:43:53 - /usr/bin/make returned exit code 1 TB --- 2003-06-16 07:43:53 - ERROR: failed to build lint kernel TB --- 2003-06-16 07:43:53 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
subscibe
___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
On 16 Jun, I wrote:
On 16 Jun, Tim Robbins wrote:
This looks like a bug in the named pipe code. Reverting
sys/fs/fifofs/fifo_vnops.c to the RELENG_5_0 version makes the problem go
away. I haven't tracked down exactly what change between RELENG_5_0 and
RELENG_5_1 caused the problem.
Looks like revision 1.86 works, but it stops working with 1.87. Moving the
soclose() calls to fifo_inactive() may have caused it.
This is an interesting observation, but I'm not sure why it would make a
difference. I haven't looked at the qmail source, but it looks like it
is doing a non-blocking open on the fifo, calling select() on the fd,
and hoping that select() waits for a writer to open the fifo before
returning with an indication that the descriptor is readable.
It looks like the select code is calling the soreadable() macro to
determine if the fifo descriptor is readable, and the soreadable() macro
returns a true value if the SS_CANTRCVMORE socket flag is set, which
would indicate an EOF condition.
I might believe that I accidentally changed the setting of this flag,
but I just compared fifo_vnops.c rev 1.78 with 1.87 and I believe this
flag should be set the same way in both versions.
In both versions, fifo_close() always calls socantrcvmore(), which sets
SS_CANTRCVMORE when the writer count drops to zero. Prior to 1.87,
fifo_close() also destroyed the sockets when the reference count dropped
to zero, which caused fifo_open() to recreate the sockets when the fifo
was opened again, and when it did, fifo_open() set the SS_CANTRCVMORE
flag again.
The posted qmail syscall trace looks like what I would expect to see in
the present implementation. I can't explain why it would behave any
differently prior to 1.87 ...
The plot thickens ...
I ran this bit of code on both 5.1 current with version 1.88 of
fifo_vnops.c, and 4.8-stable:
#include sys/types.h
#include sys/time.h
#include unistd.h
#include fcntl.h
main()
{
int fd;
fd_set readfds;
fd = open(myfifo, O_RDONLY | O_NONBLOCK);
printf(before the loop\n);
while (1) {
FD_ZERO(readfds);
FD_SET(fd, readfds);
printf(%d %d\n, fd, select(20, readfds, NULL, NULL, NULL));
}
exit(0);
}
On 4.8-stable, select() immediately returns a 1, whether or not the
fifo has ever been opened for writing.
On 5.1-current, select() waits forever, even if the fifo has been opened
for writing by another process. Select() only returns when something
has actually been written to the fifo, and since this process doesn't
read anything from the fifo, it spins on select() forever.
If some data is getting written to the fifo, it doesn't look like qmail
consumes it, and since fifo_close in 1.87 doesn't destroy the sockets,
it looks like the data is hanging around in the fifo while neither end
is open, and qmail stumbles across this data when it calls select()
after re-opening the fifo.
Now there are two questions that I can't answer:
Why is my analysis of select() and the SS_CANTRCVMORE flag
incorrect in 5.1-current with version 1.87 or 1.88 of
fifo_vnops.c.
Why doesn't qmail get stuck in a similar loop in 4.8-stable,
since select always returns true for reading on a fifo with no
writers?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
make world failure: tar/cleaning object tree
Hi, make world fails, rm -rf /usr/obj ; make -DNOCLEAN world is fine. make world failure happens in -- stage 2: cleaning up the object tree -- ... === gnu/usr.bin/tar rm -f tar addext.o argmatch.o backupfile.o basename.o dirname.o error.o exclude. o full-write.o getdate.o getline.o getopt.o getopt1.o getstr.o hash.o human.o mk time.o modechange.o prepargs.o print-copyr.o quotearg.o safe-read.o save-cwd.o s avedir.o unicodeio.o xgetcwd.o xmalloc.o xstrdup.o xstrtoul.o xstrtoumax.o buffe r.o compare.o create.o delete.o extract.o incremen.o list.o mangle.o misc.o name s.o rtapelib.o tar.o update.o tar.1.gz tar.1.cat.gz rm: tar: is a directory *** Error code 1 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Problem on installing BSD 5.x on laptop ...
Hello, I have a 3CCFEM556BI pccard connected on my laptop. However, I don't manage to get the device working during the install of FreeBSD 5.0 and 5.1. Actually the pcmcia driver work fine as it recognized my APA 1480A cardbus. During the boot there is a message ep0: eeprom failed to come ready. When I switch on the second console during the installation, I have a message ep0: No I/O space?! How could I get my 3CCFEM556BI work during the install process of FreeBSD ? Friendly Damien Touraine ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
fdescfs naming inconsistency
This isn't really a big deal, but I've noticed a slight inconsistency in the output of `mount` when a fdescfs is mounted: edgemaster# mount /dev/ad1s1a on / (ufs, local, soft-updates, multilabel) /dev/ad1s1e on /var (ufs, local, soft-updates, multilabel, acls) /dev/ad1s1f on /usr (ufs, local, soft-updates, multilabel, acls) devfs on /dev (devfs, local, multilabel) fdesc on /dev/fd (fdescfs) ^ ^^^ /dev/fd0 on /mnt (msdosfs, local) linprocfs on /usr/compat/linux/proc (linprocfs, local) Notice that while devfs and linprocfs have the 'fs' appended to their name, the fdescfs does not. Shouldn't the output be more like this? fdescfs on /dev/fd (fdescfs) ^^ So far my attempts to find the origin of this in the source have failed. -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.zombie.org pgp0.pgp Description: PGP signature
Re: fdescfs naming inconsistency
Sean Kelly writes: So far my attempts to find the origin of this in the source have failed. It's probably here: ./sys/fs/fdescfs/fdesc_vfsops.c:bcopy(fdesc, mp-mnt_stat.f_mntfromname, sizeof(fdesc)); --- Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic during boot of today's kernel.
I cvsuped just a couple of hours ago and built world and then built a kernel. That kernel always dies on startup. First it shows a Fatal Trap 9 and then a Fatal Trap 12 and then give me the debugger prompt. Is there some easy way to get the information from the debugger into an email short of writing it down? If I need to write it down, what are the important things to get? I'm on a Sony Vaio laptop that has been having trouble with APCI so I disabled it, but it still crashes. The last message printed to the screen before the crash was: pnpbios: handle 14 device ID PNP0c02 Let me know what I can do to help debug this. ___ [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-06-16 09:08:17 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-06-16 09:08:17 - 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-06-16 09:11:06 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-06-16 10:03:13 - 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 Mon Jun 16 10:03:14 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -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/dev -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 -D_KERNEL -include opt_global.h -fno-common -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/ufs/ufs/ufs_vfsops.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -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/dev -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 -D_KERNEL -include opt_global.h -fno-common -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/ufs/ufs/ufs_vnops.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -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/dev -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 -D_KERNEL -include opt_global.h -fno-common -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/vm/default_pager.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -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/dev -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 -D_KERNEL -include opt_global.h -fno-common -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/vm/device_pager.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -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/dev -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 -D_KERNEL -include opt_global.h -fno-common -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/vm/phys_pager.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -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/dev -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 -D_KERNEL -include opt_global.h -fno-common
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
On Mon, 16 Jun 2003, Don Lewis wrote:
On 16 Jun, I wrote:
On 16 Jun, Tim Robbins wrote:
This looks like a bug in the named pipe code. Reverting
sys/fs/fifofs/fifo_vnops.c to the RELENG_5_0 version makes the problem go
away. I haven't tracked down exactly what change between RELENG_5_0 and
RELENG_5_1 caused the problem.
Looks like revision 1.86 works, but it stops working with 1.87. Moving the
soclose() calls to fifo_inactive() may have caused it.
This is an interesting observation, but I'm not sure why it would make a
difference. I haven't looked at the qmail source, but it looks like it
is doing a non-blocking open on the fifo, calling select() on the fd,
and hoping that select() waits for a writer to open the fifo before
returning with an indication that the descriptor is readable.
In my review of 1.87, I forgot to ask you how atomic the close is with part
of it moved out to fifo_inactive(). I think it's important that all
traces of the old open have gone away (as far as applications can tell)
when the last close returns.
It looks like the select code is calling the soreadable() macro to
determine if the fifo descriptor is readable, and the soreadable() macro
returns a true value if the SS_CANTRCVMORE socket flag is set, which
would indicate an EOF condition.
fifo_close() sets this flag and the corresponding send flag on last close,
so there is no direct problem here.
...
The posted qmail syscall trace looks like what I would expect to see in
the present implementation. I can't explain why it would behave any
differently prior to 1.87 ...
The plot thickens ...
I ran this bit of code on both 5.1 current with version 1.88 of
fifo_vnops.c, and 4.8-stable:
#include sys/types.h
#include sys/time.h
#include unistd.h
#include fcntl.h
main()
{
int fd;
fd_set readfds;
fd = open(myfifo, O_RDONLY | O_NONBLOCK);
printf(before the loop\n);
while (1) {
FD_ZERO(readfds);
FD_SET(fd, readfds);
printf(%d %d\n, fd, select(20, readfds, NULL, NULL, NULL));
}
exit(0);
}
On 4.8-stable, select() immediately returns a 1, whether or not the
fifo has ever been opened for writing.
On 5.1-current, select() waits forever, even if the fifo has been opened
for writing by another process. Select() only returns when something
has actually been written to the fifo, and since this process doesn't
read anything from the fifo, it spins on select() forever.
If some data is getting written to the fifo, it doesn't look like qmail
consumes it, and since fifo_close in 1.87 doesn't destroy the sockets,
it looks like the data is hanging around in the fifo while neither end
is open, and qmail stumbles across this data when it calls select()
after re-opening the fifo.
Now there are two questions that I can't answer:
Why is my analysis of select() and the SS_CANTRCVMORE flag
incorrect in 5.1-current with version 1.87 or 1.88 of
fifo_vnops.c.
I think it is correct, assuming that something writes to the fifo.
Writing might be part of synchronization but actually reading the
data should not be necessary since the last close must discard the
data (POSIX spec).
Why doesn't qmail get stuck in a similar loop in 4.8-stable,
since select always returns true for reading on a fifo with no
writers?
Don't know. Maybe it uses autoconfig to handle the 4.8 behaviour.
The 4.8 behaviour is normal compared with the buggy behaviour of
not discarding data on last close, so applications should handle it
better :-). Maybe qmain spins under 4.8 too, but only until
synchronization is achieved.
Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
On 16 Jun, Bruce Evans wrote: On Mon, 16 Jun 2003, Don Lewis wrote: On 16 Jun, I wrote: On 16 Jun, Tim Robbins wrote: This looks like a bug in the named pipe code. Reverting sys/fs/fifofs/fifo_vnops.c to the RELENG_5_0 version makes the problem go away. I haven't tracked down exactly what change between RELENG_5_0 and RELENG_5_1 caused the problem. Looks like revision 1.86 works, but it stops working with 1.87. Moving the soclose() calls to fifo_inactive() may have caused it. This is an interesting observation, but I'm not sure why it would make a difference. I haven't looked at the qmail source, but it looks like it is doing a non-blocking open on the fifo, calling select() on the fd, and hoping that select() waits for a writer to open the fifo before returning with an indication that the descriptor is readable. In my review of 1.87, I forgot to ask you how atomic the close is with part of it moved out to fifo_inactive(). I think it's important that all traces of the old open have gone away (as far as applications can tell) when the last close returns. I hadn't taken queued data into consideration. Now that I've looked at this more closely, there are other problems in both the old and new code. If a process calls fcntl(fd, F_SETOWN, ...) on one end of the fifo, that should be undone when that end of the fifo is closed. In the old implementation, that only happens when both ends of the fifo are closed and the sockets are deleted. On 5.1-current, select() waits forever, even if the fifo has been opened for writing by another process. Select() only returns when something has actually been written to the fifo, and since this process doesn't read anything from the fifo, it spins on select() forever. If some data is getting written to the fifo, it doesn't look like qmail consumes it, and since fifo_close in 1.87 doesn't destroy the sockets, it looks like the data is hanging around in the fifo while neither end is open, and qmail stumbles across this data when it calls select() after re-opening the fifo. Now there are two questions that I can't answer: Why is my analysis of select() and the SS_CANTRCVMORE flag incorrect in 5.1-current with version 1.87 or 1.88 of fifo_vnops.c. I think it is correct, assuming that something writes to the fifo. Writing might be part of synchronization but actually reading the data should not be necessary since the last close must discard the data (POSIX spec). It sure looks to me like SS_CANTRCVMORE is always set when the write end of the fifo is closed, no matter whether the the sockets were freshly allocated by a fifo_open() call on the read end of the fifo, or because the the last writer closed the write end of the fifo. It sure looks like select() should immediately return if this flag is set, but it is not returning ... Actually, something seems broken. I modified my little test program to actually read the data, which works just fine, but select() still blocks when the writer closes the fifo, so there doesn't seem to be a way to detect the EOF. Why doesn't qmail get stuck in a similar loop in 4.8-stable, since select always returns true for reading on a fifo with no writers? Don't know. Maybe it uses autoconfig to handle the 4.8 behaviour. The 4.8 behaviour is normal compared with the buggy behaviour of not discarding data on last close, so applications should handle it better :-). Maybe qmain spins under 4.8 too, but only until synchronization is achieved. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
On 16 Jun, Thorsten Schroeder wrote:
Hi,
On Sun, 15 Jun 2003, Don Lewis wrote:
I don't know what it could be - perhaps a problem with named pipes
(lock/trigger)?
You can find my ktrace output here: http://cs.so36.net/~ths/kdump.txt
Which version of fifo_vnops.c? If the problem is present in
5.1-RELEASE, then the problem is likely to be the change made in 1.79
and 1.85. If the problem didn't show up until after the 5.1-RELEASE,
then the problem could be the changes in 1.87 or 1.88.
FreeBSD 5.1-CURRENT #1: Thu Jun 5 19:29:29 CEST 2003
fifo_vnops.c:
$FreeBSD: src/sys/fs/fifofs/fifo_vnops.c,v 1.87 2003/06/01 06:24:32 truckman Exp $
Try upgrading to 1.88 and applying this patch:
Index: sys/fs/fifofs/fifo_vnops.c
===
RCS file: /home/ncvs/src/sys/fs/fifofs/fifo_vnops.c,v
retrieving revision 1.88
diff -u -r1.88 fifo_vnops.c
--- sys/fs/fifofs/fifo_vnops.c 13 Jun 2003 06:58:11 - 1.88
+++ sys/fs/fifofs/fifo_vnops.c 16 Jun 2003 08:44:20 -
@@ -70,7 +70,6 @@
static int fifo_lookup(struct vop_lookup_args *);
static int fifo_open(struct vop_open_args *);
static int fifo_close(struct vop_close_args *);
-static int fifo_inactive(struct vop_inactive_args *);
static int fifo_read(struct vop_read_args *);
static int fifo_write(struct vop_write_args *);
static int fifo_ioctl(struct vop_ioctl_args *);
@@ -98,7 +97,6 @@
{ vop_create_desc, (vop_t *) vop_panic },
{ vop_getattr_desc,(vop_t *) vop_ebadf },
{ vop_getwritemount_desc, (vop_t *) vop_stdgetwritemount },
- { vop_inactive_desc, (vop_t *) fifo_inactive },
{ vop_ioctl_desc, (vop_t *) fifo_ioctl },
{ vop_kqfilter_desc, (vop_t *) fifo_kqfilter },
{ vop_lease_desc, (vop_t *) vop_null },
@@ -556,32 +554,18 @@
if (fip-fi_writers == 0)
socantrcvmore(fip-fi_readsock);
}
- VOP_UNLOCK(vp, 0, td);
- return (0);
-}
-
-static int
-fifo_inactive(ap)
- struct vop_inactive_args /* {
- struct vnode *a_vp;
- struct thread *a_td;
- } */ *ap;
-{
- struct vnode *vp = ap-a_vp;
- struct fifoinfo *fip = vp-v_fifoinfo;
-
VI_LOCK(vp);
- if (fip != NULL vp-v_usecount == 0) {
+ if (vp-v_usecount == 1) {
vp-v_fifoinfo = NULL;
VI_UNLOCK(vp);
(void)soclose(fip-fi_readsock);
(void)soclose(fip-fi_writesock);
FREE(fip, M_VNODE);
- }
- VOP_UNLOCK(vp, 0, ap-a_td);
+ } else
+ VI_UNLOCK(vp);
+ VOP_UNLOCK(vp, 0, td);
return (0);
}
-
/*
* Print out internal contents of a fifo vnode.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
Don Lewis wrote: Actually, something seems broken. I modified my little test program to actually read the data, which works just fine, but select() still blocks when the writer closes the fifo, so there doesn't seem to be a way to detect the EOF. I think this should be covered under the exceptional event and read select flags (a subsequent read will return 0). Also, you should remember that qmail opens the thing with non-blocking I/O, and then expects the select to block. Very odd program, qmail. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.1-RELEASE; Fatal trap 12: page fault while in kernel mode
the rest of '/var/log/messages' is in the attachment.. Jun 15 22:00:00 kadafi newsyslog[2458]: logfile turned over due to size100K Jun 16 00:42:30 kadafi syslogd: kernel boot file is /boot/kernel/kernel Jun 16 00:42:30 kadafi kernel: Jun 16 00:42:30 kadafi kernel: Jun 16 00:42:30 kadafi kernel: Fatal trap 12: page fault while in kernel mode Jun 16 00:42:30 kadafi kernel: fault virtual address= 0xbffe Jun 16 00:42:30 kadafi kernel: fault code = supervisor write, page not present Jun 16 00:42:30 kadafi kernel: instruction pointer = 0x8:0xc02c349c Jun 16 00:42:30 kadafi kernel: stack pointer= 0x10:0xdf106b10 Jun 16 00:42:30 kadafi kernel: frame pointer= 0x10:0xdf106b2c Jun 16 00:42:30 kadafi kernel: code segment = base 0x0, limit 0xf, type 0x1b Jun 16 00:42:30 kadafi kernel: = DPL 0, pres 1, def32 1, gran 1 Jun 16 00:42:30 kadafi kernel: processor eflags = interrupt enabled, resume, IOPL = 0 Jun 16 00:42:30 kadafi kernel: current process = 11 (swi7: tty:sio clock) Jun 16 00:42:30 kadafi kernel: trap number = 12 Jun 16 00:42:30 kadafi kernel: panic: page fault Jun 16 00:42:30 kadafi kernel: syncing disks, buffers remaining... 7142 7142 7142 7142 7142 7142 7142 7142 7142 7142 7142 7142 7142 7142 7142 7142 7142 7142 7142 7142 messages Description: Binary data ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
On Mon, 16 Jun 2003, Don Lewis wrote: On 16 Jun, Bruce Evans wrote: In my review of 1.87, I forgot to ask you how atomic the close is with part of it moved out to fifo_inactive(). I think it's important that all traces of the old open have gone away (as far as applications can tell) when the last close returns. I hadn't taken queued data into consideration. Now that I've looked at this more closely, there are other problems in both the old and new code. If a process calls fcntl(fd, F_SETOWN, ...) on one end of the fifo, that should be undone when that end of the fifo is closed. In the old implementation, that only happens when both ends of the fifo are closed and the sockets are deleted. F_SETOWN (and associated signal delivery) is even more broken than that :-]. This fcntl() should applied to the file (though not just the file descriptor), so its effect should be limited to fd's open in the file instance and go away when all thse are closed. However, F_SETOWN (and associated signal delivery) actually applies to the socket for fifos. It doesn't work quite right for ttys either. F_SETOWN apparently isn't used in ways complicated enough to require it to work right. Now there are two questions that I can't answer: Why is my analysis of select() and the SS_CANTRCVMORE flag incorrect in 5.1-current with version 1.87 or 1.88 of fifo_vnops.c. I think it is correct, assuming that something writes to the fifo. Writing might be part of synchronization but actually reading the data should not be necessary since the last close must discard the data (POSIX spec). It sure looks to me like SS_CANTRCVMORE is always set when the write end of the fifo is closed, no matter whether the the sockets were freshly allocated by a fifo_open() call on the read end of the fifo, or because the the last writer closed the write end of the fifo. It sure looks like select() should immediately return if this flag is set, but it is not returning ... Alfred changed the semantics for 5.x. I thought that you knew this. I finally gave up resisting this change after a lot of email :-). In 5.x, SS_CANTRCVMORE often has no effect for fifos (it still works normally for sockets). fifo_poll() normally calls soo_poll() with POLLIN converted to POLLINIGNEOF. This causes soo_poll() (sopoll()) to skip the usual SS_CANTRCVMORE check (which is inside soreadable()) and check the watermark instead, so that select() on a fifo normally waits for data even when the fifo is open in nonblocking mode and SS_CANTRCVMORE is set. Blocking in select() even in nonblocking mode is usually what is wanted, but is not what is wanted for detecting EOF. 4.8 handles EOF detection (== all writers going away in the context of fifos) better at a cost of providing no good way to wait for the first writer. We changed it since all other systems seem to do it like 5.x and few applications understand this. Actually, something seems broken. I modified my little test program to actually read the data, which works just fine, but select() still blocks when the writer closes the fifo, so there doesn't seem to be a way to detect the EOF. Hmm, we may have changed too much. EOF can be detected using poll() instead of select() and seting POLLIN and POLLINIGNEOF in the poll flags (this stops fifo_poll() clearing POLLIN -- see the comment), but the POLLINIGNEOF is not documented at the application level and is probably never used there. I suspect that other systems have more magic to handle EOF. I tried to avoid such magic since I think the state of the fifo should be the same when there are no writers (and no data) no matter how the state of having no writers was reached (otherwise I think the state depends too much on races between open() for reading and close() by the last writer). POSIX is clear enough on this for read/write but fuzzy for select/poll. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make world failure: tar/cleaning object tree
On Mon, Jun 16, 2003 at 10:21:51AM +0200, Matthias Andree wrote: Hi, make world fails, rm -rf /usr/obj ; make -DNOCLEAN world is fine. Always update with 'cvs update -PdA' Kris pgp0.pgp Description: PGP signature
Re: make world failure: tar/cleaning object tree
On Mon, 16 Jun 2003, Kris Kennaway wrote: On Mon, Jun 16, 2003 at 10:21:51AM +0200, Matthias Andree wrote: make world fails, rm -rf /usr/obj ; make -DNOCLEAN world is fine. Always update with 'cvs update -PdA' I used cvsup without -s. shrug -- Matthias Andree ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Need acpi-event-d?
First, I must say that it's cool that ACPI code can be examined and rewritten. In my laptop's case, this was key to make things fairly happy. Anyways, after a resume, it would appear I need to kill and restart moused. Under 4.x, apmd was used for this purpose ... but this new laptop doesn't support apm at all. /dev/apm seemed to be emulated by acpi for the benifit of battery monitors, but apmd won't run. Is there a facility to run things on resume, or is this reset something better done inside the kernel? Dave. -- |David Gilbert, Velocet Communications. | Two things can only be | |Mail: [EMAIL PROTECTED] | equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Need acpi-event-d?
On 2003.06.16 07:07:36 -0400, David Gilbert wrote: First, I must say that it's cool that ACPI code can be examined and rewritten. In my laptop's case, this was key to make things fairly happy. Anyways, after a resume, it would appear I need to kill and restart moused. Under 4.x, apmd was used for this purpose ... but this new laptop doesn't support apm at all. /dev/apm seemed to be emulated by acpi for the benifit of battery monitors, but apmd won't run. Is there a facility to run things on resume, or is this reset something better done inside the kernel? I think devd(8) should be used for this, but I havn't tried. -- Simon L. Nielsen pgp0.pgp Description: PGP signature
5.1-CURRENT hangs on disk i/o? sysctl_old_user() non-sleepable locks
(I don't know if this has any relation to the problems I reported
yesterday with qmail-send consuming 100% cpu after 5.0 to 5.1 upgrade.)
After booting 5.1-CURRENT the system runs fine for a while. Then
later most disk i/o related actions seem to hang. E.g., system works
but when cron kicks off a glimpseindex in the middle of the night, the
system is useless by the morning. If I login on the console as me, it
takes my username and password then hangs (trying to run
/usr/local/bin/bash?). If I do this as root, I do get a shell
(/bin/csh). After a point, asking for top will hang, even as root.
Even a reboot hung this morning with nothing in the logs.
The system has become almost unusable because of this, requiring
frequent reboots or hardware resets.
Sometimes when I do something as simple as ps I see this ominous
message on the console:
sysctl_old_user() with the following non-sleepablelocks held:
exclusive sleep mutex process lock r = 0 (0xc50bc9e0) locked @
/usr/src/sys/kern/kern_proc.c:258
which gets into /var/log/messages as:
Jun 16 08:33:48 PECTOPAH kernel: exclusive sleep mutex process lock r = 0
(0xc50c7618) locked @ /usr/src/sys/kern/kern_proc.c:258
There are a bunch of these.
That file is version:
$FreeBSD: src/sys/kern/kern_proc.c,v 1.189 2003/06/14 06:20:25 alc Exp $
and the line is the PROC_LOCK() portion of:
struct proc *
pfind(pid)
register pid_t pid;
{
register struct proc *p;
sx_slock(allproc_lock);
LIST_FOREACH(p, PIDHASH(pid), p_hash)
if (p-p_pid == pid) {
PROC_LOCK(p);
break;
}
sx_sunlock(allproc_lock);
return (p);
}
Any thoughts? Thanks.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
mpd, ng, Cisco VPN, resource leak
For months I'm trying to get back to a working VPN using mpd on a FreeBSD 4.4 client site and a Cisco VPN server on the peer end. With 5.0 and 5.1-current the network connection stopped working. I could work for a minute or so then the connection got hung. Trying to reconnect with a new ssh session got some message about 'resource deadlock avoided' and a subsequent ping to the peer side gets the onminous 'no buffers space available' or an additional : [EMAIL PROTECTED] ssh acc01 ssh: connect to host acc01 port 22: Connection refused [EMAIL PROTECTED] ping acs01 PING acc01 (138.134.123.12): 56 data bytes ping: sendto: Resource deadlock avoided ping: sendto: No buffer space available ping: sendto: No buffer space available ^C --- acc01 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss The connection refused occurs on the peer side where the previous ssh connection had succeeded. It's not that the sshd died. Rebooting my system allows be to connect again for a minute or 2 and then again the hang. How could I pinpoint the problem so that some knowing kernel/netgraph person will be available to find the cause? Is there a way to do a continous netstat -m or vmstat -m during a session setup? I mean other than writing it to a file in a shell while loop? -- Chris Christoph P. U. Kukulies [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
truss issue
All,
I found current truss behaviour a bit strange. It coredumps always if
trussed process do without any significant reason for my understanding.
I also confused with comment for commit originally introduced this
functionality
http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/truss/main.c.diff?r1=1.9r2=1.10.
I propose patch attached to make truss always return result of trussed
process and do not kill() itself. What do you think about it?
All the best,
Alexander.
--- usr.bin/truss/main.c.orig Mon Jun 16 23:00:35 2003
+++ usr.bin/truss/main.cMon Jun 16 23:05:03 2003
@@ -144,7 +144,7 @@
struct ex_types *funcs;
int in_exec = 0;
char *fname = NULL;
- int sigexit = 0;
+ int rval = 0;
struct trussinfo *trussinfo;
/* Initialize the trussinfo struct */
@@ -283,10 +283,10 @@
break;
case S_SIG:
fprintf(trussinfo-outfile, SIGNAL %lu\n, pfs.val);
- sigexit = pfs.val;
break;
case S_EXIT:
fprintf (trussinfo-outfile, process exit, rval = %lu\n, pfs.val);
+ rval = pfs.val;
break;
case S_EXEC:
funcs = set_etype(trussinfo);
@@ -305,11 +305,5 @@
}
} while (pfs.why != S_EXIT);
fflush(trussinfo-outfile);
- if (sigexit) {
-if (sigexit == SIGQUIT)
- exit(sigexit);
-(void) signal(sigexit, SIG_DFL);
-(void) kill(getpid(), sigexit);
- }
- return 0;
+ return rval;
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
Hi, On Mon, 16 Jun 2003, Don Lewis wrote: FreeBSD 5.1-CURRENT #1: Thu Jun 5 19:29:29 CEST 2003 fifo_vnops.c: $FreeBSD: src/sys/fs/fifofs/fifo_vnops.c,v 1.87 2003/06/01 06:24:32 truckman Exp $ Try upgrading to 1.88 and applying this patch: Index: sys/fs/fifofs/fifo_vnops.c === RCS file: /home/ncvs/src/sys/fs/fifofs/fifo_vnops.c,v retrieving revision 1.88 diff -u -r1.88 fifo_vnops.c --- sys/fs/fifofs/fifo_vnops.c13 Jun 2003 06:58:11 - 1.88 +++ sys/fs/fifofs/fifo_vnops.c16 Jun 2003 08:44:20 - [...] Yes! This seems to work fine :) qmail-send doesn't increase cpu usage after the first mail anymore. Thanks a lot, Thorsten ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: spec_specstrategy(0x3c41a000 != 0xc3419db0)
With a -current kernel from yesterday's sources (June 15) I get a consistent panic on boot. It happens when trying to mount root: Mounting root from ufs:/dev/da0s1a panic: spec_specstrategy(0xc341a000 != 0xc3419db0) This problem did not occur with a kernel from the previous day (June 14). Here's the stack trace, copied by hand: panic spec_specstrategy ufs_strategy ufs_vnoperate breadn bread ffs_blkatoff ufs_lookup ufs_vnoperate vfs_cache_lookup ufs_vnoperate lookup namei kern_mkdir start_init fork_exit fork_trampoline On request, I'll hook up a serial console and get more information. Here's the dmesg output from the working kernel: 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 #1: Sat Jun 14 11:51:14 PDT 2003 [EMAIL PROTECTED]:/a/src/sys/i386/compile/BLAKE Preloaded elf kernel /boot/kernel/kernel at 0xc04e6000. Preloaded elf module /boot/kernel/acpi.ko at 0xc04e61f4. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 400911153 Hz CPU: Pentium II/Pentium II Xeon/Celeron (400.91-MHz 686-class CPU) Origin = GenuineIntel Id = 0x653 Stepping = 3 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36 ,MMX,FXSR real memory = 402640896 (383 MB) avail memory = 385712128 (367 MB) Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS P2B-Son motherboard pcibios: BIOS version 2.10 Using $PIR table, 7 entries at 0xc00f0d10 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-safe frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: slot 4 INTD is routed to irq 9 pcib0: slot 6 INTA is routed to irq 9 pcib0: slot 10 INTA is routed to irq 5 pcib0: slot 11 INTA is routed to irq 10 pcib0: slot 12 INTA is routed to irq 11 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pcib0: slot 1 INTA is routed to irq 11 pcib1: slot 0 INTA is routed to irq 11 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 UDMA33 controller port 0xd800-0xd80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xd400-0xd41f irq 9 at device 4.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: bridge, PCI-unknown at device 4.3 (no driver attached) ahc0: Adaptec aic7890/91 Ultra2 SCSI adapter port 0xd000-0xd0ff mem 0xe000-0xefff irq 9 at device 6.0 on pci0 aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs fxp0: Intel 82557/8/9 EtherExpress Pro/100(B) Ethernet port 0xb800-0xb83f mem 0xdf00-0xdf01,0xdf80-0xdf800fff irq 5 at device 10.0 on pci0 fxp0: Ethernet address 00:02:b3:63:f9:a2 miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto em0: Intel(R) PRO/1000 Network Connection, Version - 1.6.6 mem 0xde00-0xde00,0xde80-0xde81 irq 10 at device 1 1.0 on pci0 em0: Speed:N/A Duplex:N/A bge0: Altima AC1000 Gigabit Ethernet, ASIC rev. 0x7104 mem 0xdd80-0xdd80 irq 11 at device 12.0 on pci0 bge0: Ethernet address: 00:40:f4:36:9b:d3 miibus1: MII bus on bge0 brgphy0: BCM5411 10/100/1000baseTX PHY on miibus1 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 orm0: Option ROM at iomem 0xc-0xc7fff on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec IPsec: Initialized Security Association Processing. Waiting 2 seconds for SCSI devices to settle cd0 at ahc0 bus 0 target 5 lun 0 cd0: TOSHIBA CD-ROM XM-6201TA 1030 Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 16) cd0: Attempt to query device size failed: NOT READY, Medium not present da0 at ahc0 bus 0 target 0 lun 0 da0: IBM
Re: Need acpi-event-d?
On Mon, Jun 16, 2003 at 07:07:36AM -0400, David Gilbert wrote: Anyways, after a resume, it would appear I need to kill and restart moused. Under 4.x, apmd was used for this purpose ... but this new laptop doesn't support apm at all. /dev/apm seemed to be emulated by acpi for the benifit of battery monitors, but apmd won't run. Is there a facility to run things on resume, or is this reset something better done inside the kernel? man psm Set the HOOKRESUME and INITAFTERSUSPEND flags in /boot/device.hints. Works for me on a Dell I5000. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mpd, ng, Cisco VPN, resource leak
Hi Christoph On Monday 16 June 2003 16:03, Christoph Kukulies wrote: For months I'm trying to get back to a working VPN using mpd on a FreeBSD 4.4 client site and a Cisco VPN server on the peer end. With 5.0 and 5.1-current the network connection stopped working. I could work for a minute or so then the connection got hung. Trying to reconnect with a new ssh session got some message about 'resource deadlock avoided' and a subsequent ping to the peer side gets the onminous 'no buffers space available' or an additional : [EMAIL PROTECTED] ssh acc01 ssh: connect to host acc01 port 22: Connection refused [EMAIL PROTECTED] ping acs01 PING acc01 (138.134.123.12): 56 data bytes ping: sendto: Resource deadlock avoided ping: sendto: No buffer space available ping: sendto: No buffer space available ^C --- acc01 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss The connection refused occurs on the peer side where the previous ssh connection had succeeded. It's not that the sshd died. Rebooting my system allows be to connect again for a minute or 2 and then again the hang. How could I pinpoint the problem so that some knowing kernel/netgraph person will be available to find the cause? Is there a way to do a continous netstat -m or vmstat -m during a session setup? I mean other than writing it to a file in a shell while loop? I know exactly what you are talking about. I had the same problems here. Please have a look at http://www.cs.rpi.edu/~flemej/fbsd-cisco-vpn/ . That (partly) solved the problems for me, however I have to set the routes to the subnets behind the VPN-server manually after establishing a connection to the VPN-server via mpd. If I set the routes in the mentioned script, the routingtable seems to be ok, but setting the routing entrys this way leads to the same problems you already mentioned. I have no idea whats wrong and why I have to set them manually. Perhaps we can figure out this minor last problem together. Best Regards, Markus -- GPG Pub-Key: http://www.phoenix-systems.de/mbrueffer.asc GPG Fingerprint: 3F9B EBE8 F290 E5CC 1447 8760 D48D 1072 78F8 A8D4 GPG Key ID : 0x78F8A8D4 pgp0.pgp Description: signature
Re: panic: spec_specstrategy(0x3c41a000 != 0xc3419db0)
In message [EMAIL PROTECTED], John Polstra writes: With a -current kernel from yesterday's sources (June 15) I get a consistent panic on boot. It happens when trying to mount root: Mounting root from ufs:/dev/da0s1a panic: spec_specstrategy(0xc341a000 != 0xc3419db0) This problem did not occur with a kernel from the previous day (June 14). You hit a bad point in time, right between me botching things up and me fixing it again. -- 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: panic: spec_specstrategy(0x3c41a000 != 0xc3419db0)
In article [EMAIL PROTECTED], Poul-Henning Kamp [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], John Polstra writes: With a -current kernel from yesterday's sources (June 15) I get a consistent panic on boot. It happens when trying to mount root: Mounting root from ufs:/dev/da0s1a panic: spec_specstrategy(0xc341a000 != 0xc3419db0) This problem did not occur with a kernel from the previous day (June 14). You hit a bad point in time, right between me botching things up and me fixing it again. Thanks. I had a feeling that might be the case, since nobody else was complaining about the problem. John -- John Polstra John D. Polstra Co., Inc.Seattle, Washington USA Two buttocks cannot avoid friction. -- Malawi saying ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
Thorsten Schroeder wrote: Hi, On Mon, 16 Jun 2003, Don Lewis wrote: FreeBSD 5.1-CURRENT #1: Thu Jun 5 19:29:29 CEST 2003 fifo_vnops.c: $FreeBSD: src/sys/fs/fifofs/fifo_vnops.c,v 1.87 2003/06/01 06:24:32 truckman Exp $ Try upgrading to 1.88 and applying this patch: Index: sys/fs/fifofs/fifo_vnops.c === RCS file: /home/ncvs/src/sys/fs/fifofs/fifo_vnops.c,v retrieving revision 1.88 diff -u -r1.88 fifo_vnops.c --- sys/fs/fifofs/fifo_vnops.c 13 Jun 2003 06:58:11 - 1.88 +++ sys/fs/fifofs/fifo_vnops.c 16 Jun 2003 08:44:20 - [...] Yes! This seems to work fine :) I run qmail on my 4.8 servers. For my sanity, is this a problem in 5.1-RELEASE, or in code after 5.1-RELEASE? We haven't upgraded to 5.1 yet (and don't intend to for a while), but I thought I'd ask since this bug would cripple our mail server. -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
On 16 Jun, Thorsten Schroeder wrote: Hi, On Mon, 16 Jun 2003, Don Lewis wrote: FreeBSD 5.1-CURRENT #1: Thu Jun 5 19:29:29 CEST 2003 fifo_vnops.c: $FreeBSD: src/sys/fs/fifofs/fifo_vnops.c,v 1.87 2003/06/01 06:24:32 truckman Exp $ Try upgrading to 1.88 and applying this patch: Index: sys/fs/fifofs/fifo_vnops.c === RCS file: /home/ncvs/src/sys/fs/fifofs/fifo_vnops.c,v retrieving revision 1.88 diff -u -r1.88 fifo_vnops.c --- sys/fs/fifofs/fifo_vnops.c 13 Jun 2003 06:58:11 - 1.88 +++ sys/fs/fifofs/fifo_vnops.c 16 Jun 2003 08:44:20 - [...] Yes! This seems to work fine :) qmail-send doesn't increase cpu usage after the first mail anymore. Thanks a lot, Thanks for doing the testing. I just committed this patch. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
On 16 Jun, Jesse Guardiani wrote: I run qmail on my 4.8 servers. For my sanity, is this a problem in 5.1-RELEASE, or in code after 5.1-RELEASE? We haven't upgraded to 5.1 yet (and don't intend to for a while), but I thought I'd ask since this bug would cripple our mail server. It was broken in 5.1-CURRENT shortly after 5.1-RELEASE, until I committed a patch a few minutes ago. 5.1-RELEASE is fine. The problematic versions of fifo_vnops.c are 1.87 and 1.88. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Need acpi-event-d?
On Monday 16 June 2003 09:09 am, Barney Wolff wrote: man psm Set the HOOKRESUME and INITAFTERSUSPEND flags in /boot/device.hints. Works for me on a Dell I5000. Not here (Toshiba Satellite 1605 -- really a branded Compal). It works if I don't use moused, however. I suspect the problem here is with moused, but haven't had time to tear it open (I suddenly got employed). Not sure if David's seeing the same symptoms, exactly. -Cliff L. Biffle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
On 16 Jun, Bruce Evans wrote: On Mon, 16 Jun 2003, Don Lewis wrote: On 16 Jun, Bruce Evans wrote: In my review of 1.87, I forgot to ask you how atomic the close is with part of it moved out to fifo_inactive(). I think it's important that all traces of the old open have gone away (as far as applications can tell) when the last close returns. I hadn't taken queued data into consideration. Now that I've looked at this more closely, there are other problems in both the old and new code. If a process calls fcntl(fd, F_SETOWN, ...) on one end of the fifo, that should be undone when that end of the fifo is closed. In the old implementation, that only happens when both ends of the fifo are closed and the sockets are deleted. F_SETOWN (and associated signal delivery) is even more broken than that :-]. This fcntl() should applied to the file (though not just the file descriptor), so its effect should be limited to fd's open in the file instance and go away when all thse are closed. However, F_SETOWN (and associated signal delivery) actually applies to the socket for fifos. It doesn't work quite right for ttys either. F_SETOWN apparently isn't used in ways complicated enough to require it to work right. There is a fundamental architectural problem -- devices and files don't have a list of the descriptors that have them open. That would require putting descriptors on another list (and dealing with the necessary locking), which would also bloat the size of the descriptor structure. Storing the F_SETOWN info there would bloat all descriptors even more rather than the relative handful of device structures that support this feature. Now there are two questions that I can't answer: Why is my analysis of select() and the SS_CANTRCVMORE flag incorrect in 5.1-current with version 1.87 or 1.88 of fifo_vnops.c. I think it is correct, assuming that something writes to the fifo. Writing might be part of synchronization but actually reading the data should not be necessary since the last close must discard the data (POSIX spec). It sure looks to me like SS_CANTRCVMORE is always set when the write end of the fifo is closed, no matter whether the the sockets were freshly allocated by a fifo_open() call on the read end of the fifo, or because the the last writer closed the write end of the fifo. It sure looks like select() should immediately return if this flag is set, but it is not returning ... Alfred changed the semantics for 5.x. I thought that you knew this. I finally gave up resisting this change after a lot of email :-). In 5.x, SS_CANTRCVMORE often has no effect for fifos (it still works normally for sockets). fifo_poll() normally calls soo_poll() with POLLIN converted to POLLINIGNEOF. This causes soo_poll() (sopoll()) to skip the usual SS_CANTRCVMORE check (which is inside soreadable()) and check the watermark instead, so that select() on a fifo normally waits for data even when the fifo is open in nonblocking mode and SS_CANTRCVMORE is set. Nope, I didn't know this, and I missed the POLLIN-POLLINIGNEOF conversion when I was tracing the code. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IBM T30 bluetooth - success
Tobias, I just wanted to let you know that I got the integrated bluetooth device in my IBM T30 to work (yes, I am sending this mail from my T30 via bluetooth via my Ericsson T68i and GPRS cool :) i'm glad you made it working :) Thanks to Pav and Max for all the fabulous work and help! Thanks to Bernd for the usb patch who made this possible! and thank you for your time and help with testing :) max p.s. if you have any problems, questions or suggestions please let us know __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
kld issue for NFS install of FreeBSD 5.1-Release
Hello, sysinstall seems to be broken when the install media is set to NFS : the nfsclient.ko kernel module is not loaded, and the mount_nfs server:/share /dist command fails. one workaround is to forcibly load the kernel module from the loader.rc file (I did it for a PXE/netboot install). TfH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
CTM - any users left?
Hi all Last time I looked, we had _very_ few CTM users. Is there any reason that the CTM stuff should not be a port? M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-CURRENT hangs on disk i/o? sysctl_old_user()non-sleepable locks
On 16 Jun, Chris Shenton wrote: (I don't know if this has any relation to the problems I reported yesterday with qmail-send consuming 100% cpu after 5.0 to 5.1 upgrade.) I doubt it. I checked in a fix for this problem today so you should get the fix when you next cvsup. After booting 5.1-CURRENT the system runs fine for a while. Then later most disk i/o related actions seem to hang. E.g., system works but when cron kicks off a glimpseindex in the middle of the night, the system is useless by the morning. If I login on the console as me, it takes my username and password then hangs (trying to run /usr/local/bin/bash?). If I do this as root, I do get a shell (/bin/csh). After a point, asking for top will hang, even as root. Even a reboot hung this morning with nothing in the logs. Can you break into ddb and do a ps to find out what state all the processes are in? You might want to try adding the DEBUG_VFS_LOCKS options to your kernel config to see if that turns up anything. There is also ddb command to list the locked vnodes show lockedvnods. Are you using nullfs or unionfs which are a bit fragile? The system has become almost unusable because of this, requiring frequent reboots or hardware resets. Sometimes when I do something as simple as ps I see this ominous message on the console: sysctl_old_user() with the following non-sleepablelocks held: exclusive sleep mutex process lock r = 0 (0xc50bc9e0) locked @ /usr/src/sys/kern/kern_proc.c:258 which gets into /var/log/messages as: Jun 16 08:33:48 PECTOPAH kernel: exclusive sleep mutex process lock r = 0 (0xc50c7618) locked @ /usr/src/sys/kern/kern_proc.c:258 There are a bunch of these. I've been seeing this for about the last week, I think. It seems to be harmless and nothing bad has happened to my -current box. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE nice bugs are fixed.
On Fri, Apr 11, 2003 at 04:40:17PM -0400, Jeff Roberson wrote:
On Fri, 11 Apr 2003, Steve Kargl wrote:
I started to recompile the kernel and while sitting here decided
to load linux-mozilla. The system rebooted before linux-mozilla
displayed a window. I'm not sure this ULE related.
Whoops. The system just panic after coming back up from
a linux-mozilla induce reboot. I've left the machine
at the db prompt.
Here's a hand transcribed backtrace.
panic: Negative nice count.
Stack backtrace
bactrace
panic
kseq_nice_rem
kseq_rem
sched_switchout
mi_switch
msleep
g_io_schedule_down
g_down_procbody
fork_exit
fork_trampoline
In ddb please type 'call kseq_print(0)' This is on UP right?
I'm seeing quite similar panic, when I do renice to lower (negative) value:
(Negative nice count.)
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:240
#1 0xc018b374 in boot (howto=260) at ../../../kern/kern_shutdown.c:372
#2 0xc018b6aa in panic () at ../../../kern/kern_shutdown.c:545
#3 0xc01926a3 in mi_switch () at ../../../kern/kern_synch.c:481
#4 0xc018b022 in boot (howto=256) at ../../../kern/kern_shutdown.c:312
#5 0xc018b6aa in panic () at ../../../kern/kern_shutdown.c:545
#6 0xc019dbe8 in kseq_nice_rem (kseq=0xc0312be0, nice=-10) at
../../../kern/sched_ule.c:324
#7 0xc019e2b5 in sched_nice (kg=0xfff6, nice=-20) at ../../../kern/sched_ule.c:809
#8 0xc0188eac in donice (td=0xc25fc850, p=0xc26c0790, n=-20) at
../../../kern/kern_resource.c:296
#9 0xc0188b43 in setpriority (td=0xc25fc850, uap=0xcdd65d14) at
../../../kern/kern_resource.c:205
#10 0xc0298b11 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 87, tf_esi = -10, tf_ebp =
-1077937064, tf_isp = -841589388, tf_ebx = -20, tf_edx = 0, tf_ecx = -1077937080,
tf_eax = 96, tf_trapno = 12, tf_err = 2, tf_eip = 671874691, tf_cs = 31, tf_eflags =
659, tf_esp = -1077937108, tf_ss = 47}) at ../../../i386/i386/trap.c:1023
#11 0xc0288d9d in Xint0x80_syscall () at {standard input}:138
---Can't read userspace from dump, or kernel process---
The sources are from today. I also noticed, that 5.1-BETA (build around 9th of
May) is working correctly.
Also: I've noticed a strange behaviour - if I do nice -n -15 some_prog, it
will get a nice of -10, and similiar with any other nice values (it +5 from
what it suposed to be).
Cheers,
Wiktor Niesiobedzki
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CTM - any users left?
I forwarded Mark's article with changed headers: as it seems to me ctm-users@ would be more interested/ affected. From To: [EMAIL PROTECTED] From: Mark Murray [EMAIL PROTECTED] To To: [EMAIL PROTECTED] cc: Mark Murray [EMAIL PROTECTED] bcc: [EMAIL PROTECTED] Mark Murray wrote: Hi all Last time I looked, we had _very_ few CTM users. Is there any reason that the CTM stuff should not be a port? M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] - Julian Stacey Freelance Systems Engineer, Unix Net Consultant, Munich. Ihr Rauchen = mein allergischer Kopfschmerz ! Schnupftabak probieren. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IBM T30 bluetooth - success
I can second that success. Any chance of getting this patch checked in?
thanks,
nomad
Controller /dev/usb2:
addr 1: full speed, self powered, config 1, UHCI root hub(0x),
Intel(0x), rev 1.00
uhub2
port 1 addr 2: full speed, power 200 mA, config 1, IBM Integrated
Bluetooth(0x0310), TDK(0x04bf), rev 1.15
ubt0
port 2 powered
Index: usb_subr.c
===
RCS file: /home/ncvs/src/sys/dev/usb/usb_subr.c,v
retrieving revision 1.54
diff -u -r1.54 usb_subr.c
--- usb_subr.c14 Jan 2003 23:07:43 - 1.54
+++ usb_subr.c14 Jun 2003 16:01:38 -
@@ -964,6 +964,7 @@
usbd_device_handle dev;
struct usbd_device *hub;
usb_device_descriptor_t *dd;
+ usb_port_status_t ps;
usbd_status err;
int addr;
int i;
@@ -1020,12 +1021,14 @@
up-device = dev;
dd = dev-ddesc;
/* Try a few times in case the device is slow (i.e. outside specs.) */
- for (i = 0; i 3; i++) {
+ for (i = 0; i 15; i++) {
/* Get the first 8 bytes of the device descriptor. */
err = usbd_get_desc(dev, UDESC_DEVICE, 0, USB_MAX_IPACKET, dd);
if (!err)
break;
usbd_delay_ms(dev, 200);
+ if ((i 3) == 3)
+ usbd_reset_port(up-parent, port, ps);
}
if (err) {
DPRINTFN(-1, (usbd_new_device: addr=%d, getting first desc
nomad
--- - Lee nomad Damon - \
play: [EMAIL PROTECTED]or castle!nomad \
work: [EMAIL PROTECTED] \
/\
Seneschal, Castle PAUS./ \
Celebrate Diversity /\
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
-E flag in /etc/rc.d/ipfilter causes warnings
Hello there, I recently ran into a slight issue with ipfilter running on 5.1-RELEASE. My machine serves the simple purpose as a nat gateway, so ipfilter is always going to be necessary on it. Due to this fact, i decided to include options IPFILTER in the kernel config, instead of dynamically loading the ipl.ko module. However, when ipfilter is used in the kernel image, it's automatically initialized (and thus does not need the -E flag). This has been noted in rc.conf for some time, and I of course removed the -E from the ipfilter_flags variable in that file. However, after booting my kernel with the IPFILTER options, I noticed warnings in my kernel logs that ipfilter has already been initialized, which is consistent with using flag -E when ipf is already initialized. After some brief analysis, I discovered that /etc/rc.d/ipfilter actually uses -E in the shell script function, ipfilter_start(). After removing the two instances of the -E and rebooting, the warning messages disappeared at boot time. Is this a known glitch in the hopes that people start soley using the ipl kernel module? It's really not a big deal either way, but I was more just curious than anything in which direction it's going. Thanks in advance! -- Mike Bohan [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
5.1-R: rcNG - 'mountall' missing?
Hi all, I just upgraded a couple of my systems to 5.1-REL and have been exploring the new stuff ever since. First off, I'd like to extend a big thanks to the rcNG people - well done, this is so much nicer/better/flexible than the old system! :) Then on to the question: there appears to be a number of scripts missing from /etc/rc.d, as is very noticeable when running rcorder(8) on them. Particularly the 'mountall' script is depended on by a number of other scripts. I had a quick look at what 'mountall' looks like on a NetBSD box I have access to, and it basically just issues a (u)mount -a. Is there a good reason why we don't have mountall? Are all avenues really covered by the mountcrit scripts? There is of course a specific reason why I'm interested in mountall, but more about that later... Cheers, /Johny ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-R: rcNG - 'mountall' missing?
On Tue, 17 Jun 2003 12:16:53 +1000 Johny Mattsson [EMAIL PROTECTED] wrote: Is there a good reason why we don't have mountall? Are all avenues really covered by the mountcrit scripts? This stems from the fact that the way we handle filesystems is different from the way NetBSD handles it. For our purposes, we need one pass to mount local filesystems and a second one to mount remote ones. IIRC NetBSD requires that users specify their file systems in rc.conf. This might be useful to have on FreeBSD, as long as it's strictly optional, but I don't have the time or interest to work on it. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - The Power To Serve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: -E flag in /etc/rc.d/ipfilter causes warnings
On 16 Jun 2003 21:35:44 -0400 Mike Bohan [EMAIL PROTECTED] wrote: Hello there, I recently ran into a slight issue with ipfilter running on 5.1-RELEASE. My machine serves the simple purpose as a nat gateway, so ipfilter is always going to be necessary on it. Due to this fact, i decided to include options IPFILTER in the kernel config, instead of dynamically loading the ipl.ko module. However, when ipfilter is used in the kernel image, it's automatically initialized (and thus does not need the -E flag). hmm... I thought it was the other way around (it's not effective when loaded as a module), but I may have misunderstood the man page. This has been noted in rc.conf for some time, and I of course removed the -E from the ipfilter_flags variable in that file. However, after booting my kernel with the IPFILTER options, I noticed warnings in my kernel logs that ipfilter has already been initialized, which is consistent with using flag -E when ipf is already initialized. After some brief analysis, I discovered that /etc/rc.d/ipfilter actually uses -E in the shell script function, ipfilter_start(). After removing the two instances of the -E and rebooting, the warning messages disappeared at boot time. Is this a known glitch in the hopes that people start soley using the ipl kernel module? It's really not a big deal either way, but I was more just curious than anything in which direction it's going. Thanks in advance! I believe it's harmless, and while not aesthetically pleasing, it's a necessary work-around. The stop command to rc.d/ipfilter uses -D to disable ipfilter, so it's necessary to use -E with the start command because there's no way to know how/when/why/in-what-environment it's being called. If I'm wrong or you have a better alternative to this please let me know. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - The Power To Serve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LG 5350 cell phone
Should this get a new vendor entry in usbdevs? --- Josef Karthauser [EMAIL PROTECTED] wrote: On Wed, Jun 11, 2003 at 01:05:00PM -0500, Sean Welch wrote: I have this phone myself. I have two adapters for it -- one is a serial cable the other a true (as in no serial to usb conversion box in the middle) usb cable. The phone works great under FreeBSD on the serial cable (normal Hayes modem type at commands work fine), but no version of FreeBSD has worked with the usb cable so far. I tried 4.8, 5.0-RELEASE, and a few versions of 5.x-CURRENT. The phone is quite usable from my iBook so the cable isn't the issue (the iBook reports it as a Qualcomm -- which is what the sticker says too). I see the message you do, but when I try to use umodem with it the phone continuously reboots itself until detached. I tried something along the lines of what you did to usbdevs a while back but didn't get any improvement. The connection is appreciably faster over the usb port with the true cable when compared to the serial cable; it would be very nice to use it this way on FreeBSD... Sean Maybe the phone doesn't identify itself as a usb modem class, instead relying on a vendor driver. An easy project for someone would be to write a general usb querying tool for displaying the classes, etc that a usb device supports. I've got code kicking around, mostly from Nick Hibma, but I never got around to finishing it off. Joe -- Josef Karthauser ([EMAIL PROTECTED]) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ An eclectic mix of fact and theory. = __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: -E flag in /etc/rc.d/ipfilter causes warnings
That's actually how I interpreted the man page too (the way you did), but rc.conf says the inverse, and my testing corresponds to this as well... ipfilter_flags= # should be *empty* when ipf is _not_ a module # (i.e. compiled into the kernel) to # avoid a warning about already initialized I agree there's no easy solution with the rc.d start/stop functionality. I'll let the list know if I come up with an alternate method. -- Mike Bohan [EMAIL PROTECTED] On Mon, 2003-06-16 at 22:39, Mike Makonnen wrote: On 16 Jun 2003 21:35:44 -0400 Mike Bohan [EMAIL PROTECTED] wrote: Hello there, I recently ran into a slight issue with ipfilter running on 5.1-RELEASE. My machine serves the simple purpose as a nat gateway, so ipfilter is always going to be necessary on it. Due to this fact, i decided to include options IPFILTER in the kernel config, instead of dynamically loading the ipl.ko module. However, when ipfilter is used in the kernel image, it's automatically initialized (and thus does not need the -E flag). hmm... I thought it was the other way around (it's not effective when loaded as a module), but I may have misunderstood the man page. This has been noted in rc.conf for some time, and I of course removed the -E from the ipfilter_flags variable in that file. However, after booting my kernel with the IPFILTER options, I noticed warnings in my kernel logs that ipfilter has already been initialized, which is consistent with using flag -E when ipf is already initialized. After some brief analysis, I discovered that /etc/rc.d/ipfilter actually uses -E in the shell script function, ipfilter_start(). After removing the two instances of the -E and rebooting, the warning messages disappeared at boot time. Is this a known glitch in the hopes that people start soley using the ipl kernel module? It's really not a big deal either way, but I was more just curious than anything in which direction it's going. Thanks in advance! I believe it's harmless, and while not aesthetically pleasing, it's a necessary work-around. The stop command to rc.d/ipfilter uses -D to disable ipfilter, so it's necessary to use -E with the start command because there's no way to know how/when/why/in-what-environment it's being called. If I'm wrong or you have a better alternative to this please let me know. Cheers. signature.asc Description: This is a digitally signed message part
Re: 5.1-R: rcNG - 'mountall' missing?
Mike Makonnen wrote: This stems from the fact that the way we handle filesystems is different from the way NetBSD handles it. For our purposes, we need one pass to mount local filesystems and a second one to mount remote ones. Ah, okay. I haven't actually been root on a NetBSD box, so I'm not too familiar with that side of the fence I'm afraid. Now, to (maybe) throw a spanner in the works, I'm currently working on a couple of scripts to allow the handling of md(4) based filesystems at boot time. Personally I have a need for vnode type file systems, but I'm making it so that malloc/swap filesystems are also handled (e.g. for /tmp). The issue that arises from this support is that I can't safely have the md devices attach before all the file systems are mounted since I don't know on which fs any vnode backing files reside on (and I don't want to have to do a two-pass; one for malloc/swap and one for vnode). It could potentially be a case where you want/need to attach to a file that's on a remote system (via nfs or even smb perhaps). From my scripts' point of view this isn't too bad, as I can just depend on 'mountall' (or so I think at least), but in doing so I'm perverting the meaning of 'mountall', as not all filesystems will be mounted by then. I'm not sure what the best approach would be, so I'd like some feedback on this. Would it be acceptable to introduce another dummy target (like FILESYSTEMS)? From a purely FreeBSD perspective I would probably find this the cleanest, but I know we need to play nice with NetBSD too (do they have anything like md or vn?) so that might stuff things up. I'm really open to suggestions here, and if there isn't any interest in getting md boot-time support into the baseline I'm happy to keep it as a set of local patches, but I suspected that if I write it in such a way that a swap backed /tmp is possible to achieve with a simple rc.conf tweak and a supporting file, then that might be something a number of people would be interested in. I'll post a patch set in a day or two when I've tuned the scripts a bit more (hopefully in response to feedback). IIRC NetBSD requires that users specify their file systems in rc.conf. This might be useful to have on FreeBSD, as long as it's strictly optional, but I don't have the time or interest to work on it. Interesting, but nothing I'd find useful either at the moment, so I'll pass on that task :) Cheers, /Johny ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LG 5350 cell phone
--- Josef Karthauser [EMAIL PROTECTED] wrote: An easy project for someone would be to write a general usb querying tool for displaying the classes, etc that a usb device supports. I've got code kicking around, mostly from Nick Hibma, but I never got around to finishing it off. There's usb_dump on Nick's site: http://www.etla.net/~n_hibma/usb/usb_dump.c The identifiers have been renamed, so it needs a patch http://users.erols.com/eaja/fbsd/usb_dump.diff usb_dump -D -f /dev/ugen0 will dump device, configuration, interface, and endpoint descriptors for ugen0. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IBM T30 bluetooth - success
On Mon, Jun 16, 2003 at 04:31:25PM -0700, Lee Damon wrote: I can second that success. Any chance of getting this patch checked in? I just wait on a review. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
