On Tue, 08 Aug 2000, you wrote:
> 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.
>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'
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
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 FreeBSD
>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
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
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 ba
>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
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 should
>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 fi
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
auth 76254f08 unsubscribe freebsd-current [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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
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.
> :
>>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 y
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 tslee
* Poul-Henning Kamp <[EMAIL PROTECTED]> [000807 10:03] wrote:
> 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 wh
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
:> * 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 peop
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
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 sec
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 th
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
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 re
> * 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 i
* 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 bor
> * 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
>
* 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 complai
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, thoug
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 mac
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 PROTE
31 matches
Mail list logo
