Re: pam_opieaccess breaks world
Is there an #include sys/types.h missing in pam_opieaccess.c? Yes. Added now. Thanks! M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/sys acct.h acl.h bio.h buf.h callout.hconf.h cons.h disk.h disklabel.h diskslice.h domain.h errno.h event.heventhandler.h exec.h fcntl.h file.h filedesc.h imgact.h imgact_aout.himgact_elf.h inflate.h interrupt.h ioccom.h ipc.h ...
In message: [EMAIL PROTECTED] [EMAIL PROTECTED] (Nickolay Dudorov) writes: : In article [EMAIL PROTECTED] : Alfred Perlstein [EMAIL PROTECTED] wrote: : alfred 2002/03/19 12:18:46 PST : : Modified files: : sys/sys acct.h acl.h bio.h buf.h callout.h conf.h : cons.h disk.h disklabel.h diskslice.h : domain.h errno.h event.h eventhandler.h : exec.h fcntl.h file.h filedesc.h imgact.h : imgact_aout.h imgact_elf.h inflate.h : interrupt.h ioccom.h ipc.h jail.h : kernel.h kthread.h ktrace.h libkern.h : lockf.h lockmgr.h malloc.h md5.h mman.h : mount.h msg.h msgbuf.h namei.h param.h : poll.h proc.h protosw.h queue.h : regression.h resource.h resourcevar.h : rtprio.h selinfo.h sem.h shm.h signal.h : signalvar.h socket.h socketvar.h : soundcard.h stat.h sysctl.h sysent.h : syslog.h sysproto.h systm.h termios.h : time.h timeb.h timepps.h times.h timetc.h : timex.h tty.h types.h uio.h un.h user.h : vnode.h wait.h : Log: : Remove __P : : At least in the case of 'ioccom.h' this commit breaks : the XFree86-server building in the 'drm/kernel' directory. : : The problem is in the '#define ioctl(a,b,c) xf86ioctl(a,b,c)' : which is used by the XFree86 and the __P somehow makes it possible : to build 'xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/xf86drm.c' : and now it stops here. Yes. That's likely the case. I'd kicked off a build of X11 after alfred did these changes, but it died due to lack of disk space before I got to this point and I let the matter sit there for a while. A patch to X11 will be needed. The OpenBSD folks hit this same problem a few days ago when they removed it and committed patches to their repo to fix this problem. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/sys acct.h acl.h bio.h buf.h callout.h conf.h cons.h disk.h disklabel.h diskslice.h domain.h errno.h event.h eventhandler.h exec.h fcntl.h file.h filedesc.h imgact.h imgact_aout.h imgact_elf.h inflate.h interrupt.h ioccom.h ipc.h ...
On Fri, Mar 22, 2002 at 06:50:55AM -0700, M. Warner Losh wrote: : At least in the case of 'ioccom.h' this commit breaks : the XFree86-server building in the 'drm/kernel' directory. : : The problem is in the '#define ioctl(a,b,c) xf86ioctl(a,b,c)' : which is used by the XFree86 and the __P somehow makes it possible : to build 'xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/xf86drm.c' : and now it stops here. Yes. That's likely the case. I'd kicked off a build of X11 after alfred did these changes, but it died due to lack of disk space before I got to this point and I let the matter sit there for a while. A patch to X11 will be needed. The OpenBSD folks hit this same problem a few days ago when they removed it and committed patches to their repo to fix this problem. Please send it to me as soon as you figure out what it should be and I'll speed it to the tree w/ other patches I have. Please try to make a patch that also works on -stable. Regards, -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
if_dc broken in -current
It's been quite a while since I updated my -current box, but when I did, I was surprised to find that my DE500 network card (21143 chip) had stopped working. The switch showed no link. Ifconfig showed no carrier. After some fiddling, I reverted revision 1.56 (removal of mii_pollstat call) of sys/pci/if_dc.c and the DE500 went back to normal. It auto-negotiated 100Mbit full duplex, and now works fine. I expect the problem is actually in mii/dcphy.c but since I have very little understand of how this mii stuff is supposed to work, I have to leave that to others. If no one is available to give me a hand here, I'll have to go with plan B which is to simply back out rev 1.56 of if_dc.c. (That's not such a bad plan really, just slightly inefficient.) On a different dc driver note, I'm interested in knowing if anyone is using either a PNIC or Davicom with -current. There is a slight difference between -current and -stable, and the code in -current caused problems with PNIC and Davicom cards when it was briefly in -stable. I'm assuming that nobody is using such cards, and the little bit of code is going to annoy a few people when they try the 5.0 prerelease. I'd like to fix this before it causes too much trouble. For those who are curious, the troublesome piece of code is lines 1339 and 1340 (in rev 1.69): if (isr DC_ISR_TX_IDLE (isr DC_ISR_RX_STATE) == DC_RXSTATE_STOPPED) which waits for confirmation that the transmitter and receiver are both idle before some configuration registers are fiddled with. With PNIC and Davicom cards, one or the other of these conditions never occurs. Or at least that was the trouble when this was in -stable, back in August. Could this problem have magically gone away? Stephen. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: XFree86-4.2.0 ioctl question [-current ioccom.h __P related]
On Fri, Mar 22, 2002 at 01:01:57AM -0600, Eric Liedtke wrote: While trying to build the XFree86-4-Server port this evening(cvsuped today around 1PM CST) the build died due to a redefinition of xf86ioctl. The file /usr/ports/x11-servers/XFree86-4-Server/work/xc/programs/Xserver/include/xf86_ansic.h Yes, this is a problem recently identified on the -current mailing list that someone else is looking into. When they have a patch, I will integrate it ASAP. Regards, -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/sys acct.h acl.h bio.h buf.h callout.hconf.h cons.h disk.h disklabel.h diskslice.h domain.h errno.h event.heventhandler.h exec.h fcntl.h file.h filedesc.h imgact.h imgact_aout.himgact_elf.h inflate.h interrupt.h ioccom.h ipc.h ...
In message: [EMAIL PROTECTED] Will Andrews [EMAIL PROTECTED] writes: : On Fri, Mar 22, 2002 at 06:50:55AM -0700, M. Warner Losh wrote: : : At least in the case of 'ioccom.h' this commit breaks : : the XFree86-server building in the 'drm/kernel' directory. : : : : The problem is in the '#define ioctl(a,b,c) xf86ioctl(a,b,c)' : : which is used by the XFree86 and the __P somehow makes it possible : : to build 'xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/xf86drm.c' : : and now it stops here. : : Yes. That's likely the case. I'd kicked off a build of X11 after : alfred did these changes, but it died due to lack of disk space before : I got to this point and I let the matter sit there for a while. : : A patch to X11 will be needed. The OpenBSD folks hit this same : problem a few days ago when they removed it and committed patches to : their repo to fix this problem. : : Please send it to me as soon as you figure out what it should be : and I'll speed it to the tree w/ other patches I have. Please : try to make a patch that also works on -stable. Ummm, I'm not going to be doing patches for X11 for at least a few more days, if then. I don't have the time to do it until sometime next week. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/sys acct.h acl.h bio.h buf.h callout.h conf.h cons.h disk.h disklabel.h diskslice.h domain.h errno.h event.h eventhandler.h exec.h fcntl.h file.h filedesc.h imgact.h imgact_aout.h imgact_elf.h inflate.h interrupt.h ioccom.h ipc.h ...
On Fri, Mar 22, 2002 at 08:28:36AM -0700, M. Warner Losh wrote: Ummm, I'm not going to be doing patches for X11 for at least a few more days, if then. I don't have the time to do it until sometime next week. Well if someone else does it, they need to send me the patch. :) Regards, -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: if_dc broken in -current
On Sat, 23 Mar 2002, Stephen McKay wrote: It's been quite a while since I updated my -current box, but when I did, I was surprised to find that my DE500 network card (21143 chip) had stopped working. The switch showed no link. Ifconfig showed no carrier. I've had the simular problem. Now i have media option set to needed value in ifconfig_dc0 variable. This helped. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cdrecord for ATAPI burners available..
On Tuesday 19 March 2002 14:26, you wrote: For those that have problems with burncd or simply cannot live without, I've put up the source for an ATAPI enabled cdrecord on: ftp://freebsd.dk/pub/ATA/cdrtools-1.10-ATA.tgz Is there a chance that this will find it's way into the ports-collection? Bjarne -- Homepage: http://www.mekanix.dk To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
X11 breakage
I'm building world/X11 this afternoon with the following fix to the X11 problem. It isn't so much of a fix as a tactical retreat until a real fix can happen. Warner Index: ioccom.h === RCS file: /cache/ncvs/src/sys/sys/ioccom.h,v retrieving revision 1.10 diff -u -r1.10 ioccom.h --- ioccom.h19 Mar 2002 20:18:36 - 1.10 +++ ioccom.h22 Mar 2002 16:56:36 - @@ -67,7 +67,7 @@ #include sys/cdefs.h __BEGIN_DECLS -intioctl(int, unsigned long, ...); +intioctl __P((int, unsigned long, ...)); __END_DECLS #endif To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
world broke, patch
I think this patch unbreaks world. Index: pam_opieaccess/pam_opieaccess.c === RCS file: /home/ncvs/src/lib/libpam/modules/pam_opieaccess/pam_opieaccess.c,v retrieving revision 1.7 diff -u -r1.7 pam_opieaccess.c --- pam_opieaccess/pam_opieaccess.c 14 Mar 2002 23:27:58 - 1.7 +++ pam_opieaccess/pam_opieaccess.c 22 Mar 2002 17:29:20 - @@ -39,6 +39,7 @@ #define _BSD_SOURCE +#include sys/types.h #include opie.h #include pwd.h #include unistd.h -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Peculiar(?) slowdown with -CURRENT as of 21 March
On a 0 - 10 weirdness scale, this ranks about a 4, perhaps, so it's hardly earth-shattering. But it's odd enough that I thought that a small reality check might be in order, in case the effect(s) in question were not expected. (And yes, I understand that a degree of uncertainty with respect to -CURRENT's performance is to be expected, even at the best of times. This is not a complaint.) Briefly, my SMP build machine built today's -CURRENT (while running yesterday's -- hence the Subject:) much more slowly than my laptop did. To illustrate, here are the timestamp messages from the respective kernel builds: Kernel build for FREEBEAST started on Fri Mar 22 07:59:58 PST 2002 Kernel build for FREEBEAST completed on Fri Mar 22 08:24:19 PST 2002 Kernel build for LAPTOP_30W started on Fri Mar 22 08:09:25 PST 2002 Kernel build for LAPTOP_30W completed on Fri Mar 22 08:26:31 PST 2002 So that's not a huge difference in and of itself -- 24:21 vs. 17:06 -- but what really stands out is that the laptop actually finished the whole morning's processing before the build machine did. And that's somewhat remarkable, given that: * build machine got a bit of a head start (though it did have a little bit more work to do in one respect). * build machine is 2x866 MHz P3s; laptop is a 750 MHz P3. * laptop disk is 4500 RPM; build machine's disk is probably 5400 -- certainly no slower than that. I don't really want to spam the entire list with the details of the processes used, so I cobbled up a page at http://www.catwhisker.org/~david/FreeBSD/speed.html that should have enough excruciating details for anyone sufficiently interested. Thanks, david -- David H. Wolfskill [EMAIL PROTECTED] I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Peculiar(?) slowdown with -CURRENT as of 21 March
On 22-Mar-2002 David Wolfskill wrote: On a 0 - 10 weirdness scale, this ranks about a 4, perhaps, so it's hardly earth-shattering. But it's odd enough that I thought that a small reality check might be in order, in case the effect(s) in question were not expected. (And yes, I understand that a degree of uncertainty with respect to -CURRENT's performance is to be expected, even at the best of times. This is not a complaint.) Briefly, my SMP build machine built today's -CURRENT (while running yesterday's -- hence the Subject:) much more slowly than my laptop did. To illustrate, here are the timestamp messages from the respective kernel builds: Kernel build for FREEBEAST started on Fri Mar 22 07:59:58 PST 2002 Kernel build for FREEBEAST completed on Fri Mar 22 08:24:19 PST 2002 Kernel build for LAPTOP_30W started on Fri Mar 22 08:09:25 PST 2002 Kernel build for LAPTOP_30W completed on Fri Mar 22 08:26:31 PST 2002 So that's not a huge difference in and of itself -- 24:21 vs. 17:06 -- but what really stands out is that the laptop actually finished the whole morning's processing before the build machine did. And that's somewhat remarkable, given that: * build machine got a bit of a head start (though it did have a little bit more work to do in one respect). * build machine is 2x866 MHz P3s; laptop is a 750 MHz P3. * laptop disk is 4500 RPM; build machine's disk is probably 5400 -- certainly no slower than that. I don't really want to spam the entire list with the details of the processes used, so I cobbled up a page at http://www.catwhisker.org/~david/FreeBSD/speed.html that should have enough excruciating details for anyone sufficiently interested. I saw some similar weirdness in my test machines last night where a dual processor DS20 (Alpha 21264 500x2) beat out a PII Xeon 450x4. Normally the quad xeon beats the DS20. The quad xeon was using -j16 but was about 74% idle. The DS20 had used -j8. I didn't get a chacne to run top to see how it was doing during hte world since I didn't notice the weirdness until last night after the DS20 had finsihed but the quad xeon was still chugging along. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
/dev/MAKEDEV not being installed?
Just did a fresh install of -CURRENT and noticed that MAKEDEV isn't being installed. This intentional? -sc -- Sean Chittenden To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: /dev/MAKEDEV not being installed?
Just did a fresh install of -CURRENT and noticed that MAKEDEV isn't being installed. This intentional? -sc MAKEDEV on -current is not needed, since devfs creates device nodes automatically. Alright, sounds good/believable, but how do I extend the number of pty's on current then? I only see 20 tty* entries in /dev and would like the full 256 like I compiled in. -sc -- Sean Chittenden To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
kernel build breakage on if_wi
Fresh (todays) -current not builds on current machine: vbook#/sys/i386/compile/VBOOK 142_ make kernel-depend make kernel rm -f .olddep if [ -f .depend ]; then mv .depend .olddep; fi make _kernel-depend if [ -f .olddep ]; then mv .olddep .depend; fi rm -f .newdep make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | xargs env MKDEP_CPP=cc -E CC=cc mkdep -a -f .newdep -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -elf -O3 -mpentiumpro -mpreferred-stack-boundary=2 make -V SFILES -V SYSTEM_SFILES | xargs env MKDEP_CPP=cc -E mkdep -a -f .newdep -x assembler-with-cpp -DLOCORE -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -elf -O3 -mpentiumpro -mpreferred-stack-boundary=2 rm -f .depend mv .newdep .depend cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -elf -O3 -mpentiumpro -mpreferred-stack-boundary=2 -Werror ../../../dev/wi/if_wi.c cc1: warnings being treated as errors ../../../dev/wi/if_wi.c: In function `wi_seek': ../../../dev/wi/if_wi.c:1250: warning: `status' might be used uninitialized in this function *** Error code 1 Stop in /usr/local/src/sys/i386/compile/VBOOK. vbook#/sys/i386/compile/VBOOK 143_ kernel config attached Any ideas ? -- SW Soft, Moscow Vladimir B. Grebenschikov, [EMAIL PROTECTED] machine i386 ident VBOOK maxusers256 options INCLUDE_CONFIG_FILE # Include this file in kernel cpu I486_CPU cpu I586_CPU # aka Pentium(tm) cpu I686_CPU # aka Pentium Pro(tm) options COMPAT_43 makeoptions CONF_CFLAGS=-O3 -mpentiumpro #makeoptions CONF_CFLAGS=-fno-builtin #Don't allow use of memcmp, etc. #makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols #makeoptionsKERNEL=foo #Build kernel foo and install /foo #optionsSYSVSHM #optionsSYSVSEM #optionsSYSVMSG options UCONSOLE #optionsUSERCONFIG #boot -c editor #optionsVISUAL_USERCONFIG #visual boot -c editor options INET#Internet communications protocols device ether #Generic Ethernet device loop#Network loopback device device bpf 4 #Berkeley packet filter #device vlan4 device snp 4 #Snoop device - to look at pty/vty/etc.. options PPP_BSDCOMP #PPP BSD-compress support options PPP_DEFLATE #PPP zlib/deflate/gzip support options PPP_FILTER #enable bpf filtering (needs bpfilter) options MROUTING# Multicast routing options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #print information about dropped packets options IPFIREWALL_FORWARD #enable transparent proxy support #optionsIPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity options IPDIVERT#divert sockets options DUMMYNET options FFS #Fast filesystem #optionsNFSSERVER #Network File System - server #optionsNFSCLIENT #Network File System - client # options NFS_NOSERVER#Disable the NFS-server code. options PSEUDOFS options PROCFS #Process filesystem options SOFTUPDATES # Allow this many swap-devices. device scbus #base SCSI code device da #SCSI direct access devices (aka disks) device sa #SCSI tapes device cd #SCSI CD-ROMs device pass#CAM passthrough driver options SCSI_DELAY=2000 device pty 32 #Pseudo ttys - can go as high as 256 device speaker #Play IBM BASIC-style noises out your speaker device gzip#Exec gzipped a.out's device md # Memory disks device isa device atkbdc device atkbd 1 device psm device vga device sc options MAXCONS=16
Re: /dev/MAKEDEV not being installed?
In the last episode (Mar 22), Sean Chittenden said: Just did a fresh install of -CURRENT and noticed that MAKEDEV isn't being installed. This intentional? -sc MAKEDEV on -current is not needed, since devfs creates device nodes automatically. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel build breakage on if_wi
On 22:14+0300, Mar 22, 2002, Vladimir B. Grebenschikov wrote: Fresh (todays) -current not builds on current machine: vbook#/sys/i386/compile/VBOOK 142_ make kernel-depend make kernel rm -f .olddep if [ -f .depend ]; then mv .depend .olddep; fi make _kernel-depend if [ -f .olddep ]; then mv .olddep .depend; fi rm -f .newdep make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | xargs env MKDEP_CPP=cc -E CC=cc mkdep -a -f .newdep -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -elf -O3 -mpentiumpro -mpreferred-stack-boundary=2 make -V SFILES -V SYSTEM_SFILES | xargs env MKDEP_CPP=cc -E mkdep -a -f .newdep -x assembler-with-cpp -DLOCORE -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -elf -O3 -mpentiumpro -mpreferred-stack-boundary=2 rm -f .depend mv .newdep .depend cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -elf -O3 -mpentiumpro -mpreferred-stack-boundary=2 -Werror ../../../dev/wi/if_wi.c cc1: warnings being treated as errors ../../../dev/wi/if_wi.c: In function `wi_seek': ../../../dev/wi/if_wi.c:1250: warning: `status' might be used uninitialized in this function *** Error code 1 Did you read 20020225: Warnings are now errors in the kernel. Unless you are a developer, you should add -DNO_WERROR to your make line. in UPDATING? Stop in /usr/local/src/sys/i386/compile/VBOOK. vbook#/sys/i386/compile/VBOOK 143_ kernel config attached Any ideas ? -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel build breakage on if_wi
On Fri, 2002-03-22 at 22:27, Maxim Konovalov wrote: Fresh (todays) -current not builds on current machine: ... Did you read 20020225: Warnings are now errors in the kernel. Unless you are a developer, you should add -DNO_WERROR to your make line. No, It seems I have miss HEADS UP message Anyway thank you Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] -- SW Soft, Moscow Vladimir B. Grebenschikov, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Peculiar(?) slowdown with -CURRENT as of 21 March
On Fri, 22 Mar 2002, David Wolfskill wrote: On a 0 - 10 weirdness scale, this ranks about a 4, perhaps, so it's hardly earth-shattering. But it's odd enough that I thought that a small reality check might be in order, in case the effect(s) in question were not expected. (And yes, I understand that a degree of uncertainty with respect to -CURRENT's performance is to be expected, even at the best of times. This is not a complaint.) Could be the removal of __P :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: /dev/MAKEDEV not being installed?
On Fri, 22 Mar 2002, Sean Chittenden wrote: Just did a fresh install of -CURRENT and noticed that MAKEDEV isn't being installed. This intentional? -sc MAKEDEV on -current is not needed, since devfs creates device nodes automatically. Alright, sounds good/believable, but how do I extend the number of pty's on current then? I only see 20 tty* entries in /dev and would like the full 256 like I compiled in. -sc New entries should clone themselves as needed, up to the precompiled limit. If this is not happening, it's a bug. :-) You can test this by sequentially opening /dev/ptty(n) entries and watch matching ttyp/r/q/s entries appear. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: world broke, patch
Alfred Perlstein [EMAIL PROTECTED] writes: I think this patch unbreaks world. Mark, not me. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Peculiar(?) slowdown with -CURRENT as of 21 March
Robert Watson wrote: On a 0 - 10 weirdness scale, this ranks about a 4, perhaps, so it's hardly earth-shattering. But it's odd enough that I thought that a small reality check might be in order, in case the effect(s) in question were not expected. (And yes, I understand that a degree of uncertainty with respect to -CURRENT's performance is to be expected, even at the best of times. This is not a complaint.) Could be the removal of __P :-) Speed difference between KR and ANSI compilers? 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: X11 breakage
On Fri, 22 Mar 2002, Garrett Wollman wrote: On Fri, 22 Mar 2002 10:08:05 -0700 (MST), M. Warner Losh [EMAIL PROTECTED] said: -intioctl(int, unsigned long, ...); +intioctl __P((int, unsigned long, ...)); int (ioctl)(int, unsigned long, ...); is the ISO-sanctioned way. It is just a more robust hack when used in system headers: #define ioctl you lose #include sys/ioctl.h gives undefined behaviour which happens to break both of the above. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Look at These Great Toner Cartridge Prices!!
D J Printing Corporation 2564 Cochise Drive Acworth, GA 30102 (V)770-974-8228 (F)770-974-7223 [EMAIL PROTECTED] *WE ACCEPT GOVERNMENT, SCHOOL AND UNIVERSITY PURCHASE ORDERS* --LASER, FAX AND COPIER PRINTER TONER CARTRIDGES-- *WE ACCEPT GOVERNMENT, SCHOOL AND UNIVERSITY PURCHASE ORDERS* ***FREE SHIPPING WITH ANY ORDER OF $200 OR MORE!!!*** APPLE LASER WRITER SELECT 300/310/360 $60 LASER WRITER PRO 600/630 OR 16/600$60 LASER WRITER 300/320 OR 4/600 $45 LASER WRITER LS/NT/NTR/SC $50 LASER WRITER 2NT/2NTX/2SC/2F/2G $50 LASER WRITER 12/640$60 HEWLETT PACKARD LASERJET SERIES 1200 (C7115A) $40 LASERJET SERIES 4100X/4100A (C8061A/X)$99 LASERJET SERIES 1100/1100A (C4092A) $40 LASERJET SERIES 2100/SE/XI/M/TN (C4096A) $70 LASERJET SERIES 2/2D/3/3D (92295A)$43 LASERJET SERIES 2P/2P+/3P (92275A)$55 LASERJET SERIES 3SI/4SI (92291A)$75 LASERJET SERIES 4/4M/4+/4M+/5/5M/5N (92298A/X)$55 LASERJET SERIES 4L/4ML/4P/4MP (92274A)$40 LASERJET SERIES 4000/T/N/TN (C4127A/X-H YLD) $70 LASERJET SERIES 4V/4MV (C3900A) $80 LASERJET SERIES 5000 (C4129X)$95 LASERJET SERIES 5L/6L (C3906A)$39 LASERJET SERIES 5P/5MP/6P/6MP (C3903A)$50 LASERJET SERIES 5SI/5SI MX/5SI MOPIER/8000(C3909A/X) $80 LASERJET SERIES 8100/N/DN ((C4182X) $115 HEWLETT PACKARD LASERFAX LASERFAX 500/700, FX1 $50 LASERFAX 5000/7000, FX2 $65 LASERFAX FX3 $60 LASERFAX FX4 $65 LEXMARK E312L, E310 - (13T0101 HIGH YIELD)$60 OPTRA 4019, 4029 HIGH YIELD $130 OPTRA R, 4039, 4049 HIGH YIELD$125 OPTRA S, 4059 HIGH YIELD $135 OPTRA N $100 OPTRA T 610/612/614 $185 EPSON LASER TONER EPL-7000/7500/8000$95 EPL-1000/1500 $95 EPSON INK JET STYLUS COLOR 440/640/740/760/860 (COLOR) $20 STYLUS COLOR 740/760/860 (BLACK) $20 CANON LBP-430 $45 LBP-460/465 $55 LBP-8 II $50 LBP-LX$54 LBP-NX$90 LBP-AX$49 LBP-EX$59 LBP-SX$49 LBP-BX$90 LBP-PX$49 LBP-WX$90 LBP-VX$59 CANON FAX L700 THRU L790 (FX1)$55 CANON FAX L5000 THRU L7500 (FX2) $65 CANON LASERCLASS 4000/4500/300 (FX3) $60 CANON LASERCLASS 8500 THRU 9800 (FX4) $65 CANON COPIERS PC 1/2/3/6/6RE/7/8/11/12/65 (A30) $69 PC 210 THRU 780 (E40/E31) $80 PC 300/400 (E20/E16) $80 NEC SERIES 2 LASER MODEL 90/95$100 ***FREE SHIPPING WITH ANY ORDER OF $200 OR MORE!!!*** PLEASE NOTE: * ALL OF OUR PRICES ARE IN US DOLLARS * PRICES SUBJECT TO CHANGE WITHOUT NOTICE * WE SHIP UPS GROUND. ADD $6.50 FOR SHIPPING AND HANDLING * SHIPPING COST IS MORE FOR AK AND COUNTRIES OTHER THAN THE USA * WE ACCEPT ALL MAJOR CREDIT CARDS OR COD ORDERS. * COD CHECK ORDERS ADD $3.50 TO YOUR SHIPPING COST. * OUR STANDARD MERCHANDISE REPLACEMENT POLICY IS NET 90 DAYS. * WE DO NOT SELL TO RESELLERS OR BUY FROM DISTRIBUTERS. * WE DO NOT CARRY: BROTHER, MINOLTA, KYOSERA, PANASONIC, XEROX, FUJITSU, OKIDATA OR SHARP PRODUCTS. * WE ALSO DO NOT CARRY: DESKJET OR BUBBLEJET SUPPLIES. * WE DO NOT BUY FROM OR SELL TO RECYCLERS OR REMANUFACTURERS. -PLACE YOUR ORDER AS
Peculiar(?) slowdown with -CURRENT as of 21 March
I saw some similar weirdness in my test machines last night where a dual processor DS20 (Alpha 21264 500x2) beat out a PII Xeon 450x4. Normally the quad xeon beats the DS20. The quad xeon was using -j16 but was about 74% idle. The DS20 had used -j8. I didn't get a chacne to run top to see how it was doing during hte world since I didn't notice the weirdness until last night after the DS20 had finsihed but the quad xeon was still chugging along. Are you both running with WITNESS and INVARIANTS? UMA is slightly slower with these options on than the original malloc vm_zone code. I'm not sure why it would be even worse for SMP machines though. So maybe it isn't UMA at all but it's worth looking into. Thanks, Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Peculiar(?) slowdown with -CURRENT as of 21 March
Date: Fri, 22 Mar 2002 20:43:03 -0500 (EST) From: Jeff Roberson [EMAIL PROTECTED] Are you both running with WITNESS and INVARIANTS? UMA is slightly slower with these options on than the original malloc vm_zone code. I'm not sure why it would be even worse for SMP machines though. So maybe it isn't UMA at all but it's worth looking into. I don't speak (or write) for John, but yes, I have both WITNESS INVARIANTS in my -CURRENT kernels. (The link I posted refers to a page that has copies of each kernel config, among other bits of trivia.) Reason I posted about it is because the result was at such variance with my previous experience and expectations, after all :-) And one of the reasons for my surprise is that the (SMP) build machine has usually been quite a bit faster... and the kernel configurations are about as similar to each other as makes any sort of sense, given the differences in the hardware. If anything, I'd expect the laptop to be a bit more sluggish if only because it has the usual UI stuff, like sound and an X server (with less memory)... while the only access to the build machine is either SSH or the serial console; it doesn't have a keyboard or monitor. No speakers, either. :-} Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Peculiar(?) slowdown with -CURRENT as of 21 March
On Fri, Mar 22, 2002 at 06:34:00PM -0800, David Wolfskill wrote: Date: Fri, 22 Mar 2002 20:43:03 -0500 (EST) From: Jeff Roberson [EMAIL PROTECTED] Are you both running with WITNESS and INVARIANTS? UMA is slightly slower with these options on than the original malloc vm_zone code. I'm not sure why it would be even worse for SMP machines though. So maybe it isn't UMA at all but it's worth looking into. I don't speak (or write) for John, but yes, I have both WITNESS INVARIANTS in my -CURRENT kernels. (The link I posted refers to a page that has copies of each kernel config, among other bits of trivia.) As more locks are added to the kernel the overhead of WITNESS becomes greater. 21 March was around the time of Jeff's UMA commit. Kris msg36453/pgp0.pgp Description: PGP signature
Found: module loading breakage
Apologies if you will get this message twice. My ISP seems to be
blocked in hub.freebsd.org so I had to use temporary hotmail account.
I found the reason for crashes I was experiencing ever since UMA has
been committed into -CURRENT. Apparently UMA has nothing to do with the
breakage. The real problem lies in vfs_opv_recalc function from
vfs_ini.c. Then kernel loads dynamic filesystem module, it looks for
any of the VOP operations specified by the new filesystem that have not
been registered already by the currently known filesystems. If any of
such operations exist, vfs_add_vnops function calls vfs_opv_recalc
function, which rebuilds vop_t vectors for each filesystem and sets all
global pointers like ufs_vnops_p, devfs_specop_p, etc to the new values
and then frees the old pointers. This behavior is bad because there
might be already active vnodes whose v_op fields will be left pointing
to the random garbage, leading to inevitable crash soon.
I used the workaround below to get the system booting again, but it
does nothing to solve the real problem. We should probably either update
each and every vnode known to the system with the new v_op pointer when
needed, or simply start allocating vop_t vectors large enough to hold
every vnode operation we know about. Or maybe some VFS guru can
propose a better strategy?
Index: vfs_init.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_init.c,v
retrieving revision 1.57
diff -u -r1.57 vfs_init.c
--- vfs_init.c 20 Mar 2002 04:09:58 - 1.57
+++ vfs_init.c 23 Mar 2002 04:22:00 -
@@ -129,8 +129,10 @@
for (i = 0; i vnodeopv_num; i++) {
opv = vnodeopv_descs[i];
opv_desc_vector_p = opv-opv_desc_vector_p;
+#if 0
if (*opv_desc_vector_p)
FREE(*opv_desc_vector_p, M_VNODE);
+#endif
MALLOC(*opv_desc_vector_p, vop_t **,
vfs_opv_numops * sizeof(vop_t *), M_VNODE,
M_WAITOK | M_ZERO);
_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Dhclient with non-writable /etc/resolv.conf
After having updated to the world past 2002-02-19, dhclient started
very fast cycle of acquiring and releasing leases every time it was
attached to the local network, like it's attacking the DHCP server.
After all, it was /sbin/dhclient-script that failed trying to update
/etc/resolv.conf which had schg turned on (I needed this to prevent
ppp from replacing resolv.conf when my / was mounted read-write,
until I found 'resolv readonly' option in in ppp(1) manual).
The fix below also covers read-only root filesystem case.
--- /usr/src/contrib/isc-dhcp/client/scripts/freebsdThu Mar 21 14:49:53 2002
+++ /usr/src/contrib/isc-dhcp/client/scripts/freebsdThu Mar 21 15:03:53 2002
@@ -9,7 +9,8 @@
fi
make_resolv_conf() {
- if [ x$new_domain_name != x ] [ x$new_domain_name_servers != x ]; then
+ if [ x$new_domain_name != x ] [ x$new_domain_name_servers != x ] \
+[ -w /etc/resolv.conf -o -w /etc -a ! -e /etc/resolv.conf ]; then
echo search $new_domain_name /etc/resolv.conf
for nameserver in $new_domain_name_servers; do
echo nameserver $nameserver /etc/resolv.conf
Regards.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Found: module loading breakage
* Alexander Kabaev [EMAIL PROTECTED] [020322 21:31] wrote: I used the workaround below to get the system booting again, but it does nothing to solve the real problem. We should probably either update each and every vnode known to the system with the new v_op pointer when needed, or simply start allocating vop_t vectors large enough to hold every vnode operation we know about. Or maybe some VFS guru can propose a better strategy? Good work! I was about to say: why don't you just traverse the system wide list of vnodes and fixup the pointers? Then I realized that there doesn't seem to be a system wide list... :( You could add one, it would be trivial to add a TAILQ_ENTRY to the vnode strcture as well as add/remove the nodes from the list in the vnode allocation and deallocation code. Feel ambitious? :) -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Subscribe
Hi, Need to subscribe to the mailing list. Interested in development and helping ot. Ashish Gupta -- / \\ - - // ( @ @ ) -oOOo--(_)-oOOo--- Sincerly yours, Ashish Gupta ---O-- ( ) O ) / ( ) (_/ \ ( \_)
Re: Found: module loading breakage
You could add one, it would be trivial to add a TAILQ_ENTRY to the vnode strcture as well as add/remove the nodes from the list in the vnode allocation and deallocation code. I was thinking about mp-mnt_nvnodelist, unless there are compelling reasons not to trust it. Feel ambitious? :) Feel like reviewing a patch? I will see what I can do on these weekends. -Alfred _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Found: module loading breakage
Alfred Perlstein wrote: Good work! I was about to say: why don't you just traverse the system wide list of vnodes and fixup the pointers? Then I realized that there doesn't seem to be a system wide list... :( You could add one, it would be trivial to add a TAILQ_ENTRY to the vnode strcture as well as add/remove the nodes from the list in the vnode allocation and deallocation code. Feel ambitious? :) Add an indirection, and replace the pointer in the indirection pointer, so that everything just works. It will take a doube-indirection to do. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Found: module loading breakage
Matthew Dillon wrote: Unless I am missing something, vnodes hang off their mount points. So, effectively, there is a system-wide list. The lock on a global traverasl will be pretty ugly... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Found: module loading breakage
* Terry Lambert [EMAIL PROTECTED] [020322 23:13] wrote: Matthew Dillon wrote: Unless I am missing something, vnodes hang off their mount points. So, effectively, there is a system-wide list. The lock on a global traverasl will be pretty ugly... Module loading doesn't occur often. :) -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
SMP ffs_mountfs() broken?
I just cvsupped about an hour ago, built world and built a kernel that was GENERIC with 486/586 turned off and SMP and IOAPIC turned on. It crashed while trying to mount root. Apologies for mistakes in the following since I don't have a serial console and had to write it down: normal da0 SCSI adaptor dmesg output Mounting root from ufs:/dev/ad0s1a SMP AP CPU #1 Launched! kernel trap 12 with interrupts diabled panic: blockable sleep lock (sleep mutex) Giant @ ../../../i386/i386/trap.c:706 cpuid = 1; lapic.id = 0100 Debugger(panic) Stopped at Debugger+0x41: xorl %eax, %eax trace showed the watchdog trap and then: _mtx_lock_sleep _mtx_lock_flags vn_lock spec_open ffs_mountfs ffs_mount ufs_mountroot_try ufs_mountroot start_init fork_exit fork_trampoline (sorry for eliminating all the args and such, but that's a lot of hex numbers to write down by hand -- if anyone requests i'll see what i can do about getting it off the serial port..) I've never had this machine successfully running 5.0 with SMP, this was my first attempt. My machine is: 2 x 1.4GHz K7 MP1600+ 512MB crucial ECC Adaptec 39160 Seagate 36GB drive (not used for my 5.0 box) 13GB IBM UDMA66 drive (5.0 is installed on this) Geforce2/MX Soundblaster I'll try to see if this was due to the cvsup or due to SMP. I've got a UP kernel from a few weeks ago that works fine. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Found: module loading breakage
:* Terry Lambert [EMAIL PROTECTED] [020322 23:13] wrote: : Matthew Dillon wrote: : Unless I am missing something, vnodes hang off their mount points. : So, effectively, there is a system-wide list. : : The lock on a global traverasl will be pretty ugly... : :Module loading doesn't occur often. :) : :-Alfred Yah. It's ugly, but it should't effect general performance. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Found: module loading breakage
Alfred Perlstein wrote: * Terry Lambert [EMAIL PROTECTED] [020322 23:13] wrote: Matthew Dillon wrote: Unless I am missing something, vnodes hang off their mount points. So, effectively, there is a system-wide list. The lock on a global traverasl will be pretty ugly... Module loading doesn't occur often. :) The VOP recalculation is to provide a default for new VOPs that are added. I'm not sure it's really necessary, since it's supposed to default to not impliemented, and the lookup for a given descriptor in the list should always get that, if it can't find a matching descriptor. I had a recalculation in my code from 1996 because I sorted the entries, and then used an absolute index (doing this would dereference memory off the end of the list for new VOPs). FreeBSD doesn't make this optimization, and takes the overhead of unpacking and repacking every descriptor, and then doing an extra dereference. So it shouldn't need it. Did this come in as part of the default_vops stuff, which was not part of the original design? Precalculating the tables makes sense, but there's an easy way around that: Take a page for each instance, and then rewrite the contents as needed. I don't think you can use the optimization anyway, if you want to proxy the VOP's across a network or the user/kernel boundary for user space FS work, but other than that, it's a ggood instance-time optimization (e.g. leave it there, and instance it with the double dereference for the proxy cases). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SMP ffs_mountfs() broken?
GENERIC works, so this looks like an SMP problem. Its happening right after the CPU initializes. This is probably the first SMP code the machine runs? Is hardware incompatibility a good guess? I would have expected that if someone broke ffs_mountfs() that someone else would have noticed by now... Oh, I forgot to say in my previous message that my motherboard is a Asus K7M266D. It runs 4.5-STABLE with SMP turned on fine, but only with MP spec 1.1 and not 1.4. There's a BIOS upgrade which is supposed to fix Linux + MP spec 1.4 issues which might fix 1.4 for FreeBSD as well. It could fix this as well maybe? On Fri, 22 Mar 2002, Lamont Granquist wrote: I'll try to see if this was due to the cvsup or due to SMP. I've got a UP kernel from a few weeks ago that works fine. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
