Re: 'interrupt-level buffer overflows' for sio device?
* 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 suddenly manifested : itself with the new SMP code? It seems to be new with the SMP code. At least that's what my reading of the original message is. I'm seeing the same thing as Marc, but I have a little more info: 1) it started after the SMPng commit. 2) it's not just sio, it's everything: - interactive response is markedly slower. - the keyboard autorepeats slower than it used to (even with kbdcontrol -r fast). - I/O bound processes such as mpg123 or cvsup will pause briefly when there is other I/O going on (moving the mouse, typing fast, holding down a key on the keyboard), which they didn't use to. 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). -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 'interrupt-level buffer overflows' for sio device?
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). OK. Assuming I wanted to try and help with this work, where would be a good place to start finding out what needs to be done? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 'interrupt-level buffer overflows' for sio device?
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 surprising, since sio's bottom half scheduler (schedsofttty()) is now null. The top half apparently only gets scheduled if there is an output interrupt, a fake output interrupt (flags 0x8) a modem status change, or urgent data. Urgent data probably keeps it going for slip and pppd, but there is no urgent data in the termios line discipline. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 'interrupt-level buffer overflows' for sio device?
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 enough to harvest the characters in the interrupt level buffers. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 'interrupt-level buffer overflows' for sio device?
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 problem should deminish greatly. Before we can do this there are various infrastructure pieces which must be made mp safe, such as the lockmanger. Chuck To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 'interrupt-level buffer overflows' for sio device?
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 to have their own locking and pulled out from under the giant lock this problem should deminish greatly. Before we can do this there are various infrastructure pieces which must be made mp safe, such as the lockmanger. We're running sio as a fast interrupt, so it's definitely not because of a heavyweight thread :-) I think fast interrupts also completely bypass mutexes, though something might have changed since I last looked. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 'interrupt-level buffer overflows' for sio device?
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 that the bottom half of sio isn't running fast enough to harvest the characters in the interrupt level buffers. This means that fast interrupt handlers aren't actually fast. Especially if it occurs for slow devices like mouses. Even slow interrupt handlers had about 10 times lower latency than necessary for 1200 bps serial mouses. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 'interrupt-level buffer overflows' for sio device?
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] with "unsubscribe freebsd-current" in the body of the message
Re: 'interrupt-level buffer overflows' for sio device?
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 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? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 'interrupt-level buffer overflows' for sio device?
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 to be new with the SMP code. At least that's what my reading of the original message is. That was what I thought when I wrote the original message ... it just scares me sometimes how quickly things get acknowledged as a problem in the Open Source community, especially after dealign with tech support at Sun and getting the complete run around ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 'interrupt-level buffer overflows' for sio device?
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 driver. This likely means that the bottom half of sio isn't running fast enough to harvest the characters in the interrupt level buffers. This means that fast interrupt handlers aren't actually fast. Especially if it occurs for slow devices like mouses. Even slow interrupt handlers had about 10 times lower latency than necessary for 1200 bps serial mouses. Bruce Well unfortunately this doesn't make sense since the sio interrupt _is_ still fast, and thus is not run as a thread as other interrupts, but is run just like old fast interrupts were. However, there is an issue with sio right now in that it's not getting any input (actually, on my test machines, I can't get the stupid hardware to set the actual DCD bit, so I can't even open the devices *sigh*). My guess then is that we aren't scheduling the soft interrupt to harvest the data in the top half from the bottom half. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 'interrupt-level buffer overflows' for sio device?
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" in the body of the message
