IRC channel logs

***Server sets mode: +nt

<damo22>i guess i will need to redo this work to move ACPICA to userspace, at least i kinda know what to do http://git.zammit.org/gnumach-sv.git/log/?h=debian-acpica

<damo22>bummer, rm -fr linux/ is harder than i thought

<damo22>not that i would remove it completely yet

<damo22>it compiles but there must be some ASM code that is broken without it

<damo22>#if defined (LINUX_DEV) && defined (CONFIG_INET)

<damo22> free_skbuffs ();

<damo22>in io_done_thread_continue() does that need to be present?

<damo22>even without linux drivers?

<damo22>it died on (*cp->cn_init)(cp);

<damo22>paget fault

<damo22>page fault

<damo22>aha you cant unmask_irq(1) during early console init!

<damo22>woot figured it out!!

<AliciaC>yay!

<damo22>rsdp = acpi_search_rsdp((void*)base,1024); page faults

<damo22>the address of base is 0x9fc00

<AliciaC>unusually low address, maybe corrupted?

<damo22>i think its valid, but the logic is looking for the acpi tables

<damo22>in the wrong place

<damo22>the base pointer of acpi is usually at some really low address like that

<AliciaC>ah

<damo22>its wierd that 0x9fc00 -> 0xa0000 is reserved

<damo22>in the biosmem

<damo22>so it page faults

<youpi>Feb 22 10:22:48 begin kernel: [ 0.000000] BIOS-e820: [mem 0x000000000009e000-0x000000000009efff] reserved

<youpi>Feb 22 10:22:48 begin kernel: [ 0.000000] BIOS-e820: [mem 0x000000000009f000-0x000000000009ffff] usable

<youpi>that's usual

<youpi>but that's not why it page faults

<youpi>"reserved" doesn't make gnumach not map it

<damo22>oh

<youpi>it just makes it avoid allocating memory there

<youpi>but you need to use phystokv to access it

<youpi>see the rest of the acpi code

<damo22>thanks

<youpi>(or kmem_map_aligned_table for high addresses)

<damo22> start = (uint16_t*) phystokv(0x040e);

<damo22> base = *start;

<damo22>accessing base page fautls

<damo22>or base+1024

<youpi>? what is the value of base?

<youpi>that's really not supposed to happen

<damo22>maybe the code is broken because it adds 1024 right at the beginning of the loop

<youpi>all low adresses are mapped

<damo22>0x9fc00

<youpi>that's not the mapping

<youpi>I mean the output of phystokv

<youpi>that's what you need to dereference

<damo22>ah

<youpi>you cannot just take a physical address and hope that you can use it as a virtual address :)

<damo22>im running hurd its tricky to run another hurd to debug the kernel

<damo22> /* Search RDSP in memory space between addr and addr+lenght. */

<damo22> for (end = addr+length; addr < end; addr += ACPI_RSDP_ALIGN) {

<damo22>why is length added at the beginning?

<damo22>oh

<damo22>crazy

<damo22>why is it a uint16_t *?

<damo22>are we in real mode?

<youpi>for bios things that's often made accessible for real mode software

<youpi>so has to be a 16bit paragraph number, yes

<damo22>so if its 0x9fc0 why does the code <<=4

<youpi>because it's a paragraph number, not an address

<damo22>so do i need to phystokv again on the address?

<damo22>after <<=4

<youpi>not again

<youpi>only after

<youpi>when it is actually a physical adress, not a paragraph number

<damo22>right

<damo22>its a neat tiny kernel with no linux

<damo22>can i use kmem_map_aligned_table() for 0x40e ?

<damo22>its tricky to get it right without that

<youpi>you can use it, even if it's useless to use a kmem_map for a low address

<youpi>if that simplifies the code, that's fine

<damo22>gah, why does this fail? addr = kmem_map_aligned_table((phys_addr_t)0x40e, 1024, VM_PROT_READ);

<damo22>it maps it but theres no data there

<damo22>"RSD PTR " is missing in both places

<youpi>aiui 0x40e is not where the rsdp is, but it's where you get the address where the rsdp is

<youpi>not the address actually, the paragraph number

<damo22>awww

<damo22>this is so hard just to read a physical address!

<youpi>that's computer technology yes, it's always hard

<damo22> start = (uint16_t*) phystokv(0x040e);

<damo22> base = *start << 4; /* address = paragraph number * 16 */

<damo22> addr = kmem_map_aligned_table(base, 1024, VM_PROT_READ); <--- looking in this 1024 bytes shows no header

<youpi>what is the base you get ?

<damo22>i'll have to mach_print it because gdb optimizes it out

<damo22>0x9fc00

<damo22>that maps to virtual address 0xf969c00 and theres mostly zeroes in there except:

<damo22>0xf9690c38: 0x00 0x00 0x00 0x00 0x00 0x00 0x04 0xff

<damo22>0xf9690c40: 0xa0 0x3f 0xff 0xff 0x00 0xc8 0xff 0x3f

<damo22>0xf9690c48: 0x10 0xff 0x3f 0x3f 0x8d 0x00 0x00 0x00

<damo22>none of which look like ascii magic

<damo22>0xf9690c00 i meant

<damo22>Thread 1 hit Breakpoint 1, acpi_search_rsdp (addr=0xf9690c00, length=length@entry=1024)

<damo22>as fallback for missing entry i tried:

<damo22>addr = kmem_map_aligned_table((phys_addr_t)0xe0000, 0x10000, VM_PROT_READ);

<damo22>that comes up empty too

<damo22>maybe i moved the smp_init too early before the memory works

<damo22>linux_init used to run before

<damo22>i give up tonight its late

<AliciaC>is the order of operations correct? or might it be doing *(start<<4)?

IRC channel logs

2021-03-24.log