Re: error when make kernel using egcs-1.1.2pre
On Fri, Mar 05, 1999 at 04:40:33AM -0800, David O'Brien wrote: === make depend error === cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -DVM_STACK -include opt_global.h ../../i386/i386/genassym.c cc1: Invalid option `-fformat-extensions' *** Error code 1 If you are up to the task, you can download my bmake framework and modified EGCS sources that have this FreeBSD'ism. FTP the cvs repository from ftp.nuxi.com:/pub/FreeBSD/egcs. FTP Directory: ftp://ftp.nuxi.com/pub/FreeBSD/egcs/ Parent Directory .: Permission denied [As plain directory] -- Andreas Klemmhttp://www.FreeBSD.ORG/~andreas What gives you 90% more speed, for example, in kernel compilation ? http://www.FreeBSD.ORG/~fsmp/SMP/akgraph-a/graph1.html NT = Not Today (Maggie Biggs) ``powered by FreeBSD SMP'' To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
netscape trouebles
Hi, For quite some time now Netscape 4.5 has been very unstable on my -current system. I've cvsup'ed and made world many times in the hope the problem would go away. Today I decided to ktrace it, and see where it would stop. Of course it now refuses to crash. Even on java stuff that would crash it _every_ time without the ktrace. Now I can start my netscape with ktrace -f /dev/null netscape, and it'll probably be happy, although this is less than a satisfactory solution. I figure that the fact that it runs fine with the ktrace might mean something significant, although I wouldn't know what. So if anyone has an idea, I'd be delighted to hear about it. The system is a Celeron-366, not overclocked, running -current, XF3.3.3.1 and WindowMaker 0.51.0 and I have plenty of ram (160mb). Netscape is the only application giving me trouble. I've tried the FreeBSD version and the Linux version of Netscape, and they both behave the same. It appears that the Linux version is a bit less stable than the FreeBSD version. Am I the only one with this problem? Alex -- ++---+ | SMTP: ale...@funk.org | E-Gold: 101979 | | ICBM: N52 22.647' E4 51.555' | PGP: 0x1d512a3f | ++---+ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: netscape trouebles
For quite some time now Netscape 4.5 has been very unstable on my -current system. I've cvsup'ed and made world many times in the hope the problem would go away. Today I decided to ktrace it, and see where it would stop. Of course it now refuses to crash. Even on java stuff that would crash it _every_ time without the ktrace. Now I can start my netscape with ktrace -f /dev/null netscape, and it'll probably be happy, although this is less than a satisfactory solution. I figure that the fact that it runs fine with the ktrace might mean something significant, although I wouldn't know what. So if anyone has an idea, I'd be delighted to hear about it. I've had an unstable Netscape ever since upgrading to 3.x. There was quite a bit of discussion about this around a month ago, but no firm conclusion was reached. For me, it happens with MOZILLA_NO_ASYNC_DNS turned on (ie. no separate DNS lookup processes) *and* I access a site where the corresponding name servers take a long time to answer. I found some more discussion about Netscape hanging in a Linux related Web page, and the author has also produced a (Linux specific) patch. I include the README file below. Sorry, no URL, but it's real easy to find the package (search for Netscape-pipepatch) with ftpsearch. Steinar Haug, Nethelp consulting, sth...@nethelp.no -- The Netscape pipe overflow workaround = There is a known problem with most versions of Netscape currently in use, where the Netscape freezes when loading specific pages. The lockup is complete - there is no window refreshing and no reaction to the kill -TERM. The only way out is to kill the process with SIGKILL or from the window manager and to manually remove the lock file. The problem is timing-dependent - while most people seeing it can reproduce it using specific pages, these pages are different for different people. The cause of this problem is quite simple. On most (if not all Unixes) there is a limit on the pipe size and writing to a pipe will block, if the pipe is full. This limit is 4096 bytes on the Linux. The Netscape uses a pipe for some internal synchronisation and fails to take this into an account. When the pipe overflows, the Netscape locks up trying to write into the pipe and nobody reading it. The presented workaround is a side-effect of narrowing down this problem (the goal was to prove, if this is a kernel or application problem). It is NOT intended as a general solution to the problem (Netscape developers must fix it) and there is NO GUARANTEE that it doesn't break something else. However, the hack helped quite a lot of people and so I decided to publish it. The idea behind this hack is to insert a layer between Netscape and the libc, which catches the problematic pipe and fakes I/O operations that would otherwise cause the lock-up. Installation First you must know what version of Netscape you are using - the keywords here are libc5 and glibc (aka libc6). This is not necessarily the library your distribution defaults to - it is perfectly possible to use libc5 Netscape on a glibc-based system. ldd $MOZILLA_HOME/netscape | grep libc.so will probably give an idea, but there can be broken installations of ldd giving questionable results (e.g. libc.so.5 = not found is a valid answer for a libc5 installation). Next edit the Makefile and check the LIBC and LIBDL variables. These should be OK for a glibc Netscape, you will need to change them for a libc5 one (the instructions for doing this is in the Makefile). Compile and install the hack (the default destination is /usr/local/lib): make make install Now the tricky part - you must set the LD_PRELOAD environment variable to point to your hack somewhere where only Netscape can see it. Generally you do this in some starting script for netscape. As the distributions vary here, you are basically on your own. The patch for Red Hat 5.2 is included (file starting.script.rh52.patch). End remarks === The workaround is (C) 1999 Stanislav Meduna. The use, modification and distribution is completely free. There is ABSOLUTELY NO WARRANTY and i will NOT support the workaround. There ARE known problems - it is not known, if they are caused by the hack or only exposed by using it - I will NOT try to fix them. Some of the discussion on this hack is included in the file Discussion. If you include the workaround in some distribution, I would like to hear about it. Stanislav Meduna st...@eunet.sk 30. 1. 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: UPDATE2: ATA/ATAPI driver new version available.
It seems Steve Price wrote: [debug output omitted] I think I know what is failing now, I just have to find a fix for it.. -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
callout changes nit
I make a habit of checking out any interesting kernel changes in full, and one
thing I found in the recent diff by Mr. Wollman for kern_timeout.c is:
+void
+callout_init(c)
+ struct callout *c;
+{
+ bzero(c, sizeof c);
}
That doesn't look correct, does it?
Brian Feldman_ __ ___ ___ ___
gr...@unixhelp.org _ __ ___ | _ ) __| \
http://www.freebsd.org/ _ __ ___ | _ \__ \ |) |
FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: callout changes nit
At 10:59 AM 3/6/99 -0500, Brian Feldman wrote:
I make a habit of checking out any interesting kernel changes in full, and
one
thing I found in the recent diff by Mr. Wollman for kern_timeout.c is:
+void
+callout_init(c)
+ struct callout *c;
+{
+ bzero(c, sizeof c);
}
That doesn't look correct, does it?
Sure doesn't to me.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: callout changes nit
In article pine.bsf.4.05.9903061057250.11342-100...@janus.syracuse.net,
Brian Feldman gr...@unixhelp.org wrote:
I make a habit of checking out any interesting kernel changes in full, and one
thing I found in the recent diff by Mr. Wollman for kern_timeout.c is:
+void
+callout_init(c)
+ struct callout *c;
+{
+ bzero(c, sizeof c);
}
That doesn't look correct, does it?
Agreed. I think it should be sizeof *c.
John
--
John Polstra j...@polstra.com
John D. Polstra Co., Inc.Seattle, Washington USA
Nobody ever went broke underestimating the taste of the American public.
-- H. L. Mencken
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
SNAP -- Current
I installed 4.0-19990304-SNAP/src/sys and cvsup-ed to current . I found that the last changes of current are not included into snap/src/src (till 03/04/99). Is that o.k.? Val _ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: callout changes nit
I make a habit of checking out any interesting kernel changes in full, and one
thing I found in the recent diff by Mr. Wollman for kern_timeout.c is:
+void
+callout_init(c)
+ struct callout *c;
+{
+ bzero(c, sizeof c);
}
That doesn't look correct, does it?
Care to expand on why this looks wrong?
Nate
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: callout changes nit
I make a habit of checking out any interesting kernel changes in full, and
one
thing I found in the recent diff by Mr. Wollman for kern_timeout.c is:
+void
+callout_init(c)
+ struct callout *c;
+{
+ bzero(c, sizeof c);
}
That doesn't look correct, does it?
Agreed. I think it should be sizeof *c.
Ahh, I see. I think it should say
bzero(c, sizeof(struct callout));
To avoid the compiler using the size of the pointers et. al.
Nate
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: NTP nanokernel support (experimental)
According to Poul-Henning Kamp: Please send comments and observations, both positive AND negative. I can't get my DCF77 device to synchronize with both the kernel diff applied and 4.0.92c. With the older 4.0.90f I'm able to sync. remote refid st t when poll reach delay offset jitter == LOCAL(0)LOCAL(0)10 - 24 64 3770.0000.000 0.000 *GENERIC(0) .DCFa. 0 - 20 64 3570.000 10.664 0.617 ... remote refid st t when poll reach delay offset jitter == 127.127.1.0 127.127.1.0 10 - 57 64 3770.0000.000 0.000 *127.127.8.0 .DCFa. 0 -- 64 3570.000 15.090 0.193 I am very interested in seing some peerstats files for refclocks running this code. 51243 56309.281 127.127.8.0 96f5 0.011960917 0.0 0.0 0.002261763 51243 56310.281 127.127.8.0 96f5 0.011612083 0.0 0.0 0.001471172 51243 56311.291 127.127.8.0 96f5 0.011183750 0.0 0.0 0.000786827 51243 56312.285 127.127.8.0 96f5 0.011175333 0.0 0.0 0.000718346 51243 56356.278 127.127.8.0 96f5 0.014832500 0.0 0.0 0.002910501 51243 56357.274 127.127.8.0 96f5 0.015144083 0.0 0.0 0.003002719 51243 56358.278 127.127.8.0 96f5 0.015144583 0.0 0.0 0.002788572 51243 56359.274 127.127.8.0 96f5 0.015447583 0.0 0.0 0.002825388 51243 56360.274 127.127.8.0 96f5 0.015403750 0.0 0.0 0.002513153 51243 56361.278 127.127.8.0 96f5 0.015087917 0.0 0.0 0.001963783 51243 56362.285 127.127.8.0 96f5 0.015087917 0.0 0.0 0.001396828 51243 56363.278 127.127.8.0 96f5 0.01509 0.0 0.0 0.000193172 ... 51243 56494.272 127.127.8.0 96f5 0.014399417 0.0 0.0 0.000286762 51243 56495.277 127.127.8.0 96f5 0.014374750 0.0 0.0 0.000279898 51243 56496.277 127.127.8.0 96f5 0.014352500 0.0 0.0 0.000268971 51243 56497.269 127.127.8.0 96f5 0.014813083 0.0 0.0 0.000284027 51243 56497.652 127.127.8.0 96f5 0.014813083 0.0 0.0 0.000281249 -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #70: Sat Feb 27 09:43:08 CET 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NTP nanokernel support (experimental)
In message 19990306164238.a29...@keltia.freenix.fr, Ollivier Robert writes: According to Poul-Henning Kamp: Please send comments and observations, both positive AND negative. I can't get my DCF77 device to synchronize with both the kernel diff applied and 4.0.92c. With the older 4.0.90f I'm able to sync. It looks synchronized to me, it just looks like it hasn't swung in yet ? I find it very sluggish in reacting too, but I'm not sure yet if it is a feature or a bug. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: callout changes nit
On Sat, 6 Mar 1999, Nate Williams wrote:
I make a habit of checking out any interesting kernel changes in full,
and one
thing I found in the recent diff by Mr. Wollman for kern_timeout.c is:
+void
+callout_init(c)
+ struct callout *c;
+{
+ bzero(c, sizeof c);
}
That doesn't look correct, does it?
Agreed. I think it should be sizeof *c.
Ahh, I see. I think it should say
bzero(c, sizeof(struct callout));
To avoid the compiler using the size of the pointers et. al.
I prefer to do this in my own code, usually. However, using *c doesn't
use the size of the pointer.
Nate
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Brian Feldman_ __ ___ ___ ___
gr...@unixhelp.org _ __ ___ | _ ) __| \
http://www.freebsd.org/ _ __ ___ | _ \__ \ |) |
FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: callout changes nit
I make a habit of checking out any interesting kernel changes in full,
and one
thing I found in the recent diff by Mr. Wollman for kern_timeout.c is:
+void
+callout_init(c)
+ struct callout *c;
+{
+ bzero(c, sizeof c);
}
That doesn't look correct, does it?
Agreed. I think it should be sizeof *c.
Ahh, I see. I think it should say
bzero(c, sizeof(struct callout));
To avoid the compiler using the size of the pointers et. al.
I prefer to do this in my own code, usually. However, using *c doesn't
use the size of the pointer.
Understood, but the point being that Garrett is an experienced
programmer, and made this mistake. The latter version avoids any
possibilities of said mistake.
Nate
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: callout changes nit
Nate Williams wrote:
+void
+callout_init(c)
+ struct callout *c;
+{
+ bzero(c, sizeof c);
}
That doesn't look correct, does it?
Agreed. I think it should be sizeof *c.
Ahh, I see. I think it should say
bzero(c, sizeof(struct callout));
To avoid the compiler using the size of the pointers et. al.
This is largely a matter of taste, so we don't need to agree on it. :-)
But I do have a specific reason for preferring the sizeof *c
form. Namely, it reduces redundancy. The advantage is best seen if
you consider making a macro for clearing a structure. Here are two
possibilities:
#define CLEAR_STRUCT(ptr) bzero((ptr), sizeof *(ptr))
#define CLEAR_STRUCT(ptr, type) bzero((ptr), sizeof(type))
In this context, the 1-parameter form is indisputably less
error-prone. Of course, the context of the original example was
different. So I'm satisfied to say we are both right.
John
---
John Polstra j...@polstra.com
John D. Polstra Co., Inc.Seattle, Washington USA
Nobody ever went broke underestimating the taste of the American public.
-- H. L. Mencken
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: callout changes nit
On Sat, 6 Mar 1999, Nate Williams wrote:
I make a habit of checking out any interesting kernel changes in
full, and one
thing I found in the recent diff by Mr. Wollman for kern_timeout.c is:
+void
+callout_init(c)
+ struct callout *c;
+{
+ bzero(c, sizeof c);
}
That doesn't look correct, does it?
Agreed. I think it should be sizeof *c.
Ahh, I see. I think it should say
bzero(c, sizeof(struct callout));
To avoid the compiler using the size of the pointers et. al.
I prefer to do this in my own code, usually. However, using *c doesn't
use the size of the pointer.
Understood, but the point being that Garrett is an experienced
programmer, and made this mistake. The latter version avoids any
possibilities of said mistake.
It's just as easy to make the mistake of typing sizeof(struct foo *); I think
there should perhaps be a warning in gcc/egcs about this, like
-Wpointer-sizeof that would warn if you try sizeof(c) where c is a pointer,
but not sizeof(*c) or sizeof(void *). It would help find this kind of
thing, but of course would only be enabled by user-choice, not by default.
Maybe I should just write my own linter instead :)
Nate
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Brian Feldman_ __ ___ ___ ___
gr...@unixhelp.org _ __ ___ | _ ) __| \
http://www.freebsd.org/ _ __ ___ | _ \__ \ |) |
FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Lots of warnings in 4.0-CURRENT kernel build
I just built a new 4.0-CURRENT kernel yesterday and noticed that there seem to be more warnings generated than used to be. I rebuilt it today with the latest sources as of 3am March 6, built a new kernel from scratch (after deleting the entire old build dir), removed the cc lines, and got this set of warnings that I've appended to the end of this note. (The kernel does link successfully, and at least last night's kernel is running fine, so this isn't a really critical problem.) I do understand that some of the code is still being worked on, but I thought files such as if_fxp.c and ncr.c are relatively stable now. I'm curious if most people are building kernels without the default warnings or are just ignoring them? I'd be happy to go over all the files and get everything to compile without warnings, but as others have already discovered, the warnings may be indicating real bugs that need fixing. Perhaps the owners could take a closer look? Maybe there should be a daily kernel warnings posting to the mailing list to prompt the owners to fix the code? :-) Or a daily send-pr containing the latest kernel warnings generated? :-) Or am I just pointing out what everyone but me already knows is being worked on? -- Parag Patel kern/init_sysent.c:23: warning: cast discards `volatile' from pointer target type kern/kern_sysctl.c: In function `sysctl_register_set': kern/kern_sysctl.c:127: warning: cast discards `const' from pointer target type kern/kern_sysctl.c: In function `sysctl_unregister_set': kern/kern_sysctl.c:135: warning: cast discards `const' from pointer target type kern/sys_generic.c: In function `write': kern/sys_generic.c:251: warning: assignment discards `const' from pointer target type pci/if_fxp.c: In function `fxp_init': pci/if_fxp.c:1294: warning: passing arg 2 of `bcopy' discards `volatile' from pointer target type pci/if_fxp.c:1351: warning: passing arg 2 of `bcopy' discards `volatile' from pointer target type pci/if_fxp.c: In function `fxp_mc_setup': pci/if_fxp.c:1867: warning: passing arg 2 of `bcopy' discards `volatile' from pointer target type pci/ncr.c: In function `ncr_log_hard_error': pci/ncr.c:5333: warning: cast discards `volatile' from pointer target type pci/ncr.c: In function `ncr_exception': pci/ncr.c:5470: warning: cast discards `volatile' from pointer target type pci/ncr.c: In function `ncr_int_ma': pci/ncr.c:5773: warning: cast discards `volatile' from pointer target type pci/ncr.c:5777: warning: cast discards `volatile' from pointer target type pci/ncr.c:5801: warning: cast discards `volatile' from pointer target type pci/ncr.c:5808: warning: cast discards `volatile' from pointer target type pci/ncr.c:5816: warning: cast discards `volatile' from pointer target type pci/ncr.c:5821: warning: cast discards `volatile' from pointer target type pci/ncr.c:5831: warning: cast discards `volatile' from pointer target type pci/ncr.c:5835: warning: cast discards `volatile' from pointer target type pci/ncr.c: In function `ncr_regtest': pci/ncr.c:6803: warning: cast discards `volatile' from pointer target type pci/ncr.c:6804: warning: cast discards `volatile' from pointer target type In file included from dev/kbd/atkbd.c:336: dev/kbd/kbdtables.h:1151: warning: missing braces around initializer for `key_map.key[0]' i386/isa/ipl_funcs.c: In function `setdelayed': i386/isa/ipl_funcs.c:136: warning: cast discards `volatile' from pointer target type i386/isa/joy.c: In function `joyread': i386/isa/joy.c:169: warning: suggest parentheses around comparison in operand of i386/isa/sio.c: In function `comhardclose': i386/isa/sio.c:1338: warning: suggest parentheses around within || i386/isa/sio.c: In function `comparam': i386/isa/sio.c:2000: warning: suggest parentheses around within || i386/isa/snd/ad1848.c: In function `cs423x_attach': i386/isa/snd/ad1848.c:1587: warning: assignment from incompatible pointer type i386/isa/snd/ad1848.c: In function `opti931_attach': i386/isa/snd/ad1848.c:1690: warning: assignment from incompatible pointer type i386/isa/snd/ad1848.c: In function `opti925_attach': i386/isa/snd/ad1848.c:1755: warning: assignment from incompatible pointer type i386/isa/snd/ad1848.c: In function `guspnp_attach': i386/isa/snd/ad1848.c:1818: warning: assignment from incompatible pointer type i386/isa/snd/ad1848.c: In function `ad1816_intr': i386/isa/snd/ad1848.c:2039: warning: suggest parentheses around comparison in operand of i386/isa/snd/sbcard.h:358: warning: `sb16_recmasks_L' defined but not used i386/isa/snd/sbcard.h:376: warning: `sb16_recmasks_R' defined but not used libkern/index.c: In function `index': libkern/index.c:48: warning: cast discards `const' from pointer target type libkern/rindex.c: In function `rindex': libkern/rindex.c:52: warning: cast discards `const' from pointer target type pci/es1370.c:150: warning: initialization from incompatible pointer type i386/isa/snd/ulaw.h:40: warning: `dsp_ulaw'
fd broken
On Fri, 5 Mar 1999, Brian Feldman wrote: It seems that actually, not through my own fault, the fd driver is broken. I noticed this weeks ago but thought it a fluke since I only had the problem on one computer. However, on the school FreeBSD box, I also notice the same problem! The point is that previously, it had stopped working on my home box. Now, it also doesn't work on a different box that had been 3.0 before, and had fd working great. I have not made any modifications to the fd driver. fd0: recal failed ST0 70abnrml,seek_cmplt,equ_chck cyl 0 fd0: recal failed ST0 70abnrml,seek_cmplt,equ_chck cyl 0 fd0: recal failed ST0 70abnrml,seek_cmplt,equ_chck cyl 0 fd0: recal failed ST0 70abnrml,seek_cmplt,equ_chck cyl 0 fd0c: hard error reading fsbn 16 of 16-31 (No status) fd0: recal failed ST0 70abnrml,seek_cmplt,equ_chck cyl 0 fd0: recal failed ST0 70abnrml,seek_cmplt,equ_chck cyl 0 fd0: recal failed ST0 70abnrml,seek_cmplt,equ_chck cyl 0 fd0: recal failed ST0 70abnrml,seek_cmplt,equ_chck cyl 0 fd0c: hard error reading fsbn 0 (No status) fd0: recal failed ST0 70abnrml,seek_cmplt,equ_chck cyl 0 fd0: recal failed ST0 70abnrml,seek_cmplt,equ_chck cyl 0 fd0: recal failed ST0 70abnrml,seek_cmplt,equ_chck cyl 0 fd0: recal failed ST0 70abnrml,seek_cmplt,equ_chck cyl 0 fd0c: hard error reading fsbn 1 (No status) Hope someone knows :( I'll check the recent updates to the driver and see if one of them is at fault. None of them look like they could be at fault, at least easily. Can someone try using your floppy drive with the latest sources? It doesn't work in two 4.0 machines which have absolutely nothing in common except being 586en. Brian Feldman _ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve!_ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: fd broken
I have the same problem on 4.0-current SMP of Mon Feb 15 03:34:29 PST 1999. tomdean To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NTP nanokernel support (experimental)
According to Poul-Henning Kamp: It looks synchronized to me, it just looks like it hasn't swung in yet ? The two outputs I sent were with 4.0.90f. When I run 4.0.92c, ntpd is not able to get any accurate data from the device whereas 4.0.90f does. I get lots of these in /var/log/messages and it doesn't sync at all. -=-=- Mar 6 14:02:25 tara ntpd[7600]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 3 bits Mar 6 14:02:29 tara ntpd[7600]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 2 bits Mar 6 14:02:38 tara ntpd[7600]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 2 bits Mar 6 14:02:38 tara ntpd[7600]: PARSE receiver #0: FAILED TIMECODE: - (check receiver configuration / cableling) Mar 6 14:02:50 tara ntpd[7600]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 2 bits Mar 6 14:02:52 tara ntpd[7600]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 2 bits Mar 6 14:03:35 tara ntpd[7600]: PARSE receiver #0: no data from device within poll interval (check receiver / cableling) -=-=- Maybe it is a problem with 4.0.92c... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #70: Sat Feb 27 09:43:08 CET 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NTP nanokernel support (experimental)
This looks like a reception problem. You must be pretty far out in the reception area of DCF77 (just like me), and will probably find that whenever a sunrise or sunset is in the area reception sux. Try to see if it does better in daylight... I don't know the state of the DCF77/parse stuff in v4 at all, I have not tried to use it, I'm relying on my GPS for now. Poul-Henning In message 19990306200053.b30...@keltia.freenix.fr, Ollivier Robert writes: According to Poul-Henning Kamp: It looks synchronized to me, it just looks like it hasn't swung in yet ? The two outputs I sent were with 4.0.90f. When I run 4.0.92c, ntpd is not able to get any accurate data from the device whereas 4.0.90f does. I get lots of these in /var/log/messages and it doesn't sync at all. -=-=- Mar 6 14:02:25 tara ntpd[7600]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 3 bits Mar 6 14:02:29 tara ntpd[7600]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 2 bits Mar 6 14:02:38 tara ntpd[7600]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 2 bits Mar 6 14:02:38 tara ntpd[7600]: PARSE receiver #0: FAILED TIMECODE: - (check receiver configuration / cableling) Mar 6 14:02:50 tara ntpd[7600]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 2 bits Mar 6 14:02:52 tara ntpd[7600]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 2 bits Mar 6 14:03:35 tara ntpd[7600]: PARSE receiver #0: no data from device within poll interval (check receiver / cableling) -=-=- Maybe it is a problem with 4.0.92c... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #70: Sat Feb 27 09:43:08 CET 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
[no subject]
auth 99e0b1d8 unsubscribe freebsd-current hellr...@usa.net
Re: callout changes nit
On Sat, 6 Mar 1999 11:34:57 -0700, Nate Williams n...@mt.sri.com said: Understood, but the point being that Garrett is an experienced programmer, and made this mistake. The latter version avoids any possibilities of said mistake. ...and instead opens up the possibility of the same bug if the type of the structure is ever changed. I will fix this (currently harmless) problem later today. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same woll...@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NTP nanokernel support (experimental)
I just got a new set of PARSE patches from Frank Kardel, and I'm waiting for Dave Mills to give me the go-ahead to commit them. Dave is chasing some possible bugs and wanted a stable codebase for a while. H To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: callout changes nit
Ah,
bzero(c, sizeof *c);
I suppose.
Brian Feldman wrote:
I make a habit of checking out any interesting kernel changes in full, and one
thing I found in the recent diff by Mr. Wollman for kern_timeout.c is:
+void
+callout_init(c)
+ struct callout *c;
+{
+ bzero(c, sizeof c);
}
That doesn't look correct, does it?
Brian Feldman_ __ ___ ___ ___
gr...@unixhelp.org _ __ ___ | _ ) __| \
http://www.freebsd.org/ _ __ ___ | _ \__ \ |) |
FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: ATA driver
In article 199903051706.taa00...@hangdog.is.co.za, Geoff Rehmet geo...@is.co.za wrote: I've just decided to keep my list of bonnie tests running. I haven't pulled the latest changes yet, as CVSUP is basically a day behind from cvsup.za.freebsd.org. Are you sure? The CVSup server logs on freefall show that cvsup.za.freebsd.org has been updating itself reliably every hour. Or did you mean you're having trouble getting into it? If so, it might be worth trying cvsup2.za.freebsd.org instead. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Nobody ever went broke underestimating the taste of the American public. -- H. L. Mencken To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Typo in new atapi-all.c
In article 4.1.19990304100812.00cb0...@aire.open.ac.uk, Mike Zanker a.m.zan...@open.ac.uk wrote: At 10:03 04/03/99 , Sheldon Hearn wrote: I'm living in the past again. Fixed in rev1.225 of files.i386 . Update your src/sys/i386/conf, since LINT has been updated as well. Hmm, I just did but via cvsup.uk.freebsd.org. Maybe the fix hasn't propagated to there yet. For small updates that you want immediately, CVSWeb is your friend: http://www.freebsd.org/cgi/cvsweb.cgi John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Nobody ever went broke underestimating the taste of the American public. -- H. L. Mencken To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
State CPU255 in top(1) on an SMP box.
Hi! I cvsuped, made and installed the world at 04:00 7th May 1999 (JST) on my SMP box to find that the STATE in top(1) displayed CPU255 for some processes. I have only 2 CPUs... [/usr/src/usr.bin/top/machine.c:char *format_next_process(handle, get_userid)] if (smpmode PP(pp, p_oncpu) == 0xff) ^^ this should be '!='. Seigo TANIMURA |M1, Nakagawa Lab, Dept of Electronics CS =|Faculty of Engineering, Yokohama National Univ Powered by SIEMENS, |http://www.naklab.dnj.ynu.ac.jp/~tanimura/ FreeBSD 4.0-CURRENT |http://www.sakura.ne.jp/~tcarrot/ (7th Mar 1999) muesli. |tanim...@naklab.dnj.ynu.ac.jp tcar...@sakuramail.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: State CPU255 in top(1) on an SMP box.
[/usr/src/usr.bin/top/machine.c:char *format_next_process(handle, get_userid)] if (smpmode PP(pp, p_oncpu) == 0xff) ^^ this should be '!='. Oops. Thanks for the fix. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
