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 / Zach Heilig > 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: > > 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: 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.com<http://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
trap in ufs_lookup
>i_offset, NULL, &bp))) return (error); numdirpasses = 2; nchstats.ncs_2passes++; } (kgdb) printf "i_offset %d & bmask %d = %d\n", dp->i_offset, bmask, (dp->i_offset & bmask) i_offset 37593 & bmask 8191 = 4825 (kgdb) quit 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: 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: Suspend on Current
On Sun, 17 Jan 1999, Daniel C. Sobral wrote: > Is it just me, or is there anyone else experiencing system freezes > on current after a zzz? I tried it on an Intel chipset a while back, and got the same result. Of course, I disabled APM from then on :) > > -- > Daniel C. Sobral (8-DCS) > d...@newsguy.com > > If you sell your soul to the Devil and all you get is an MCSE from > it, you haven't gotten market rate. > > 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: Running old program on 3.0-RELEASE
On Sun, 17 Jan 1999, Igor Shulgin wrote: > I recently installed 3.0-RELEASE on existing 2.1.0-RELEASE. > After that one program does not run any more. > That program is being invoked by Apache daemon (now I use Apache 1.2.6 from > 3.0-RELEASE/packages) and is needed for access to some special part of our > WWW-server. After attempt of invocation this program accordingly to user's > action next message appears in /var/log/httpd-error.log : > "ld.so failed: Can't find shared library "libg++.so.3.0"" > User is seeing message "500 Internal Server Error" on his screen. > I have no influence on author of program mentioned above to prompt him to > recompile his program on 3.0-RELEASE. As I know this program successful works > on pack of 2.1.x and 2.2.x systems. > > I run "ldconfig -r" and not found "libg++.so.3.0" in list. > File /usr/lib/libg++.so.3.0 exist but have old date "Nov 16 1995" because > this file remained from old version. There is new file > /usr/lib/compat/libg++.so.3.0 with date "Oct 16 1997". There is line > ldconfig_paths="/usr/lib/compat /usr/X11R6/lib /usr/local/lib" > in file /etc/rc.conf and I see messages at rebooting about successful running > ldconfig on these directories. > Output of "ldconfig -r" has 1st and 2nd line: > "/var/run/ld-elf.so.hints > searching directories: /usr/lib:/usr/lib/compat:/usr/local/lib " > But there are not files from /usr/lib/compat in list. > > Is something incorrectly installed in my system? > Should I remove all files from /usr/lib with date "16 Nov 1995" and earlier? > Must I remove directory /usr/lib before any installation newer version above > older? > > Thanks in advance. All old /usr/lib files need to be moved to /usr/lib/compat or /usr/lib/aout. /usr/lib/compat is the better place because it contains OLD, not current, libs. Hint: do NOT save the archives "libfoo.a", they're for building new static executables, and you don't want to replace your much more current ars. Did you even try installing "compat21 compat22 compat1x" etc? > > --- With good wishes, > Igor Shulgin > 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: Running old program on 3.0-RELEASE
On Sun, 17 Jan 1999, Igor Shulgin wrote: > Brian Feldman wrote: > >All old /usr/lib files need to be moved to /usr/lib/compat or /usr/lib/aout. > >/usr/lib/compat is the better place because it contains OLD, not current, > libs. > > What about files which already exist in /usr/lib/compat directory with same > name but new date? Move them to /usr/lib/aout (may be to /usr/lib/compat/aout > ?) or simly remove them? libg++.so.3.0 is such case. > > >Hint: do NOT save the archives "libfoo.a", they're for building new static > >executables, and you don't want to replace your much more current ars. Did > you > >even try installing "compat21 compat22 compat1x" etc? > > > Of course. During installation I not checked "compat" but after installation > I run install.sh from compat1x compat21 compat22 directories of 3.0-RELEASE > distribution (in this order). Have order the meaning? Okay, try this: /bin/sh cd /usr/lib for i in *; do if file $i | grep FreeBSD/i386 >/dev/null; then rm $i; fi done After doing that, look in /etc/rc.conf and check if you have an ldconfig_paths_aout. If you don't, set it to something on the order of "/usr/X11R6/lib/aout /usr/local/lib/aout /usr/lib/aout /usr/lib/compat/aout /usr/lib/compat". Then try typing ldconfig -aout /usr/X11R6/lib/aout /usr/local/lib/aout \ /usr/lib/aout /usr/lib/compat/aout /usr /lib/compat You may want to also clean out /usr/local/lib, /usr/X11R6/lib, etc. to make certain no a.out is there. I'd do something like cd /usr/local/lib; mkdir aout for i in *; do if file $i | grep FreeBSD/i386 >/dev/null; then mv $i aout; fi \ done Cheers, > > >> --- With good wishes, > >> Igor Shulgin > >> > > Brian Feldman _ __ ___ ___ ___ > > gr...@unixhelp.org _ __ ___ | _ ) __| \ > > http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | > > FreeBSD: The Power to Serve!_ __ ___ _ |___/___/___/ > > > > 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: Running old program on 3.0-RELEASE
On Sun, 17 Jan 1999, Igor Shulgin wrote: > Brian Feldman wrote: > > > >Okay, try this: > > > >/bin/sh > >cd /usr/lib > >for i in *; do if file $i | grep FreeBSD/i386 >/dev/null; then rm $i; fi > done > > > >After doing that, look in /etc/rc.conf and check if you have an > >ldconfig_paths_aout. If you don't, set it to something on the order of > >"/usr/X11R6/lib/aout /usr/local/lib/aout /usr/lib/aout /usr/lib/compat/aout > /usr/lib/compat". > >Then try typing ldconfig -aout /usr/X11R6/lib/aout /usr/local/lib/aout \ > >/usr/lib/aout /usr/lib/compat/aout /usr /lib/compat > > > Thank you very much for your help! > After doing this I see strange (for me) thing: files in /usr/lib/compat is > not showed in "ldconfig -r -elf" nor "ldconfig -r -aout". After this I move > directory /usr/lib/compat from ldconfig_paths to ldconfig_paths_aout in file > rc.conf . And now all works! > Is it mistake in file rc.conf (I did not modify it before) or my system is > incorrectly configuring? I use /usr/lib/compat in both of those, because older compat stuff is in there, as is newer. /usr/lib/compat/aout is just aout, but /usr/lib/compat seems to be a mix of ELF and a.out, now. Glad I could help! > > --- With good wishes, > Igor Shulgin > > >> > Brian Feldman _ __ ___ ___ ___ > >> > gr...@unixhelp.org _ __ ___ | _ ) __| \ > >> > http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | > >> > FreeBSD: The Power to Serve!_ __ ___ _ |___/___/___/ > >> > >> > >> > >> > > > > Brian Feldman _ __ ___ ___ ___ > > gr...@unixhelp.org _ __ ___ | _ ) __| \ > > http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | > > FreeBSD: The Power to Serve!_ __ ___ _ |___/___/___/ > > > > > > > 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: kernel malloc and M_CANWAIT
On Mon, 18 Jan 1999, Mike Smith wrote: > > > > Here at whistle we are trying to remember about a conversation > > regarding malloc that occured recently. Maybe others can help. > > > > There was some talk about the fact that malloc(..M_CANWAIT) > > can now return with a failure. Is that true? > > Yes; it's necessary to do this to allow some chance of avoiding > deadlock. Ouch! Is everything in src-sys already checking the return value of an M_WAITOK? > > -- > \\ 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: kernel malloc and M_CANWAIT
On Mon, 18 Jan 1999, Mike Smith wrote: > > On Mon, 18 Jan 1999, Mike Smith wrote: > > > > > > > > > > Here at whistle we are trying to remember about a conversation > > > > regarding malloc that occured recently. Maybe others can help. > > > > > > > > There was some talk about the fact that malloc(..M_CANWAIT) > > > > can now return with a failure. Is that true? > > > > > > Yes; it's necessary to do this to allow some chance of avoiding > > > deadlock. > > > > Ouch! Is everything in src-sys already checking the return value of an > > M_WAITOK? > > Probably not, no. I had some patches from Andrzej who was trying to do > it just for the mbuf allocator case; there's definitely a call for > someone to take the time to clean things up. Well, it'll be hard to determine (for me, not knowing any of the kernel well) whether it's proper for: a. return EAGAIN b. return ENOMEN c. try again, then return EAGAIN/ENOMEM? But I'm going to start fixing what I can. It would have been nice for a HEADS UP! or somesuch. > > -- > \\ 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: kernel malloc and M_CANWAIT
On Mon, 18 Jan 1999, Mike Smith wrote:
> > > So malloc() will generally not return NULL even in low memory
> > > situations
> > > unless the KVM map fills up, which isn't supposed to happen but can in
> > > certain severe circumstances. Callers should therefore check for
> > > NULL.
> >
> > why not just put it in a loop and block on lbolt?
> > (or call panic)
>
> Because you shouldn't panic unless there's no alternative. Panicking
> on resource starvation is just totally lame.
And what's wrong with spinning inside malloc until the resources are free?
There are places that architecturally require M_WAITOK to not return NULL.
Look at the void () functions that call malloc/MALLOC. Also, commit the
attached patch; it was OKed by Bruce to disallow this, but he seems to forget
to commit it.
>
> --
> \\ 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! _ __ ___ _ |___/___/___/
--- src/sys/kern/vfs_syscalls.c.origFri Dec 25 22:27:21 1998
+++ src/sys/kern/vfs_syscalls.c Fri Dec 25 22:28:12 1998
@@ -2909,6 +2909,10 @@
if (error = namei(&nd))
return (error);
vp = nd.ni_vp;
+ if (vp->v_type == VFIFO) {
+ error = EINVAL;
+ goto out;
+ }
if (error = VOP_GETATTR(vp, &vattr, p->p_ucred, p))
goto out;
if (p->p_ucred->cr_uid != vattr.va_uid &&
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re2: kernel malloc and M_CANWAIT
On Mon, 18 Jan 1999, Mike Smith wrote:
> > > So malloc() will generally not return NULL even in low memory
> > > situations
> > > unless the KVM map fills up, which isn't supposed to happen but can in
> > > certain severe circumstances. Callers should therefore check for
> > > NULL.
> >
> > why not just put it in a loop and block on lbolt?
> > (or call panic)
>
> Because you shouldn't panic unless there's no alternative. Panicking
> on resource starvation is just totally lame.
Ahem:
uipc_mbuf.c: unmodified, readonly: line 268 of 945 [28%]
panic("Out of mbuf clusters");
uipc_mbuf.c: unmodified, readonly: line 296 of 945 [31%]
panic("Out of mbuf clusters");
And if the max number of mbuf clusters is{, to become} a sysctl, shouldn't
these just be informative printf()s or something?
>
> --
> \\ 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: kernel malloc and M_CANWAIT
On Tue, 19 Jan 1999, Bruce Evans wrote:
> >Look at the void () functions that call malloc/MALLOC. Also, commit the
> >attached patch; it was OKed by Bruce to disallow this, but he seems to forget
> >to commit it.
>
> It is queued behind 10-100 other patches.
>
> >--- src/sys/kern/vfs_syscalls.c.orig Fri Dec 25 22:27:21 1998
> >+++ src/sys/kern/vfs_syscalls.c Fri Dec 25 22:28:12 1998
> >@@ -2909,6 +2909,10 @@
> > if (error = namei(&nd))
> > return (error);
> > vp = nd.ni_vp;
> >+if (vp->v_type == VFIFO) {
> >+error = EINVAL;
> >+goto out;
> >+}
> > if (error = VOP_GETATTR(vp, &vattr, p->p_ucred, p))
> > goto out;
> > if (p->p_ucred->cr_uid != vattr.va_uid &&
>
> Actually, the patch from Lite1 is queued. It also backs out support
> for revoke of everything except cdevs and bdevs. I don't have time to
> check what happens for regular files, pipes and sockets...
Hmm... that may be a good idea, although for it seems to work on all of them,
I haven't checked for any kind of leak in the others, nor would truly expect
one. And pipes ARE fifo's aren't they?
>
> Bruce
>
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: kernel malloc and M_CANWAIT
On Mon, 18 Jan 1999, Mike Smith wrote: > > >If the system is simply low on memory, kmem_malloc() will block. > > > > > >So malloc() will generally not return NULL even in low memory > > > situations > > >unless the KVM map fills up, which isn't supposed to happen but can in > > >certain severe circumstances. Callers should therefore check for NULL. > > > > Callers that check for NULL are bogus. > > If it can truly never return NULL, that's true. But it would also be > true to say that callers that can't deal with a veto return and that > can't guarantee deadlock avoidance are also bogus. > > I got the impression that my understanding of M_WAITOK's behaviour > came from a discussion with you about it, but it looks like I was > mistaken. Everyone else's impression of malloc M_WAITOK's behavior has always been that it could never return NULL, at least without (say) trying to allocate all available kernel memory. > > -- > \\ 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: linuxthreads, gimp 1.1+, dies
On Mon, 18 Jan 1999 br...@worldcontrol.com wrote: > I running gimp -unstable (CVS 1/17/1998) and FreeBSD -current > (1/17/1998) with > > CFLAGS= -O2 -m486 -pipe -DCOMPAT_LINUX_THREADS -DVM_STACK > COPTFLAGS= -O -pipe -DCOMPAT_LINUX_THREADS -DVM_STACK > > and linuxthreads port from http://lt.tar.com. > > recompiled glib, gtk+ and gimp which works fine reasonably > well without threads. > > with threads > CFLAGS="-D_THREAD_SAFE -I/usr/local/include -L/usr/local/lib -O2 -m486 -pipe > -lpthread" Where's -g? > > Everything compiles and it runs. However, various operations crash > for example: > > starting tile preswapper > /usr/local/bin/gimp fatal error: sigsegv caught > /usr/local/bin/gimp (pid:15557): [E]xit, [H]alt, show [S]tack trace or > [P]roceed: > S > #0 0x282a0326 in g_on_error_stack_trace ( > #1 0x282a0254 in g_on_error_query (prg_name=0xefbfdb40 "/usr/local/bin/gimp") > #2 0x808b867 in fatal_error () > #3 0x80cef0a in on_signal () > #4 > #5 0x8100a33 in tile_idle_thread () > #6 0x28155ea1 in pthread_start_thread (arg=0xeb7ffd08) > #7 0x2815650d in _clone () at clone.S:1 > #8 0x7202c in ?? () > #9 0x1 in ?? () > Try compiling with debugging info, get a coredump, and debug with the binary that has the full debugging symbols. > > -- > Brian Litzinger > > 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
Truth to M_WAITOK?
Would someone PLEASE tell us all if malloc can really return NULL now with flags & M_WAITOK? I've gotten contradictory answers... 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
kldload of procfs panics
I'm having a bit of trouble with 4.0-CURRENT as of last night. After fully
updating my system, on reboot procfs (a KLD module) panics the system as
follows: (more explanation after bt)
#9 0xf01d9c1a in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -142545460,
tf_esi = -250596864, tf_ebp = -142545512, tf_isp = -142545640,
tf_ebx = 0, tf_edx = 0, tf_ecx = 0, tf_eax = 10, tf_trapno = 12,
tf_err = 0, tf_eip = -266759770, tf_cs = 8, tf_eflags = 66134,
tf_esp = 880, tf_ss = -147665856}) at ../../i386/i386/trap.c:437
#10 0xf01991a6 in ffs_read (ap=0xf780edb0) at ../../ufs/ufs/ufs_readwrite.c:97
#11 0xf0161bbd in vn_rdwr (rw=UIO_READ, vp=0xf732cc40, base=0xf1104000 "",
len=880, offset=0x4418, segflg=UIO_SYSSPACE, ioflg=8,
---Type to continue, or q to quit---
cred=0xf05a0280, aresid=0xf780ee90, p=0xf7333620) at vnode_if.h:331
#12 0xf012d11f in link_elf_load_file (filename=0xf10a8d90 "procfs.ko",
result=0xf780ef2c) at ../../kern/link_elf.c:635
#13 0xf012cb76 in link_elf_load_module (filename=0xf10a8d90 "procfs.ko",
result=0xf780ef2c) at ../../kern/link_elf.c:340
#14 0xf012afa3 in linker_load_file (filename=0xf1104c00 "procfs",
result=0xf780ef4c) at ../../kern/kern_linker.c:263
#15 0xf012b782 in kldload (p=0xf7333620, uap=0xf780ef84)
at ../../kern/kern_linker.c:655
#16 0xf01da56f in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = -272638612,
tf_esi = -1, tf_ebp = -272638580, tf_isp = -142544940,
tf_ebx = -272638324, tf_edx = 99, tf_ecx = 10, tf_eax = 304,
tf_trapno = 12, tf_err = 2, tf_eip = 134517080, tf_cs = 31,
tf_eflags = 662, tf_esp = -272638620, tf_ss = 39})
at ../../i386/i386/trap.c:1100
#17 0xf01ccf2c in Xint0x80_syscall ()
#18 0x8048245 in ?? ()
#19 0x80480e9 in ?? ()
(kgdb) frame 10
#10 0xf01991a6 in ffs_read (ap=0xf780edb0) at ../../ufs/ufs/ufs_readwrite.c:97
97 if ((u_int64_t)uio->uio_offset > fs->fs_maxfilesize)
(kgdb) printf "%p\n", fs
0x0
Now fs is part of strucct inode in the vnode, but struct inode seems to be
TOTALLY ZERO! After rebooting, a fsck fixes all filesystems and the system
boots fine, but on any _clean_ boot, procfs panics. I have absolutely no idea
what could be causing this, but that I know procfs is the first module loaded
and if I use the boot loader to load kernel+procfs first, nothing panics (e.g.
kernfs). Anyone have an idea?
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: Using LinuxThreads
On Fri, 22 Jan 1999, Doug Rabson wrote: > On Thu, 21 Jan 1999, Julian Elischer wrote: > > > > > > > On Thu, 21 Jan 1999, Richard Seaman, Jr. wrote: > > > > > > And when are COMPAT_LINUX_THREADS and VM_STACK going away? > > > > > > I have no idea. I was hoping that at least COMPAT_LINUX_THREADS > > > would go away before the branch. I don't have commit authority, > > > so it isn't up to me. > > > > > > > hmm did you send me the patches? > > > > I can certainly do it now..(given a patch set to apply) > > > > I just realised however, that if we make them go away we break > > SMP right? > > hmm I guess we only break it for programs that woudltry use it > > which should be none if you run SMP :-) > > It doesn't break SMP (I'm running an SMP kernel with > COMPAT_LINUX_THREADS). All that happens is that linux_clone() returns > an error. Surprisingly StarOffice still works fairly well. StarOffice 5.0? Is this with Luoqi's shared process across SMP patches? > > -- > 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 > 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: kvm_getswapinfo() function added to libkvm. top, pstat, systat updated
On Fri, 22 Jan 1999, Matthew Dillon wrote: > A new function, kvm_getswapinfo(), has been added to libkvm. > > pstat, systat, and top have been updated to use the new function. > > -Matt > > Matthew Dillon > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > Where's struct kvm_swap and typedef struct kvm_swap *kvm_swap_t supposed to now be? 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: kvm_getswapinfo() function added to libkvm. top, pstat, systat updated
On Fri, 22 Jan 1999, Garrett Wollman wrote: > < said: > > > Where's struct kvm_swap and typedef struct kvm_swap *kvm_swap_t supposed to > > now be? > > Hopefully the latter isn't anywhere, since style(9) says very > specifically that such typedefs are Not To Be Introduced. This doesn't change the fact that there seems to be them... Of course, without these definitions libkvm no longer will compile. > > -GAWollman > > -- > Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the > same > woll...@lcs.mit.edu | O Siem / The fires of freedom > Opinions not those of| Dance in the burning flame > MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick > 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: panic: found dirty cache page 0xf046f1c0
On Fri, 22 Jan 1999, Manfred Antar wrote:
> At 10:34 AM 1/23/99 +0800, Peter Wemm wrote:
> >Dual p5-90 w/ 48M ram, doing a major cvs update/merge (which mostly got
> >lost):
> >
> >panic: found dirty cache page 0xf046f1c0
> >mp_lock = 0101; cpuid = 1; lapic.id = 0100
> >Debugger("panic")
> >Stopped at Debugger+0x37: movl$0,in_Debugger
> >db> trace
> >Debugger(f01f1806) at Debugger+0x37
> >panic(f01fbb50,f046f1c0,0,80,f45cbb20) at panic+0xa4
> >vm_page_alloc(f45f6f68,80,3,0,80) at vm_page_alloc+0x114
> >vm_page_grab(f45f6f68,80,83,0,80) at vm_page_grab+0x8d
> >_pmap_allocpte(f45cbb20,80,201df000,201df000,2a86000) at _pmap_allocpte+0x19
> >pmap_allocpte(f45cbb20,201df000,f02c4df4,201df000,f45cbac0) at
> >pmap_allocpte+0x53
> >pmap_enter(f45cbb20,201df000,2a86000,5,0) at pmap_enter+0x3d
> >vm_fault(f45cbac0,201df000,1,0,f4195180) at vm_fault+0x891
> >trap_pfault(f45f9fbc,1,201df236) at trap_pfault+0xf2
> >trap(27,27,,5,efbfad38) at trap+0x1c2
> >calltrap() at calltrap+0x3c
> >--- trap 0xc, eip = 0x201df236, esp = 0xefbfac4c, ebp = 0xefbfad38 ---
> >db> c
> >boot() called on cpu#1
> >
> >syncing disks... 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232
> >232
> > 232 232 232 232 giving up
> >1: dev:, flags:20020034, blkno:1057008, lblkno:0
> >[..]
> >
> >This was compiled two houts ago from absolute latest -current:
> >FreeBSD spinner.netplex.com.au 4.0-CURRENT FreeBSD 4.0-CURRENT #385:
> >Sat Jan 23 08:38:42 WST 1999
> >pe...@spinner.netplex.com.au:/home/src/sys/compile/SPINNER i386
> >
> >My other SMP machine (2xPPro200) seems to be running fine:
> >FreeBSD beast.netplex.com.au 4.0-CURRENT FreeBSD 4.0-CURRENT #267:
> >Thu Jan 21 21:39:45 WST 1999
> >pe...@beast.netplex.com.au:/home/src/sys/compile/BEAST i386
> >
> >Cheers,
> >-Peter
> >
> I just got the same thing doing a make -j8 world
> Machine is a dual pentium pro Intel PR440FX
> This must be from the recent vm changes as I could make -j8 world
> continually a
> few days ago without problem. This is the second time it happened to me
> the first time I was running X so I couldn't see the debugger message .
> This time without X I got the :
>
> panic: found dirty cache page
You should definitely be using DDB_UNATTENDED, by the way, if you're going
to be running X and want DDB but not to have DDB try to pop up on a panic.
I did get DDB_UNATTENDED behavior finally working as well as it should, so
there's no reason not to use it.
>
> Manfred
> =
> ||man...@netcom.com||
> ||p...@infinex.com ||
> ||Ph. (415) 681-6235||
> =
>
>
> 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: panic: found dirty cache page 0xf046f1c0
On Sat, 23 Jan 1999, Matthew Dillon wrote: > Yes, we're working on it in a sub-group. > > Since the panic message is a new one -- it's one I added that never > existed > in -3.x, it is possible that the bug is not related to my VM stuff but > related to something else going on. > > I've found a number of other bugs in the greater VM system which I am > comitting fixes for, *BUT* I don't think any of them are related to this > particular panic. > > I am also comitting some very strict KASSERT checking to try to catch > the problem earlier. Everyone running 4.x kernels should add the > following Ahem, would you kindly define 'everyone'? > options to your kernel config: > > options INVARIANTS > options INVARIANT_SUPPORT > > > -Matt > Matthew Dillon > > > :On Sun, 24 Jan 1999, Peter Wemm wrote: > : > :[..] > :> Oh, one other thing that occurred to me.. Under 4.0-current, I regularly > :> (ie: within 30 seconds of boot) get if_de tranmitter underflows. My > :> console corruption was happening at the instant that de0 was being > :> configured with ifconfig. exmh is running to a remote display over that > :> de0 interface. > : > :Here too... pretty quickly after boot on a SMP machine (current as of Jan > :12) that pushes quite a bit of traffic, the following messages appear: > : > :de0: abnormal interrupt: transmit underflow (raising TX threshold to 96|256) > :de0: abnormal interrupt: transmit underflow (raising TX threshold to 128|512) > :de0: abnormal interrupt: transmit underflow (raising TX threshold to > 160|1024) > : > :The card is: > : > :de0: rev 0x22 int a irq 16 on pci0.12.0 > :de0: 21140A [10-100Mb/s] pass 2.2 > :de0: address 00:c0:f0:1f:5d:0d > :de0: enabling Full Duplex 100baseTX port > : > :Actually a Kingston clone, not a real DEC (so 1/5th of the price - but the > :receiver doesn't go audibly *click* when it's autosensing). > : > :So far I've gotten this message once: > : > :de0: abnormal interrupt: transmit underflow (switching to store-and-forward > mode) > : > :Any harm in them, or can I safely ignore them? Would it be a good idea to > :raise the TX threshold by default, if only to avoid the messages? > :It's plugged into a Catalyst switch, if it makes any difference... > : > : > : -- Niels. > : > : > :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 > 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: 2Re: panic: found dirty cache page 0xf046f1c0
On Sat, 23 Jan 1999, Matthew Dillon wrote:
>
> :
> :i have 'ed' driver and mine blows up as well.
> :
> :panic: found dirty cache page 0xf047ae60
> :Debugger("panic")
>
> Ok, so much for if_de being the cause.
>
> BTW, for anybody who doesn't want to wait for us to find the
> bug, you can comment out the MADV_FREE code and that should
> put a stop to it. The MADV_FREE code isn't broken, but it seems
> to cause the bug to occur which is why *I* haven't commented
> it out - I'd rather find the bug.
>
> Also, update your kernel trees and turn on the INVARIANTS options:
>
> options INVARIANTS
> options INVARIANT_SUPPORT
>
> -Matt
> Matthew Dillon
>
>
> :
> :btw, i'm hardly 'stressing' this machine it's a k6-233+96ram and
> :i'm running X and doing a 'make release'
> :
> :Is it safe to enable crashdumps on IDE disks yet?
> :
> :-Alfred
>
> I don't know.
>
> I wasn't aware that there was a problem with crash dumps on
> ide disks. There shouldn't be.
>
Crashdumps on IDE disks never stopped working for me.
>
> 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
Addition to /etc/rc, maybe
How does this look? --- src/etc/rc.orig Mon Jan 25 17:39:07 1999 +++ src/etc/rc Mon Jan 25 17:43:52 1999 @@ -152,6 +152,16 @@ clean_var fi +# Load the vn module, if enabled. +if [ "X$vn_enable" = "XYES" ]; then + echo "Loading vn module." + if [ -f /modules/vn.ko ]; then + kldload vn + else + echo "Cannot find /modules/vn.ko." + fi +fi + # Add additional swapfile, if configured. if [ "x$swapfile" != "xNO" -a -w "$swapfile" -a -b /dev/vn0b ]; then echo "Adding $swapfile as additional swap." --- src/etc/rc.conf.origMon Jan 25 17:36:03 1999 +++ src/etc/rc.conf Mon Jan 25 17:44:14 1999 @@ -12,7 +12,9 @@ ### Important initial Boot-time options # ## +vn_enable="NO" # Set to YES if you want the vn kld loaded. swapfile="NO" # Set to name of swapfile if aux swapfile desired. + # This needs pseudo-device vn or vn_enable="YES". apm_enable="NO"# Set to YES if you want APM enabled. pccard_enable="NO" # Set to YES if you want to configure PCCARD devices. pccard_mem="DEFAULT" # If pccard_enable=YES, this is card memory address. 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: dummynet causes crash?
On Sun, 24 Jan 1999, Luigi Rizzo wrote:
> which version of ip_dummynet are you using. There were lately a few
> changes to fix a problem related to route entries being freed in the
> wrong way.
>
> > .(02:36:11)(r...@bright.reserved)
> > ipfw add pipe 1 ip from server to cvsup.freebsd.org
> > (long pause i assume DNS)
> > 0 pipe 1 ip from 192.168.2.20 to 198.104.92.71
> ...
> >
> > Fatal trap 12: page fault while in kernel mode
> > fault virtual address = 0xdeadc116
>
> interestingly enough, the above address is "0xdeadbeef + 551 (decimal)".
> It looks like somehow a wrong route entry was passed to ether_output().
>
> > the only thing i can think of is that dummynet doesn't like not being told
> > if a pipe is 'in' or 'out' :/
>
> nope -- it can detect this by itself. the problem must be elsewhere.
> if you have more input on the dummynet version (as per the CVS log)
> and os version please let me know.
>
> > my ether card is a: ed card, a 'realteck 8029'
>
> ... and the network card does not make a difference, dummynet works at
> a layer above.
>
> cheers
> luigi
{"/home/green"}$ calc 0xdeadc116 - 0xdeadc0de
56
possibly? IIRC 0xdeadc0de is used to fill freed memory areas in certain cases,
to help detect programming errors related to such.
>
> 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: Heads up! New swapper and VM changes have been committed to -4.x
On 24 Jan 1999, Dag-Erling Smorgrav wrote: > Boris Staeblow writes: > > Beside your suggestions there are much more programs which use > > libkvm: > > > > /bin/ps/ > > /libexec/rpc.rstatd/ > > /sbin/ccdconfig/ > > /sbin/dmesg/ > > These are statically linked, and must be relinked after libkvm has > been rebuilt. > > > /sbin/dset/ > > This does not exist anymore. > > > /usr.bin/fstat/ > > /usr.bin/gcore/ > > /usr.bin/ipcs/ > > /usr.bin/netstat/ > > /usr.bin/nfsstat/ > > /usr.bin/systat/ > > /usr.bin/top/ > > /usr.bin/vmstat/ > > /usr.bin/w/ > > /usr.sbin/iostat/ > > /usr.sbin/kernbb/ > > /usr.sbin/kgmon/ > > /usr.sbin/pstat/ > > /usr.sbin/xntpd/xntpd/ > > These are dynamically linked, and will automatically pick up the new > libkvm. > But (most) still require the structures to be the exact same way, which is the reason for the recompile anyway... don't forget that! > DES > -- > Dag-Erling Smorgrav - d...@flood.ping.uio.no > > 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: IDE DMA works, I'll be a...
On Sun, 24 Jan 1999, Matthew Dillon wrote: > > :> I haven't cvs updated in 24 hours, if the Acer is newly committed then > I'll > :> have to update again and retry. The CTX is using the Acer. > :> > :> ide_pci0: rev 0x20 > int a irq 0 on pci0.11.0 > : > : > :It's there...what symptoms are you seeing? Are you overclocking? > :-- > :++ > :| Lee Cremeans -- Manassas, VA, USA (WakkyMouse on DALnet and WTnet)| > > > No overclocking. Stock CTX box. Could it be the drive, maybe? > > I only get 2.4 MBytes/sec, same as before. On my PPro box ( Intel > PIIX3 Bus-master IDE controller ) it went from around 2.4 MB/sec > to 8 MBytes/sec. > > archive:/cvs# time dd if=/dev/zero of=test2 bs=32k count=1024 > 1024+0 records in > 1024+0 records out > 33554432 bytes transferred in 13.700387 secs (2449159 bytes/sec) > 0.000u 2.728s 0:13.75 19.7% 357+1405k 5+525io 1pf+0w > Hmm, this is strange. I used to be able to get >3MB/s with an old chipset and plain K6, now with ide_pci0: rev 0x20 int a $ wdc0 at 0x1f0-0x1f7 irq 14 flags 0xa0ffa0ff on isa wdc0: unit 0 (wd0): , DMA, 32-bit, multi-block-32 wd0: 1554MB (3183264 sectors), 3158 cyls, 16 heads, 63 S/T, 512 B/S wdc0: unit 1 (wd1): , DMA, 32-bit, multi-block-32 wd1: 1554MB (3183264 sectors), 3158 cyls, 16 heads, 63 S/T, 512 B/S wdc1 at 0x170-0x177 irq 15 flags 0xa0ffa0ff on isa wdc1: unit 0 (atapi): , removable, iordy wfd0: medium type unknown (no disk) wdc1: unit 1 (atapi): , removable, dma, iordy This is strange, because DMA enabled on wd[01] and acd0 doesn't seem to... err "work". I say this because I am down to ~2.5MB/s on each hard drive, a MB or so decrease; I also seem to be reading (bs=512k) from the CD uncooked device at the right speed (~2MB/s), but it takes up 40% of the CPU, which seems to be just PIO. Anyone else? > > -Matt > Matthew Dillon > > > ide_pci0: rev 0x20 int > a irq 0 on pci0.11.0 > wdc0 at 0x1f0-0x1f7 irq 14 flags 0xa0ffa0ff on isa > wdc0: unit 0 (wd0): , 32-bit, multi-block-16 > wd0: 3832MB (7849170 sectors), 8306 cyls, 15 heads, 63 S/T, 512 B/S > wdc1 at 0x170-0x177 irq 15 flags 0xa0ffa0ff on isa > wdc1: unit 0 (atapi): , removable, dma, iordy > > > 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: IDE DMA works, I'll be a...
On Mon, 25 Jan 1999, Matthew Dillon wrote:
> :On Mon, 25 Jan 1999 19:40:38 EST, Brian Feldman wrote:
> :
> :> I say this because I am down to ~2.5MB/s on each hard drive, a MB or
> :> so decrease; I also seem to be reading (bs=512k) from the CD uncooked
> :...
> :
> :Since I rebuilt world shortly after Matt's VM surgery started, I've also
> :noticed this -- lower apparent transfer rates from /dev/zero to disk,
> :higher CPU usage during such transfers.
> :
> :I'm _not_ saying it's Matt's stuff that's done this, it's just that that
> :was the stuff I _noticed_ happening in commit mail. I think I saw
> :something happening to wd.c recently as well, so I _definitely_ am not
> :going on record as laying blame.
> :
> :Just some confirmation. :-)
> :
> :Ciao,
> :Sheldon.
>
> Hmm, interesting. A dd copy doesn't touch on the main of what I did,
> but I do have a (bad) hack in there to handle a case that John brought
> up in regards to the inactive page queue getting overloaded with
> clean meta-data. It might be interesting to turn that off and see if
> your transfer rates improve.
>
> You can turn off the hack by commenting out the case that activates
> it: Add the #if/#endif and split the open brace out from the else,
> as shown.
>
> I would like to know if your transfer rate improves or not, and by
> how much.
>
>
> /*
> * Figure out what to do with dirty pages when they are encountered.
> * Assume that 1/3 of the pages on the inactive list are clean. If
> * we think we can reach our target, disable laundering (do not
> * clean any dirty pages). If we miss the target we will loop back
> * up and do a laundering run.
> */
>
> #if 0
> if (cnt.v_inactive_count / 3 > page_shortage) {
> maxlaunder = 0;
> launder_loop = 0;
> } else
> #endif
> {
> maxlaunder =
> (cnt.v_inactive_target > max_page_launder) ?
> max_page_launder : cnt.v_inactive_target;
> launder_loop = 1;
> }
>
>
> -Matt
> Matthew Dillon
>
>
I'd rather use if (0 && cnt.v_inactive_count / 3 > page_shortage) {. I'm
trying it out now, here's the "before":
IOZONE performance measurements:
2972048 bytes/second for writing the file
2962863 bytes/second for reading the file
>
> 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: IDE DMA works, I'll be a...
On Mon, 25 Jan 1999, Matthew Dillon wrote:
> :> I would like to know if your transfer rate improves or not, and by
> :> how much.
> :>
> :> #if 0
> :> if (cnt.v_inactive_count / 3 > page_shortage) {
> :> maxlaunder = 0;
> :> launder_loop = 0;
> :> } else
> :> #endif
> :>{
> :>-Matt
> :
> :I'd rather use if (0 && cnt.v_inactive_count / 3 > page_shortage) {. I'm
> :trying it out now, here's the "before":
> :
> :IOZONE performance measurements:
> :2972048 bytes/second for writing the file
> :2962863 bytes/second for reading the file
> : Brian Feldman _ __ ___ ___ ___
>
> Welll... I went ahead and tested it on my diskless workstation,
> which actually has a DMA IDE drive connected to it at the moment
> for another test I'm running.
>
> I didn't see any change in performance. That doesn't meant that
> hasn't been a chance, just that it doesn't look like the one thing
> I thought might be causing it is causing it.
>
> Are you sure the problem isn't simply that your disk is getting
> a bit more full and causing the test to skip around more ( or move
> to more inner tracks, which have lower transfer rates), and
> thus appear to slow down a little ?
No, this REALLY isn't it. I have tons free on the test drive. iozone 100 on
a 64 mb system:
{"/home/green"}$ diff iozone.old iozone
15,16c15,16
< Writing the 100 Megabyte file, 'iozone.tmp'...37.320312 seconds
< Reading the file...37.710938 seconds
---
> Writing the 100 Megabyte file, 'iozone.tmp'...37.75 seconds
> Reading the file...37.687500 seconds
19,20c19,20
< 2809665 bytes/second for writing the file
< 2780562 bytes/second for reading the file
---
> 2777684 bytes/second for writing the file
> 2782291 bytes/second for reading the file
>
> -Matt
>
> Before ( iozone 64 on a 48MB machine )
>
> IOZONE performance measurements:
> 7809031 bytes/second for writing the file
> 10324440 bytes/second for reading the file
>
> IOZONE performance measurements:
> 8388608 bytes/second for writing the file
> 10324440 bytes/second for reading the file
>
> After ( iozone 64 on a 48MB machine )
>
> IOZONE performance measurements:
> 8103711 bytes/second for writing the file
> 10336864 bytes/second for reading the file
>
> IOZONE performance measurements:
> 8429768 bytes/second for writing the file
> 10324440 bytes/second for reading the file
>
> Matthew Dillon
>
>
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: IDE DMA works, I'll be a...
And here's with Soren's (sorry, I don't have any kind of European keyboard
mapping) patch.
{"/home/green"}$ diff3 iozone.old iozone iozone.newer
1:15,16c
Writing the 100 Megabyte file, 'iozone.tmp'...37.320312 seconds
Reading the file...37.710938 seconds
2:15,16c
Writing the 100 Megabyte file, 'iozone.tmp'...37.75 seconds
Reading the file...37.687500 seconds
3:15,16c
Writing the 100 Megabyte file, 'iozone.tmp'...39.187500 seconds
Reading the file...38.820312 seconds
1:19,20c
2809665 bytes/second for writing the file
2780562 bytes/second for reading the file
2:19,20c
2777684 bytes/second for writing the file
2782291 bytes/second for reading the file
3:19,20c
2675792 bytes/second for writing the file
2701101 bytes/second for reading the file
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
One answer, one question.
And the culprit for the Netscape problems is (drumroll please)
-DVM_STACK!
Now can someone help me out here, and figure out why:
{"/home/green"}$ ps
ps: bad namelist
{"/home/green"}$ sysctl kern.bootfile
kern.bootfile: /kernel
{"/home/green"}$ l /var/db/kvm_kernel.db
-rw-r--r-- 1 root wheel 1310720 Jan 27 00:53 /var/db/kvm_kernel.db
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: One answer, one question.
On Wed, 27 Jan 1999, Jeroen Ruigrok/Asmodai wrote:
> On 27-Jan-99 Brian Feldman wrote:
> > And the culprit for the Netscape problems is (drumroll please)
> > -DVM_STACK!
> > Now can someone help me out here, and figure out why:
> > {"/home/green"}$ ps
> > ps: bad namelist
> > {"/home/green"}$ sysctl kern.bootfile
> > kern.bootfile: /kernel
> > {"/home/green"}$ l /var/db/kvm_kernel.db
> > -rw-r--r-- 1 root wheel 1310720 Jan 27 00:53 /var/db/kvm_kernel.db
>
> Ye sure about it?
>
> I cannot remember that -DVM_STACK was used on 3.0 CURRENT when the problems
> were starting already.
>
> Also, I am also not seeing the relevance of ps. Sure, Matthew commited a
> bunch of VM hacks 'n fixes which appear to work nicely here (mayhaps even
> better than the prior stuff) and ps works properly. Ye sure yet not just
> forgetting to rebuild ps and the likes after the recent changes?
I am certain VM_STACK is breaking Netscape. Ps isn't related, but I am having
problems with it, even after rebuilding everything, kvm_mkdb'ing... :(
>
> ---
> Jeroen Ruigrok van der Werven It's a Dance of Energy,
> asmodai(at)wxs.nl when the Mind goes Binary...
> Network/Security Specialist <http://home.wxs.nl/~asmodai>
> BSD & picoBSD: The Power to Serve <http://www.freebsd.org>
>
> 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: 4.0-Current, netscape halts system
On Wed, 27 Jan 1999, Sheldon Hearn wrote: > > > On Tue, 26 Jan 1999 07:46:18 +0100, Jeroen Ruigrok/Asmodai wrote: > > > Yer kidding right? A program that _needs_ 100 MB or more? Surely yer > > kidding... I haven't seen a program in normal corporate/home use that > > justifies the memory usage of 100 MB or more including NetScape's > > Navigator/Communicator. > > You haven't had to provide an ISP-grade news or proxy service yet, have > you? :-) > > Ignoring that comment, since I assume you meant "I haven't seen an > end-user application in...", it _is_ conceivable that the way Netscape > keeps track of its cache _does_ mean an inevitable requirement for > enormous amounts of memory. > > I still don't think we're getting any closer to the question "Why is > Netscape unstable on CURRENT when it worked fine for me on STABLE?" The > problem seems to be that those who know enough to offer a useful answer > don't seem to be seeing the instability reported. > > So if this thread isn't going to be dropped, the focus should probably > be shifted to "What information should we request from people who have > this problem?" > > Ciao, > Sheldon. If you have Netscape problems, it would be worthwhile to try removing -DVM_STACK from src/sys/compile/BLAH/Makefile and doing a make clean all install. I am pretty certain this is the cause of Netscape crashing, at least on startup... > > 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: One answer, one question.
On Wed, 27 Jan 1999, Jeroen Ruigrok/Asmodai wrote: > On 27-Jan-99 Brian Feldman wrote: > > I am certain VM_STACK is breaking Netscape. Ps isn't related, but I am > > having problems with it, even after rebuilding everything, kvm_mkdb'ing... > > :( > > OK, I'm going to rebuild NetScape against the latest sources et al, I last > compiled it against a 3.0 CURRENT in December... > > Heh, did that while I was typing this mail... It doesn't appear to work any > differently then before (which means it will crash after a while). > > In what sense do ye think VM_STACK is related to the Netscape issue? I'd > love to hear what ye think causes it to bomb... I haven't really messed with it too much, so right now I think it's related because testing makes it appear to be. i.e. if I have a kernel with VM_STACK Netscape will sig11 right after loading; without VM_STACK it's as stable as ever. I'd love to figure out why ps isn't working, though... > > regards, > > --- > Jeroen Ruigrok van der Werven It's a Dance of Energy, > asmodai(at)wxs.nl when the Mind goes Binary... > Network/Security Specialist <http://home.wxs.nl/~asmodai> > BSD & picoBSD: The Power to Serve <http://www.freebsd.org> > 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: One answer, one question.
350 Restarting at 4087132. Send STORE or RETRIEVE to initiate transfer. 150 Opening BINARY mode data connection for mozilla-source.tar.gz (7854772 bytes). 37% |**| 4414 KB39:56 ETA When it's done, I'll work on figuring out the DNS problems. 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: 4.0-Current, netscape halts system
On Wed, 27 Jan 1999, Richard Seaman, Jr. wrote: > On Wed, Jan 27, 1999 at 10:20:14AM -0500, Brian Feldman wrote: > > On Wed, 27 Jan 1999, Sheldon Hearn wrote: > > > > > > I still don't think we're getting any closer to the question "Why is > > > Netscape unstable on CURRENT when it worked fine for me on STABLE?" The > > > problem seems to be that those who know enough to offer a useful answer > > > don't seem to be seeing the instability reported. > > > > > > So if this thread isn't going to be dropped, the focus should probably > > > be shifted to "What information should we request from people who have > > > this problem?" > > > > > > Ciao, > > > Sheldon. > > > > If you have Netscape problems, it would be worthwhile to try removing > > -DVM_STACK from src/sys/compile/BLAH/Makefile and doing a make clean all > > install. I am pretty certain this is the cause of Netscape crashing, at > > least > > on startup... > > Anything is possible. FWIW, though, I've been running with -DVM_STACK > enabled for over a month, and I use Netscape 4.5 everyday, and never had > a problem. Netscape 4.08 here, never had VM_STACK being used before most recent kernel. I booted with a new kernel to find out netscape sig11d on start-up. Then I booted /kernel.old and Netscape worked fine. So I booted a brand-new kernel without VM_STACK and Netscape runs. Go figure? :) The old kernel had not VM_STACK. Anyhoo, I'm making world in hopes of getting rid of that damned ps error. > > -- > Richard Seamman, Jr. email: d...@tar.com > 5182 N. Maple Lanephone: 414-367-5450 > Chenequa WI 53058 fax: 414-367-5852 > 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: Netscape | Mozilla
On Wed, 27 Jan 1999, Luke wrote: > > I wrote a port for Linux Netscape if anyone wants it. I sent it in but it > > came back to me with some comments about netscape port proliferation. > > I tried that one but it wants linux_lib installed on /compat and > theres > no room. Do you know if its ok to make /compat a link to somewhere else for > the > linux_lib port. [why does it install into / anyways] Yep, it's alright! I've been doing that for many months. It's installed into / because it's a "core"ish thing. > --- > > E-Mail: Luke > Sent by XFMail > -- > > 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: btokup() macro in sys/malloc.h
On Thu, 28 Jan 1999, Peter Jeremy wrote: > Matthew Dillon wrote: > >:> NEW > >:> > >:> #define btokup(addr)(&kmemusage[((caddr_t)(addr) - kmembase) >> > >PAGE_SHIFT]) > >: > >:The added parentheses don't make any difference, semantically. This > >:change probably wouldn't meet the criteria spelled out in style(9): > > > >Then style(9) needs to be updated, because we have to add parenthesis > >to be able to not get warnings with -Wall. > > I'll support that. The example given in style(9): > > a = b->c[0] + ~d == (e || f) || g && h ? i : j >> 1; > > should rate as an entry in the Obfuscated C competition rather than > an example of maintainable code. > > style(9) should emphasize legibility and maintainability, rather than > minimizing the number of extraneous (from the compiler's perspective) > parenthesis. The code you're writing has to be maintained for many years > - and the maintainers will not always have your in-depth expertise. > The code also forms a `reference implementation' for someone who wants > to do something similar. Here's another vote from someone who uses liberal parentheses! I think of it like this: it may be correct, but if I can't understand it after I've written it, what good is the code? Saving a few bytes isn't worth obfuscating code. Style(9) should /dons flame-retardant suit/ encourage usage of extra parens that make code more readable to humans. > > Peter > > 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: btokup() macro in sys/malloc.h
On Thu, 28 Jan 1999, John Birrell wrote:
> Nate Williams wrote:
> > > Anyway, if we're going to -Wall'ify the kernel (as we should)
> > > then we need to update sytle(9) to reflect that.
> > >
> > > In fact, style(9) should say:
> > >
> > > If at all possible, your code should compile without warnings
> > > when the gcc -Wall flag is given.
> >
> > I disagree. As has been shown many times in the past (and I suspect the
> > down-under constituent will show that at least a couple of the
>
> I think you must mean the "Sydney-down-under constituent". There *is*
> a difference. 8-)
>
> > 'warnings' fixes will be wrong and hide bogus code), making -Wall a goal
> > causes people to cover up bad code with bad casts and such.
> >
> > '-Wall' is *NOT* a good design goal.
>
> Fixing warnings with bad casts is a problem, sure, but asking people
> to write code without casts (if possible) that will compile cleanly with
> -Wall is a reasonable thing to ask IMO. In my experience, the resulting
> code tends to be more portable across architectures with different
> pointer/long sizes and endian-ness.
>
> Just my 0.02, and I hate style(9) anyway.
>
In cases, -Wall is bogus anyway. Here's one:
foo.c:89: warning: char format, void arg (arg 2)
void *region;
printf("mem open failed: %s\n", region);
According to standards, a void pointer may be freely used instead of any
other type of pointer, both as an lvalue and to assign to the other pointer.
Printf(), hence, wouldn't see a difference (of course). Gcc should not
complain about various void pointer things like this.
> --
> John Birrell - j...@cimlogic.com.au; j...@freebsd.org
> http://www.cimlogic.com.au/
> CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137
>
> 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: btokup() macro in sys/malloc.h
On Wed, 27 Jan 1999, Matthew Dillon wrote: > > :> then we need to update sytle(9) to reflect that. > :> > :> In fact, style(9) should say: > :> > :> If at all possible, your code should compile without warnings > :> when the gcc -Wall flag is given. > : > :I disagree. As has been shown many times in the past (and I suspect the > :down-under constituent will show that at least a couple of the > :'warnings' fixes will be wrong and hide bogus code), making -Wall a goal > :causes people to cover up bad code with bad casts and such. > : > :'-Wall' is *NOT* a good design goal. > > Nonsense. -Wall does *NOT* contribute to a bad programmer programming > badly, and I found at least three fairly serious mistakes when I turned > it on. > > I mean, come on... by your argument the compiler might as well give up > and not bother warning you about anything! And for the exact antithesis of silence, TenDRA has the most wonderful warnings, and it's a great free linter (but does its job better than standard lint), while producing as good code as GCC most of the time. That takes not into account once when I ran into some glaring bugs in the compilation, but at least the warnings were correct :) > > -Matt > Matthew Dillon > > > :Nate > : > :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 > 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: -Wall -Wcast-qual and SYSINIT
On Wed, 27 Jan 1999, Matthew Dillon wrote:
> Right now we have a problem with struct sysinit.
>
> The problem is that some SYSINIT functions supply a function taking
> a const void * and a const pointer for data, and other SYSINIT
> functions supply a function taking a void * and a non-const pointer
> for data.
>
> What this means, effectively, is that we want one of two SYSINIT
> structures where both the function argument and udata are of the
> same type. Something like the union shown below. If the function
> argument type does not match the data type we want the initialization
> to generate a warning.
>
> struct sysinit {
> unsigned intsubsystem; /* subsystem identifier*/
> unsigned intorder; /* init order within
> subsystem*/
> union {
> struct {
> void(*func) __P((void *));
> void*udata; /* multiplexer/argument */
> } n;
> struct {
> void(*func) __P((const void *));
> const void *udata; /* multiplexer/argument */
> } c;
> } u;
> si_elem_t type; /* sysinit_elem_type*/
> };
>
> Unfortunately, GCC isn't smart enough to match the function type
> to the correct structure - it always stuffs it into the first structure.
Overloading a struct? Yuck :(
>
> So the above cool hack will not work :-(.
Overloading is just a bad hack in concept.
>
> I can't think of how to do this without actually having two different
> sysinit structures - on that uses a non-const function and data element,
> and one that uses a const function and data element. While having two
> sysinit structures would work, it would be a little iffy keeping them
> in sync with each other so the kernel init call code doesn't have to deal
> with both types.
>
> struct c_sysinit {
> unsigned intsubsystem; /* subsystem identifier*/
> unsigned intorder; /* init order within
> subsystem*/
> void(*func) __P((void *));
> void*udata; /* multiplexer/argument */
> si_elem_t type; /* sysinit_elem_type*/
> };
>
> struct n_sysinit {
> unsigned intsubsystem; /* subsystem identifier*/
> unsigned intorder; /* init order within
> subsystem*/
> void(*func) __P((const void *));
> const void *udata; /* multiplexer/argument */
> si_elem_t type; /* sysinit_elem_type*/
> };
>
> The SYSINIT problem accounts for about half the remaining compilation
> warnings. I would like to find a good solution for it.
>
> -Matt
> Matthew Dillon
>
>
>
> 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: btokup().. patch to STYLE(9) (fwd)
On Thu, 28 Jan 1999, Nate Williams wrote:
> > > Some people when confronted by people wanting to have extra braces
> > > say "change style(9)".
> > >
> > > Well, here is my change..
> >
> > You can count my vote.
> >
> > I would also add a paragraph like this:
> >
> > If possible code should complile cleanly with gcc's -Wall flag.
> > Note however that this does not imply that it's OK to eliminate
> > warnings simply by covering them up with typecasts, etc., as that
> > actually does more harm than good.
> >
> > I hope that wording is sufficiently unoffensive to the -Wall haters.
>
> '-Wall haters'. That almost sounds like 'Wall-flowers' or something. :)
>
> Agreed, but that's not the only reason I dislike '-Wall'. The other
> reason is that some of the warnings enabled in -Wall are purely
> stylistic, and are not even warnings.
>
> Making all software compile quietly with gcc -Wall means complying with
> what the GNU folks thinks is the correct 'style' of writing software,
> rather than having style issues ignored. In other words, you end up
> making change change for the sake of change, which is silly just to
> please the compiler.
>
> But, after the recent flame fiasco I'm not saying anything more.
>
I for one like the warning
do {foo();} while(bar=baz());
that shows up, saying parentheses should be used. YES, this is a style thing,
BUT if you use the extra parentheses and know what it means, you know that
the author meant
do {foo();} while((bar=baz())!=0);
instead of
do {foo();} while(bar==baz());
This is just one of the cases in which I agree with the "style" comments/
warnings in GCC -Wall.
>
> Nate
>
> 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: btokup().. patch to STYLE(9) (fwd)
I seem to remember there once was a comment in a well-known body of code, which went something like: "You are not supposed to understand this." 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: btokup().. patch to STYLE(9) (fwd)
On Sat, 30 Jan 1999, Greg Lehey wrote: > On Friday, 29 January 1999 at 11:02:48 -0700, Warner Losh wrote: > >> If I were working on this code written by someone else it'd leave my > >> editor looking like the top example, that's for sure. I think that > >> "How easy is it to edit a piece of code and still have it do what you > >> expect" is an important consideration, because people DO edit things. > > > > Agreed. > > > >>> I do agree that complex things like: > >>> > >>> if (a | b & c % d ^ e) > >>> > >>> should really have some parents to show what is going on. > >> > >> I have NO idea of what that is doing and I have plans of looking it up in > >> the book to work it out.. > > > > Yes. I agree with that. > > if (a | b & c % d ^ e) > > should have been written as: > > if (((a | (b & (c % d))) ^ e) != 0) > > (then again, either way it is ugly code and should have comments). > > It's interesting that this whole argument has just addressed the > syntax, and nobody has given any consideration to the semantics. In > this example, all variables are a single character. Given the fact > that this expression is probably indented 16 characters, there's a > strong incentive to keep the variable names short, even at the expense > of intelligibility. Consider one possible expansion > > if (((allocationfail | (IGNOREFAILUREMASK & (incount % > BLKSIZE))) ^ failures) != 0) > > (yes, this still doesn't make sense, but I can't be bothered to look > for something more appropriate) This is now 99 characters wide, and > it's the kind of code which doesn't gain in legibility by being broken > into multiple lines, especially if the indentation of the follow-on > lines is independent of the structure of the expression. bde has made > it clear he considers code more than 80 characters wide to be Evil. > Question: how many people still limit their editor windows to 80 > characters? I do; doesn't everyone? > > Greg > -- > See complete headers for address, home page and phone numbers > finger g...@lemis.com for PGP public key > > 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: LINUX clone? sched_yield?
On Sat, 30 Jan 1999, Paulo Fragoso wrote: > Hi, > > I'm trying to install StarOffice 5.0 in my FBSD-3.0-STABLE (26Jan1999). > When setup is running the kernel reports: > > linux_clone(303): Not enabled > Jan 30 15:05:39 foker /kernel: cmd setup.bin pid 303 tried to use > non-present sched_yield > Jan 30 15:05:53 foker last message repeated 892 times > > What's happening? sched_yield() is a stub that informs you nicely that it doesn't exist :) Use the options: options "P1003_1B" options "_KPOSIX_PRIORITY_SCHEDULING" options "_KPOSIX_VERSION=199309L" > > Many thanks, > Paulo Fragoso. > > ps: I'm using one Multi-Processor motherboar with LX chip set, 2 PII > 266MHz: > > FreeBSD foker.nlink.com.br 3.0-STABLE FreeBSD 3.0-STABLE #1: Sat Jan 30 > 14:56:27 EST 1999 > pa...@foker.nlink.com.br:/usr/src/sys/compile/KERNEL-SMP i386 > > Programming 24 pins in IOAPIC #0 > FreeBSD/SMP: Multiprocessor motherboard > cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 > cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 > io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 > > -- > " ... Overall we've found FreeBSD to excel in performace, stability, > technical support, and of course price. Two years after discovering > FreeBSD, we have yet to find a reason why we switch to anything else" > -David Filo, Yahoo! > > > 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: vn and 4.0
On Mon, 1 Feb 1999, Kris Kennaway wrote: > On Mon, 1 Feb 1999, Daniel C. Sobral wrote: > > > Is vn safe right now on -current? > > It's broken for me without Matt's patch posted the other day (not yet checked > in). I can send you a copy if you missed it. > > > And does current's msdos fs > > support fat-32? > > Don't know, but I think so. FAT32 has been supported for quite a while now, along with FAT12/FAT16 and the VFAT extension (long file names). In fact, we've just about got a read only NTFS now too. > > Kris > > - > (ASP) Microsoft Corporation (MSFT) announced today that the release of its > productivity suite, Office 2000, will be delayed until the first quarter > of 1901. > > > 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: a nit, however....
On Sun, 31 Jan 1999, Mike O'Dell wrote: > > any reason why the kernel "config" program shouldn't > be changed to dramatically reduce the requirement for > the silling quoting of option values??? if an option > needs embedded whitespace, but other than that, > is there any reason other than historical for > the silliness about nubmers, etc?? Actually, as I understand it config(8) was never meant to allow the LACK of quotation marks. It's simply we've grown accustomed to not using them, I suppose, that we don't. I, for one, have every option quoted in my kernel configuration file. The right thing would be to not allow lack of quotes at all, I believe, but that would be disastrous now with current config files, and release scripts. > > -mo > > 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: style 9 pet annoyance
On Tue, 2 Feb 1999, Greg Lehey wrote: > On Monday, 1 February 1999 at 17:03:55 -0600, Eric Haug wrote: > > > > Hi All, > > You should run vi with set tabstop=3 and shiftwidth=3 > > and see what you think of the 4 spaces that are IMHO > > now making the code look really bad. > > If that's the case, maybe we shouldn't. Having 4 (not 3) spaces would be a better idea. Many people do this. > > > I think that the spaces stuff should be eliminated > > in favor of only tabs. > > I don't think that will meet with general agreement. I don't see why it shouldn't, except people like to be stuck in their ways. If everyone could just echo "set ts=4 sw=4" > .exrc, we wouldn't have these tab/space arguments. That's probably way too much to ask, of course. > > Greg > -- > See complete headers for address, home page and phone numbers > finger g...@lemis.com for PGP public key > > 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: swap_page_getswapspace failed (don't do stupid things with /dev/mem)
On Mon, 1 Feb 1999, Matthew Dillon wrote: > :So, never do stupid things as root; that's always my moto. Well, so I did > :something stupid as root, but it wasn't inherrently *that* stupid, at > :least not stupid enough to require a hard boot :). Below is the source > :... > :Except I decided to test that feature that overrides the device filename > :(normally /dev/audit). Instead, I chose /dev/mem. Don't do that (ouch). > :The machine began to churn -- ok, so the buffer expands as necessary > :without limit, which is something that will go away once I actually write > :... > :swap_pager_getswapspace: failed > : > :from the kernel. And needless to say, it loops fairly tightly and we > :... > > Uh. Mm.. Hmm :-) > > i = read(fd, &size, sizeof(size)); > ... malloc(bufsize * sizeof(char)) > i = read(fd, buf, bufsize); > > When you are reading /dev/mem, 'size' can turn out to be anything. > You are then allocating 'size' bytes ( which could be some insane > value ). Finally, you try to read() from /dev/mem into the buffer > the same insane value. > > The system is almost certainly trying to kill this process, but it > can't because the process is stuck in an uninterruptable system read() > of an insane amount of data. > > I don't think there is anything to 'fix' here. The system is making > the best of a bad situation. Perhaps, though, we could test for signal > 9 within the insanely huge read() loops and pop out. I did a signal test inside /dev/urandom (probably yet to be committed, but Bruce said he was going to.) There's no reason we can't do one here, but we may have to break read()s of /dev/mem to smaller chunks to allow for this. Maybe there is a better way to break out of a running system call, and have it return immediately, but I haven't seen one. > > -Matt > > > 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: Heads up: comitted optimization to vm_map_insert()
On Tue, 2 Feb 1999, Matthew Dillon wrote: > I've comitted an optimization to vm_map_insert() after initial > tests seemed to indicate that it works. Basically it allows > OBJT_SWAP objects to be optimized in addition to OBJT_DEFAULT > objects already optimized in certain specific cases. > > However, a followup test that I had never run before had a > temporary seg-fault ( i.e. it didn't repeat when I re-ran > the test ). I think the seg fault may have revealed a new > bug and is not related to the optimization I comitted, so I > haven't backed out the commit. I am not 100% sure though, > and I am testing this now. What test? If we had this exact test, it could be exploiting the exact bug, could it not? I'll let you know of any weird crashes in previously stable programs. > > If anyone notices weird seg-faulting that didn't occur before > tonight, please notify me! Will do! CPU_WT_ALLOC actually seemed to have caused instability before... > > -Matt > Matthew Dillon > > > 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
various -CURRENT nits
I've got a few patches today; let's see:
The TCB hash check is broken, because ffs() returns offsets starting
at 1, not 0.
Some of VoxWare doesn't compile.
In addition, if anyone thinks it should be done, should I make PQ_L[12]_SIZE
config(8) tuneable (individually, not via PQ_FOOCACHE)? I use different
values because I have a K6-2 (8+8 pages L1) that does not match PQ_L1_SIZE.
I'd also like to readd the comment that CPU_WT_ALLOC might not be stable on
a K6-2, because it actually _doesn't_ seem to be stable here. The fixes to
the two problems follow.
Brian Feldman_ __ ___ ___ ___
gr...@unixhelp.org _ __ ___ | _ ) __| \
http://www.freebsd.org/ _ __ ___ | _ \__ \ |) |
FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/
--- src/sys/netinet/tcp_subr.c.orig Wed Feb 3 21:40:42 1999
+++ src/sys/netinet/tcp_subr.c Wed Feb 3 21:42:17 1999
@@ -136,8 +136,8 @@
tcbinfo.listhead = &tcb;
if (!(getenv_int("net.inet.tcp.tcbhashsize", &hashsize)))
hashsize = TCBHASHSIZE;
- if ((1 << ffs(hashsize)) != hashsize) {
- printf("WARNING: TCB hash size not a power of 2\n");
+ if ((1 << (ffs(hashsize) - 1)) != hashsize) {
+ printf("WARNING: TCB hash size (%d) not a power of 2\n",
hashsize);
hashsize = 512; /* safe default */
}
tcbinfo.hashbase = hashinit(hashsize, M_PCB, &tcbinfo.hashmask);
--- src/sys/i386/isa/sound/os.h.origWed Feb 3 20:51:52 1999
+++ src/sys/i386/isa/sound/os.h Wed Feb 3 20:51:47 1999
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: Heads up: comitted optimization to vm_map_insert()
On Wed, 3 Feb 1999, Matthew Dillon wrote: > :> the test ). I think the seg fault may have revealed a new > :> bug and is not related to the optimization I comitted, so I > :> haven't backed out the commit. I am not 100% sure though, > :> and I am testing this now. > : > : What test? If we had this exact test, it could be exploiting the exact > bug, > :could it not? I'll let you know of any weird crashes in previously stable > :programs. > > My "do lots of things that force the machine to page up the wazoo and > try to make it crash" test :-) So do you run Netscape, or do you run StarOffice? ;) > > -Matt > 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: Heads up: comitted optimization to vm_map_insert()
On 4 Feb 1999, Dag-Erling Smorgrav wrote: > Brian Feldman writes: > > On Wed, 3 Feb 1999, Matthew Dillon wrote: > > > My "do lots of things that force the machine to page up the wazoo and > > > try to make it crash" test :-) > > So do you run Netscape, or do you run StarOffice? ;) > > Just trying to compile Applix should be enough. Ask Mike ;) Hah, I remember when I tried compiling (old-school) Mozilla, and ld was over 100mb ;) People need more RAM like in Jordan's home box, or wcarchive for that matter! This summer, hope I'll get my 512mb, and say goodbye to wd[03]s1b =) Let's ask Mr. VM if the fixes he did today were the culprits for his sig11, shall we? > > DES > -- > Dag-Erling Smorgrav - d...@flood.ping.uio.no > > 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
swapper BIG problems
Okay, here's the situation:
I've got an old program from when I was first learning C lying around, and I
converted it to be a very rudimentary memory tester.
#include
#include
#include
#define SIZE 1024*1024
void
main(void) {
int count, yep = 0;
void *stfu[SIZE];
void *mem;
for (count = 0; count < SIZE; count++) {
if ((mem = stfu[count] = malloc(1024))) {
int where;
printf("%p (%i) malloc'd\n", stfu[count], count);
for (where = 0; where < (1024 / sizeof(unsigned)); where++)
((unsigned *)mem)[where] = 0xdeadbeef;
yep++;
}
else
break;
}
for (count = 0; count < yep; count++) {
int where;
mem = stfu[count];
for (where = 0; where < (1024 / sizeof(unsigned)); where++)
if (((unsigned *)mem)[where] != 0xdeadbeef) {
fprintf(stderr, "memory check failed at %i of %i\n", count,
yep);
exit(2);
}
free(stfu[count]);
printf("%i free'd\n", count);
}
if (yep != SIZE) {
printf("mallocs failed at %i\n", yep);
exit (1);
}
else
exit (0);
}
It succeeds as per allocating the memory until the swap is full. But, when
it starts the reading/freeing, the swapins cause hundreds of
swap_pager_getswapspace: failed
This will put the system in a deadlock if, for instance, this program is run
in an xterm and an X server is running locally, and it's too swapped out to
be used, but the memory program displays things to the term (catch-22).
What I see this as is (but I'm just guessing, I'm not a real kernel hacker
yet):
The mallocations fail where the swap runs out. Fine, whatever. The printf's
in the free routines call malloc() after free()ing the kilobyte, but malloc
does not have the memory for it (or does but complains) and so complains a
LOT. The printfs work so it _SEEMS_ to be that the only thing bringing the
system to a halt is the printfs is the kernel itself, most likely the
printf's. Does this seem correct? If it's actually the kernel printf that's
hanging the system, what's the solution? What if it's not?
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: swapper BIG problems
If I do a little
--- swap_pager.c.orig Thu Feb 4 23:30:43 1999
+++ swap_pager.cThu Feb 4 23:31:22 1999
@@ -203,8 +203,10 @@
swp_sizecheck()
{
if (vm_swap_size < nswap_lowat) {
+/*
if (swap_pager_full == 0)
printf("swap_pager: out of swap space\n");
+*/
swap_pager_full = 1;
} else if (vm_swap_size > nswap_hiwat) {
swap_pager_full = 0;
@@ -442,9 +444,7 @@
{
daddr_t blk;
- if ((blk = blist_alloc(swapblist, npages)) == SWAPBLK_NONE) {
- printf("swap_pager_getswapspace: failed\n");
- } else {
+ if ((blk = blist_alloc(swapblist, npages)) != SWAPBLK_NONE) {
vm_swap_size -= npages;
swp_sizecheck();
}
My system survives through the run quite well. It does in fact seem I was
correct in my educated guess, but if anyone knows differently, (Matt, John
Dyson) please let me know! Right now it seems the printf()s can cause the
deadlock.
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: swapper BIG problems
On 5 Feb 1999, John Saunders wrote: > In nlc.lists.freebsd-current you wrote: > > It succeeds as per allocating the memory until the swap is full. But, when > > Malloc's don't cause swap space allocation. Theoretically a process can > malloc all of it's virtual address space so long as it doesn't touch > the pages. If you looked at the "prgram" (term used loosely) it touches every bit of memory it allocates. > > > it starts the reading/freeing, the swapins cause hundreds of > > swap_pager_getswapspace: failed > > > Once you actually start touching the pages does swap space (or real > memory) get allocated. However by now you have malloc'ed more data > than exists in physical swap space, and the swapper can't do anything > about it except throw away your dirty pages without saving them. The pages were already touched and in swap. After each page was read in by the pager, the printf() tried to malloc but generated the error (as it seems to me). > > > This will put the system in a deadlock if, for instance, this program is run > > in an xterm and an X server is running locally, and it's too swapped out to > > be used, but the memory program displays things to the term (catch-22). > > This is a problem. Possibly the print commands should be rate limited. > If they go to the console how do they end up in an xterm? Possibly your > syslog.conf, or you run xconsole. The problem is, the commands were going to the console, not even the xterm. I found out by looking at /var/log/messages after poking reset. > > Cheers. > --++ > . | John Saunders - mailto:j...@nlc.net.au(EMail) | > ,--_|\|- http://www.nlc.net.au/ (WWW) | >/ Oz \ |- 02-9489-4932 or 041-822-3814 (Phone) | >\_,--\_/ | NHJ NORTHLINK COMMUNICATIONS - Supplying a professional, | > v | and above all friendly, internet connection service. | > ++ > 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: Problem with "top" on current ?
On Fri, 5 Feb 1999, William Woods wrote: > Running 4.0 -Current build as of a few miniutesd ago, I go to run top and I > get. > > top: cannot read *swapblist: kvm_read: Bad address > top: cannot read blmeta_t: kvm_read: Bad address > Floating point exception Try "kvm_mkdb" yet? > > -- > E-Mail: William Woods > Date: 05-Feb-99 / Time: 18:34:17 > FreeBSD 4.0 -Current > -- > > 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: Problem with "top" on current ?
On Fri, 5 Feb 1999, Matthew Dillon wrote: > > : > :Ahhh...not sure what you mean here... > : > :On 06-Feb-99 Brian Feldman wrote: > :> On Fri, 5 Feb 1999, William Woods wrote: > :>> Floating point exception > :... > :> > :> Try "kvm_mkdb" yet? > :> > :-- > :E-Mail: William Woods > > Try this: > > cd /usr/src/lib/libkvm > make; make install; make clean > cd /usr/src/usr.bin/top > make; make install; make clean > kvm_mkdb > In case anyone wants to rebuild everything with a kvm dependency, I made a little something (maybe it's a time for a make kvmdepend target, or something) #cd /usr/src cd lib/libkvm make all install clean cd - for dir in bin sbin usr.bin usr.sbin; do cd $dir for file in *; do if [ -f $file/Makefile ] && grep lkvm $file/Makefile; then (cd $file; make all install clean) fi done cd .. done > > -Matt > > Matthew Dillon > > > 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
msdosfs/vn trouble, doscmd "nicety", fd trouble
Okay, I've got three separate problems today:
Doscmd is really only useable with X, and running doscmd -bx with a local X
server generates tons of "trap 25 with interrupts disabled". I don't recall
this being the case many moons ago...
When I mount a floppy image (msdos, using the vn device), I soon get:
panic: zone: entry not free
syncing disks... 152 47 44 38 31 24 17 1 done
dumping to dev 30001, offset 73728
dump 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:287
287 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:287
#1 0xf0136fed in panic (fmt=0xf0213774 "zone: entry not free")
at ../../kern/kern_shutdown.c:448
#2 0xf01afed3 in zerror (error=1) at ../../vm/vm_zone.c:455
#3 0xf015a650 in namei (ndp=0xf78f9f08) at ../../vm/vm_zone.h:91
#4 0xf0161238 in rename (p=0xf73731e0, uap=0xf78f9f84)
at ../../kern/vfs_syscalls.c:2461
#5 0xf01d9a2b in syscall (frame={tf_es = 47, tf_ds = 47, tf_edi = 134828010,
tf_esi = 134934656, tf_ebp = -272657172, tf_isp = -141582380,
tf_ebx = 134931436, tf_edx = -272640240, tf_ecx = 14, tf_eax = 128,
tf_trapno = 7, tf_err = 2, tf_eip = 672138692, tf_cs = 31,
tf_eflags = 582, tf_esp = -272657192, tf_ss = 47})
at ../../i386/i386/trap.c:1100
#6 0xf01cc4fc in Xint0x80_syscall ()
#7 0x8050ec1 in ?? ()
#8 0x8050703 in ?? ()
#9 0x80516cc in ?? ()
#10 0x8052ae0 in ?? ()
#11 0x8052b90 in ?? ()
#12 0x804e43d in ?? ()
#13 0x8068ebc in ?? ()
#14 0x804a491 in ?? ()
(kgdb)
(kgdb) frame 3
#3 0xf015a650 in namei (ndp=0xf78f9f08) at ../../vm/vm_zone.h:91
91 zerror(ZONE_ERROR_NOTFREE);
(kgdb) print *ndp
$1 = {ni_dirp = 0x80af080 ".new.GraphBuil", ni_segflg = UIO_USERSPACE,
ni_startdir = 0xf78f9f30, ni_rootdir = 0xf012e469, ni_vp = 0xf05a0e00,
ni_dvp = 0xf73731e0, ni_pathlen = 4147589600,
ni_next = 0x5e9 , ni_loopcnt = 0, ni_cnd = {
cn_nameiop = 2, cn_flags = 4112, cn_proc = 0xf73731e0,
cn_cred = 0xf133c200, cn_pnbuf = 0xf73731e0 "?\022\221?",
cn_nameptr = 0x8000 ,
cn_namelen = 0, cn_hash = 134828010, cn_consume = -266186924}}
I'll try do some more testing on this... I really don't know if it's a problem
with msdosfs or vn. It will only show p (like this) with INVARIANTS on.
I also notice I can't seem to use my flopy drive anymore. The BIOS and BTX
can both use it, the kernel:
fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1.44MB 3.5in
fd0: 1.44MB 3.5in
and I can hear the drive click-whir-buzz like normal, but if I try to use
the drive ({,r}fd0, etc), all I get is
fd0: recal failed ST0 70 cyl 0
fd0: recal failed ST0 70 cyl 0
fd0: recal failed ST0 70 cyl 0
fd0: recal failed ST0 78 cyl 0
fd0c: hard error reading fsbn 0 of 0-3 (No status)
With this, I'm wondering if everyone's floppy drives work fine and if their
drives work fine on an AcerLabs socket 7 motherboard. If so, maybe I can
scrounge up a different floppy drive and try it out, but it really seems
to not be a hardware problem.
Thanks in advance.
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: low level format--how??
On Sat, 6 Feb 1999, Daren Sefcik wrote: > No..it's an HP generic and it has no BIOS... > I tried using SCSI ToolBox on my windows > machine but it just hangs. > The disk was formatted for freebsd and I used > the newfs_msdos command on it and now it > is hosed..I can't seem to get it back. > Disklabel gives me a "disk not configured" error Have you tried dd if=/dev/zero of=/dev/rsd# count=100? > > argghh..any ideas/help..?? > > Daren > > On Sat, 6 Feb 1999, Josef Grosch wrote: > > > On Sat, Feb 06, 1999 at 12:55:16PM -0800, Daren Sefcik wrote: > > > Is it possible to do a low level format > > > of a scsi disk..I do not see a utility > > > to do so. > > > > If you are using an Adaptec controller card, like a 2940, there is a > > low-level format in the card-bios. You can get into the card-bios utilities > > by watching the system as it is coming up and hitting control-a. > > > > Your mileage may vary. > > > > > > Josef > > > > -- > > Josef Grosch | Another day closer to a |FreeBSD 3.0 > > jgro...@mooseriver.com | Micro$oft free world | UNIX for the masses > > > > > 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: msdosfs/vn trouble, doscmd "nicety", fd trouble
The panic() I'm getting is not what appears to be the fault of vn(4). I can vnconfig, newfs, and mount_ufs a filesystem to my heart's content, even running my nice file-system-beater-upper (TM). The problem only occurs when I try to use msdosfs, and then occurs when: I chdir into the msdosfs, then when I try to chdir out. On the second chdir, I get the lovely panic. With INVARIANTS on, this is easily reproducible. 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
msdosfs is dead, Jim.
How am I supposed to find the maintainer of a certain part of the kernel, anyway? The basic problem is that msdosfs panic()s quite easily with a "zone not free" error (INVARIANTS is /ON/ in the kernel), when I attempt to do a rw mount of a FAT16. I don't know what else it affects, but it's easily and consistently reproducible. This is not in relation to vn(4), which it was originally tested with, as vn(4) works flawlessly. 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: cleanup of rc.conf ( -4.x )
On Mon, 8 Feb 1999, Matthew Dillon wrote:
> This does not make any operational change except to get rid
> of the $conf_dir junk from rc.conf, which I originally put
> in to try to bootstrap rc.diskless.
>
> A much better way to do rc.diskless was suggested to me,
> which I'm going to implement. It involves retargeting
> the /conf/ME softlink by mount_union'ing a small MFS
> filesystem onto /conf. Then one simply makes /etc/rc.conf.local
> a softlink to /conf/ME/rc.conf.local ( i.e. a sysop would do
> that as an extra, we wouldn't distribute the base system
> like that of course )
>
> In anycase, I've committed a new rc.conf that gets rid
> of $conf_dir, FYI, and am about to commit a new rc.diskless and
> new examples that uses the mount_union idea for retargeting
> during a diskless boot that will be much more straightward and
> obvious.
>
Hasn't mount_union been dead for ~forever (+/- a few years)?
> -Matt
> Matthew Dillon
>
>
>
>
> rc_conf_files="/etc/rc.conf.site /etc/rc.conf.local"
>
> ...
>
> ##
> ### Allow local configuration override at the very end here ##
> ##
> #
> #
>
> for i in ${rc_conf_files}; do
> if [ -f $i ]; then
> . $i
> fi
> done
>
>
>
> 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: cleanup of rc.conf ( -4.x )
On Tue, 9 Feb 1999, Garrett Wollman wrote: > < said: > > >> A much better way to do rc.diskless was suggested to me, > >> which I'm going to implement. It involves retargeting > >> the /conf/ME softlink by mount_union'ing a small MFS * Note this. > > > Union mounts do not work, and I believe they are some distance from > > working (unless you have better patches than I do, of course). > > Last I checked, union mounts work just fine, thank you very much. > unionfs (which should have been called `translucentfs') is what > doesn't work. See above note and reference to mount_union(8). > > -GAWollman > > -- > Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the > same > woll...@lcs.mit.edu | O Siem / The fires of freedom > Opinions not those of| Dance in the burning flame > MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick > > 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: DHCP, install, security, ICMP_BANDLIM
On Tue, 9 Feb 1999, Mikhail Teterin wrote: > How about putting bpf functionality into install-kernel, but not > into the GENERIC kernel? > > If the install required the use of dhcp, sysinstall should yell > about having to rebuild the kernel with bpf-device in. > > On the other hand, the security-concerned ISPs and others can > rebuild their kernels to remove the bpf (they probably rebuild > them anyway for other reasons, or should do that anyway). This brings up something: shouldn't ICMP_BANDLIM be in the GENERIC kernel? > > -mi > > 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: Heads up! /etc/rc.conf.site is dead.
On 11 Feb 1999 kai.grossjoh...@cs.uni-dortmund.de wrote: > Jon Hamilton writes: > > > But then you're right back where you started. Since rc.conf isn't > > supposed to be touched by the install/upgrade tools, it'll get out > > of date (and will become a hinderance rather than a help) as > > default settings change, and as settings are added/deleted. > > Can we make something which compares /etc/rc.conf and > /etc/default/rc.conf and emits warnings if a variable is set in > /etc/rc.conf which isn't in /etc/default/rc.conf? > > I realize that this is not as simple as extracting all variable names > from both files, sorting them, and running diff. There are a few > variable names which are variable, for instance the network interface > settings. Actually, it's almost that easy. It may require a few "hints" at the beginning of the file, but I could make a shell script (not using sed/awk/whatnot) to do this if anyone would want it. > > kai `a FreeBSD newbie but hopefully not stupid' > -- > I like _b_o_t_h kinds of music. > > 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: [Call for Review] new ioctl for src/sys/pccard/*
On Sat, 13 Feb 1999, Jun Kuriyama wrote: > Nate Williams wrote: > > The changes to pccardd to support the new 'inactive' flag are still > > missing. We can power the slot on/off, but pccardd is unaware of these > > changes. Doesn't it need to be aware of the new 'power' state? > > Hmm. I looked pccard in PAO but it is complex in state treatment. I > should make this more clearer. > I'll continue to check PAO code so I will return this area after I check > other area of PAO. At this time, I'll commit "beep" feature only. > > > Right. Last I looked at PAO the pccard code had modifications all over > > the kernel. > > I think so, too. :-) Pardon my naivite, but why iswas PAO not part of FreeBSD itself? > > > -- > Jun Kuriyama // kuriy...@sky.rim.or.jp > // kuriy...@freebsd.org > > 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: lpt0
On Sat, 13 Feb 1999, Chuck Robey wrote: > Recently I noticed that lpt0 has been replaced by the ppbus stuff, in > LINT. The problem is, I can't find any example as to how to set it up > for a plain, vanilla printer ppbus has so many more capabilities > than lp, I think it's embarrassed about it's dowdy origins. I don't > know what controller to use (ppbus0 or maybe ppc0?) and the old device, > lpt0, doesn't even exist in LINT anymore. > > I tried picking up the lines for ppbus0 and nlpt, which I guessed might > be right, from LINT, and dropping them into my config file. They > compile fine, but nothing is probed (my dmesg shows no printer) and I > can't print. > > What's the right setup for a plain, ordinary IRQ 7 printer port? > Please, don't answer if you're going to talk about connecting some > parallel interfaced thing like a zip drive. I can't seem to find any > docs on this, nor any mail messages (nothing in UPDATING either). There > is much discussion about things like zip drive connecting, though ... The following works great for me: controller ppbus0 device nlpt0 at ppbus? device plip0 at ppbus? device ppi0at ppbus? device pps0at ppbus? controller ppc0at isa? port ? tty irq 7 > > +--- > 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 picnic (FreeBSD-current) > (301) 220-2114 | and jaunt (Solaris7). > +--- > > > > > > 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: Aladdin chipset SMBus support available!
On Sat, 13 Feb 1999, Nicolas Souchu wrote: > Hi folks, > > I've just committed the alpm(4) driver to -current: the Aladdin SMBus > driver. Great, my newest mobo is an AcerLabs. > > With an onboard system management chip (lm7x or w87381), > it offers monitoring capabilities to recent Acer based motherboards like > the ASUS P5AB. I'm using a matsonic. > > Example program to fetch temperature or voltages is available at > http://www.planet.sci.kobe-u.ac.jp/~takawata/smbus/examples/ > There's also an example program to fetch SDRAM info over the smbus. I tried them, and there's the problem: all the ioctl()s they perform return EINTR! Has this driver been tested on many motherboards? Why should I expect an EINTR? Just wondering :) > > You may also want to know what smbus(4) is: > http://www.freebsd.org/~nsouch/iicbus.html > > Feedbacks are wellcome. > > Nicholas. > > PS: A driver is also available for the Intel PIIX4, see intpm(4). > > -- > nso...@teaser.fr / nso...@freebsd.org > FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org > > 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: Aladdin chipset SMBus support available!
On Sun, 14 Feb 1999, Nicolas Souchu wrote: > On Sat, Feb 13, 1999 at 05:22:00PM -0500, Brian Feldman wrote: > > > >On Sat, 13 Feb 1999, Nicolas Souchu wrote: > > > >> Example program to fetch temperature or voltages is available at > >> http://www.planet.sci.kobe-u.ac.jp/~takawata/smbus/examples/ > >> There's also an example program to fetch SDRAM info over the smbus. > > I attach you the detect.c program. It's very simple and may help us > in knowing what I2C hardware you have on your mobo. Where's my detect.c? I think you forgot to attach it :) > >I tried them, and there's the problem: all the ioctl()s they perform return > >EINTR! Has this driver been tested on many motherboards? Why should I expect > >an EINTR? Just wondering :) > > EINTR is odd. It just mean that the device at the address requested on the > I2C bus do not respond. I have to translate SMBus errors to the appropriate > unix ones. Hmm... wouldn't the appropriate error for something not responding be an ENXIO or ETIMEDOUT? EINTR seems more than a little wrong for this purpouse. > > -- > nso...@teaser.fr / nso...@freebsd.org > FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org > 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: Disk locks and weird things
On Sun, 14 Feb 1999, Erik Funkenbusch wrote: > Recently I've been trying to upgrade an early januarrry -current to > current -current. I've rebuilt the kernel several times over the last few > days (with new cvsup's) so i've eliminated any freak check-in mismatches. > > During a make world (usually about 10-20 minutes in on my P100) everything > just comes to a grinding halt. No disk activity, but the screen saver will > kick in (despite the shell being in the middle of said make world). > > If I switch to any alternate consoles and try to do anything, even an ls, it > accesses the disk for a brief second, then hangs as well. Other tasks that > don't need to access the disk keep running (such as natd and obviously the > screen saver). > > After waiting about a half hour, I hit the reset and get lots of UNREF > FILE's and SUMMARY INFORMATION BAD and BLK(S) MISSING IN BIT MAPS. They all > say slavaged or cleared. But you didn't look in /var/log/messages? For shame! > > It doesn't appear to be a problem with the actual disk, since rebooting > works fine until I try and build again. Even building the kernel works > fine. but doing a make world does not (I don't know if anything else causes > this). It never fails in the same place twice either, but it's always the > same effect. What you should have said is "It doesn't appear to be a problem with the actual disk, since rebooting with a different brand disk of the same capabilities doesn't work." or vice versa. > > Additionally, i've been getting No such user 'tty', service ignored messages > from ntalk and comsat. I'm sure these services were updated to make use of > some tty user or something, but i'd like to know what exactly I should do > here. Look in src/etc/master.passwd. vipw and add the lines for users you don't have. > > I'm also getting messages from de0 and lo0 that say: > > de0 XXX: driver didn't set ifq_maxlen That's mostly harmless. It's a warning to driver maintainers that was just put in recently; the driver hasn't ever set ifq_maxlen, no doubt. > > Finally, if I try and run top i get: > > top: cannot read swaplist: kvm_read: Bad address > kvm_open: proc size mismatch (11392 total, 680 chunks) > top: Out of memory. > > I assume this is from a newer kernel with older support files (such as top) > but since I can't get world to build, I'm kinda stuck.. Yes it is, but the proper order is to make th world and then make the kernel. > > One more thing. I figured I might try a complete reinstallation so I tried > to download the 4.0-snap of 2-11 and was able to successfully create a > kern.flp but when I tried to create mfsroot.flp it seems to sit in a loop > forever just moving the disk head back and forth. I tried it with several > floppies (including the one I was able to successfully create kern.flp on) > with the same results. > > > > 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: Aladdin chipset SMBus support available!
On Sun, 14 Feb 1999, Nicolas Souchu wrote:
> On Sun, Feb 14, 1999 at 08:40:11AM -0500, Brian Feldman wrote:
> >
> >On Sun, 14 Feb 1999, Nicolas Souchu wrote:
> >
> >> On Sat, Feb 13, 1999 at 05:22:00PM -0500, Brian Feldman wrote:
> >> >
> >> >On Sat, 13 Feb 1999, Nicolas Souchu wrote:
> >> >
> >> >> Example program to fetch temperature or voltages is available at
> >> >> http://www.planet.sci.kobe-u.ac.jp/~takawata/smbus/examples/
> >> >> There's also an example program to fetch SDRAM info over the smbus.
> >>
> >> I attach you the detect.c program. It's very simple and may help us
> >> in knowing what I2C hardware you have on your mobo.
> >
> >Where's my detect.c? I think you forgot to attach it :)
>
> :) here it is!
alpm0: rev 0x00 on pci0.3.0
alsmb0:
smbus0: on alsmb0
smb0: on smbus0
{"/home/green/examples"}$ ./detect
a2 found.
d2 found.
>
> >
> >> >I tried them, and there's the problem: all the ioctl()s they perform
> >> >return
> >> >EINTR! Has this driver been tested on many motherboards? Why should I
> >> >expect
> >> >an EINTR? Just wondering :)
> >>
> >> EINTR is odd. It just mean that the device at the address requested on the
> >> I2C bus do not respond. I have to translate SMBus errors to the appropriate
> >> unix ones.
> >
> >Hmm... wouldn't the appropriate error for something not responding be an
> >ENXIO or ETIMEDOUT? EINTR seems more than a little wrong for this purpouse.
>
> Fix committed.
>
> BTW, as outlined by -pkh all this is just a first step in a huge monitoring
> adventure where all still need to be _defined_ (architecture and interfaces)
> and implemented. Any proposition for doing the job is wellcome,
> since I just have enough time to do the hardware SMBus support.
Sounds like fun
>
> Nicholas
>
> --
> nso...@teaser.fr / nso...@freebsd.org
> FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org
>
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: Aladdin chipset SMBus support available!
On Sun, 14 Feb 1999, Nicolas Souchu wrote:
> On Sun, Feb 14, 1999 at 12:11:09PM -0500, Brian Feldman wrote:
> >
> >On Sun, 14 Feb 1999, Nicolas Souchu wrote:
> >
> >> On Sun, Feb 14, 1999 at 08:40:11AM -0500, Brian Feldman wrote:
> >> >
> >> >On Sun, 14 Feb 1999, Nicolas Souchu wrote:
> >> >
> >> >> On Sat, Feb 13, 1999 at 05:22:00PM -0500, Brian Feldman wrote:
> >> >> >
> >> >> >On Sat, 13 Feb 1999, Nicolas Souchu wrote:
> >> >> >
> >> >> >> Example program to fetch temperature or voltages is available at
> >> >> >> http://www.planet.sci.kobe-u.ac.jp/~takawata/smbus/examples/
> >> >> >> There's also an example program to fetch SDRAM info over the smbus.
> >> >>
> >> >> I attach you the detect.c program. It's very simple and may help us
> >> >> in knowing what I2C hardware you have on your mobo.
> >> >
> >> >Where's my detect.c? I think you forgot to attach it :)
> >>
> >> :) here it is!
> >
> >alpm0: rev 0x00 on pci0.3.0
> >alsmb0:
> >smbus0: on alsmb0
> >smb0: on smbus0
> >
> >{"/home/green/examples"}$ ./detect
> >a2 found.
> >d2 found.
>
> So,
>
> ./spd 1
>
> will work!
Sorta. It did work. Then it stopped working. Running detect seems to kill my
SM (or at least reset it to some weird state)
{"/home/green/examples"}$ ./detect
{"/home/green/examples"}$
>
> --
> nso...@teaser.fr / nso...@freebsd.org
> FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org
>
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: lpt0
On Sun, 14 Feb 1999, Jordan K. Hubbard wrote: > > On Sat, Feb 13, 1999 at 07:36:37PM -0800, Jordan K. Hubbard wrote: > > > > > >FWIW, I would also like to see this happen. > > > > What's the deadline? I did it for -current this day. I'm waiting for > > some feedback before the 3.1 replica. > > Actually, subsequent discussions with Dag-Erling have sort of shown > this to have been rather too ambitious of me and now I've major second > thoughts. :( > > I think the number of changes involved in making the cut-over are just > too likely to hang us at the last minute, and that's nothing any of us > want. Any there any last cosmetic tie-ups of a less scary nature, or > are we good to go as-is in the 3.0 branch? ICMP_BANDLIM by default in GENERIC? And maybe perhaps a note that there is a much improved parallel port driver that everyone should use? Putting nlpt, ppbus, ppc etc in there should be fine, considering nlpt wouldn't collide with anyone trying to configure an old kernel... > > - Jordan > > 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: New print interface
It says "generic" every time, whther or not there's a printer attached. lpt0: on ppbus 0 lpt0: Interrupt-driven port should be lpt0: generic printer port on ppbus 0 lpt0: Interrupt-driven port 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: Aladdin chipset SMBus support available!
On Sun, 14 Feb 1999, Nicolas Souchu wrote:
> On Sun, Feb 14, 1999 at 01:01:27PM -0500, Brian Feldman wrote:
> [...]
> >
> >Sorta. It did work. Then it stopped working. Running detect seems to kill my
> >SM (or at least reset it to some weird state)
> >
> >{"/home/green/examples"}$ ./detect
> >{"/home/green/examples"}$
>
> You mean you got some output from spd? Which? Try recompiling alpm.o with
> DEBUG defined.
>
On spd I would get an error message, and if I ever did spd 1 it got as far
as printing 128 bytes used, then erred out...
> rm alpm.o ; make CC="cc -DDEBUG"
I'll rm alpm.o; CC='cc -DDEBUG' make alpm.o; make, if that's what you mean.
>
> --
> nso...@teaser.fr / nso...@freebsd.org
> FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org
>
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: Aladdin chipset SMBus support available!
On Sun, 14 Feb 1999, Nicolas Souchu wrote: > On Sun, Feb 14, 1999 at 04:30:27PM -0500, Brian Feldman wrote: > >> > > > >On spd I would get an error message, and if I ever did spd 1 it got as far > >as printing 128 bytes used, then erred out... > > > >> rm alpm.o ; make CC="cc -DDEBUG" > > > >I'll rm alpm.o; CC='cc -DDEBUG' make alpm.o; make, if that's what you mean. > > any difference? Yes: Feb 14 17:12:16 green /kernel: alpm: idle? STS=0x0 Feb 14 17:12:48 green last message repeated 380 times Feb 14 17:13:14 green last message repeated 5 times > > -- > nso...@teaser.fr / nso...@freebsd.org > FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org > > 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: Problesm w/ 4.0-current & wine
On Mon, 15 Feb 1999, Donn Miller wrote: > > > Kris Kennaway wrote: > > > On Mon, 15 Feb 1999, Donn Miller wrote: > > > > > I've got the USER_LDT option in my kernel, and I'm running an `aout' > > > instead of `elf' kernel. > > > > I thought running a.out systems had been deprecated for -current and was no > > longer supported. Since you're running a bleeding-edge codebase anyway, why > > haven't you updated to an ELF kernel? > > Did that. I installed the kernel, updated the new bootblocks with disklabel > -B > /dev/rwd0s2a, echo /boot/loader > /boot.conf. Now, when I enter "-c" at the > "boot: " prompt, it boots with the new boot loader, and never goes into > UserConfig (it continues booting as if I never entered "-c" at the boot > prompt). That sounds like a bug, but the "boot: " prompt is NOT the new boot loader, it's the semi-new boot0 (which is quite nice, Mr. Nordier). When you actually yet to BTX, try boot -c. > > Donn > > > 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: Problesm w/ 4.0-current & wine
On Mon, 15 Feb 1999, Daniel C. Sobral wrote: > Brian Feldman wrote: > > > > That sounds like a bug, but the "boot: " prompt is NOT the new boot loader, > > it's the semi-new boot0 (which is quite nice, Mr. Nordier). When you > > actually > > yet to BTX, try boot -c. > > Terminology errors abound here. I know, because I made many of them > in the past. > > boot0 is the "booteasy" prompt (F?). > BTX is a kernel. "Prompt" doesn't apply here. > The twisting | is boot2. If you type something at this time, you get > boot2 prompt. Unless you type enter, od course. > The later stage is called "loader". > > So, change BTX with loader, and your advice stands. :-) Whoops, I always end up typing the wrong thing :) boot0 is the MBR, boot2 is the kernel loader, and they're all by Mr. Nordier. The BTX loader does have a "prompt" by default and if you interrupt the countdown. The prompt is, of course, Forth :) > > -- > Daniel C. Sobral (8-DCS) > d...@newsguy.com > d...@freebsd.org > > Well, as a computer geek, I have to believe in the binary universe. > > 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: Problesm w/ 4.0-current & wine
On Mon, 15 Feb 1999, Mike Smith wrote: > > Whoops, I always end up typing the wrong thing :) boot0 is the MBR, boot2 is > > the kernel loader, and they're all by Mr. Nordier. > > Wrong again. boot0 is in the MBR, boot1 and boot2 are the bootstrap; > all by Robert. The loader, OTOH, uses Robert's BTX code, Ficl, and a > lot of code derived by me from the NetBSD standalone loader. Boot2 is, as you say, correctly identified as the "bootstrap", however you cannot deny that boot2 is a kernel loader as it can load a pure executable (a.out kernel or /boot/loader) or an ELF kernel. > > > The BTX loader does have a "prompt" by default and if you interrupt the > > countdown. The prompt is, of course, Forth :) > > The "BTX loader" doesn't have a prompt at all. The kernel loader has a > prompt, and the prompt is not written in Forth (yet). By "BTX loader" I refer to the BTX kernel and system which can bootstrap a kernel and load modules. The prompt isn't OF Forth, I stated that the prompt TAKES Forth; perhaps I could have said that better. > > -- > \\ 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: Problems in VM structure ?
On Tue, 16 Feb 1999, Matthew Dillon wrote: > :maxusers 256 > > Try reducing maxusers to 128. Another person reported similar behavior > to me and after a bunch of work he tried going back to a basic > distribution -- and everything started working again. > > It turned out that a maxusers value of 256 and 512 were causing his > machine > to go poof, but a maxusers value of 128 worked fine. > > I haven't tracked the problem down yet. Please try reducing your maxusers > to 128 and email the results to current. For what it's worth, my maxusers is 250 and my system is quite stable, even during a make -j25 buildworld. > > -Matt > > > 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: SMP and SO5.0
On Tue, 16 Feb 1999, Luoqi Chen wrote:
> > Hi,
> > I downloaded Star Office 5 and only THEN realised that the code for doing
> > linux thread
> > emulation is #ifndef SMP :) Still, after downloading 70 meg over a 56k
> > modem and paying
> > 19c/meg I was gonna try the sucker regardless.. And well, it works!
> >
> > The install hung at the end, after its done everything, so I killed it, but
> > after that I
> > can run it with (seemingly) no problems.. (Except for the 2000 odd 'shared
> > address space
> > fork attempted' messages in my syslog)
> >
> > I only had a quick fiddle, but it started up everything fine and ran quite
> > well..
> >
> > The install was a pain tho, as I had to unpack the setup program (its a
> > self extracting
> > zip) and rename the libs in it to lower case and then add an
> > LD_LIBRARY_PATH to point to
> > them, but apart from that it was OK.
> >
> > Its worth noting though, that eMusic which uses Linux threads doesn't work
> > under
> > emulation (it just hangs) I think I'll boot a non-SMP kernel and have a go
> > ('cause it
> > took me an hour to find all of the $...@$ dependancies it needs because
> > Linux ldd doesn't
> > work anymore)
> >
> > ---
> > Daniel O'Connor software and network engineer
> > for Genesis Software - http://www.gsoft.com.au
> > "The nice thing about standards is that there
> > are so many of them to choose from."
> > -- Andrew Tanenbaum
> >
> You may try my patch at http://www.freebsd.org/~luoqi, which would allow
> linux threads to run on SMP.
>
> -lq
With any form of kernel threads not working, and aio being highly unstable for
SMP because of the VM system, is it not worthwhile to actually implement or
merge the changes like this?
>
>
> 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: uptime weirdnessl
On Thu, 18 Feb 1999, Chris Costello wrote: > On Thu, Feb 18, 1999, Erik Funkenbusch put this into my mailbox: > > I'm seeing a problem with uptime in recent -currents which doesn't make any > > sense to me. > >I've had that with 3.0-STABLE, as well. I'm not sure why, but it kept > saying: > > uptime: /dev//chris: No such file or directory > ... uptime output ... > >Obviously the same problem existed in w(1). A reboot solved the problem. > I suppose I should look into this and produce a patch. A patchh is unnecessary. I figured that all out long ago. A patchh is unnecessary. > > > > odin# uptime > > uptime: /dev//umount: /proc: not currently mounted > > umount:: No such file or directory > > uptime: /dev// /var: not currently mounted > > umount: /usr: n: No such file or directory > > 3:24PM up 1 day, 18:17, 3 users, load averages: 1.00, 1.00, 1.00 > > > > umount is available and it's in the path, and all the above directories > > exists (and /proc seems to be functioning) > > > > Any ideas? Yes. Look at /var/run/wtmp. Look CAREFULLY at /dev/null. > > > > > > > > To Unsubscribe: send mail to majord...@freebsd.org > > with "unsubscribe freebsd-current" in the body of the message > > > > -- > When I was a boy I was told that anybody could become President. Now > I'm beginning to believe it. > -- Clarence Darrow > > > 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: uptime weirdnessl
On Thu, 18 Feb 1999, Matthew D. Fuller wrote: > On Thu, Feb 18, 1999 at 07:05:39PM -0500, a little birdie told me > that Brian Feldman remarked > > > On Thu, Feb 18, 1999, Erik Funkenbusch put this into my mailbox: > > > > > > > > Any ideas? > > > > Yes. Look at /var/run/wtmp. Look CAREFULLY at /dev/null. > > Look even more carefully at /var/run/utmp, since wtmp is in /var/log and > doesn't affect w/uptime anyway. O:-) > Eek, it must be that bug in remember.c:similarly_named_files(). Time to upgrade to Brain 1.1-STABLE! Btw, I was of course referring to wtmp being garbage and /dev/null being a "regular" file. > > > --- > > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > | Matthew Fuller http://www.over-yonder.net/~fullermd | > * fulle...@futuresouth.com fulle...@over-yonder.net * > | UNIX Systems Administrator Specializing in FreeBSD | > * FutureSouth Communications ISPHelp ISP Consulting * > | "The only reason I'm burning my candle at both ends, | > *is because I haven't figured out how to light the* > | middle yet" | > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > 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
More kernel threading ;)
This time I've got a problem with LinuxThreads (again), but really any kernel
threads. Anyway, for those who say to put your patches where your mouth is,
this is a pretty annoying problem which I have solved, and I've provided a
fix. So here goes:
With RFMEM, a shared address space is created and p->p_vmspace->vm_refcnt is
incremented. With shared memory, p->p_vmspace->vm_shm is allocated and used.
Now when processes exit (in the code before this patch), if vm_refcnt is not
1, shared memory is not taken care of at all. Instead, I changed it so that
shared memory's shm_nattch is decreased, and if < 1, freed. This solves the
problem of:
p1: fork1(RFMEM)
p[12]: shm create/attach
kill -9 p2 (no chance for the process to catch the signal and delete the
shared memory correctly)
exit1(p2)-> vm_refcnt--, shm not deleted/unreferenced
p1: no child! *SPLAT*
exit1(p1)-> vm_refcnt-- == 1, vm deleted and shm tried to be deleted:
shmexit-> shm all tried to be freed, but refcnt > 0, so it's not really deleted
and refcnt is dec'd once
You end up with (ipcs -a) a shared memory segment with a refcnt of 1, being
SET deleted but still there, and undeleteable because its' refcnt is 1 (refcnt
being shm_nattch...).
And the patch follows :)
--- src/sys/kern/sysv_shm.c.old Sat Feb 20 11:36:15 1999
+++ src/sys/kern/sysv_shm.c Sat Feb 20 11:46:19 1999
@@ -596,10 +596,13 @@
shmmap_s = (struct shmmap_state *)p->p_vmspace->vm_shm;
for (i = 0; i < shminfo.shmseg; i++, shmmap_s++)
- if (shmmap_s->shmid != -1)
+ if (shmmap_s->shmid != -1 &&
+ --shmsegs[IPCID_TO_IX(shmmap_s->shmid)].shm_nattch < 1)
shm_delete_mapping(p, shmmap_s);
- free((caddr_t)p->p_vmspace->vm_shm, M_SHM);
- p->p_vmspace->vm_shm = NULL;
+ if (p->p_vmspace->vm_refcnt == 1) {
+ free((caddr_t)p->p_vmspace->vm_shm, M_SHM);
+ p->p_vmspace->vm_shm = NULL;
+ }
}
void
--- src/sys/kern/kern_exit.c.oldSat Feb 20 11:36:02 1999
+++ src/sys/kern/kern_exit.cSat Feb 20 11:46:22 1999
@@ -206,6 +206,10 @@
/* The next two chunks should probably be moved to vmspace_exit. */
vm = p->p_vmspace;
+
+ if (vm->vm_shm)
+ shmexit(p);
+
/*
* Release user portion of address space.
* This releases references to vnodes,
@@ -215,8 +219,6 @@
* may be mapped within that space also.
*/
if (vm->vm_refcnt == 1) {
- if (vm->vm_shm)
- shmexit(p);
pmap_remove_pages(vmspace_pmap(vm), VM_MIN_ADDRESS,
VM_MAXUSER_ADDRESS);
(void) vm_map_remove(&vm->vm_map, VM_MIN_ADDRESS,
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: sh(1) -- exec vs. fork
On Fri, 19 Feb 1999, Rahul Dhesi wrote: > Many years ago I posted a shell script to Usenet in which I prepended a > line with 'exec', in an attempt to avoid having a shell process hanging > around doing a wait(). David Korn himself (of Korn shell fame) > responded saying this was not necessary, as the shell would do exec() > anyway. > > I check with trace() on a Sun and he seemed to be right. This was for > the classic Bourne shell many years ago. > > But I just checked /bin/sh on 3.1-RELEASE with ktrace and the above does > not seem to be true. I get drastically different traces for > >#! /bin/sh >exec /bin/pwd > > and > >#! /bin/sh >/bin/pwd > > Rahul I know that the FreeBSD Bourne shell doesn't do this, nor does the PDKSH. I checked and the copy of the AT&T Korn shell I have (for BSDi) does do what David Korn says. > > > Date: Fri, 19 Feb 99 11:43:59 EST > > From: Mikhail Teterin > > To:curr...@freebsd.org > > Message-Id: <199902191644.laa08...@misha.cisco.com> > > Subject: sh(1) -- exec vs. fork > > Reply-To: m...@aldan.algebra.com > > > I just finished going through a couple of crontabs prepending the > > command-lines with ``exec'', when it hit me. > > > > Can shell itself recognize, there will be no more commands and just > > proceed to exec without forking? What would this break? > ... > > > 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
one SysV bug/fix, how many more
Two things:
1. I've been looking at sysv_shm.c, and shouldn't there be a ton of splvm()ing
going on which isn't? It seems that there are quite a few race conditions
that never showed up before because there was no support for sharing certain
parts of proc (p_vmspace etc.) For that matter, does any of kern_exit.c:exit1()
need to be spl()d? It sure seems like it to me. Along with other parts of
kern_exit.c, and many other things having to do with refcnt's. Is it just my
paranoia, or have I got this spl concept correct?
2. I sent a previous message, but got no reply at all; the patch included
follows here, and was made to fix a bug where non-removeable shm segments
existed.
--- src/sys/kern/sysv_shm.c.old Sat Feb 20 11:36:15 1999
+++ src/sys/kern/sysv_shm.c Sat Feb 20 11:46:19 1999
@@ -596,10 +596,13 @@
shmmap_s = (struct shmmap_state *)p->p_vmspace->vm_shm;
for (i = 0; i < shminfo.shmseg; i++, shmmap_s++)
- if (shmmap_s->shmid != -1)
+ if (shmmap_s->shmid != -1 &&
+ --shmsegs[IPCID_TO_IX(shmmap_s->shmid)].shm_nattch < 1)
shm_delete_mapping(p, shmmap_s);
- free((caddr_t)p->p_vmspace->vm_shm, M_SHM);
- p->p_vmspace->vm_shm = NULL;
+ if (p->p_vmspace->vm_refcnt == 1) {
+ free((caddr_t)p->p_vmspace->vm_shm, M_SHM);
+ p->p_vmspace->vm_shm = NULL;
+ }
}
void
--- src/sys/kern/kern_exit.c.oldSat Feb 20 11:36:02 1999
+++ src/sys/kern/kern_exit.cSat Feb 20 11:46:22 1999
@@ -206,6 +206,10 @@
/* The next two chunks should probably be moved to vmspace_exit. */
vm = p->p_vmspace;
+
+ if (vm->vm_shm)
+ shmexit(p);
+
/*
* Release user portion of address space.
* This releases references to vnodes,
@@ -215,8 +219,6 @@
* may be mapped within that space also.
*/
if (vm->vm_refcnt == 1) {
- if (vm->vm_shm)
- shmexit(p);
pmap_remove_pages(vmspace_pmap(vm), VM_MIN_ADDRESS,
VM_MAXUSER_ADDRESS);
(void) vm_map_remove(&vm->vm_map, VM_MIN_ADDRESS,
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: one SysV bug/fix, how many more
On Sun, 21 Feb 1999, Bruce Evans wrote: > >parts of proc (p_vmspace etc.) For that matter, does any of > >kern_exit.c:exit1() > >need to be spl()d? It sure seems like it to me. Along with other parts of > >kern_exit.c, and many other things having to do with refcnt's. Is it just my > >paranoia, or have I got this spl concept correct? > > spl is for blocking interrupts. Process-related things shouldn't be and > mostly aren't touched by interrupts. > > Bruce > But without an spl, couldn't multiple processes do Very Bad Things in a partially shared proc context? 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: one SysV bug/fix, how many more
On Mon, 22 Feb 1999, Bruce Evans wrote: > >> spl is for blocking interrupts. Process-related things shouldn't be and > >> mostly aren't touched by interrupts. > > >But without an spl, couldn't multiple processes do Very Bad Things in a > >partially shared proc context? > > They can do that with or without an spl if they don't lock things properly > spl can give improper giant locking as a side effect, but it doesn't > necessarily prevent other processes running, since tsleep() isn't locked > by spls. Okay, so we'd need a true mutex, not spl. Do you not agree that there are some pretty glaring races in code that assumes that vmspace, signals, etc. aren't shared? > > Bruce > 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: NFS Problems
On 22 Feb 1999, Joel Ray Holveck wrote: > >> The program on the client side always freezes (top reports it's > >> STAT as 'D'). > > You need to pass the 'l' switch to ps and look at the 'wchan' column to > > see where it's actually stuck. > > This reminds me; do we have a utility to reference wmesg strings back > to the code that sets them, a la TAGS? Would this be useful? > > Thanks, > joelh Ahem: glimpse! :) > > -- > Joel Ray Holveck - jo...@gnu.org >Fourth law of programming: >Anything that can go wrong wi > sendmail: segmentation violation - core dumped > > > 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: Filesystem deadlock
On Mon, 22 Feb 1999, Alexander N. Kabaev wrote: > The following script reliably causes FreeBSD 4.0-CURRENT (and 3.1-STABLE > as of today) to lookup. Shortly after this script is started, all disk > activity > > stops and any attempt to create new process causes system to freese. While in > DDB, ps command > > shows, that all ten fgrep processes are sleeping on inode, all xargs are in > waitpid and > > all sh processes are in wait. You forget about all the processes (just a few, actually) stuck in "kmaw" (kmem_alloc_wait). This is definitely reproducible :( Should be simple for someone more knowledgeable to diagnose, as it looks to be a straight vm/vfs(ufs/ffs) interaction. > > Unfortunately, I cannot run -g kernel on my box > at this time, so amount of useful information I can provide is pretty much > limited :( > > #!/bin/sh > for j in 1 2 3 4 5 6 7 8 9 10; do > echo -n $i $j > nohup sh -c 'while :; do find /usr -type f | xargs fgrep zukabuka; > done' \ > >/dev/null 2>&1 & > echo > done > > > > > > 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: LSOF import into base system?
On Tue, 23 Feb 1999, Ollivier Robert wrote: > According to David E . O'Brien: > > If people feel this is desired, I can easily bmake and import it. > > >From working with Vic Abell, I know he is interested in any > > problems/issues that we may find in LSOF if we find issues when > > scrutinizing it. > > Well, the way I see it, Vic is already maintaining LSOF for so many > platforms that I don't see any real advantage in importing it. As long as > he can sync with FreeBSD internal changes (and he can because he has access > to such systems -- thanks you for that), we have a a working lsof. > > That way, Vic doesn't have divergent versions (you don't plan to update > contrib/lsof for each change Vic makes to other platforms don't you ?). > > To be honest, I would not miss fstat(1), even if it is good ol' BSD code, I > install lsof everywhere. Putting lsof features into fstat is just IMO a > waste of time and code. AHEM! I use it. Often. I'm certain many others do to. Don't get rid of it, ever! > > Now, can we import Postfix instead ? :-) :-) [ducks and runs] > -- > Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr > FreeBSD keltia.freenix.fr 3.0-CURRENT #69: Mon Jan 18 02:02:12 CET 1999 > > > > 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: lockmgr panic with mmap()
On Sat, 27 Feb 1999, Jonathan Hanna wrote:
>
> The attached program sometimes causes a lockmgr panic. I do not think is
> always
> did. I am running 4.0-CURRENT form Feb 19.
>
> The trace is:
> panic lockmgr: locking against self
> lockmgr
> mv_map_growstack
> grow_stack
> trap_pfault
> trap
> calltrap
> subyte
> syscall
> ...
>
> A command on a running image such as this usually does it, though I do not
> know what
> conditions are neccessary:
>
> fincore /usr/local/netscape-4.5/communicator-4.5.bin
>
> Jonathan Hanna
>
>
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 2875392
initial pcb at 23ef40
panicstr: lockmgr: locking against myself
panic messages:
---
panic: lockmgr: locking against myself
syncing disks... 10 10 6 done
dumping to dev 20001, offset 73728
dump 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:287
287 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:287
#1 0xf0137821 in panic (fmt=0xf0206116 "lockmgr: locking against myself")
at ../../kern/kern_shutdown.c:448
#2 0xf0133738 in lockmgr (lkp=0xf5f5f280, flags=2, interlkp=0x0, p=0xf5f688e0)
at ../../kern/kern_lock.c:320
#3 0xf01a5b25 in vm_map_growstack (p=0xf5f688e0, addr=134524928)
at ../../vm/vm_map.c:666
#4 0xf01dc52a in grow_stack (p=0xf5f688e0, sp=134524928)
at ../../i386/i386/vm_machdep.c:571
#5 0xf01d836f in trap_pfault (frame=0xf5f70ec8, usermode=0, eva=134524928)
at ../../i386/i386/trap.c:808
#6 0xf01d806e in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -1,
tf_esi = 0, tf_ebp = -168358064, tf_isp = -168358160,
tf_ebx = 672337920, tf_edx = 134524928, tf_ecx = -168366080, tf_eax = 1,
tf_trapno = 12, tf_err = 2, tf_eip = -266506240, tf_cs = 8,
tf_eflags = 66067, tf_esp = -266694180, tf_ss = 134524928})
at ../../i386/i386/trap.c:437
#7 0xf01d7000 in suibyte ()
#8 0xf01d899f in syscall (frame={tf_es = 47, tf_ds = 47, tf_edi = 321312,
tf_esi = 134524928, tf_ebp = -272640092, tf_isp = -168357932,
tf_ebx = -272640036, tf_edx = 7, tf_ecx = 7, tf_eax = 78,
tf_trapno = 12, tf_err = 2, tf_eip = 671697364, tf_cs = 31,
tf_eflags = 582, tf_esp = -272640248, tf_ss = 47})
at ../../i386/i386/trap.c:1100
#9 0xf01cb69c in Xint0x80_syscall ()
#10 0x80485d1 in ?? ()
(kgdb) frame 8
#8 0xf01d899f in syscall (frame={tf_es = 47, tf_ds = 47, tf_edi = 321312,
tf_esi = 134524928, tf_ebp = -272640092, tf_isp = -168357932,
tf_ebx = -272640036, tf_edx = 7, tf_ecx = 7, tf_eax = 78,
tf_trapno = 12, tf_err = 2, tf_eip = 671697364, tf_cs = 31,
tf_eflags = 582, tf_esp = -272640248, tf_ss = 47})
at ../../i386/i386/trap.c:1100
1100 error = (*callp->sy_call)(p, args);
(kgdb) print callp
$1 = (struct sysent *) 0x0
(kgdb) quit
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: lockmgr panic with mmap() (fwd)
>
> The attached program sometimes causes a lockmgr panic. I do not think is
> always
> did. I am running 4.0-CURRENT form Feb 19.
>
> The trace is:
> panic lockmgr: locking against self
> lockmgr
> mv_map_growstack
> grow_stack
> trap_pfault
> trap
> calltrap
> subyte
> syscall
> ...
>
> A command on a running image such as this usually does it, though I do not
> know what
> conditions are neccessary:
>
> fincore /usr/local/netscape-4.5/communicator-4.5.bin
>
> Jonathan Hanna
>
>
Yep, this is reproducible :(
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 2875392
initial pcb at 23ef40
panicstr: lockmgr: locking against myself
panic messages:
---
panic: lockmgr: locking against myself
syncing disks... 10 10 6 done
dumping to dev 20001, offset 73728
dump 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:287
287 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:287
#1 0xf0137821 in panic (fmt=0xf0206116 "lockmgr: locking against myself")
at ../../kern/kern_shutdown.c:448
#2 0xf0133738 in lockmgr (lkp=0xf5f5f280, flags=2, interlkp=0x0, p=0xf5f688e0)
at ../../kern/kern_lock.c:320
#3 0xf01a5b25 in vm_map_growstack (p=0xf5f688e0, addr=134524928)
at ../../vm/vm_map.c:666
#4 0xf01dc52a in grow_stack (p=0xf5f688e0, sp=134524928)
at ../../i386/i386/vm_machdep.c:571
#5 0xf01d836f in trap_pfault (frame=0xf5f70ec8, usermode=0, eva=134524928)
at ../../i386/i386/trap.c:808
#6 0xf01d806e in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -1,
tf_esi = 0, tf_ebp = -168358064, tf_isp = -168358160,
tf_ebx = 672337920, tf_edx = 134524928, tf_ecx = -168366080, tf_eax = 1,
tf_trapno = 12, tf_err = 2, tf_eip = -266506240, tf_cs = 8,
tf_eflags = 66067, tf_esp = -266694180, tf_ss = 134524928})
at ../../i386/i386/trap.c:437
#7 0xf01d7000 in suibyte ()
#8 0xf01d899f in syscall (frame={tf_es = 47, tf_ds = 47, tf_edi = 321312,
tf_esi = 134524928, tf_ebp = -272640092, tf_isp = -168357932,
tf_ebx = -272640036, tf_edx = 7, tf_ecx = 7, tf_eax = 78,
tf_trapno = 12, tf_err = 2, tf_eip = 671697364, tf_cs = 31,
tf_eflags = 582, tf_esp = -272640248, tf_ss = 47})
at ../../i386/i386/trap.c:1100
#9 0xf01cb69c in Xint0x80_syscall ()
#10 0x80485d1 in ?? ()
(kgdb) frame 8
#8 0xf01d899f in syscall (frame={tf_es = 47, tf_ds = 47, tf_edi = 321312,
tf_esi = 134524928, tf_ebp = -272640092, tf_isp = -168357932,
tf_ebx = -272640036, tf_edx = 7, tf_ecx = 7, tf_eax = 78,
tf_trapno = 12, tf_err = 2, tf_eip = 671697364, tf_cs = 31,
tf_eflags = 582, tf_esp = -272640248, tf_ss = 47})
at ../../i386/i386/trap.c:1100
1100 error = (*callp->sy_call)(p, args);
(kgdb) print callp
$1 = (struct sysent *) 0x0
(kgdb) quit
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: gcc
How about this, which noone has suggested: Why don't we, for now, import EGCS and libstdc++, getting those working? Of course, here's the trick; let's keep /usr/bin/gcc and /usr/bin/cc as 2.7.2.x like they are now. But for /usr/bin/c++ and /usr/bin/g++, let's have EGCS overwrite the 2.7.2.x ones. As far as I see, EGCS doesn't gain anything for C, and only has gains for C++. Why not switch over partially? We can have 2.7.2.1 not build cc1plus, only cc1 and cc1obj, and have EGCS 1.1.1 build only cc1plus. With this, we get two advantages over the current system. Not only do we get a working, actively supported, C++ compiler, but also we get to keep (for now) the stable, reliable, C compiler we've been depending on for years. Noone can complain that the compiler is destabilizing the system, as all "system" utilities are in C, not C++, and noone can complain that we're behind the times with C++, since we have the latest C++ compiler and libstdc++. Of course, in the long run, once stability is proven, switching to entirely EGCS would make sense. 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: gcc
On Mon, 1 Mar 1999, Peter Jeremy wrote: > Brian Feldman wrote: > [use cc1-2.7.2.1 and ECGS cc1plus] > > > we get to keep > >(for now) the stable, reliable, C compiler we've been depending on for years. > > With all the well-known idiosyncrasies that we've been working around > for years. > > > Of > >course, in the long run, once stability is proven, switching to entirely EGCS > >would make sense. > > There's a catch-22 here: We can't prove the stability of EGCS until we > start using it. Even if we don't make EGCS the base compiler, we need > a standard documented mechanism for doing `make world' with EGCS as well > as agreement that bug reports using ECGS will be considered. All gcc/cc do is act as a front-end to cc1/cc1obj/cc1plus. Hence, a second cc for egcs could be used, or maybe using a cc -egcs flag, etc. > > Peter > 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: CALL FOR TESTERS of new ATA/ATAPI driver..
Do you have any plans to move the wfd(4) driver to the new ATA framework? I'd be glad to test it all out, as long as I don't lose my LS-120's functionality. Thanks in advance! 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: egcs and gcc
On Mon, 1 Mar 1999, Chuck Robey wrote: > On Mon, 1 Mar 1999, David O'Brien wrote: > > > > .if defined(WANT_SHAREDLIBS) > > > CONFIGURE_ARGS+= --enable-shared > > > .endif > > > > > > in it. That's not particularly friendly, I wonder why it was put in > > > there, unless the feature is somehow broken? I'm trying to rebuild it > > > now to see what it then installs. > > > > Because people like a previous poster thinks that eg++ should like > > against /usr/lib/libstdc++.so.2 which is plain WRONG. eg++ is totally > > incompatable with g++ 2.7.x. So what happens when you move an eg++ > > produced binary to a machine that doesn't have EGCS installed? > > OK, but listing from my gcc-lib/i386-unknown-freebsd4.0/egcs-2.91.62 > gives: > > SYSCALLS.c.XcrtbeginS.o libiberty.a > cc1*crtend.olibobjc.a > cc1obj* crtendS.o libstdc++.a > cc1plus*f771* libstdc++.so@ > collect2* include/libstdc++.so.2.9@ > cpp*libg2c.alibstdc++.so.2.9.0* > crtbegin.o libgcc.aspecs > > (I compiled this with the WANT_SHAREDLIBS on). It seems to make a > libstdc++.so.2.9 my first guess is, we'd want to bump the number so > that it fits the form for our loader (one rev number, not two) and use > it like the old one. It's the new form, done for egcs, it should work, > right? If you move it to a machine without version 3 installed, it'll > complain, right? > > I'm learning here, don't get upset if I'm all wet. Another thing I note > is that, unlike all the rest of the snapshots of egcs, the pre-release > version (and seemingly only the prerelease version) that the port uses > has gcj, the java tool, cut out. That seems kind of a shame, doesn't > it? > > I tried taking the gcj part out of the latest egcs snap, and dropping it > inplace in the prerelease version. Cygnus supplies the tarball for the > gcc/java directory separately (if you want it), bless them! It > configures ok (I *think*) with --enable-java, but it won't finish > compiling. It's Makefile isn't correct, doesn't have a rule for an > object file gcj needs (lost the error listing, I just had a freezeup). You're not concerned about the freezeup? > > I'm out of time tonight. I think you're telling me to redo my egcs > install with the WANT_SHAREDLIBS off, right? And you're going to have > the libstdc++ ported (I read that, right?) so I should just maybe be > patient? > > +--- > 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 picnic (FreeBSD-current) > (301) 220-2114 | and jaunt (Solaris7). > +--- > > > > > > > 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
