Re: ntpd hanging machine
> On Mon, 28 Feb 2000, Matthew Frost wrote: > > > I'm experiencing some problems with ntpd. It would appear that a few > > (10-15) minutes after I start it, the machine crashes completely... > > > > Feb 28 14:10:02 egrorian ntpd[153]: ntpd 4.0.99b Mon Feb 28 12:12:17 GMT 2000 (1) > > Feb 28 14:10:02 egrorian ntpd[153]: using kernel phase-lock loop 2040 > > Feb 28 14:10:02 egrorian ntpd[153]: using kernel phase-lock loop 2041 > > > > And then locked solid.. > > I've been seeing the exact same behavior ever since the big ntp4 > merge. Until that point I was using the stock ntp4 from udel with no > problems. But I tried the one shipping with 4.0 and it locks up completely > (looks like a hardware lockup). The ntp4 from udel works completely > though. Odd :) Try disabling where it uses rtprio to set itself realtime and see if that "fixes" it. Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current lockups
> On 2000-Mar-07 06:29:17 +1100, Dave Boers <[EMAIL PROTECTED]> wrote: > >It is rumoured that Arun Sharma had the courage to say: > >> Compiling Mozilla with make -j 2 got -current to lock up, twice in > >> succession. I'm running a fairly recent snapshot (a week or two old) > >> on a Dual celeron box (BP6) with UDMA66 enabled. > > > >Finally. I've been complaining about this on several occasions. I'm also > >running UDMA66 and Dual Celeron BP6. No overclocking. > > Later postings mention possible problems with UDMA66. The other > possibility that has been discussed recently is potential priority > inversions for processes using rtptio and idprio. > > Note that ntpd will use rtprio if the Posix P1003.1b extensions aren't > enabled in the kernel. (These were enabled by default in GENERIC on > i386 in mid-January). If you have the new ntpd (rather than xntpd) > and are running a kernel without options P1003_1B, > _KPOSIX_PRIORITY_SCHEDULING and _KPOSIX_VERSION=199309L, you could > potentially get a lockup due to a priority inversion. (Though I > think the probability is very small). There's no difference between rtprio and P1003.1B scheduling other than the name. rtprio is the same as P1003.1B "SCHED_RR". I'd like to remove the rtprio call from ntpd. I think we ought to do it now before 4.0 ships. Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crash in currtprio, after dumping no operating system..
> > Hello > > Just about a hour ago cvsupped the latest sources and built world because > of fixes in vinum. I have /usr mounted to striped volume over three > disks. After reboot I had crash just a moment after the setiathome > processes started, the crash was in currtprio, I have two seti processes > sheduled to start with idprio 31. I did dump and rebooted, then found > myself sitting behind my desk and watching No Operating System Found > prompt. Boot blocks are there, my machine BIOS reports it. Sorry can't > provide more information as I need to recover first. Anyway, this is very > strange and I want to warn anybody first. My system is SMP, three > identical SCSI disks hooked up to the onboard AIC-7896. Three 256MB swap > partitions, separate root on the first disk and /usr on the striped > volume. Was it a panic saying currtprio != curproc->p_rtprio.prio? That was my fault, it's out now. Any SMP kernel from earlier today should re-sup. Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ntpd hanging machine
> On Thu, 2 Mar 2000, Matthew Dillon wrote: > > > :> > merge. Until that point I was using the stock ntp4 from udel with no > > :> > problems. But I tried the one shipping with 4.0 and it locks up completely > > > rtprio (and idprio) is virtually guarenteed to lockup your machine > > eventually. Don't use either. > > Unfortunately, ntpd in -current uses rtprio by default. > > Perter Dufault's recent changes fixed some related things, but not the > priority inversion problems. My guess is that the new ntpd now does something while it is rtpriod and it didn't used to. As far as I can tell the rtprio does nothing except maybe resume ntpd in preference to other readied kernel processes. The rtprio should be taken out of ntpd, it also (as I've talked over with Bruce) screws up the kernel priorities. This illustrates the danger of using it at all. With no way to bail out if you get upside down, any mods to the program are dangerous. It's probably almost safe to run a program rtprio or idprio if all you do is compute during that time and go back to time sharing before doing anything else, but be sure you're paged in, don't handle signals that way, etc... My "solution" would be to make rtprio lower priority than regular time sharing and if it needs to use any time sharing resources fault it or temporarily boost it up to time sharing. Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current lockups
> On 2000-Mar-09 10:05:21 +1100, Peter Dufault <[EMAIL PROTECTED]> wrote: > >There's no difference between rtprio and P1003.1B scheduling other than > >the name. rtprio is the same as P1003.1B "SCHED_RR". > > I wasn't aware of that. > > >I'd like to remove the rtprio call from ntpd. I think we ought to do > >it now before 4.0 ships. > > Given there is a known a priority inversion bug related to realtime > (or idle) scheduling, it would seem wise not to use it in any system > utilities. The relevant patch would appear to be (untested): > > --- /usr/src/usr.sbin/ntp/config.hTue Feb 1 13:56:05 2000 > +++ /tmp/config.h Thu Mar 9 11:46:11 2000 You have to do something in the "./configure" stuff. Hopefully someone in the know can suggest the "--with-no-foobar" option needed on the command line so I don't have to wade into it. Autoconfiguring POSIX realtime is a bad, bad idea because: 1. You don't know if it is available in all environments; 2. You don't know who is allowed to use it; 3. You don't know what the heck it does. It decidedly does not mean "run as fast as you can". Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MAX_UID ?
> If this was comp.std.c, then I'd agree that such constructs may fail > in some environments. It's not so clear that we need to worry about > this here (this being FreeBSD)... No, system headers should be sticklers to the standard to remain friendly to architectures BSD won't run on but the headers might be useful for. I can imagine non-byte addressable floating point DSPs with sizeof(char) == sizeof(double). I won't complain about the headers in a machine subdirectory. -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP
> there are very few values that could make sense in both Hours scale and > usecs scale.. > > thus items that could be small could be in uSecs and items that could > be big could be in Secs.. A small set of functions could be used to > make this uniform through the system > > syscall_Secs_to_hz(ulong *ticks, boolean Allow_zero SYSCTL_HANDLER_ARGS) > syscall_mSecs_to_hz(ulong *ticks, boolean Allow_zero, SYSCTL_HANDLER_ARGS) > syscall_uSecs_to_hz(ulong *ticks, boolean Allow_zero, SYSCTL_HANDLER_ARGS) How about struct timeval instead? 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: HEADS UP
> >> How about struct timeval instead? > > Timevals shouldn't be used in new interfaces. Use timespecs, which are > both Standard and more future proof. Agreed. > >Firstly we are talking about time deltas, and on the sysctl side of things > >it's very hard to set 'timevals (as you'd need to set two different > >variables) so you need a single value on teh userland side of things. > > sysctl can handle structs. The problems are that sysctl(8) has little or > no support for inputting structs, and timespec units might be inconvenient > (sysctl -w kern.quantum=0.00100 vs sysctl -w kern.quantum=1). We > already use microseconds instead of nanoseconds for kern.quantum because > nanoseconds resolution is unwieldy and not needed. # sysctl -w kern.quantum=1000us # kern.quantum: 1000us -> 1000us is an argument for settling on a single future proof structure. 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: (P)review: sigset_t for more than 32 signals
> Description:
> When we want to support Linux binaries in the future and possibly also want
> real-time signals, then we need to support more than 32 signals.
>
> Current status:
> The diffs result in a working backwards compatible GENERIC kernel. The
> linuxulator also doesn't seem to be broken. Recompiling programs (such as
> sh) also seems to work *in general*.
>
> Known problems:
> Building world fails because the freshly built cpp segfaults. A setjmp call
> that may be involved matches the problem of a return address being 0. gdb
> does not display a complete backtrace...
>
> Diffs:
> kernel/userland - http://www.FreeBSD.org/~marcel/signal.diff
> linux module - http://www.FreeBSD.org/~marcel/linux.diff
>
> To do:
> o LINT needs to be compiled to make sure most code has been changed,
> o most of userland still needs be touched,
> o the alpha port needs to be taken care of.
>
> Your suggestions, comments, criticism and participation is requested!
This is convenient, I had just been discussing this with someone.
Firstly, you should get rid of any explicit 32, 31, etc and anything
else tied to the assumed number of bits in an int.
Secondly, I'd personally make it scale to a ridiculous number of
signals such as 4096 by changing a single manifest constant to really
thrash things out.
Finally, an extract from some earlier thoughts about expanding
explicitly to 64 signals:
...
If we go with the moral equivalent of this struct (not really, see below):
typedef struct {
unsigned int n;
uint64_t v;
} sigset_t;
where "n" is the number of signals it will be easy to catch
broken programs using improperly initialized sigset_t's (only
valid value for "n" 64), and we'll be ready in case
once people start using pools of unnamed signals they want many.
To get around the issues (ordering i.e. n must be first in memory
so you can see how many signals in this implementation, new versions
of the compiler change alignment for uint64_t, etc), I'd make
it an array of three uint32_t. With machine specific sigset_t access
macros you could get back to manipulations of long longs.
Or let it be three native unsigned ints (some typedef unaffected
by compiler switches), put the array size in v[0], and let the size of
the array and the size of the int determine the value of NSIG or
vice-verse.
I would take an approach that will detect many broken programs, probably
the array of three native ints.
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: (P)review: sigset_t for more than 32 signals
> Description: > When we want to support Linux binaries in the future and possibly also want > real-time signals, then we need to support more than 32 signals... I thought about this a bit more and thought of a good two-step process: 1. Immediately do roughly what you displayed only without increasing the number of signals but instead using two sixteen bit ints, and commit after testing. This will be binary compatible with the existing syscalls and will start to compile-time break two classes of programs: Those using sigset_t access methods against non-sigset_t's; Those directly accessing sigset_t's. Programs doing both of these, i.e. directly manipulating unsigned longs on the i386, will not be detected but will continue to work as they do now. 2. Switch to the higher number of signals using the approach I suggested making the high 16 bits of the "header" word an unusual pattern of mask bits by looking at bits unlikely to ever be masked. This pattern is architecture dependent, but it doesn't matter much as long as the pattern is for the most widely used system, i.e., i386. By encoding the number of ints that follow in the array in the low order 16 bits you'll be limitted to 2,097,152+1 signals with this approach, but that won't be a restriction for a while. Now you can detect in the kernel calls likely to be from the final class of broken programs. 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: (P)review: sigset_t for more than 32 signals
> Peter Dufault wrote:
>
> > Firstly, you should get rid of any explicit 32, 31, etc and anything
> > else tied to the assumed number of bits in an int.
>
> You first need to get rid of any code that assumes that siget_t is an
> (unsigned) integer. Use macros to abstract the access to the new sigset_t
> so that you don't replace one assumption with the other...
But you want that code to break.
>
> > typedef struct {
> > unsigned int n;
> > uint64_t v;
> > } sigset_t;
>
> You can't use any BSD or FreeBSD specific types (such as u_int32)t) in
> publicly visible types (such as sigset_t). It breaks programs because it's
> not ANSI and/or Posix.
Further on you'll see I don't support this (this was a "dramatization"
of the structure), however, because the typedef ends in "_t" it is
reserved by POSIX for the implementation.
This is a particularly safe implementation typedef,
since I don't anticipate uint64_t ever being used in a future specification
as a different data type.
I don't know about ANSI.
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: (P)review: sigset_t for more than 32 signals
> Peter Dufault wrote:
>
> > 1. Immediately do roughly what you displayed only without increasing
> > the number of signals but instead using two sixteen bit ints, and
> > commit after testing.
> [snip]
> > 2. Switch to the higher number of signals using the approach I
> > suggested making the high 16 bits of the "header"
> > word an unusual pattern of mask bits by looking at bits unlikely
> > to ever be masked.
> [snip]
>
> You forget that you still need to be backwards compatible...
No -
What about binary compatability? You can't change the size of the
sigset_t without changing the system call.
I assumed you had added a new system call and kept
the old one for compatability along with a compatability header. I didn't
look closely enough at your patches.
I'll quickly type this so forgive the errors, and I hope Bruce
isn't following this.
First a compat/signal.h that sets up a few test macros and includes
for the new signal.h. This is used for compatability, however,
initially this will be signal.h and the new signal.h will be newsignal.h
to provide the "stay 32 bits and binary compatible and find broken programs"
period:
compat/signal.h:
#ifndef _COMPAT_SIGNAL_H_
#define _COMPAT_SIGNAL_H_
#include
/* Set up test macros to configure signal.h for compatability. */
/* Old number of signals: */
#define NSIG 32
/* Don't use a "header" that specifies number of signals: */
#define _SIGNAL_HEADER 0
#ifndef _SIGNAL_PIECES_T
/* Set up the typedef for signals. Use a pair of 16 bit integers
* to catch programs that cheat on using sigset_t access methods:
*/
#ifdef _SIGNAL_CATCH_BROKEN
typedef u_int16_t signal_pieces_t;
#else
typedef u_int32_t signal_pieces_t;
#endif
#define _SIGNAL_PIECES_T signal_pieces_t
#endif /* _SIGNAL_PIECES_T */
#include
#endif /* _COMPAT_SIGNAL_H_ */
Now a real signal.h:
#ifndef _SIGNAL_H_
#define _SIGNAL_H_
#include
/* Are we running in compatability mode? */
#ifndef _COMPAT_SIGNAL_H_
/* Not compat mode, set up for 64 bit signals */
#define NSIG 64
#define _SIGNAL_HEADER 1
#ifndef _SIGNAL_PIECES_T
typedef u_int32_t signal_pieces_t;
#define _SIGNAL_PIECES_T signal_pieces_t
#endif
#endif /* _COMPAT_SIGNAL_H_ */
/* Finally we can define our typedef. How many items do
* we need in our array, taking into account
*
* XXX Pretend we included the right thing to get _NBBY, the
* number of bits in a byte, I don't know what that may be.
*/
#ifdef _SIGNAL_HEADER
#define _SIGNAL_N ((NSIG / (sizeof(signal_pieces_t) * _NBBY) + 1))
#else
#define _SIGNAL_N (NSIG / (sizeof(signal_pieces_t) * _NBBY))
#endif
typedef struct {
signal_pieces_t s[_SIGNAL_N];
};
/* Now just insert the macros to make this work...
*/
. . .
#endif /* _SIGNAL_H_ */
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: (P)review: sigset_t for more than 32 signals
Not > #ifdef _SIGNAL_HEADER But > #if _SIGNAL_HEADER == 1 of course. 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: (P)review: sigset_t for more than 32 signals
> Anything that knows about sigset_t will already be using the POSIX > macros for it, since sigset_t was a POSIX invention. The old > `sigmask'-style functions don't have such an API, so they need to be > left as-is. (Such programs would not know about high-numbered signals > anyway, so this is no great loss.) OK, given this my attempt to force everyone to the POSIX style is misguided. 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: 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: randomdev entropy gathering is really weak
> The reason why ntp is interesting is that we compare the received data > with our unpredictable local clock. It is the result of this comparison > which is good entropy bits. Is the resolution of thermal sensors on many new motherboards and CPU high enough to get thermal randomness? Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
> In message <[EMAIL PROTECTED]> Peter Dufault writes: > : > The reason why ntp is interesting is that we compare the received data > : > with our unpredictable local clock. It is the result of this comparison > : > which is good entropy bits. > : > : Is the resolution of thermal sensors on many new motherboards and > : CPU high enough to get thermal randomness? > > Yes. You'll also find that the voltage drifts as well. However, I > doubt you'd be able to get more than 1 bit out of the voltage > readings. The thermal readings, depending on their precision, would > also yield several random bits. But this several may be only 3 or 4. > The temperature varies based on work load and on the climate controls > in place at the site. I actually meant can you get real randomness, measuring the thermal noise in the on-chip temperature diode should be a good source of randomness. Except they are probably "kind" enough to fully filter it out. Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
My naive addendum to Matt's recommended dev/test env
I've been off FreeBSD for a while. I've decided to follow Matt Dillon's recommendations for setting up an NFS development system from -stable to -current. Here are my notes for the naive on doing this. This is all obvious, if you're new or out of it this will save you a few hours getting up to date. Sorry that I'm belaboring the obvious, these notes together with the previous notes can be a time saver for the archives. In these notes, I will change the system name based on what OS it is running: either "release", "stable", or "current". Locate and read Matt Dillon's thread from November 2001 entitled "My Recommended Development/Testing environment for -current", see geocrawler or FreeBSD.org. You must be running -stable to build -current. It is a bug when -stable can't build -current, it is irrelevant when the latest formal release can't build -current. Thus you must start with the latest formal release. Install -stable identically to the way you install -current per Matt's notes. This gives you a way to track and build both -stable and -current. Matt assumes this is obvious. Do as much as possible non-root. Matt's warnings about "don't install -current on top of -stable!" are OK but better yet is do everything except "install" as yourself so that you can't wipe things out by mistake. The dangerous step from my point of view is installing a new -stable on top of your -release or -stable, -current work should be done on a crashable box. To support non-root builds, set up /usr/obj/FreeBSD as a directory owned by whomever you will build as. Assuming "as" is yourself, you can now do the build process without worrying about wrecking anything. Build -stable this way, logged in as yourself (I set up scripts with key words associated with "stable" or "current" just to make it easier): > release:~% cd /FreeBSD/FreeBSD-stable > release:/FreeBSD/FreeBSD-stable/% cvs checkout -r RELENG_4 src > release:/FreeBSD/FreeBSD-stable/% cd src > release:/FreeBSD/FreeBSD-stable/src/% make buildworld >& buildworld.out [OBSERVATION: This next part seems particularly succeptible to introduced bugs, I think I'm out of line according to the handbook in this next step, see the warnings in the handbook about using a new "config" executable to configure your kernel. Can't this handbook warning be folded into the "make buildkernel" from the working directory?] Still running the latest released kernel and still logged in as yourself build the -stable kernel: > release:/FreeBSD/FreeBSD-stable/src/% make buildkernel (bla-bla, kernel builds). You've gone as far as you can non-root. Now comes the part where you can wipe out your -stable system, and if you're like me, you're using your -stable system for at least some real work. Re-read the section in the handbook about doing backups and having copies of fixit floppies before upgrading to -stable. Once you've done, or decided not to do, such backups, become root, install the new kernel, and reboot to single user mode. Note Well: the handbook says pay attention to any additional make flags that you used in your "make" steps, you must use them in your "make installworld" as well. > release:/FreeBSD/FreeBSD-stable/src/% su (ohwha-tafool-iam) > release:/FreeBSD/FreeBSD-stable/src/# make installkernel (bla-bla, stable kernel installs on top of your release system) > release:/FreeBSD/FreeBSD-stable/src/# shutdown now > (bla bla, reboot -s, "Enter full pathname" etc, now you're single user > running the stable kernel with the release world) > # fsck -p > # mount -u / > # mount -a -t ufs > # swapon -a > # cd /FreeBSD/FreeBSD-stable/src > # make installworld (Lot's of noise as the stable kernel installs the stable world. Then reboot) > # sync > # reboot Now login as yourself running the stable kernel and the stable world. You're now up to date on stable, follow Matt's advice, only do it on the -stable box as yourself and not root. Specifically: Repeat the process and build -current on -stable, again as yourself, but don't do any installs - you will do the installs only on your crash -current box. > stable:~% cd /FreeBSD/FreeBSD-current > stable:/FreeBSD/FreeBSD-stable/% cvs checkout -r HEAD src > stable:/FreeBSD/FreeBSD-stable/% cd src > stable:/FreeBSD/FreeBSD-stable/src/% make buildworld >& buildworld.out (The -current world builds) Build the -current kernel, again as yourself: > stable:/FreeBSD/FreeBSD-stable/src/% make buildkernel >& kernel.out Now do all installs on the crash box. Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Posix feature tests update
Critique, please. I'm building a large body of code with the following cc options: > -D_POSIX_VERSION=199506L -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199506L and one of my own: > -D_P1003_1G_VISIBLE together with locally hacked up headers. Here's how I'm hacking. This could go into current if no one objects. 1. In "sys/_posix.h" the test macro _BSD_TRADITIONAL is defined if neither _POSIX_SOURCE nor _POSIX_C_SOURCE are defined. In most system headers, those items currently bracketed by > #ifndef _POSIX_SOURCE instead are bracketed by > #ifdef _BSD_TRADITIONAL 2. What I'd previously put in sys/_posix.h as > #define _P1003_1B_VISIBLE is replaced by > #define _P1003_1_199309 The notion is that prior to a draft being finalized it is fine to select it with _P1003_1B_VISIBLE (or _P1003_1G_VISIBLE) since you don't know the final _POSIX_VERSION and it should be viewed with suspicion, but once it is finalized it should be replaced by the _POSIX_VERSION numeric id. 3. I'd get rid of the verbose and unclear: #define _P1003_1B_VISIBLE_HISTORICALLY and replace it with the inline (that is, repeated in the headers) test > #if defined(_BSD_TRADITIONAL) || defined(_P1003_1_199309) 4. Everything added in the 1995 P1003.1 is bracketed by > #ifdef _P1003_1_199506 or > #if defined(_BSD_TRADITIONAL) || defined(_P1003_1_199506) as appropriate, i.e. if brand new it gets the first test, if pre-existing it gets the second. 5. Those items from the draft Posix 1003.1-G are bracketed by _P1003_1G_VISIBLE optionally or'd with _BSD_TRADITIONAL, as needed. -- It is useful to specify the Posix version, but right now the lack of networking support makes it only marginally useful. Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Posix feature tests update
> < said: > > > Critique, please. > > I have almost completely finished this work. Please join the > [EMAIL PROTECTED] mailing-list, where the patches were > posted several months ago, and where hopefully more discussion can > still take place. Good, I shall do so. Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Junior Kernel Hacker Task: M_ZERO
> I have introduced the M_ZERO flag to the kernel malloc, which provides > the service to bzero() the memory allocted. > > In the kernel sources, the archetypical change to use this facility > looks like this: > > Old code: >databuf = malloc(length, M_DEVBUF, M_WAITOK); >bzero(databuf, length); > > New code: >databuf = malloc(length, M_DEVBUF, M_WAITOK | M_ZERO); > > Short term the benefit is less clutter in the code and a smaller > cache footprint of the kernel. > > Long term, this will allow us to optimize malloc(9) by allocating > from a pool of memory which is zero'ed whenever the cpu is idle. I'm thinking you really want to split this into two cases - first, I want zeroed out memory NOW and second I want zeroed out memory when and if I'm called into action because it might not happen. You can have a ZFOD (zero fill on demand) fault give you a zeroed out page for the second case. For the first case I'm not sure what the optimization gives you other than indeterminacy. I'm also not clear when you want an idle task zeroing memory compared to a ZFOD type of operation for anyone expecting zeroed memory. I guess I'm suggesting a clarification on when you want to set this flag. If I want to be sure I get my zeroed out stuff real soon should I use still use bzero? Peter (couldn't afford BSDcon this year, looking forward to the right coast version) -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Typo in labpc.c
> > >> >This seems to only do the cdevsw_add if the malloc failed. I presume > >> >this is the opposit of the intended sense. I'll fix it up if you also > >> >think it looks wrong. > >> > >> If nobody have noticed in "17 months, 2 weeks ago" (as cvs-web says) > >> that labpc doesn't work, the labpc driver should be killed, not fixed. > >> > >> Objections ? > > > >What you are saying is that people who may be using this driver have > >not yet moved up to -current or 4.x and as such should not be allowed > >to? > > I'm saying: > >"If nobody have noticed in "17 months, 2 weeks ago" (as cvs-web says) >that labpc doesn't work, the labpc driver should be killed, not fixed." > > That's 1.5 year Julian, and if nobody *who is using it* objects it goes. For the record: If anyone wants labpc tested and kept up to date send me a card and I'll test it at each stable release cycle. Even better, also send me the register compatible DAQCARD 1200 PC card version. My former client using a batch of those cards obviously isn't staying up to date on the OS. Anyone who upgrades a working system will be just as upset if it doesn't work as if it is gone so I defer on the axe discussion. Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Typo in labpc.c
> > For the record: If anyone wants labpc tested and kept up to date send
> > me a card and I'll test it at each stable release cycle. Even better,
> > also send me the register compatible DAQCARD 1200 PC card version.
> >
> > My former client using a batch of those cards obviously
> > isn't staying up to date on the OS. Anyone who upgrades a working
> > system will be just as upset if it doesn't work as if it is gone
> > so I defer on the axe discussion.
>
> I gather you aren't in a position to test using your former client's
> cards.. ("former" is a bit of a clue I guess). What are the chances that
> he may decide one day to upgrade? (e.g. to support a new PC)
We aren't enemies, and they will probably be clients again. I
could test things down their on my own dime but it would be too
big a dime. I'd be better off buying a board on my own but I'm not
going to.
These are manufacturing test stands for medical equipment that have
been "validated" in their limited environment. They have identical
spare computers, will install 3.4, and set them up and test the
test stands following a formal step by step procedure. They don't
need me to help them and they probably won't upgrade for the life
of the current product unless they needed to change production
numbers.
Unlike many projects, this sort is extremely close-ended. One of
the things we do during release is to make sure every feature is
specified and has a test, and I happily go through and rip out
those features without that. That's why it is hard for me to argue
with Poul.
Peter
--
Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control,
HD Associates, Inc. Fail-Safe systems, Agency approval
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Fan speed control sony vaio lx800 slimtop
I've installed current on a Vaio LX800 slimtop, configured ACPI and can turn the thing on and off with the "power" button. By the way, the 4.2R to -current upgrade was painless. Now I'd like to figure out how to turn the damn fan up and down. This machine is quiet under windows but sets the fan to high under FreeBSD and never turns it down. The fan has three settings - 0V, 6V and 12V. Under windows it stays between 0 and 6V. I've tried "apm -h 1; apm -e 1;" hoping something would happen but it still doesn't slow down the fan. If someone can sketch out a road map of what I should do I'll do the dirty work. I don't know about ACPI etc and so would appreciate a kick start. I've picked up the spec but haven't printed it out yet. Peter PS minimal Sony Vaio LX700/LX800 technical info is available on the Italian Sony web site. -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fan speed control sony vaio lx800 slimtop
> > Note also that Scott Long ([EMAIL PROTECTED]) is also working on this, > > you will want to check with him to work out where he's up to... > > OK, I intended to try acpi_thermal hacking for the next target, now > I can be a tester and feed back something for Scott's hack :-) Note that there are no \_TZ_ entries in that "vaiolx800.asl" dump that I submitted for the ACPI collection. I'm not sure where that collection is - I don't see it off www.jp.freebsd.org/acpi, if anyone wants to see that .asl file I can put it somewhere public. I also haven't found any "PNP" devices corresponding to an ACPI fan (I forget the exact number) during boot -v. Would I have to do anything special to see it? If anyone has any other ideas of what to do let me know - I'm wondering if throttling down the CPU turns down the fan. In the meantime I've made terrific progress by putting "dynamat" sound absorbing material on the bottom of the plastic drum-like base of the Vaio, it is quieter and now my desk doesn't vibrate when the fan is on high. (www.dynamat.com, new web site in progress) Next I'll open it up and put dynamat on the inside of the plastic - I assume most heat loss is by convection and this won't make much difference. Once I do get the fan throttling working I'll have a real quiet system. Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fan speed control sony vaio lx800 slimtop
> It's possible that the EC is solely responsible for the fan, or that > Sony decided in their infinite wisdom to do it all in a driver somewhere. "acpiconf -s 1" switches the fan to its low setting, so we do know how to do it. Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fan speed control sony vaio lx800 slimtop
> > Would I have to do anything special to see it? If anyone has any > > other ideas of what to do let me know - I'm wondering if throttling > > down the CPU turns down the fan. > > It's possible that the EC is solely responsible for the fan, or that > Sony decided in their infinite wisdom to do it all in a driver somewhere. I have a new theory - do we need to enable some sort of suspend on halt for Intel chips? I see we do this for various cyrix chips, and I saw in a search that pentiums with MMX have "auto halt" and "low power on auto halt" options: http://www-student.informatik.uni-bonn.de:8001/~petera/lpp/ Do we enable these? I don't see any CPU_SUSP_HLT options in initcpu.c for Intel chips. Chip is > CPU: Pentium III/Pentium III Xeon/Celeron (801.82-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x686 Stepping = 6 > >Features=0x383f9ff > Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fan speed control sony vaio lx800 slimtop
I'm slightly hoping that enabling an AUTO HALT mode will turn the fan down. I don't think it will, I think I will have to do some subset of what "acpiconf -s 1" does in cpu_idle but will still respond to the next clock interrupt... So my two questions are: 1. Is there an obvious subset of S1 that would be an acceptable replacement for executing HLT and nothing happening in cpu_idle, and, 2. Does anyone understand "AUTO HALT", low power mode, etc on the Pentium III? I found programs (previous message has links) to enable power saving modes on Pentia, but they set a bit in "Model Specific Register 0x12: CTR0", and the Pentium III documentation says "code that accesses registers 11H, 12H, and 13H will generate exceptions on a P6 family processor". (IA-32 Software Developer's Manual, Volume 3: System Programming Guide, Intel order number 245472, page B-25) Peter (The system is reasonably quiet now with my additional sound proofing, but I'm afraid it isn't designed to continously run what was originally an unacceptably noisy fan). -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fan speed control sony vaio lx800 slimtop
I'm giving up on turning down the slimtop fan for now, the only way I can think of to figure out how Sony is turning down the fan is to boot windows, single step through the installation of the device drivers until I know which one is doing it, and then disassemble it to see what they're up to. If someone has any other ideas let me know. I might hook a scope up to the fan and boot windows just to see if it simply turning the fan down or is varying it. Maybe I'll add a voltage regulator and a few bits of control from the unused printer (it isn't run off the MB) and vary the fan speed brute force. I asked Sony support about the fan issue, they promptly replied that running the fan at high continuosly is fine, that no additional information is available, and that they will "record my interest in alternate operating systems". At least they have a polite way of saying they support nothing but Windows. So I'm going to roll this system back to 4.2 stable and start using it for work. If anyone wants me to try anything out with -current or ACPI then holler today. Two additional ACPI-APM things I did notice: 1. Putting APM into the config caused the keyboard switch to start working to turn the machine on. I'd taken it out at someones suggestion. This is weird, I can only guess APM does something as the machine powers off that ACPI doesn't. 2. Using APM to suspend the machine causes the LED on the power switch to turn amber, using "acpiconf -s 1" doesn't, the machine suspends but the LED stays green. If anyone has any little snippet they want me to try before going back to stable let me know. Anyway, if anyone buys one of these things then rubber bumpers on the base and Dynamat lining the plastic case makes it as quiet as a "normal" computer plus gives it a real solid feel. Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: I386_CPU
> Will Andrews <[EMAIL PROTECTED]> writes: > > Well, Warner, I've never done embedded systems. So, tell me, do they > > actually use any C++ code in embedded systems? C++ has a rather high > > overhead as far as disk space & memory goes. > > That's a myth. > > > I would imagine that 99%+ > > of embedded systems do not use C++ code except perhaps for a very small > > amount of the code. > > >From experience, I would imagine the reverse. OK, I'll pipe up. 1. I can't agree with you about the reverse, that 99% is C++ and 1% C, much more can and should be done in C++, and 2. When you know what you're doing there is no additional overhead in time and space using C++ versus C. Also, you won't be screwing around creating large amounts of messy "class code" housekeeping in C. I think the kernel could benefit from restricted C++ support. However, 3. Far too many people don't know at all what they're doing. One of the first things I noticed on a recent project was I couldn't compile and run it in simulation without running out of swap because objects representing the system memory map were being accidentally created but not referenced. C is much more forgiving of ignorance. Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel malloc and M_CANWAIT
> > why not just put it in a loop and block on lbolt? > > (or call panic) > > Because you shouldn't panic unless there's no alternative. Panicking > on resource starvation is just totally lame. We haven't used up the kernel name space yet. This sort of fundamental change should be enabled by a new flag and then added when handled. Changing things to return NULL pointers in the kernel where they never were before is equally lame. Without the appropriate work you're just pushing the panic off to a hard to find location. Peter -- Peter Dufault (dufa...@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: btokup() macro in sys/malloc.h
> A warning is just that. It's not an error, so don't treat it like one. I use different productions to enable different warnings on code with different histories. For one thing, new revs of the compiler will otherwise cause trouble when the warning behavior changes. I also use -Werror. Eliminating warnings is almost pointless without this. And yeah, I have a NO_WERROR flag for when I'm in a rush. I know -Werror is the eventual goal. So I disagree with Nate about ignoring warnings you've enabled - it is too easy to ignore a new problem. I agree with him that gratuitous casts and similar fixes during damn-the-torpedos mass conversions of large bodies of code are bad in that they can effectively hide latent problems more deeply than they were hidden before such a conversion. So IMHO: Eliminating warnings is good; Any mechanistic change to eliminate warnings that can mask problems can not be used. Peter -- Peter Dufault (dufa...@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Naming files in sys/kern
> < said: > > > It's not clear to me, when thinking of introducing a new file (say, for > > auditing support :), what I should name it. Would it be kern_audit.c or > > sys_audit.c? > > Depends on what it is auditing. If it only auditing the basic I/O > operations, then it would go in sys_*.c. If it's a more general > kernel facility, then it goes in kern_*.c. > > > Or, if it is POSIX.1e, would it go into a /usr/src/sys/posix1e > > directory as the posix4 realtime stuff did (assuming that support > > for additional features from that posix draft were going to be > > forthcoming)? > > Giving the unhelpful tendency of Project 1003 to renumber its > standards after-the-fact (or fold them into the main 1003.1 document), > I would suggest against using committee identifiers like this. This is posix4 due to my stupidity - I bought the O'Reilly "posix.4" book and changed the name to that even though I used to know better. I started with this in its own directory since it is supposed to be able to be enabled/disabled en masse via feature test macros, and because I wanted to keep all the posixy stuff in one place with calls out into the regular BSD kernel. Since the name is wrong, I think right thing to do now is make this directory something that means "posix_subsystem" and put similar chunks that follow similar rules there. That keeps the code associated with twisty standardized feature test macros in one place. Peter -- Peter Dufault (dufa...@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: LINUX clone? sched_yield?
> < said: > > > sched_yield() is a stub that informs you nicely that it doesn't exist :) > > Use the options: > > options "P1003_1B" > > options "_KPOSIX_PRIORITY_SCHEDULING" > > options "_KPOSIX_VERSION=199309L" > > Peter: is there any harm in enabling these features permanently? This bumps the version that the system says it is but I think the pieces are in place. If Bruce has any POSIX tests he can rebuild the system with POSIX_VERSION and _KPOSIX_VERSION set to 199309L and see what happens. This is the right thing to do for -current, and I have it turned on with a NO_KPOSIX_PRIORITY_SCHEDULING option in the patches I'm about to commit. Fixed-priority scheduling is broken in the SMP case and I'm planning on disabling both RTPRIO and _KPOSIX_PRIORITY_SCHEDULING on SMP unless one turns it on with RTPRIO_AND_SMP_ANYWAY. SMP and RTPRIO function but not correctly. Programs that assume that the presence of the header means the subsystem is present will fail on SMP the way they fail now. When my build world completes I'm planning on applying essentially the patches that are in my home directory on freefall in PATCHES.sched. Peter -- Peter Dufault (dufa...@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: LINUX clone? sched_yield?
> There's a yield() syscall that is enabled permanently. Is there any > harm in untangling it from the POSIX sched_yield()? :-) I've got a synch_yield() in kern_synch and a call into it from yield() in kern_thread that duplicates the yield() behavior for the non-RTPRIO, non-sched_yield() condition. synch_yield() also KASSERTS that p == curproc since nothing else makes sense. However, I've woken up to a gcc SIG 11 during my world build. This is from yesterday AM sources and is the first crash for my crash box. Though I doubt it is my patches I'll look a bit to convince myself. Prior to this that system has been running a week with a patched world. Peter -- Peter Dufault (dufa...@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
more about yield() versus sched_yield()
> I've got a synch_yield() in kern_synch and a call into it from yield() > in kern_thread that duplicates the yield() behavior for the non-RTPRIO, > non-sched_yield() condition. synch_yield() also KASSERTS > that p == curproc since nothing else makes sense. While we're discussing yield here's a question. The difference between yield() and sched_yield() is that yield unconditionally yields while sched_yield() won't if you are the highest priority process and the only process in your run queue. Does anyone know the reuirements on yield() and would it continue to function for us if it worked the same as sched_yield()? Peter -- Peter Dufault (dufa...@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: more about yield() versus sched_yield()
> Another difference is that it correctly counts context switches as voluntary.
Good point. The patched version calls maybe_resched(), and I'm
adding the line at "<<<".
(This also will let people who haven't looked at that code
complain about the function interface - it doesn't bother me,
macros could come later.)
/*
* prioritize: Compute a priority based on the type of scheduler.
*/
static priority_type
prioritize(struct proc *p)
{
priority_type priority;
int class = RTP_PRIO_BASE(p->p_rtprio.type);
if (class == RTP_PRIO_NORMAL) {
priority = (RTP_PRIO_NORMAL << 8) | (p->p_priority / PPQ);
}
else
priority = (class << 8) | p->p_rtprio.prio;
return priority;
}
/*
* curpriority_set: Set the current process priority to that of the process
* in the call.
*/
void
curpriority_set(struct proc *p)
{
newcurpriority = prioritize(p);
}
/*
* curpriority_cmp: Compare the priorities. Return:
* <0: p < curpriority
* 0: p == curpriority
* >0: p > curpriority
*/
static int
curpriority_cmp(struct proc *p)
{
priority_type prio = prioritize(p);
return prio - newcurpriority;
}
/*
* maybe_resched: Decide if you need to reschedule or not,
* taking the priorities and schedulers into account.
*
* This function needs to be call AFTER chk->p_priority has
* been updated.
*/
static void
maybe_resched(struct proc *chk)
{
if (curproc == 0)
need_resched();
else if (chk == curproc) {
/*
* If chk is curproc, we may need to preempt if
* we're making our priority less favorable.
*/
if (curpriority_cmp(chk) > 0) {
chk->p_stats->p_ru.ru_nvcsw++; /* <<< Adding */
need_resched();
}
}
/*
* If chk is not the curproc, we want to preempt if chk has
* a more favorable priority than curproc.
*
* We shouldn't preempt the current process because of the
* priority of a sleeping or stopped process.
*
*/
else if ((chk->p_flag & P_INMEM) &&
chk->p_stat == SRUN &&
curpriority_cmp(chk) < 0) {
need_resched();
}
}
--
Peter Dufault (dufa...@hda.com) Realtime development, Machine control,
HD Associates, Inc. Safety critical systems, Agency approval
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: more about yield() versus sched_yield()
> >(This also will let people who haven't looked at that code > >complain about the function interface - it doesn't bother me, > >macros could come later.) > > I might complain about style bugs, and typedefs named priority_type, > and magic conversions between priority_type and int. Or you might gently suggest improvements. Peter -- Peter Dufault (dufa...@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Weird piecemeal reads over socketpair() pipe breaks up small writes into even smaller reads.
> When the writer blocks, the reader runs and uses a buggy loop to read > only the first chunk of input. > > On an otherwise idle system, the need_resched() condition seems to be > true always. I would have expected the synchronisation provided by the > sleep(1) to bias need_resched() in the opposite direction. A reschedule > has been done, normally just after the previous hardclock() call, just > before the writer wakes up, so another one should not be done soon > (until after the next hardclock() call). Sorry everyone, I'll be away for a week and won't put in my scheduler fixes until I get back. Most of the changes are on Freefall in my home directory. I hate to be so passive about committing tested code, but my schedule is such over the last few months that I'm never around to fix things up if the unexpected happens. I'm working hard on a proposal that will let me spend some quality time on this - wish me luck. Meanwhile, I'm off all the lists. I'll check e-mail sent to either dufa...@hda.com or dufa...@freebsd.org intermittently. Peter -- Peter Dufault (dufa...@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: cvs commit: src/sys/conf kern.pre.mk (fwd)
On Mon, Feb 25, 2002 at 11:35:12PM -0700, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Mike Makonnen <[EMAIL PROTECTED]> writes: > : On Mon, 2002-02-25 at 20:59, M. Warner Losh wrote: > : > I've fixed a few of the low hanging fruit, but I don't know how to get > : > rid of warnings like: > : > > : > const char *foo = "blah"; > : > char *baz = foo; > : > > : > when I know they are safe. > : > : Correct me if I'm wrong, but isn't the correct declaration: > : > : const char foo[] = "blah"; > : char baz[] = "foo"; > > You miss the point. First, there's no "" around foo. Second, what I > quoted was boiled down from a bunch of macros and such. Third, the > real example would be > > volatile int conspeed; > int *foo = &conspeed; > > Where foo is only accessed before all other accesses to conspeed. When it is too twisty to fix at the moment I use macros such as: #define BOGUSLY_CAST_AWAY_VOLATILITY(T,P) ((T)(unsigned int)(P)) ... volatile int conspeed; int *foo = BOGUSLY_CAST_AWAY_VOLATILITY(int *, &conspeed); to surpress the warnings. You can easily redefine the macro to get them back so together with the discouraging name you're not sweeping things under the rug. I don't think there is a GCC attribute to get around this differently. Peter PS - this is a quick example, please no one comment on the size of unsigned int or using gcc typeof instead, etc. -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
