IRC channel 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>yes

<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

<anatoly>yep

<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>Waiting...done

<damo22>ESR error upon STARTUP 0x4

<damo22>looks like INIT ipi works, but SIPI doesnt

<damo22>Sending IPIs to APIC ID 1...

<damo22>Waiting...done

<damo22>ESR error upon INIT 0x4

<damo22>Waiting...done

<damo22>ESR error upon STARTUP 0x4

<damo22>Waiting...done

<damo22>ESR error upon STARTUP 0x4

<damo22>done

<damo22>Started cpu 1 (lapic id 0001)

<damo22>HANG

<damo22>hmmm

<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>Waiting...done

<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 https://github.com/apple-oss-distributions/xnu/blob/main/osfmk/i386/lapic_native.c#L1033 && https://github.com/apple-oss-distributions/xnu/blob/main/osfmk/i386/mp_native.c#L114 && https://github.com/apple-oss-distributions/xnu/blob/main/osfmk/i386/lapic.h#L243

<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 https://xem.github.io/minix86/manual/intel-x86-and-64-manual-vol3/o_fe12b1e2a880e0ce.html

<damo22>+ phys_addr_t warm_reset_vec = phystokv(0x467);

<damo22>+

<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

IRC channel logs

2024-02-04.log