* Dag-Erling Smorgrav [EMAIL PROTECTED] [000924 11:27] wrote:
Warner Losh [EMAIL PROTECTED] writes:
In message [EMAIL PROTECTED] The Hermit
Hacker writes:
: Okay, I'm a little confused here ... from what I'm reading/following, this
: isn't a new problem ... or is it? If not, why has it
Alfred Perlstein [EMAIL PROTECTED] writes:
This is basically a result of the entire kernel running at the
equivelant of splhigh, all interrupts are blocked until a context
switch in kernel land.
There's work in progress to mpsafe the drivers (at least for
ethernet, more will arrive later).
On Thu, 7 Sep 2000, Warner Losh wrote:
Also, this is interrupt level overflows. We can run the fast
interrupts fast enough to harvest characters from the hardware.
What's not happening is that sio's bottom half isn't being run fast
enough so the interrupt level buffers overflow.
Not
In message [EMAIL PROTECTED] The Hermit Hacker
writes:
: sio1: 32 more interrupt-level buffer overflows (total 32)
From the man page:
sio%d: interrupt-level buffer overflow. Problem in the bottom half of
the driver.
This likely means that the bottom half of sio isn't running fast
FYI, this is very likely not caused by the heavy weight
interrupt threads, but rather because the interrupt threads can't
be run because the giant lock is held by a process running in the
kernel. Once we get drivers to have their own locking and pulled out
from under the giant lock this
On Thursday, 7 September 2000 at 17:00:15 -0600, Chuck Paterson wrote:
FYI, this is very likely not caused by the heavy weight
interrupt threads, but rather because the interrupt threads can't
be run because the giant lock is held by a process running in the
kernel. Once we get drivers
On Thu, 7 Sep 2000, Warner Losh wrote:
In message [EMAIL PROTECTED] The Hermit Hacker
writes:
: sio1: 32 more interrupt-level buffer overflows (total 32)
From the man page:
sio%d: interrupt-level buffer overflow. Problem in the bottom half of
the driver.
This likely means
Also, this is interrupt level overflows. We can run the fast
interrupts fast enough to harvest characters from the hardware.
What's not happening is that sio's bottom half isn't being run fast
enough so the interrupt level buffers overflow.
Warner
To Unsubscribe: send mail to [EMAIL
On Thu, 7 Sep 2000, Warner Losh wrote:
Also, this is interrupt level overflows. We can run the fast
interrupts fast enough to harvest characters from the hardware.
What's not happening is that sio's bottom half isn't being run fast
enough so the interrupt level buffers overflow.
Okay, I'm
On Thu, 7 Sep 2000, Warner Losh wrote:
In message [EMAIL PROTECTED] The Hermit Hacker
writes:
: Okay, I'm a little confused here ... from what I'm reading/following, this
: isn't a new problem ... or is it? If not, why has it suddenly manifested
: itself with the new SMP code?
It seems
Bruce Evans wrote:
On Thu, 7 Sep 2000, Warner Losh wrote:
In message [EMAIL PROTECTED] The Hermit
Hacker writes:
: sio1: 32 more interrupt-level buffer overflows (total 32)
From the man page:
sio%d: interrupt-level buffer overflow. Problem in the bottom half of
the
In message [EMAIL PROTECTED] John Baldwin writes:
: My guess then is that we aren't scheduling the
: soft interrupt to harvest the data in the top half from the bottom half.
That's what I think as well.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current"
12 matches
Mail list logo
