Re: occasional filesystem corruption

2001-03-11 Thread Boris Popov

On Tue, 20 Feb 2001, Vallo Kallaste wrote:

> I have experienced two filesystem corruption cases recently. Both
> took place in /usr filesystem, the first was file with very big
[skip]
> lock order reversal
> ../../kern/kern_synch.c:429: sleeping with "vnode interlock" locked from 
>/usr/ports/net/smbfs/work/smbfs-1.3.5/kernel/modules/smbfs2/../../fs/smbfs/smbfs_vnops.c:280

Thanks, this particular bug is fixed. Not sure if it can cause
filesystem corruption (in fact it shouldn't). However, it is not advisable
to use kernel modules with WITNESS enabled.

P.S. setting more appropriate subject might give a faster response :)
--
Boris Popov
http://www.butya.kz/~bp/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: make.conf lack of CPUTYPE=k6-3 support

2001-03-11 Thread Maxim Sobolev

Maxim Sobolev wrote:

> >
> >
> > --AhhlLboLdkugWU4S
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> > Content-Transfer-Encoding: quoted-printable
> >
> > On Mon, Mar 12, 2001 at 12:29:58AM -0300, Mario Sergio Fujikawa Ferreira wr=
> > ote:
> > > Hi,
> > >=20
> > > Is there anything against adding support for
> > > k6-3 to the just added CPUTYPE mechanism? :)
> > > My little machine feels left out. Hehehhe
> > > I made a simple patch to etc/defaults/make.conf
> > > and share/mk/bsd.cpu.mk
> > > Should I have touched anything else?
> > >=20
> > > Regards,
> > >=20
> > > ps: I think this can be MFCed asap (even during the
> > > veil period) since it is very straightforward.
> >
> > Looks fine to me. I'll commit it.
>
> I see no reason for it. k6-3 is essentially k6-2 core with extra cache on
> chip. Threre are no other significant differencies in the features or
> instruction set.

Not even to mention that there is such a beast as k6-2+

I would suggest to rename k6-2 into k6/3dnow (similarly to what we have for
i586/mmx) and put a note saying that k6/3dnow should be used for k6-2/k6-2+/k6-3.

-Maxim


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: make.conf lack of CPUTYPE=k6-3 support

2001-03-11 Thread Maxim Sobolev

> 
> 
> --AhhlLboLdkugWU4S
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Mon, Mar 12, 2001 at 12:29:58AM -0300, Mario Sergio Fujikawa Ferreira wr=
> ote:
> > Hi,
> >=20
> > Is there anything against adding support for
> > k6-3 to the just added CPUTYPE mechanism? :)
> > My little machine feels left out. Hehehhe
> > I made a simple patch to etc/defaults/make.conf
> > and share/mk/bsd.cpu.mk
> > Should I have touched anything else?
> >=20
> > Regards,
> >=20
> > ps: I think this can be MFCed asap (even during the
> > veil period) since it is very straightforward.
> 
> Looks fine to me. I'll commit it.

I see no reason for it. k6-3 is essentially k6-2 core with extra cache on
chip. Threre are no other significant differencies in the features or
instruction set.

-Maxim

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: how's vinum these days with DEVFS?

2001-03-11 Thread Alfred Perlstein

* Greg Lehey <[EMAIL PROTECTED]> [010311 21:20] wrote:
> On Sunday, 11 March 2001 at 20:39:03 -0800, Alfred Perlstein wrote:
> > * Greg Lehey <[EMAIL PROTECTED]> [010311 15:21] wrote:
> >> On Sunday, 11 March 2001 at  3:27:02 -0800, Alfred Perlstein wrote:
> >>>
> >>> Vinum+DEVFS doesn't make the million symlinks that non-devfs
> >>> vinum does.
> >>
> >> The only symlinks that the non-devfs version makes are to the drives.
> >> Everything else is device nodes.  But yes, it doesn't make as many
> >> device nodes, and that is a Good Thing.
> >>
> >>> Try using /dev/vinum/vol/raid01 instead of /dev/vinum/raid01
> >>>
> >>> (notice you need the '/vol/' path component)
> >>
> >> I missed that.  This is not correct.  The directory /dev/vinum/vol
> >> should go away.
> >
> > Er, too late. :)
> >
> > On a devfs system here's what you'll see:
> >
> >>> ls -lR /dev/vinum/
> > total 0
> > crw---  1 root  wheel   91, 0x4001 Feb 22 21:26 Control
> > crw---  1 root  wheel   91, 0x4002 Feb 22 21:26 control
> > crw---  1 root  wheel   91, 0x4000 Feb 22 21:26 controld
> > drwxr-xr-x  2 root  wheel 0 Mar 11 03:24 plex
> > drwxr-xr-x  2 root  wheel 0 Mar 11 03:24 sd
> > drwxr-xr-x  2 root  wheel 0 Mar 11 03:24 vol
> >
> > /dev/vinum/plex:
> > total 0
> > crw---  1 root  wheel   91,   1 Feb 22 21:26 vinum0.p0
> >
> > /dev/vinum/sd:
> > total 0
> > crw---  1 root  wheel   91,   2 Feb 22 21:26 vinum0.p0.s0
> > crw---  1 root  wheel   91, 0x1002 Feb 22 21:26 vinum0.p0.s1
> >
> > /dev/vinum/vol:
> > total 0
> > crw---  1 root  wheel   91,   0 Feb 22 21:26 vinum0
> >
> >
> > I'd like to keep it this way, it just makes sense.
> 
> No, that's a gratuitous change.  All the docco talks about keeping the
> volumes in the main directory.  That's why people are having trouble.
> Yes, it looks more uniform, but the objects aren't uniform.

Since both you and Poul refused to fix the code I choose how I thought
it should be.  Can you explain why:

> Yes, it looks more uniform, but the objects aren't uniform.

It just doesn't make sense to me to mix these device nodes in
with the control/Control/controld nodes.  Also, why not have
a /dev/vinum/ctl/ directory for those nodes?

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: make.conf lack of CPUTYPE=k6-3 support

2001-03-11 Thread Kris Kennaway

On Mon, Mar 12, 2001 at 12:29:58AM -0300, Mario Sergio Fujikawa Ferreira wrote:
> Hi,
> 
>   Is there anything against adding support for
> k6-3 to the just added CPUTYPE mechanism? :)
>   My little machine feels left out. Hehehhe
>   I made a simple patch to etc/defaults/make.conf
> and share/mk/bsd.cpu.mk
>   Should I have touched anything else?
> 
>   Regards,
> 
> ps: I think this can be MFCed asap (even during the
> veil period) since it is very straightforward.

Looks fine to me. I'll commit it.

Kris

 PGP signature


Re: swap-backed md-based /tmp to replace mfs-based one

2001-03-11 Thread Sheldon Hearn



On Sun, 11 Mar 2001 15:11:09 PST, Kris Kennaway wrote:

> We really need to provide a better rc.conf hook for doing this --
> expecting people to write their own script just to create a /tmp is
> lame.

Hello?  Anybody there?  Am I alone in this universe?  Throw the
goddamned ball!

[Apologies to Eddie Murphy]

I sent patches for this in this message:

Message-ID: <[EMAIL PROTECTED]>

You can grab the message from:

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=385910+0+current/cvs-all

Ciao,
Sheldon.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



FYI: nfs performance suboptimal

2001-03-11 Thread Warner Losh

Warning: The following is a somewhat vague report, given as a fyi.  I
don't need a resolution on this problem, but wanted to report it.

NFS server: Sony VAIO PCG-505TS
uname -a:
FreeBSD anvil.village.org 5.0-CURRENT FreeBSD 5.0-CURRENT #569: Sat
Mar 10 13:17:30 MST 2001
(really Mar 3 current)


NFS client: PPro-200
uname -a
FreeBSD billy-club.village.org 5.0-CURRENT FreeBSD 5.0-CURRENT #59:
Sat Feb 24 14:49:35 MST 2001

The Sony VAIO has a ep0 (3C589E).  It has 1 2.5" IDE drive.
The PPro has dc0: <82c169 PNIC 10/100BaseTX> on pci0.  It has a scsi
drive and an IDE drive.

I'm seeing about 100kbps on nfs read performance.  When I try to copy
about 300MB of mp3s like so
mount laptop:/mp3 /mnt
cd /mnt/path/to/files
tar cf - . | (cd /mp3 ; tar xvf -)

After about 10 minutes of really bad network performance, the network
dies.  All network traffic on the server gives errors with no buffers
available.  netstat -m shows that there are plenty of mbufs available
(10% are used).  I had to reboot to get the network back.  The client
survived just fine.

I have no clue if I can reproduce this, but thought I'd let people
know there might be dragons here.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: panic trying to play Civillization (with trace, etc.)

2001-03-11 Thread Mikhail Teterin

> Mikhail Teterin <[EMAIL PROTECTED]> writes:
> > Here is  the trace with my  attempts to browse through  it.
> 
> If you can, please reproduce the panic on a kernel compiled with the
> INVARIANTS, INVARIANT_SUPPORT and WITNESS options.

Well, with this options on, the machine does not crash, but the
program segfaults on startup:

   []
   430 ktrace   NAMI  "/usr/games/civctp"
   430 ktrace   RET   execve -1 errno 2 No such file or directory
   430 ktrace   CALL  execve(0xbfbff730,0xbfbffc40,0xbfbffc48)
   430 ktrace   NAMI  "/usr/local/sbin/civctp"
   430 ktrace   RET   execve -1 errno 2 No such file or directory
   430 ktrace   CALL  execve(0xbfbff730,0xbfbffc40,0xbfbffc48)
   430 ktrace   NAMI  "/usr/local/bin/civctp"
   430 civctp   RET   execve 0
   430 civctp   PSIG  SIGSEGV SIG_DFL
   430 civctp   NAMI  "civctp.core"

The points of interest:

. I had to brandelf the binary manually after I untarred the stuff
  from the CD Loki Games sent me.
. The Linux Netscape continues to work properly
. The binary crashes in the same fashion even when the /compat/linux
  is not available (not mounted), which leads me to believe, it is
  not recognized as a Linux binary
. One does not need to be root to cause the crash (on the system
  without INVARIANTS and WITNESS)
. The kernel has already complained twice since reboot:

# dmesg
[]
lock order reversal
 1st lockmgr interlock last acquired @ ../../kern/kern_lock.c:239
 2nd 0xcefa0520 process lock @ ../../kern/kern_sig.c:183
 3rd 0xc1029f80 lockmgr interlock @ ../../kern/kern_lock.c:560
lock order reversal
 1st vnode interlock last acquired @ ../../kern/vfs_vnops.c:625
 2nd 0xc0419680 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:939
 3rd 0xcefb986c vnode interlock @ ../../ufs/ffs/ffs_vfsops.c:948

-mi

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: how's vinum these days with DEVFS?

2001-03-11 Thread Greg Lehey

On Sunday, 11 March 2001 at 20:39:03 -0800, Alfred Perlstein wrote:
> * Greg Lehey <[EMAIL PROTECTED]> [010311 15:21] wrote:
>> On Sunday, 11 March 2001 at  3:27:02 -0800, Alfred Perlstein wrote:
>>>
>>> Vinum+DEVFS doesn't make the million symlinks that non-devfs
>>> vinum does.
>>
>> The only symlinks that the non-devfs version makes are to the drives.
>> Everything else is device nodes.  But yes, it doesn't make as many
>> device nodes, and that is a Good Thing.
>>
>>> Try using /dev/vinum/vol/raid01 instead of /dev/vinum/raid01
>>>
>>> (notice you need the '/vol/' path component)
>>
>> I missed that.  This is not correct.  The directory /dev/vinum/vol
>> should go away.
>
> Er, too late. :)
>
> On a devfs system here's what you'll see:
>
>>> ls -lR /dev/vinum/
> total 0
> crw---  1 root  wheel   91, 0x4001 Feb 22 21:26 Control
> crw---  1 root  wheel   91, 0x4002 Feb 22 21:26 control
> crw---  1 root  wheel   91, 0x4000 Feb 22 21:26 controld
> drwxr-xr-x  2 root  wheel 0 Mar 11 03:24 plex
> drwxr-xr-x  2 root  wheel 0 Mar 11 03:24 sd
> drwxr-xr-x  2 root  wheel 0 Mar 11 03:24 vol
>
> /dev/vinum/plex:
> total 0
> crw---  1 root  wheel   91,   1 Feb 22 21:26 vinum0.p0
>
> /dev/vinum/sd:
> total 0
> crw---  1 root  wheel   91,   2 Feb 22 21:26 vinum0.p0.s0
> crw---  1 root  wheel   91, 0x1002 Feb 22 21:26 vinum0.p0.s1
>
> /dev/vinum/vol:
> total 0
> crw---  1 root  wheel   91,   0 Feb 22 21:26 vinum0
>
>
> I'd like to keep it this way, it just makes sense.

No, that's a gratuitous change.  All the docco talks about keeping the
volumes in the main directory.  That's why people are having trouble.
Yes, it looks more uniform, but the objects aren't uniform.

Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: how's vinum these days with DEVFS?

2001-03-11 Thread Alfred Perlstein

* Boris Popov <[EMAIL PROTECTED]> [010311 20:52] wrote:
> On Sun, 11 Mar 2001, Poul-Henning Kamp wrote:
> 
> > In message <[EMAIL PROTECTED]>, Alfred Perlstein writes:
> > 
> > >What's up with devfs not gc'ing itself?  Ie, after a directory
> > >becomes empty it seems to still exist within the devfs namespace
> > >instead of disappearing.
> > 
> > That was a deliberate decision, removing a directory(-inode) which
> > might have a valid vnode is kind of a nasty thing to attempt.
> 
>   Err, "might" ?  These things are well defined by VFS interface.

You hand it off to deadfs no?

You want to have the same sort of handling that the common FS does
when let's say you have two xterms open, one in your homedir and the
other in homedir/foo, in the first you rmdir foo and suddenly the
second is a bit confused, but it doesn't panic the box...


-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: how's vinum these days with DEVFS?

2001-03-11 Thread Boris Popov

On Sun, 11 Mar 2001, Poul-Henning Kamp wrote:

> In message <[EMAIL PROTECTED]>, Alfred Perlstein writes:
> 
> >What's up with devfs not gc'ing itself?  Ie, after a directory
> >becomes empty it seems to still exist within the devfs namespace
> >instead of disappearing.
> 
> That was a deliberate decision, removing a directory(-inode) which
> might have a valid vnode is kind of a nasty thing to attempt.

Err, "might" ?  These things are well defined by VFS interface.

--
Boris Popov
http://www.butya.kz/~bp/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: how's vinum these days with DEVFS?

2001-03-11 Thread Alfred Perlstein

* Matthew Jacob <[EMAIL PROTECTED]> [010311 20:45] wrote:
> > 
> > Yeah... don't really need that. :)
> > 
> > In vinum's case there's a directory /dev/vinum/drive that points
> > to the device backing the vinum device:
> > 
> > /dev/vinum % ls -lR
> > total 7
> > brwx--  1 root  wheel   25, 0x4001 Sep 26  1999 Control
> > brwx--  1 root  wheel   25, 0x4002 Sep 26  1999 control
> > brwx--  1 root  wheel   25, 0x4000 Sep 26  1999 controld
> > drwxr-xr-x  2 root  wheel   512 Sep 26  1999 drive
> > drwxr-xr-x  2 root  wheel   512 Sep 26  1999 plex
> > drwxr-xr-x  2 root  wheel   512 Sep 26  1999 rplex
> > drwxr-xr-x  2 root  wheel   512 Sep 26  1999 rsd
> > crwxr-xr--  1 root  wheel   91,   0 Sep 26  1999 rvinum0
> > drwxr-xr-x  2 root  wheel   512 Sep 26  1999 rvol
> > drwxr-xr-x  2 root  wheel   512 Sep 26  1999 sd
> > brwxr-xr--  1 root  wheel   25,   0 Sep 26  1999 vinum0
> > drwxr-xr-x  3 root  wheel   512 Sep 26  1999 vol
> > 
> > ./drive:
> > total 0
> > lrwxr-xr-x  1 root  wheel   9 Sep 26  1999 vinumdrive0 -> /dev/da1e
> > lrwxr-xr-x  1 root  wheel  11 Sep 26  1999 vinumdrive1 -> /dev/da2s1e
> > 
> > Ok, now is there a way to get rid of these symlinks when vinum goes
> > away?  Ok, if there isn't a way to delete them, what if I unload
> > and reload vinum then try to make them again?
> > 
> 
> I'm afraid to answer. DES will stay angry.

Well now that was a giant waste of my time, wasn't it.

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: how's vinum these days with DEVFS?

2001-03-11 Thread Matthew Jacob

> 
> Yeah... don't really need that. :)
> 
> In vinum's case there's a directory /dev/vinum/drive that points
> to the device backing the vinum device:
> 
> /dev/vinum % ls -lR
> total 7
> brwx--  1 root  wheel   25, 0x4001 Sep 26  1999 Control
> brwx--  1 root  wheel   25, 0x4002 Sep 26  1999 control
> brwx--  1 root  wheel   25, 0x4000 Sep 26  1999 controld
> drwxr-xr-x  2 root  wheel   512 Sep 26  1999 drive
> drwxr-xr-x  2 root  wheel   512 Sep 26  1999 plex
> drwxr-xr-x  2 root  wheel   512 Sep 26  1999 rplex
> drwxr-xr-x  2 root  wheel   512 Sep 26  1999 rsd
> crwxr-xr--  1 root  wheel   91,   0 Sep 26  1999 rvinum0
> drwxr-xr-x  2 root  wheel   512 Sep 26  1999 rvol
> drwxr-xr-x  2 root  wheel   512 Sep 26  1999 sd
> brwxr-xr--  1 root  wheel   25,   0 Sep 26  1999 vinum0
> drwxr-xr-x  3 root  wheel   512 Sep 26  1999 vol
> 
> ./drive:
> total 0
> lrwxr-xr-x  1 root  wheel   9 Sep 26  1999 vinumdrive0 -> /dev/da1e
> lrwxr-xr-x  1 root  wheel  11 Sep 26  1999 vinumdrive1 -> /dev/da2s1e
> 
> Ok, now is there a way to get rid of these symlinks when vinum goes
> away?  Ok, if there isn't a way to delete them, what if I unload
> and reload vinum then try to make them again?
> 

I'm afraid to answer. DES will stay angry.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: how's vinum these days with DEVFS?

2001-03-11 Thread Alfred Perlstein

* Greg Lehey <[EMAIL PROTECTED]> [010311 15:21] wrote:
> On Sunday, 11 March 2001 at  3:27:02 -0800, Alfred Perlstein wrote:
> >
> > Vinum+DEVFS doesn't make the million symlinks that non-devfs
> > vinum does.
> 
> The only symlinks that the non-devfs version makes are to the drives.
> Everything else is device nodes.  But yes, it doesn't make as many
> device nodes, and that is a Good Thing.
> 
> > Try using /dev/vinum/vol/raid01 instead of /dev/vinum/raid01
> >
> > (notice you need the '/vol/' path component)
> 
> I missed that.  This is not correct.  The directory /dev/vinum/vol
> should go away.

Er, too late. :)

On a devfs system here's what you'll see:

~ % ls -lR /dev/vinum/
total 0
crw---  1 root  wheel   91, 0x4001 Feb 22 21:26 Control
crw---  1 root  wheel   91, 0x4002 Feb 22 21:26 control
crw---  1 root  wheel   91, 0x4000 Feb 22 21:26 controld
drwxr-xr-x  2 root  wheel 0 Mar 11 03:24 plex
drwxr-xr-x  2 root  wheel 0 Mar 11 03:24 sd
drwxr-xr-x  2 root  wheel 0 Mar 11 03:24 vol

/dev/vinum/plex:
total 0
crw---  1 root  wheel   91,   1 Feb 22 21:26 vinum0.p0

/dev/vinum/sd:
total 0
crw---  1 root  wheel   91,   2 Feb 22 21:26 vinum0.p0.s0
crw---  1 root  wheel   91, 0x1002 Feb 22 21:26 vinum0.p0.s1

/dev/vinum/vol:
total 0
crw---  1 root  wheel   91,   0 Feb 22 21:26 vinum0


I'd like to keep it this way, it just makes sense.

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: how's vinum these days with DEVFS?

2001-03-11 Thread Alfred Perlstein

* Matthew Jacob <[EMAIL PROTECTED]> [010311 12:19] wrote:
> On Sun, 11 Mar 2001, Alfred Perlstein wrote:
> 
> > * Poul-Henning Kamp <[EMAIL PROTECTED]> [010311 12:02] wrote:
> > > In message <[EMAIL PROTECTED]>, Matthew 
>Jacob writes:
> > > >
> > > >> Lastly make_dev_alias() is undocumented.
> > > 
> > > Right, just like most of the rest of the kernel.
> > > 
> > > >Really? That's a deficiency. It should be.
> > > 
> > > Yes, ideally, yes.
> 
> I've updated the man page.
> 
> > 
> > The problem with make_dev_alias() not being documented is that it would
> > have been an effort to figure out if duplicate make_dev_alias() calls
> > were idempotent, done with refcounts or a good way to panic your
> > machine.
> 
> ...I'm not following this. Too many dime or more expensive words! What you at?
> 
> > 
> > There's also no destroy_dev_alias() that I can see.  So when vinum
> > goes away I didn't realize how one unpopulates the /dev/vinum/ tree.
> 
> The destroy_dev destroys all aliases.

Yeah... don't really need that. :)

In vinum's case there's a directory /dev/vinum/drive that points
to the device backing the vinum device:

/dev/vinum % ls -lR
total 7
brwx--  1 root  wheel   25, 0x4001 Sep 26  1999 Control
brwx--  1 root  wheel   25, 0x4002 Sep 26  1999 control
brwx--  1 root  wheel   25, 0x4000 Sep 26  1999 controld
drwxr-xr-x  2 root  wheel   512 Sep 26  1999 drive
drwxr-xr-x  2 root  wheel   512 Sep 26  1999 plex
drwxr-xr-x  2 root  wheel   512 Sep 26  1999 rplex
drwxr-xr-x  2 root  wheel   512 Sep 26  1999 rsd
crwxr-xr--  1 root  wheel   91,   0 Sep 26  1999 rvinum0
drwxr-xr-x  2 root  wheel   512 Sep 26  1999 rvol
drwxr-xr-x  2 root  wheel   512 Sep 26  1999 sd
brwxr-xr--  1 root  wheel   25,   0 Sep 26  1999 vinum0
drwxr-xr-x  3 root  wheel   512 Sep 26  1999 vol

./drive:
total 0
lrwxr-xr-x  1 root  wheel   9 Sep 26  1999 vinumdrive0 -> /dev/da1e
lrwxr-xr-x  1 root  wheel  11 Sep 26  1999 vinumdrive1 -> /dev/da2s1e

Ok, now is there a way to get rid of these symlinks when vinum goes
away?  Ok, if there isn't a way to delete them, what if I unload
and reload vinum then try to make them again?

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



make.conf lack of CPUTYPE=k6-3 support

2001-03-11 Thread Mario Sergio Fujikawa Ferreira

Hi,

Is there anything against adding support for
k6-3 to the just added CPUTYPE mechanism? :)
My little machine feels left out. Hehehhe
I made a simple patch to etc/defaults/make.conf
and share/mk/bsd.cpu.mk
Should I have touched anything else?

Regards,

ps: I think this can be MFCed asap (even during the
veil period) since it is very straightforward.

-- 
Mario S F Ferreira - UnB - Brazil - "I guess this is a signature."
lioux at ( freebsd dot org | linf dot unb dot br )
flames to beloved [EMAIL PROTECTED]


--- etc/defaults/make.conf.orig Sat Mar 10 04:35:47 2001
+++ etc/defaults/make.conf  Mon Mar 12 00:23:16 2001
@@ -22,7 +22,7 @@
 # NO_CPU_CFLAGS variable below.
 # Currently the following CPU types are recognised:
 #   Intel x86 architecture:
-#   (AMD CPUs) k7 k6-2 k6 k5
+#   (AMD CPUs) k7 k6-3 k6-2 k6 k5
 #   (Intel CPUs)   p4 p3 p2 i686 i586/mmx i586 i486 i386
 #   Alpha/AXP architecture: ev6 pca56 ev56 ev5 ev45 ev4
 #


--- share/mk/bsd.cpu.mk.origSun Mar  4 06:40:11 2001
+++ share/mk/bsd.cpu.mk Mon Mar 12 00:21:16 2001
@@ -30,6 +30,8 @@
 . if ${MACHINE_ARCH} == "i386"
 .  if ${CPUTYPE} == "k7"
 CFLAGS += -march=k6# gcc doesn't support athlon yet, but it will
+.  elif ${CPUTYPE} == "k6-3"
+CFLAGS += -march=k6
 .  elif ${CPUTYPE} == "k6-2"
 CFLAGS += -march=k6
 .  elif ${CPUTYPE} == "k6"
@@ -75,6 +77,8 @@
 .if ${MACHINE_ARCH} == "i386"
 . if ${CPUTYPE} == "k7"
 MACHINE_CPU = k7 3dnow k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == "k6-3"
+MACHINE_CPU = 3dnow k6 k5 i586 i486 i386
 . elif ${CPUTYPE} == "k6-2"
 MACHINE_CPU = 3dnow k6 k5 i586 i486 i386
 . elif ${CPUTYPE} == "k6"



Re: swap-backed md-based /tmp to replace mfs-based one

2001-03-11 Thread Dima Dorfman

Kris Kennaway <[EMAIL PROTECTED]> writes:
> On Sun, Mar 11, 2001 at 03:15:27PM -0800, David O'Brien wrote:
> > It should be a wrapper called mount_mdfs or mount_mfs so people upgrading
> > can keep their /etc/fstab [mostly] the same.
> 
> The latter would be best, IMO.

I wrote a program to do this, but noone showed very much interest on
-hackers.  The pros are that it makes it very convenient to do all
sorts of things with md without having to write different scripts to
do it.  The cons are that it "calls itself a mount_* but isn't a
mount_* since it just runs a bunch of programs", and that it breaks
`mount -p` because the filesystem shows up as "ufs" (which is
technically correct).  I'll post a URL to the code (it's a C program)
if someone wants to look at it.

Dima Dorfman
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: swap-backed md-based /tmp to replace mfs-based one

2001-03-11 Thread David Wolfskill

>Date: Sun, 11 Mar 2001 15:11:09 -0800
>From: Kris Kennaway <[EMAIL PROTECTED]>
>To: Hajimu UMEMOTO <[EMAIL PROTECTED]>

>We really need to provide a better rc.conf hook for doing this --
>expecting people to write their own script just to create a /tmp is
>lame.

I appreciate the validation that what I'm trying to do makes sense (at
least to some folks).  And I appreciate Hajimu Umemoto's contribution,
since I hadn't been aware of the "diskless_mount" specification.

But basically, I agree with the sentiment re: making it easier.

I would be very pleased if it were made as easy as the use of an
mfs-based /tmp (merely specify "filesystem type" as "mfs"), but my
(very!) brief acquaintance with the semantics of the md device gives me
the impression that the exact approach is unlikely to be useful.

But if we could have a set of variables defined in /etc{/defaults,}/rc.conf
for providing the parameters for creating the md-based /tmp, as well as
the decision as to whether or not this is wanted, and have some code in
/etc/rc* that pays attention to it, I believe that could be quite
satisfactory.  So far, it seems to me that the critical parameters would
be the binary go/no go decision and the size.  (It appears that the md
device name can be dynamically assigned at creation time.)

(I believe it would also be useful if /etc/rc.shutdown were to unmount
and de-allocate the resources for such things -- not becasue of any
familiarity with the code, but because that just seems to be the Right
Thing To Do.  And to that end, it might be useful to have a somewhat
separate script (from the rest of the existing /etc/rc* scripts) that
could be invoked to create or destroy the /tmp.)

Cheers,
david
-- 
David H. Wolfskill  [EMAIL PROTECTED]
As a computing professional, I believe it would be unethical for me to
advise, recommend, or support the use (save possibly for personal
amusement) of any product that is or depends on any Microsoft product.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: swap-backed md-based /tmp to replace mfs-based one

2001-03-11 Thread Kris Kennaway

On Sun, Mar 11, 2001 at 03:15:27PM -0800, David O'Brien wrote:
> On Sun, Mar 11, 2001 at 03:11:09PM -0800, Kris Kennaway wrote:
> > We really need to provide a better rc.conf hook for doing this --
> > expecting people to write their own script just to create a /tmp is
> > lame.
> 
> It should be a wrapper called mount_mdfs or mount_mfs so people upgrading
> can keep their /etc/fstab [mostly] the same.

The latter would be best, IMO.

Kris

 PGP signature


Re: how's vinum these days with DEVFS?

2001-03-11 Thread Greg Lehey

On Sunday, 11 March 2001 at  3:27:02 -0800, Alfred Perlstein wrote:
> * Niels Chr. Bank-Pedersen <[EMAIL PROTECTED]> [010311 02:29] wrote:
>>
>> I'll sneak in my experience with DEVFS+vinum here as well:
>>
>>   vinum: loaded
>>   vinum: reading configuration from /dev/da3s1f
>>   vinum: updating configuration from /dev/da1s1e
>>   vinum: updating configuration from /dev/da2s1e
>>   vinum: updating configuration from /dev/da0s1e
>>   swapon: adding /dev/da1s1b as swap device
>>   swapon: adding /dev/da2s1b as swap device
>>   Automatic boot in progress...
>>   /dev/da0s1a: FILESYSTEM CLEAN; SKIPPING CHECKS
>>   /dev/da0s1a: clean, 406977 free (1049 frags, 50741 blocks, 0.2% fragmentation)
>>   Can't stat /dev/vinum/raid01: No such file or directory
>>   Can't stat /dev/vinum/raid01: No such file or directory
>>   /dev/vinum/raid01: CAN'T CHECK FILE SYSTEM.
>>   /dev/vinum/raid01: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
>>
>> This was with a -current from around March 1. (don't think
>> anything has changed since).  Booting a non-DEVFS kernel
>> passes the fs-check and works as expected.
>
> Vinum+DEVFS doesn't make the million symlinks that non-devfs
> vinum does.

The only symlinks that the non-devfs version makes are to the drives.
Everything else is device nodes.  But yes, it doesn't make as many
device nodes, and that is a Good Thing.

> Try using /dev/vinum/vol/raid01 instead of /dev/vinum/raid01
>
> (notice you need the '/vol/' path component)

I missed that.  This is not correct.  The directory /dev/vinum/vol
should go away.

Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: swap-backed md-based /tmp to replace mfs-based one

2001-03-11 Thread David O'Brien

On Sun, Mar 11, 2001 at 03:11:09PM -0800, Kris Kennaway wrote:
> We really need to provide a better rc.conf hook for doing this --
> expecting people to write their own script just to create a /tmp is
> lame.

It should be a wrapper called mount_mdfs or mount_mfs so people upgrading
can keep their /etc/fstab [mostly] the same.
 
-- 
-- David  ([EMAIL PROTECTED])
  GNU is Not Unix / Linux Is Not UniX

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: swap-backed md-based /tmp to replace mfs-based one

2001-03-11 Thread Kris Kennaway

We really need to provide a better rc.conf hook for doing this --
expecting people to write their own script just to create a /tmp is
lame.

Kris

 PGP signature


Re: how's vinum these days with DEVFS?

2001-03-11 Thread Poul-Henning Kamp

In message <[EMAIL PROTECTED]>, Matthew Jacob 
writes:
>
>> Lastly make_dev_alias() is undocumented.

Right, just like most of the rest of the kernel.

>Really? That's a deficiency. It should be.

Yes, ideally, yes.


--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: how's vinum these days with DEVFS?

2001-03-11 Thread Poul-Henning Kamp

In message <[EMAIL PROTECTED]>, Alfred Perlstein writes:

>What's up with devfs not gc'ing itself?  Ie, after a directory
>becomes empty it seems to still exist within the devfs namespace
>instead of disappearing.

That was a deliberate decision, removing a directory(-inode) which
might have a valid vnode is kind of a nasty thing to attempt.

>Since you guys are in docco mode, you might as well document how one
>detects a devfs system in a running system.  There's an example
>in the vinum(8) source:
>
>if (sysctlbyname("vfs.devfs.generation", NULL, NULL, NULL, 0) == 0)
>devfs_is_active = 1;
>else
>devfs_is_active = 0;

Which is the correct and blessed way to find out.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: swap-backed md-based /tmp to replace mfs-based one

2001-03-11 Thread Hajimu UMEMOTO

> On Sun, 11 Mar 2001 13:17:58 -0800 (PST)
> David Wolfskill <[EMAIL PROTECTED]> said:

david> Accordingly, I created the following shell script to accomplish a
david> similar objective, based upon the above-mentioned example in the
david> mdconfig man page.  At present, I have it sitting in
david> /usr/local/etc/rc.d, which isn't ideal, but I wanted to find out if
david> anyone had better approaches for doing this, suggestions for
david> improvement, or arguments that what I'm trying to do is misguided and
david> shouldn't be done:

I wrote following script obtained from manpage:

#!/bin/sh
mdconfig -a -t swap -s 128M -u 10
disklabel -r -w md10 auto
newfs /dev/md10c
tunefs -n enable /dev/md10c
mount /dev/md10c /tmp
chmod 1777 /tmp

Then, I put diskless_mount="/etc/rc.mount_tmp" into /etc/rc.conf.

--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED]  [EMAIL PROTECTED]  ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: how's vinum these days with DEVFS (second part)

2001-03-11 Thread Matthew Jacob


> Matthew Jacob <[EMAIL PROTECTED]> writes:
> > > Matthew Jacob <[EMAIL PROTECTED]> writes:
> > > > Hmm. Sounds to me more like an argument for requiring devfs if you
> > > > use vinum.
> > > Not until vinum works equally well with devfs as without it.
> > Har har har har har
> 
> Please take your sarcasm and shove it. And get acquainted with the
> issue at hand before joining the discussion.

I am acquainted with this issue. I actually started it with the subject
above. I have been mostly reading the threads.

I think you owe me an apology.

-matt



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



swap-backed md-based /tmp to replace mfs-based one

2001-03-11 Thread David Wolfskill

During the past week, I've been tracking -STABLE (daily) & -CURRENT (about
2 days out of 3) on a new laptop.  (More stuff about that in the recent
-mobile archives, for folks who might have an interest.)

Although I realize that there are significant differences between the
FreeBSD mfs vs. the Sun tmpfs, using an mfs-based, swap-backed /tmp has
generally been working well for me over the last 3 years of using FreeBSD.
(I tend to be generous with swap diskspace allocations, which helps.)

And on this laptop, I have 3 different bootable "root" (& associated /usr)
partitions, so I can run -CURRENT, as well as run either of a couple of
-STABLEs.  But since I'm running no more than one at a time, it made sense
to me to have the swap space be common to all three environments, and to
make /tmp be swap-backed.

In -STABLE, I merely stuffed an appropriate entry in /etc/fstab, and It
Just Worked.  However, based on the example in the mdconfig man page on
-CURRENT, I get the impression that the process is a little more
involved.

Accordingly, I created the following shell script to accomplish a
similar objective, based upon the above-mentioned example in the
mdconfig man page.  At present, I have it sitting in
/usr/local/etc/rc.d, which isn't ideal, but I wanted to find out if
anyone had better approaches for doing this, suggestions for
improvement, or arguments that what I'm trying to do is misguided and
shouldn't be done:

#!/bin/sh

size=512M   # Plugged directly in to the mdconfig command,
# so use an expression that's compatible with that.

case "$1" in
start)
# Taken from the mdconfig man page, then lightly hacked:
# To create and mount a 128MByte swap backed filesystem on /tmp:
if [ -x /sbin/mdconfig ]; then
/sbin/mdconfig -a -t swap -s $size -u 10 && \
/sbin/disklabel -r -w md10 auto && \
/sbin/newfs /dev/md10c && \
/sbin/tunefs -n enable /dev/md10c && \
/sbin/mount /dev/md10c /tmp && \
/bin/chmod 1777 /tmp && \
exit 0
fi
;;
stop)
dev=`/sbin/mount | /usr/bin/awk '/ \/tmp / {print $1}'` || exit 1
/sbin/umount /tmp && [ -c $dev ] && /sbin/mdconfig -d -u $dev
exit 0
;;
*)
echo "Usage: `basename $0` {start|stop}" >&2
;;
esac

exit 2



Thanks,
david
-- 
David H. Wolfskill  [EMAIL PROTECTED]
As a computing professional, I believe it would be unethical for me to
advise, recommend, or support the use (save possibly for personal
amusement) of any product that is or depends on any Microsoft product.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: how's vinum these days with DEVFS (second part)

2001-03-11 Thread Dag-Erling Smorgrav

Matthew Jacob <[EMAIL PROTECTED]> writes:
> > Matthew Jacob <[EMAIL PROTECTED]> writes:
> > > Hmm. Sounds to me more like an argument for requiring devfs if you
> > > use vinum.
> > Not until vinum works equally well with devfs as without it.
> Har har har har har

Please take your sarcasm and shove it. And get acquainted with the
issue at hand before joining the discussion.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: panic trying to play Civillization (with trace, etc.)

2001-03-11 Thread Dag-Erling Smorgrav

Mikhail Teterin <[EMAIL PROTECTED]> writes:
> Here is  the trace with my  attempts to browse through  it.

If you can, please reproduce the panic on a kernel compiled with the
INVARIANTS, INVARIANT_SUPPORT and WITNESS options.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: how's vinum these days with DEVFS (second part)

2001-03-11 Thread Matthew Jacob


> Matthew Jacob <[EMAIL PROTECTED]> writes:
> > Hmm. Sounds to me more like an argument for requiring devfs if you
> > use vinum.
> 
> Not until vinum works equally well with devfs as without it.

Har har har har har

Almost a Catch-22... "We have to do really wierd things so vinum will work
equally well without devfs as with it... so we can, then, remove all the
wierd things we did to make vinum work equally well without devfs as with
it"...

I think what you really meant to say was "No, we won't require devfs".




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: how's vinum these days with DEVFS (second part)

2001-03-11 Thread Matthew Jacob


I think I'm assuming that DEVFS will become standard. I really see it working
very very well and solving lots of problems. I have yet to really find cases
where it really *can't* work (modulo broken drivers).


> 
> > Matthew Jacob <[EMAIL PROTECTED]> writes:
> > > Hmm. Sounds to me more like an argument for requiring devfs if you
> > > use vinum.
> > 
> > Not until vinum works equally well with devfs as without it.
> 
> Har har har har har
> 
> Almost a Catch-22... "We have to do really wierd things so vinum will work
> equally well without devfs as with it... so we can, then, remove all the
> wierd things we did to make vinum work equally well without devfs as with
> it"...
> 
> I think what you really meant to say was "No, we won't require devfs".
> 
> 
> 
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: how's vinum these days with DEVFS (second part)

2001-03-11 Thread Dag-Erling Smorgrav

Matthew Jacob <[EMAIL PROTECTED]> writes:
> Hmm. Sounds to me more like an argument for requiring devfs if you
> use vinum.

Not until vinum works equally well with devfs as without it.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: how's vinum these days with DEVFS (second part)

2001-03-11 Thread Matthew Jacob

On 11 Mar 2001, Dag-Erling Smorgrav wrote:

> Matthew Jacob <[EMAIL PROTECTED]> writes:
> > > Since you guys are in docco mode, you might as well document how one
> > > detects a devfs system in a running system.
> > Why should you care?
> 
> Because if the system doesn't have devfs, the userland vinum code
> needs to create the device nodes "manually".

Hmm. Sounds to me more like an argument for requiring devfs if you use vinum.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: how's vinum these days with DEVFS (second part)

2001-03-11 Thread Dag-Erling Smorgrav

Matthew Jacob <[EMAIL PROTECTED]> writes:
> > Since you guys are in docco mode, you might as well document how one
> > detects a devfs system in a running system.
> Why should you care?

Because if the system doesn't have devfs, the userland vinum code
needs to create the device nodes "manually".

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: how's vinum these days with DEVFS (second part)

2001-03-11 Thread Matthew Jacob


> Since you guys are in docco mode, you might as well document how one
> detects a devfs system in a running system.  There's an example
> in the vinum(8) source:
> 
> if (sysctlbyname("vfs.devfs.generation", NULL, NULL, NULL, 0) == 0)
> devfs_is_active = 1;
> else
> devfs_is_active = 0;

Why should you care? You should be calling make_dev/make_dev_alias/destroy_dev
whether DEVFS is running or not. Why on earth would you want things to be
different? Is it because you see DEVFS as not offering something you can get
w/o it or what

-matt



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: how's vinum these days with DEVFS?

2001-03-11 Thread Matthew Jacob

On Sun, 11 Mar 2001, Alfred Perlstein wrote:

> * Poul-Henning Kamp <[EMAIL PROTECTED]> [010311 12:02] wrote:
> > In message <[EMAIL PROTECTED]>, Matthew 
>Jacob writes:
> > >
> > >> Lastly make_dev_alias() is undocumented.
> > 
> > Right, just like most of the rest of the kernel.
> > 
> > >Really? That's a deficiency. It should be.
> > 
> > Yes, ideally, yes.

I've updated the man page.

> 
> The problem with make_dev_alias() not being documented is that it would
> have been an effort to figure out if duplicate make_dev_alias() calls
> were idempotent, done with refcounts or a good way to panic your
> machine.

...I'm not following this. Too many dime or more expensive words! What you at?

> 
> There's also no destroy_dev_alias() that I can see.  So when vinum
> goes away I didn't realize how one unpopulates the /dev/vinum/ tree.

The destroy_dev destroys all aliases.

> 
> What's up with devfs not gc'ing itself?  Ie, after a directory
> becomes empty it seems to still exist within the devfs namespace
> instead of disappearing.
> 
> Since you guys are in docco mode, you might as well document how one
> detects a devfs system in a running system.  There's an example
> in the vinum(8) source:
> 
> if (sysctlbyname("vfs.devfs.generation", NULL, NULL, NULL, 0) == 0)
> devfs_is_active = 1;
> else
> devfs_is_active = 0;
> 
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: how's vinum these days with DEVFS?

2001-03-11 Thread Alfred Perlstein

* Poul-Henning Kamp <[EMAIL PROTECTED]> [010311 12:02] wrote:
> In message <[EMAIL PROTECTED]>, Matthew Jacob 
>writes:
> >
> >> Lastly make_dev_alias() is undocumented.
> 
> Right, just like most of the rest of the kernel.
> 
> >Really? That's a deficiency. It should be.
> 
> Yes, ideally, yes.

The problem with make_dev_alias() not being documented is that it would
have been an effort to figure out if duplicate make_dev_alias() calls
were idempotent, done with refcounts or a good way to panic your
machine.

There's also no destroy_dev_alias() that I can see.  So when vinum
goes away I didn't realize how one unpopulates the /dev/vinum/ tree.

What's up with devfs not gc'ing itself?  Ie, after a directory
becomes empty it seems to still exist within the devfs namespace
instead of disappearing.

Since you guys are in docco mode, you might as well document how one
detects a devfs system in a running system.  There's an example
in the vinum(8) source:

if (sysctlbyname("vfs.devfs.generation", NULL, NULL, NULL, 0) == 0)
devfs_is_active = 1;
else
devfs_is_active = 0;

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: how's vinum these days with DEVFS?

2001-03-11 Thread Matthew Jacob

On Sun, 11 Mar 2001, Poul-Henning Kamp wrote:

> In message <[EMAIL PROTECTED]>, Matthew Jacob 
>writes:
> >
> >> Lastly make_dev_alias() is undocumented.
> 
> Right, just like most of the rest of the kernel.
> 
> >Really? That's a deficiency. It should be.
> 
> Yes, ideally, yes.
I'm hacking the man page now.. Feel free to correct the change


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: how's vinum these days with DEVFS?

2001-03-11 Thread Matthew Jacob


> Lastly make_dev_alias() is undocumented.

Really? That's a deficiency. It should be.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: how's vinum these days with DEVFS?

2001-03-11 Thread Alfred Perlstein

* Dag-Erling Smorgrav <[EMAIL PROTECTED]> [010311 09:02] wrote:
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > Vinum+DEVFS doesn't make the million symlinks that non-devfs
> > vinum does.
> 
> Why not? make_dev_alias() is cheap and easy to use.

Take a look at the /dev/vinum tree under devfs and non-devfs systems
and you'll understand why I wanted to get rid of the symlinks.

Basically, I found them to be distasteful and not worth keeping
around.

To completely emulate the rats' nest of symlinks I would have had
to link to outside disks as well, I really didn't want to do
that.

Lastly make_dev_alias() is undocumented.

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Threaded linux should work again

2001-03-11 Thread Dag-Erling Smorgrav

I fixed the bug in linux_clone() that made caused the 'not SRUN'
panics in -CURRENT. Opera, Tivoli and other threaded Linux apps should
now work again.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: libg2c missing?

2001-03-11 Thread Leif Neland

Solved! I had NO_FORTRAN=true on master, but not on slave.
After I sync'ed the make.conf's, I could install.

Leif

- Original Message - 
From: "Leif Neland" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, March 10, 2001 4:03 PM
Subject: libg2c missing?


> I've got two machines, called say master and slave.
> 
> Master got the sources, and I do a cvsup and make world almost every
> night.
> 
> Occationally (once a month or so, when current is in a not too bad shape)
> I mount master:/usr/src and master:/usr/obj on slave, and do an
> installworld.
> 
> Now it fails in gnu/lib/libg2c:
> install -c -o root -g wheel -m 444   libg2c.a /usr/lib
> install: libg2c.a: No such file or directory
> *** Error code 71
> 
> The typescript for make world on master doesn't mention libg2c.
> I've got libg2c.a dated feb 8 and libg2c.so.1 dated feb 4 on master, while
> the other libs are from tonights buildworld.
> 
> I copied /usr/lib/libg2c* from master to slave, but that didn't do any
> difference.
> 
> So the question is: Why will this buildworld, which can installworld on
> master, not installworld on slave, which is not that much older?
> 
> Leif
> 
> 
> 
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: growfs

2001-03-11 Thread Steve O'Hara-Smith

On Sun, 11 Mar 2001 14:13:38 +0100
Andrea Campi <[EMAIL PROTECTED]> wrote:

AC> I was about to fill in a doc PR on this but then I thought I'm better off
AC> checking other people experiences...

A completely different question about growfs - is it fit for -stable ?
If so could it be MFC'd (after 4.3 I suppose).

-- 
Life is complex - it has real and imaginary parts.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: how's vinum these days with DEVFS?

2001-03-11 Thread Dag-Erling Smorgrav

Alfred Perlstein <[EMAIL PROTECTED]> writes:
> Vinum+DEVFS doesn't make the million symlinks that non-devfs
> vinum does.

Why not? make_dev_alias() is cheap and easy to use.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



-CURRENT no longer boots

2001-03-11 Thread Dag-Erling Smorgrav

Booting [/boot/kernel/kernel]...   
Copyright (c) 1992-2001 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #51: Sun Mar 11 17:31:08 CET 2001
[EMAIL PROTECTED]:/usr/src/sys/compile/DES
Timecounter "i8254"  frequency 1193182 Hz
CPU: AMD-K6(tm) 3D processor (350.80-MHz 586-class CPU)
  Origin = "AuthenticAMD"  Id = 0x58c  Stepping = 12
  Features=0x8021bf
  AMD Features=0x8800
real memory  = 201310208 (196592K bytes)
avail memory = 191782912 (187288K bytes)
Preloaded elf kernel "kernel" at 0xc03c1000.
K6-family MTRR support enabled (2 registers)
VESA: v2.0, 8192k memory, flags:0x1, mode table:0xc033ffa2 (122)
VESA: Matrox Graphics Inc.
Using $PIR table, 8 entries at 0xc00f0b40
apm0:  on motherboard
apm0: found APM BIOS v1.2, connected at v1.2
npx0:  on motherboard
npx0: INT 16 interface
pcib0:  at pcibus 0 on motherboard
pci0:  on pcib0
agp0:  mem 0xe000-0xe3ff at device 0.0 on pci0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
pci1:  at 0.0 (no driver attached)
pci0:  at 3.0 (no driver attached)
isab0:  at device 7.0 on pci0
isa0:  on isab0
xl0: <3Com 3c900-COMBO Etherlink XL> port 0xd800-0xd83f irq 12 at device 11.0 on pci0
xl0: Ethernet address: 00:60:08:cf:a8:e4
xl0: selecting 10baseT transceiver, half duplex
atapci0:  port 0xd400-0xd40f irq 0 at device 15.0 
on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
ed0 at port 0x280-0x29f iomem 0xd8000 irq 5 on isa0
ed0: address 00:20:18:64:9b:b6, type NE2000 (16 bit) 
sc0:  at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x100>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A, console
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
sbc0:  at port 0x220-0x22f,0x300-0x301,0x388-0x38b irq 7 drq 0,1 on 
isa0
pcm0:  on sbc0
unknown:  can't assign resources
unknown:  can't assign resources
sio1: <16550A-compatible COM port> at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
fdc0:  at port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on isa0
atkbdc0:  at port 0x60,0x64 irq 1 on isa0
atkbd0:  irq 1 on atkbdc0
unknown:  can't assign resources
IP packet filtering initialized, divert disabled, rule-based forwarding disabled, 
default to deny, unlimited logging
panic: blockable mtx_lock() of Giant when not legal @ ../../kern/kern_intr.c:503
Debugger("panic")
Stopped at  Debugger+0x44:  pushl   %ebx
db> trace
Debugger(c02aab03) at Debugger+0x44
panic(c02a9a60,c02c70b4,c02a7950,1f7,c21c3700) at panic+0x70
witness_enter(c035c2a0,2,c02a7950,1f7) at witness_enter+0x396
ithread_loop(c21c6880,cef07fa8) at ithread_loop+0x266
fork_exit(c0184bf0,c21c6880,cef07fa8) at fork_exit+0xec
fork_trampoline() at fork_trampoline+0x8
db> show mutex
db> show witness
Sleep mutexes:
0 xl0 -- last acquired @ ../../pci/if_xl.c:1241
0 rman -- last acquired @ ../../kern/subr_rman.c:196
0 rman head -- last acquired @ ../../kern/subr_rman.c:107
0 sf_bufs list lock -- last acquired @ ../../kern/uipc_syscalls.c:1437
0 m_ext counter free list lock -- last acquired @ ../../kern/uipc_mbuf.c:216
0 mcluster free list lock -- last acquired @ ../../kern/uipc_mbuf.c:381
0 vm86pcb lock -- last acquired @ ../../i386/i386/vm86.c:579
0 Giant -- last acquired @ ../../kern/kern_mutex.c:835
1  mbuf free list lock -- last acquired @ ../../netinet/igmp.c:108
1  random reseed -- last acquired @ ../../dev/random/yarrow.c:265
1  fork list -- last acquired @ ../../kern/kern_sx.c:138
1  bpf global lock -- last acquired @ ../../net/bpf.c:1221
1  zone subsystem -- last acquired @ ../../vm/vm_zone.c:176
1  eventhandler -- last acquired @ ../../kern/subr_eventhandler.c:76
2   lockmgr interlock -- last acquired @ ../../kern/kern_lock.c:239
3process lock -- last acquired @ ../../kern/kern_lock.c:260
4 ucred -- last acquired @ ../../kern/kern_prot.c:1162
4 uidinfo hash -- last acquired @ ../../kern/kern_resource.c:745
5  uidinfo struct -- last acquired @ ../../kern/kern_resource.c:781
2   malloc -- last acquired @ ../../kern/kern_malloc.c:157
1  lockmgr -- last acquired @ ../../kern/kern_lock.c:239
1  zone -- last acquired @ ../../vm/vm_zone.c:366
1  proctree -- last acquired @ order list:0
2   allproc -- last acquired @ order list:0
3process lock -- last acquired @ ../../kern/kern_lock.c:260
4 ucred -- last acquired @ ../../kern/kern_prot.c:1162
4 uidinfo hash -- last acquired @ ../../kern/kern_resource.c:745
5  uidinfo struct -- last acquired @ ../../kern/kern_resource.c:781

Spin mutexes:

Mutexes which were never acquired:
arp_inq
ip_inq
lo
ufs ihash
ifsvgt
cd9660_ihash
vnode_free_list
spechash
mntid
mntvnode
mountlist
ed
bpf interface lock
xl
buftime lock
vm object_list

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



panic trying to play Civillization (with trace, etc.)

2001-03-11 Thread Mikhail Teterin

Hi! All of  a sudden I can't play  my game :( The new  kernels all crash
just trying to start the executable...

Here is  the trace with my  attempts to browse through  it. The bzip2-ed
kernel  and vmcore,  as  well  as the  /sys  subtree  are available  for
examination at:
http://aldan.algebra.com:8015/~mi/civctp-crash/

The  panic-triggering (Linux)  binary is  also there  (civctp). I  don't
think  you  can  play  the  game with  it  without  the  data-files  and
libraries, so Loki games should not  object :) Most probably you will be
able to get the  same panic by just trying to  run the executable, which
worked  just fine  with the  Feb 22  current-kernel. I  link all  of the
modules into the kernel.

I can  also give an account  or two (the  machine is on a  static-IP DSL
link) to  those who wish  to take a closer  look, but can  not reproduce
this locally. Thanks!

#0  dumpsys () at ../../kern/kern_shutdown.c:478
#1  0xc01de0d0 in boot (howto=260) at ../../kern/kern_shutdown.c:321
#2  0xc01de4ec in poweroff_wait (junk=0xc0342fcf, howto=-822364608)
at ../../kern/kern_shutdown.c:571
#3  0xc02e8f65 in trap_fatal (frame=0xcf02adc4, eva=0)
at ../../i386/i386/trap.c:987
#4  0xc02e8c99 in trap_pfault (frame=0xcf02adc4, usermode=0, eva=0)
at ../../i386/i386/trap.c:901
#5  0xc02e858f in trap (frame={tf_fs = -1069744104, tf_es = 16, 
  tf_ds = -821952496, tf_edi = -822364608, tf_esi = -1069645600, 
  tf_ebp = -821907952, tf_isp = -821907984, tf_ebx = 0, 
  tf_edx = -822364608, tf_ecx = 86, tf_eax = 1, tf_trapno = 12, 
  tf_err = 0, tf_eip = -1071804515, tf_cs = 8, tf_eflags = 65538, 
  tf_esp = 4, tf_ss = 1}) at ../../i386/i386/trap.c:448
#6  0xc01d8f9d in _mtx_unlock_sleep (m=0xc03e80e0, opts=4, 
file=0xc0324024 "../../kern/kern_shutdown.c", line=258)
at ../../kern/kern_mutex.c:525
#7  0xc01ddde5 in boot (howto=256) at ../../kern/kern_shutdown.c:258
#8  0xc01de4ec in poweroff_wait (junk=0xc0342fcf, howto=-822364608)
at ../../kern/kern_shutdown.c:571
#9  0xc02e8f65 in trap_fatal (frame=0xcf02aef4, eva=0)
at ../../i386/i386/trap.c:987
#10 0xc02e8c99 in trap_pfault (frame=0xcf02aef4, usermode=0, eva=0)
at ../../i386/i386/trap.c:901
#11 0xc02e858f in trap (frame={tf_fs = -1051459560, tf_es = 16, tf_ds = 16, 
  tf_edi = -822364608, tf_esi = -1069645600, tf_ebp = -821907648, 
  tf_isp = -821907680, tf_ebx = 0, tf_edx = 1, tf_ecx = 598, tf_eax = 598, 
  tf_trapno = 12, tf_err = 0, tf_eip = -1071804515, tf_cs = 8, 
  tf_eflags = 65666, tf_esp = -822364608, tf_ss = -1069645600})
at ../../i386/i386/trap.c:448
#12 0xc01d8f9d in _mtx_unlock_sleep (m=0xc03e80e0, opts=0, 
file=0xc034305c "../../i386/i386/trap.c", line=1247)
at ../../kern/kern_mutex.c:525
#13 0xc02e979d in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, 
  tf_edi = 144704672, tf_esi = -1077937872, tf_ebp = -1077937588, 
  tf_isp = -821907500, tf_ebx = 4, tf_edx = 148, tf_ecx = -1077937736, 
  tf_eax = 148, tf_trapno = 12, tf_err = 2, tf_eip = 139025316, 
  tf_cs = 31, tf_eflags = 598, tf_esp = -1077937900, tf_ss = 47})
at ../../i386/i386/trap.c:1247
#14 0xc02d705d in syscall_with_err_pushed ()
#15 0x8461eab in ?? ()
#16 0x83e012f in ?? ()
#17 0x83dfeeb in ?? ()
#18 0x81be0df in ?? ()
#19 0x81aa7c9 in ?? ()
#20 0x804b271 in ?? ()
#21 0x84b2f66 in ?? ()
#22 0x80480de in ?? ()
#23 0x846dc94 in ?? ()
(kgdb)  up 12
#12 0xc01d8f9d in _mtx_unlock_sleep (m=0xc03e80e0, opts=0, 
file=0xc034305c "../../i386/i386/trap.c", line=1247)
at ../../kern/kern_mutex.c:525
525 p1 = TAILQ_FIRST(&m->mtx_blocked);
(kgdb) p m
$1 = (struct mtx *) 0xc03e80e0
(kgdb) p *m
$2 = {mtx_lock = 3472602691, mtx_recurse = 1, mtx_saveintr = 0, mtx_flags = 2, 
  mtx_description = 0xc0341df9 "Giant", mtx_blocked = {tqh_first = 0x0, 
tqh_last = 0xcefbd400}, mtx_contested = {le_next = 0xc03e80e0, 
le_prev = 0xcefbb7e0}, mtx_next = 0xc03dae60, mtx_prev = 0xc03e82a0, 
  mtx_debug = 0x0}
(kgdb) p m->mtx_blocked
$3 = {tqh_first = 0x0, tqh_last = 0xcefbd400}
(kgdb) l 
520
521 mtx_lock_spin(&sched_lock);
522 if ((opts & MTX_QUIET) == 0)
523 CTR1(KTR_LOCK, "_mtx_unlock_sleep: %p contested", m);
524
525 p1 = TAILQ_FIRST(&m->mtx_blocked);
526 MPASS(p->p_magic == P_MAGIC);
527 MPASS(p1->p_magic == P_MAGIC);
528
529 TAILQ_REMOVE(&m->mtx_blocked, p1, p_procq);
(kgdb) up
#13 0xc02e979d in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, 
  tf_edi = 144704672, tf_esi = -1077937872, tf_ebp = -1077937588, 
  tf_isp = -821907500, tf_ebx = 4, tf_edx = 148, tf_ecx = -1077937736, 
  tf_eax = 148, tf_trapno = 12, tf_err = 2, tf_eip = 139025316, 
  tf_cs = 31, tf_eflags = 598, tf_esp = -1077937900, tf_ss = 47})
at ../../i386/i386/trap.c:1247
1247mtx_unlock(&Giant);
(kgdb) l
1242
1243/*
1244 * Release Giant if we had to get it

Re: make installworld 'kinda' broken in perl

2001-03-11 Thread Bruce Evans

On Sun, 11 Mar 2001, Julian Elischer wrote:

> I often do 'make buildworld' on one machine
> and on many other machines I do:
>  mount  -r /usr/src
>  mount -r /usr/obj 
> 
> through nfs so I can do a 'make installworld'
> using the prebuilt system.
> 
> Unfortunatly the perl distribution is trying to write
> back to /usr/obj or /usr/src.
> 
> it is the only place that does this. And it's new becasue 
> I've done this in the past.
> 
> here's the error:
> ===> gnu/usr.bin/perl/library/SDBM_File
> cd sdbm && make all
> rm -rf libsdbm.a<- why does it try to do this?
>   surely it should have been done in the
>   'buildworld' phase. I'm not sure if
>   it's trying to rm in /usr/obj or /usr/src,
>   but either way, it's wrong..
> 
> 
> rm: libsdbm.a: Read-only file system
> *** Error code 1 (continuing)
> `all' not remade because of errors.

This is an old bug:

>From [EMAIL PROTECTED] Mon Nov  6 03:05:35 2000 +1100
Date: Mon, 6 Nov 2000 03:05:31 +1100 (EST)
From: Bruce Evans <[EMAIL PROTECTED]>
X-Sender: [EMAIL PROTECTED]
To: Don Lewis <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED], Steven Farmer <[EMAIL PROTECTED]>, 
[EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: installworld failure - libsdbm.a
In-Reply-To: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O
X-Status: 
X-Keywords:  
X-UID: 1357

On Sun, 5 Nov 2000, Don Lewis wrote:

> On Nov 4, 11:54am, Kent Stewart wrote:
> } Subject: Re: installworld failure - libsdbm.a
> } 
> } 
> } Steven Farmer wrote:
> } > 
> } > After this morning's cvsup and buildworld, installworld failed trying
> } > to build libsdbm.a.  I worked around the problem by adding chmod to
> } > Makefile.inc1 as shown below.  BTW - isn't it kind of wierd for a
> } > library to be _built_ at installworld time?
> } 
> } Yes, it is. It is supposed to be build in buildworld where is also
> } chmod'ed appropriately. Something triggers the build during
> } installworld, which is a place they don't want to add chmod to. I have
> } had it hit me once.
> 
> I had the same thing happen to me yesterday abuse six hours into
> a -current "make release".  The problem didn't recur when I reran
> "make release".  One possible quirk is that I am mounting the scratch
> area from a 4.1-stable NFS server.  Notice that only the .a file is
> getting built, and not the .o files.  I suspect that the file
> timestamps are getting messed up, causing make to rebuild the .a
> file.

That is another bug.  The main bug is that the perl install looks at
timestamps (install targets shouldn't depend on anything).

> } > ===> gnu/usr.bin/perl/library/SDBM_File
> } > cd /usr/obj/usr/src/gnu/usr.bin/perl/library/SDBM_File/ext/SDBM_File ; make -B 
>install  INSTALLPRIVLIB=/usr/libdata/perl/5.00503  
>INSTALLARCHLIB=/usr/libdata/perl/5.00503/mach

This is from gnu/usr.bin/perl/library/SDBM_File/../Makefile.inc.  No problems
yet.

> } > cd sdbm && make all

This is from the automatically generated Makefile in the obj directory.  This
Makefile is nothing like a BSD makefile and has bugs like:

install :: all pure_install doc_install

This causes things to be built at install time if they are out of date.

> } > rm -rf libsdbm.a
> } > ar cr libsdbm.a sdbm.o  pair.o  hash.o && : libsdbm.a
> } > chmod 755 libsdbm.a
> } > chmod:No such file or directory
> } > *** Error code 1

Bruce


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



growfs

2001-03-11 Thread Andrea Campi

I was about to fill in a doc PR on this but then I thought I'm better off
checking other people experiences...

I just used growfs on my / filesystem, after shrinking the swap partition
which just happened to be after it. I had to do nothing magic beside dropping
to single user so as to have a ro /. This is in contrast to what the man page
says:

 system on the specified special file.  Currently growfs can only grow un-
 mounted file systems.  Do not try growing a mounted file system, your
 system may panic and you will not be able to use the file system any
 longer.  Most of the options you have used with newfs(8) once can not be
 changed.  In fact you can only increase the size of the file system.  Use

Is this just extra paranoia or was I very lucky? Do we need to fix the doc?

Bye,
Andrea

-- 
Yes, I've heard of "decaf." What's your point?

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: how's vinum these days with DEVFS?

2001-03-11 Thread Alfred Perlstein

* Niels Chr. Bank-Pedersen <[EMAIL PROTECTED]> [010311 02:29] wrote:
> 
> I'll sneak in my experience with DEVFS+vinum here as well:
> 
>   vinum: loaded
>   vinum: reading configuration from /dev/da3s1f
>   vinum: updating configuration from /dev/da1s1e
>   vinum: updating configuration from /dev/da2s1e
>   vinum: updating configuration from /dev/da0s1e
>   swapon: adding /dev/da1s1b as swap device
>   swapon: adding /dev/da2s1b as swap device
>   Automatic boot in progress...
>   /dev/da0s1a: FILESYSTEM CLEAN; SKIPPING CHECKS
>   /dev/da0s1a: clean, 406977 free (1049 frags, 50741 blocks, 0.2% fragmentation)
>   Can't stat /dev/vinum/raid01: No such file or directory
>   Can't stat /dev/vinum/raid01: No such file or directory
>   /dev/vinum/raid01: CAN'T CHECK FILE SYSTEM.
>   /dev/vinum/raid01: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
> 
> This was with a -current from around March 1. (don't think
> anything has changed since).  Booting a non-DEVFS kernel
> passes the fs-check and works as expected.

Vinum+DEVFS doesn't make the million symlinks that non-devfs
vinum does.

Try using /dev/vinum/vol/raid01 instead of /dev/vinum/raid01

(notice you need the '/vol/' path component)

-Alfred

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



make installworld 'kinda' broken in perl

2001-03-11 Thread Julian Elischer

I often do 'make buildworld' on one machine
and on many other machines I do:
 mount  -r /usr/src
 mount -r /usr/obj 

through nfs so I can do a 'make installworld'
using the prebuilt system.

Unfortunatly the perl distribution is trying to write
back to /usr/obj or /usr/src.

it is the only place that does this. And it's new becasue 
I've done this in the past.

here's the error:
===> gnu/usr.bin/perl/library/SDBM_File
cd sdbm && make all
rm -rf libsdbm.a<- why does it try to do this?
  surely it should have been done in the
  'buildworld' phase. I'm not sure if
  it's trying to rm in /usr/obj or /usr/src,
  but either way, it's wrong..


rm: libsdbm.a: Read-only file system
*** Error code 1 (continuing)
`all' not remade because of errors.
rm -rf libsdbm.a
rm: libsdbm.a: Read-only file system
*** Error code 1 (continuing)
`all' not remade because of errors.
Installing /usr/libdata/perl/5.6.0/mach/SDBM_File.pm
Installing /usr/libdata/perl/5.6.0/mach/auto/sdbm/extralibs.ld
Installing /usr/libdata/perl/5.6.0/mach/auto/SDBM_File/SDBM_File.so
Installing /usr/libdata/perl/5.6.0/mach/auto/SDBM_File/SDBM_File.bs
Writing /usr/libdata/perl/5.6.0/mach/auto/SDBM_File/.packlist
Appending installation info to /usr/libdata/perl/5.6.0/mach/perllocal.pod
===> gnu/usr.bin/perl/library/Socket
 
-- 
  __--_|\  Julian Elischer
 /   \ [EMAIL PROTECTED]
(   OZ) World tour 2000-2001
---> X_.---._/  
v

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: how's vinum these days with DEVFS?

2001-03-11 Thread Niels Chr. Bank-Pedersen

On Sun, Mar 11, 2001 at 12:03:34AM -0800, Matthew Jacob wrote:
> 
> 
> On Sun, 11 Mar 2001, Greg Lehey wrote:
> 
> > On Saturday, 10 March 2001 at 17:12:42 -0800, Matt Jacob wrote:
> > > (top of tree within the last day or so):
> > >
> > > Things  seem *almost* okay, but:
> > >
> > > nellie.feral.com > root vinum
> > > vinum -> stripe -v /dev/da3a /dev/da4a /dev/da5a /dev/da6a /dev/da7a /dev/da8a
> > > /dev/da9a /dev/da10a /dev/da11a /dev/da12a
> > > drive vinumdrive0 device /dev/da3a
> > > 
> > > Can't get config for plex 0: Invalid argument
> > >
> > > and at the console:
> > >
> > > WARNING: Driver mistake: repeat make_dev("vinum/control")
> > 
> > Hmm.
> > 
> > > Mar 10 17:09:57 nellie /boot/kernel/kernel: vinumioctl: invalid ioctl from 
>process 682 (vinum): c1384644
> > 
> > This looks like a mismatch between the plex size in the userland and
> > kernel code.  Did you rebuild vinum(8)?
> 
> Complete fresh build, top of tree... I'll try again...

I'll sneak in my experience with DEVFS+vinum here as well:

  vinum: loaded
  vinum: reading configuration from /dev/da3s1f
  vinum: updating configuration from /dev/da1s1e
  vinum: updating configuration from /dev/da2s1e
  vinum: updating configuration from /dev/da0s1e
  swapon: adding /dev/da1s1b as swap device
  swapon: adding /dev/da2s1b as swap device
  Automatic boot in progress...
  /dev/da0s1a: FILESYSTEM CLEAN; SKIPPING CHECKS
  /dev/da0s1a: clean, 406977 free (1049 frags, 50741 blocks, 0.2% fragmentation)
  Can't stat /dev/vinum/raid01: No such file or directory
  Can't stat /dev/vinum/raid01: No such file or directory
  /dev/vinum/raid01: CAN'T CHECK FILE SYSTEM.
  /dev/vinum/raid01: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.

This was with a -current from around March 1. (don't think
anything has changed since).  Booting a non-DEVFS kernel
passes the fs-check and works as expected.


/Niels Chr.

-- 
 Niels Christian Bank-Pedersen, NCB1-RIPE.
 Network Manager, Tele Danmark NET, IP-section.

 "Hey, are any of you guys out there actually *using* RFC 2549?"

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Entropy harvesting? Grim reaper is more like it...

2001-03-11 Thread Doug Rabson

On Sat, 10 Mar 2001, David O'Brien wrote:

> On Fri, Mar 09, 2001 at 01:39:58PM -0800, Matthew Jacob wrote:
> > > Erm, just so you know.  The 4100 here at WC doesn't even make it past
> > > the SCSI probe due to interrupt issues.
> >
> > Hmm. Well, it *was* working a couple of days ago :-)
>
> Uh, actually _your_ 4100 is the only I've ever known to work on
> post-SMPng.  The WC 4100 has *never* worked on post SMPng.  I don't
> believe I've heard that DFR's runs SMPng either.
>
> I guess I should get a `dd' of your system disk, or get you a console on
> the WC box.

My 4100 was working after the last set of mcpcia fixes. I haven't updated
it for about a week so it may be broken again I guess.

-- 
Doug Rabson Mail:  [EMAIL PROTECTED]
Phone: +44 20 8348 6160



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



unsubscribe daniel@everad.com

2001-03-11 Thread Daniel Mester





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message