Re: PATCH for testing
On Mon, Nov 15, 1999 at 05:44:12PM -0800, David Greenman wrote: I agree that we need to get rid of 'e' and any other options that allow reading another process's environment. I think it would be sufficient, to allow only root to use the 'e' option. There is no need to get rid of it entirely. Then other utility would have to go as well (tcpdump, ...). -- Andreas Klemm http://www.FreeBSD.ORG/~andreas http://www.freebsd.org/~fsmp/SMP/SMP.html powered by Symmetric MultiProcessor FreeBSD Get new songs from our band: http://www.freebsd.org/~andreas/64bits/index.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH for testing
On Thu, 18 Nov 1999, Andreas Klemm wrote: On Mon, Nov 15, 1999 at 05:44:12PM -0800, David Greenman wrote: I agree that we need to get rid of 'e' and any other options that allow reading another process's environment. I think it would be sufficient, to allow only root to use the 'e' option. There is no need to get rid of it entirely. Then other utility would have to go as well (tcpdump, ...). Or perhaps restricting -U to root only? Since -e w/out -U isn't harmful, no? - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
MAKEWORLD fails at texinfo
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -I../intl -DLOCALEDIR=\/usr/local/share/locale\ -g -O2 -c makeinfo.c makeinfo.c: In function `xrealloc': makeinfo.c:1205: parse error before `void' makeinfo.c:1209: `exit_value' undeclared (first use this function) makeinfo.c:1209: (Each undeclared identifier is reported only once makeinfo.c:1209: for each function it appears in.) makeinfo.c:1252: parse error before `typedef' makeinfo.c: At top level: makeinfo.c:1254: warning: data definition has no type or storage class makeinfo.c:1259: parse error before `*' makeinfo.c: In function `reverse_list': makeinfo.c:1261: parse error before `*' makeinfo.c:1261: declaration for parameter `GENERIC_LIST' but no such parameter makeinfo.c:1263: syntax error before `*' makeinfo.c:1264: syntax error before `*' makeinfo.c:1268: `next' undeclared (first use this function) makeinfo.c:1268: invalid type argument of `-' makeinfo.c:1269: invalid type argument of `-' makeinfo.c:1269: `prev' undeclared (first use this function) *** Error code 1 this was cvsupped at 7:15 a.m on the 15th using the standard-supfile as found in /usr/share/examples RG To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: MAKEWORLD fails at texinfo
On Fri, 15 Jan 1999 ea...@phc.igs.net wrote: gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -I../intl -DLOCALEDIR=\/usr/local/share/locale\ -g -O2 -c makeinfo.c makeinfo.c: In function `xrealloc': makeinfo.c:1205: parse error before `void' makeinfo.c:1209: `exit_value' undeclared (first use this function) makeinfo.c:1209: (Each undeclared identifier is reported only once makeinfo.c:1209: for each function it appears in.) makeinfo.c:1252: parse error before `typedef' ... snip ... makeinfo.c:1269: invalid type argument of `-' makeinfo.c:1269: `prev' undeclared (first use this function) *** Error code 1 this was cvsupped at 7:15 a.m on the 15th using the standard-supfile as found in /usr/share/examples This is the exact same problem Satoshi already mentioned earlier today ... I am experiencing the exact same thing ... someway makeinfo.c got screwed up .. missing half of the xrealloc-function Pascal Hofstee - dae...@shadowmere.student.utwente.nl -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS d- s+: a-- C++ UB P+ L- E--- W- N+ o? K- w--- O? M V? PS+ PE Y-- PGP-- t+ 5 X-- R tv+ b+ DI D- G e* h+ r- y+ --END GEEK CODE BLOCK-- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
pcm: mixer's synth and cd devices are swapped (Yamaha OPL card)
I have found that the mixer has the volume controls for the synth and cd devices swapped. Strangely, this swap does not affect the recording source selection (mixer =rec cd properly sets the CD as recording device). I have tested this using mixer(8), xmmix and kmix, so the problem resides in the mixer device. This is my hardware configuration (from kernel's boot messages): Probing for PnP devices: CSN 1 Vendor ID: YMH0800 [0x0008a865] Serial 0x Comp ID: PNPb02f [0x2fb0d041] mss_attach Yamaha YMF719 OPL-SA31 at 0xe80 irq 5 dma 0:1 flags 0x11 setting up yamaha registers set yamaha master volume to max pcm1 (CS423x/Yamaha/AD1816 Yamaha YMF719 OPL-SA3 sn 0x) at 0xe80-0xe87 irq 5 drq 0 flags 0x11 on isa I filed a problem report (kern/9487). -- JMA --- José Mª Alcaide | mailto:j...@we.lc.ehu.es Universidad del País Vasco | http://www.we.lc.ehu.es/~jose Dpto. de Electricidad y Electrónica | Facultad de Ciencias - Campus de Lejona | Tel.: +34-946012479 48940 Lejona (Vizcaya) - SPAIN | Fax: +34-944858139 --- Go ahead... make my day. - H. Callahan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Gratuitous name changes (was: libalias and ident)
On Thu, 14 Jan 1999, Brian Somers wrote: : But this isn't necessarily a good idea as it may attract a pile of : ``why the hell did you break my configuration for no good reason'' : messages. : : Anyone with any strong opinions on this ? : : Of course it's not guaranteed that libalias will change to libnat, : there's another thread starting on -hackers about that :-) It's also : possible to change the ppp flag, even if libalias isn't renamed. I winced when I heard that the flag was named -alias in the first place, since aliasing really is a different animal. (At least, that's what they taught *me* in school.) :) I say, if the change can be made before the -STABLE branch, do it. People should expect to rewrite a lot of config files anyway. However, if it's not too much trouble, -alias could be kept temporarily with a deprecation warning that would display on invocation. (Most people, while loath to read announcements and manpages, would probably think about investigating if their ppp started beeping and printing annoying error messages on bootup.) - Matt Behrens m...@zigg.com Network Administrator, zigg.com http://www.zigg.com/ Engineer, Nameless IRC Network http://www.nameless.net/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
CTM CVSUP differences
Hello, I'm using ctm-cvs for synchronizing my CVS-Tree. But sometimes I get MD5 checksum errors when apllying the ctm's. To resynchronize my ctm's with the CVS-Tree i have to use cvsup at ctm.freebsd.org with the option strictrcs. Many files have to be retransmitted and many fixup's appear. Is it possible that there are slight differences between the CTM's and the real world ? Is CTM a little neglient when the diffs are generated? Boris -- b...@dva.in-berlin.de Boris Staeblow To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NFS woes: getting worse?
I have similar experiences. I sometimes do a make release with an NFS mounted chroot environment. My latest successful build is dated from Dec 21. All of the later builds (starting Jan 6th) failed. The error seems to be very deterministic though. I have at least a lot of garbage in chroot/usr/include, with the usual 0-Bytes starting on page boundary (but never the first page) up to the end of the file. I looked at the cvs log, but the only NFS/vfs/vm change I discovered (I'm using only NFSv2/UDP, so the one for NFSv3 on Solaris 7 doesn't apply) were the removal of waslocked paramter on Jan 5th. I don't know if this is related, though. Daniel Matthew Dillon schrieb: :Forgot to mention, this happens with a read-only NFS tree too. I was :running builds on the client with a shared /usr/ports and WRKDIRPREFIX :pointing to a local directory, and the build will topple over in the :middle unable to find a Makefile on the server or something. : :That is the problem that went away with the server load. : :Satoshi I am running a Dec 24th CVS tree while working on the first set of VM commits. I've been using read-only NFS mounts of /usr/src on diskless workstations in order to do make -j6 buildworld runs on them ( /usr/obj being a big 300 MB MFS filesystem on the same workstation, swap-backed, where swap itself is BOOTP NFS based swap). I have not experienced any NFS corruption at all, so whatever blew NFS up must have been committed after Dec 24th. Note that I *AM* using luoqi's VFS/BIO patches, which fixed the msdosfs mount-after-ufs-mount-attempt crash. I'll have time to help track down the NFS problems after the tree splits and I can commit the new swapper, but I can't update my tree until then. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NFS woes: getting worse?
Actually the good news is that the problems I see with the XFree86-contrib port are absolutely reproducible. To be sure I set the test case up on a different set of machines than the pair at home on which I first noticed it. I'll dig a little more this weekend and perhaps I can correlate my ktrace data against the tcpdump trace. -Chris On Fri, 15 Jan 1999, Satoshi Asami wrote: * From: as...@freebsd.org (Satoshi Asami) * * * From: Chris Timmons skyn...@opus.cts.cwu.edu * * * make: don't know how to make Makefiles. Stop * * I've seen similar things, but they went away when I reduced the load * (other compilations in my case) on the server. How busy is your * server? Forgot to mention, this happens with a read-only NFS tree too. I was running builds on the client with a shared /usr/ports and WRKDIRPREFIX pointing to a local directory, and the build will topple over in the middle unable to find a Makefile on the server or something. That is the problem that went away with the server load. Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Weird file corruption?
On Wed, Jan 13, 1999 at 05:26:40PM -0500, Brian Feldman wrote: ... How could it be memory when it's written to disk, extracted, then after a nearly full build read again? Why would it extract completely the first time with no errors? I had this exact same problem when evaluating pentium motherboards a while back. One of my (parity!) simms was marginal [later verified with a simm checker], but it was not noticed until after I made one corrupt archive [and deleted the originals]. Luckily, both the simm and the motherboard were still returnable. This also verified for me that most Intel chipsets for pentium do not use parity even if available. -- Zach Heilig z...@uffdaonline.net / Zach Heilig z...@gaffaneys.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: windowmaker
I will happily take the patches and test it on -current :) -Jim On Thu, 14 Jan 1999, Brian Handy wrote: Anyone running the new windowmaker (0.50.2) on current? Any problems, advice, pitfalls? The windowmaker port is out of date (0.20.3). I'm running it on -STABLE...no -current box here. I've sent the patches to my committer guy, but he doesn't seem to be in right now. (Maybe I'll submit a PR here in a minute so someone else can grab it and have a go at it.) Regards, Brian -- Jim Joseph Email: j...@phoenix.net Be free and open and breezy! Enjoy! Things won't get any better so get used to it. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Which sound card now?
Is the SB PCI 128 supported yet in -current. I new a new sound card and I really would like a 'real' Sound balster. On Fri, 15 Jan 1999, Satoshi Asami wrote: * From: br...@worldcontrol.com * So I am now mostly back the square 1. I'm still using an old GUS MAX, * which at the whim of FreeBSD-core may suddenly stop working. Just one point -- the axing of voxware was *not* approved by FreeBSD-core, and that's why it has been brought back. Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- Jim Joseph Email: j...@phoenix.net Be free and open and breezy! Enjoy! Things won't get any better so get used to it. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
splash screen xdm
It seems that if the splash screen image is not cleared (ie: press any key) before xdm starts up then once logged in the user is unable to switch to a vitual terminal (ie: ctrl-alt-f1 etc), and it just beeps when those keys are pressed. Solution? Putting the command kldunload splash_bmp before the line that loads xdm seems to work. Is this a bug or just the way things are? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: splash screen xdm
It seems that if the splash screen image is not cleared (ie: press any key) before xdm starts up then once logged in the user is unable to switch to a vitual terminal (ie: ctrl-alt-f1 etc), and it just beeps when those keys are pressed. Solution? Putting the command kldunload splash_bmp before the line that loads xdm seems to work. Is this a bug or just the way things are? It's arguably a bug - the splash should be cleared before the vty switch that X makes. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Still safe to do a remote 'installworld'?
Am I still safe to do the equivalent of a 'remote' install world? - I have 2 x 3.0 boxes, one which is fresh 3.0-RELEASE, the other which is 3.0-CURRENT... If I take the /usr/src /usr/obj directories from sucsessful 'buildworld' on the -current machine can I run an 'installworld' on the -release machine? Or is it highly likely to stuff up because of all the recent elven changes etc? - Unfortunately the -release box isn't meaty enough to build the world... I gave up after around 16 hours a time and a few failures (which have been posted here, and subsequently fixed) - I'd kinda not like to have to wait another 16 hours to find any more problems ;-) - especially when the faster box can munch through it in around an hour flat... :) Regards, Karl To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
New NMBCLUSTERS tuning alternative
With this commit, I'm trialling a simple method for providing tuning hints for otherwise statically-set parameters from the bootloader. You can now say: set kern.ipc.nmbclusters= to effectively set NMBCLUSTERS to . I've looked at other approaches, particularly a hook in the SYSCTL_* defines to search the environment and set the variables when the MIB is instantiated, but this won't happen early enough for some things. Any suggestions welcome, of course. --- Forwarded Message msmith 1999/01/15 09:25:03 PST Modified files: sys/i386/i386machdep.c Log: Fetch an overide for NMBCLUSTERS from the kernel environment. Never allow the value to be reduced below that defined when the kernel was built. Revision ChangesPath 1.322 +7 -1 src/sys/i386/i386/machdep.c Modified files: sys/kern kern_environment.c sys/sys systm.h Log: Add getenv_int(), specifically for retrieving integer values from kernel environment variables. This makes it easy to pass tuning parameters in from the bootloader. Revision ChangesPath 1.4 +20 -1 src/sys/kern/kern_environment.c 1.84 +2 -1 src/sys/sys/systm.h --- End of Forwarded Message -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: New NMBCLUSTERS tuning alternative
I love it. Haven't tried it, but the concept is great, and on the assumption it works, will make things even easier... Keep 'em coming. :) On Fri, 15 Jan 1999, Mike Smith wrote: With this commit, I'm trialling a simple method for providing tuning hints for otherwise statically-set parameters from the bootloader. You can now say: set kern.ipc.nmbclusters= to effectively set NMBCLUSTERS to . I've looked at other approaches, particularly a hook in the SYSCTL_* defines to search the environment and set the variables when the MIB is instantiated, but this won't happen early enough for some things. Any suggestions welcome, of course. --- Forwarded Message msmith 1999/01/15 09:25:03 PST Modified files: sys/i386/i386machdep.c Log: Fetch an overide for NMBCLUSTERS from the kernel environment. Never allow the value to be reduced below that defined when the kernel was built. Revision ChangesPath 1.322 +7 -1 src/sys/i386/i386/machdep.c Modified files: sys/kern kern_environment.c sys/sys systm.h Log: Add getenv_int(), specifically for retrieving integer values from kernel environment variables. This makes it easy to pass tuning parameters in from the bootloader. Revision ChangesPath 1.4 +20 -1 src/sys/kern/kern_environment.c 1.84 +2 -1 src/sys/sys/systm.h --- End of Forwarded Message -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Can the bootloader create a file or set a flag in the bootblocks?
It would be kind of cool if when managing a remote system if /kernel failed to boot, then on the next boot, the loader will fire up /kernel.old, or a /kernel.somethingorother. Sort of a kernel-clean flag. Then 300 miles away, I can try stuff, and have at least some assurance that I'll eventually be able to get back to a kernel I could use. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Can the bootloader create a file or set a flag in the bootblocks?
It would be kind of cool if when managing a remote system if /kernel failed to boot, then on the next boot, the loader will fire up /kernel.old, or a /kernel.somethingorother. Sort of a kernel-clean flag. Then 300 miles away, I can try stuff, and have at least some assurance that I'll eventually be able to get back to a kernel I could use. We're trying to work out a clean way of managing that sort of persistent state that doesn't involve nasty hacks like the 'nextboot' code did. It's kinda tricky if you don't want write implemented in all your filesystems (bloat!) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
FreeBSD 3.0-RELEASE Apache 1.3.2 problem
Hi All! I recently installed FreeBSD 3.0-RELEASE from ftp.freebsd.org and Apache/1.3.2 (Server version: Apache/1.3.2 (Unix). Server built: Oct 14 1998 23:19:52) from ftp.freebsd.org/pub/FreeBSD/3.0-RELEASE/packages/www/apache-1.3.2.tgz . After running 'pkg_add apache-1.3.2.tgz' I renamed all /usr/local/etc/apache/*.conf.default in *.conf . Nothing other was changed. After running /usr/local/etc/rc.d/apache.sh I see next message on screen: Local package initialization:Syntax error on line 26 of /usr/local/etc/apache/httpd.conf: Cannot load /usr/local/libexec/apache/mod_mime_magic.so into server: /usr/local/libexec/apache/mod_mime_magic.so: Undefined symbol ap_make_sub_pool Therefore httpd is not running. File /usr/local/libexec/apache/mod_mime_magic.so exist with rights rwxr-xr-x. In file /usr/local/etc/apache/httpd.conf there is line (1st line among others LoadModule): LoadModule mime_magic_module libexec/apache/mod_mime_magic.so What I have done wrong? Is it possible to run Apache 1.3.x on FreeBSD 3.0 ? --- With good wishes, Igor Shulgin -- Phone/fax: +7 (3512) 65-49-51 | SIE Garant-Ural E-mail: igo...@garural.chel.su | To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
sig11 from 3.0.0-19990106-SNAP
I must have missed this on the list, but I caught a sig11 on sysinstall from 3.0.0-19990106-SNAP. DEBUG on VTY2 reports: DEBUG: diskPartitionWrite: Examining 1 devices DEBUG: bootalloc: can't stat /boot/boot1 DEBUG: bootalloc: can't stat /boot/boot2 DEBUG: Signal 11 caught! That's bad! Ideas? Different SNAPs to try? (This is completely reproducible.) - Matt Behrens m...@zigg.com Network Administrator, zigg.com http://www.zigg.com/ Engineer, Nameless IRC Network http://www.nameless.net/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: sig11 from 3.0.0-19990106-SNAP
I must have missed this on the list, but I caught a sig11 on sysinstall from 3.0.0-19990106-SNAP. DEBUG on VTY2 reports: DEBUG: diskPartitionWrite: Examining 1 devices DEBUG: bootalloc: can't stat /boot/boot1 DEBUG: bootalloc: can't stat /boot/boot2 DEBUG: Signal 11 caught! That's bad! Ideas? Different SNAPs to try? (This is completely reproducible.) It's fixed. I just did a two-floppy install of the 12'th SNAP, it worked fine. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
PPP data-dependent bug
FYI, when I rcp (actually, rsync) a certain makefile (ppp -alias), I get lots of these, and it never completes: Warning: CCP: deflink: Incorrect ResetAck (id 49, not 50) ignored Warning: CCP: deflink: Incorrect ResetAck (id 49, not 50) ignored Warning: CCP: deflink: Unexpected ResetAck (id 51) ignored Warning: CCP: deflink: Unexpected ResetAck (id 55) ignored Warning: CCP: deflink: Unexpected ResetAck (id 55) ignored To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Unexpected Busfree Error SEQADDR 0x0153
I got this message after getting the newest source from cvsup today (15.01.1999, about 14 h GMT). I compiled the sources then installed everything and compiled a new kernel. So, the kernel stops after recognition of the NIC when accessing the first SCSI adaptor of two (first Adaptec AHA2940UW, second Adaptec AHA2940AU) with some obsucre errors, like somthing with PHASE and at the end UNEXPETED BUSFREE SEQADDR 0x153. The whole message is gone. I can boot the box with old kernel, compiled a week ago. I installed also the newest bootblocks ... Seems to be an driver problem ... Best wishes Oliver To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Can the bootloader create a file or set a flag in the bootblocks?
That particular feature could also be done with once-persistence as in: On next reboot load this file... In message 199901151746.jaa01...@dingo.cdrom.com, Mike Smith writes: It would be kind of cool if when managing a remote system if /kernel failed to boot, then on the next boot, the loader will fire up /kernel.old, or a /kernel.somethingorother. Sort of a kernel-clean flag. Then 300 miles away, I can try stuff, and have at least some assurance that I'll eventually be able to get back to a kernel I could use. We're trying to work out a clean way of managing that sort of persistent state that doesn't involve nasty hacks like the 'nextboot' code did. It's kinda tricky if you don't want write implemented in all your filesystems (bloat!) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Can the bootloader create a file or set a flag in the bootblocks?
That particular feature could also be done with once-persistence as in: On next reboot load this file... Sure. The problem is just implementing any persistence at all. Consider that we support the following backing-stores for the kernel: - UFS on local disk - (V)FAT(32) - NFS - TFTP - iso9660 Obviously we can't write to CDROMs, but a persistence mechanism needs to work with each of these others. I've been leaning towards a very simple solution using a small, preallocated file which we just overwrite. It's not beautiful, but it's workable. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Can the bootloader create a file or set a flag in the bootblocks?
Poul-Henning Kamp wrote: Sort of a kernel-clean flag. Then 300 miles away, I can try stuff, and have at least some assurance that I'll eventually be able to get back to a kernel I could use. Hmmm... This does rely on the 'stuffed-kernel' eventually cleanly rebooting the machine, we don't want anyone getting a 'false sense of confidence' out of this ;-) - A lot of the machines we use don't even reboot on a 'shutdown -r' :-( -Kp To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Make world failure
Hi, My src tree is current as of 2:00 EST (35 minutes ago), and I'm seeing the following failure: cp dl_dlopen.xs DynaLoader.xs /usr/obj/usr/src/tmp/usr/bin/miniperl -I/usr/obj/usr/src/gnu/usr.bin/perl/perl/lib -I/usr/obj/usr/src/gnu/usr.bin/perl/perl/lib /usr/obj/usr/src/gnu/usr.bin/perl/perl/lib/ExtUtils/xsubpp -noprototypes -typemap /usr/obj/usr/src/gnu/usr.bin/perl/perl/lib/ExtUtils/typemap DynaLoader.xs xstmp.c mv xstmp.c DynaLoader.c cc -c -nostdinc -O -pipe -DVERSION=\1.03\ -DXS_VERSION=\1.03\ -DPIC -fpic -I/usr/obj/usr/src/gnu/usr.bin/perl/perl -DPERL_CORE -DLIBC= DynaLoader.c In file included from DynaLoader.xs:107: /usr/obj/usr/src/gnu/usr.bin/perl/perl/perl.h:301: sys/types.h: No such file or directory /usr/obj/usr/src/gnu/usr.bin/perl/perl/perl.h:312: stdarg.h: No such file or directory In file included from /usr/obj/usr/src/gnu/usr.bin/perl/perl/iperlsys.h:203, from /usr/obj/usr/src/gnu/usr.bin/perl/perl/perl.h:319, from DynaLoader.xs:107: /usr/obj/usr/src/gnu/usr.bin/perl/perl/perlsdio.h:5: stdio.h: No such file or directory In file included from DynaLoader.xs:107: I'll see if I can figure out what changed later this afternoon. Later, John To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
a few suggestions/comments on 3.0-RELEASE
Hello! First of all I appologize if any of these problems have been addressed on the -current list, I am not subscribed, and at the moment don't have much time to carefully browse through the archive of the -current. However, after a quick glance I didn't find it reported. All this is related to the 3.0-RELEASE. I've encountered this problems while installing 3.0-RELEASE on a PII-350 with ASUS P2B-LS motherboard (i.e. there is Adaptec U2W adapter and Intel EtherExpress 100/10 on board) All HDDs are UW SCSI. 1. Having two /stand/sysinstall working in parallel in two different virtual consoles (after the system is brought up after the initial installation), makes the system to panic and reboot. This seems to happen if, and at the moment when both sysinstall's are writing something intensively, say installing packages in one and installing additional options for the distribution (catpages, manpages, sources..) - both from the ftp. The errors appear on the screen so fast that I couldn't catch what they were, but they seemed to be related to the disk i/o. Everytime (I tried 3-4 times) it was the same error. None is written to /var/log/messages. 2. I didn't find any documentation in the man pages which describes the features of the new bootstrap - i.e. that it is capable of handling slice number. /boot.help doesn't have that reference either. (I mean the possibility of specifying 2:da(1,2,a)kernel where the second 2 is for the slice number) The only place I found where it was addressed was somebody's answer in -questions archive, and on the -stable list. Also, it might be nice if the disklabel(8) man pages explicitely say that the bootstrap code can be installed on each slice. (am I wrong ?) 3. if I start /stand/sysinstall after bringing the computer up for the first time, and try to add and configure the network interface (fxp0 in my case), it prompts me if I want to bring it up. If I say yes, it was not complaining about anything, but in some cases (may be even all - I didn't test extensively) the routing to the will not come up (according to the netstat), so it'd look like (approximately, recreated from my memory): netstat -i Name Mtu Network AddressIpkts IerrsOpkts Oerrs Coll fxp0 1500 Link 00.00.c0.3d.41.c6 0 00 0 0 lp0* 1500 Link 0 00 0 0 tun0* 1500 Link 0 00 0 0 lo0 16384 Link 0 00 0 0 lo0 16384 127 localhost 0 00 0 0 Just doing the configuration of the interface, and than rebooting does the job alright. (My only doubt is that I don't remember whether there were any leftovers of attempts of configuring the fxp0 interface manually just before starting the sysinstall. In any case I think sysinstall should be able to bring the interface up properly.) I didn't experience any problem with bringing the interface up from the installation floppy. 4. (it's probably relevant to -ports list ?) make for the ssh (not ssh2) complains about the absence of bsd.port.post.mk and bsd.port.pre.mk Copying it from the -stable brunch seems to fix the problem. (It seems that I've seen somebody complaining about this problem, but couldn't find it anywhere, and it is not reflected in the ERRATA http://www.freebsd.org/releases/3.0R/errata.html ) If you want to reply or to ask about some details I missed, please include my address in the reciepients, because I am not subscribed to -current mailing list. Regards, Igor To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Out of file descriptors
After a cvsup and make world this AM, I get .: Out of file descriptors then I am thrown into single user, and the booting process stops. Can someone advise me what is causing this, and what I have to do to eliminate the problem? Thanks in advance! Tom To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Weird file corruption?
On Fri, 15 Jan 1999, Zach Heilig wrote: On Wed, Jan 13, 1999 at 05:26:40PM -0500, Brian Feldman wrote: ... How could it be memory when it's written to disk, extracted, then after a nearly full build read again? Why would it extract completely the first time with no errors? I had this exact same problem when evaluating pentium motherboards a while back. One of my (parity!) simms was marginal [later verified with a simm checker], but it was not noticed until after I made one corrupt archive [and deleted the originals]. Luckily, both the simm and the motherboard were still returnable. Good to know I am looking in the right place. I switched my timings from Turbo to Normal (I have 2 EDO/2 FP), and now it seems to past tests, but I think I did see a few bytes get corrupted in an image in netscape... ah well, so you'd recommend finding someone with a SIMM checker? This also verified for me that most Intel chipsets for pentium do not use parity even if available. -- Zach Heilig z...@uffdaonline.net / Zach Heilig z...@gaffaneys.com Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Can the bootloader create a file or set a flag in the bootblocks?
On Fri, 15 Jan 1999, Mike Smith wrote: That particular feature could also be done with once-persistence as in: On next reboot load this file... Sure. The problem is just implementing any persistence at all. Consider that we support the following backing-stores for the kernel: - UFS on local disk - (V)FAT(32) - NFS - TFTP - iso9660 Obviously we can't write to CDROMs, but a persistence mechanism needs to work with each of these others. I've been leaning towards a very simple solution using a small, preallocated file which we just overwrite. It's not beautiful, but it's workable. It can't go into free space in a boot block? We still have room left over... It could only be a few bytes, enumerating numbered kernels in /boot/kernels.rc, or something like that -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Can the bootloader create a file or set a flag in the bootblocks?
On Fri, 15 Jan 1999, Mike Smith wrote: Obviously we can't write to CDROMs, but a persistence mechanism needs to work with each of these others. I've been leaning towards a very simple solution using a small, preallocated file which we just overwrite. It's not beautiful, but it's workable. It can't go into free space in a boot block? We still have room left over... It could only be a few bytes, enumerating numbered kernels in /boot/kernels.rc, or something like that It needs to be a general solution, and see above, again, for the things it needs to be able to do. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Can the bootloader create a file or set a flag in the bootblocks?
On Fri, 15 Jan 1999, Mike Smith wrote: On Fri, 15 Jan 1999, Mike Smith wrote: Obviously we can't write to CDROMs, but a persistence mechanism needs to work with each of these others. I've been leaning towards a very simple solution using a small, preallocated file which we just overwrite. It's not beautiful, but it's workable. It can't go into free space in a boot block? We still have room left over... It could only be a few bytes, enumerating numbered kernels in /boot/kernels.rc, or something like that It needs to be a general solution, and see above, again, for the things it needs to be able to do. So for FFS, it could be stored in the superblock, label, or one of the other structures that aren't actually inodes, right? For FAT, couldn't it be stored in either the FAT or the volume name? TFTP and NFS are both non-local, but still have writing capabilities built in. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Weird file corruption?
On Fri, Jan 15, 1999 at 02:51:01PM -0500, Brian Feldman wrote: Good to know I am looking in the right place. I switched my timings from Turbo to Normal (I have 2 EDO/2 FP), and now it seems to past tests, but I think I did see a few bytes get corrupted in an image in netscape... ah well, so you'd recommend finding someone with a SIMM checker? Except simm checkers don't always catch errors, so if the simm passes, there still is no guarantee (but simm checkers do weed out obvious duds quicker than trying in a system). Unfortunately, there is no conclusive test [that I know about] to prove a simm is good. The best test I know is to use emperical evidence based on how the system acts with or without the suspect simm. Even better is to only use motherboards that support parity and/or ECC, with parity/ecc simms/dimms. Then you catch most problems right away, rather than scratching your head (and doing the if I twiddle this knob, it seems to reduce the problem... I think). -- Zach Heilig z...@uffdaonline.net / Zach Heilig z...@gaffaneys.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Can the bootloader create a file or set a flag in the bootblocks?
I've been thinking about this same thing, and I thought that relatively static fallback list of environments plus an (persistant) index to tell you what you've tried so far might work. I was considering stealing a byte from the RTC CMOS to hold the state between reboots. louie To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
umount: permission denied as root?
I recently purchased an optical drive for doing backups. After doing a backup, I naturally flipped the switch to write protect. At a later point, I needed to restore some files from the backup, and so, stuck the disk back in, and mounted it. When I was done, the disk wouldn't unmount. When I tried, umount came back with a 'permission denied'. At the time, I was root. (If root doesn't have permission, who does?!) The problem was in my /etc/fstab file, I had the following: /dev/da1c /backup ufs rw 0 0 OK, so it is my fault, I should have mounted it read-only. Unfortunately, it took a reboot to get the disk out of the drive! So, I am thinking that perhaps the code should be made more robust? +C -- Thinking of purchasing RAM from the Chip Merchant? Please read this first: http://www.enigami.com/~ckempf/chipmerchant.html Cory KempfMacintosh / Unix Consulting Software Development cke...@enigami.comhttp://www.enigami.com/~ckempf/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Can the bootloader create a file or set a flag in the bootblocks?
It needs to be a general solution, and see above, again, for the things it needs to be able to do. So for FFS, it could be stored in the superblock, label, or one of the other structures that aren't actually inodes, right? For FAT, couldn't it be stored in either the FAT or the volume name? TFTP and NFS are both non-local, but still have writing capabilities built in. No, it needs to be in a file so that it can be simply manipulated from userland. Remember, the writable list is: - FFS - FAT - NFS - TFTP -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: umount: permission denied as root?
On 15 Jan 1999, Cory Kempf wrote:
I recently purchased an optical drive for doing backups. After doing a
backup, I naturally flipped the switch to write protect.
At a later point, I needed to restore some files from the backup, and
so, stuck the disk back in, and mounted it.
When I was done, the disk wouldn't unmount. When I tried, umount
came back with a 'permission denied'. At the time, I was root. (If
root doesn't have permission, who does?!)
The problem was in my /etc/fstab file, I had the following:
/dev/da1c /backup ufs rw 0 0
OK, so it is my fault, I should have mounted it read-only.
Unfortunately, it took a reboot to get the disk out of the drive!
So, I am thinking that perhaps the code should be made more robust?
I had this exact problem with my LS-120 a week or so ago.
Here's a reenaction (yes, I'm doing this in real life now to verify it's
working)
{/home/green}# mount /floppy
{/home/green}# umount /floppy
umount: /floppy: Input/output error
{/home/green}# mount | grep flop
/dev/wfd0a on /floppy (local, writes: sync 2 async 2)
{/home/green}# # d'oh! It's write-protected.
{/home/green}# mount -u -o ro /floppy
{/home/green}# umount /floppy
{/home/green}#
Hope I helped!
+C
--
Thinking of purchasing RAM from the Chip Merchant?
Please read this first: http://www.enigami.com/~ckempf/chipmerchant.html
Cory KempfMacintosh / Unix Consulting Software Development
cke...@enigami.comhttp://www.enigami.com/~ckempf/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Brian Feldman_ __ ___ ___ ___
gr...@unixhelp.org _ __ ___ | _ ) __| \
http://www.freebsd.org/ _ __ ___ | _ \__ \ |) |
FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: CTM CVSUP differences
According to Boris Staeblow: Is it possible that there are slight differences between the CTM's and the real world ? There should not be. Is CTM a little neglient when the diffs are generated? I cannot say anything else than it has been working for me for several years and the few times it blew up was when some fairly large problem hit the CTM generator and it happened only once in one or two years. In fact, it has been very stable for several thousand of generated chunks. cvs-cur is now at the following level and I don't remember when tha last problem was (problem as in badly generated chunks)... -rw--- 1 nobody wheel 728351 Jan 15 19:08 cvs-cur.4987.gz -rw--- 1 nobody wheel 388427 Jan 15 19:08 cvs-cur.4988.gz -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #67: Tue Dec 29 20:24:02 CET 1998 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Still safe to do a remote 'installworld'?
On Fri, 15 Jan 1999, Karl Pielorz wrote: Am I still safe to do the equivalent of a 'remote' install world? - I have 2 x 3.0 boxes, one which is fresh 3.0-RELEASE, the other which is 3.0-CURRENT... If I take the /usr/src /usr/obj directories from sucsessful 'buildworld' on the -current machine can I run an 'installworld' on the -release machine? I've done that a number of times in the last month or two. Works like a charm. One thing to watch out for is that kernel's are now ELF which means you must install the new bootblocks on the -release machine first. Also check out the mergemaster port for a handy way to update /etc. -john To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 3.0-RELEASE Apache 1.3.2 problem
On Fri, 15 Jan 1999, Igor Shulgin wrote: What I have done wrong? Is it possible to run Apache 1.3.x on FreeBSD 3.0 ? Yes but you need to install a more recent port or package. The conversion to ELF tripped up a few things like Apache that didn't know about ELF FreeBSD systems. That is all fixed now. (See the FreeBSD FAQ for more info about the ELF conversion) -john To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Weird file corruption?
Zach Heilig z...@uffdaonline.net wrote: Except simm checkers don't always catch errors, so if the simm passes, there still is no guarantee (but simm checkers do weed out obvious duds quicker than trying in a system). Unfortunately, there is no conclusive test [that I know about] to prove a simm is good. I'd agree with that. The guts of a DRAM (or any type) is high-speed analog circuitry with delicate multi-phase clocking (the external clocks and selects are internally subdivided into maybe 20 phases). There can be pattern-sensitive crosstalk between rows or columns that depends on inter-access timings - or even how long since a particular row was refreshed. I suspect it's impossible to prove that a SIMM is good - there are two many combinations to test. Even better is to only use motherboards that support parity and/or ECC, with parity/ecc simms/dimms. This is the only practical way to detect memory problems. A subsidiary problem is that, unlike say Solaris, FreeBSD doesn't automatically report ECC errors. Without this, your memory controller can be furiously correcting a hard single-bit error and die when it glitches to a double-bit error. Someone did post a script that checked and cleared the relevant register in an i440 several months ago, but I seem to have mislaid both the script and reference :-(. Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Forward all spam to u...@ftc.gov
On Wed, Jan 13, 1999 at 07:36:35PM -0600, Jim Bryant wrote: This announcement is located on the Federal Trade Commission's complaint form page http://www.ftc.gov/ftc/complaint.htm I've been using the address for over half a year.. Nada for response nor spam reduction. So I just tightened up my procmail filters instead.. -- Joseph nugundam =best=com==/==\=IIGS=/==\=Playstation=/==\=Civic HX CVT=/==\ #Anime Expo 1998 www.anime-expo.org/ # Redline Games www.redlinegames.com/ # Cal-Animage Epsilon www.best.com/~nugundam/epsilon/ # EX: The Online World of Anime Manga www.ex.org/ / To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Diskless NFS boot stopping at rootfs
I'm trying to adapt a working 2.2.6 diskless booting arrangement to 3.0, for both clients and the server. The client machines load the kernel just fine, then I see NFS ROOT: 10.0.0.1:/export/boot/fs which is correct, but the process stops there. It doesn't get any further. I'm not sure if the machine is successfully mounting the root fs or not. There is no error after timeout, the client's IP does respond to pings. I have no configured swap, and while all the configurations I have seen did have nfs swap, my setup worked under 2.2.6 without it and I'd prefer to avoid it. Following is all the info that seemed pertinent. These configs are with very few changes (IP numbers and such) the ones that worked under 2.2.6. If you reply, please reply to me directly, I'm not subscribed to the list. Thank you in advance for your help. --- My 3.0 kernel config for the clients: machine i386 cpu I586_CPU identSNX maxusers 16 options NO_SWAPPING options BOOTP options BOOTP_NFSROOT options INET#InterNETworking options FFS #Berkeley Fast Filesystem options MFS #Memory Filesystem options NFS #Network Filesystem options NFS_ROOT#NFS usable as root device, NFS req'ed options PROCFS #Process filesystem options COMPAT_43#Compatible with BSD 4.3 [KEEP THIS!] options UCONSOLE#Allow users to grab the console options FAILSAFE#Be conservative options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor config kernel root on wd0 controller isa0 controller eisa0 controller pci0 device sc0 at isa? port IO_KBD conflicts tty irq 1 vector scintr device npx0 at isa? port IO_NPX irq 13 vector npxintr device sio0 at isa? port IO_COM1 flags 0x10 tty irq 4 vector siointr device sio1 at isa? port IO_COM2 tty irq 3 vector siointr device psm0 at isa? port IO_KBD conflicts tty irq 12 vector psmintr device ed0 at isa? port 0x300 net irq 5 iomem 0xd8000 vector edintr pseudo-device loop pseudo-device ether pseudo-device pty 16 pseudo-device gzip # Exec gzipped a.out's options KTRACE #kernel tracing options SYSVSHM --- A sample entry from my bootptab: dslsupport01:\ :ht=ether:\ :ha=00400568cd52:\ :sm=255.255.255.0:\ :hn:\ :ip=10.0.0.31:\ :gw=10.0.0.1:\ :rp=/export/boot/fs:\ :bf=kernel:\ :td=/export/boot/fs:\ :vm=rfc1048: --- A sample tftp config file: rootfs 10.0.0.1:/export/boot/fs hostname dslsupport01 --- The contents of the clients /etc/rc file: #!/bin/sh PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin export PATH TERM=vt100 export TERM clear echo; echo; echo echo Please be patient while the system comes up... echo; echo; echo #/sbin/ldconfig /usr/lib /usr/lib/compat /usr/X11R6/lib ifconfig lo0 127.0.0.1 #mount -t nfs -u 10.0.0.1:/export/boot/fs / mount -a #if [ -f /dev/audio ]; then /usr/X11R6/bin/au :8086 -aa echo Starting auserver on port 8086... #fi while [ 1 -eq 1 ]; do /usr/X11R6/bin/XF86_S3V -bpp 16 -query deimos done --- The contents of the clients /etc/fstab: 10.0.0.1:/export/boot/fs/ nfs ro 0 0 10.0.0.1:/export/boot/dev /devnfs rw 0 0 /dev/null /tmpmfs rw,-T=tmp 0 0 --- Nicholas Esborn | www.azstarnet.com | StarNet (520) 618-RTFM | To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NFS woes: getting worse?
On Fri, 15 Jan 1999, Satoshi Asami wrote: * From: as...@freebsd.org (Satoshi Asami) * * * From: Chris Timmons skyn...@opus.cts.cwu.edu * * * make: don't know how to make Makefiles. Stop * * I've seen similar things, but they went away when I reduced the load * (other compilations in my case) on the server. How busy is your * server? Forgot to mention, this happens with a read-only NFS tree too. I was running builds on the client with a shared /usr/ports and WRKDIRPREFIX pointing to a local directory, and the build will topple over in the middle unable to find a Makefile on the server or something. That is the problem that went away with the server load. I'm a day late in reading my mail, but on a machine I just finished upgrading to current, with nfs mounted /usr/ports, I had identical problems. When I used WRKDIRPREFIX to stick the build directories somewhere local, the problem disappeared. I haven't yet taken a close enough look at nfs options (mount options) to see if I can tweak it out. I sure enough have a pretty good test platform for it. My initial guess is that writes aren't completing; Makefiles built using Imake from ports are missing the last few K, which causes all the errors. +--- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic (FreeBSD-current) (301) 220-2114 | and jaunt (NetBSD). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: CTM CVSUP differences
On Fri, 15 Jan 1999, Boris Staeblow wrote: Hello, I'm using ctm-cvs for synchronizing my CVS-Tree. But sometimes I get MD5 checksum errors when apllying the ctm's. To resynchronize my ctm's with the CVS-Tree i have to use cvsup at ctm.freebsd.org with the option strictrcs. Many files have to be retransmitted and many fixup's appear. Is it possible that there are slight differences between the CTM's and the real world ? Is CTM a little neglient when the diffs are generated? CTM is remarkably stable. In running it 3 years (I stopped about 4 months ago when my net connection improved) I had only 1 stoppage, a well known one caused by someone messing witht he archive. If you're getting problems like this on a regular basis, then you *really* ought to either consider your environment. Are you using any other tool besides ctm to touch your cvs archive? Are you doing commits locally? CTM won't allow anything but ctm alone to modify the tree, no exceptions whatsoever. In terms of convenience, cvsup is supreme, but in terms of stability, Poul's baby here is the champ, so you have to really consider other places of corruption first. +--- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic (FreeBSD-current) (301) 220-2114 | and jaunt (NetBSD). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
trap in ufs_lookup
I've got a crash in ufs_lookup, and I'm trying to assess responsibility. I
use SoftUpdates on all drives and _MAY_ have some bad RAM. This crash was
during a make -j4 -DNOCLEAN world, and maybe it may be due to SoftUpdates not
completely having finished the dir, but I'm thinking it could've been RAM
corruption. Someone help me :)
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type show copying to see the conditions.
There is absolutely no warranty for GDB; type show warranty for details.
GDB 4.16 (i386-unknown-freebsd),
Copyright 1996 Free Software Foundation, Inc...
IdlePTD 2899968
initial pcb at 2425ec
panicstr: vm_fault: fault on nofault entry, addr: f3748000
panic messages:
---
panic: vm_fault: fault on nofault entry, addr: f3748000
syncing disks... 234 232 223 198 167 150 123 92 63 19 11 1 1 1 1 1 1 1 1 1 givin
g up
dumping to dev 30001, offset 40960
dump 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55
54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28
27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:285
285 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:285
#1 0xf01383d5 in panic (
fmt=0xf0211d86 vm_fault: fault on nofault entry, addr: %lx)
at ../../kern/kern_shutdown.c:446
#2 0xf01a297e in vm_fault (map=0xf025e014, vaddr=4084498432,
fault_type=1 '\001', fault_flags=0) at ../../vm/vm_fault.c:232
#3 0xf01da750 in trap_pfault (frame=0xf7c46cd0, usermode=0, eva=4084499165)
at ../../i386/i386/trap.c:824
#4 0xf01da3f2 in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = 21209,
tf_esi = -247132928, tf_ebp = -138121840, tf_isp = -138121992,
tf_ebx = -210468135, tf_edx = -222954112, tf_ecx = 8191, tf_eax = 37593,
tf_trapno = 12, tf_err = 0, tf_eip = -266750417, tf_cs = 8,
tf_eflags = 66178, tf_esp = -138278720, tf_ss = -138121524})
at ../../i386/i386/trap.c:437
#5 0xf019b62f in ufs_lookup (ap=0xf7c46dcc) at ../../ufs/ufs/ufs_lookup.c:238
#6 0xf01a03e9 in ufs_vnoperate (ap=0xf7c46dcc)
at ../../ufs/ufs/ufs_vnops.c:2294
#7 0xf0157f30 in vfs_cache_lookup (ap=0xf7c46e28) at vnode_if.h:55
#8 0xf01a03e9 in ufs_vnoperate (ap=0xf7c46e28)
at ../../ufs/ufs/ufs_vnops.c:2294
#9 0xf015a405 in lookup (ndp=0xf7c46ea8) at vnode_if.h:31
#10 0xf0159ed8 in namei (ndp=0xf7c46ea8) at ../../kern/vfs_lookup.c:152
#11 0xf015f5a0 in stat (p=0xf7b8b3c0, uap=0xf7c46f84)
---Type return to continue, or q return to quit---
at ../../kern/vfs_syscalls.c:1614
#12 0xf01dad47 in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 136292736,
tf_esi = 0, tf_ebp = -272644404, tf_isp = -138121260,
tf_ebx = 134749056, tf_edx = 12, tf_ecx = 134749056, tf_eax = 188,
tf_trapno = 12, tf_err = 2, tf_eip = 134580048, tf_cs = 31,
tf_eflags = 582, tf_esp = -272644524, tf_ss = 39})
at ../../i386/i386/trap.c:1100
#13 0xf01cd85c in Xint0x80_syscall ()
#14 0x8050303 in ?? ()
#15 0x8049761 in ?? ()
#16 0x8057a79 in ?? ()
#17 0x8057a45 in ?? ()
#18 0x80496e8 in ?? ()
#19 0x8057a79 in ?? ()
#20 0x8057a45 in ?? ()
#21 0x80496e8 in ?? ()
#22 0x8057a79 in ?? ()
#23 0x8057a45 in ?? ()
#24 0x80496e8 in ?? ()
#25 0x8049aa0 in ?? ()
#26 0x804fd0f in ?? ()
#27 0x80480e9 in ?? ()
(kgdb) frame 5
#5 0xf019b62f in ufs_lookup (ap=0xf7c46dcc) at ../../ufs/ufs/ufs_lookup.c:238
238 ep = (struct direct *)((char *)bp-b_data + entryoffseti
nblock);
(kgdb) l
233 * Full validation checks are slow, so we only check
234 * enough to insure forward progress through the
235 * directory. Complete checks can be run by patching
236 * dirchk to be true.
237 */
238 ep = (struct direct *)((char *)bp-b_data + entryoffseti
nblock);
239 if (ep-d_reclen == 0 ||
240 (dirchk ufs_dirbadentry(vdp, ep, entryoffsetinblo
ck))) {
241 int i;
242
(kgdb) printf %p + %d\n, bp-b_data, entryoffset^Ht^Ginblock
0xf3743000 + 21209
(kgdb) printf %d: %s\n, p-p_pid ^H ^H, p-p_comm
68863: make
#relevant code:
bmask = VFSTOUFS(vdp-v_mount)-um_mountp-mnt_stat.f_iosize - 1;
if (nameiop != LOOKUP || dp-i_diroff == 0 ||
dp-i_diroff dp-i_size) {
entryoffsetinblock = 0;
dp-i_offset = 0;
numdirpasses = 1;
} else {
dp-i_offset = dp-i_diroff;
if ((entryoffsetinblock = dp-i_offset bmask)
(error = UFS_BLKATOFF(vdp, (off_t)dp-i_offset, NULL, bp)))
return (error);
numdirpasses = 2;
nchstats.ncs_2passes++;
}
(kgdb) printf i_offset %d bmask %d = %d\n,
Re: splash screen xdm
It seems that if the splash screen image is not cleared (ie: press any key) before xdm starts up then once logged in the user is unable to switch to a vitual terminal (ie: ctrl-alt-f1 etc), and it just beeps when those keys are pressed. Solution? Putting the command kldunload splash_bmp before the line that loads xdm seems to work. Is this a bug or just the way things are? Definitely a bug. Which version of the X server are you using? Did you see any error message when this happened? /var/log/messages* may reveal something. Kazu To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: splash screen xdm
Вы писали: It seems that if the splash screen image is not cleared (ie: press any key) before xdm starts up then once logged in the user is unable to switch to a vitual terminal (ie: ctrl-alt-f1 etc), and it just beeps when those keys are pressed. Solution? Putting the command kldunload splash_bmp before the line that loads xdm seems to work. Is this a bug or just the way things are? My current has not this bug. All works Ok. xdm starts by init (ttys). -- Best wishes, Eugeny http://coredumped.null.ru coredum...@coredumped.null.ru ICQ#: 5885106 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: splash screen xdm
On Sat, 16 Jan 1999, Eugeny Kuzakov wrote: ?? ??: It seems that if the splash screen image is not cleared (ie: press any key) before xdm starts up then once logged in the user is unable to switch to a vitual terminal (ie: ctrl-alt-f1 etc), and it just beeps when those keys are pressed. Solution? Putting the command kldunload splash_bmp before the line that loads xdm seems to work. Is this a bug or just the way things are? My current has not this bug. All works Ok. xdm starts by init (ttys). Do you have in rc.conf a screen saver or possibly vidcontrol flags defined? -- Best wishes, Eugeny http://coredumped.null.ru coredum...@coredumped.null.ru ICQ#: 5885106 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: [Fwd: splash screen xdm]
It seems that if the splash screen image is not cleared (ie: press any key) before xdm starts up then once logged in the user is unable to switch to a vitual terminal (ie: ctrl-alt-f1 etc), and it just beeps when those keys are pressed. Solution? Putting the command kldunload splash_bmp before the line that loads xdm seems to work. Is this a bug or just the way things are? Definitely a bug. Which version of the X server are you using? 3.3.3.1 and, if it helps, my video card is detected as: vga0: S3 ViRGE VX graphics accelerator rev 0x02 int a irq 11 on pci0.17.0 sc0 on isa sc0: VGA color 16 virtual consoles, flags=0x0 vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa Did you see any error message when this happened? /var/log/messages* may reveal something. nothing produced in /var/log/messages, nothing on xconsole After logging out of the x session, (back to xdm) it beeps and logs: xf86OpenConsole: VT_ACTIVATE failed in xdm-errors, but xdm still seems to work okay, and you can log back in. If you reboot, then it exits to a colourfull set of ascii characters, and blocks of coloured in rectangles, (as if its still trying to display the splash screen) and reboots normally. It doesn't seem to matter if xdm is started from /etc/ttys or /etc/rc.local If the splash screen IS cleared before xdm starts, then there is no problem... Last make update, make world kernel: Fri, Jan. 15. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Can't compile new kernel after CVSup...
Hello! After cvsuped my source tree, i try to compile a new kernel, c following: # config -r MY_KERNEL # cd ../../compile/MY_KERNEL # make depend # make cc -c -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wuninitialized -Wformat -Wunused -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -include opt_global.h -elf ../../libkern/umoddi3.c cc -c -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wuninitialized -Wformat -Wunused -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -include opt_global.h -elf ../../pci/es1370.c ../../pci/es1370.c:150: warning: initialization from incompatible pointer type ../../i386/isa/snd/ulaw.h:40: warning: `dsp_ulaw' defined but not used cc -c -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wuninitialized -Wformat -Wunused -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -include opt_global.h -elf ../../pci/ide_pci.c ../../pci/ide_pci.c: In function `ide_pci_candma': ../../pci/ide_pci.c:1462: structure has no member named `ctrlr' *** Error code 1 Stop. Something wrong? Rgdz, Осокин Сергей aka oZZ, o...@etrust.ru P.S. 16.01.1999 - 4 days before 3.0-STABLE? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Disk Geometry Patch. Could someone test this on -current.
I have found several people using IDE disks on newer Award BIOSes have trouble
getting the boot-time probes and installation routines to recognize the correct
disk geometry.
If anyone is running 3.0 (or 2.2.x) on a machine with Award BIOS using IDE
drives with LBA turned off in the kernel configuration, and if you have trouble
getting dmesg/boot probes to recognize the proper disk size, could you test the
attached patch for me?
I would also like to find testers with ANY BIOS that reports a disk size too
small. I think my patch will correct most problems with IDE geometry showing as
smaller than it actually is. (I don't make any claims about geometries being
reported as too large, or SCSI disks...)
Thanks to anyone who can help.
Andrew Sherrod
P.S. I know this is not a really big problem, but it always seemed a bit
insulting that FreeBSD had to rely on DOS boot sectors to get the correct disk
geometry. I would rather that we could identify the correct geometry without
having to rely on another OS.
And, face it, for newbies and those not terribly computer literate, getting the
right geometry during installation is a very nice feature. It is rather
disheartening for a new-comer to find out that their new operating system can't
even identify the correct disk geometry.
_
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com
-
PR: i386/9431
-
-
Patch for 2.2.8 (May also workfor 2.2.6/2.2.7)
-
*** wd.c.2_2_8 Wed Jan 13 21:07:30 1999
--- wd.c.original.2_2_8 Wed Jan 13 21:08:24 1999
***
*** 113,122
#define WDOPT_FORCEHD(x) (((x)0x0f00)8)
#define WDOPT_MULTIMASK 0x00ff
- /* This bit mask is used to determine if the drive supports LBA addressing.
*/
-
- #define WDCAP_LBA 0x02
-
/*
* This biotab field doubles as a field for the physical unit number on
* the controller.
--- 113,118
***
*** 1731,1745
du-dk_dd.d_nsectors = wp-wdp_sectors;
du-dk_dd.d_secpercyl = du-dk_dd.d_ntracks * du-dk_dd.d_nsectors;
du-dk_dd.d_secperunit = du-dk_dd.d_secpercyl *
du-dk_dd.d_ncylinders;
!
!/* Check for BIOS LBA flag. This should allow kernel to determine
! actual disk geometry for diffiuclt BIOSes.
! This will likely only be of use during initial installation, or
! perhaps when configuring a new drive. Otherwise, the disk geometry
! should already be known. -A. Sherrod 01/13/1999*/
!
! if ( ( (wp-wdp_capabilityWDCAP_LBA) ||
!(wp-wdp_cylinders == 16383 ) )
du-dk_dd.d_secperunit wp-wdp_lbasize) {
du-dk_dd.d_secperunit = wp-wdp_lbasize;
du-dk_dd.d_ncylinders =
--- 1727,1733
du-dk_dd.d_nsectors = wp-wdp_sectors;
du-dk_dd.d_secpercyl = du-dk_dd.d_ntracks * du-dk_dd.d_nsectors;
du-dk_dd.d_secperunit = du-dk_dd.d_secpercyl *
du-dk_dd.d_ncylinders;
! if (wp-wdp_cylinders == 16383
du-dk_dd.d_secperunit wp-wdp_lbasize) {
du-dk_dd.d_secperunit = wp-wdp_lbasize;
du-dk_dd.d_ncylinders =
-
Patch for 3.0
-
*** wd.c.3_0 Wed Jan 13 12:07:46 1999
--- wd.c.original.3_0 Wed Jan 13 11:17:54 1999
***
*** 130,140
*/
#define id_physid id_scsiid
- /* This bitmask is used to determine if the BIOS flags showing LBA
support
-are active or inactive */
-
- #define WDCAP_LBA0x02
-
/*
* Drive states. Used to initialize drive.
*/
--- 130,135
***
*** 1954,1973
du-dk_dd.d_ntracks * du-dk_dd.d_nsectors;
du-dk_dd.d_secperunit =
du-dk_dd.d_secpercyl * du-dk_dd.d_ncylinders;
!
! /* If BIOS specifies LBA mode is supported, but LBA flags
! are not set, check if wdp_lbasize is larger than
! CHS size. If so, use the lba_size.
! This should fix problems with certain BIOSes (e.g.
Award)
! which do not report the correct size when using only
! CHS calculations.
! This will not force the use of LBA mode. It is only
! used to determine disk geometry.
!
! -A. Sherrod 01/13/1999 */
!
!
Re: splash screen xdm
On Fri, 15 Jan 1999, Brian Feldman wrote:
Solution? Putting the command kldunload splash_bmp before the line that
loads xdm seems to work. Is this a bug or just the way things are?
My current has not this bug. All works Ok.
xdm starts by init (ttys).
Do you have in rc.conf a screen saver or possibly vidcontrol flags defined?
Saver ? Yes.
saver=snake # screen saver: Uses /modules/${saver}_saver.ko
Are you about allscreens_flags ? No.
--
Best wishes, Eugeny Kuzakov
Laboratory 321 ( Omsk, Russia )
k...@lab321.ru
ICQ#: 5885106
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
3.0.1 soon ?
Just wondering if there is an updated timeline for 3.0.1 release ? ---Mike ** Mike Tancsa, Network Admin* m...@sentex.net Sentex Communications Corp, * http://www.sentex.net/mike Cambridge, Ontario* 01.519.651.3400 Canada* To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Can the bootloader create a file or set a flag in the bootblocks?
Jaye Mathisen writes: It would be kind of cool if when managing a remote system if /kernel failed to boot, then on the next boot, the loader will fire up /kernel.old, or a /kernel.somethingorother. Sort of a kernel-clean flag. Then 300 miles away, I can try stuff, and have at least some assurance that I'll eventually be able to get back to a kernel I could use. In case in that discussion it wasn't clear, there *is* a way to do this: see man nextboot. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: trap in ufs_lookup
I'm pretty sure this is not softupdates related. It could either be bad RAM
or a bad disk block, there is no way entryoffsetinblock could be 21209,
the block size is only 8192. And you need over 2000 files to fill the
directory to i_offset == 37593, assuming an average file name length of
10 bytes.
-lq
I've got a crash in ufs_lookup, and I'm trying to assess responsibility. I
use SoftUpdates on all drives and _MAY_ have some bad RAM. This crash was
during a make -j4 -DNOCLEAN world, and maybe it may be due to SoftUpdates not
completely having finished the dir, but I'm thinking it could've been RAM
corruption. Someone help me :)
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type show copying to see the conditions.
There is absolutely no warranty for GDB; type show warranty for details.
GDB 4.16 (i386-unknown-freebsd),
Copyright 1996 Free Software Foundation, Inc...
IdlePTD 2899968
initial pcb at 2425ec
panicstr: vm_fault: fault on nofault entry, addr: f3748000
panic messages:
---
panic: vm_fault: fault on nofault entry, addr: f3748000
syncing disks... 234 232 223 198 167 150 123 92 63 19 11 1 1 1 1 1 1 1 1 1
givin
g up
dumping to dev 30001, offset 40960
dump 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56
55
54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29
28
27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:285
285 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:285
#1 0xf01383d5 in panic (
fmt=0xf0211d86 vm_fault: fault on nofault entry, addr: %lx)
at ../../kern/kern_shutdown.c:446
#2 0xf01a297e in vm_fault (map=0xf025e014, vaddr=4084498432,
fault_type=1 '\001', fault_flags=0) at ../../vm/vm_fault.c:232
#3 0xf01da750 in trap_pfault (frame=0xf7c46cd0, usermode=0, eva=4084499165)
at ../../i386/i386/trap.c:824
#4 0xf01da3f2 in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = 21209,
tf_esi = -247132928, tf_ebp = -138121840, tf_isp = -138121992,
tf_ebx = -210468135, tf_edx = -222954112, tf_ecx = 8191, tf_eax =
37593,
tf_trapno = 12, tf_err = 0, tf_eip = -266750417, tf_cs = 8,
tf_eflags = 66178, tf_esp = -138278720, tf_ss = -138121524})
at ../../i386/i386/trap.c:437
#5 0xf019b62f in ufs_lookup (ap=0xf7c46dcc) at
../../ufs/ufs/ufs_lookup.c:238
#6 0xf01a03e9 in ufs_vnoperate (ap=0xf7c46dcc)
at ../../ufs/ufs/ufs_vnops.c:2294
#7 0xf0157f30 in vfs_cache_lookup (ap=0xf7c46e28) at vnode_if.h:55
#8 0xf01a03e9 in ufs_vnoperate (ap=0xf7c46e28)
at ../../ufs/ufs/ufs_vnops.c:2294
#9 0xf015a405 in lookup (ndp=0xf7c46ea8) at vnode_if.h:31
#10 0xf0159ed8 in namei (ndp=0xf7c46ea8) at ../../kern/vfs_lookup.c:152
#11 0xf015f5a0 in stat (p=0xf7b8b3c0, uap=0xf7c46f84)
---Type return to continue, or q return to quit---
at ../../kern/vfs_syscalls.c:1614
#12 0xf01dad47 in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 136292736,
tf_esi = 0, tf_ebp = -272644404, tf_isp = -138121260,
tf_ebx = 134749056, tf_edx = 12, tf_ecx = 134749056, tf_eax = 188,
tf_trapno = 12, tf_err = 2, tf_eip = 134580048, tf_cs = 31,
tf_eflags = 582, tf_esp = -272644524, tf_ss = 39})
at ../../i386/i386/trap.c:1100
#13 0xf01cd85c in Xint0x80_syscall ()
#14 0x8050303 in ?? ()
#15 0x8049761 in ?? ()
#16 0x8057a79 in ?? ()
#17 0x8057a45 in ?? ()
#18 0x80496e8 in ?? ()
#19 0x8057a79 in ?? ()
#20 0x8057a45 in ?? ()
#21 0x80496e8 in ?? ()
#22 0x8057a79 in ?? ()
#23 0x8057a45 in ?? ()
#24 0x80496e8 in ?? ()
#25 0x8049aa0 in ?? ()
#26 0x804fd0f in ?? ()
#27 0x80480e9 in ?? ()
(kgdb) frame 5
#5 0xf019b62f in ufs_lookup (ap=0xf7c46dcc) at ../../ufs/ufs/ufs_lookup.c:238
238 ep = (struct direct *)((char *)bp-b_data +
entryoffseti
nblock);
(kgdb) l
233 * Full validation checks are slow, so we only check
234 * enough to insure forward progress through the
235 * directory. Complete checks can be run by patching
236 * dirchk to be true.
237 */
238 ep = (struct direct *)((char *)bp-b_data +
entryoffseti
nblock);
239 if (ep-d_reclen == 0 ||
240 (dirchk ufs_dirbadentry(vdp, ep,
entryoffsetinblo
ck))) {
241 int i;
242
(kgdb) printf %p + %d\n, bp-b_data, entryoffset^Ht^Ginblock
0xf3743000 + 21209
(kgdb) printf %d: %s\n, p-p_pid ^H ^H, p-p_comm
68863: make
#relevant code:
bmask = VFSTOUFS(vdp-v_mount)-um_mountp-mnt_stat.f_iosize - 1;
if (nameiop != LOOKUP || dp-i_diroff == 0 ||
dp-i_diroff dp-i_size) {
entryoffsetinblock = 0;
Automated debug sanity checkers
I was thinking about the DIAGNOSTICS replacement macros and had a random thought... Suppose you're sitting in front of a ddb (or better yet gdb) prompt because your kernel has just crashed due to who knows what reason. What do you do to debug this? You start looking at variables, memory, etc for anything funny going on. For example, several times we've spent hours going through a crash dump to find, for example, that a process was on two queues, or some mbuf was mangled, etc. The thought is that it would be really easy to help automate this process, by doing the following: 1. Define a new kernel option INCLUDE_SANITY_CHECKS (or whatever) 2. When this is defined, all the various FreeBSD kernel submodules (VM, networking, device drivers, etc) would include a function that exhaustively runs sanity checks -- ie, validations that all the assumptions in the code are true -- for that particular submodule. This means checking all queues, flags, whatever. 3. The function is required to only READ memory, not modify it. It can report any inconsistencies, though, obviously. 4. The function is linked into a linker set SANITY_SET(...) or whatever Then by simply calling this function from the debugger you can much more quickly narrow down on the problem (and hopefully fix it before you get tired and go to sleep :-) Moreover, since the function is running post-mortem, it can do very detailed checks that would otherwise take way too long. E.g., check every mbuf, every queue entry, check the filesystem, etc. Basically a fsck for the kernel memory. Is this something that people would be motivated enough to make as official FreeBSD kernel good housekeeping policy? -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Can the bootloader create a file or set a flag in the bootblocks?
Archie Cobbs writes: Jaye Mathisen writes: It would be kind of cool if when managing a remote system if /kernel failed to boot, then on the next boot, the loader will fire up /kernel.old, or a /kernel.somethingorother. Sort of a kernel-clean flag. Then 300 miles away, I can try stuff, and have at least some assurance that I'll eventually be able to get back to a kernel I could use. In case in that discussion it wasn't clear, there *is* a way to do this: see man nextboot. Oops, sorry.. nextboot of course doesn't work with the new bootblocks.. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Automated debug sanity checkers
On Fri, Jan 15, 1999 at 09:12:07PM -0800, Archie Cobbs wrote: I was thinking about the DIAGNOSTICS replacement macros and had a random thought... Suppose you're sitting in front of a ddb (or better yet gdb) prompt because your kernel has just crashed due to who knows what reason. What do you do to debug this? You start looking at variables, memory, etc for anything funny going on. For example, several times we've spent hours going through a crash dump to find, for example, that a process was on two queues, or some mbuf was mangled, etc. The thought is that it would be really easy to help automate this process, by doing the following: 1. Define a new kernel option INCLUDE_SANITY_CHECKS (or whatever) INVARIANT_SUPPORT. Hey, I just happen to remember that somebody added this a couple of days ago - hmm, could it have been me? :-) 2. When this is defined, all the various FreeBSD kernel submodules (VM, networking, device drivers, etc) would include a function that exhaustively runs sanity checks -- ie, validations that all the assumptions in the code are true -- for that particular submodule. This means checking all queues, flags, whatever. Ie, invariants. 4. The function is linked into a linker set SANITY_SET(...) or whatever I've not thought of that - that may be a good idea. Then by simply calling this function from the debugger you can much more quickly narrow down on the problem (and hopefully fix it before you get tired and go to sleep :-) Moreover, since the function is running post-mortem, it can do very detailed checks that would otherwise take way too long. E.g., check every mbuf, every queue entry, check the filesystem, etc. Basically a fsck for the kernel memory. You do not only want to call this at post-mortem. You often want to selectively use this while the kernel is running. Example: At one point (a year and half or so ago), I was debugging the tty driver in bisdn. For some reason, it was crashing in various ways at various times, with no sane reason - just garbage data. I spent quite a bit of time looking at this, finding no reason for the faults - they just happened, taking on average perhaps 4 hours hours under load to trigger. As I was getting more and more frustrated with attempting to shotgun debug this, I went back to my normal mode of development - I wrote invariants for all data structures in the vicinity. When I added an invariant for the clist structures (and check of it all over the place), I found that my crash (now an invariant incorrect panic) time went down to two minutes - and that it was always the same way, with the same stack backtrace, instead of crashing at various random points. The reason for the bug turned out to be that both I and the implementor of the driver had missed the change of spls from levels in BSD4.4 to masks in FreeBSD. After I had seen the invariant failure, I could see that something was being interrupted between two spls - and after 3 minutes of reading the FreeBSD manpage and three lines of changes I had something that worked. That driver had been non-functional for at least three releases of bisdn (and the userland code to handle it was not even there, which I expect was due to this). I further expect that somebody had tried pretty hard to debug it, as they had spent the time to actually write it. The fact that I (which at that point had little experience with the FreeBSD kernel) was able able to debug that in a couple of hours where others had used more time and failed before me show some of the power of invariants for finding obscure bugs. I would like to have invariants available for all significant data structures, and I'm planning to write them up as I get time for it. Is this something that people would be motivated enough to make as official FreeBSD kernel good housekeeping policy? I suspect a large number of us will use it, making it likely it will sort of maintain itself. Eivind. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Gratuitous name changes (was: libalias and ident)
If libalias changes to libnat, I'd prefer to just change the ppp flag to -nat, update the ppp version to 2.1 and update You would change it, and you'd only document -nat, but you'd still preserve -alias as a synonym for it (for at least a year or so) because otherwise: But this isn't necessarily a good idea as it may attract a pile of ``why the hell did you break my configuration for no good reason'' messages. That will happen. :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
another texinfo buglet?
I cvsupped a couple of times, even blew away the entire contrib/texinfo and gnu/usr.bin/texinfo in the middle but I still get this === === makeinfo cc -O -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\/usr/share/local\ -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/lib -I../libintl -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo/makeinfo.c /usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo/makeinfo.c: In function `xrealloc': /usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo/makeinfo.c:1205: parse error before `void' : === Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NFS woes: getting worse?
* From: as...@freebsd.org (Satoshi Asami) * * * From: Chris Timmons skyn...@opus.cts.cwu.edu * * * make: don't know how to make Makefiles. Stop * * I've seen similar things, but they went away when I reduced the load * (other compilations in my case) on the server. How busy is your * server? Forgot to mention, this happens with a read-only NFS tree too. I was running builds on the client with a shared /usr/ports and WRKDIRPREFIX pointing to a local directory, and the build will topple over in the middle unable to find a Makefile on the server or something. That is the problem that went away with the server load. Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NFS woes: getting worse?
:Forgot to mention, this happens with a read-only NFS tree too. I was :running builds on the client with a shared /usr/ports and WRKDIRPREFIX :pointing to a local directory, and the build will topple over in the :middle unable to find a Makefile on the server or something. : :That is the problem that went away with the server load. : :Satoshi I am running a Dec 24th CVS tree while working on the first set of VM commits. I've been using read-only NFS mounts of /usr/src on diskless workstations in order to do make -j6 buildworld runs on them ( /usr/obj being a big 300 MB MFS filesystem on the same workstation, swap-backed, where swap itself is BOOTP NFS based swap). I have not experienced any NFS corruption at all, so whatever blew NFS up must have been committed after Dec 24th. Note that I *AM* using luoqi's VFS/BIO patches, which fixed the msdosfs mount-after-ufs-mount-attempt crash. I'll have time to help track down the NFS problems after the tree splits and I can commit the new swapper, but I can't update my tree until then. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
typo in src/gnu/usr.bin/texinfo/makeinfo/Makefile
silver% cat /usr/src/gnu/usr.bin/texinfo/makeinfo/Makefile # $Id: Makefile,v 1.8 1999/01/14 20:00:46 markm Exp $ (snip) CFLAGS+= -DLOCALEDIR=\/usr/share/local\ ^ this should be 'locale'... Seigo TANIMURA |M1, Nakagawa Lab, Dept of Electronics CS =|Faculty of Engineering, Yokohama National Univ Powered by SIEMENS, |http://www.naklab.dnj.ynu.ac.jp/~tanimura/ FreeBSD 3.0-CURRENT |http://www.sakura.ne.jp/~tcarrot/ (2nd Jan 1999) muesli. |tanim...@naklab.dnj.ynu.ac.jp tcar...@sakuramail.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: another texinfo buglet?
* ===
* === makeinfo
* cc -O -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\/usr/share/local\
-I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo
-I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo
-I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/lib
-I../libintl -I/usr/obj/usr/src/tmp/usr/include -c
/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo/makeinfo.c
*
/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo/makeinfo.c:
In function `xrealloc':
*
/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo/makeinfo.c:1205:
parse error before `void'
* :
* ===
I looked into it a bit more. This file is definitely corrupted.
These are the lines around 1205:
===
/* Like realloc (), but barfs if there isn't enough memory. */
void *
xrealloc (pointer, nbytes)
void *pointer;
unsigned int nbytes;
{
void *temp;
if (!pointer)
temp = (void *)xmalloc (nbytes);
else
temp = (void *)realloc (pointer, nbytes);
/* If EXIT_VALUE is zero, print the full usage message to stdout.
Otherwise, just say to use --help for more info.
Then exit with EXIT_VALUE. */
void === 1205
usage (exit_value)
int exit_value;
{
if (exit_value != 0)
fprintf (stderr, _(Try `%s --help' for more information.\n), progname);
else
printf (_(Usage: %s [OPTION]... TEXINFO-FILE...\n\
===
Line 1205 is the void before usage(). It looks like (at least) the
second half of xrealloc() is missing.
Satoshi
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Which sound card now?
Some weeks or days ago my GUS MAX (non-PnP) became a relic when Voxware was axed from FreeBSD. Eventhough, Voxware was reinstated, I diligently went about finding a Luigi-Approved sound card. After weeks of research I came to the conclusion that the 'Aopen AW 37 Pro' was the card of choice. I then set about ordering 2. Two different companies have told me that the card is no longer made. So I am now mostly back the square 1. I'm still using an old GUS MAX, which at the whim of FreeBSD-core may suddenly stop working. And I have no idea what modern card will be reasonably well supported under pcm0. Does anyone have any suggestions? -- Brian Litzinger br...@litzinger.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Which sound card now?
* From: br...@worldcontrol.com * So I am now mostly back the square 1. I'm still using an old GUS MAX, * which at the whim of FreeBSD-core may suddenly stop working. Just one point -- the axing of voxware was *not* approved by FreeBSD-core, and that's why it has been brought back. Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: another texinfo buglet?
I'll third that. Eddie. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NFS woes: getting worse?
Hi, On Fri, 15 Jan 1999, Bjoern Fischer wrote: On Thu, Jan 14, 1999 at 08:03:46PM -0800, Chris Timmons wrote: I have duplicated on two pairs of machines a case whereby you have two -current machines as of ~20:00 UTC 1999/Jan/14 which cannot interoperate via NFS without corruption. [...] 18034 bytes read by the NFS client, 19229 bytes read on the local system! The file shown in the kdump output above is Makefile (see path below), and we can see that it's true size is 19229. This is just one instance of the problem. [...] Same problems here -- or even worse. Running -current on a NFS-server and several diskless clients attached to it (I like the silence at my desk), I get truncated files and NFS-writes with a lot of ^...@^@^...@^@^@ and some other garbage in it. I'm seeing the same thing with src-cur.3700, ~10 Jan. Doing `make depend' for the kernel I get the ^...@^@+crap towards the end of .depend, and it's completely repeatable. Guess I'll see what tcpdump has to say unless someone can suggest something more effective. The server is otherwise unloaded, so I guess load isn't a factor. FWIW, the client is a rather faster machine than the server and the link is 10Mb. -- Bob Bishop +44 118 977 4017 r...@gid.co.uk fax +44 118 989 4254 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ZIP+ detection, need testers for the patch
On Fri, 15 Jan 1999, Nicolas Souchu wrote: Hi there, Currently, the ZIP+ probe is intrusive and sends char to the printer if no ZIP+ is connected. Here is a patch that corrects the problem for my printer, but I haven't any ZIP+ :) So, please check the ZIP+ is still detected. With this patch, I can *not* detect my ZIP+ (attached to a machine which detects it using the existing code). -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Which sound card now?
Eventhough, Voxware was reinstated, I diligently went about finding a Luigi-Approved sound card. After weeks of research I came to the conclusion that the 'Aopen AW 37 Pro' was the card of choice. ... And I have no idea what modern card will be reasonably well supported under pcm0. I have had good success recently with Yamaha ISA cards, e.g. YMF715 or YMF719. luigi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Which sound card now?
And I have no idea what modern card will be reasonably well supported under pcm0. Does anyone have any suggestions? Followup: Dru Nelson was so kind to post me the details of his research on this subject and told me the following: I just went to Central Computer www.centralcomputer.com. They are close to where I work. AXRA 16 Yamaha 719 3D Sound...$15.95 J-Bond MF-719 Yamaha 3D OPL-3 w Midi..$36 ESS 16 IDE 3D Sound Card..$14 Television:TeleSound EX16 IDE.$68 USSA ASW192 PCI Sound Card$24.95 Yamaha Wave Force 192XG PCI Sound Card oem$32 of the above, i think the first two can work reasonably well; the ESS might work (with the recent patches) for listening to mpeg audio, whereas the Yamaha PCI do not work because Yamaha are not disclosing programming info on them. cheers luigi ---+- Luigi RIZZO . EMAIL: lu...@iet.unipi.it. Dip. di Ing. dell'Informazione HTTP://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) ---+- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
