IRC channel logs


back to list of 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
<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!!
<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
<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
<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
<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
<youpi>that's not the mapping
<youpi>I mean the output of phystokv
<youpi>that's what you need to dereference
<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>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>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>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>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)?