Re: [Neomagic] newpcm problems under current
According to Cameron Grant: is the irq shared? have your printf display the neomagic status - i'll bet it's 0 indicating the irq was not generated by the neomagic. Ahem, yes it is shared, by almost everything on the machine. Should have thought of that... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [Neomagic] newpcm problems under current
Hmmm. I'm seeing something like this. I have an Gravis UltraSound MAX and mpg123 will play a list of songs correctly, but if I ^C out of it and try again, I see the "pcm0: play interrupt timeout, channel dead" message and it don't want to play again until a reboot. The gusc0 device is the only one using irq 5 and I have used this setup for quite a while. gusc0: Gravis UltraSound MAX at port 0x220,0x320-0x327,0x32c-0x333 irq 5 drq 1,3 flags 0x13 on isa0 pcm0: GUS CS4231 on gusc0 John -- John Hay -- [EMAIL PROTECTED] "me too" pcm0: NeoMagic 256AV mem 0xfda0-0xfdaf,0xfac0-0xfaff irq 5 at device 0.1 on pci1 pcm0: play interrupt timeout, channel dead Then EBUSY until the cows come home. I chatted with Cam some this evening; this problem seems to have come about as a result of driver restructuring. This chipset used to "just work" on my Dell notebook under some earlier 4.0 revision. On Sun, 6 Aug 2000, Ollivier Robert wrote: FreeBSD sidhe.freenix.org 5.0-CURRENT FreeBSD 5.0-CURRENT #19: Thu Aug 3 19:19:36 CEST 2000 roberto@sidhe:/src/src/sys/compile/nSIDHE i386 FreeBSD Audio Driver (newpcm) Aug 3 2000 17:03:04 Installed devices: pcm0: NeoMagic 256AV at memory 0xfe00, 0xfea0 irq 9 (1p/1r channels duplex) The first time I run mpg123, it does nothing (that is, no sound is emitted) and afterwards, /dev/dsp can't be opened at all... Robert N M Watson [EMAIL PROTECTED] http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
emu10k1 problems solved
Just wanted to say that with the recent changes in the emu10k1 driver all my problems with it have disappeared. There are no more "dodgy irq" messages and the sound quality has improved too (no more crackling). Great work Cameron. ___ Benedikt Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ugly, slow shutdown
On Sun, 06 Aug 2000 01:49:49 +1000, Stephen McKay wrote: I think shutdown time has gotten uglier and slower than it needs to be. Probably because you already understand what's going on. The existing text for the "stopping process" messages is designed to help folks stay calm while their machines apparently lock up at shutdown time. I think they're very healthy and should stay exactly as they are. The second patch is of no importance to me. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libexec/telnetd broken?
On Mon, 07 Aug 2000 10:06:54 +0900, Jun Kuriyama wrote: In file included from /usr/src/libexec/telnetd/sys_term.c:117: /usr/obj/usr/src/i386/usr/include/sys/tty.h:84: field `t_rsel' has incomplete type Not sure what caused this, but I saw it too last night. It seems to be fixed now, though. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ugly, slow shutdown
* Stephen McKay [EMAIL PROTECTED] [000805 08:49] wrote: Patch 2 is smaller and possibly controversial. Normally bufdaemon and syncer are sleeping when they are told to suspend. This delays shutdown by a few boring seconds. With this patch, it is zippier. I expect people to complain about this shortcut, but every sleeping process should expect to be woken for no reason at all. Basic kernel premise. You better bet it's controversial, this isn't "Basic kernel premise" it's quite possible and acceptable for some piece of code to expect this sequence: me someone else put myself at the head of a queue waiting for some resource finish with resource and perform wakeup assume wakeup was notification of resource availability and use it without checking for a 'stray' wakeup. *boom* *crash* *ow* :) I've been running these patches on a 4.x machine for a while now. No problems except I am now surprised by the slow and ugly shutdown of unpatched machines. :-) If you want to speed it up "properly" then either set up some protocol or do something along the lines of what speedup_syncer() does: if (updateproc-p_wchan == lbolt) setrunnable(updateproc); It 'knows' that the syncer is safe to wakeup when sleeping on lbolt (only) and only wakes it up then, otherwise it may be in some other random part of vfsbio and blow up. but... Actually I think that speedup_syncer() is somewhat bogus and should also check some sort of variable that says "syncer is idle" rather than lbolt, because we never know when an lbolt sleep may happen in the codepath. (ugh) The syncer would need to set this variable before sleeping to declare itself "safe" for per-emptive wakeup. It's a bit of hysteria but it's definetly possible. hope this helps, -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ugly, slow shutdown
* Stephen McKay [EMAIL PROTECTED] [000805 08:49] wrote: Patch 2 is smaller and possibly controversial. Normally bufdaemon and syncer are sleeping when they are told to suspend. This delays shutdown by a few boring seconds. With this patch, it is zippier. I expect people to complain about this shortcut, but every sleeping process should expect to be woken for no reason at all. Basic kernel premise. You better bet it's controversial, this isn't "Basic kernel premise" Actually, that depends. It is definitely poor programming practice to not check the condition for which you slept on wakeup. *boom* *crash* *ow* :) Doctor: So don't do that. In this case, the relevant processes just need to learn to check whether they've been woken in order to die. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ugly, slow shutdown
* Mike Smith [EMAIL PROTECTED] [000807 01:25] wrote: * Stephen McKay [EMAIL PROTECTED] [000805 08:49] wrote: Patch 2 is smaller and possibly controversial. Normally bufdaemon and syncer are sleeping when they are told to suspend. This delays shutdown by a few boring seconds. With this patch, it is zippier. I expect people to complain about this shortcut, but every sleeping process should expect to be woken for no reason at all. Basic kernel premise. You better bet it's controversial, this isn't "Basic kernel premise" Actually, that depends. It is definitely poor programming practice to not check the condition for which you slept on wakeup. Stephen's patches didn't give them that option, the syncer could be in some other part of vfs that doesn't expect to be woken up, perhaps in uniterruptable sleep... perhaps waiting for a DMA transfer? How does one check if the data filled into a buffer is actually from the driver and not just stale? *boom* *crash* *ow* :) Doctor: So don't do that. In this case, the relevant processes just need to learn to check whether they've been woken in order to die. No, they need to signify that it's safe to wake them up early. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ugly, slow shutdown
* Mike Smith [EMAIL PROTECTED] [000807 01:25] wrote:
* Stephen McKay [EMAIL PROTECTED] [000805 08:49] wrote:
... every sleeping process should expect
to be woken for no reason at all. Basic kernel premise.
You better bet it's controversial, this isn't "Basic kernel premise"
Actually, that depends. It is definitely poor programming practice to
not check the condition for which you slept on wakeup.
Stephen's patches didn't give them that option, the syncer could be
in some other part of vfs that doesn't expect to be woken up, perhaps
in uniterruptable sleep... perhaps waiting for a DMA transfer?
How does one check if the data filled into a buffer is actually from
the driver and not just stale?
The time honoured standard is:
raise cpu priority
while (we do not have exclusive use of some item) {
set some sort of "I want this item" flag (optional)
sleep on a variable related to the item
}
use the item/data we waited for
lower cpu priority
A typical example from vfs_subr.c:
s = splbio();
while (vp-v_numoutput) {
vp-v_flag |= VBWAIT;
error = tsleep((caddr_t)vp-v_numoutput,
slpflag | (PRIBIO + 1), "vinvlbuf", slptimeo);
if (error) {
splx(s);
return (error);
}
}
... the code plays a little with vp here ...
splx(s);
A simpler example from swap_pager.c:
s = splbio();
while ((bp-b_flags B_DONE) == 0) {
tsleep(bp, PVM, "swwrt", 0);
}
... code uses bp here ...
splx(s);
Both of these examples are safe from side effects due to waking up early.
This is how all such code should be. To do otherwise is to introduce possible
race conditions.
At your prompting, though, I've looked at more code and have found an example
that violates this principle. I assume it is a bug waiting to bite us. In
the 4.1.0 source (sorry, that's all I have on operational computers at this
moment) line 581 of vfs_bio.c sleeps without looping. It would seem that
Alfred's assertion of lurking danger is correct. This stuff should be fixed.
*boom* *crash* *ow* :)
Doctor: So don't do that.
In this case, the relevant processes just need to learn to check whether
they've been woken in order to die.
No, they need to signify that it's safe to wake them up early.
When I return to the land of FreeBSD I'll offer a speedup that does not wake
processes in arbitrary places (to avoid tickling lurking bugs). To do this
I would make processes that want to use the suspension mechanism call a
routine in kern_kthread.c for their just-loafing-about sleep. Then that
module will have enough information to do the job quickly.
And back to the simpler bit (the bike shed bit). Does everyone else actually
*like* the verbose messages currently used? And the gratuitous extra newline
in the "syncing..." message?
Stephen.
PS My main machine has blown its power supply. Contact with me will be patchy.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: When Good DIMMS go Bad (or how I fixed my sig11)
On Fri, 4 Aug 2000, Mike Muir wrote: :Stephen Hocking wrote: : : About a week ago, I complained of mysterious Sig 11s during a make world. : After some experimentation, a PC100 DIMM was found to be better suited for a : 66MHz memory bus in another machine, who obligingly donated a DIMM in return : that actually works with a 100MHz bus. I think the trip from Australia and : this Texas heat finally pushed the dodgy one over the edge. : :Have you tried any memory testing routines such as memtest86 ? Its the :only you write to a floppy and it runs before any bootstrap kicks in -- :independant of the OS -- and takes around 18 hours for a single pass. It :appears to be quite a comprehensive torture test. If so, how did that Software memory testers don't work. They may sometimes find problems, true, but if they don't, it doesn't mean the memory is good. Lots of failures are only triggered by certain access paterns, which is why it's so hard to convince people that their memory is bad. The only reliable way to test memory is with a hardware testor, or swapping known good memory in. David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ugly, slow shutdown
In message [EMAIL PROTECTED] Stephen McKay writes: : And back to the simpler bit (the bike shed bit). Does everyone else actually : *like* the verbose messages currently used? And the gratuitous extra newline : in the "syncing..." message? I like the newer messages in your patch, but I don't care enough to bikeshed this :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: When Good DIMMS go Bad (or how I fixed my sig11)
In message [EMAIL PROTECTED] David Scheidt writes: : convince people that their memory is bad. The only reliable way to test : memory is with a hardware testor, or swapping known good memory in. Yes. while (1) do ; make world; done is a close second to a hardware tester. I can't tell you the number of times I've had flakey systems that made people sure FreeBSD was busted. A new CPU, mobo or memory fixed these right up. Troubleshooting that can be interesting... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: When Good DIMMS go Bad (or how I fixed my sig11)
On Mon, 7 Aug 2000, Warner Losh wrote: :In message [EMAIL PROTECTED] David :Scheidt writes: :: convince people that their memory is bad. The only reliable way to test :: memory is with a hardware testor, or swapping known good memory in. : :Yes. while (1) do ; make world; done is a close second to a hardware :tester. Ah, that tells you have a problem. It unfortunatly, doesn't distinguish a bad memory module from a bad memory bus. One of my abits blew up a bit ago with SIGSEGVs, I swapped memory in and around till I got to the point that I realized that as long as I didn't populate the last DIMM slot, it worked fine. It's not long for this earth, that machine. David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: When Good DIMMS go Bad (or how I fixed my sig11)
On Mon, 7 Aug 2000, David Scheidt wrote: Ah, that tells you have a problem. It unfortunatly, doesn't distinguish a bad memory module from a bad memory bus. One of my abits blew up a bit ago with SIGSEGVs, I swapped memory in and around till I got to the point that I realized that as long as I didn't populate the last DIMM slot, it worked fine. It's not long for this earth, that machine. Reminds me of the 4-5 SIMM pair on Tyan Tomcat P5 SMP motherboards. They're notorious for not working. I've got a pair of those boards and cannot put exactly 6 SIMMs despite the claims of requiring pairs. It *really* wants SIMMs installed 4 at a time. They were nice boards otherwise though. Brandon D. Valentine -- bandix at looksharp.net | bandix at structbio.vanderbilt.edu "Truth suffers from too much analysis." -- Ancient Fremen Saying To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ugly, slow shutdown
: * Stephen McKay [EMAIL PROTECTED] [000805 08:49] wrote: : : Patch 2 is smaller and possibly controversial. Normally bufdaemon and : syncer are sleeping when they are told to suspend. This delays shutdown : by a few boring seconds. With this patch, it is zippier. I expect people : to complain about this shortcut, but every sleeping process should expect : to be woken for no reason at all. Basic kernel premise. : : You better bet it's controversial, this isn't "Basic kernel premise" : :Actually, that depends. It is definitely poor programming practice to :not check the condition for which you slept on wakeup. : : *boom* *crash* *ow* :) : :Doctor: So don't do that. I gotta agree. This is very bad programming practice. There are many, many places in the kernel where tsleep() is called with a 0 delay and assumed not to return until something meaningful happens. For example, for handling NFS retries, some of the locking code (I think), and I could probably find many others. In general 'quick hacks' only cause immense pain later on... sometimes years later on. It is NOT WORTH IT. In the case of buf_daemon, waking up the process is a definite no-no. You can wakeup lbolt, but you can't just go wakeup the process willy-nilly -- it could be sitting anywhere. What I would suggest is to add another argument to the shutdown event-handler registration, an optional wakeup address. If NULL, no wakeup is performed. Otherwise a wakeup on the specified address is performed. You can then pass lbolt to it when the syncer buf_daemon processes register. That is a simple, safe solution. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ugly, slow shutdown
In message [EMAIL PROTECTED], Matt Dillon writes: : * Stephen McKay [EMAIL PROTECTED] [000805 08:49] wrote: : : Patch 2 is smaller and possibly controversial. Normally bufdaemon and : syncer are sleeping when they are told to suspend. This delays shutdown : by a few boring seconds. With this patch, it is zippier. I expect people : to complain about this shortcut, but every sleeping process should expect : to be woken for no reason at all. Basic kernel premise. : : You better bet it's controversial, this isn't "Basic kernel premise" : :Actually, that depends. It is definitely poor programming practice to :not check the condition for which you slept on wakeup. : : *boom* *crash* *ow* :) : :Doctor: So don't do that. I gotta agree. This is very bad programming practice. There are many, many places in the kernel where tsleep() is called with a 0 delay and assumed not to return until something meaningful happens. For example, for handling NFS retries, some of the locking code (I think), and I could probably find many others. Then this code should be changed to do the right thing, which is to *always* check the condition being slept on before proceeding. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: Ugly, slow shutdown
In message [EMAIL PROTECTED], Alfred Perlstein writes: Then this code should be changed to do the right thing, which is to *always* check the condition being slept on before proceeding. Can you give a reason why we'll have to now start coding defensively because our arguments to tsleep() are just "advisory" now? It is not something we "suddenly have to do" it's been The Right Way even since I first sharpened my teeth on unix kernels many years ago. Coding defensively btw, is in the same category :-) I can also imagine some fun infinite loops like so: monitor issues wakeup producer wakes and terminates or goes away consumer spins checking on availability This is wrong code. It should be: monitor issues wakeup producer wakes and terminates or goes away consumer spins checking on producer still present and on availability You'll find plenty examples of such code in the tty code. Also, one must now do this? timeo = currenttime + 2; while (timeo != currenttime) tsleep(timeo); ? If the exact duration of your timeout is important, you should always calibrate it against getmicrotime() or getmicrouptime() (depending on it being UTC locked or not). This has also always been the case. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: Ugly, slow shutdown
Can you give a reason why we'll have to now start coding defensively because our arguments to tsleep() are just "advisory" now? It is not something we "suddenly have to do" it's been The Right Way even since I first sharpened my teeth on unix kernels many years ago. Uh, Poul, I think you're full of it. The previous behavior of tsleep where you can make assumptions about who wakes you and under what conditions is a long and well established idiom. We (the kernel developers of BSD) have always coded to the established kernel programming interface and most of us consider it bad form to check for conditions which can't happen because the kernel API doesn't allow it. For example, we don't check for a NULL return from malloc in the case of !NO_WAIT, because we knew that the code would never do that. There are many other examples of similar assumptions in the kernel. We write the code to be efficient and only check for bogus conditions that might happen. The only exception to this is programatic ASSERTs that do internal consistency checks, but the purpose of those is quite different. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org Manufacturer of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: When Good DIMMS go Bad (or how I fixed my sig11)
On Mon, 7 Aug 2000, David Scheidt wrote: On Mon, 7 Aug 2000, Warner Losh wrote: :In message [EMAIL PROTECTED] David Scheidt writes: :: convince people that their memory is bad. The only reliable way to test :: memory is with a hardware testor, or swapping known good memory in. : :Yes. while (1) do ; make world; done is a close second to a hardware :tester. Ah, that tells you have a problem. It unfortunatly, doesn't distinguish a bad memory module from a bad memory bus. One of my abits blew up a bit ago with SIGSEGVs, I swapped memory in and around till I got to the point that I realized that as long as I didn't populate the last DIMM slot, it worked fine. It's not long for this earth, that machine. Many motherboards are unstable when you populate all DIMM slots. You generally have limitations to what types of DIMMs you can use (i.e. single-sided only, registered only, etc.) when you do populate all of them. The manual _should_ specify these limitations. -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and Alpha architectures. ( http://www.freebsd.org ) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ugly, slow shutdown
Just a quick perusal of the kernel code shows a number of possible unexpected side effects from unexpected wakeups. I see several places where a 'WANTED' flag is set in a loop waiting for something and assumed to be cleared after the tsleep() returns. Some of these side effects are quite persistent. For example, if PG_WANTED is set in a page the VM system will activate the page rather then deactivate it. An unexpected wakeup in the VM system could lead to a page with PG_WANTED *LEFT* *SET* on the page! It might not be fatal, but it sure isn't the type of operation we want! There are a couple of places in the NFS code where a sleep wakeup results in a retry. There is a place where LC_EXPIREDWANTED is checked and causes a whole sequence of conditionals to be skipped. This is after 5 minutes of searching. I'm not going to spend N hours trying to find every case. Just finding two in 5 minutes is enough proof for me that it's just too dangerous to go and change expected tsleep/wakeup semantics without going through and auditing and documenting every piece of code that uses tsleep/wakeup. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
No Subject
auth 76254f08 unsubscribe freebsd-current [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ugly, slow shutdown
David Greenman wrote: Can you give a reason why we'll have to now start coding defensively because our arguments to tsleep() are just "advisory" now? It is not something we "suddenly have to do" it's been The Right Way even since I first sharpened my teeth on unix kernels many years ago. Uh, Poul, I think you're full of it. The previous behavior of tsleep where you can make assumptions about who wakes you and under what conditions is a long and well established idiom. We (the kernel developers of BSD) have always coded to the established kernel programming interface and most of us consider it bad form to check for conditions which can't happen because the kernel API doesn't allow it. For example, we don't check for a NULL return from malloc in the case of !NO_WAIT, because we knew that the code would never do that. There are many other examples of similar assumptions in the kernel. We write the code to be efficient and only check for bogus conditions that might happen. The only exception to this is programatic ASSERTs that do internal consistency checks, but the purpose of those is quite different. In the particular case of sleeping though, a woken process does need to check the condition that it slept on because one of the other processes sleeping on that resource may have had a chance to run first and changed some state. So as a general rule, you shouldn't assume that everything is fine when you return from being asleep because it might not be. I agree with your sentiment about defensive coding in the kernel though. Defensive coding should only be used on the boundary of your interface, i.e. if you're getting non-deterministic data from somewhere, most commonly user behaviour. Everything inside the kernel implementation should be deterministic and therefore there shouldn't be any need for defensive programming. Any cause of errors that defensive programming catches in the kernel can only be caused by bugs and therefore falls into the category of diagnostics. There's actually a lot of defensive programming creeping into the kernel which should really be wrapped in an #ifdef INVARIANTS. Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ugly, slow shutdown
In the particular case of sleeping though, a woken process does need to check the condition that it slept on because one of the other processes sleeping on that resource may have had a chance to run first and changed some state. So as a general rule, you shouldn't assume that everything is fine when you return from being asleep because it might not be. No, that's not true, and there are many examples in the kernel where a bogus wakeup would lead to bad things happening. I recall some code in the advisory locking code, and VM system, that assume that there is only one wakeup event and that the thing causing it assures that certain other things have occured before issuing it. That's just the way it has worked since the dawn of time. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org Manufacturer of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ugly, slow shutdown
David Greenman wrote: In the particular case of sleeping though, a woken process does need to check the condition that it slept on because one of the other processes sleeping on that resource may have had a chance to run first and changed some state. So as a general rule, you shouldn't assume that everything is fine when you return from being asleep because it might not be. No, that's not true, and there are many examples in the kernel where a bogus wakeup would lead to bad things happening. I recall some code in the advisory locking code, and VM system, that assume that there is only one wakeup event and that the thing causing it assures that certain other things have occured before issuing it. That's just the way it has worked since the dawn of time. I did say "as a general rule". If you know that "by design" nothing else is going to mess with what you're sleeping on before you wake up then you can make tighter optimisations but that's not the general case. There is such a thing as over optimisation though and for the sake of a simple if statement it is probably better to write code that is robust to changes made elsewhere in the system rather than squeeze every inch of performance out of the code, unless there's a real need to optimize in that particular area. Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ugly, slow shutdown
I did say "as a general rule". If you know that "by design" nothing else is going to mess with what you're sleeping on before you wake up then you can make tighter optimisations but that's not the general case. There is such a thing as over optimisation though and for the sake of a simple if statement it is probably better to write code that is robust to changes made elsewhere in the system rather than squeeze every inch of performance out of the code, unless there's a real need to optimize in that particular area. In some cases it isn't practical or very expensive to verify that the condition that caused the sleep in the first place has been satisfied - that's often why certain parts of the kernel rely on the established tsleep symantics. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org Manufacturer of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
mouse madness under X
This is a problem I've had starting with the last couple of builds. If I switch from X to a virtual console, then back again, *sometimes* the mouse cursor will be stuck on the right hand side of the screen. I can move it up and down, but not side to side. The way to cure the problem is to go back to the console, wait a few seconds, then come back into X. The problem goes away. At first I thought this was a problem with my wm, but I tried a different one and got the same result. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ugly, slow shutdown
In article [EMAIL PROTECTED], Alfred Perlstein [EMAIL PROTECTED] wrote: * Poul-Henning Kamp [EMAIL PROTECTED] [000807 10:03] wrote: Then this code should be changed to do the right thing, which is to *always* check the condition being slept on before proceeding. Can you give a reason why we'll have to now start coding defensively because our arguments to tsleep() are just "advisory" now? I'm not really sure why for a single reader/writer situation we have to have hysterics for a stray wakeup, it bloats code and is not needed in all places. It is just basic good programming practice. In his classic paper, "An Introduction to Programming with Threads" [1] Andrew Birrell argues for the explicit test in his discussion of condition variables, which are very similar to the kernel's tsleep/wakeup constructs. After giving a couple of purely technical reasons, he goes on to say: But the main reason for advocating use of this pattern is to make your program more obviously, and more robustly, correct. With this style it is immediately clear that the "expression" is true before the following statements are executed. Without it, this fact could be verified only by looking at all the places that might signal the condition variable. In other words, this programming convention allows you to verify correctness by local inspection, which is always preferable to global inspection. I will add that this is the pattern that Kirk teaches in his kernel internals class. [1] http://gatekeeper.dec.com/pub/DEC/SRC/research-reports/abstracts/src-rr-035.html John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ugly, slow shutdown
I will add that this is the pattern that Kirk teaches in his kernel internals class. If that's true, then he should practice what he preaches. Some of the code that I'm refering to (e.g. lockf) was apparantly written by him. I'll say again, however, that some of the cases that rely on the historical symantics would become very expensive if they had to go through a series of complex checks (perhaps list traversals, etc), in order to verify that the wakeup wasn't bogus. I personally don't think this is an improvement. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org Manufacturer of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ugly, slow shutdown
In article [EMAIL PROTECTED], David Greenman [EMAIL PROTECTED] wrote: I will add that this is the pattern that Kirk teaches in his kernel internals class. If that's true, Do you want me to fax you a copy of page 15 of his class notes from the course he gave at last year's FreeBSDCon, or will you just take my word for it? then he should practice what he preaches. Some of the code that I'm refering to (e.g. lockf) was apparantly written by him. Whether Kirk practices what he preaches is irrelevant to this discussion. Instead of focusing on a 1-sentence "I will add ..." from my posting, why not respond to the main thrust of it -- the paragraph I quoted from the Birrell paper? I'll say again, however, that some of the cases that rely on the historical symantics would become very expensive if they had to go through a series of complex checks (perhaps list traversals, etc), in order to verify that the wakeup wasn't bogus. I personally don't think this is an improvement. Some of them might be expensive, but most of them would not. Obviously the waker-upper knows that the condition is true. Otherwise the existing code which doesn't check wouldn't work. In the expensive cases the waker-upper could simply set a flag for the sleeper to check. Note, I am not expressing an opinion about whether the sleeps should be terminated prematurely during shutdown. But I am expressing a strong opinion about whether sleepers should do a reality check before proceeding. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
inheriting certificate trust
I've got a verisign'ed certificate for our webserver. According to Microsoft explorer/outlook, it can be used for verifying the servers identity, but not for mail. I've used this certificate to sign a new certificate, and Microsoft recognizes it and the trust chain, and will use it for verifying the servers identity, but not for mail. According to openssl x509, both certificates are usable for smime. Can I use the webserver certificate to make mail-certificates, or is it because the root CA at verisign is not for mail, then none of its children can be for mail? Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
