summaryrefslogtreecommitdiff
path: root/Notes
diff options
context:
space:
mode:
authorrtm <rtm>2006-08-08 19:58:06 +0000
committerrtm <rtm>2006-08-08 19:58:06 +0000
commit0e84a0ec6e7893dad13dff9a958c5bc987b79c82 (patch)
tree5739d0a2af8277db7a47c74e52975d9e9d81cef7 /Notes
parente8d11c2e846ad15b32caacc8a919722b76d00f79 (diff)
downloadxv6-labs-0e84a0ec6e7893dad13dff9a958c5bc987b79c82.tar.gz
xv6-labs-0e84a0ec6e7893dad13dff9a958c5bc987b79c82.tar.bz2
xv6-labs-0e84a0ec6e7893dad13dff9a958c5bc987b79c82.zip
fix race in holding() check in acquire()
give cpu1 a TSS and gdt for when it enters scheduler() and a pseudo proc[] entry for each cpu cpu0 waits for each other cpu to start up read() for files
Diffstat (limited to 'Notes')
-rw-r--r--Notes78
1 files changed, 78 insertions, 0 deletions
diff --git a/Notes b/Notes
index 22658fc..2291621 100644
--- a/Notes
+++ b/Notes
@@ -163,3 +163,81 @@ and file arguments longer than 14
and directories longer than one sector
kalloc() can return 0; do callers handle this right?
+
+why directing interrupts to cpu 1 causes trouble
+ cpu 1 turns on interrupts with no tss!
+ and perhaps a stale gdt (from boot)
+ since it has never run a process, never called setupsegs()
+ but does cpu really need the tss?
+ not switching stacks
+ fake process per cpu, just for tss?
+ seems like a waste
+ move tss to cpu[]?
+ but tss points to per-process kernel stack
+ would also give us a gdt
+ OOPS that wasn't the problem
+
+wait for other cpu to finish starting before enabling interrupts?
+ some kind of crash in ide_init ioapic_enable cprintf
+move ide_init before mp_start?
+ didn't do any good
+ maybe cpu0 taking ide interrupt, cpu1 getting a nested lock error
+
+cprintfs are screwed up if locking is off
+ often loops forever
+ hah, just use lpt alone
+
+looks like cpu0 took the ide interrupt and was the last to hold
+the lock, but cpu1 thinks it is nested
+cpu0 is in load_icode / printf / cons_putc
+ probably b/c cpu1 cleared use_console_lock
+cpu1 is in scheduler() / printf / acquire
+
+ 1: init timer
+ 0: init timer
+ cpu 1 initial nlock 1
+ ne0s:t iidd el_occnkt rc
+ onsole cpu 1 old caller stack 1001A5 10071D 104DFF 1049FE
+ panic: acquire
+ ^CNext at t=33002418
+ (0) [0x00100091] 0008:0x00100091 (unk. ctxt): jmp .+0xfffffffe ; ebfe
+ (1) [0x00100332] 0008:0x00100332 (unk. ctxt): jmp .+0xfffffffe
+
+why is output interleaved even before panic?
+
+does release turn on interrupts even inside an interrupt handler?
+
+overflowing cpu[] stack?
+ probably not, change from 512 to 4096 didn't do anything
+
+
+ 1: init timer
+ 0: init timer
+ cnpeus te11 linnitki aclo nnoolleek cp1u
+ ss oarltd sccahleldeul esrt aocnk cpu 0111 Ej6 buf1 01A3140 C5118
+ 0
+ la anic1::7 0a0c0 uuirr e
+ ^CNext at t=31691050
+ (0) [0x00100373] 0008:0x00100373 (unk. ctxt): jmp .+0xfffffffe ; ebfe
+ (1) [0x00100091] 0008:0x00100091 (unk. ctxt): jmp .+0xfffffffe ; ebfe
+
+cpu0:
+
+0: init timer
+nested lock console cpu 0 old caller stack 1001e6 101a34 1 0
+ (that's mpmain)
+panic: acquire
+
+cpu1:
+
+1: init timer
+cpu 1 initial nlock 1
+start scheduler on cpu 1 jmpbuf ...
+la 107000 lr ...
+ that is, nlock != 0
+
+maybe a race; acquire does
+ locked = 1
+ cpu = cpu()
+what if another acquire calls holding w/ locked = 1 but
+ before cpu is set?