diff options
author | rtm <rtm> | 2006-08-08 19:58:06 +0000 |
---|---|---|
committer | rtm <rtm> | 2006-08-08 19:58:06 +0000 |
commit | 0e84a0ec6e7893dad13dff9a958c5bc987b79c82 (patch) | |
tree | 5739d0a2af8277db7a47c74e52975d9e9d81cef7 /Notes | |
parent | e8d11c2e846ad15b32caacc8a919722b76d00f79 (diff) | |
download | xv6-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-- | Notes | 78 |
1 files changed, 78 insertions, 0 deletions
@@ -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? |