Re: lpd panic
> seems to be going ok, but I pick up a kernel panic whilst printing. Ditto. Also on a dual-cpu machine, also a really recent CURRENT. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
wall/rwall cleanups
Please review. This syncs up our code with some NetBSD changes, as well
as attempting to sync rwall up with wall.
Kris
Index: wall/wall.c
===
RCS file: /mnt/ncvs/src/usr.bin/wall/wall.c,v
retrieving revision 1.15
diff -u -r1.15 wall.c
--- wall/wall.c 2000/10/02 17:31:57 1.15
+++ wall/wall.c 2000/11/26 05:55:24
@@ -68,6 +68,7 @@
void makemsg __P((char *));
static void usage __P((void));
+char *ttymsg __P((struct iovec *, int, char *, int));
#defineIGNOREUSER "sleeper"
@@ -85,7 +86,7 @@
struct iovec iov;
struct utmp utmp;
FILE *fp;
- char *p, *ttymsg();
+ char *p;
char line[sizeof(utmp.ut_line) + 1];
(void)setlocale(LC_CTYPE, "");
@@ -109,7 +110,7 @@
makemsg(*argv);
if (!(fp = fopen(_PATH_UTMP, "r")))
- errx(1, "cannot read %s", _PATH_UTMP);
+ err(1, "cannot read %s", _PATH_UTMP);
iov.iov_base = mbuf;
iov.iov_len = mbufsize;
/* NOSTRICT */
@@ -144,17 +145,17 @@
time_t now;
FILE *fp;
int fd;
- char *p, *whom, hostname[MAXHOSTNAMELEN], lbuf[256], tmpname[64];
+ char *p, *tty, hostname[MAXHOSTNAMELEN], lbuf[256], tmpname[64];
+ const char *whom;
- snprintf(tmpname, sizeof(tmpname), "%s/wall.XX", _PATH_TMP);
-
- if (!(fd = mkstemp(tmpname)) || !(fp = fdopen(fd, "r+")))
- errx(1, "can't open temporary file");
+ (void)snprintf(tmpname, sizeof(tmpname), "%s/wall.XX", _PATH_TMP);
+ if ((fd = mkstemp(tmpname)) == -1 || !(fp = fdopen(fd, "r+")))
+ err(1, "can't open temporary file");
(void)unlink(tmpname);
if (!nobanner) {
- char *tty = ttyname(2);
- if (!tty)
+ tty = ttyname(STDERR_FILENO);
+ if (tty == NULL)
tty = "no tty";
if (!(whom = getlogin()))
@@ -175,7 +176,7 @@
"Broadcast Message from %s@%s",
whom, hostname);
(void)fprintf(fp, "%-79.79s\007\007\r\n", lbuf);
- (void)snprintf(lbuf, sizeof(lbuf),
+ (void)snprintf(lbuf, sizeof(lbuf),
"(%s) at %d:%02d %s...", tty,
lt->tm_hour, lt->tm_min, lt->tm_zone);
(void)fprintf(fp, "%-79.79s\r\n", lbuf);
@@ -183,7 +184,7 @@
(void)fprintf(fp, "%79s\r\n", " ");
if (fname && !(freopen(fname, "r", stdin)))
- errx(1, "can't read %s", fname);
+ err(1, "can't read %s", fname);
while (fgets(lbuf, sizeof(lbuf), stdin))
for (cnt = 0, p = lbuf; (ch = *p) != '\0'; ++p, ++cnt) {
if (ch == '\r') {
@@ -232,11 +233,11 @@
rewind(fp);
if (fstat(fd, &sbuf))
- errx(1, "can't stat temporary file");
+ err(1, "can't stat temporary file");
mbufsize = sbuf.st_size;
if (!(mbuf = malloc((u_int)mbufsize)))
- errx(1, "out of memory");
+ err(1, "out of memory");
if (fread(mbuf, sizeof(*mbuf), mbufsize, fp) != mbufsize)
- errx(1, "can't read temporary file");
+ err(1, "can't read temporary file");
(void)close(fd);
}
Index: rwall/rwall.c
===
RCS file: /mnt/ncvs/src/usr.bin/rwall/rwall.c,v
retrieving revision 1.8
diff -u -r1.8 rwall.c
--- rwall/rwall.c 1999/08/28 01:05:32 1.8
+++ rwall/rwall.c 2000/11/26 05:55:59
@@ -61,6 +61,7 @@
#include
#include
#include
+#include
#include
#include
@@ -70,8 +71,9 @@
int mbufsize;
char *mbuf;
-void makemsg __P((char *));
+void makemsg __P((char *));
static void usage __P((void));
+char *ttymsg __P((struct iovec *, int, char *, int));
/* ARGSUSED */
int
@@ -120,7 +122,7 @@
static void
usage()
{
- fprintf(stderr, "usage: rwall hostname [file]\n");
+ (void)fprintf(stderr, "usage: rwall hostname [file]\n");
exit(1);
}
@@ -131,14 +133,15 @@
struct tm *lt;
struct passwd *pw;
struct stat sbuf;
- time_t now, time();
+ time_t now;
FILE *fp;
int fd;
- char *whom, hostname[MAXHOSTNAMELEN], lbuf[256], tmpname[64];
+ char *tty, hostname[MAXHOSTNAMELEN], lbuf[256], tmpname[64];
+ const char *whom;
- snprintf(tmpname, sizeof(tmpname), "%s/wall.XX", _PATH_TMP);
- if (!(fd = mkstemp(tmpname)) || !(fp = fdopen(fd, "r+")))
- errx(1, "can't open temporary file");
+ (void)snprintf(tmpname, sizeof(tmpname), "%s/wall.XX", _PATH_TMP);
+ if ((fd = mkstemp(tmpname)) == -1 || !(fp = fdopen(fd, "r+")))
+ err(1, "can't open temporary file");
(void)unlink(tmpname);
if (!(whom = getlogin()))
@@ -156,23 +159,26 @@
Re: libc.so.4 not found
On Sat, Nov 25, 2000 at 10:28:53PM +0100, Leif Neland wrote: > Could this be the reason why Avp (virusscanner) for FreeBSD 4X just dumps > core on Fbsd current? > It works on a Fbsd stable. Could be malloc.conf defaults. i.e. a bug in avp triggered by the debugging /etc/malloc.conf settings in -current. Kris PGP signature
Re: -current on ibm tp a20p?
Christian Carstensen wrote: > On Fri, 24 Nov 2000, Rogier R. Mulhuijzen wrote: > > > 1) is this a CardBus card maybe? > > It happens with > >a) Lucent WaveLAN (silver) >b) 3com 3c589d > > > > 2) What does 'pccardc dumpcis' return? > > Code 85 not found > Code 85 not found > code Unknown ignored > Code 134 not found > Code 134 not found This means your pccard memory window overlaps something. Do you have an ATI rage chipset by any chance? My Vaio has one of these and its rom is 80K long and goes from 0xc -> 0xd3fff. pccardd defaults to 0xd for mapping the CIS which is right underneath the ROM. Try: pccard_mem="0xd4000" in /etc/rc.conf. Or even 0xd8000 if that doesn't work. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RFC: /dev/console -> /var/log/messages idea/patch
"David O'Brien" <[EMAIL PROTECTED]> writes: > On Fri, Nov 24, 2000 at 01:08:37AM +0100, Cyrille Lefevre wrote: > > > Its in the scrollback buffer. > > > > and how do you access the scroll-back buffer if you are not front to the > > console (read remote) ? > > Do you mean remotely loged in across the network, or a serial [remote] > console? If you mean the later the comconsole port logs all console > output to a file. remotly logged. at my job, I manage around 160 machines (unfortunaly, there is no FreeBSD) and I appreciate HP-UX boxes which have this feature. if something doesn't start at boot time, I've just to look at /var/adm/rc.log and search the FAIL keyword. don't rememeber about IRIX boxes, nothing exists under Solaris boxes. Cyrille. -- Cyrille Lefevre 12, Rue de Bizerte 75017 Paris tel/fax: +33 (0)1 45 22 83 85 home: mailto:[EMAIL PROTECTED] work: mailto:[EMAIL PROTECTED] icq: mailto:[EMAIL PROTECTED] http://wwp.icq.com/17089123 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RFC: /dev/console -> /var/log/messages idea/patch
Alexander Leidinger <[EMAIL PROTECTED]> writes: > On 24 Nov, Cyrille Lefevre wrote: > > >> >> The attached patch is a "proof-of-concept" on which I would like > >> >> to get some comments: > >> > > >> > I'm only a moronic user, but this would make my life easier. My machine > >> > switches into 132x43 on startup, and I always lose the output. So this > >> > >> Its in the scrollback buffer. > > > > and how do you access the scroll-back buffer if you are not front to the > > console (read remote) ? > > You can't. > > I didn't see the relationship between my answer to Ashley and your > question, can you please give me a hint? I just want to say that I'm full about doing something which logs what's happen at boot time, and that the scrollback buffer isn't sufficient. in other words, something like PR#14931 until this work is commited. Cyrille. -- home: mailto:[EMAIL PROTECTED] work: mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc.so.4 not found
On Sat, Nov 25, 2000 at 03:34:49PM -0800, Derek Schene' wrote: > I tried this- > > > I'd suggest just symlinking libc.so.4 to libc.so.5, nothing terrible > > should happen. Since nothing has changed in the -CURRENT libc yet, this will work. BTW, you'd want to do the same for libc_r.so.4. > Local package initialization:fopen: No such file or directory I would go into /usr/local/etc/rc.d/ and try to figure out *which* binary is causing all the trouble so the problem can be efficiently debugged. At this point you're skating around the problem rather than just hit it head on. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc.so.4 not found
Thanks for everyone's input, I feel I'm getting closer and see where my previous thinking had gone wrong. I tried this- > I'd suggest just symlinking libc.so.4 to libc.so.5, nothing terrible > should happen. and now when booting get- Local package initialization:fopen: No such file or directory So I copied libc.so.4 from the 4.0 livefile cdThis gave the same message (also had a core dump but may be unrelated). But the good news is now emacs, cvsup, etc. are working. I don't know if this matters but when looking at- implies that the -current packages on ftp.freebsd.org haven't been built since the bump and are thus slightly out dated. I'm thinking the snapshot came from current.freebsd.org? (SNAP5) And when it was mentioned- 2. a 4.1.1-RELEASE libc.so.4 was being used on a 4.0-RELEASE system. I thought I may have problems with using 4.0-RELEASE libc.so.4 on a 5.0-CURRENT system and may be better going with the symlink to libc.so.5? or look for a 4.2-RELEASE libc.so.4 up for people to download and put in /usr/lib/compat manually.? Thanks, Derek To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world broken: mbuf.h:120: `MSIZE' undeclared here
On Sat, 25 Nov 2000 18:01:33 -0500 (EST), Bosko Milekic <[EMAIL PROTECTED]> said: > jlemon, I think you may want to remove the include for > sys/mbuf.h in if_var.h if it isn't needed (try) -- I think this > is what may be screwing up netstat. I tried your suggestion and it got me past the problem I was having in kerberosIV (same error as Steve, different place) but stopped here: ===> libncp cc -O -pipe -march=i686 -I/usr/obj/usr/src/i386/usr/include -c /usr/src/lib/libncp/ipx.c -o ipx.o In file included from /usr/src/lib/libncp/ipx.c:41: /usr/obj/usr/src/i386/usr/include/net/if_var.h:95: field `ifq_mtx' has incomplete type -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA [EMAIL PROTECTED] [EMAIL PROTECTED] "Any movement in history which attempts to perpetuate itself, becomes reactionary." -- Josip Broz Tito To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world broken: mbuf.h:120: `MSIZE' undeclared here
No biggie guys... jlemon, I think you may want to remove the include for sys/mbuf.h in if_var.h if it isn't needed (try) -- I think this is what may be screwing up netstat. Sorry, Steve, for this inconvenience, but this stuff does occasionally happen in -CURRENT. :-) On Sat, 25 Nov 2000, Steve Kargl wrote: > ===> usr.bin/netstat > cc -O -pipe -Wall -DIPSEC -DINET6 -DIPSEC -I/usr/obj/usr/src/i386/usr/include -c >/usr/src/usr.bin/netstat/if.c > In file included from /usr/obj/usr/src/i386/usr/include/net/if_var.h:78, > from /usr/src/usr.bin/netstat/if.c:49: > /usr/obj/usr/src/i386/usr/include/sys/mbuf.h:120: `MSIZE' undeclared here (not in a >function) > /usr/obj/usr/src/i386/usr/include/sys/mbuf.h:120: size of array `MH_databuf' has >non-integer type > /usr/obj/usr/src/i386/usr/include/sys/mbuf.h:123: `MSIZE' undeclared here (not in a >function) > /usr/obj/usr/src/i386/usr/include/sys/mbuf.h:123: size of array `M_databuf' has >non-integer type > /usr/obj/usr/src/i386/usr/include/sys/mbuf.h:239: `MCLBYTES' undeclared here (not in >a function) > *** Error code 1 > > Stop in /usr/src/usr.bin/netstat. > *** Error code 1 > > > Sources are from today at 10:27 PST. > -- > Steve Cheers, Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
lpd panic
I'm finally having enough time again to look at FreeBSD again, so I went back and I'm looking at my port complaints. In looking at a2ps, after I reinstalled it fresh (so if it'd been changed I would see those) I see it seems to be going ok, but I pick up a kernel panic whilst printing. The process active at the time is (irq7:lpt0), the trace shows it's dying in fork_trampoline. I have a two processor machine in a very recent (hours old) current, and the panic is a "supervisor read, page not present". If this is familiar to anyone, please give me a shout (note I *am* running a smp kernel). If I get no reply, I guess I'm going to see about tracing this thing back. Thanks. Chuck Robey | Interests include C & Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel panic with ipfw pipes
Gentlemen, I'm holding up on committing this as we speak as I believe the counter manipulations become illegal following the ifq locking commits. This is good as it will give us an opportunity/bigger reason to review this code further before making a commit. Feel free to use the diff for yourselves for now. Cheers, Bosko. On Sun, 26 Nov 2000, Clive Lin wrote: > Hi, > > This works ! I was the dummynet victim due to dummynet, but now > I'm saved :-) Hopes this to be committed soon. > > On Thu, Nov 23, 2000 at 11:40:19AM +0800, Bosko Milekic wrote: > > Please try this patch and report: > > > > http://people.freebsd.org/~bmilekic/ip_pipe.diff > > -- > CirX - This site doesnt' exist. > 9c k9o h9 s1bg s1f, 7v .y xqx a sj m8r ffg1 vg5 a6 asox tmul h38. > ant sj m8r ob ? 1fj mwby a1 tao vg5. soq df v' .a. CirX. > > Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc.so.4 not found
On Sat, Nov 25, 2000 at 03:07:05PM -0700, [EMAIL PROTECTED] wrote: > I am not sure, if anybody care for this fix, but I just copied libc.so.5 > to libc.so.4 when kde was complaining about not finding it. I am not sure > if this should work, but it does work just fine... It will work for a while. But we'll have to offer -current users a proper libc.so.4 soon. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc.so.4 not found
I am not sure, if anybody care for this fix, but I just copied libc.so.5 to libc.so.4 when kde was complaining about not finding it. I am not sure if this should work, but it does work just fine... JAn On Sat, 25 Nov 2000, David O'Brien wrote: > On Sat, Nov 25, 2000 at 12:44:34PM -0600, Bill Fumerola wrote: > > > Huh? Why the worst of both worlds?? > > > > Incompatible changes AND no way to differentiate between the two. (plus we > > don't even know what changed it, so we have no way of telling people "your > > libc before X won't work with binarys that use the frobozz() interface) > > There wasn't an incompatible change. There is too much confusion on > this issue. There were two things that caused a problem. > > 1. a bug in libc_r such that programs that ran before, crashed. > 2. a 4.1.1-RELEASE libc.so.4 was being used on a 4.0-RELEASE system. > > #1 just showed off incorrect application code. > #2 has never been officially supported. > > > People who have binaries they can't recompile will need them. The fact that > > it pains our CVS tree really isn't an issue to me, > > This is -current, so people should be able to deal with the issue. I'll > probably put a 4.2-RELEASE libc.so.4 up for people to download and put in > /usr/lib/compat manually. > > > I'd like to think we have software engineering that utilizes source > > code management, and not the other way around. > > I would like to think that way too -- but that isn't the truth. > As I said, I'm willing to commit a compat lib now, but I don't want any > crap when I update it and the diff is the size of the file itself. > > -- > -- David ([EMAIL PROTECTED]) > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc.so.4 not found
On Sat, Nov 25, 2000 at 12:44:34PM -0600, Bill Fumerola wrote: > > Huh? Why the worst of both worlds?? > > Incompatible changes AND no way to differentiate between the two. (plus we > don't even know what changed it, so we have no way of telling people "your > libc before X won't work with binarys that use the frobozz() interface) There wasn't an incompatible change. There is too much confusion on this issue. There were two things that caused a problem. 1. a bug in libc_r such that programs that ran before, crashed. 2. a 4.1.1-RELEASE libc.so.4 was being used on a 4.0-RELEASE system. #1 just showed off incorrect application code. #2 has never been officially supported. > People who have binaries they can't recompile will need them. The fact that > it pains our CVS tree really isn't an issue to me, This is -current, so people should be able to deal with the issue. I'll probably put a 4.2-RELEASE libc.so.4 up for people to download and put in /usr/lib/compat manually. > I'd like to think we have software engineering that utilizes source > code management, and not the other way around. I would like to think that way too -- but that isn't the truth. As I said, I'm willing to commit a compat lib now, but I don't want any crap when I update it and the diff is the size of the file itself. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc.so.4 not found
On Sat, Nov 25, 2000 at 10:28:53PM +0100, Leif Neland wrote: > Could this be the reason why Avp (virusscanner) for FreeBSD 4X just dumps > core on Fbsd current? > It works on a Fbsd stable. no, if it was missing the proper version of libc, the linker would let you know about it. coredump is completly different. I'd suggest truss/kdump/etc to try and figure out what avp is doing differently on -current then -stable. -- Bill Fumerola - security yahoo / Yahoo! inc. - [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RFC: /dev/console -> /var/log/messages idea/patch
On Fri, Nov 24, 2000 at 01:08:37AM +0100, Cyrille Lefevre wrote: > > Its in the scrollback buffer. > > and how do you access the scroll-back buffer if you are not front to the > console (read remote) ? Do you mean remotely loged in across the network, or a serial [remote] console? If you mean the later the comconsole port logs all console output to a file. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc.so.4 not found
Could this be the reason why Avp (virusscanner) for FreeBSD 4X just dumps core on Fbsd current? It works on a Fbsd stable. Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
world broken: mbuf.h:120: `MSIZE' undeclared here
===> usr.bin/netstat cc -O -pipe -Wall -DIPSEC -DINET6 -DIPSEC -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/netstat/if.c In file included from /usr/obj/usr/src/i386/usr/include/net/if_var.h:78, from /usr/src/usr.bin/netstat/if.c:49: /usr/obj/usr/src/i386/usr/include/sys/mbuf.h:120: `MSIZE' undeclared here (not in a function) /usr/obj/usr/src/i386/usr/include/sys/mbuf.h:120: size of array `MH_databuf' has non-integer type /usr/obj/usr/src/i386/usr/include/sys/mbuf.h:123: `MSIZE' undeclared here (not in a function) /usr/obj/usr/src/i386/usr/include/sys/mbuf.h:123: size of array `M_databuf' has non-integer type /usr/obj/usr/src/i386/usr/include/sys/mbuf.h:239: `MCLBYTES' undeclared here (not in a function) *** Error code 1 Stop in /usr/src/usr.bin/netstat. *** Error code 1 Sources are from today at 10:27 PST. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RFC: /dev/console -> /var/log/messages idea/patch
In message <[EMAIL PROTECTED]>, Chuck Paterson writes: > > Is there reason to believe that we won't have dead lock >problems from the M_WAITOK? It seems like that if anything in >the path needed to full fill the malloc needs to log there >is a problem. We don't otherwise treat the /dev/console file descriptor magically. Think about ktracing a process which writes to /dev/console, debugging it and so on... One can successfully argue that the relationship between the console device and syslogd is needlessly incestous but until somebody restructures the console code to be more sanely (or even just at all) layered that is a "Sigh.. wouldn't it be nice if..." kind of item. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RFC: /dev/console -> /var/log/messages idea/patch
Is there reason to believe that we won't have dead lock problems from the M_WAITOK? It seems like that if anything in the path needed to full fill the malloc needs to log there is a problem. Chuck To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel panic with ipfw pipes
Hi, This works ! I was the dummynet victim due to dummynet, but now I'm saved :-) Hopes this to be committed soon. On Thu, Nov 23, 2000 at 11:40:19AM +0800, Bosko Milekic wrote: > Please try this patch and report: > > http://people.freebsd.org/~bmilekic/ip_pipe.diff -- CirX - This site doesnt' exist. 9c k9o h9 s1bg s1f, 7v .y xqx a sj m8r ffg1 vg5 a6 asox tmul h38. ant sj m8r ob ? 1fj mwby a1 tao vg5. soq df v' .a. CirX. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc.so.4 not found
On Sat, Nov 25, 2000 at 03:08:34AM -0800, David O'Brien wrote: > In this case it doesn't matter -- "a fresh hard drive" and "local > package" implies that the -current packages on ftp.freebsd.org haven't > been built since the bump and are thus slightly out dated. Plus all 3rd party software that provides only binaries (legato, glftpd, etc). Without the compat libraries or the symlink hacks these programs have no way of running. > > I'll renew my annoyance with the fact that we just bumped this without > > even figuring out why things broke or if we could change them in a way > > to save functionality without having to bump the version number[1]. > > It doesn't matter as at least Garrett has some changes he's going to make > that aren't compatible. libc.so will be at least at version "5" in > FreeBSD 5.0, so we'll have to go thru this pain eventually anyway. Suckage. At least we'll know the reason this time. > > We also never propagated this bump to RELENG_4, so the release shipped > > with the worst of both worlds. > > Huh? Why the worst of both worlds?? Incompatible changes AND no way to differentiate between the two. (plus we don't even know what changed it, so we have no way of telling people "your libc before X won't work with binarys that use the frobozz() interface) > I'm not quite sure what isn't together other than no compat4x libc.so.4 > yet -- I can certainly create one, but I'll have to update it for the > libc.so.4 in 4.3 and 4.4. Don't forget the compat libs are uuencoded > files, so CVS will see large diffs. If people don't mind, I'll certainly > make the compat libs now. People who have binaries they can't recompile will need them. The fact that it pains our CVS tree really isn't an issue to me, I'd like to think we have software engineering that utilizes source code management, and not the other way around. -- Bill Fumerola - security yahoo / Yahoo! inc. - [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Patch for current on LCA based alphas
LCA systems doesn't like probing after PCI slot 19.
Probing slot 20 panics the system.
The following patch made it into single user mode on my AXPpci33.
I asume it will also work on multias.
I can't tell more as the tested system is a 4.1-RELEASE and I need
to update the world before further testing.
Index: lca_pci.c
===
RCS file: /vol/cvs/FreeBSD/src/sys/alpha/pci/lca_pci.c,v
retrieving revision 1.7
diff -u -r1.7 lca_pci.c
--- lca_pci.c 2000/08/31 16:19:27 1.7
+++ lca_pci.c 2000/11/25 18:23:26
@@ -76,7 +76,7 @@
static int
lca_pcib_maxslots(device_t dev)
{
- return 31;
+ return 19;
}
#define LCA_CFGOFF(b, s, f, r) \
--
B.Walter COSMO-Project http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
-current dies in kerberosIV
cc -O -pipe -march=i686 -I/usr/src/kerberosIV/libexec/kipd/../../../crypto/kerberosIV/include -I/usr/src/kerberosIV/libexec/kipd/../../../crypto/kerberosIV/lib/roken -I/usr/src/kerberosIV/libexec/kipd/../../../crypto/kerberosIV/lib/krb -I/usr/src/kerberosIV/libexec/kipd/../../../crypto/kerberosIV/appl/kip -I/usr/src/kerberosIV/libexec/kipd/../../include -Wall -DHAVE_CONFIG_H -I/usr/obj/usr/src/kerberosIV/libexec/kipd/../../include -DBINDIR=\"/usr/bin\" -DSBINDIR=\"/usr/sbin\" -I/usr/obj/usr/src/i386/usr/include -c /usr/src/kerberosIV/libexec/kipd/../../../crypto/kerberosIV/appl/kip/kipd.c In file included from /usr/obj/usr/src/i386/usr/include/net/if_var.h:78, from /usr/src/kerberosIV/libexec/kipd/../../../crypto/kerberosIV/appl/kip/kip.h:78, from /usr/src/kerberosIV/libexec/kipd/../../../crypto/kerberosIV/appl/kip/kipd.c:36: /usr/obj/usr/src/i386/usr/include/sys/mbuf.h:120: `MSIZE' undeclared here (not in a function) /usr/obj/usr/src/i386/usr/include/sys/mbuf.h:120: size of array `MH_databuf' has non-integer type /usr/obj/usr/src/i386/usr/include/sys/mbuf.h:123: `MSIZE' undeclared here (not in a function) /usr/obj/usr/src/i386/usr/include/sys/mbuf.h:123: size of array `M_databuf' has non-integer type /usr/obj/usr/src/i386/usr/include/sys/mbuf.h:239: `MCLBYTES' undeclared here (not in a function) In file included from /usr/src/kerberosIV/libexec/kipd/../../../crypto/kerberosIV/lib/krb/krb.h:355, from /usr/src/kerberosIV/libexec/kipd/../../../crypto/kerberosIV/appl/kip/kip.h:87, from /usr/src/kerberosIV/libexec/kipd/../../../crypto/kerberosIV/appl/kip/kipd.c:36: /usr/src/kerberosIV/libexec/kipd/../../../crypto/kerberosIV/lib/krb/krb-protos.h:523: syntax error before `.' /usr/src/kerberosIV/libexec/kipd/../../../crypto/kerberosIV/lib/krb/krb-protos.h:533: syntax error before `.' /usr/src/kerberosIV/libexec/kipd/../../../crypto/kerberosIV/lib/krb/krb-protos.h:551: syntax error before `.' -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA [EMAIL PROTECTED] [EMAIL PROTECTED] "It's not what we don't know that hurts us, it's what we know for certain that just ain't so." -- Mark Twain To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Missing ithreads
I'm missing the ithread processes for irq10 and irq15. As you can see in the dmesg output there are de devices that are using the irqs in question. I asume that they are only missing in the list as the devices are working fine. PID TT STAT TIME COMMAND 0 ?? DLs0:00.16 (swapper) 1 ?? ILs0:00.06 /sbin/init -- 2 ?? DL 0:06.24 (pagedaemon) 3 ?? DL 0:00.00 (vmdaemon) 4 ?? DL 0:00.20 (bufdaemon) 5 ?? DL 0:07.21 (syncer) 10 ?? RL 702:28.90 (idle) 11 ?? WL 2:44.60 (swi1: net) 12 ?? WL32:02.76 (swi6: clock) 13 ?? WL 0:00.00 (swi4: vm) 14 ?? DL 0:00.87 (random) 15 ?? WL 0:00.00 (swi5: task queue) 16 ?? WL 0:01.49 (irq14: ata0) 17 ?? WL 0:39.49 (irq12: de0) 18 ?? WL 0:06.24 (irq11: de4) 19 ?? WL 0:00.01 (irq1: atkbd0) 20 ?? RL 9:05.12 (irq5: isic0) 21 ?? WL 0:00.00 (irq7: ppc0) 22 ?? WL 0:00.00 (swi0: tty:sio) 155 ?? Ss 2:14.50 ppp -auto gtn 225 ?? Ss 1:02.22 natd -f /etc/natd.conf 384 ?? Is 0:04.79 syslogd -s 393 ?? S real memory = 16777216 (16384K bytes) avail memory = 12795904 (12496K bytes) Preloaded elf kernel "kernel.ko" at 0xc03b6000. Intel Pentium detected, installing workaround for F00F bug md0: Malloc disk npx0: on motherboard npx0: INT 16 interface pcib0: at pcibus 0 on motherboard pci0: on pcib0 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xe800-0xe80f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 pcib1: at device 10.0 on pci0 pci1: on pcib1 de0: port 0xd800-0xd87f mem 0xfbdff000-0xfbdff07f irq 12 at device 4.0 on pci1 de0: Cogent EM440TX 21140A [10-100Mb/s] pass 2.0 de0: address 00:00:92:a7:13:40 de1: port 0xd400-0xd47f mem 0xfbdfe000-0xfbdfe07f irq 15 at device 5.0 on pci1 de1: Cogent EM440TX 21140A [10-100Mb/s] pass 2.0 de1: address 00:00:92:a7:13:41 de2: port 0xd000-0xd07f mem 0xfbdfd000-0xfbdfd07f irq 10 at device 6.0 on pci1 de2: Cogent EM440TX 21140A [10-100Mb/s] pass 2.0 de2: address 00:00:92:a7:13:42 de3: port 0xc800-0xc87f mem 0xfbdfc000-0xfbdfc07f irq 11 at device 7.0 on pci1 de3: Cogent EM440TX 21140A [10-100Mb/s] pass 2.0 de3: address 00:00:92:a7:13:43 pcib2: at device 11.0 on pci0 pci2: on pcib2 de4: port 0xb800-0xb87f mem 0xfbcff000-0xfbcff07f irq 11 at device 4.0 on pci2 de4: Cogent EM440TX 21140A [10-100Mb/s] pass 2.0 de4: address 00:00:92:a7:12:88 de5: port 0xb400-0xb47f mem 0xfbcfe000-0xfbcfe07f irq 12 at device 5.0 on pci2 de5: Cogent EM440TX 21140A [10-100Mb/s] pass 2.0 de5: address 00:00:92:a7:12:89 de6: port 0xb000-0xb07f mem 0xfbcfd000-0xfbcfd07f irq 15 at device 6.0 on pci2 de6: Cogent EM440TX 21140A [10-100Mb/s] pass 2.0 de6: address 00:00:92:a7:12:8a de7: port 0xa800-0xa87f mem 0xfbcfc000-0xfbcfc07f irq 10 at device 7.0 on pci2 de7: Cogent EM440TX 21140A [10-100Mb/s] pass 2.0 de7: address 00:00:92:a7:12:8b atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 isic0 at port 0x1b40-0x1b5f,0x1720-0x173f,0x720-0x73f,0xf20-0xf3f,0x1340-0x135f,0x340-0x35f,0xb40-0xb5f irq 5 flags 0x4 on isa0 isic0: passive stack unit 0 isic0: AVM A1 or Fritz!Card Classic ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode lpt0: on ppbus0 lpt0: Interrupt-driven port sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16450 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16450 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: can't assign resources DUMMYNET initialized (000608) i4b: ISDN call control device attached i4brbch: 4 raw B channel access device(s) attached IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to accept, unlimited logging i4bipr: 4 IP over raw HDLC ISDN device(s) attached (VJ header compression) i4bctl: ISDN system control port attached IPv6 packet filtering initialized, default to accept, unlimited logging i4btrc: 4 ISDN trace device(s) attached i4bing: 4 i4b NetGraph ISDN B-channel device(s) attached i4btel: 2 ISDN telephony interface device(s) attached i4bisppp: 16 ISDN SyncPPP device(s) attached (VJ header compression) IPsec: Initialized Security Association Processing. ad0: 1536MB [3121/16/63] at ata0-master WDMA2 Mounting root from ufs:/dev/ad0a [...] -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
kde2 upgrade fails in wierd fashion
This is strange. I deinstalled all kde11 type ports and then made installed the kde2 port. However, each time I got and startx, I stay with kde 1.1.2. I am using Xfree86 4.01 and a reasonably recent version of CURRENT. Has anybody got an explanation for this behavior? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RFC: /dev/console -> /var/log/messages idea/patch
In message <1050.974925641@critter>, Poul-Henning Kamp writes: > > The attached patch is a "proof-of-concept" on which I would like > to get some comments: > > It bugs me big time that the output from /etc/rc and all other output > to /dev/console is volatile and lost once it scrolls of your console. It's a no-brainer. Let's do it. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: [EMAIL PROTECTED] Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: INVARIANTS and -current
Steve Kargl <[EMAIL PROTECTED]> writes: > Eivind Eklund wrote: > > (Based on suggestion from Robert Watson.) > > > > I want to enable INVARIANTS by default in -current. This result in some > > slowdown, but it also makes it more likely that we'll find bugs quickly. > > People that want to run -current should know enough to disable it if it is > > in the way, anyway. > > I support your proposal. But, have a question: Has > anyone actually measured the performance impact of > INVARIANTS? I'm tempted to suggest that INVARIANTS > should be the default in not only -current in 5.0 > when she's released. Anyone interested in performance > in 5.0 will build custom kernels, and so he can turn > INVARIANTS off. sorry for the late answer. well, I'm not at all w/ you to enable INVARIANTS in -stable. the reason is simple. I had INVARIANTS for months (years?), but in september, I got plenty of "TRAP FAULT 12 and calcru: monotonisation" because of this. after disabling INVARIANTS, no problems anymore. I've posted a message about that in -stable w/ no answer, as I remember me. so, before to enable INVARIANTS in -stable or anywhere, the code should be much better checked, at least around kern_resource.c. Cyrille. -- home: mailto:[EMAIL PROTECTED] work: mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc.so.4 not found
On Sat, Nov 25, 2000 at 02:44:08AM -0600, Bill Fumerola wrote: > On Sat, Nov 25, 2000 at 12:18:43AM -0800, Derek Schene' wrote: > > On a fresh hard drive I installed 5.0 20001123 Current and got the > > following after installation: > > > > Local package initialization:/usr/libexec/ld-elf.so.1: Shared object > > "libc.so.4" not found > > we bumped the libc version to 5, but we didn't make compat4 libaries > available for installation yet. In this case it doesn't matter -- "a fresh hard drive" and "local package" implies that the -current packages on ftp.freebsd.org haven't been built since the bump and are thus slightly out dated. > I'll renew my annoyance with the fact that we just bumped this without > even figuring out why things broke or if we could change them in a way > to save functionality without having to bump the version number[1]. It doesn't matter as at least Garrett has some changes he's going to make that aren't compatible. libc.so will be at least at version "5" in FreeBSD 5.0, so we'll have to go thru this pain eventually anyway. > We also never propagated this bump to RELENG_4, so the release shipped > with the worst of both worlds. Huh? Why the worst of both worlds?? > To answer your question, though: > > I'd suggest just symlinking libc.so.4 to libc.so.5, nothing terrible > should happen. This should work until we get our act together regarding > this change. I'm not quite sure what isn't together other than no compat4x libc.so.4 yet -- I can certainly create one, but I'll have to update it for the libc.so.4 in 4.3 and 4.4. Don't forget the compat libs are uuencoded files, so CVS will see large diffs. If people don't mind, I'll certainly make the compat libs now. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc.so.4 not found
On Sat, Nov 25, 2000 at 12:18:43AM -0800, Derek Schene' wrote: > On a fresh hard drive I installed 5.0 20001123 Current and got the > following after installation: > > Local package initialization:/usr/libexec/ld-elf.so.1: Shared object > "libc.so.4" not found we bumped the libc version to 5, but we didn't make compat4 libaries available for installation yet. I'll renew my annoyance with the fact that we just bumped this without even figuring out why things broke or if we could change them in a way to save functionality without having to bump the version number[1]. We also never propogated this bump to RELENG_4, so the release shipped with the worst of both worlds. To answer your question, though: I'd suggest just symlinking libc.so.4 to libc.so.5, nothing terrible should happen. This should work until we get our act together regarding this change. -- Bill Fumerola - security yahoo / Yahoo! inc. - [EMAIL PROTECTED] / [EMAIL PROTECTED] 1. to my knowledge. I tried to keep up on this thread but its possible someone figure it out and we just didn't revert the libc bump. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
libc.so.4 not found
On a fresh hard drive I installed 5.0 20001123 Current and got the following after installation: Local package initialization:/usr/libexec/ld-elf.so.1: Shared object "libc.so.4" not found I tried again from scratch with 5.0 20001124 Current and have the same problem. This affects emacs, apache, and unfortunately cvsup I have played with some symbolic links with no luck. This came from reading- http://www.freebsd.org/handbook/linuxemu-lbc-install.html#LINUXEMU-LIBS-PORT but I don't think this has anything to do with Linux Binary Compatibility. This was the closes I came when searching on ld-elf.so.1 and libc.so.4 Note the only change between my 11/23 and 11/24 install was I added Netscape Communicator 4.74 and got- xfree86-aoutlibs-3.3.3 installation aborted error code 1 Any ideas on the libc? Derek To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
