Re: calcru and upages

1999-05-23 Thread Poul-Henning Kamp
In message 199905230245.maa13...@godzilla.zeta.org.au, Bruce Evans writes:
calcru() access p_stats, which is in upages. Therefore, as I understand, 
it should not be called on a swapped out process. Neither calcru() nor 

Does anyone object to moving everything except the stack from the upages
to the proc table?

not me.

--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org   Real hackers run -current on their laptop.
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: MFS still hosed

1999-05-23 Thread Poul-Henning Kamp

Can somebody please try if this fixes MFS ?

Poul-Henning

Index: ufs/mfs/mfs_vfsops.c
===
RCS file: /home/ncvs/src/sys/ufs/mfs/mfs_vfsops.c,v
retrieving revision 1.63
diff -u -r1.63 mfs_vfsops.c
--- mfs_vfsops.c1999/05/14 20:40:23 1.63
+++ mfs_vfsops.c1999/05/23 09:22:20
@@ -62,6 +62,10 @@
 
 MALLOC_DEFINE(M_MFSNODE, MFS node, MFS vnode private part);
 
+/* XXX: this is bogus, should be (NUMCDEV-1) or use dynamic allocation */
+#define CDEV_MAJOR 255
+#define BDEV_MAJOR 255
+
 #ifdef MFS_ROOT
 static caddr_t mfs_rootbase;   /* address of mini-root in kernel virtual 
memory */
 static u_long  mfs_rootsize;   /* size of mini-root in bytes */
@@ -462,8 +466,6 @@
 mfs_init(vfsp)
struct vfsconf *vfsp;
 {
-   dev_t dev = NODEV;
-   cdevsw_add(dev, mfs_cdevsw, NULL);
-   cdevsw_add_generic(255, major(dev), mfs_cdevsw);
+   cdevsw_add_generic(BDEV_MAJOR, CDEV_MAJOR, mfs_cdevsw);
return (0);
 }
--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org   Real hackers run -current on their laptop.
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: libg2c.a in -current

1999-05-23 Thread David O'Brien
 Anyone know why libf2c* was renamed to libg2c* in egcs?

Cygnus has hacked (possibly considerably) Bell-Labs' libf2c.  To the
point a program written to the EGCS's FORTRAN lib wouldn't be linkable
with libf2c.  Thus they felt the need for a unique name.

 Does egcs have a replacement for f2c?  

Yep, g77.  :-)

f2c was written to compile FORTRAN programs.  It was quicker for the f2c
authors to write f2c to output C code than ASM, *AND* it meant they
didn't have to deal with code generation, nor optimization.

However, there are many optimizations the code generator can do if it
knows the input language was FORTRAN.  Thus a native FORTRAN compiler
(ie, g77) is preferred.  f2c was never meant to be a FORTRAN to C
translator in which you then maintained the resulting C.


 Would anyone object if I installed the header file, g2c.h, along with
 the library?

Since you seem to believe it is useful, I'll install it.
 
-- 
-- David(obr...@nuxi.com  -or-  obr...@freebsd.org)


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: libg2c.a in -current

1999-05-23 Thread David O'Brien
 Index: Makefile
 ===
 RCS file: /home/ncvs/src/gnu/lib/libg2c/Makefile,v

 +beforeinstall:
 + ${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 ${.CURDIR}/g2c.h \
 + ${DESTDIR}/usr/include
 +


$ brucify Makefile
Line 123: Continuation of rule should be indented 4 spaces, not 1 tab
  character.

-- 
-- David(obr...@nuxi.com  -or-  obr...@freebsd.org)


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



UFS parameter survey: HELP WANTED!

1999-05-23 Thread Poul-Henning Kamp
---BeginMessage---

I recently made a 15GB filesystem and ended up with almost 500
cylinder groups.  That is unlikely to be optimal.  I talked to Kirk
about the right parameters for UFS on modern disks some years back,
and he said that no more than maybe a hundred cylinder groups made
any sense.

I think the fact that disks have gotten 25 times larger since the
newfs paramters were last tweaked means that it is time to do so
again.  Unfortunately determining the parameters are not simple,
so I would like to solicit help from as many as possible in
determining if we should retune the newfs defaults.

What I'm looking for is hard and soft data on the difference it
makes for various sets of parameters, for various workloads and
programs.  So if you have time and facilities, lend me a hand.

Basically, we can only sensibly compare data from the same hardware
with the same workload, otherwise there are too many things to
compare.  Not all things can be measured precisely, but try to
provide as much data as you can, and as good data as you can,
ie: don't change controllers move partitions change BIOS settings
without noting that you did so.

The newfs parameters I would like to map out are:

-a -b -c -e -f -i -m -t -u

I'm generally interested in all impacts of this, but in particular
if you can measure one or more of these specific parameters:

read performance
write performance
create performance
fsck time
space wastage
other

I have no particular wishes for what program/application is used
to excercise the system, but I would always prefer real-world over
synthetic benchmarks.  If somebody could measure news-server and
web-server performance for instance it would be great.

If anybody feels like making a structured benchmark script which
just takes a device name as arg and runs some standardized tests
that would be great too!

Please report all results to fs-d...@phk.freebsd.dk using this
form.  Put the information instead of the ___, but leave the line
number intact please.  You don't need to return the lines starting
with #

I will post news and updates about this project on:

http://phk.freebsd.dk/ufs

If there is sufficient interest we will make a mailing list too.

Thank you for your participation!

Poul-Henning

*BEGIN UFSTUNE FORM*

# Your email address.  This will be used only to catalogue and
# request further details from you.  It will not be published
# or distributed.
# Example:
#   1 p...@freebsd.org
1 ___

# Identity of the system you used.  This is just to keep all measurements
# straight.  It is used with your email as a unique index.  This
# should identify one particular combination of hardware, excluding
# the disk you had the filesystems on.  If you have the disk on
# different controllers in the same system, that will count as two
# systems.  Use names/numbers/whatever helps you keep track of things.
# Please use the same thing for all measurements made on the same
# system.
# Example:
#   2 rover using NCR controller
2 ___

# Identity of the disk/device you had the filesystem on, please
# cutpaste the ... piece from /var/run/dmesg.boot:
# Example:
#   3 Quantum XP34300W 81HB
3 ___

# Describe the nature of the test in one-line form.
# Example:
#   4 Time to fsck filesystem with all four 3.2 CD's loaded
4 ___

# Describe the nature and conditions of the test in 
# sufficient detail that somebody else can repeat it.
# Example:
#   5 Filesystem is newfs'ed and mounted.  The four CDs from the FreeBSD
#   5 3.2 release were copied in using find . -print | cpio -dump XXX
#   5 where XXX is mountpoint/cd[1234].  Filesystem unmounted and run
#   5 /usr/bin/time -l fsck /dev/rsd0c
5 ___

# You must repeat the rest of the form for each experiment.

# document the newfs commandline used.  Include a -s option here.
# Example:
#   6 newfs -f 2048 -s 3072
6 ___

# document any mount options, kernel features or softupdates.
# Example:
#   7 softupdates
7 ___

# note any other detailes pertaining to this experiment (multiline)
# Example:
#   8 BIOS set to 5 MHz/narrow
8 ___

# document the result of the experiment, for instance the output from
# time(1) or similar (multiline)
# Example:
#   9 2.91 real 0.03 user 0.05 sys
9 ___

*END UFSTUNE FORM*

--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org   Real hackers run -current on their laptop.
FreeBSD -- It will take a long time before progress goes too far!
---End Message---


Re: MFS still hosed

1999-05-23 Thread Sheldon Hearn


On Sun, 23 May 1999 11:32:27 +0200, Poul-Henning Kamp wrote:

 Can somebody please try if this fixes MFS ?

Do you want your patch applied alongside Luoqi Chen's patch to
kern_conf.c from last week? I've been able to mount_mfs without problems
since then.

Ciao,
Sheldon/


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: calcru and upages

1999-05-23 Thread Dmitrij Tejblum
Peter Wemm wrote:
 Bruce Evans wrote:
  calcru() access p_stats, which is in upages. Therefore, as I understand, 
  it should not be called on a swapped out process. Neither calcru() nor 
  
  Does anyone object to moving everything except the stack from the upages
  to the proc table?

This would certainly make my sleep better. However, IMO the real 
problem here is the hackish way the VM maintain upages. It is not
so hard to make such incorrect accesses to u-area detected better.
I used this:

--- vm_glue.c   Thu May 20 00:24:18 1999
+++ vm_glue.c   Thu May 20 00:27:33 1999
@@ -317,6 +317,9 @@ faultin(p)
setrunqueue(p);
 
p-p_flag |= P_INMEM;
+   p-p_stats = p-p_addr-u_stats;
+   if (p-p_sigacts == NULL)
+   p-p_sigacts = p-p_addr-u_sigacts;
 
/* undo the effect of setting SLOCK above */
--p-p_lock;
@@ -516,6 +519,9 @@ swapout(p)
(void) splhigh();
p-p_flag = ~P_INMEM;
p-p_flag |= P_SWAPPING;
+   p-p_stats = NULL;
+   if (p-p_sigacts == p-p_addr-u_sigacts)
+   p-p_sigacts = NULL;
if (p-p_stat == SRUN)
remrq(p);
(void) spl0();


Probably better idea would be pass MAP_NOFAULT in a non-currently-existent 
argument to kmem_alloc_pageable() in pmap_new_proc().

 Well, we have three things that are about the same size:
 struct  pcb u_pcb;240 bytes
 struct  sigacts u_sigacts;292 bytes
 struct  pstats u_stats;   248 bytes
 
 On the other hand:  sizeof (struct proc) = 328 bytes.
 
 the pcb contains a heap of space for the FP state.  It accounts for 176 of
 the 240 bytes, leaving 64-odd bytes left for the pcb proper.  The ldt
 pointers need to move to proc scope for rfork()/clone(), and gc'ing a few
 things that can get it as low as 40 - 48 bytes.  pcb_savefpu has padding in
 case a FPU emulator is used and is actually smaller than 176 bytes, and
 could be changed depending on whether it's a real or emulated fpu.

I guess, this is bit different on alpha ;-).

 
 IMHO, I'd move them to reference counted malloc'ed structs since sigacts
 needs to be shared for clone/rforked processes.

I think sigacts is already sometimes shared, and not stored in u-area 
in these cases.

 I think there is also
 benefit to having the sigacts at least malloced, one day we should be able
 to extend the signals beyond the existing 32 set, at least for the 32
 extra RT signals.

Isn't this an argument for keep them in upages? When the struct is 
larger, you want to swap it out stronger? 

 I personally would love to see this come out of the upages, it makes
 tracking through a stack overflow even harder.  We could put an unmapped
 red-line page below the bottom stack page to ensure we get a double fault
 on an overflow instead of mystery corruptions etc.

Why not move 'struct user' on top of the upages, above the kernel stack?

Sayed all that, I don't actually suggest to keep struct user. I almost 
hate it.

Dima




To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: MFS still hosed

1999-05-23 Thread Poul-Henning Kamp
In message 4478.927463...@axl.noc.iafrica.com, Sheldon Hearn writes:


On Sun, 23 May 1999 11:32:27 +0200, Poul-Henning Kamp wrote:

 Can somebody please try if this fixes MFS ?

Do you want your patch applied alongside Luoqi Chen's patch to
kern_conf.c from last week? I've been able to mount_mfs without problems
since then.

Yes.  The problem here is to get MFS-rootfs to work.

--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org   Real hackers run -current on their laptop.
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



MAKEDEV problems

1999-05-23 Thread Harry Starr
The -current MAKEDEV has a problem.

The recent addition of the i4btel?? stuff has broken sh MAKEDEV all

The section of the sh case for i4teld*) should be BEFORE the case for
i4tel*). (match the longest prefix first!)

This problem is causing the generation of i4teld? to FAIL! and thus the
'all'

Harry.






To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



disk slices and MAKEDEV confusion

1999-05-23 Thread Harry Starr
I am confused!

The /boot/loader is announcing that it wants the root device to be
da0s1a.

It appears that the normal fstab entries want sliced versions as well,
eg.
# DeviceMountpoint  FStype  Options Dump
Pass#
/dev/da0s1b noneswapsw  0   0
/dev/da0s1a /   ufs rw  1   1

SO! Why does sh MAKEDEV all NOT make the partition entries for the
slice(s) ???

ie, sh MAKEDEV all only makes the compatability slice entries -- da0s1,
da0s2 etc.

It requires a sh MAKEDEV da0s1a to get the slice/partition entries.

I checked on the standard entries in disc2 of the release cds
(/R/cdrom/disc2/dev) and the partition entries are not there either for the
da and wd entries.

Have I totally lost the plot on device naming.???

Harry.




To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: libg2c.a in -current

1999-05-23 Thread Steve Price
On Sun, 23 May 1999, David O'Brien wrote:

#  Index: Makefile
#  ===
#  RCS file: /home/ncvs/src/gnu/lib/libg2c/Makefile,v
# 
#  +beforeinstall:
#  +   ${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 ${.CURDIR}/g2c.h \
#  +   ${DESTDIR}/usr/include
#  +
# 
# 
# $ brucify Makefile
# Line 123: Continuation of rule should be indented 4 spaces, not 1 tab
#   character.

I pilfered the format from src/lib/libalias/Makefile, so it fails
brucify(1) there as well. :)

-steve



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: libg2c.a in -current

1999-05-23 Thread Bruce Evans
# $ brucify Makefile
# Line 123: Continuation of rule should be indented 4 spaces, not 1 tab
#   character.

I pilfered the format from src/lib/libalias/Makefile, so it fails
brucify(1) there as well. :)

I don't know where all the bad examples in src/lib/*/Makefile came from.
In Lite2 there are only 3 examples of beforeinstall targets, all of which
have rules with continuation lines, all of which are indented 4 spaces.

Bruce


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: libg2c.a in -current

1999-05-23 Thread Brian Somers
 # $ brucify Makefile
 # Line 123: Continuation of rule should be indented 4 spaces, not 1 tab
 #   character.
 
 I pilfered the format from src/lib/libalias/Makefile, so it fails
 brucify(1) there as well. :)
 
 I don't know where all the bad examples in src/lib/*/Makefile came from.
 In Lite2 there are only 3 examples of beforeinstall targets, all of which
 have rules with continuation lines, all of which are indented 4 spaces.

I can't pass the blame for libalias/Makefile :-}

 Bruce

-- 
Brian br...@awfulhak.orgbr...@freebsd.org
  http://www.Awfulhak.org   br...@openbsd.org
Don't _EVER_ lose your sense of humour !  br...@uk.freebsd.org




To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



ethernet card problems

1999-05-23 Thread Aleksander Rozman - Andy
Hi !

I am new to to list and to BSD-current. I cvsup'ed whole thing and
installed it over weekend, but I encountered problem. I have one machine at
home with two ethernet cards of same type (NE2000 compatible). One is used
for connection to cable modem and other to my private network. Problem is
that in kernel they aren't both added. I added them in config file (ed0 and
ed1), but on startup the second card isn't started. On previous kernel
(v3.1) everything worked ok, but now it doesn't. Is this change in kernel
or did I make mistake in my config file. Please help me, cause running 3.1
kernel on 4.0 all other files, doesn't work very good.

Andy

**
*  Aleksander Rozman - Andy  * Member of:  E2:EA, E2F, SAABer, Trekkie,  *
* a...@mail.kks.net  * X-Phile, Heller's angel, True's screamer, *
*a...@atechnet.ml.org* True's Trooper, Questie, Legacy, PO5, *
* Maribor, Slovenia (Europe) * Profiler, Buffy (Slayerete), Pretender*
* ICQ-UIC: 4911125   *
* PGP key available  *http://www.atechnet.ml.org/~andy/  *
**



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: calcru and upages

1999-05-23 Thread Peter Wemm
Poul-Henning Kamp wrote:
 In message 199905230245.maa13...@godzilla.zeta.org.au, Bruce Evans writes:
 calcru() access p_stats, which is in upages. Therefore, as I understand, 
 it should not be called on a swapped out process. Neither calcru() nor 
 
 Does anyone object to moving everything except the stack from the upages
 to the proc table?
 
 not me.

I'd also like to implement a proper clone(2) ala Linux.  We have most of
the infrastructure in place already, using that and comparing with NetBSD's
take on the subject should be fairly useful in the end.  The main
difference between clone(2) and rfork(2) is that clone() takes a stack
argument and is more specific about certain sharing semantics. At present
these are emulated via flags added into rfork's visibility, I think it
would be cleaner to just use a proper syscall interface onto fork1() rather
than bend rfork(2) even more.

Cheers,
-Peter




To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



ed0 not recognized (even tried it as ed1)

1999-05-23 Thread Bill Pechter
Following my latest rebuild (make world on Friday, make of kernel
on Friday) -- I can no longer find my ed0 (WD 8216) network card.

dmesg.yesterday:ed0 at port 0x280-0x29f iomem 0xd8000-0xdbfff irq 10 on isa0
dmesg.yesterday:ed0: address 00:00:c0:bb:a8:b2, type SMC8216/SMC8216C (16 bit) 
dmesg.yesterday:ed0: interrupting at irq 10

I see no probe at all for the device.

Any suggestions?

The ed0 line is the same as it was before:
device ed0 at isa? port 0x260 irq 9 iomem 0xd8000

I did fix the atkbdc0 lines... after the keyboard didn't respond.

controller  atkbdc0 at isa? port IO_KBD
device  atkbd0  at atkbdc? irq 1

Have I missed something in the last few days?

Bill
---
  bpech...@shell.monmouth.com|pech...@pechter.dyndns.org
  Three things never anger: First, the one who runs your DEC,
  The one who does Field Service and the one who signs your check.


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



panic() in devfs_makelink() with recent -current

1999-05-23 Thread Louis A. Mamakos

I recently tried building a new kernel after quite a bit, and I get a
panic while the system's booting in devfs_makelink, apparently being
called from fd_attach().

Is DEVFS and the new-bus code hopelessly incompatable, and should I just
unconfigure DEVFS?  Or is this something that I can dig into a bit more
and find a relatively simple fix?  

I copied down some of what the trace command spewed in ddb, and it appears
that the first argument to devfs_makelink is 0, which is sorta weird..

louie



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: ed0 not recognized (even tried it as ed1)

1999-05-23 Thread Warner Losh
In message 199905240133.vaa01...@i4got.pechter.dyndns.org Bill
Pechter writes:
: dmesg.yesterday:ed0 at port 0x280-0x29f iomem 0xd8000-0xdbfff irq 10 on isa0
: The ed0 line is the same as it was before:
: device ed0 at isa? port 0x260 irq 9 iomem 0xd8000

I find that extremely hard to believe...  Different IRQ and different
port is what it appears to me...  Maybe that's why things didn't work.

: I did fix the atkbdc0 lines... after the keyboard didn't respond.
: controlleratkbdc0 at isa? port IO_KBD
: deviceatkbd0  at atkbdc? irq 1

# atkbdc0 controlls both the keyboard and the PS/2 mouse
controller  atkbdc0 at isa? port IO_KBD
device  atkbd0  at atkbdc? irq 1
device  psm0at atkbdc? irq 12
device  vga0at isa? port ? conflicts

is what I have in my config file.  Maybe you didn't run config(8)?
You can tell if you didn't because there is a copy of the config file
in compile/BLAH/config.c.  That was my problem with the keyboard (I
had changed it in my config file, but had neglected to run config on
the correct config file, hence I got all confused for a short period
of time).

Warner


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: panic() in devfs_makelink() with recent -current

1999-05-23 Thread Natty Rebel
Quoting Louis A. Mamakos (lo...@transsys.com):
 
 I recently tried building a new kernel after quite a bit, and I get a
 panic while the system's booting in devfs_makelink, apparently being
 called from fd_attach().
 
 Is DEVFS and the new-bus code hopelessly incompatable, and should I just
 unconfigure DEVFS?  Or is this something that I can dig into a bit more
 and find a relatively simple fix?  
 
 I copied down some of what the trace command spewed in ddb, and it appears
 that the first argument to devfs_makelink is 0, which is sorta weird..
Can I say me too here.  My panics were happening in the swapper process.
After reading your message I commented out the DEVFS option and voila!
the new kernel booted without a hitch.  I'm up for doing some kernel 
digging ...

 
 louie
 
 
 
 To Unsubscribe: send mail to majord...@freebsd.org
 with unsubscribe freebsd-current in the body of the message

#;^)
-- 
natty rebel
harder than the rest ...


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



isa_compat error diagnostic

1999-05-23 Thread Andrey A. Chernov
I got this with recent -current. Something need to be fixed since ed0 line
is the same as in LINT (iomem 0xd8000) excepting irq is different.

...
ed0 at port 0x300-0x31f iomem 0 irq 10 on isa0
isa_compat: didn't get memory for ed
ed0: address 00:c0:6c:62:47:20, type NE2000 (16 bit) 
...

-- 
Andrey A. Chernov
http://nagual.pp.ru/~ache/
MTH/SH/HE S-- W-- N+ PEC+ D A a++ C G+ QH+(++) 666+++ Y


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message