IRC channel logs


back to list of logs

<damo22>start acpi:
<damo22>Sending IPI(0) to call TLB shootdown...done
<damo22>Kernel General protection trap, eip 0xc10315fd
<damo22>kernel: General protection (13), code=0
<damo22>Stopped at all_intrs+0x9: movl 0xc11e070c,%ebx
<damo22>c10315fc: 50 push %eax
<damo22>c10315fd: 8b 1d 0c 07 1e c1 mov 0xc11e070c,%ebx
<damo22>that last address holds the "lapic" value
<damo22>it didnt fail on pushing to the stack because the stack pointer was not 0
<damo22>i dont know why it general protection faulted
<damo22>hmm now its crashing in splx:
<damo22>int3 /* Oops, interrupts got enabled?! */
<damo22>it could be switching to an available task during iret instruction
<damo22>that could cause general protection fault
<damo22>youpi1: is it safe to call "sti" directly when i want to enable interrupts for the first time on an AP?
<damo22>or should i use spl() or something
<damo22>i think i should call spl0() ?
<youpi1>well, all the variables concerning interrupts need to be initialized somehow
<youpi1>the main CPU's code seem to use spl0() eventually to enable interrupts
<youpi1>but these variables still need to be properly initialized
<damo22>it boots when i dont enable the lapic timer on AP, but then the AP cpu sits in loop while bsp boots
<damo22>otherwise if i enable the lapic timer on AP, it now hits all_intrs ud2
<damo22>invalid opcode
<damo22>i can push my branch soon
<youpi>damo22: ud2 is not actually "invalid", in that it's meant to stop the cpu, because we've gotten to a bogus point, here $esp doesn't have the expected valkue
<youpi>so either it's actually a stack overflow (which I doubt), or $esp is just not properly initialized
<damo22>in cpu_setup, after all the steps, do i need to reset esp to int stack?
<damo22>paging is enabled
<damo22>or do i need to set esp in the cpuboot.S
<youpi>see how it's done for the main cpu
<youpi>it's set inside all_intrs
<youpi>(and it has nothing to do with paging)
<damo22> it crashes at this point
<youpi>but AP need to have $esp set at some point, yes
<youpi>for the first value at least
<damo22>i do set it in cpuboot.S and it seems to pass that because it reaches the c code
<damo22>movl CX(EXT(int_stack_top), %edx), %esp
<damo22>andl $0xfffffff0, %esp
<damo22>When interrupts are pending in the IRR register, the local APIC dispatches them to the processor one at a time,
<damo22>based on their priority and the current processor priority in the PPR (see Section, “Task and Processor
<damo22>so a timer interrupt on lapic 1 can go to cpu0 ??
<damo22>how do you make LVTT interrupts only go to the processor where the lapic is?
<youpi>I don't know, never programmed x86 smp
<youpi>but i'd be surprised that the lapic interrupt could go to another cpu
<damo22>the docs are long, and yet so incomplete
<damo22>esp 0xc11d8e1c
<stixp>Hi there, when performing a `arm-none-eabi-objcopy -O binary`, the resulting file is totally empty, and I don't have any error code. Do you know cases where this would happen ?
<damo22>hurd isnt ported to arm afaik
<stixp>The generic `objcopy` is very different from the arm one ? Would you have in mind another channel more suited for this question to be asked ?
<damo22>AP=(1) reset page dir done
<damo22>stack overflow
<damo22>should the int stacks be more than 0x1000 per cpu?
<damo22>maybe the ktss temp stack was allocated on the stack?!
<damo22>and filled it
<damo22>looks like esp is not set up right, it still overflows if i make the INTSTACK_SIZE bigger
<damo22>argh i had to run autoreconf -fi or my tree was out of whack
<damo22>some constants were not updated
<damo22>i verified there is a stack positioning problem
<damo22>but i checked the initial stack values and they appear correct
<damo22>stack pointers*
<damo22>somehow, just before the AP goes into lapic_enable_timer(), esp is pointing at something outside of its int stack
<damo22>which the interrupt handler determines is a stack overflow
<damo22>interrupt routines
<damo22>but at that point there have been no interrupts
<damo22>it must be that the routines in cpu_setup() used a lot of the stack and didnt release it?
<damo22>if i dont need to ever return from a function, can i reset the stack pointer in c?
<damo22>it seems the function i am in has chewed a lot of stack
<youpi>I don't understand: when you boot an AP, don't you tell which stack it should use?
<damo22>i have booted the AP with the correct stack
<damo22>but when it comes to turn on interrupts, the stack has overflowed
<youpi>then you shouldn't need more than that, and setting the int_stack_top array for all_intrs to copy that into esp
<youpi>note the comparison at the beginning of all_itrs
<youpi>« on an interrupt stack?  »
<youpi>that test looks bogus since it doesn't care about the CPU number
<youpi>it's supposed to test whether one is on the interrupt stack of the current CPU
<damo22>i have changed my code
<damo22>something must be switching to int_stack_base instead of int_stack_top
<damo22>i can work on this tomorrow as its a public holiday
<damo22>but its baffling
<softwar>I happened to see a roadmap at the HP conference debconf, is there a recommendation for ext4 yet?
<Pellescours>damo22: when you compile for smp, do you enable apic or not?
<Pellescours>because I just tried your branch feat-smp2-fault, and without apic, it seems to boot with rumpdisk IDE. Except than It seems to hang (or a step really takes times idk)
<Pellescours>Oh nevermind it’s feat-smp2-works
<Pellescours>I just tried to use gnumach with apic (and rumpdisk piixide, latest build myself) and it to works. I’m able to ssh on it. I just have some message "lost interupt" and "type: ata tc_bcount: 4096 tc_skip: 0"
<Pellescours>Ah poweroff command did not worked correctly, I had to hard reboot the VM
<Pellescours>gnumach with apic and no smp (for the 2 previous messages)