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
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
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
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
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,
* 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
* 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
* 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.
* 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
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
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
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
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
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
: * 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
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
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
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
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.
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
auth 76254f08 unsubscribe freebsd-current [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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.
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
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
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
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
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
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], 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
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
30 matches
Mail list logo
