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
* 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,
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 suddenly manifested
> : itself with the new SMP code?
> It s
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 sur
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"
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
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?
>
> I
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 to be new with the SMP code. At least that's
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
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 PROTECTED]
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 lik
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 driv
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 pr
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
this corresponds to the device I have the mouse on ... the machine has
only been up 18hrs ... not sure where else to look ... I'm referencing
/dev/ttyd1, like I've always done for my mouse, and just checked /dev (ran
MAKEDEV ttyd1) to make sure nothing has changed there ...
Help?
sio0 at port 0
15 matches
Mail list logo