IRC channel logs


back to list of logs

<damo22>iska: yes we are very close, i mean, it does boot with smp but gets stuck due to some kind of threading issue because we are running code paths that have not been tested with multiprocessor yet
<damo22>start acpi: acpi pci rumpdisk Kernel Page fault trap, eip 0xc10321b9
<damo22>kernel: Page fault (14), code=0
<damo22>Stopped at thread_select.part.0.constprop.0+0xc9: cmpl $0x1,0x58(%eax)
<damo22>what are all those zeroes?
<youpi>kdb doesn't know how many parameters functions take
<youpi>so it just peeks what is on the stack
<damo22>if im iterating through a task's threads to sync the iopbs, do i need to lock the task?
<youpi>you very probably need to lock something to sync on the task list yes
<damo22>im using the iopb simple lock, but not sure if thats enough
<damo22> simple_lock (&new_task->machine.iopb_lock);
<damo22> update_ktss_iopb (new_task->machine.iopb, new_task->machine.iopb_size); <--- this function now iterates through a tasks threads to sync them all
<damo22> simple_unlock (&new_task->machine.iopb_lock);
<youpi>it's not enough concerning the iteration itself
<youpi>about iterating over threads to shoot tlb, did you see signal_cpus' comment ?
<damo22>yes its a long comment
<damo22>ohh i need to read it again
<youpi>and PMAP_UPDATE_TLBS' users variable
<damo22>there is a function that is supposed to be called by the interrupt right?
<damo22>by each cpu
<youpi>yes but I'm talking about iterating over threads etc.
<youpi>but that's already handled by the users variable
<damo22>cpus_using ?
<youpi>remember that mach has already been run on smp
<youpi>just not on x86 smp
<youpi>so normally only x86-specific code needs updating
<youpi>yes, cpus_using
<damo22>ok yes
<damo22>im mostly working in i386/
<damo22>i think we need to reintroduce some IPLs
<youpi>I don't think we need
<youpi>linux doesn't use them
<damo22>An implicit assumption made
<damo22>* throughout the TLB code is that all kernel code that runs at or higher
<damo22>* than splvm blocks out update interrupts, and that such code does not
<damo22>* touch pageable pages.
<youpi>disabling interrupts + lock is enough to protect things
<youpi>yes, which means cli
<youpi>(is enough)
<damo22>but for the TLB sync, i think we just have to implement interrupt_processor(cpuX) as a IPI that triggers pmap_update_interrupt() on cpuX
<damo22>and ensure interrupts are enabled when that is called
<damo22>at least on the calling cpu
<youpi>one doesn't have to ensure interrupts are enabled
<youpi>just that they happen to get enabled sooner or later
<youpi>which is all what spl is about
<youpi>you need that for the clock to advance anyway..
<damo22>ok. This ktss thing is tricky though. im not sure why the threading is trampling all over each other
<youpi>for ktss I'd say just interrupt all threads and be done
<youpi>iopl change is rare enough that we don't need to optimize that
<youpi>all *cpus* actually
<damo22>all cpus :D
<damo22>that would be easier
<damo22> for (slot = 0; slot < NCPUS; slot++)
<damo22> {
<damo22> if (machine_slot[slot].is_cpu)
<damo22> update_ktss_iopb_per_cpu (new_iopb, size, slot);
<damo22> }
<damo22>hmm its still page faulting at thread_select
<damo22>after thread_block
<damo22>so when splvm() is called that sets SPL7 ?
<damo22>and cli
<damo22>and we dont need to distinguish between splvm and splsched?
<damo22>youpi: in thread_block, why does cpu_number() get called twice?
<damo22>shouldnt it remember the cpu number it first called?
<damo22>or the opposite, the myprocessor variable should be recomputed inside the spl
<damo22>(qemu) cpu 0
<damo22>(qemu) x 0xf47ffffc
<damo22>f47ffffc: Cannot access memory
<damo22>(qemu) cpu 1
<damo22>(qemu) x 0xf47ffffc
<damo22>f47ffffc: 0x00000000
<damo22>what the hell
<damo22>when the thread swaps, the other cpu cant read its memory
<damo22>why would that be?
<damo22>do we need FS and GS set up?
<damo22>problem is %eax is zero when it shouldnt be
<damo22>its trying to dereference 0x58(%eax)
<damo22>my CPU_NUMBER() function was borked
<damo22>bad address ff008f
<damo22>how do i allow low addresses in bios such as 0xf0000 to be allowed in kernel? im getting kernel accessed userspace
<damo22>how do i allow low addresses in bios such as 0xff000 to be allowed in kernel? im getting kernel accessed userspace page fault