Re: some guidance on forked cvsup please

[Matthew Dillon]

:Now we've gone and got forked, can someone please give us examples of cvsup 
:files for those that want to follow 4-current and those that want to follow 
:3-stable.
:
:Thanks!

It's real simple.  The -stable is the 3.x branch.  This is the branch
that Jordan just created tonight.  So, for example, if you do a 
'cvs log kern/vfs_bio.c' you will see this:

...
head: 1.193
...
RELENG_3: 1.193.0.2
RELENG_3_BP: 1.193

What this means is that the HEAD of the CVS tree is 1.193, and 
RELENG_3 ( the new -stable ) has been forked off as 1.193.0.2.

If your files are currently checked out and have the HEAD branch's
revision, then anything you checkin will be checked in under
-current ( the -4.x tree ).

If your files are currently checked out and have RELENG_3's branch
revision, then anything you check in will be checked in under
-stable ( the -3.x tree ).

If you haven't messed with your CVS tree and it was previously
-current ( 3.x ), it is still -current, but is now 4.x.

-Matt
Matthew Dillon 



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

Re: panic: vinvalbuf: dirty bufs (during reboot, several times)

[Matthew Dillon]

:
:Ah, excellent.  If my tests of Luoqi's fix work, I'll commit it as
:part of my big VM commit to -4.x, and also commit this and a few 
:other simple VM bug fixes to -3.x.

Oops, there is still something broken.   I think getblk() needs to be
reorganized completely, there are still cases where B_CACHE gets cleared
and B_DELWRI can leak through without getting comitted.

-Matt
Matthew Dillon 


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

some guidance on forked cvsup please

[Gregory Bond]

Now we've gone and got forked, can someone please give us examples of cvsup 
files for those that want to follow 4-current and those that want to follow 
3-stable.

Thanks!



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

Re: panic: vinvalbuf: dirty bufs (during reboot, several times)

[Matthew Dillon]

:>...
:> having to check for B_DELWRI in bread(), breadn(), and nfs_bioread()
:> by forcing getblk() to handle the B_DELWRI condition.
:>
:> Cool.  I'll replace my nfs_bioread() patch with this one and test it
:> before committing all this stuff to the -4.x branch ( which I will also
:> do sometime tonight ).
:>
:> I am also CCing this to current so Greg and Andreas are kept abrest
:> of events.  I think this will fix *both* of their reported panics.
:
:Not mine :-)  Mine was a bug in vinum which I had already fixed; I was
:just concerned about whether it had shown its nose again.
:
:Greg

Ah, excellent.  If my tests of Luoqi's fix work, I'll commit it as
part of my big VM commit to -4.x, and also commit this and a few 
other simple VM bug fixes to -3.x.

-Matt

Matthew Dillon 



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

Re: Booting -current with new loader

[Mike Smith]

> > > I'm not sure about anybody else here, but to my mind a "Winblows on C:
> > > drive and let's try out FreeBSD on the second disk" configuration should
> > > really be supported seamlessly. 
> > 
> > You're more than welcome to propose a technical solution that solves 
> > the problem.
> 
> OK, the technical solution that I propose is an alternative (optional
> because I want to retain the current semantics) config semantics. 
> 
> controller  wdc0at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff
> controller  wdc1at isa? port "IO_WD2" bio irq 15 flags 0xa0ffa0ff
> disk  wd? at wdc?
> 
> This would act identical to the way the SCSI system works by assigning
> names to disks as they get probed. It would also have the advantage of
> assigning disk names in the same order as the BIOS (and thereby the boot
> loader), hence there would be a 1 to 1 mapping between what the boot
> loader uses and what the FreeBSD kernel detects. 
> 
> I believe the current problem stems from the BIOS (and thereby the boot
> loader) and the FreeBSD kernel assigning names using a different algorithm
> and then getting out of step when the kernel skips a name.

You're spot on the money here.  If you have any good ideas about 
guaranteeing the probe order (and there are some other issues here, 
like what about systems where the BIOS doesn't know about the IDE 
disks?) matches up, I'm all ears.  Later versions of the EDD spec offer 
a technique for geting a device path for a given ID, but support for 
that seems to be *very* flaky.

> If anybody knows how to do this quickly then I am happy to help test it. 

Right now I'm looking at stamping the disklabel which contains the 
designated root filesystem and passing the stamp into the kernel, which 
will then go look for it.  There are still gremlins with this approach, 
but I can't think of anything better. 8(

-- 
\\  Sometimes you're ahead,   \\  Mike Smith
\\  sometimes you're behind.  \\  m...@smith.net.au
\\  The race is long, and in the  \\  msm...@freebsd.org
\\  end it's only with yourself.  \\  msm...@cdrom.com



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

Re: panic: vinvalbuf: dirty bufs (during reboot, several times)

[Greg Lehey]

On Wednesday, 20 January 1999 at 23:00:34 -0800, Matthew Dillon wrote:
>> Sorry, Matt, the patch in my previous email was fatally flawed. Try this one
>> below. The two printf() messages don't necessarily come out in pairs and
>> it's not just NFS bufs' B_CACHE bits are cleared, so my comment about
>> vm_page_is_valid() check in my previous message was wrong and the check is
>> needed here.
>>
>> -lq
>
> Ok, I understand what you've done... you are effectively bypassing
> having to check for B_DELWRI in bread(), breadn(), and nfs_bioread()
> by forcing getblk() to handle the B_DELWRI condition.
>
> Cool.  I'll replace my nfs_bioread() patch with this one and test it
> before committing all this stuff to the -4.x branch ( which I will also
> do sometime tonight ).
>
> I am also CCing this to current so Greg and Andreas are kept abrest
> of events.  I think this will fix *both* of their reported panics.

Not mine :-)  Mine was a bug in vinum which I had already fixed; I was
just concerned about whether it had shown its nose again.

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

Re: panic: vinvalbuf: dirty bufs (during reboot, several times)

[Matthew Dillon]

:Sorry, Matt, the patch in my previous email was fatally flawed. Try this one
:below. The two printf() messages don't necessarily come out in pairs and
:it's not just NFS bufs' B_CACHE bits are cleared, so my comment about
:vm_page_is_valid() check in my previous message was wrong and the check is
:needed here.
:
:-lq

Ok, I understand what you've done... you are effectively bypassing
having to check for B_DELWRI in bread(), breadn(), and nfs_bioread()
by forcing getblk() to handle the B_DELWRI condition.

Cool.  I'll replace my nfs_bioread() patch with this one and test it
before committing all this stuff to the -4.x branch ( which I will also
do sometime tonight ).

I am also CCing this to current so Greg and Andreas are kept abrest
of events.  I think this will fix *both* of their reported panics.

-Matt

Matthew Dillon 


:Index: vfs_bio.c
:===
:RCS file: /home/ncvs/src/sys/kern/vfs_bio.c,v
:retrieving revision 1.193
:diff -u -r1.193 vfs_bio.c
:--- vfs_bio.c  1999/01/19 08:00:51 1.193
:+++ vfs_bio.c  1999/01/21 05:26:10
:@@ -1437,6 +1437,11 @@
: 
:   if (bp->b_bcount != size) {
:   if ((bp->b_flags & B_VMIO) && (size <= bp->b_kvasize)) {
:+printf("getblk: extending buf %ld->%d\n", bp->b_bcount, size);
:+  if (bp->b_flags & B_DELWRI) {
:+  VOP_BWRITE(bp);
:+  goto loop;
:+  }
:   allocbuf(bp, size);
:   } else {
:   if (bp->b_flags & B_DELWRI) {
:@@ -1471,6 +1476,8 @@
:   resid = (checksize > (PAGE_SIZE - poffset)) ?
:   (PAGE_SIZE - poffset) : checksize;
:   if (!vm_page_is_valid(bp->b_pages[i], poffset, 
resid)) {
:+printf("getblk: clear B_CACHE, bufsize %ld, page %d valid %02x dirty %02x\n",
:+  bp->b_bufsize, i, bp->b_pages[i]->valid, bp->b_pages[i]->dirty);
:   bp->b_flags &= ~(B_CACHE | B_DONE);
:   break;
:   }
:


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

Re: panic: vinvalbuf: dirty bufs (during reboot, several times)

[Greg Lehey]

On Thursday, 21 January 1999 at  7:19:39 +0100, Andreas Klemm wrote:
> On Thu, Jan 21, 1999 at 12:09:00PM +1030, Greg Lehey wrote:
>> On Wednesday, 20 January 1999 at 19:33:54 +0100, Andreas Klemm wrote:
>>> On Tue, Jan 19, 1999 at 11:00:55PM -0800, Matthew Dillon wrote:

 Hmm.  Interesting, it's dying trying to fsync an FFS vnode.   Are you
 by any chance running NFS ( client *or* server ) on this box?
>>>
>>> No, no NFS compiled in and am not using it. See my kernel config.
>>
>> Where's your kernel config?  Are you running vinum?  I had some
>> problems with this in earlier versions, but I'm pretty sure none are
>> left.
>
> Im my first mail (where I reported the problem) I sent kernel config
> file and dmesg output. 

You shouldn't expect everybody to have kept that message.  Matt
obviously hadn't either.  That's what quotes are for.

> And no, sorry, am using ccd, not vinum.

No need to apologize :-)  If you had been using vinum, I'd have to
worry about a potential bug.  But it's conceivable that something
similar exists in ccd.  Try umounting the ccd file systems before
shutting down and see what happens.

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

Re: panic: vinvalbuf: dirty bufs (during reboot, several times)

[Andreas Klemm]

On Thu, Jan 21, 1999 at 12:09:00PM +1030, Greg Lehey wrote:
> On Wednesday, 20 January 1999 at 19:33:54 +0100, Andreas Klemm wrote:
> > On Tue, Jan 19, 1999 at 11:00:55PM -0800, Matthew Dillon wrote:
> >>
> >> Hmm.  Interesting, it's dying trying to fsync an FFS vnode.   Are you
> >> by any chance running NFS ( client *or* server ) on this box?
> >
> > No, no NFS compiled in and am not using it. See my kernel config.
> 
> Where's your kernel config?  Are you running vinum?  I had some
> problems with this in earlier versions, but I'm pretty sure none are
> left.

Im my first mail (where I reported the problem) I sent kernel config
file and dmesg output. And no, sorry, am using ccd, not vinum.

-- 
Andreas Klemmhttp://www.FreeBSD.ORG/~andreas
 What gives you 90% more speed, for example, in kernel compilation ?
  http://www.FreeBSD.ORG/~fsmp/SMP/akgraph-a/graph1.html
 "NT = Not Today" (Maggie Biggs)  ``powered by FreeBSD SMP''

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

Re: make release produces unbootable boot floppies, no boot loader, no /kernel

[Mike Smith]

>Hang on a second... I think you might be putting words in my
> mouth... I'm not saying that the nfs boot floppy is the One True
> Boot Floppy.  I see no reason why we can't have a netboot.flp and
> a dskboot.flp created.

The slicing that's being contemplated at the moment is actually
"install from CDROM" and "install from anywhere else".  The CDROM 
support actually covers a reasonable amount of code (although there are 
some angsty issues about ATAPI ZIP/LS120 disks still).

>If you really want to make things easier for the beginner, why
> not provide a DOS boot program. Then you wouldn't even have to
> worry about boot floppies. Tell new folks to copy the boot program
> to the DOS partition and run it from DOS. Case closed. No boot
> floppy required. I can imagine half a dozen ways to make this work.

Please read everything that Robert Nordier has written about how it's
not possible to boot once DOS has started.  Or take it from me - we have
canned support for that mode of operation and we're not going back.

>Unfortunately, I'm not a committer, and it really isn't a
> technical question... It's a political issue... FreeBSD seems to
> want 'The One True Floppy'...

Not really; and if you have diffs that let us split into a couple of
cleanly separated floppies with no missing cases then we would 
enthusiastically leap onboard.  But "net/no-net" isn't enough of a 
dividing line.  We're pretty much resigned to the death of "one true 
floppy".  8(


-- 
\\  Sometimes you're ahead,   \\  Mike Smith
\\  sometimes you're behind.  \\  m...@smith.net.au
\\  The race is long, and in the  \\  msm...@freebsd.org
\\  end it's only with yourself.  \\  msm...@cdrom.com



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

Re: C++ compliler unable to produce excutables

[root]

> 
> Do you have egcs or gcc-2.8 or anything else installaed that installs
> /usr/local/bin/g++? 
> 
yes, that's the one I really recently installed
I was suspecious about it, but now you confirmed it.

> Such extra compilers from ports tend to break. Make sure you use
> /usr/bin/g++. 
> 
Thanks
-- 
- MAY THE FORCE BE WITH YOU.~o  .^.
  ___   o~ .00 )
Static Email   : osiris2...@yahoo.com   /|   o~ /)(
Bouncing Email : r...@isis.dynip.com   / |   | \
Web Site   : http://isis.dynip.com:80 (Frames) ___/  |  /   \
Anon FTP Site  : ftp://isis.dynip.com:21 (anonymous)  |  /''___/ /   |
Gopher Site: gopher://isis.dynip.com:70   | /'''/___/|
Network News   : isis.dynip.com (Read, Post, Xfer)  __|/'''/
Mailing Lists  : majord...@isis.dynip.com (public)
pgp key: finger r...@isis.dynip.com


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

Re: KLD naming

[Jordan K. Hubbard]

> I guess it depends on how fancy we want to get.  Here are some examples 
> that I've been rolling around; some are fanciful, some practical)
> 
>   dev_generic device (eg. dev_sio)
>   bus_bus support (eg. bus_pci)
>   netif_  network interface (eg. netif_ed)
>   netproto_   network protocol (eg. netproto_arp)
>   netdomain_  network domain (eg. netdomain_ip)
>   vfs_VFS layer (eg. vfs_nfs)
>   kern_   kernel infrastructure (eg. kern_vfs)
>   syscall_loadable system calls (eg. syscall_sendfile)

I like this.  It's the best alternative to an arbitrarily deep
(and much disputed) directory structure I've seen so far.

- Jordan

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

Re: KLD naming

[Mike Smith]

> On Wed, Jan 20, 1999 at 07:19:15PM -0800, David O'Brien wrote:
> [..]
> > etc?  This is what the original poster suggested, and nobody has really
> > given a good response what is wrong with the "grouping" being expressed
> > in the modules' name.  Mike Smith and Andrzej Bialecki have given good
> > reasons why *not* to go to a subdirectory structure.
> 
> What would you name a network stack?   For example:
> 
>   net_mpls_tdp.ko
>   net_mpls_ldp.ko
>   net_mpls_core.ko
> 
> or
>   net_h323v2_yada.ko
>   net_h323v2_yadayada.ko
>   net_h323v2_barf.ko
> 
> or
>   codec_g711.ko
>   codec_g7231a.ko
>   codec_g729.ko
> 
> Is that acceptable?  Anyone have better ideas?

I guess it depends on how fancy we want to get.  Here are some examples 
that I've been rolling around; some are fanciful, some practical)

dev_generic device (eg. dev_sio)
bus_bus support (eg. bus_pci)
netif_  network interface (eg. netif_ed)
netproto_   network protocol (eg. netproto_arp)
netdomain_  network domain (eg. netdomain_ip)
vfs_VFS layer (eg. vfs_nfs)
kern_   kernel infrastructure (eg. kern_vfs)
syscall_loadable system calls (eg. syscall_sendfile)

I don't think we want to make the mistake of being too specific about 
what pigeonhole something falls into.  In many cases, we might want new 
categories when a new case arises, eg. for USB we might have:

bus_usb.ko
usb_hub.ko
usb_mouse.ko
usb_keyboard.ko
usb_disk.ko
usb_scanner.ko
...

There's no ambiguity here, the names are simple and convey a direct 
set of relationships.  Your examples (except the first) do a pretty 
good job of the same thing.

-- 
\\  Sometimes you're ahead,   \\  Mike Smith
\\  sometimes you're behind.  \\  m...@smith.net.au
\\  The race is long, and in the  \\  msm...@freebsd.org
\\  end it's only with yourself.  \\  msm...@cdrom.com



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

Re: make release produces unbootable boot floppies, no boot loader, no /kernel

[John W. DeBoskey]

hi,

   Hang on a second... I think you might be putting words in my
mouth... I'm not saying that the nfs boot floppy is the One True
Boot Floppy.  I see no reason why we can't have a netboot.flp and
a dskboot.flp created.

   If you really want to make things easier for the beginner, why
not provide a DOS boot program. Then you wouldn't even have to
worry about boot floppies. Tell new folks to copy the boot program
to the DOS partition and run it from DOS. Case closed. No boot
floppy required. I can imagine half a dozen ways to make this work.

   However, I don't really want the above. I'd simply like to see
a netboot.flp become a standard part of the distribution. There are
others on the list besides myself who have said they would like to
see this. It's simple to do, just a few extra commands in the
release.8 target.

   Unfortunately, I'm not a committer, and it really isn't a
technical question... It's a political issue... FreeBSD seems to
want 'The One True Floppy'...

Oh well,
Thanks for listening!
John

   I said:

> >If I hop on my soapbox, I'd really like to see a single floppy
> > network install which supports nfs(which I also re-enable on the
> > normal boot.flp since it fits on the 2.88M image).
> 
  and Mike replied:

> The problem is that there are too many people standing on too many 
> different soapboxes.  Each and every one of you wants a different 
> combination of stuff on the One True Boot Floppy.
> 
> I'm sure you can see what's wrong with this picture.
> 
> -- 
> \\  Sometimes you're ahead,   \\  Mike Smith
> \\  sometimes you're behind.  \\  m...@smith.net.au
> \\  The race is long, and in the  \\  msm...@freebsd.org
> \\  end it's only with yourself.  \\  msm...@cdrom.com
> 
> 


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

Re: boot.flp versions

[W Gerald Hicks]

[snips]
> As to whether a boot.flp from an earlier SNAP will "work just the same,"
> I don't know.
> 
> Cheers,
> david
> -- 
> David Wolfskill   UNIX System Administrator
> d...@whistle.com  voice: (650) 577-7158   pager: (650) 371-4621

I used a 3.0-RELEASE boot.flp to load a 'minimal configuration' by changing
the options screen to the Jan 12 SNAP.

First thing after that, I loaded a cvsup-bin package, grabbed the sources
from our local cvsup-mirror and built world.

It's working fine now but I'll bet 'you shouldn't do this' (TM)  :-)

Cheers,

Jerry Hicks
wghi...@bellsouth.net


--
Jerry Hicks
wghi...@bellsouth.net



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

Heads up! New swapper and VM changes being committed to -4.x tonight.

[Matthew Dillon]

The new swapper and a bunch of VM stuff I've been sitting 
on is going to be committed into the new -current tree tonight.

These changes also include the most recent NFS fix ( of two.. the
one prior to this one has already been committed ).  This fix and
numerous other minor VM bug fixes that are applicable to the -3.x tree
will be backported once some external testing has been done.  Hopefully
*before* the 3.1 freeze.

New material not related to out-and-out bug fixes will probably not
be backported to -3.x.  Or, if it is, not for some time.

-Matt

Matthew Dillon 


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

Re: KLD naming

[Robert Watson]

On Wed, 20 Jan 1999, Mike Smith wrote:

> > I was just pointing out that having things in subdirectories
> > is better than having a zillion files piled into a single directory.
> 
> I'm torn between agreeing that it's tidier and disagreeing on the 
> grounds that it's much more of a pain to administer.  "Where is that 
> damnned module?" "Why am I loading a stale version of saver_foo?", etc.

Putting the source code in different directories is not equivilent to
putting the modules in different directories, needless to say.  :-)  As
such, I think having a structured source tree is really nice, but the
simplicity of modules in a single directory in the style of MacOS
extensions as you discuss has appeal (and means that users don't have to
try and reproduce a directory hierarchy for binary-only modules they get
somewhere).  On the other hand, this still requires moderation in
namespace use for modules.

  Robert N Watson 

rob...@fledge.watson.org  http://www.watson.org/~robert/
PGP key fingerprint: 03 01 DD 8E 15 67 48 73  25 6D 10 FC EC 68 C1 1C

Carnegie Mellon Universityhttp://www.cmu.edu/
TIS Labs at Network Associates, Inc.  http://www.tis.com/
SafePort Network Services http://www.safeport.com/


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

Re: make: don't know how to make vinumdaemon.c. Stop

[Greg Lehey]

On Wednesday, 20 January 1999 at 23:34:52 -0500, Mike Tancsa wrote:
> At 02:51 PM 1/21/99 +1030, Greg Lehey wrote:
>> On Wednesday, 20 January 1999 at 23:15:15 -0500, Mike Tancsa wrote:
>>>
>>> Am I the only one seeing this ?
>>
>> Yes, I think so.
>> I would guess that you cvsupped in the window between 16:25:48 PST,
>> when I committed the new Makefile, and 16:31:31 PST, when I committed
>> vinumdaemon.c.  Try again once the tags have been updated (a couple of
>> hours).  Check sys/conf/newvers.sh: it should show 4.0.
>
> Sounds like this might be the problem... I will resup it again in a bit.
> #   @(#)newvers.sh  8.1 (Berkeley) 4/20/94
> #   $Id: newvers.sh,v 1.41 1998/11/01 15:36:20 wosch Exp $
>
> TYPE="FreeBSD"
> REVISION="3.0"
> BRANCH="CURRENT"
> RELEASE="${REVISION}-${BRANCH}"
> SNAPDATE=""

Yup, I'm waiting too.

BTW, read the HEADS UP that I sent out a while back.

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

Re: make: don't know how to make vinumdaemon.c. Stop

[Mike Tancsa]

At 02:51 PM 1/21/99 +1030, Greg Lehey wrote:
>On Wednesday, 20 January 1999 at 23:15:15 -0500, Mike Tancsa wrote:
>>
>> Am I the only one seeing this ?
>
>Yes, I think so.
>I would guess that you cvsupped in the window between 16:25:48 PST,
>when I committed the new Makefile, and 16:31:31 PST, when I committed
>vinumdaemon.c.  Try again once the tags have been updated (a couple of
>hours).  Check sys/conf/newvers.sh: it should show 4.0.

Sounds like this might be the problem... I will resup it again in a bit.
#   @(#)newvers.sh  8.1 (Berkeley) 4/20/94
#   $Id: newvers.sh,v 1.41 1998/11/01 15:36:20 wosch Exp $

TYPE="FreeBSD"
REVISION="3.0"
BRANCH="CURRENT"
RELEASE="${REVISION}-${BRANCH}"
SNAPDATE=""



---Mike

**
Mike Tancsa, Network Admin*  m...@sentex.net
Sentex Communications Corp,   *  http://www.sentex.net/mike
Cambridge, Ontario*  01.519.651.3400
Canada*

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

Re: make: don't know how to make vinumdaemon.c. Stop

[Greg Lehey]

On Wednesday, 20 January 1999 at 23:15:15 -0500, Mike Tancsa wrote:
>
> Am I the only one seeing this ?

Yes, I think so.

> Current as a few hrs ago...
>
> /usr/src/sys/modules/mfs/../../ufs/mfs/mfs_vfsops.c:68: warning: 
> `mfs_rootsize' defined but not used
> /usr/src/sys/modules/vinum/../../dev/vinum/vinum.c:324: warning: 
> initialization from incompatible pointer type
> /usr/src/sys/modules/vinum/../../dev/vinum/vinumio.c: In function 
> `check_drive':
> /usr/src/sys/modules/vinum/../../dev/vinum/vinumio.c:513: warning: variable 
> `cptr' might be clobbered by `longjmp' or `vfork'

Hmm.  These messages look like an old version of vinumio.c.

> make: don't know how to make vinumdaemon.c. Stop>

I would guess that you cvsupped in the window between 16:25:48 PST,
when I committed the new Makefile, and 16:31:31 PST, when I committed
vinumdaemon.c.  Try again once the tags have been updated (a couple of
hours).  Check sys/conf/newvers.sh: it should show 4.0.

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

Re: KLD naming

[Christian Kuhtz]

On Wed, Jan 20, 1999 at 07:19:15PM -0800, David O'Brien wrote:
[..]
> etc?  This is what the original poster suggested, and nobody has really
> given a good response what is wrong with the "grouping" being expressed
> in the modules' name.  Mike Smith and Andrzej Bialecki have given good
> reasons why *not* to go to a subdirectory structure.

What would you name a network stack?   For example:

net_mpls_tdp.ko
net_mpls_ldp.ko
net_mpls_core.ko

or
net_h323v2_yada.ko
net_h323v2_yadayada.ko
net_h323v2_barf.ko

or
codec_g711.ko
codec_g7231a.ko
codec_g729.ko

Is that acceptable?  Anyone have better ideas?

Cheers,
Chris

-- 
  "Logic is a little bird, sitting in a tree; that smells *awful*."
 --  /usr/bin/fortune

[Disclaimer: I speak for myself and my views are my own and not in any way to
 be construed as the views of BellSouth Corporation. ]

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

make: don't know how to make vinumdaemon.c. Stop

[Mike Tancsa]

Am I the only one seeing this ?  Current as a few hrs ago...

/usr/src/sys/modules/mfs/../../ufs/mfs/mfs_vfsops.c:68: warning:
`mfs_rootsize' defined but not used
/usr/src/sys/modules/vinum/../../dev/vinum/vinum.c:324: warning:
initialization from incompatible pointer type
/usr/src/sys/modules/vinum/../../dev/vinum/vinumio.c: In function
`check_drive':
/usr/src/sys/modules/vinum/../../dev/vinum/vinumio.c:513: warning: variable
`cptr' might be clobbered by `longjmp' or `vfork'
make: don't know how to make vinumdaemon.c. Stop


---Mike
**
Mike Tancsa, Network Admin*  m...@sentex.net
Sentex Communications Corp,   *  http://www.sentex.net/mike
Cambridge, Ontario*  01.519.651.3400
Canada*

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

Re: KLD naming

[Christian Kuhtz]

Why not just follow the directory structure under /sys?

Afterall, we are talking about kernel stuff here.

On Wed, Jan 20, 1999 at 10:58:13AM -, p...@originative.co.uk wrote:
[..]
> I don't think subdirectories based on bus type is a good idea, it
> doesn't really fit the granularity we're probably heading towards. Some
> thinks don't really fit at all, filesystems, screen savers etc and even
> for drivers we're heading towards less bus specific devices so an
> ethernet driver, say, would be the same for any bus, only the startup
> code would be different and possibly(probably) in a different module.
> 
> A functional structure is probably better
> 
> /modules
>   /devices
>   /ethernet
>   /storage
>   /display
>   /network
>   /filesystems
>   /screensavers
> 
> 
> etc.
> 
> Not a specific proposal for actual directories but perhaps a better
> direction. I think we should start thinking more in terms of function,
> rather than bus, in a lot of what we do with devices as we abstract out
> the bus code more effectively.
> 
> Paul.
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
> 

-- 
  "Logic is a little bird, sitting in a tree; that smells *awful*."
 --  /usr/bin/fortune

[Disclaimer: I speak for myself and my views are my own and not in any way to
 be construed as the views of BellSouth Corporation. ]

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

Re: ELF kernel make problem

[Kenneth Wayne Culver]

> 
> 
>  I recently used "make world" to update make system to ELF. The make world
> finished successfully everything appears to function correctly except when
> I try to recompile my kernel. make depend works but once I get to 'make'
> it will compile for a while then stop when it gets to db_aout.o and say
> Not an ELF file, or File format not recognized.  Any suggestions?
> 
> Owen
> 
> BTW - I used mergemaster to update my files.

when you do the config on your kernel config file type:

config -r  

replace  with the name of your kernel config file.

Kenneth Culver


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

ELF kernel make problem

[Owen Barnett]

 I recently used "make world" to update make system to ELF. The make world
finished successfully everything appears to function correctly except when
I try to recompile my kernel. make depend works but once I get to 'make'
it will compile for a while then stop when it gets to db_aout.o and say
Not an ELF file, or File format not recognized.  Any suggestions?

Owen

BTW - I used mergemaster to update my files.



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

HEADS UP: New version of Vinum

[Greg Lehey]

I've just committed a new version of Vinum with a large number of
changes.  It works fine here, much better than the old version, but
there's just a possibility that things may go wrong.  If you have
trouble, please let me know immediately.

One way you can shoot yourself in the foot: the `read' command has
changed.  In the previous version, you specified the name of exactly
one device containing a vinum partition.  This is suboptimal, because
it doesn't allow you to read multiple configurations, and it doesn't
allow you to move drives around.  In the new version, you *must*
specify the names of *all* disks containing Vinum partitions.  For
example, if you have Vinum partitions /dev/da1h /dev/da2h /dev/da3h
/dev/da4h /dev/da5h and /dev/da6h, you might previously have written:

  vinum read /dev/da3h

Now you *must* write:

  vinum read /dev/da1 /dev/da2 /dev/da3 /dev/da4 /dev/da5 /dev/da6

If you do this wrong, you have the potential to wipe out your on-disk
configuration.  You can avoid this by disabling saving the
configuration.  Do this with the `setdaemon' command:

  # vinum
  vinum -> setdaemon 4
  vinum -> read /dev/da1 /dev/da2 /dev/da3 /dev/da4 /dev/da5 /dev/da6

Yes, I know, specifying bits for the setdaemon command is tacky, and
it'll go away.  Bit 4 disables the configuration save.  When your
configuration is recognized correctly, you can re-enable it with
`setdaemon 0'.  For more information RTFM.

The on-disk configuration has also changed.  Previously, it contained
the names of the drives as well as the other objects; now Vinum finds
the drives by itself.  You can check the versions by looking at the
config copy at offset 9 blocks from the beginning of the partition:

   # dd if=/dev/da2h skip=9 count=1
   volume obj state up
   volume src state up
   volume raid state up
   volume r state up
   volume S state up
   plex name obj.p0 state up org concat vol obj 
   plex name obj.p1 state up org striped 128b vol obj 
   plex name src.p0 state up org striped 128b vol src 
   plex name src.p1 state up org concat vol src 
   plex name raid.p0 state up org raid5 vol raid 
   plex name r.p0 state up org raid5 vol r 
   plex name S.p0 state up org raid5 vol S 
   sd name obj.p0.s0 drive drive2 plex obj.p0 state up len 409600b driveoffset 
265b plexof1+0 records in

This version shows the new configuration: it starts with volume
definitions.  The old version starts with drive definitions.  The
new version will ignore any drive definitions it finds in the
configuration.

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

Re: KLD naming

[David O'Brien]

> Perhaps something more along the lines of:
> 
> /modules<- empty, except for directories
> /console<- console related modules
> blank_saver.ko, daemon_saver.ko, fade_saver.ko, green_saver.ko,

Gross.  What is wrong with:

saver_*.ko
device_*.ko
linux_*.ko
fs_*.ko
if_*.ko

etc?  This is what the original poster suggested, and nobody has really
given a good response what is wrong with the "grouping" being expressed
in the modules' name.  Mike Smith and Andrzej Bialecki have given good
reasons why *not* to go to a subdirectory structure.

-- 
-- 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: boot.flp versions

[David O'Brien]

> I'm wondering if an earlier boot.flp, say from the 1/6/99 SNAP, will
> work just the same?  Thanks.

Normally, a boot.flp of about the same time will work fine.  You just
need to go into the Options and change the release name string.

The 1/6/99 boot.flp is broken.  /boot/* can't be found.  This means you
can't do a fresh install (well, maybe in dangeriously dedicated mode -- I
didn't try that) because the boot blocks can't be found by sysinstall.

I was able to install the 1/6/99 SNAP by 1st installing a minimal 3.0-R
and then doing an upgrade using the 1/6/99 boot.flp.  This will leave you
with an a.out kernel.  You will need to install new boot blocks before
you make your first 1/6/99 kernel.
 
-- 
-- 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: boot.flp versions

[Neal Westfall]

I installed the 19990112 snap late last night with no problems using
the 2 disk install.  Worked great.  Its now been upgraded to current.

On Thu, 21 Jan 1999, Daniel O'Connor wrote:

> The boot.flp is broken..
> Try the 2 disk install (ie kern.flp and mfsroot.flp)
> 
> They boot, but when I got some sucker^h^h^h^h friend to test it, he had no 
> end of trouble
> installing. Things like sysinstall trying to run the holographic shell twice,
> mounting things twice and sig-11'ing..
> 
> I recommended a source install after that :)
> 
> ---
> 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
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
> 

--
Neal Westfall  mailto:nwest...@odc.net  http://www.odc.net/~nwestfal/
FreeBSD: The Power To Serve!http://www.freebsd.org/

  $Id: dot.signature,v 1.2 1998/12/30 08:23:13 nwestfal Exp nwestfal $


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

Re: FreeBSD include paths

[Mike Smith]

> Hello all,
> 
> I got a nagging question...
> Very often when trying to compile packages I find myself editing
> makefiles and having to add really obvious include paths like
> /usr/local/include or /usr/X11R6/include in order to get the
> package installed.
> Now I wonder, why doesn't the system itself have these include paths
> "enabled"  by default?
> Is there a way to fix these ever occuring annoyances when compiling
> programs?

You are probably building sources from Linux developers.  The "correct" 
fix is to edit the Makefiles as you are doing, and point out to the 
package authors that it is not correct to assume that the system 
includes will be spammed with installed packages.

> -- 
> QQWT!"^""9QQQ 
> QP'  _%7? WindowMaker, the choice of a GNUstep Generation. 

Please trim your oversized and offensive signature file.

-- 
\\  Sometimes you're ahead,   \\  Mike Smith
\\  sometimes you're behind.  \\  m...@smith.net.au
\\  The race is long, and in the  \\  msm...@freebsd.org
\\  end it's only with yourself.  \\  msm...@cdrom.com



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

Re: make release produces unbootable boot floppies, no boot loader, no /kernel

[Mike Smith]

>If I hop on my soapbox, I'd really like to see a single floppy
> network install which supports nfs(which I also re-enable on the
> normal boot.flp since it fits on the 2.88M image).

The problem is that there are too many people standing on too many 
different soapboxes.  Each and every one of you wants a different 
combination of stuff on the One True Boot Floppy.

I'm sure you can see what's wrong with this picture.

-- 
\\  Sometimes you're ahead,   \\  Mike Smith
\\  sometimes you're behind.  \\  m...@smith.net.au
\\  The race is long, and in the  \\  msm...@freebsd.org
\\  end it's only with yourself.  \\  msm...@cdrom.com



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

FreeBSD include paths

[Marco van Hylckama Vlieg]

Hello all,

I got a nagging question...
Very often when trying to compile packages I find myself editing
makefiles and having to add really obvious include paths like
/usr/local/include or /usr/X11R6/include in order to get the
package installed.
Now I wonder, why doesn't the system itself have these include paths
"enabled"  by default?
Is there a way to fix these ever occuring annoyances when compiling
programs?

Thanks in advance,

Marco

-- 
QQWT!"^""9QQQ 
QP'  _%7? WindowMaker, the choice of a GNUstep Generation. 
PWQQ, http://www.windowmaker.org/
'mWQh Marco's WindowMaker icons:
.__s_QWQQ http://marco.shada.com/wmaker/
.   ]QQQ@ 
L   )WQQ( Marco van Hylckama Vlieg
!`_ajQ@(  ma...@windowmaker.org
   "?TUVY"`   


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

Re: make release produces unbootable boot floppies, no boot loader, no /kernel

[John W. DeBoskey]

   Well, FWIW, I've been modifying my local 'make release' to produce
a 2.88M boot floppy, which I then use as the boot image when I burn a
CD of the SNAP. Works like a champ.

   Thus, the isofs creation is a straight run of the code in 
examples/worm and cdrecord:

sh /usr/share/examples/worm/makecdfs.sh \
   -b "${SNAP}" /cdwork/disc1 /cdwork/cd1.image \
  "${SNAP} (c) FreeBSD" && \
cd /cdwork && cdrecord dev=5,0 speed=4 -v cd1.image



   If I hop on my soapbox, I'd really like to see a single floppy
network install which supports nfs(which I also re-enable on the
normal boot.flp since it fits on the 2.88M image).


oh well,
John


> Mike Smith wrote:
> 
> > > This sounds like booting/installing from CD-ROM is currently
> > > impossible as well ???
> >
> > That's correct.  We're looking at having to move to a harddisk
> > emulation mode to get this back on track.
> 
> Would a 2.88M virtual floppy for the CD-ROM boot image be a quick fix, or is
> it too much work?
> 
> 
> - --
> Drew Derbyshire UUPC/extended e-mail:  softw...@kew.com
>Telephone:  617-279-9812
> 
> "I get by with a little help from my friends . . ."  - Lennon/McCartney
> 
> 
> 
> 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

RE: boot.flp versions

[Daniel O'Connor]

On 21-Jan-99 Matt Behrens wrote:
>  From 19990112?  I had no such problems on three different systems.
Hmm.. OK..
Maybe pilot error :)

---
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

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

Re: KLD naming

[Zach Heilig]

On Wed, Jan 20, 1999 at 03:36:14PM -0800, Mike Smith wrote:
> [KLD module file locations]
> > I was just pointing out that having things in subdirectories
> > is better than having a zillion files piled into a single directory.

> I'm torn between agreeing that it's tidier and disagreeing on the 
> grounds that it's much more of a pain to administer.  "Where is that 
> damnned module?" "Why am I loading a stale version of saver_foo?", etc.

Perhaps something more along the lines of:

/modules<- empty, except for directories
/console<- console related modules
blank_saver.ko, daemon_saver.ko, fade_saver.ko, green_saver.ko,
logo_saver.ko, rain_saver.ko, snake_saver.ko, star_saver.ko,
vesa.ko, warp_saver.ko
/devices<- device drivers.
joy.ko
/emulation  <- like linux, fpu, etc...
fpu.ko, gnufpu.ko, ibcs2.ko, ibcs2_coff.ko, linux.ko
/fs <- filesystem related modules
atapi.ko, ccd.ko, cd9660.ko, coda.ko, fdesc.ko, kernfs.ko, mfs.ko,
msdos.ko, nfs.ko, null.ko, portal.ko, procfs.ko, umap.ko, union.ko,
vinum.ko
/net<- network related modules.
if_disc.ko, if_ppp.ko, if_sl.ko, if_tun.ko, ipfw.ko

I think this takes care of everything currently in /modules.

-- 
Zach Heilig  / Zach Heilig 

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

Re: boot.flp versions

[Jordan K. Hubbard]

All: Sorry the boot.flp has been broken for this long, but I've had
other distractions lately.  I will make it work once more, somehow
or other, and just keep your eyes on current.freebsd.org over
the next few days.  When it returns to 1.44MB in size again, give
it a try. :)

- Jordan

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

Re: boot.flp versions

[David Wolfskill]

>Date: Wed, 20 Jan 1999 17:50:58 -0800 (PST)
>From: "Richard J. Dawes" 

>The "boot.flp" in 3.0.0-19990112-SNAP/floppies is 2880K, which of course
>won't work.  [I think this was acknowledged earlier by JKH, but has gone
>unfixed.]  I'm wondering if an earlier boot.flp, say from the 1/6/99
>SNAP, will work just the same?  Thanks.

Mike Smith alluded to the "two-floppy boot" procedure about a week ago;
the README.TXT in the floppies directory mentions how to use the
kern.flp & the mfsroot.flp images to get started.

As to whether a boot.flp from an earlier SNAP will "work just the same,"
I don't know.

Cheers,
david
-- 
David Wolfskill UNIX System Administrator
d...@whistle.comvoice: (650) 577-7158   pager: (650) 371-4621

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

Re: /etc/nsswitch.conf

[Joerg B. Micheel]

On Wed, Jan 20, 1999 at 05:58:01PM +0100, Dag-Erling Smorgrav wrote:
> Mike Nguyen  writes:
> > I noticed that NetBSD is switching over to using /etc/nsswitch.conf (like
> > Slowlaris, PH-UX, etc.). Would it be a good idea to do this for FreeBSD too
> > (when I first started using FreeBSD, it took me a long time to figure out 
> > the
> > analogous file for hostname lookups was /etc/host.conf) -- it seems
> > consolidating all that config information would in one place would be a good
> > thing.
> 
> When I first started using Solaris, it took me a long time to figure
> out the analoguous file for hostname setup was /etc/nodename. It seems

Thats because Solaris has separated hostname's from nodename. Originally,
/etc/hostname.le0, the name/IP address for the primary Ethernet interface,
would become the hosts name. What, if you have 3 or 4 interfaces ? The
algorithm used in /etc/rc* with SunOS would pick the first interface
available. Now if you happen to have a vendor that picks an network
interface name "lower" than "le", your host suddenly may a different
name. So it happend with FORE's SPANS interface (fa0). When reading
Internet RFCs carefully, you figure that there is in fact the term of
a nodename, so the decision that Sun made was not very far fetched.
Which did not keep them from making the same mistake again. The
default multicast interface again gets chosen the same odd way, instead
of having a separate configuration mechanism. I chose to reconfigure
machines and add something like /etc/hostname.mcast and make it a
symlink to the appropriate interface.

> consolidating all that config information in one place, such as
> /etc/rc.conf, would be a good thing.

Agreed, it really isn't such a good idea to clutter /etc/ with all
those single line configuration files.

Joerg
-- 
Joerg B. MicheelEmail: 
SingAREN Technology Center  Phone: +65 8742582
Kent Ridge Digital Labs, Rm 3-65, C041  Fax:   +65 7744990
21 Heng Mui Keng TerracePager: +65 96016020
Singapore 119613Plan:  Troubleshooting ATM
Republic of Singapore  Networks and Applications

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

Re: boot.flp versions

[Mike Smith]

> Hello!
> 
> The "boot.flp" in 3.0.0-19990112-SNAP/floppies is 2880K, which of course
> won't work.  [I think this was acknowledged earlier by JKH, but has gone
> unfixed.]  I'm wondering if an earlier boot.flp, say from the 1/6/99
> SNAP, will work just the same?  Thanks.

Use the two-floppy install (kern.flp, mfsroot.flp) instead.

-- 
\\  Sometimes you're ahead,   \\  Mike Smith
\\  sometimes you're behind.  \\  m...@smith.net.au
\\  The race is long, and in the  \\  msm...@freebsd.org
\\  end it's only with yourself.  \\  msm...@cdrom.com



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

RE: boot.flp versions

[Matt Behrens]

>From 19990112?  I had no such problems on three different systems.

(System #3 had a lot of other unrelated problems, like a loose
ethernet cable and mislabelled jumpers on drives, but none of them
were 19990112-related.) :)

On Thu, 21 Jan 1999, Daniel O'Connor wrote:

: On 21-Jan-99 Richard J. Dawes wrote:
: >  The "boot.flp" in 3.0.0-19990112-SNAP/floppies is 2880K, which of course
: >  won't work.  [I think this was acknowledged earlier by JKH, but has gone
: >  unfixed.]  I'm wondering if an earlier boot.flp, say from the 1/6/99
: >  SNAP, will work just the same?  Thanks.
: The boot.flp is broken..
: Try the 2 disk install (ie kern.flp and mfsroot.flp)
: 
: They boot, but when I got some sucker^h^h^h^h friend to test it, he had no 
end of trouble
: installing. Things like sysinstall trying to run the holographic shell twice,
: mounting things twice and sig-11'ing..
: 
: I recommended a source install after that :)

- Matt Behrens 
  Network Administrator, zigg.com 
  Engineer, Nameless IRC Network 


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

Re: panic: vinvalbuf: dirty bufs (during reboot, several times)

[Greg Lehey]

On Wednesday, 20 January 1999 at 19:33:54 +0100, Andreas Klemm wrote:
> On Tue, Jan 19, 1999 at 11:00:55PM -0800, Matthew Dillon wrote:
>>
>> Hmm.  Interesting, it's dying trying to fsync an FFS vnode.   Are you
>> by any chance running NFS ( client *or* server ) on this box?
>
> No, no NFS compiled in and am not using it. See my kernel config.

Where's your kernel config?  Are you running vinum?  I had some
problems with this in earlier versions, but I'm pretty sure none are
left.

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

Re: KLD naming

[Archie Cobbs]

Mike Smith writes:
> > > A single directory holding module files.
> > 
> > Blech :-)
> 
> Put aside the aesthetics for a moment, and try to raise some real, 
> practical objections.  I'm continually battling my own temptation to 
> make the whole module thing more complex, but if you've got really good 
> reasons that can justify the extra complexity everywhere I'm still open 
> to suggestions.

You've got a good point, I don't have any really good reasons,
other than trying to be 'organized'.

I guess if it looks like the number of files is getting out of
hand, then at that time we can say "I told you so!" and then fix
the problem.

Solving problems on-demand rather than preemptively is more
efficient I suppose.. :-)

-Archie

___
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com

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

RE: boot.flp versions

[Daniel O'Connor]

On 21-Jan-99 Richard J. Dawes wrote:
>  The "boot.flp" in 3.0.0-19990112-SNAP/floppies is 2880K, which of course
>  won't work.  [I think this was acknowledged earlier by JKH, but has gone
>  unfixed.]  I'm wondering if an earlier boot.flp, say from the 1/6/99
>  SNAP, will work just the same?  Thanks.
The boot.flp is broken..
Try the 2 disk install (ie kern.flp and mfsroot.flp)

They boot, but when I got some sucker^h^h^h^h friend to test it, he had no end 
of trouble
installing. Things like sysinstall trying to run the holographic shell twice,
mounting things twice and sig-11'ing..

I recommended a source install after that :)

---
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

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

boot.flp versions

[Richard J. Dawes]

Hello!

The "boot.flp" in 3.0.0-19990112-SNAP/floppies is 2880K, which of course
won't work.  [I think this was acknowledged earlier by JKH, but has gone
unfixed.]  I'm wondering if an earlier boot.flp, say from the 1/6/99
SNAP, will work just the same?  Thanks.

--Rich




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

Experiences with aout-to-elf and new bootblocks

[Peter Jeremy]

I have been experimenting with moving a 2.2.6-RELEASE system to 3.0
(-current for now, but probably moving towards -stable).  Not wanting
to totally trash my current system until I have the new one working,
I've been building 3.0 on a second disk [mounted as /3.0 on my 2.x
system].

I'm using CTM 'cvs-cur 4996' as a base.

My experiences with 'DESTDIR=/3.0 make aout-to-elf' are:
1) The _real_ system libraries are moved, rather than the ones
   relative to /3.0.  I then need to manually move them back and
   repeat the ldconfig to keep my 2.x system consistent.
2) The miniperl built during the perl5 build looks in
   /usr/libdata/perl for it's libraries, although they're installed
   in /3.0/usr/libdata/perl.  A manual symbolic link fixed that.
3) During the kernel build (do_aout_kernel), config fails because
   it is using the 2.x config instead of the one it just built.
   I solved this with "chroot /3.0 'build kernel'"

Other than the above, everything worked (although I wasn't game to try
the do_install_kernel_reboot step and installed the new kernel
manually).

[I also needed to manually run 'make distribution' in .../src/etc
 to initially populate the new /etc - before manually transferring
 my system configuration].

I then had a look at the new bootblocks (following Peter's elfday
tutorial: http://www.freebsd.org/~peter/elfday.html).  I found that
/boot/loader could load my 2.x kernel (although it happily handled
[gzip'd] -current kernels in both a.out and ELF format).  The stage2
loader boot: prompt happily loaded the 2.x kernel.  When /boot/loader
tries to load my 2.x kernel, the screen displays gibberish and the
system locks up (hard reset needed).  Any ideas on this one?

Finally, whilst I can happily load a 3.x kernel from my 2nd HD,
the kernel is confused about where it's loading from:  It can't
find root and panics.

System details: PII-266 with IDE disks:
primary master:   wd0:  dualboot (W95/FreeBSD 2.x)
primary slave:ATAPI cdrom
secondary master: wd2: FreeBSD 3.0 (not dangerously dedicated)
secondary slave:  not present

Both the 2.x and -current kernels correctly recognize both disks
during the probes.  When I try to boot from wd2a, the kernel
reports:
changing root device to wd1s1a
changing root device to wd1a
error 6: panic cannot mount root(2)

If I recall correctly, the problem here is that the BIOS is reporting
the 2 HDs as 0 and 1, rather than 0 and 2.  I can't recall what the
work-around is (I'd prefer not to juggle the disks).  Any suggestions?

Peter
--
Peter Jeremy (VK2PJ)peter.jer...@alcatel.com.au
Alcatel Australia Limited
41 Mandible St  Phone: +61 2 9690 5019
ALEXANDRIA  NSW  2015   Fax:   +61 2 9690 5982

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

Re: Booting -current with new loader

[John Saunders]

On Wed, 20 Jan 1999, Mike Smith wrote:

> > The option of putting the second drive
> > as slave on the primary interface would work, however anybody that knows
> > anything about IDE (read somebdy interested in trying FreeBSD) would put
> > it on the second interface for speed reasons.
> 
> Er, you want to stop and think about that for a second?  If you have 
> Windows on one disk and FreeBSD on the other, where is the opportiunity 
> for drive conflicts (the source of performance loss)?

In the context of one disk totally Windows and the other totally FreeBSD
then yes you are correct. However I have a 1 Gig partition at the end of
both disks that I have a CCD mirror on. Read performance won't suffer by
moving the drive but write performance halves. Actually I have intended to
modify CCD so that is distributes reads over all devices in the mirror, I
noticed that it simply hammers the first drive. I'm not sure if core would
be interested in such a patch since I think vinum is taking over.

That's why I shy away from moving my hardware around. Also I would have to
break out the screw driver, when all I need is some finger work.

> > I'm not sure about anybody else here, but to my mind a "Winblows on C:
> > drive and let's try out FreeBSD on the second disk" configuration should
> > really be supported seamlessly. 
> 
> You're more than welcome to propose a technical solution that solves 
> the problem.

OK, the technical solution that I propose is an alternative (optional
because I want to retain the current semantics) config semantics. 

controller  wdc0at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff
controller  wdc1at isa? port "IO_WD2" bio irq 15 flags 0xa0ffa0ff
diskwd? at wdc?

This would act identical to the way the SCSI system works by assigning
names to disks as they get probed. It would also have the advantage of
assigning disk names in the same order as the BIOS (and thereby the boot
loader), hence there would be a 1 to 1 mapping between what the boot
loader uses and what the FreeBSD kernel detects. 

I believe the current problem stems from the BIOS (and thereby the boot
loader) and the FreeBSD kernel assigning names using a different algorithm
and then getting out of step when the kernel skips a name.

If anybody knows how to do this quickly then I am happy to help test it. 

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.   |
  ++


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

Re: Truth to M_WAITOK?

[Dan Swartzendruber]

At 03:46 PM 1/20/99 -0800, Mike Smith wrote:
>> >It looks like M_WAITOK will either return non-NULL or panic; it 
>> >shouldn't be capable of returning NULL.  Ideally, it shouldn't panic 
>> >either (why is it only that M_WAITOK can panic, and M_NOWAIT can't?).
>> 
>> Because failures for M_NOWAIT are normal (all pages may be in use,
>> and the caller is not prepared for pages top be freed by swapping).
>> Therefore, callers that set M_NOWAIT must be prepared for failure.  OTOH,
>> failures for M_WAITOK are abnormal, and at least for map == kmem_map (as
>> it is for calls to kmem_malloc() from malloc()), the correct handling
>> for failure is to panic since a full map is unlikely to become unfull
>> and neither the caller or kmem_malloc() can know what to do to unfill it.
>
>Bear with the ignorance a moment; how is a full map any different to no 
>more kmem space?
>
>In the "out of kmem" case, we call VM_WAIT and retry.  Why not do this 
>in the kmem_map full case as well?

I've stayed out of this until now, but here's my 2 cents.  I never
understood why so much Unix code can't be bothered to check error codes.
If the semantics for a procedure are to return NULL if it can't get the
buffer without waiting, fine.  I don't understand why that implies that
specifying that you are willing to wait means the routine can never fail.
If it is true that an allocation routine will never normally fail when
WAITOK is specified, that still doesn't mean that some implementation or
other couldn't return NULL on some kind of pathological error.  Maybe not
in this subsystem, but I don't like the precedent that is set.




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

Re: Truth to M_WAITOK?

[Bruce Evans]

>Bear with the ignorance a moment; how is a full map any different to no 
>more kmem space?

I'd call them the same.  The map is kmem_map for malloc(), and running
out of space in that map is fatal.  When the map fills up, it is usually
not really full, it is just so fragmented that contiguous space can't be
found for the larger than usual allocation in the current request.
Freeing memory in the map won't necessarily reduce fragmentation.  The
map must be quite sparse to work at all.

>In the "out of kmem" case, we call VM_WAIT and retry.  Why not do this 
>in the kmem_map full case as well?

I'd call that the the out of general memory (pages) case.  This is non-
fatal because normally lots of memory is allocated to applications and
it is easy to free some by swapping.   There are no fragmentation problems
since pages can be mapped anywhere in virtual memory.

Bruce

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

Re: KLD naming

[Andrzej Bialecki]

On Wed, 20 Jan 1999, Archie Cobbs wrote:

> > > I like this idea (subdirectories) better.. it will last longer :-)
> > 
> > It's a really bad idea, because it requires you to classify things.  It 
> > also makes it much harder to administer.  In addition, classifications 
> > are bad (witness the need to reorganise the kernel source tree).
> > 
> > > You should then be able to load a module "isa/if_ed.ko" etc
> > > and have it work (no leading slash).
> > 
> > And here is a good example.  Why would you want to put if_ed in the 
> > "ISA" category when it can be attached to both the PCI and ISA busses?
> 
> I don't care how you classify it.. of course the "isa" category is wrong.
> 
> I was just pointing out that having things in subdirectories
> is better than having a zillion files piled into a single directory.

Not always. Consider a case when all modules are on a slow media (such as
a floppy or zipfs) - then putting things in subdirs adds quite significant
overhead to load/ls/search due to pathname lookups.

Andrzej Bialecki

   ++---++  -
||PicoBSD||   FreeBSD in your pocket? Go and see:
 Research & Academic   |+---+|   "Small & Embedded FreeBSD"
 Network in Poland | |TT~~~| |http://www.freebsd.org/~picobsd/
   ~-+==---+-+  -


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

Re: Truth to M_WAITOK?

[Mike Smith]

> >It looks like M_WAITOK will either return non-NULL or panic; it 
> >shouldn't be capable of returning NULL.  Ideally, it shouldn't panic 
> >either (why is it only that M_WAITOK can panic, and M_NOWAIT can't?).
> 
> Because failures for M_NOWAIT are normal (all pages may be in use,
> and the caller is not prepared for pages top be freed by swapping).
> Therefore, callers that set M_NOWAIT must be prepared for failure.  OTOH,
> failures for M_WAITOK are abnormal, and at least for map == kmem_map (as
> it is for calls to kmem_malloc() from malloc()), the correct handling
> for failure is to panic since a full map is unlikely to become unfull
> and neither the caller or kmem_malloc() can know what to do to unfill it.

Bear with the ignorance a moment; how is a full map any different to no 
more kmem space?

In the "out of kmem" case, we call VM_WAIT and retry.  Why not do this 
in the kmem_map full case as well?

-- 
\\  Sometimes you're ahead,   \\  Mike Smith
\\  sometimes you're behind.  \\  m...@smith.net.au
\\  The race is long, and in the  \\  msm...@freebsd.org
\\  end it's only with yourself.  \\  msm...@cdrom.com



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

Re: Truth to M_WAITOK?

[Bruce Evans]

>It looks like M_WAITOK will either return non-NULL or panic; it 
>shouldn't be capable of returning NULL.  Ideally, it shouldn't panic 
>either (why is it only that M_WAITOK can panic, and M_NOWAIT can't?).

Because failures for M_NOWAIT are normal (all pages may be in use,
and the caller is not prepared for pages top be freed by swapping).
Therefore, callers that set M_NOWAIT must be prepared for failure.  OTOH,
failures for M_WAITOK are abnormal, and at least for map == kmem_map (as
it is for calls to kmem_malloc() from malloc()), the correct handling
for failure is to panic since a full map is unlikely to become unfull
and neither the caller or kmem_malloc() can know what to do to unfill it.

Bruce

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

Re: KLD naming

[Mike Smith]

[KLD module file locations]

> I was just pointing out that having things in subdirectories
> is better than having a zillion files piled into a single directory.

I'm torn between agreeing that it's tidier and disagreeing on the 
grounds that it's much more of a pain to administer.  "Where is that 
damnned module?" "Why am I loading a stale version of saver_foo?", etc.

As a rule when I'm thinking about KLDs I look at the way that MacOS
manages inits/extensions.  That's a model that's survived over a decade
of use by generally fairly clueless users, and hasn't completely
irritated the smarter ones either.

> > are bad (witness the need to reorganise the kernel source tree).
> 
> Maybe I'm just an optimist.. but if we have already solved (through
> various incarnations) how to classify the kernel source, then we can
> pretty much inherit this same classification scheme for the modules.

The fact that we're trying to reorganise the kernel sources right now 
tends to indicate to me that we haven't solved this at all.

> > A single directory holding module files.
> 
> Blech :-)

Put aside the aesthetics for a moment, and try to raise some real, 
practical objections.  I'm continually battling my own temptation to 
make the whole module thing more complex, but if you've got really good 
reasons that can justify the extra complexity everywhere I'm still open 
to suggestions.

-- 
\\  Sometimes you're ahead,   \\  Mike Smith
\\  sometimes you're behind.  \\  m...@smith.net.au
\\  The race is long, and in the  \\  msm...@freebsd.org
\\  end it's only with yourself.  \\  msm...@cdrom.com



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

Re: Truth to M_WAITOK?

[Mike Smith]

> Would someone PLEASE tell us all if malloc can really return NULL now with
> flags & M_WAITOK?  I've gotten contradictory answers...

I went back and looked at the code again.

It looks like M_WAITOK will either return non-NULL or panic; it 
shouldn't be capable of returning NULL.  Ideally, it shouldn't panic 
either (why is it only that M_WAITOK can panic, and M_NOWAIT can't?).


-- 
\\  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

Truth to M_WAITOK?

[Brian Feldman]

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

New tag for -STABLE?

[oZZ!!!]

Hello!
What is new tag for -STABLE?
RELENG_3_1 ?

Rgdz,
Осокин Сергей aka oZZ,
o...@etrust.ru


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

Re: /etc/nsswitch.conf

[Chris Csanady]

>I noticed that NetBSD is switching over to using /etc/nsswitch.conf (like
>Slowlaris, PH-UX, etc.). Would it be a good idea to do this for FreeBSD too
>(when I first started using FreeBSD, it took me a long time to figure out the
>analogous file for hostname lookups was /etc/host.conf) -- it seems
>consolidating all that config information would in one place would be a good
>thing.

I would really like to see this integrated into FreeBSD.  Does anyone have
any plans to do this?  It would be really nice to be able to do lookups
using hesiod or perhaps even LDAP.

Btw, has anyone looked at nsd in Irix6.5?  It is quite interesting..

Chris




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

Re: KLD naming

[Archie Cobbs]

Mike Smith writes:
> > > When I first started writing KLD, I had a vague notion that there would be
> > > a simple directory structure under /modules, e.g.:
> > > 
> > >   /modules
> > >   pci/
> > >   ncr.ko
> > >   ...
> > >   isa/
> > >   if_ed.ko
> > >   ...
> > >   ...
> > 
> > I like this idea (subdirectories) better.. it will last longer :-)
> 
> It's a really bad idea, because it requires you to classify things.  It 
> also makes it much harder to administer.  In addition, classifications 
> are bad (witness the need to reorganise the kernel source tree).
> 
> > You should then be able to load a module "isa/if_ed.ko" etc
> > and have it work (no leading slash).
> 
> And here is a good example.  Why would you want to put if_ed in the 
> "ISA" category when it can be attached to both the PCI and ISA busses?

I don't care how you classify it.. of course the "isa" category is wrong.

I was just pointing out that having things in subdirectories
is better than having a zillion files piled into a single directory.

> are bad (witness the need to reorganise the kernel source tree).

Maybe I'm just an optimist.. but if we have already solved (through
various incarnations) how to classify the kernel source, then we can
pretty much inherit this same classification scheme for the modules.

After all, they are all *kernel* modules, right?

> A single directory holding module files.

Blech :-)

-Archie

___
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com

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

Re: Booting -current with new loader

[Mike Smith]

> I'm not sure about anybody else here, but to my mind a "Winblows on C:
> drive and let's try out FreeBSD on the second disk" configuration should
> really be supported seamlessly. 

You're more than welcome to propose a technical solution that solves 
the problem.

> The option of putting the second drive
> as slave on the primary interface would work, however anybody that knows
> anything about IDE (read somebdy interested in trying FreeBSD) would put
> it on the second interface for speed reasons.

Er, you want to stop and think about that for a second?  If you have 
Windows on one disk and FreeBSD on the other, where is the opportiunity 
for drive conflicts (the source of performance loss)?

You'd be much better off with both disks on the primary controller and 
your CDROM on the secondary controller if you cared about performance.

-- 
\\  Sometimes you're ahead,   \\  Mike Smith
\\  sometimes you're behind.  \\  m...@smith.net.au
\\  The race is long, and in the  \\  msm...@freebsd.org
\\  end it's only with yourself.  \\  msm...@cdrom.com



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

Re: panic: vinvalbuf: dirty bufs (during reboot, several times)

[Matthew Dillon]

(This is mainly for Luoqi, John, or David, or anyone who understands
struct buf's and NFS).

I see some other weirdness in bread() relating to NFS as well. 

int
bread(struct vnode * vp, daddr_t blkno, int size, struct ucred * cred,
struct buf ** bpp)
{
struct buf *bp;

bp = getblk(vp, blkno, size, 0, 0);
*bpp = bp;

/* if not found in cache, do some I/O */
if ((bp->b_flags & B_CACHE) == 0) {
if (curproc != NULL)
curproc->p_stats->p_ru.ru_inblock++;
bp->b_flags |= B_READ;
bp->b_flags &= ~(B_DONE | B_ERROR | B_INVAL);
if (bp->b_rcred == NOCRED) {
if (cred != NOCRED)
crhold(cred);
bp->b_rcred = cred;
}
vfs_busy_pages(bp, 0);
VOP_STRATEGY(vp, bp);
return (biowait(bp));
}
return (0);
}

The question is:  Do we have to check for B_DELWRI here and flush the bp
before we issue the read op?

-Matt


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

Re: KLD naming

[Mike Smith]

> > When I first started writing KLD, I had a vague notion that there would be
> > a simple directory structure under /modules, e.g.:
> > 
> > /modules
> > pci/
> > ncr.ko
> > ...
> > isa/
> > if_ed.ko
> > ...
> > ...
> 
> I like this idea (subdirectories) better.. it will last longer :-)

It's a really bad idea, because it requires you to classify things.  It 
also makes it much harder to administer.  In addition, classifications 
are bad (witness the need to reorganise the kernel source tree).

> You should then be able to load a module "isa/if_ed.ko" etc
> and have it work (no leading slash).

And here is a good example.  Why would you want to put if_ed in the 
"ISA" category when it can be attached to both the PCI and ISA busses?

> In fact, we can implement this (maybe it already works) before
> coming to a final decision on what the actual layout should be.

A single directory holding module files.

-- 
\\  Sometimes you're ahead,   \\  Mike Smith
\\  sometimes you're behind.  \\  m...@smith.net.au
\\  The race is long, and in the  \\  msm...@freebsd.org
\\  end it's only with yourself.  \\  msm...@cdrom.com



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

Re: panic: vinvalbuf: dirty bufs (during reboot, several times)

[Matthew Dillon]

Try this.  In nfs_bioread(), nfs/nfs_bio.c:

Before, it was:

if (getpages && !(bp->b_flags & B_VMIO)) {
#ifdef DIAGNOSTIC
printf("nfs_bioread: non vmio buf found, discarding\n");


Try changin the if() to this:

if (
(getpages && !(bp->b_flags & B_VMIO)) ||
(bp->b_flags & (B_CACHE|B_DELWRI)) == B_DELWRI
) {
#ifdef DIAGNOSTIC
printf("nfs_bioread: non vmio buf found, discarding\n");
#endif

I believe what is going on is that bioread() is misinterpreting B_CACHE
to mean that it can discard the entire buffer.  If B_DELWRI is set,
however, it must sync the buffer first.

What is occuring is that when a program write()'s non-contiguously and
then lseek's back and read()'s again, B_CACHE is getting cleared and the
buffer is being re-read from NFS without first being flushed to NFS,
causing the written data to be overwritten by the read.

I have NOT tested this well.  It seems to solve the vi SEG fault problem.

-Matt

Matthew Dillon 



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

Re: panic: vinvalbuf: dirty bufs (during reboot, several times)

[Matthew Dillon]

:ok, here are some instructions which -- I hope -- reproduce it
:(I haven't found a *nice* way; this is the ridiculous way):
:
:NFS server and client are completely 3.0-CURRENT
:(of CTM src-cur.3712.gz) with Luoqi's NFS fix. The server has all
:(physical) file systems mounted with softupdates except `/'.
:
:On the client simply edit `http://www.freebsd.org/~yokota/sc_update.txt'
:...
:After the vi-SEGV try to shutdown the server with `shutdown -[rh] now'.
:You may shutdown the client first -- it makes no difference.
:Then you will get the panic.
:
:Good luck.
:
:  Bjoern

Good work!  I can repeat the SEGV fault.  The SEGV is being caused by
a bug in NFS which I haven't tracked down yet, but basically what
happens is that vi tries to create a recovery file and uses lseek()
to skip around a little, then seek's back and reads something it
just wrote.

Over NFS, this blew up -- it didn't read what it wrote.

cc x.c -o x
cd somewhere ( into NFS partition on NFS client )
./x | hexdump
cd localfilesystem
/path/x | hexdump

I do not know if this related to the non-NFS panic.  When I find the bug,
we'll know better.  This should be easy.

-Matt

#include 
#include 
#include 
#include 

char buf[4096];

int
main(int ac, char **av)
{
int fd = open("test", O_RDWR|O_CREAT|O_TRUNC, 0666);
int n;

memset(buf, 1, 4096);
write(fd, buf, 1024);
lseek(fd, 0x800, 0);
write(fd, buf, 1024);
lseek(fd, 0xC00, 0);
write(fd, buf, 1024);
lseek(fd, 0x1000, 0);
write(fd, buf, 1024);
lseek(fd, 0x1400, 0);
write(fd, buf, 1024);
lseek(fd, 0x1800, 0);
write(fd, buf, 1024);
lseek(fd, 0x800, 0);
read(fd, buf, 1024);
write(1, buf, 1024);

return(0);
}


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

Re: HEADS UP: another syscons update

[John Hay]

> > 
> > > Is "make clean" really necessary?  A "make depend" ought to be
> > > sufficient, I would think.
> > 
> > I think that's an attempt to protect people who've upgraded from STABLE
> > and haven't gotten used to ``config -r''?
> 
> config -r?  I'd be highly suprised if this was needed at all for 99% of the
> time.  The only time that I've been aware of it being needed was quite some
> time ago when there was an option that got removed - if people were using 
> it, that option wouldn't get cleaned out from the .h files, and it caused 
> a problem somewhere.  I don't remember the specifics, it was a long time 
> ago.  The only other time I can think of where this might be needed is 
> when the system clock gets screwed and the *.h files get future dates on 
> them.  In just about all other cases, a 'make clean' is sufficient to 
> start the tree from scratch if there are any suspicions about old files.  

The place where it really bytes is when options move from one *.h to
another. Especially if you then change it. :-) I wish config would
remove old options out of *.h files.

John
-- 
John Hay -- john@mikom.csir.co.za

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

Re: panic: vinvalbuf: dirty bufs (during reboot, several times)

[Andreas Klemm]

On Tue, Jan 19, 1999 at 11:00:55PM -0800, Matthew Dillon wrote:
> 
> Hmm.  Interesting, it's dying trying to fsync an FFS vnode.   Are you
> by any chance running NFS ( client *or* server ) on this box?

No, no NFS compiled in and am not using it. See my kernel config.

> First, if either of you are compiling up your own kernels, please
> remember that if you are using SOFTUPDATES, the SOFTUPDATES code
> does *NOT* reside in /usr/src/sys but instead resides in 
> /usr/src/contrib/sys ... when you update your kernel, also make sure
> that /usr/src/contrib/sys is updated.

I know this, but checked it to be sure,
yes I use the 'up to date' softupdate source from contrib/sys.

 *  from: @(#)ffs_softdep.c 9.28 (McKusick) 8/8/98
 *  $Id: ffs_softdep.c,v 1.20 1999/01/07 16:14:10 bde Exp $

 *  @(#)softdep.h   9.5 (McKusick) 2/11/98
 *  $Id: softdep.h,v 1.4 1998/05/19 23:07:25 julian Exp $   

> If I can reproduce it on one of my machines, I can probably figure out
> what is going on.  If both of you are running NFS, it could possibly be
> the NFS server forgetting to unbusy a page somewhere.  If you aren't
> running NFS, it could be an actual bug in FFS somewhere(!).

No NFS.

-- 
Andreas Klemmhttp://www.FreeBSD.ORG/~andreas
 What gives you 90% more speed, for example, in kernel compilation ?
  http://www.FreeBSD.ORG/~fsmp/SMP/akgraph-a/graph1.html
 "NT = Not Today" (Maggie Biggs)  ``powered by FreeBSD SMP''

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

Cosmetic issues with ISDN startup

[Blaz Zupan]

I am experiencing two rather cosmetic issues with how the ISDN subsystem
starts up. The first is, that when you enable isdnd, syslogd is not yet
running. So isdnd outputs a whole lot of garbage (basically the whole
configuration) to the console.

This patch to /usr/src/usr.sbin/i4b/isdnd/log.c solves the mess:

*** log.c.old   Sun Dec 27 22:47:01 1998
--- log.c   Wed Jan 20 18:57:08 1999
***
*** 100,106 
logfacility);
else
  #endif
!   (void)openlog("isdnd", LOG_PID|LOG_CONS|LOG_NDELAY,
logfacility);
}
  
--- 100,106 
logfacility);
else
  #endif
!   (void)openlog("isdnd", LOG_PID|LOG_NDELAY,
logfacility);
}
  
I really don't believe the messages are urgent enough to warrant LOG_CONS,
considering that named doesn't openlog() with LOG_CONS either.

The next issue is in /etc/rc.network. When you solve the above mess, you
get this during startup:

Doing initial network setup: hostname.
 isdnd
... [rest of messages]

I belive the isdnd should be output on the previous line, this patches
fixes it:

*** rc.network.old  Thu Jan 14 00:18:07 1999
--- rc.network  Wed Jan 20 19:20:28 1999
***
*** 23,39 
domainname $nisdomainname
echo -n ' domain'
  fi
  echo '.'
  
  # Initial ATM interface configuration
  if [ "X${atm_enable}" = X"YES" -a -f /etc/rc.atm ]; then
. /etc/rc.atm
atm_pass1
- fi
- 
- # ISDN subsystem startup
- if [ "X${isdn_enable}" = X"YES" -a -f /etc/rc.isdn ]; then
-   . /etc/rc.isdn
  fi
  
  # Special options for sppp(4) interfaces go here.  These need
--- 23,40 
domainname $nisdomainname
echo -n ' domain'
  fi
+ 
+ # ISDN subsystem startup
+ if [ "X${isdn_enable}" = X"YES" -a -f /etc/rc.isdn ]; then
+   . /etc/rc.isdn
+ fi
+ 
  echo '.'
  
  # Initial ATM interface configuration
  if [ "X${atm_enable}" = X"YES" -a -f /etc/rc.atm ]; then
. /etc/rc.atm
atm_pass1
  fi
  
  # Special options for sppp(4) interfaces go here.  These need

Best regards,

Blaz Zupan, b...@medinet.si, http://home.amis.net/blaz
Medinet d.o.o., Linhartova 21, 2000 Maribor, Slovenia


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

Re: /etc/nsswitch.conf

[Chris Tubutis]

Dag-Erling Smorgrav wrote:
> 
> Mike Nguyen  writes:
> > I noticed that NetBSD is switching over to using /etc/nsswitch.conf (like
> > Slowlaris, PH-UX, etc.). Would it be a good idea to do this for FreeBSD too
> > (when I first started using FreeBSD, it took me a long time to figure out 
> > the
> > analogous file for hostname lookups was /etc/host.conf) -- it seems
> > consolidating all that config information would in one place would be a good
> > thing.
> 
> When I first started using Solaris, it took me a long time to figure
> out the analoguous file for hostname setup was /etc/nodename. It seems
> consolidating all that config information in one place, such as
> /etc/rc.conf, would be a good thing.


I agree; I deal with Solaris, Linux and FreeBSD every day.  This may sound
pretty Redmondish, but imho the more that things are the same, the better.

ct

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

Re: HEADS UP: another syscons update

[Sheldon Hearn]

On Thu, 21 Jan 1999 01:03:21 +0800, Peter Wemm wrote:

> The first machine has been doing 'config -n' since 1996

Don't get me wrong, config _usually_ works for us without ``-r''. But we
got bitten once or twice and have since opted for ``config -r'', since
that's what fixed things for us when we had trouble.

> Are you sure you're doing a 'make depend' after each config(8) run and
> after building for the first time after a cvsup run or cvs update?

Dead sure. That's a habit we got into with STABLE, even.

Ciao,
Sheldon.

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

Re: Directory structure on current.freebsd.org

[Wilko Bulte]

As p...@originative.co.uk wrote...
> > -Original Message-
> > From: Peter Jeremy [mailto:peter.jer...@auss2.alcatel.com.au]
> > Sent: Wednesday, January 20, 1999 6:21 AM
> > To: freebsd-current@FreeBSD.ORG
> > Subject: Re: Directory structure on current.freebsd.org
> > 
> > 
> > Oliver Fromme  wrote:
> > >In releases/snapshots they're called "axp" and "x86", while in
> > >ports they're called "alpha" and "i386".
> > 
> > I agree that having two different names is confusing.
> > 
> > DEC (or Compaq) literature seems to use both Alpha and AXP - I'm not
> > sure that either is an especially better choice.

Officially it is Alpha AXP. Alpha was too generic to be trademarked.

> > I personally find "i386" a pain because it is used to specify both an
> > architecture (IA-32) and a particular implementation (80386) of that
> > architecture.  In some cases it may not be clear which is meant.
> 
> I think the architecture names are more appropriate than any cpu related
> name. For the alpha, while we might all use alpha in everyday speech axp
> is more specific when it comes to releases since the alpha release of

Hear hear ;-)

> the alpha code can get a tad confusing, I think that's why it was
> changed in the first place. It'd be nice if i386 could become IA32 but
> it probably won't happen.

Wilko
_ __
 |   / o / /  _  Bulteemail: wi...@yedi.iaf.nl 
 |/|/ / / /( (_) Arnhem, The Netherlands  WWW  : http://www.tcja.nl
__ Powered by FreeBSD __

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

Re: HEADS UP: another syscons update

[Peter Wemm]

Sheldon Hearn wrote:
> 
> 
> On Thu, 21 Jan 1999 00:29:54 +0800, Peter Wemm wrote:
> 
> > 'make depend' really does work, and is quite safe.  Cleaning the tree 
> > should be a very rare requirement.
> 
> Perhaps the chap sitting next to me and I are just unlucky. Between the
> two of us, we've needed to use ``config -r'' three times since moving
> over to CURRENT about two weeks ago. What I pity we didn't save
> typescripts for the failures this corrected. :(

It's worked a few times in a row for me; some samples:
FreeBSD 3.0-CURRENT #384: Sat Jan 16 17:23:36 WST 1999
FreeBSD 3.0-CURRENT #111: Sat Jan 16 14:39:22 WST 1999
FreeBSD 3.0-CURRENT #265: Wed Jan 20 06:02:36 WST 1999
FreeBSD 3.0-CURRENT #61: Mon Jan 18 19:33:08 WST 1999

The first machine has been doing 'config -n' since 1996, with (when 
necessary) a make clean.  It was doing early SMP development which tended 
to have some scarey consequences on filesystems at times. :-]

Are you sure you're doing a 'make depend' after each config(8) run and
after building for the first time after a cvsup run or cvs update? Yes, a
'make depend' is required whenever the sources change any of their include
files.

> Ciao,
> Sheldon.

Cheers,
-Peter
--
Peter WemmNetplex Consulting
"No coffee, No workee!" :-)



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

Re: /etc/nsswitch.conf

[Dag-Erling Smorgrav]

Mike Nguyen  writes:
> I noticed that NetBSD is switching over to using /etc/nsswitch.conf (like
> Slowlaris, PH-UX, etc.). Would it be a good idea to do this for FreeBSD too
> (when I first started using FreeBSD, it took me a long time to figure out the
> analogous file for hostname lookups was /etc/host.conf) -- it seems
> consolidating all that config information would in one place would be a good
> thing.

When I first started using Solaris, it took me a long time to figure
out the analoguous file for hostname setup was /etc/nodename. It seems
consolidating all that config information in one place, such as
/etc/rc.conf, would be a good thing.

YMMV.

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

Re: HEADS UP: another syscons update

[Dag-Erling Smorgrav]

Peter Wemm  writes:
> config -r?  I'd be highly suprised if this was needed at all for 99% of the
> time.  The only time that I've been aware of it being needed was quite some
> time ago when there was an option that got removed - if people were using 
> it, that option wouldn't get cleaned out from the .h files, and it caused 
> a problem somewhere.

Old-style options weren't placed in .h files, but passed on the
command line, so they broke the dependency system. Perhaps that is
what you are referring to?

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

Re: HEADS UP: another syscons update

[Sheldon Hearn]

On Thu, 21 Jan 1999 00:29:54 +0800, Peter Wemm wrote:

> 'make depend' really does work, and is quite safe.  Cleaning the tree 
> should be a very rare requirement.

Perhaps the chap sitting next to me and I are just unlucky. Between the
two of us, we've needed to use ``config -r'' three times since moving
over to CURRENT about two weeks ago. What I pity we didn't save
typescripts for the failures this corrected. :(

Ciao,
Sheldon.

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

Re: HEADS UP: another syscons update

[Peter Wemm]

Sheldon Hearn wrote:
> 
> 
> On Wed, 20 Jan 1999 07:21:23 PST, John Polstra wrote:
> 
> > Is "make clean" really necessary?  A "make depend" ought to be
> > sufficient, I would think.
> 
> I think that's an attempt to protect people who've upgraded from STABLE
> and haven't gotten used to ``config -r''?

config -r?  I'd be highly suprised if this was needed at all for 99% of the
time.  The only time that I've been aware of it being needed was quite some
time ago when there was an option that got removed - if people were using 
it, that option wouldn't get cleaned out from the .h files, and it caused 
a problem somewhere.  I don't remember the specifics, it was a long time 
ago.  The only other time I can think of where this might be needed is 
when the system clock gets screwed and the *.h files get future dates on 
them.  In just about all other cases, a 'make clean' is sufficient to 
start the tree from scratch if there are any suspicions about old files.  

'make depend' really does work, and is quite safe.  Cleaning the tree 
should be a very rare requirement.

> Ciao,
> Sheldon.

Cheers,
-Peter



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

Re: HEADS UP: another syscons update

[Sheldon Hearn]

On Wed, 20 Jan 1999 07:21:23 PST, John Polstra wrote:

> Is "make clean" really necessary?  A "make depend" ought to be
> sufficient, I would think.

I think that's an attempt to protect people who've upgraded from STABLE
and haven't gotten used to ``config -r''?

Ciao,
Sheldon.

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

Re: HEADS UP: another syscons update

[John Polstra]

In article <199901191140.uaa23...@zodiac.mech.utsunomiya-u.ac.jp>,
Kazutaka YOKOTA   wrote:
> I have committed another syscons update.
> 
> Because one new file has been added to the source tree, and one file
> has changed location, I have to ask you to run config() before you
> compile the kernel next time, and "make clean depend all" in your
> kernel compile directory.

Is "make clean" really necessary?  A "make depend" ought to be
sufficient, I would think.

John
-- 
  John Polstra   j...@polstra.com
  John D. Polstra & Co., Inc.Seattle, Washington USA
  "Nobody ever went broke underestimating the taste of the American public."
-- H. L. Mencken

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

/etc/nsswitch.conf

[Mike Nguyen]

I noticed that NetBSD is switching over to using /etc/nsswitch.conf (like
Slowlaris, PH-UX, etc.). Would it be a good idea to do this for FreeBSD too
(when I first started using FreeBSD, it took me a long time to figure out the
analogous file for hostname lookups was /etc/host.conf) -- it seems
consolidating all that config information would in one place would be a good
thing.

Mike.

---
Mike Nguyen  - UNIX Sysadmin and Geek
  Pager (800) SKY- pin# 1138368
 or 1138...@skytel.com

Abandon the search for Truth; settle for a good fantasy.


---

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

Re: Booting -current with new loader

[John Saunders]

> The next option is configuring my master drive on the secondary interface
> as wd1 instead of wd2.

This works fine. I guess the real solution is to make the IDE disk scan
the same as we do for SCSI, which also happens to be the same as the
BIOS does. We possible need a config syntax like

controler wdc0 ...
controler wdc1 ...
devicewd? ay wdc?

This will automatically assign numbers to drives as it finds them.
Actually I tried this syntax which config accepted OK, however no
drives got detected.

Anyway for me at least a kernel config file tweak got me booting with
spash screens. If you want my system to be a test bed for any mods,
please let me know.

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.   |
  ++

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

Re: panic: vinvalbuf: dirty bufs (during reboot, several times)

[Bjoern Fischer]

On Tue, Jan 19, 1999 at 11:00:55PM -0800, Matthew Dillon wrote:
[...]
> ::But there's still something wrong: When shutting down the server
> ::it still sometimes panics in vinvalbuf() complaining 'bout dirty
> ::pages. On the client side vi dies of SEGV (edited file and
> ::/var/tmp/vi.recover on nfs fs) generating a wrong sized recover
> ::file. After that the server panics on shutdown. Without triggering
> ::the bug it shuts down gracefully.
> ::
> ::I'll try to receipe a situation for easily reproducing this.
> ::
> ::  Bjoern
> 
[...]
> With that out of the way, if the vinvalbuf() problem still occurs
> our best bet is if Bjoern can give us a repeatable vi SEGV / shutdown
> sequence that results in the panic.
> 
> If I can reproduce it on one of my machines, I can probably figure out
> what is going on.  If both of you are running NFS, it could possibly be
> the NFS server forgetting to unbusy a page somewhere.  If you aren't
> running NFS, it could be an actual bug in FFS somewhere(!).

ok, here are some instructions which -- I hope -- reproduce it
(I haven't found a *nice* way; this is the ridiculous way):

NFS server and client are completely 3.0-CURRENT
(of CTM src-cur.3712.gz) with Luoqi's NFS fix. The server has all
(physical) file systems mounted with softupdates except `/'.

On the client simply edit `http://www.freebsd.org/~yokota/sc_update.txt'
(hey, don't laugh. Other files won't do it. Not even files with the
same size.) with FreeBSD vanilla vi (nvi). `sc_update.txt' is also
attached to this mail if the file in it's original location had been
changed recently. vi doesn't start normally, but skrews up and gets
into an uninterruptible state. Trying to kill the beast makes it SEGV.
(Of course everything is pretty normal when viing on the server.)

The file system which contains the file and the one which contains
/var/tmp/vi.recover are NFS ver2,udp,hard (although ver3,tcp/udp
should work^H^H^H^Hfail, too). They don't need to be separate mounts.

After the vi-SEGV try to shutdown the server with `shutdown -[rh] now'.
You may shutdown the client first -- it makes no difference.
Then you will get the panic.

Good luck.

  Bjoern

-- 
(sig_t*)NULL
Last update: 12 January 1999.
Kazutaka YOKOTA
yok...@freebsd.org
---
I) Syscons Update
II) Splash Screen
III) Splash Screen/Screen Saver FAQ

---
I) Syscons Update

Major update for the console driver started on 10 January.  New
keyboard and video card drivers have been introduced

(This is just the begining.  There will be more updates to follow in
the next few months.)

Because of these changes, you must update several things in your
-current system.

1. You are required to update your kernel configuration file.

If you are using syscons, 

controller  atkbdc0 at isa? port IO_KBD tty
device  atkbd0  at isa? tty irq 1
#device psm0at isa? tty irq 12
device  vga0at isa? port ? conflicts
device  sc0 at isa? tty

pseudo-device   splash

Note that `splash' is required if you intend to use screen savers or
splash screen.

!!IMPORTANT!!
Due to sloppy programming of mine, the pseudo-device splash is ALWAYS
needed for the syscons driver at the moment.  The problem will be
fixed soon .(12 Jan. 99)

If you are pcvt user,

controller  atkbdc0 at isa? port IO_KBD tty
device  atkbd0  at isa? tty irq 1
#device psm0at isa? tty irq 12
device  vt0 at isa? tty

2. The following options for syscons are replaced by new ones.

SC_ALT_SEQACCESS->  VGA_ALT_SEQACCESS
SLOW_VGA->  VGA_SLOW_IOACCESS

3. The following flags for syscons are no longer available.

0x08Force detection of keyboard.
0x10Old-style (XT) keyboard support.
0x20Don't reset keyboard.

Use corresponding new flags for atkbd instead.

0x01Don't install the keyboard driver if no keyboard is found,
else we always assume a keyboard.
0x02Don't reset keyboard.
0x04XT keyboard support.

4. You must recompile screen saver modules and the vesa module in
/sys/modules, as well as kbdcontrol and vidcontrol in
/usr/src/usr.sbin.

If you regularly do `make world', you will be in good shape.  If you
don't do it often, this may be a good opportunity.


II) Splash Screen

A splash screen module has been added. See /sys/modules/splash.

This version has rather limited capabilities: it can handle W*ndows
256 color BMP file only (other color depth probably won't work); the
size of the image must be 320x200 or less.

In order to see splash image when your kernel loads, do the following:

Make sure the following line is added to your kernel configuration
file and rebuild a new kernel.

 pseudo-device splash

Copy your favorite W*ndows BMP file to somewhere the boot loader can
see.

When the boot loader starts, load kernel, splash imag

src/games turds after make buildworld

[Sheldon Hearn]

Hi folks,

I'm finding turds in src/games/{advanture,hack,phantasia}/ and would
like to prevent buildworld from producing them.

Looks to me as though the turds are produced by a broken build-tools
rule in their Makefiles.

Anyone know wtf these games contribute to buildworld's bootstrapping?
:-)

Thanks,
Sheldon.

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

Re: KLD naming

[Jeroen C. van Gelderen]

From: Archie Cobbs 

>Doug Rabson writes:
>> > Might it be a good idea to choose a consistent naming scheme for the
>> > modules? I'd think so because it would help blind loading at the boot
>> > prompt. If you choose names it the following format:
>> >
>> > type_name
>> > saver_warp
>> > saver_daemon
>> >
>> > the modules of one type will sort together in a directory listing. This
is a
>> > change that will make FreeBSD more user friendly I think.
>>
>> When I first started writing KLD, I had a vague notion that there would
be
>> a simple directory structure under /modules, e.g.:
>>
>> /modules
>> pci/
>> ncr.ko
>> ...
>> isa/
>> if_ed.ko
>> ...
>> ...
>
>I like this idea (subdirectories) better.. it will last longer :-)
>Witness the explosion of the ports tree.

I witnessed. But I don't think we will be heading that way. Even if you have
40 modules in each category, this ought to work (ls saver*). It will work
because we prefix every driver with it's type so they sort together. This
would have worked for the ports tree as well.

Another advantage of the flat model is that it's way easier to browse. IMHO
it's a real pain to have descend into subdirectories, only to find out that
you want to look in another one.

Cheers,
Jeroen
--
Jeroen C. van Gelderen -- gelde...@mediaport.org -- 0x46D8D3C8 -- &[8-D}~<=


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

RE: KLD naming

[paul]

> -Original Message-
> From: Archie Cobbs [mailto:arc...@whistle.com]
> Sent: Wednesday, January 20, 1999 6:13 AM
> To: d...@nlsystems.com
> Cc: gelde...@mediaport.org; curr...@freebsd.org
> Subject: Re: KLD naming
> 
> 
> Doug Rabson writes:
> > > Might it be a good idea to choose a consistent naming 
> scheme for the
> > > modules? I'd think so because it would help blind loading 
> at the boot
> > > prompt. If you choose names it the following format:
> > > 
> > > type_name
> > > saver_warp
> > > saver_daemon
> > > 
> > > the modules of one type will sort together in a directory 
> listing. This is a
> > > change that will make FreeBSD more user friendly I think.
> > 
> > When I first started writing KLD, I had a vague notion that 
> there would be
> > a simple directory structure under /modules, e.g.:
> > 
> > /modules
> > pci/
> > ncr.ko
> > ...
> > isa/
> > if_ed.ko
> > ...
> > ...
> 
> I like this idea (subdirectories) better.. it will last longer :-)
> Witness the explosion of the ports tree.
> 
> You should then be able to load a module "isa/if_ed.ko" etc
> and have it work (no leading slash).

I don't think subdirectories based on bus type is a good idea, it
doesn't really fit the granularity we're probably heading towards. Some
thinks don't really fit at all, filesystems, screen savers etc and even
for drivers we're heading towards less bus specific devices so an
ethernet driver, say, would be the same for any bus, only the startup
code would be different and possibly(probably) in a different module.

A functional structure is probably better

/modules
/devices
/ethernet
/storage
/display
/network
/filesystems
/screensavers


etc.

Not a specific proposal for actual directories but perhaps a better
direction. I think we should start thinking more in terms of function,
rather than bus, in a lot of what we do with devices as we abstract out
the bus code more effectively.

Paul.

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

Re: PPP data-dependent bug

[Brian Somers]

> 
> FYI, when I rcp (actually, rsync) a certain makefile (ppp -alias), I
> get lots of these, and it never completes:
> 
> Warning: CCP: deflink: Incorrect ResetAck (id 49, not 50) ignored
> Warning: CCP: deflink: Incorrect ResetAck (id 49, not 50) ignored
> Warning: CCP: deflink: Unexpected ResetAck (id 51) ignored
> Warning: CCP: deflink: Unexpected ResetAck (id 55) ignored
> Warning: CCP: deflink: Unexpected ResetAck (id 55) ignored

Dare I say ``you're talking to a lousy CCP/FSM implementation'' ?  
(your response:  It's also user-ppp).

Unfortunately, there aren't any interesting logs that mention the 
ResetReq - just logs that mention the reason behind it :-(  If you're 
using user-ppp on the other end, you could have a look at the CCP 
logs there and try to match up the FSM IDs (the bit in parenthesis 
after the {Send,Recv}ResetReq messages).

You're proabably better off using hardware compression here - if the 
peer can't get a reset right.

-- 
Brian   
  
Don't _EVER_ lose your sense of humour !




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

RE: Directory structure on current.freebsd.org

[paul]

> -Original Message-
> From: Peter Jeremy [mailto:peter.jer...@auss2.alcatel.com.au]
> Sent: Wednesday, January 20, 1999 6:21 AM
> To: freebsd-current@FreeBSD.ORG
> Subject: Re: Directory structure on current.freebsd.org
> 
> 
> Oliver Fromme  wrote:
> >In releases/snapshots they're called "axp" and "x86", while in
> >ports they're called "alpha" and "i386".
> 
> I agree that having two different names is confusing.
> 
> DEC (or Compaq) literature seems to use both Alpha and AXP - I'm not
> sure that either is an especially better choice.
> 
> > "x86" could imply that we're
> >running on 286, too, and it's more in line with "sparc64"),
> 
> I personally find "i386" a pain because it is used to specify both an
> architecture (IA-32) and a particular implementation (80386) of that
> architecture.  In some cases it may not be clear which is meant.

I think the architecture names are more appropriate than any cpu related
name. For the alpha, while we might all use alpha in everyday speech axp
is more specific when it comes to releases since the alpha release of
the alpha code can get a tad confusing, I think that's why it was
changed in the first place. It'd be nice if i386 could become IA32 but
it probably won't happen.

Paul.

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

Re: dual boot problems

[Robert Nordier]

David Green-Seed wrote:
 
> Here's my problem:
> 
> at 10:21pm PST (Jan 19th 1998) I cvsupped world, rebuilt, installed the new
> boot blocks, and did a first-time install of an ELF kernel.  Unfortunately,
> I'm
> dual-booting with windows 95 using fbsdboot.exe - which I just discovered
> does not work with an ELF kernel.
> 
> Has anyone encountered this problem (and what did you do to fix it) or does
> anyone have any suggestions (other than getting rid of windows 95)?  I've
> checked around - and the only thing that I can come up with is that NTLDR
> (the windows NT loader) will boot an elf FreeBSD using the new boot
> blocks...
> but I don't have NT.
> 
> Any help/suggestions would be much appreciated.

The fbsdboot.exe program should probably be considered obsolete.  It
should (in theory) be possible to use it to load /boot/loader, which
can then load the kernel, but there are various reasons this doesn't
work too well.

The standard approach would be to install the FreeBSD boot manager.
This displays a menu like

F1   DOS
F2   FreeBSD

every time the machine is rebooted.  So, whether in FreeBSD or
Windows, you'd reboot to switch OSes.

To install this, there's a utility at

http://www.freebsd.org/~rnordier/boot0inst-1.0.2.tar.gz

though you can also use sysinstall.

There are also various alternative boot managers, commercial and
otherwise.  System Commander from V-Communications seems fairly
popular: though I wouldn't personally pay a $100 list price for
this kind of thing.

--
Robert Nordier

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

dual boot problems

[David Green-Seed]

Here's my problem:

at 10:21pm PST (Jan 19th 1998) I cvsupped world, rebuilt, installed the new
boot blocks, and did a first-time install of an ELF kernel.  Unfortunately,
I'm
dual-booting with windows 95 using fbsdboot.exe - which I just discovered
does not work with an ELF kernel.

Has anyone encountered this problem (and what did you do to fix it) or does
anyone have any suggestions (other than getting rid of windows 95)?  I've
checked around - and the only thing that I can come up with is that NTLDR
(the windows NT loader) will boot an elf FreeBSD using the new boot
blocks...
but I don't have NT.

Any help/suggestions would be much appreciated.

David.

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