Re: pcic.c {,un}register_pcic_intr declarations

1999-03-13 Thread Mark Murray
Mike Smith wrote:
  I have card* compiled in (perhaps I should have mentioned that?), and
  pcic* kldloaded.
 
   This makes the pcic module useless, and, as I said, renders any 
   combination other than 100% static *broken*.
  
  Rubbish! Why is my system working?
 
 Because you have an horrific mishmash of bits; it's not meant to be 
 broken up as you have. 

If that is the case, then the documentation and people's ideas
differ dramatically from reality. As I said, I have a nicely
working Libretto here. The configs could be tidier, and more
of the kernel could be KLD, but it works almost as well as PAO
did 7 months ago, and this is -CURRENT :-).

  Any suggestions for a kernel neophyte on how to get stuck into 3)?
 
 Not really; you'd need to study how KLD currently works, then go back 
 over the discussions that Peter, Doug, I and others have had about how 
 we might identify modules within a file, and implement it.  I fear that 
 it will result in binary incompatability (again).

Fooey :-(. Smells like a kernel registry-of-loaded-bits is needed?

M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org


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



ERRATA NOTICE: FreeBSD 3.1-RELEASE

1999-03-13 Thread freebsd-errata-update

**
** THIS IS AN AUTOMATIC ERRATA UPDATE FOR FREEBSD 3.1-RELEASE **
**

You can retrieve the complete ERRATA from:

ftp://ftp.freebsd.org/pub/FreeBSD/3.1-RELEASE/ERRATA.TXT

The last update was sent: Mon Feb 15 17:42:32 1999
This update is sent:  Sat Mar 13 06:00:32 1999

--
 SYSTEM ERRATA INFORMATION:



o  Kernel change information is not saved in the new kernel, even
   though this is claimed to work in the docs.

Fix: The change information is being written out, in fact, but to the
 wrong location.  move /kernel.config to /boot/kernel.conf (if it
 exists, otherwise there were no changes to save) and add the
 following lines to /boot/loader.rc:

load /kernel
load -t userconfig_script /boot/kernel.conf
autoboot 5

 This will cause the kernel change information to be read in and
 used properly (and you just learned a little about the new 3-stage
 loader in the process, so the exercise wasn't a total loss).


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



Re: HEADS UP: new loader.rc stuff

1999-03-13 Thread Chuck Robey
On Wed, 10 Mar 1999, Daniel C. Sobral wrote:

 A new loader.rc mechanism has been introduced. Nothing has changed
 with loader, mind you, and you can continue to use your current
 loader.rc (if any) unchanged, but Jordan thinks it might be better
 to install a loader.rc using the new mechanism by default, to keep
 support easy, so things might change in the future...
 
 Meanwhile, the new loader.rc stuff, for those who want it. It is
 modeled after rc.conf files. We now have a
 /boot/defaults/loader.conf, with all defaults (meaning it hardly
 does anything, serving more as a template), which will also load
 /boot/loader.conf and /boot/loader.conf.local, in that order, if
 present.
 
 The idea is to leave /boot/loader.conf for sysinstall,
 /boot/loader.conf.local for the user, and /boot/defaults/loader.conf
 to installworld.

Daniel, I'm having a little trouble getting this to work.  I don't see
any kind of example loader.conf, or loader.conf.local,  I made the file
you asked, below (/boot/loader.rc) ... I didn't have a loader.conf, so
on boot, it issues me an error on that.  I have a new pnp sound card I
have working manually, by donig a boot -c, and issuing the command

pnp 1 0 os enable port0 0x534 port2 0x220 irq0 15 drq0 1 drq1 0

This very helpfully shows up in my dmesg, and I get sound, but I want to
have this done automatically on boot (no boot -c).  My kernel already is
correct, so I stuck that line into the otherwise empty
loader.conf.local, but it told me that I had a syntax error (on
encountering the first 1) and didn't get the configuration done.  I
checked very carefully, the loader.conf.local does have that exact pnp
line I showed.

It would help me if you had an example loader.conf and loader.conf.local
file hanging around ... and maybe an ls -lR /boot, so I'd know I had a
complete set of files.

Thanks.

 
 To use this, put the following lines in your /boot/loader.rc:
 
 include /boot/loader.4th
 start
 
 Then you can create a /boot/loader.conf.local with whatever other
 stuff you'd like, such as using a splash screen.
 
 Feedback, comments, musings and flames are welcome. (I'd
 particularly like a better name than start :)
 
 --
 Daniel C. Sobral  (8-DCS)
 d...@newsguy.com
 d...@freebsd.org
 
   FreeBSD is Yoda, Linux is Luke Skywalker.
 
 
 
 To Unsubscribe: send mail to majord...@freebsd.org
 with unsubscribe freebsd-current in the body of the message
 
 

+---
Chuck Robey | Interests include any kind of voice or data 
chu...@glue.umd.edu | communications topic, C programming, and Unix.
213 Lakeside Drive Apt T-1  |
Greenbelt, MD 20770 | I run picnic (FreeBSD-current)
(301) 220-2114  | and jaunt (Solaris7).
+---






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



Re: bmake/contrib framework for egcs

1999-03-13 Thread Vladimir Kushnir
Hello, here's where cpp died. There's a small error in freebsd.h:
INCLUDE_DEFAULTS array defined in a wrong way (patch attached). Now cpp
doesn't die anymore. There's an another problem, though. For somereason
libgcc doesn't want to compile with base c++ (conflict in new, it
seems). It does compile if COMPILER_PATH is set to uitilize a newly
compiled c++ and cc1plus, but it takes addition 
CFLAGS+=-I${GCCDIR}/cp/inc
to gnu/usr.bin/cc/Makefile.inc. Then everything builds indeed.

BTW, binaries compiled with egcc are still larger than with stock gcc. Is
there a way to shrink them (beyond what's possible with -O optimisation)?  

On Thu, 11 Mar 1999, David O'Brien wrote:

  How's this going?  
 
 Everything now builds, and I can pass the C++ STL tests supplied with
 EGCS.
 
 There is at least one case w/in gnu/usr.bin/cc that ``make cleandir 
 make cleandir  make obj  make depend  make  make clean  make''
 will file to build.  But I haven't worried too much about that yet.
 
 The biggest problem is that ``cpp'' will get a sig11 when executed by
 c++.  If I use ``c++ -v'' and manually execute what c++ is, I don't get
 the sig11.  I got tired of trying to track this down, so to get around
 this (so I could work on libstdc++), I copy ``cpp'' into /usr/libexec
 from a copy of an installed EGCS port.
 
 The version in my repository is EGCS 1.1.2-pre3.  Rumors have it that
 1.1.2 will released on Friday, and by Monday at the latest.

Regards,
Vladimir


===|===
 Vladimir Kushnir  |
 ku...@mail.kar.net,   |Powered by FreeBSD
 kush...@ap3.bitp.kiev.ua  |


*** freebsd.h.orig  Sat Mar 13 23:20:27 1999
--- freebsd.h   Wed Mar 10 23:22:32 1999
***
*** 259,267 
  #ifdef FREEBSD_NATIVE
  
  #define INCLUDE_DEFAULTS { \
!   { /usr/include, 0, 0 }, \
!   { /usr/include/g++, 1, 1 }, \
!   { 0, 0, 0} \
}
  
  #undef MD_EXEC_PREFIX
--- 259,267 
  #ifdef FREEBSD_NATIVE
  
  #define INCLUDE_DEFAULTS { \
!   { /usr/include, 0, 0, 0 }, \
!   { /usr/include/g++, G++, 1, 1 }, \
!   { 0, 0, 0, 0} \
}
  
  #undef MD_EXEC_PREFIX


Re: bmake/contrib framework for egcs

1999-03-13 Thread Alex Zepeda
On Sat, 13 Mar 1999, Vladimir Kushnir wrote:

 BTW, binaries compiled with egcc are still larger than with stock gcc. Is
 there a way to shrink them (beyond what's possible with -O optimisation)?  

Try -Os, -fno-exceptions* -fno-rtti* or any combo of the above.

* Don't do this with libraries, just in case you've got any programs that
use exceptions or rtti.  Obviously this won't work with programs that use
rtti and/or exceptions.

- alex



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



Re: bmake/contrib framework for egcs

1999-03-13 Thread Vladimir Kushnir
Thanks, I'll try, but what I mean is egcs compiled binaries are bigger
even for C, not C++, and as if memory serves -Os is -O2 subset. So 
probably I'll just have to accept this increase in binaries size :-(. Ah  
well, it ain't all that much, anyway.

Oh, incidentally, I forgot to add that (when compiling libstdc++ with new
c++ for the first time, it can't find file exception. So perhaps in
gnu/lib/libstdc++/Makefile this part of CFLAGS shoild be 
-I${EGCSDIR}/gcc/cp/inc rather than -I${EGCSDIR}/gcc/cp/inc/exception
(after all, ${EGCSDIR}/gcc/cp/inc/exception is a file).
  

On Sat, 13 Mar 1999, Alex Zepeda wrote:

 On Sat, 13 Mar 1999, Vladimir Kushnir wrote:
 
  BTW, binaries compiled with egcc are still larger than with stock gcc. Is
  there a way to shrink them (beyond what's possible with -O optimisation)?  
 
 Try -Os, -fno-exceptions* -fno-rtti* or any combo of the above.
 
 * Don't do this with libraries, just in case you've got any programs that
 use exceptions or rtti.  Obviously this won't work with programs that use
 rtti and/or exceptions.
 
 - alex
 

Regards,
Vladimir

===|===
 Vladimir Kushnir  |
 ku...@mail.kar.net,   |Powered by FreeBSD
 kush...@ap3.bitp.kiev.ua  |



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



Re: bmake/contrib framework for egcs

1999-03-13 Thread Alex Zepeda
On Sun, 14 Mar 1999, Vladimir Kushnir wrote:

 Thanks, I'll try, but what I mean is egcs compiled binaries are bigger
 even for C, not C++, and as if memory serves -Os is -O2 subset. So 
 probably I'll just have to accept this increase in binaries size :-(. Ah  
 well, it ain't all that much, anyway.

-Os is a subset of -O2, which enables everything that won't increase the
size of a binary.  However, I don't know about rtti, but IIRC exception
handling code (or perhaps stubs thereof) are included even in C code, just
incase.  Perhaps jdp can shed some more light on this (he's been a very
useful resource to me in the past).

 Oh, incidentally, I forgot to add that (when compiling libstdc++ with new
 c++ for the first time, it can't find file exception. So perhaps in
 gnu/lib/libstdc++/Makefile this part of CFLAGS shoild be 
 -I${EGCSDIR}/gcc/cp/inc rather than -I${EGCSDIR}/gcc/cp/inc/exception
 (after all, ${EGCSDIR}/gcc/cp/inc/exception is a file).

- alex



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



Re: HEADS UP: new loader.rc stuff

1999-03-13 Thread Daniel C. Sobral
Chuck Robey wrote:
 
 Daniel, I'm having a little trouble getting this to work.  I don't see
 any kind of example loader.conf, or loader.conf.local,  I made the file
 you asked, below (/boot/loader.rc) ... I didn't have a loader.conf, so
 on boot, it issues me an error on that.  I have a new pnp sound card I

...

 It would help me if you had an example loader.conf and loader.conf.local
 file hanging around ... and maybe an ls -lR /boot, so I'd know I had a
 complete set of files.

Well, first, this has been introduced only on -current at the
present time. I am in no hurry to mfc, because this thing has just
been introduced. I want the freedom to make drastic changes, and
I'll loose that once it gets on the stable three.

If you are running -stable, you'll be able to use it if you import
-current's sys/boot and sys/sys/linker.h, cd /sys/boot ; make depend
 make all install.

OTOH, you might solve your problem just by adding the following two
lines to /boot/loader.rc

load kernel
load -t userconfig_script /kernel.config

and then putting your pnp configuration line on /kernel.config (if
it is not there already).

This will work on both current and stable, so I think I ought to
mention it. :-)

Now, back to the loader.rc stuff, in case you _are_ running
-current... it should have installed the following files:

/boot/loader.4th
/boot/support.4th
/boot/defaults/loader.conf

The last file is all you really need as example.

A man page is in the works. It is queued right after the loader man
page, which has been a real drag to write, but I think I might be
committing it today. But the loader.conf man page won't really add
anything for you that is not in /boot/defaults/loader.conf.

--
Daniel C. Sobral(8-DCS)
d...@newsguy.com
d...@freebsd.org

My theory is that his ignorance clouded his poor judgment.


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



Re: HEADS UP: new loader.rc stuff

1999-03-13 Thread Chuck Robey
On Sun, 14 Mar 1999, Daniel C. Sobral wrote:

 If you are running -stable

This is the -current list, and I'm running current.  I don't have the
file userconfig_script nor /kernel.config.

, you'll be able to use it if you import
 -current's sys/boot and sys/sys/linker.h, cd /sys/boot ; make depend
  make all install.
 
 OTOH, you might solve your problem just by adding the following two
 lines to /boot/loader.rc
 
 load kernel
 load -t userconfig_script /kernel.config
 
 and then putting your pnp configuration line on /kernel.config (if
 it is not there already).

This is good info for current, right?  And I don't need to worry about
userconfig_script?  What's load -t do (I don't need a man page, but at
least a few words on the -t, please).

The pnp line will be the only thing in /kernel.config, that's normal?

 
 This will work on both current and stable, so I think I ought to
 mention it. :-)

I am not running stable, it doesn't track all the new config stuff, but
I have all the files listed below, it seems.

 
 Now, back to the loader.rc stuff, in case you _are_ running
 -current... it should have installed the following files:
 
 /boot/loader.4th
 /boot/support.4th
 /boot/defaults/loader.conf
 
 The last file is all you really need as example.

I was asking about where to stick in the pnp line, and an example of
that.  I guess it's not loader.conf (I just tested that, it didn't work
there).  I'm a little leery yet of the load -t because I don't have that
userconfig_script file, and I don't know what the load -t does.

 
 A man page is in the works. It is queued right after the loader man
 page, which has been a real drag to write, but I think I might be
 committing it today. But the loader.conf man page won't really add
 anything for you that is not in /boot/defaults/loader.conf.
 
 --
 Daniel C. Sobral  (8-DCS)
 d...@newsguy.com
 d...@freebsd.org
 
   My theory is that his ignorance clouded his poor judgment.
 
 

+---
Chuck Robey | Interests include any kind of voice or data 
chu...@glue.umd.edu | communications topic, C programming, and Unix.
213 Lakeside Drive Apt T-1  |
Greenbelt, MD 20770 | I run picnic (FreeBSD-current)
(301) 220-2114  | and jaunt (Solaris7).
+---






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



Re: HEADS UP: new loader.rc stuff

1999-03-13 Thread Andrzej Bialecki
On Sat, 13 Mar 1999, Chuck Robey wrote:

  load kernel
  load -t userconfig_script /kernel.config
  
  and then putting your pnp configuration line on /kernel.config (if
  it is not there already).
 
 This is good info for current, right?  And I don't need to worry about
 userconfig_script?  What's load -t do (I don't need a man page, but at
 least a few words on the -t, please).

'-t' does basically two things. First of all, it selects right loading
procedure, e.g. just suck it in instead of interpreting it as an ELF
binary. The other thing is that it attaches a magic label to this piece of
code, so that later from within the kernel you can do
preload_search_by_type(my_lovely_magic_string) and it will return a
pointer to the right data, be it an executable code or a text or a
graphics image.

  
 The pnp line will be the only thing in /kernel.config, that's normal?

Yes. Since you're running -current, you should be able to use kget(8) as a
dset replacement to generate /kernel.config for you, based on the changes
in UserConfig.

Andrzej Bialecki

//  ab...@webgiro.com WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small  Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 



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



Re: bmake/contrib framework for egcs

1999-03-13 Thread David O'Brien
On Sat, Mar 13, 1999 at 11:33:23PM +0200, Vladimir Kushnir wrote:
 Hello, here's where cpp died. There's a small error in freebsd.h:
 ^
 freebsd-elf.h

 INCLUDE_DEFAULTS array defined in a wrong way (patch attached). Now cpp

Crud!  I had freebsd.h right, but didn't get the changes to
INCLUDE_DEFAULTS into freebsd-elf.h.

Thanks!

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



Diskless boot stopping at NFS ROOT:...

1999-03-13 Thread Nicholas Esborn
This is a problem I have had on two seperate systems, running
3.0-RELEASE and now 3.1-STABLE built about a week ago.  The systems were
brought up seperately.

Unfortunately since this machine never comes up to any usable state, I
don't have detailed logs of its boot output.  I'll try to summarize:

I compiled the 3.1-S kernel with KERNFORMAT=aout and placed it in
/usr/local/netboot/fs/, my NFS rootfs.  The following dirs were cpio'd
from the host system:

drwxr-xr-x   2 root  wheel  512 Mar 13 17:51 bin
drwxr-xr-x   2 root  wheel 1024 Mar 13 17:52 lkm
drwxr-xr-x   2 root  wheel 1536 Mar 13 17:52 sbin
drwxr-xr-x   4 root  wheel  512 Mar 13 17:52 stand

I made usr and cpio'd the following dirs into it:

drwxr-xr-x   2 root  wheel  6144 Mar 13 18:03 bin
drwxr-xr-x   3 root  wheel   512 Mar 13 18:03 compat
drwxr-xr-x   4 root  wheel  3584 Mar 13 18:05 lib
drwxr-xr-x   9 root  wheel   512 Mar 13 18:05 libdata
drwxr-xr-x   7 root  wheel  1024 Mar 13 18:07 libexec
drwxr-xr-x   2 root  wheel  3584 Mar 13 18:07 sbin
drwxr-xr-x  26 root  wheel   512 Mar 13 18:15 share

I made etc and copied ttys into it.  I made the following rc:

#!/bin/sh
echo 'STARTING UP'
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin
export PATH
ifconfig lo0 inet 127.0.0.1 netmask 0x
mount -t nfs -u 10.0.0.1:/export/boot/fs /
mount -a
/sbin/ldconfig -elf /usr/lib /usr/lib/compat /usr/X11R6/lib
while [ 1 -eq 1 ]; do
/usr/X11R6/bin/XF86_S3 -bpp 16 -query deimos
done

The mounting stuff may be problematic, but it doesn't look like rc is
even running...

The clients find the kernel and start booting, goes through its bootpc
configuration obtaining all the right numbers, prints:

NFS ROOT: 10.0.0.1:/usr/local/netboot/fs

and stops.  I have to hard power cycle the client.

The kernel is GENERIC with BOOTP, BOOTP_NFSROOT, BOOTP_NFSV3, and
BOOTP_COMPAT.  I can't tell if the nfs flags are getting set in the
kernel, as the machine never comes up to a shell.

Here's the irony: I can currently get 2.2.x booting through almost the
same procedures and setups (only differing where 2.2.x and 3.x features
differ).

Any ideas?  Thank you for your time either way.  Please respond to me by
email as I'm not on the mailing lists.

Nick Esborn



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



Re: HEADS UP: new loader.rc stuff

1999-03-13 Thread Chuck Robey
On Sun, 14 Mar 1999, Andrzej Bialecki wrote:

 On Sat, 13 Mar 1999, Chuck Robey wrote:
 
   load kernel
   load -t userconfig_script /kernel.config
   
   and then putting your pnp configuration line on /kernel.config (if
   it is not there already).
  
  This is good info for current, right?  And I don't need to worry about
  userconfig_script?  What's load -t do (I don't need a man page, but at
  least a few words on the -t, please).
 
 '-t' does basically two things. First of all, it selects right loading
 procedure, e.g. just suck it in instead of interpreting it as an ELF
 binary. The other thing is that it attaches a magic label to this piece of
 code, so that later from within the kernel you can do
 preload_search_by_type(my_lovely_magic_string) and it will return a
 pointer to the right data, be it an executable code or a text or a
 graphics image.
 
   
  The pnp line will be the only thing in /kernel.config, that's normal?
 
 Yes. Since you're running -current, you should be able to use kget(8) as a
 dset replacement to generate /kernel.config for you, based on the changes
 in UserConfig.

Wonderful, between you, Don Maddox and Dan Sobral, you guys have
explained that pretty darned well.  Glad it's in the mail archives now.  
My new $30 sound card is also surprising heck out of me by sounding
fine, too. I'll stick info on that in snd/CARDS when I'm finished
getting more info on it.

This stuff oughta be somewhere, soonest.  If it's not man page, at least
a temporary distillation of it in a file in sys/boot, to be tossed once
there's a man page.


+---
Chuck Robey | Interests include any kind of voice or data 
chu...@glue.umd.edu | communications topic, C programming, and Unix.
213 Lakeside Drive Apt T-1  |
Greenbelt, MD 20770 | I run picnic (FreeBSD-current)
(301) 220-2114  | and jaunt (Solaris7).
+---






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



Re: bmake/contrib framework for egcs

1999-03-13 Thread David O'Brien
 gnu/lib/libstdc++/Makefile this part of CFLAGS shoild be 
 -I${EGCSDIR}/gcc/cp/inc rather than -I${EGCSDIR}/gcc/cp/inc/exception
 (after all, ${EGCSDIR}/gcc/cp/inc/exception is a file).

Yes.  What I was working on is newer than the CVS repository.  I'm
chasing several issues  moving things around.  I haven't been keeping
the CVSup'able totally bits upto date in the past few days.

Tonight or Sunday, I hope to have the same thing I'm working on available
to all.   

-- 
-- 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: HEADS UP: new loader.rc stuff

1999-03-13 Thread Jordan K. Hubbard
 This stuff oughta be somewhere, soonest.  If it's not man page, at least
 a temporary distillation of it in a file in sys/boot, to be tossed once
 there's a man page.

*chuckle*  It's like taking candy from a baby, I tell you!

I can't help but notice that Chuck is a committer, and under the rules
of he who last touched it, gets it in -committers, I'd say we're all
in unanimous agreement (with him) that he should now commit something
to start this process along, right folks? :-)

- Jordan


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



Re: bmake/contrib framework for egcs

1999-03-13 Thread Vladimir Kushnir
Excellent, I'll have a free weekend then :-) BTW, do you plan to include
egcs' g77 as well?

On Sat, 13 Mar 1999, David O'Brien wrote:

 Yes.  What I was working on is newer than the CVS repository.  I'm
 chasing several issues  moving things around.  I haven't been keeping
 the CVSup'able totally bits upto date in the past few days.
 
 Tonight or Sunday, I hope to have the same thing I'm working on available
 to all.   
 
 -- 
 -- David(obr...@nuxi.com  -or-  obr...@freebsd.org)
 
 


===|===
 Vladimir Kushnir  |
 ku...@mail.kar.net,   |Powered by FreeBSD
 kush...@ap3.bitp.kiev.ua  |



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