IRC channel logs


back to list of logs

<damo22>Pellescours: yes that is a problem, i dont know how to make it reserve an address lower than 1MB
<damo22>[ 1.360115] mtrr: your CPUs had inconsistent variable MTRR settings
<damo22>[ 1.363609] mtrr: probably your BIOS does not setup all CPUs.
<damo22>[ 1.367612] mtrr: corrected configuration.
<damo22>linux said that
<damo22>The processor priority is used to determine if any accepted interrupts (indicated by APIC[270:200][Request-
<damo22>Bits]) are high enough priority to be serviced by the processor
<anatoly>while compile mig I got following warning "/usr/include/sys/errno.h:1:2: warning: #warning redirecting incorrect #include <sys/errno.h> to <errno.h> [-Wcpp]". So error.h from mig includes sys/errno.h file which produces this warning and then includes errno.h. Is this something expected?
<anatoly>damo22: have you tried with the original bios at this point of progress?
<anatoly>*tried to boot
<youpi>anatoly: probably not, you can probably try to fix the include and see what happens
<youpi>also, try to drop the errno declaration, errno.h is really suppsed to be providing that
<damo22>anatoly: that is a very good idea, but i dont really want to flash this board with vendor again as its a lot of work to put coreboot back on
<anatoly>damo22: i can see :-) are you required to use external flasher on this motherboard?
<damo22>but the flash chip has a socket so i can pull out the chip
<damo22>although its a bit tedious and can easily damage the pins
<damo22>its nice to have the full BKDG for a cpu that you are running
<damo22>i can look up pretty much every register that matters
<damo22>and cross check if coreboot is setting it up correctly, or if gnumach needs to
<damo22>otherwise bios would be a black box and have to trust it
<anatoly>youpi: it seems like errno.h is under sys directory on bsd systems. At least what quick searching on internet tells me.
<youpi>perhaps but posix says it's in errno.h
<damo22>apparently TPR is set to 0x10 in linux
<damo22>This field is assigned by software to set a threshold priority at which
<damo22>the core is interrupted.
<damo22>we are using 0
<damo22>i dont know if that affects INIT and STARTUP ipis
<damo22>When a processor accepts an INIT interrupt, the APIC is reset as at power-up, with the exception that:
<damo22>• APIC20[ApicId] is unaffected.
<damo22>• Pending APIC register writes complete.
<damo22>State at Reset
<damo22>At power-up or reset, the APIC is hardware disabled (MSR0000_001B[ApicEn]=0) so only SMI, NMI, INIT,
<damo22>and ExtInt interrupts may be accepted
<anatoly>mig's test code ignores TARGET_CPPFLAGS passed to ./configure . I'm not sure if it makes sense to do the opposite :-)
<anatoly>so I replace sys/errno.h with errno.h and removed errno decalration then compiled mig and ran tests successfully
<anatoly>Made mig fail in the tests and use errno to report and error. Looks it's ok to drop the errno definition from error.h
<damo22>HPET enabled
<damo22>Kernel (reserved) trap, eip 0xc102c7e9, code 0, cr2 c109af44
<damo22>kernel trap, type 15, code = 0
<damo22>why would it trap when returning from spl0
<damo22>dont you hate it when you change too many things at once, and then it breaks and you have to figure out which bit caused it
<damo22>i forgot to commit when i had it refusing SIPI
<damo22>i cant even get it to reproduce that
<damo22>it just reboots
<damo22>removing a 10ms timeout i had changed its behaviour
<damo22>maybe my printfs are causing a fault
<damo22>because they delay too long
<damo22>ok the only reason the machine can reboot if it tries to send INIT is if the lapic is not set up correctly
<damo22>ok i am getting something interesting, the AP does something as soon as it receives INIT ipi but seems to load code from reset vector because i see coreboot log but only a portion and then it gets stuck
<damo22>i dont think the machine rebooted, but i cant be sure
<damo22>because on screen i still see COM 1 console
<damo22>i think i kexec'd coreboot on the AP :P
<damo22>InitDet: CPU initialization command detect. Read-write. Reset: 0. This bit may be used by soft-
<damo22>ware to distinguish between an INIT and a warm/cold reset by setting it to a 1 before an initialization
<damo22>event is generated. This bit is cleared by RESET_L but not by an INIT command.
<damo22>D18F0x6C Link Initialization Control
<damo22>bit 6
<damo22>hmm maybe coreboot is supposed to set that after it brings up APs
<damo22>setpci -d 1022:1530 6c.b=40
<damo22>did not help
<damo22>SMI, NMI, INIT, Startup, and External interrupts are classified as non-vectored interrupts.
<damo22>When an APIC accepts a non-vectored interrupt, it is handled directly by the processor instead of being queued
<damo22>in the APIC.
<damo22>Trying to enable: 1 at 0x3
<damo22>Sending IPIs to APIC ID 1...
<damo22>ESR error upon STARTUP 0x4
<damo22>looks like INIT ipi works, but SIPI doesnt
<damo22>Sending IPIs to APIC ID 1...
<damo22>ESR error upon INIT 0x4
<damo22>ESR error upon STARTUP 0x4
<damo22>ESR error upon STARTUP 0x4
<damo22>Started cpu 1 (lapic id 0001)
<rrq>bit 2: Set when the local APIC detects that a message it sent was not accepted by any APIC on the APIC bus. Used
<rrq>only on P6 family and Pentium processors.
<solid_black>hi all :(
<damo22>ESR error upon INIT 0x4
<damo22>ESR error upon STARTUP 0xc
<damo22>thats a new error
<rrq>Bit 3: Receive Accept Error
<damo22>7 IllegalRegAddr: illegal register address. Read-write. Reset: 0. This bit indicates that an access to a
<damo22>nonexistent register location within this APIC was attempted. Can only be set in xAPIC mode.
<damo22>6 RcvdIllegalVector: received illegal vector. Read-write. Reset: 0. This bit indicates that this APIC
<damo22>has received a message with an illegal vector (00h to 0Fh for fixed and lowest priority interrupts).
<zamfofex>solid_black: Why the frowny face?
<damo22>err not bits 7 and 6, bits 3 and 2
<damo22>thanks rrq
<damo22>somehow i thought that was 0xc0
<damo22>hmm is an illegal vector 0x00 to 0x0f for SIPI?
<Pellescours>damo22: looking at xnu && &&
<Pellescours>it seems that vector uses the base address for interrupt
<damo22>0300:0000 is this equivalent to 0x3000 ?
<rrq>yes segment:offset = address
<damo22>Pellescours: how does that make any sense for vector that is for startup ipi?
<damo22>i thought its supposed to be the address >> 12
<Pellescours>By digging more, I can see that we structure the write differently.
<Pellescours>So it’s probably the same in the end
<rrq>I also found
<damo22>+ phys_addr_t warm_reset_vec = phystokv(0x467);
<damo22>+ /* Set CMOS shutdown code to 0xA (jump through 40:67) */
<damo22>+ outb(0x70, 0xf);
<damo22>+ outb(0x71, 0xa);
<damo22>i saw something like that in netbsd
<damo22>it definitely changes the behaviour