diff options
author | rtm <rtm> | 2006-08-10 02:07:10 +0000 |
---|---|---|
committer | rtm <rtm> | 2006-08-10 02:07:10 +0000 |
commit | 8a8be1b8c36e38f58f8ba3e425b6e701ad65abf3 (patch) | |
tree | 8e04f2b39be9be0a06e2b14c2b24ed7328766c7e /Notes | |
parent | 28d9ef04ddaa4cf32f3c63c976afdc535a36db98 (diff) | |
download | xv6-labs-8a8be1b8c36e38f58f8ba3e425b6e701ad65abf3.tar.gz xv6-labs-8a8be1b8c36e38f58f8ba3e425b6e701ad65abf3.tar.bz2 xv6-labs-8a8be1b8c36e38f58f8ba3e425b6e701ad65abf3.zip |
low-level keyboard input (not hooked up to /dev yet)
fix acquire() to cli() *before* incrementing nlock
make T_SYSCALL a trap gate, not an interrupt gate
sadly, various crashes if you hold down a keyboard key...
Diffstat (limited to 'Notes')
-rw-r--r-- | Notes | 38 |
1 files changed, 38 insertions, 0 deletions
@@ -241,3 +241,41 @@ maybe a race; acquire does cpu = cpu() what if another acquire calls holding w/ locked = 1 but before cpu is set? + +if I type a lot (kbd), i get a panic +cpu1 in scheduler: panic "holding locks in scheduler" +cpu0 also in the same panic! +recursive interrupt? + FL_IF is probably set during interrupt... is that correct? +again: + olding locks in scheduler + trap v 33 eip 100ED3 c (that is, interrupt while holding a lock) + 100ed3 is in lapic_write +again: + trap v 33 eip 102A3C cpu 1 nlock 1 (in acquire) + panic: interrupt while holding a lock +again: + trap v 33 eip 102A3C cpu 1 nlock 1 + panic: interrupt while holding a lock +OR is it the cprintf("kbd overflow")? + no, get panic even w/o that cprintf +OR a release() at interrupt time turns interrupts back on? + of course i don't think they were off... +OK, fixing trap.c to make interrupts turn off FL_IF + that makes it take longer, but still panics + (maybe b/c release sets FL_IF) + +shouldn't something (PIC?) prevent recursive interrupts of same IRQ? + or should FL_IF be clear during all interrupts? + +maybe acquire should remember old FL_IF value, release should restore + if acquire did cli() + +DUH the increment of nlock in acquire() happens before the cli! + so the panic is probably not a real problem + test nlock, cli(), then increment? + +BUT now userfs doesn't do the final cat README + +AND w/ cprintf("kbd overflow"), panic holding locks in scheduler + maybe also simulataneous panic("interrupt while holding a lock") |