Re: ep0 3com etherlink III still unhappy
On Mon, 1 Nov 1999, Mark Hittinger wrote: ep0: 3Com EtherLink III (3c509-TPO) at port 0x300-0x30f irq 10 on isa0 ep0: eeprom failed to come ready. ep0: eeprom failed to come ready. ep0: eeprom failed to come ready. ep0: eeprom failed to come ready. ep0: eeprom failed to come ready. ep0: Ethernet address ff:ff:ff:ff:ff:ff ep1: 3Com 3C509B EtherLink III at port 0x210-0x21f irq 5 on isa0 ep1: Ethernet address 00:a0:24:a1:9a:1e The card is actually 0x300, not 0x210. Disabling pnp isn't a work around any longer. Does ep1 work (i.e. can you send and receive packets on ep1)? If so, you can probably change your kernel config to have just 'device ep0' which would allow the card to appear as ep0 again. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ep0 3com etherlink III still unhappy
ep0: 3Com EtherLink III (3c509-TPO) at port 0x300-0x30f irq 10 on isa0
ep0: eeprom failed to come ready.
...
ep0: Ethernet address ff:ff:ff:ff:ff:ff
ep1: 3Com 3C509B EtherLink III at port 0x210-0x21f irq 5 on isa0
ep1: Ethernet address 00:a0:24:a1:9a:1e
I still have problems with probing ep's on one Cyrix system.
One thing that has made it better is passing a bit delay down to
elink_idseq, that is:
void
elink_idseq(u_char p, void (*bit_delay)(void))
{
register int i;
register u_char c;
c = 0xff;
for (i = 255; i; i--) {
(*bit_delay)();
outb(ELINK_ID_PORT, c);
if (c 0x80) {
c = 1;
I haven't bothered committing this since it still fails 1 out of 6 times.
Without this it fails 1 out of 3 times. If it logically makes sense
that a delay is needed here (I don't have any docs) someone might add it.
Peter
--
Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control,
HD Associates, Inc. Safety critical systems, Agency approval
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Ross Harvey's nice fixes and associated clean up
I've merged Ross Harvey's "nice" fixes and associated clean up from NetBSD in with my own scheduler hacks. They're at http://www.freebsd.org/~dufault via the "system" link. I won't promise much other than that the resulting kernel boots and runs with no obvious problems to my canned regression tests. There could yet be glaring problems. For the alpha people - I didn't add a separate scheduler clock, you'll have to do that on your own and modify kern_clock.c to not call "update_estcpu", instead call that from your scheduler clock. See Ross's work, my "update_estcpu" is the equivalent of his "sched_clock". If we keep this work I'll match his nomenclature. Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GENERIC build broken
:A GENERIC kernel build breaks here with: : :- :sh ../../conf/newvers.sh GENERIC :cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes :-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi :-nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -include opt_global.h -elf :vers.c :linking kernel :mfs_vfsops.o: In function `mfs_init': :mfs_vfsops.o(.text+0x63d): undefined reference to `mountrootfsname' :*** Error code 1 :1 error :- : :Is it just some unfinished commits? : :John :-- :John Hay -- [EMAIL PROTECTED] It looks like a dead global in mfs due to Mike's reorganization of the rootfs stuff. I'll let Mike do the trivial fix, though, since he broke it :-). -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: minor heads up - /etc/make.conf{,.local} being moved
Matthew Dillon wrote: (Approved by jkh) /etc/make.conf.local will become /etc/make.conf and /etc/make.conf will become /etc/defaults/make.conf. This change is long overdue. The sys.mk adjustment has already been committed. An email has been sent to the CVS meisters to get /usr/src/etc/make.conf moved. make will dump out with an appropriate error and instructions if you update your source tree and still have an /etc/make.conf.local. I like this change (kind of) but is it really necessary to cause make to exit if there is a make.conf.local? Why not have it read all 3? One of the things we talked about at the 'Con was that a three tiered system works well for rc.conf when you have a lot of machines sharing similar configuration details, but with some unique elements present on each machine. Perhaps I'm missing something, but how can make.conf.local be a bad thing? Doug -- "Stop it, I'm gettin' misty." - Mel Gibson as Porter, "Payback" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: minor heads up - /etc/make.conf{,.local} being moved
: sent to the CVS meisters to get /usr/src/etc/make.conf moved. : : make will dump out with an appropriate error and instructions if you : update your source tree and still have an /etc/make.conf.local. : : I like this change (kind of) but is it really necessary to cause make :to exit if there is a make.conf.local? Why not have it read all 3? One :of the things we talked about at the 'Con was that a three tiered system :works well for rc.conf when you have a lot of machines sharing similar :configuration details, but with some unique elements present on each :machine. Perhaps I'm missing something, but how can make.conf.local be a :bad thing? : :Doug I think it is necessary to make it exit for now, because what we are really doing is a net-0 gain in files... turning what used to be functionality in /etc/make.conf.local into /etc/make.conf. The intent is not to add a third file. If the intent were to add a third configuration file then, sure, we could allow all three. But that isn't my intent. I am somewhat worried that people upgrading from 3.x to 4.x will get confused if that error message is not in there. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: minor heads up - /etc/make.conf{,.local} being moved
On Tue, 2 Nov 1999, Doug Barton wrote: I think it is necessary to make it exit for now, because what we are really doing is a net-0 gain in files... turning what used to be functionality in /etc/make.conf.local into /etc/make.conf. The intent is not to add a third file. If the intent were to add a third configuration file then, sure, we could allow all three. But that isn't my intent. Ok, well put me on record as wanting three files. While I still have I am not for proliferation of config files. rc.conf and rc.conf.local should have been handled the same way AFAIC. Put me down as wanting two files. An extra file is just more shtuff to keep track of. I too am iffy on /etc/defaults. If the purpose of defaults is to keep "standard" things in isolation then lets do that. Begrudgingly, defaults do clean up /etc a bit. It makes mergemastering easier too. The defaults will be better when they become more complete. some reservations about the whole /etc/defaults thing, I believe that if we are going to use it we should use it to full advantage, offering people more functionality, not less. Unless I am missing something, the The number of files relating to make would still be two. The purpose of each of those files is the same. The new functionality is precisely equal to the previous functionality. Thank You, | http://students.washington.edu/jcwells/ Jason Wells To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: compile error (graphics)
Stephan van Beerschoten [EMAIL PROTECTED] wrote: } ... } cc -Wall -Wstrict-prototypes -Wnested-externs -Wno-format \ } -L/usr/X11R6/lib -o xscreensaver xscreensaver.o windows.o \ } timers.o subprocs.o xset.o splash.o setuid.o stderr.o prefs.o \ } lock.o passwd.o passwd-kerberos.o passwd-pwent.o ../utils/fade.o \ } ../utils/overlay.o ../utils/xroger.o ../utils/spline.o \ } ../utils/yarandom.o ../utils/resources.o ../utils/usleep.o \ } ../utils/visual.o-L/usr/X11R6/lib -lXmu -lXss -lXdpms -lXxf86vm \ } -lSM -lICE -lXmu -lXt -lXt -lX11 -lXext -lkrb -ldes -lcrypt } /usr/lib/libkrb.so: undefined reference to `init_error_table' } /usr/lib/libkrb.so: undefined reference to `initialize_error_table_r' } *** Error code 1 } } I got the same error while trying to compile xlockmore from ports, } and I know I've seen this before that one as well, I just can't } remember. anyone ? You need to add -lcom_err to your link line. -Patrick Patrick L. Hartling | Research Assistant, VRAC [EMAIL PROTECTED] | Carver Lab - 0095E Black Engineering http://www.137.org/patrick/ | http://www.vrac.iastate.edu/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: minor heads up - /etc/make.conf{,.local} being moved
On Tue, Nov 02, 1999 at 10:41:19PM +, Jason C. Wells wrote: Put me down as wanting two files. An extra file is just more shtuff to keep track of. I too am iffy on /etc/defaults. If the purpose of defaults is to keep "standard" things in isolation then lets do that. Begrudgingly, defaults do clean up /etc a bit. It makes mergemastering easier too. The defaults will be better when they become more complete. The thing about the defaults/foo.conf, foo.conf, foo.conf.local scheme is that you don't _have_ to use foo.conf.local if you don't want to. Some of us have a use for it, such as putting site configuration in foo.conf, and machine configuration in foo.conf.local. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ep0 3com etherlink III still unhappy
On Tue, 2 Nov 1999, Doug Rabson wrote: On Mon, 1 Nov 1999, Mark Hittinger wrote: ep0: 3Com EtherLink III (3c509-TPO) at port 0x300-0x30f irq 10 on isa0 ep0: eeprom failed to come ready. ep0: eeprom failed to come ready. ep0: eeprom failed to come ready. ep0: eeprom failed to come ready. ep0: eeprom failed to come ready. ep0: Ethernet address ff:ff:ff:ff:ff:ff ep1: 3Com 3C509B EtherLink III at port 0x210-0x21f irq 5 on isa0 ep1: Ethernet address 00:a0:24:a1:9a:1e The card is actually 0x300, not 0x210. Disabling pnp isn't a work around any longer. Does ep1 work (i.e. can you send and receive packets on ep1)? If so, you can probably change your kernel config to have just 'device ep0' which would allow the card to appear as ep0 again. As per my commit 'heads up' nobody should have anything more or less than 'device ep0' in their config file. I'm assuming he is booting a GENERIC kernel, which I changed to reflect my modifications to if_ep. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GENERIC build broken
I got dragged away yesterday before I could fix this properly; it actually requires a bit more finessing due to the way MFS creates a root-private instance of itself when it nominates itself as root. I don't want to commit a half-baked fix, so I'm going to ask for a little forbearance and fix it properly this evening. :A GENERIC kernel build breaks here with: : :- :sh ../../conf/newvers.sh GENERIC :cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -include opt_global.h -elf vers.c :linking kernel :mfs_vfsops.o: In function `mfs_init': :mfs_vfsops.o(.text+0x63d): undefined reference to `mountrootfsname' :*** Error code 1 :1 error :- : :Is it just some unfinished commits? : :John :-- :John Hay -- [EMAIL PROTECTED] It looks like a dead global in mfs due to Mike's reorganization of the rootfs stuff. I'll let Mike do the trivial fix, though, since he broke it :-). -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Heads up: GENERIC broken (mfs)
Those of you that have been reading this list will have noticed that I broke MFS_ROOT and thus GENERIC last night. This message is just to let you all know that I know it's broke (now), and that I'll be working on it this evening (PST). Apologies for the breakage in the interim. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: minor heads up - /etc/make.conf{,.local} being moved
On Tue, 2 Nov 1999, Jason C. Wells wrote: On Tue, 2 Nov 1999, Doug Barton wrote: I think it is necessary to make it exit for now, because what we are really doing is a net-0 gain in files... turning what used to be functionality in /etc/make.conf.local into /etc/make.conf. The intent is not to add a third file. If the intent were to add a third configuration file then, sure, we could allow all three. But that isn't my intent. Ok, well put me on record as wanting three files. While I still have Put me down as wanting two files. An extra file is just more shtuff to keep track of. I too am iffy on /etc/defaults. If the purpose of defaults is to keep "standard" things in isolation then lets do that. Begrudgingly, defaults do clean up /etc a bit. It makes mergemastering easier too. The defaults will be better when they become more complete. Actually system updates are exactly why I treat the /etc/defaults business with a great deal of mistrust. It hides (or more precisely, it _can_ hide) details of changes and new options from the user. Using mergemaster at least allows you to see more clearly what has been changed, however It still makes me nervous. I'm contemplating some changes that will help correlate differences between /etc/defaults/*.conf and /etc/*.conf[.local], but right now I have no time to hack them out. some reservations about the whole /etc/defaults thing, I believe that if we are going to use it we should use it to full advantage, offering people more functionality, not less. Unless I am missing something, the The number of files relating to make would still be two. The purpose of each of those files is the same. The new functionality is precisely equal to the previous functionality. Well I don't think that you've made a case yet that the number of files should be zero sum, and as someone pointed out you don't have to use make.conf.local if you don't want or need it. My points are simply that we already have a precedent, the three-tier system for rc.conf has proven to be useful, and if we are going to make a change anyway let's give the user more options, not less. Doug -- "Stop it, I'm gettin' misty." - Mel Gibson as Porter, "Payback" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GENERIC build broken
: .. Mike Smith writes .. :I got dragged away yesterday before I could fix this properly; it :actually requires a bit more finessing due to the way MFS creates a :root-private instance of itself when it nominates itself as root. I :don't want to commit a half-baked fix, so I'm going to ask for a little :forbearance and fix it properly this evening. If you can actually fix the MFS hacks that have been put in over the years to deal with root fs mounts a lot of people are going to be *very* happy with you! It is certainly worth some temporary breakage. I am not happy at all with the rootfsid hacks I made a few months ago but I didn't have time to do anything about it at the time and I had to get BOOTP working again after someone left it broken for a couple of weeks. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: named.conf oddity
Jeroen Ruigrok/Asmodai said:
Nov 3 00:07:44 daemon named[481]: /etc/dns/named.conf:4: syntax error
near '195.121.1.34'
Nov 3 00:07:44 daemon named[481]: /etc/dns/named.conf:7: syntax error
near '}'
I start named with -b /etc/dns/named.conf
And this is my, working for the last half year named.conf:
options {
directory "/etc/dns";
forwarders {
195.121.1.34;
195.121.1.66;
};
};
It seems a recent update to lib/libc/net/inet_addr.c is the culprit here.
Any IP address with a component of 34 will fail in inet_aton(). Here's a
patch that should fix it up:
Index: inet_addr.c
===
RCS file: /home/ncvs/src/lib/libc/net/inet_addr.c,v
retrieving revision 1.9
diff -u -r1.9 inet_addr.c
--- inet_addr.c 1999/10/31 04:43:55 1.9
+++ inet_addr.c 1999/11/03 02:01:52
@@ -65,6 +65,8 @@
#include ctype.h
#include errno.h
+#include limits.h
+#include stdlib.h
#include string.h
/*
@@ -98,7 +100,7 @@
u_long val;
char *c;
char *endptr;
- int base, gotend, n;
+ int gotend, n;
c = (char *)cp;
n = 0;
@@ -111,8 +113,10 @@
errno = 0;
val = strtoul(c, endptr, 0);
- if (val == ERANGE) /* Fail completely if it overflowed. */
+ if ((val == ULONG_MAX) (errno == ERANGE)) {
+ /* Fail completely if it overflowed. */
return (0);
+ }
/*
* If the whole string is invalid, endptr will equal
--
Mike Spengler Network Computing Services, Inc.
Email: [EMAIL PROTECTED]1200 Washington Ave. So.
Phone: +1 612 337 3557 Minneapolis MN 55415
FAX: +1 612 337 3400 (aka Minnesota Supercomputer Center)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: named.conf oddity
It seems a recent update to lib/libc/net/inet_addr.c is the culprit here.
Any IP address with a component of 34 will fail in inet_aton(). Here's a
patch that should fix it up:
Index: inet_addr.c
===
RCS file: /home/ncvs/src/lib/libc/net/inet_addr.c,v
retrieving revision 1.9
diff -u -r1.9 inet_addr.c
--- inet_addr.c 1999/10/31 04:43:55 1.9
+++ inet_addr.c 1999/11/03 02:01:52
@@ -65,6 +65,8 @@
#include ctype.h
#include errno.h
+#include limits.h
+#include stdlib.h
#include string.h
/*
@@ -98,7 +100,7 @@
u_long val;
char *c;
char *endptr;
- int base, gotend, n;
+ int gotend, n;
c = (char *)cp;
n = 0;
@@ -111,8 +113,10 @@
errno = 0;
val = strtoul(c, endptr, 0);
- if (val == ERANGE) /* Fail completely if it overflowed. */
+ if ((val == ULONG_MAX) (errno == ERANGE)) {
+ /* Fail completely if it overflowed. */
return (0);
+ }
/*
* If the whole string is invalid, endptr will equal
The check should be simply `if (errno == ERANGE)'. The (val == ULONG_MAX)
check is a harmless bug (harmless because non-overflowing values 0xff,
including ULONG_MAX, cause a failure later).
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ep problem with 4.0-19991101-CURRENT snapshot
In message [EMAIL PROTECTED] Jesper Skriver writes: : sysinstall can assign a ip address via. DHCP, but the machine cannot be : ping'ed from other hosts on the lan, same if I manually configure ep0 : via ifconfig. This sounds like the classic "The right interrupt isn't assigned problem" that I see from time to time. What IRQ did ep0 say it was using? Ditto for pcic0? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GENERIC build broken
: I am not happy at all with the rootfsid hacks I made a few months ago : but I didn't have time to do anything about it at the time and I had : to get BOOTP working again after someone left it broken for a couple : of weeks. : :Well, bootp in the kernel has to die too. Huh? And replace it with what? BOOTP is the only way to get an NFS root and swap. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GENERIC build broken
On 1999-Nov-03 15:59:38 +1100, Matthew Dillon wrote: :Well, bootp in the kernel has to die too. Huh? And replace it with what? BOOTP is the only way to get an NFS root and swap. Sun uses reverse ARP to do this. Reverse ARP _is_ a hack, but it _is_ an alternative to BOOTP. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GENERIC build broken
: I am not happy at all with the rootfsid hacks I made a few months ago : but I didn't have time to do anything about it at the time and I had : to get BOOTP working again after someone left it broken for a couple : of weeks. : :Well, bootp in the kernel has to die too. Huh? And replace it with what? BOOTP is the only way to get an NFS root and swap. No; that's what the loader is for. The kernel shouldn't be doing any application-level snot like BOOTP at all. The same work was previously done by netboot; putting bootp into the kernel was _always_ the wrong idea. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
diskless boot roadmap (was:L Re: GENERIC build broken )
On 1999-Nov-03 15:59:38 +1100, Matthew Dillon wrote: :Well, bootp in the kernel has to die too. Huh? And replace it with what? BOOTP is the only way to get an NFS root and swap. Sun uses reverse ARP to do this. Reverse ARP _is_ a hack, but it _is_ an alternative to BOOTP. RARP would be a really bad move at the moment, since everyone else is using DHCP. For those that are still following, the roadmap looks like this at the moment: - On the PC, we will be following the PXE lead, since that's where the market is going. This basically involves using the PXE firmware which will talk to a PXE server to get the loader. It can also be conned into using normal DHCP. File transfer is either by MTFTP (multicast TFTP) or normal TFTP. The loader will do plain DHCP and use NFS to get the kernel straight out of the prospective root filesystem. Please don't complain about how ugly PXE is. It's the closest thing the PC world has ever seen to a sane network boot architecture. You're welcome to go work on RPL if you want some perspective. 8) - On the Alpha, diskless booting involves BOOTP/TFTP to fetch the loader. The loader will then happily use BOOTP or DHCP again (since SRM is too stupid to tell _us_ what it discovered) and NFS to read the kernel from the root filesystem. As you can see from the above, there's no call for RARP, bootparam, RPL or any other form of mumbo-jumbo. There's also no call for the kernel to do any of this work; the loader will do it all and pass it in to the kernel in a format it can use directly. What is currently missing, you ask? - The loader DHCP code needs to be written. - The kernel needs to improve the way it handles interface configuration information passed to it by the loader. - We need more PXE work done for the i386 loader. Intel are helping here a little, but I could use a couple of extra hands to get this done sooner rather than later. That's about it; we're almost there. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GENERIC build broken
: :Huh? And replace it with what? BOOTP is the only way to get an NFS :root and swap. : :Sun uses reverse ARP to do this. Reverse ARP _is_ a hack, but it _is_ :an alternative to BOOTP. : :Peter Mmm. Well, I suppose, but it isn't going to be any less complex because rarp does not support all the require features natively. BOOTP is a very simple protocol. You can't get much simpler and the kernel root fs portion of the implementation is going to wind up being the same anyway. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: diskless boot roadmap (was:L Re: GENERIC build broken )
On 1999-Nov-03 16:15:03 +1100, Mike Smith wrote: On 1999-Nov-03 15:59:38 +1100, Matthew Dillon wrote: :Well, bootp in the kernel has to die too. Huh? And replace it with what? BOOTP is the only way to get an NFS root and swap. Sun uses reverse ARP to do this. Reverse ARP _is_ a hack, but it _is_ an alternative to BOOTP. RARP would be a really bad move at the moment, since everyone else is using DHCP. I'm not suggesting we move to RARP. Matt was stating that BOOTP is the only way. There's also no call for the kernel to do any of this work; the loader will do it all and pass it in to the kernel in a format it can use directly. Sounds excellent. (Not that I'm offering at this point in time). Initialisation code in the permanently resident kernel is basically just wasting physical RAM. The less of it there is, the better. How much of the probe code can we move into userland? Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GENERIC build broken
: Huh? And replace it with what? BOOTP is the only way to get an NFS : root and swap. : :No; that's what the loader is for. The kernel shouldn't be doing any :application-level snot like BOOTP at all. : :The same work was previously done by netboot; putting bootp into the :kernel was _always_ the wrong idea. : :-- :\\ Give a man a fish, and you feed him for a day. \\ Mike Smith Great in theory, but unless someone is actually willing to do the great deal of work required to support this we're stuck with BOOTP in the kernel. Even if you were to do this most of the junk in the kernel to actually do the mounts would have to stick around. Frankly, I don't think it's such a big deal to leave it in the kernel, you wouldn't actually be cleaning much up by moving it out. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
probe code (was Re: diskless boot roadmap)
Initialisation code in the permanently resident kernel is basically just wasting physical RAM. The less of it there is, the better. How much of the probe code can we move into userland? Actually, with PnP architectures becoming the norm, probe code basically goes away, so the whole point is pretty moot. Attach code is somewhat bulkier, but you need to bear in mind that it's needed for devices that arrive after boot time. Attach code is typically far too closely tied to the operational code to separate it at all. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GENERIC build broken
: Huh? And replace it with what? BOOTP is the only way to get an NFS : root and swap. : :No; that's what the loader is for. The kernel shouldn't be doing any :application-level snot like BOOTP at all. : :The same work was previously done by netboot; putting bootp into the :kernel was _always_ the wrong idea. Great in theory, but unless someone is actually willing to do the great deal of work required to support this we're stuck with BOOTP in the kernel. Er, hello? It's _already_been_done_, even. See above inre: netboot. Even if you were to do this most of the junk in the kernel to actually do the mounts would have to stick around. Frankly, I don't think it's such a big deal to leave it in the kernel, you wouldn't actually be cleaning much up by moving it out. It's pointless duplicating it in the kernel when the code that's loaded the kernel has already done it. Nuking it from the kernel has several benefits: - the bootp code in the kernel has rotted, and is quite ugly. - it removes one more confusing option. - it's redundant. The code for performing the actual NFS root mount is tiny compared to the bootp and ifconfig code. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Make world error on todays cvsup......
Doing a make world on a DEC Alpha 200 4/233 I get this: The command that produced this was make -DNOGAMES -j 4 world cd /usr/src/include/../sys; install -C -o root -g wheel -m 444 cam/*.h /usr/obj/usr/src/tmp/usr/include/cam cd /usr/src/include/../sys; install -C -o root -g wheel -m 444 msdosfs/*.h /usr/obj/usr/src/tmp/usr/include/msdosfs cd /usr/src/include/../sys; install -C -o root -g wheel -m 444 net/*.h /usr/obj/usr/src/tmp/usr/include/net cd /usr/src/include/../sys; install -C -o root -g wheel -m 444 netatalk/*.h /usr/obj/usr/src/tmp/usr/include/netatalk cd /usr/src/include/../sys; install -C -o root -g wheel -m 444 netatm/*.h /usr/obj/usr/src/tmp/usr/include/netatm cd /usr/src/include/../sys; install -C -o root -g wheel -m 444 netgraph/*.h /usr/obj/usr/src/tmp/usr/include/netgraph cd /usr/src/include/../sys; install -C -o root -g wheel -m 444 netinet/*.h /usr/obj/usr/src/tmp/usr/include/netinet cd /usr/src/include/../sys; install -C -o root -g wheel -m 444 netipx/*.h /usr/obj/usr/src/tmp/usr/include/netipx cd /usr/src/include/../sys; install -C -o root -g wheel -m 444 netkey/*.h /usr/obj/usr/src/tmp/usr/include/netkey cd /usr/src/include/../sys; install -C -o root -g wheel -m 444 netncp/*.h /usr/obj/usr/src/tmp/usr/include/netncp cd /usr/src/include/../sys; install -C -o root -g wheel -m 444 netns/*.h /usr/obj/usr/src/tmp/usr/include/netns cd /usr/src/include/../sys; install -C -o root -g wheel -m 444 nfs/*.h /usr/obj/usr/src/tmp/usr/include/nfs cd /usr/src/include/../sys; install -C -o root -g wheel -m 444 nwfs/*.h /usr/obj/usr/src/tmp/usr/include/nwfs cd /usr/src/include/../sys; install -C -o root -g wheel -m 444 pccard/*.h /usr/obj/usr/src/tmp/usr/include/pccard cd /usr/src/include/../sys; install -C -o root -g wheel -m 444 posix4/*.h /usr/obj/usr/src/tmp/usr/include/posix4 cd /usr/src/include/../sys; install -C -o root -g wheel -m 444 sys/*.h /usr/obj/usr/src/tmp/usr/include/sys cd /usr/src/include/../sys; install -C -o root -g wheel -m 444 vm/*.h /usr/obj/usr/src/tmp/usr/include/vm cd /usr/src/include/../sys; install -C -o root -g wheel -m 444 isofs/cd9660/*.h /usr/obj/usr/src/tmp/usr/include/isofs/cd9660 cd /usr/src/include/../sys; install -C -o root -g wheel -m 444 ufs/ffs/*.h /usr/obj/usr/src/tmp/usr/include/ufs/ffs install: ufs/ffs/softdep.h: No such file or directory *** Error code 71 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error --- any ideas -- E-Mail: William Woods [EMAIL PROTECTED] Date: 02-Oct-99 Time: 21:45:37 FreeBSD 3.3 -Stable -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make world error on todays cvsup......
In article [EMAIL PROTECTED], William Woods [EMAIL PROTECTED] wrote: Doing a make world on a DEC Alpha 200 4/233 I get this: ... cd /usr/src/include/../sys; install -C -o root -g wheel -m 444 ufs/ffs/*.h /usr/obj/usr/src/tmp/usr/include/ufs/ffs install: ufs/ffs/softdep.h: No such file or directory *** Error code 71 ... any ideas Yep. Read /usr/src/sys/ufs/ffs/README.softupdates, and do what it says. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make world error on todays cvsup......
Thank you... On 03-Nov-99 John Polstra wrote: In article [EMAIL PROTECTED], William Woods [EMAIL PROTECTED] wrote: Doing a make world on a DEC Alpha 200 4/233 I get this: ... cd /usr/src/include/../sys; install -C -o root -g wheel -m 444 ufs/ffs/*.h /usr/obj/usr/src/tmp/usr/include/ufs/ffs install: ufs/ffs/softdep.h: No such file or directory *** Error code 71 ... any ideas Yep. Read /usr/src/sys/ufs/ffs/README.softupdates, and do what it says. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron -- E-Mail: William Woods [EMAIL PROTECTED] Date: 02-Oct-99 Time: 22:28:41 FreeBSD 3.3 -Stable -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GENERIC build broken
: great deal of work required to support this we're stuck with BOOTP : in the kernel. : :Er, hello? It's _already_been_done_, even. See above inre: netboot. Good god, you are talking about netboot? Hello? Mike, I get the feeling that you've never actually tried to use netboot. You "get" wrong. You could probably actually search the archives for much of what I've said about diskless booting over the last four or so years and get a reasonable picture of what I know, or just accept that fact that I'm acutely aware of the possibilities and limitations that currently exist. I'd like to suggest you use etherboot in the interim, but it doesn't fill in the nfs_diskless structure, which is somewhat of a pity since that's all that's needed. You could probably fix this in about ten minutes if you want a functional solution, and it probably supports most if not all of the cards you currently have. You seem to believe that it is direct replacement for BOOTP. It isn't even close. That's neither what I said, nor what I believe. I merely pointed out that netboot has already done the "great deal of work" that you're agonising about. You'll note that the loader also already contains this "great deal of work", since it seems to netboot Alphas just fine. If you care to read what I've actually written, you'll note that I am advocating the death of BOOTP once it's replaced by something that works better. You might want to consider turning down the gain on your Panic-o-tronic implant on this one. netboot only works with a very small number of ethernet cards while the BOOTP code in the kernel works with *all* ethernet cards that the kernel supports. The BOOTP code in the kernel is singularly useless if you can't get the kernel onto the machine in the first place. Until I see clear air under your feet via judicious use of your own bootstraps, I'll persist in making diskless booting work properly. Should you care to be part of the solution rather than part of the problem, I'd appreciate it if you could pick up a couple of network cards that boast PXE 2.0 compliant boot ROMs. I still hold out hope of having something minimally functional before Comdex, although the first step will probably still require BOOTP in the kernel. It was quite unnecessary and inappropriate to get so frazzled about this in public Matt. I'm not a moron, and labelling me such isn't really terribly productive. You could have made the points you tried to above without anywhere near as much angst, and I could have addressed them far more palatably as well. As a general rule, it's useful to assume that the person you're talking to is not a complete idiot. If it looks like they're behaving that way, you might want to double-check your assumptions before going off. It's a little more overhead, but it can save on the repercussions later. Regards, -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GENERIC build broken
I've settled Matt's qualms in private, since this was getting a little off track. Needless to say I'm quite on top of the current set of issues, and Matt's just a bit confused about what I'm trying to say. : great deal of work required to support this we're stuck with BOOTP : in the kernel. : :Er, hello? It's _already_been_done_, even. See above inre: netboot. Good god, you are talking about netboot? Hello? Mike, I get the feeling that you've never actually tried to use netboot. You seem to believe that it is direct replacement for BOOTP. It isn't even close. netboot only works with a very small number of ethernet cards while the BOOTP code in the kernel works with *all* ethernet cards that the kernel supports. netboot doesn't work with a single one of my machines. -Matt -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GENERIC build broken
I think there is only one thing that will ever allow us to remove the BOOTP code from the kernel, and that is if a time comes when the BIOSes for all standard off-the-shelf motherboards all have the ability to set a boot-from-network option. When/if that ever occurs, then we will be able to remove the code. I can tell you from experience that relying on standards without direct bios support across the board, or relying and ad-hoc programs like netboot, simply will not stand the test of time. What may appear to work fine now for X number of PC motherboards/ethercard brands will only work for X/2 number of PC motherboards/ethercards two years from now. Only something integrated into the kernel or something that uses the kernel's driver source directly can stand the test of time prior to ubiquitous BIOS integration. It is a sad but true fact. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GENERIC build broken
I think there is only one thing that will ever allow us to remove the BOOTP code from the kernel, and that is if a time comes when the BIOSes for all standard off-the-shelf motherboards all have the ability to set a boot-from-network option. When/if that ever occurs, then we will be able to remove the code. Please take a few minutes to go to developer.intel.com and read about PXE. Note that it's card-centric, not board-centric, so it doesn't require any buy-in from motherboard vendors. Also, because it's software only, there are already third-party vendors with software for most cards on the market. The last time I looked, InCom had support for well over 100 different network cards. With the general adoption of PXE in the WfM context for diskless WinTel installs, you can be certain that any network adapter with a bootrom socket is going to have PXE-compliant support available. If you want to participate in this dicussion much futher without dragging us off on these irrelevant tangents, it's quite important that you catch up on your reading. If you've been and looked at PXE more than a few months ago, go back again as they've massively updated the spec for PXE 2.0. Note that PXE 2.0, and UNDI in particular, go so far as to make it quite feasible to write a generic kernel driver that will talk to any PCI or PnP network adapter with a PXE-compliant bootrom. Not that I'm advocating this, you should understand. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
