Messages in this thread |  | | | Date | Wed, 25 Nov 1998 13:20:15 -0500 (EST) | | From | George <> | | Subject | Keyboard dying due to console again? |
| |
After my computer's keyboard died (except for CTRL+ALT+DEL and ALT+SysRq) I remembered the 2.1.125 patch removed the disable/enable_bh() code from console.c with the following note:
/* * Console on virtual terminal * * NOTE NOTE NOTE! This code can do no global locking. In particular, * we can't disable interrupts or bottom half handlers globally, because * we can be called from contexts that hold critical spinlocks, and * trying do get a global lock at this point will lead to deadlocks. */ Well, there are still 6 cases of disable_bh/enable_bh in console.c:
do_con_write (4) con_font_op (2)
So, if the code isn't supposed to do locking in vt_console_print(), is it legal to do locking in do_con_write()?
I'm no expert, but somehow the symptoms of the earlier SMP keyboard deaths and my own SMP keyboard death now are strikingly similiar. So is the right fix to remove the last disable/enable_bh()'s?
Originally reproduced with a 32 thread program doing repeated debug writes to the screen as I was working in other consoles and occasionally switching over to check on it. Load average was about 40 and system worked fine other than the keyboard. I telnet'd in and everything was still going as it should have been. System is a dual Pentium 233MMX and Tyan Tomcat IV.
-George
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
|  |