IRC channel logs


back to list of logs

<almuhs>youpi: somethink like this? rsdt = pmap_get_mapwindow(INTEL_PTE_R(rsdt_phys));
<youpi>that's the function yes, but look at what it returns
<almuhs>and INTEL_PTR_R is the mine?
<almuhs>in pmap.h appears many others INTEL_PTE
<damo22>i did something similar to pmap_map_bd
<almuhs>the function returns "pmap_mapwindow_t"
<almuhs>static pmap_mapwindow_t mapwindows[PMAP_NMAPWINDOWS];
<almuhs>"Two slots for temporary physical page mapping, to allow for physical-to-physical transfers."
<almuhs>how can I use It?
<damo22>the way i did it was using vremap from linux/ code to map everything i needed to virtual addresses
<almuhs>damo22: but that is a very dirty wat
<damo22>but i hacked it to throw away the addresses so i wouldnt need to store the mapping in the linux memory management
<damo22>why does kalloc not have a way to store the size of the request?
<damo22>so you wouldnt need to know the size on free
<almuhs>this code seems to be a good example of mapping
<damo22>youpi: do you think the vremap way is bad?
<youpi>almuhs: look inside the pmap_mapwindow_t type
<almuhs>I did this already
<almuhs>in some example, the function are used as this way
<almuhs>src_map = pmap_get_mapwindow(INTEL_PTE_R(src));
<almuhs> src_addr_v = src_map->vaddr;
<youpi>damo22: that should work
<damo22>the problem is you need to store the mapping somewhere so you can free it
<youpi>well, that or you don't free it
<damo22>or just leave it
<youpi>I mean, if you want to free it, well yes you have to have the pointer
<youpi>I don't see how it could magically work otherwise :)
<damo22>and you need the size stored so you can free it
<damo22>so you need a lookup table like linux has
<youpi>ah, I thought you meant the problem of the vremap interface
<youpi>yes, sure vremap makes it easier
<damo22> can almuhs use this?
<damo22>instead of vremap
<youpi>if it's never to be freed that's much simpler
<damo22>and then never free it
<damo22>it seems to be allocating new memory, and then making the physical page point there?
<almuhs>It continues failing in the same point
<youpi>not new memory, new adressing space
<almuhs>I'm trying to map the address using this
<youpi>not making the physical page ponite there, but make the virtual address space ponit to the physical page
<youpi>which is what is needed, yes
<almuhs>what do you refers?
<youpi>almuhs: I was talking to dam
<almuhs>oh, ok
<youpi>almuhs: you really need to read what you are using
<youpi>I told you to look at what that function returns
<youpi>pmap_mapwindow_t holds a pt_entry_t and a vm_offset_t
<youpi>pt_entry as in "page table entry"
<youpi>and vm_offset as "virtual memory offset"
<youpi>do don't case pmap_map_window_t* into struct acpi_rsdt*
<almuhs>static pmap_mapwindow_t mapwindows[PMAP_NMAPWINDOWS];
<youpi>it's not the actual poniter
<almuhs>this is what the function returns
<youpi>it's a potner to a structure that contains the pointer
<youpi>and that's not the actual virtual pointer
<youpi>it's an address of a structure that contains the pointer
<damo22>he put `->vaddr`
<youpi>forget what I just wrote
<almuhs>but It doesn't works
<youpi>did you print what it returns?
<youpi>really, I'm amazed how people nowadays do not just print what they are doing
<youpi>people don't seem to realize that yes, computer science is hard and nobody gets it right the first time
<almuhs>yes, I printed It
<youpi>so you just always have to check that things behave the way you thought
<youpi>ok, did you get the print ?
<youpi>that being said, see what damo22 said
<youpi>that'd be more simple and powerful actually
<damo22>almuhs: i have a simpler way that does not involve pmap_get_window, you just allocate a new address space and point the physical page there
<almuhs>this is the solution which a friend used to map lapic, is not?
<youpi>that being said the address you got looks good
<youpi>the eip after that looks completely bogus
<almuhs>but It doesn't pass the memcmp
<damo22>i dont think ffffe000 is a good address
<youpi>it is
<youpi>see the pmap window initialization
<youpi>it's really put at the end of the kernel memory
<damo22>but its reserved in the e820 map
<youpi>almuhs: your memcmp looks wrong
<youpi>is .signature really a poniter ?
***Server sets mode: +nt
<youpi>err, you only called pa_to_pte
<youpi>why only that?
<youpi>all other callers of pmap_get_mapwindow use INTEL_PTE_W or R
<youpi>which surely is needed indeed
<youpi>otherwise if you don't have an R flag you can't read it
<almuhs>then I copy the define of #INTEL_PTE_R
<almuhs>#define INTEL_PTE_R(p) (INTEL_PTE_VALID | INTEL_PTE_REF | pa_to_pte(p))
<youpi>well, for instance yes
<damo22>that define should be in pmap.h but its not
<youpi>at least there was no way for the code to work
<youpi>yes, we probably want to move it
<almuhs>ok, now It reach Hurd booting
<almuhs>but rsdt checking fails
<almuhs>(excuse me the ugly screenshot, Mach runs so fast to shot as other way)
<youpi>almuhs: just to be sure you could print kernel_virtual_end
<youpi>I really mean kernel_virtual_end
<almuhs>Is It a variable name?
<youpi>yes, grep will tell you
<youpi>really, grep rules
<damo22>i still think this function would work better
<youpi>ooh right there's alignment questions
<almuhs>the kernel virtual end is ffffff
<youpi>almuhs: ok so the mapping was right
<youpi>it's the page alignment that poses problem
<damo22>my function above would handle that
<almuhs>really, the fail is now in memcmp
<youpi>yes, because of alignment problems
<youpi>I didn't realize you had a non-aligned address
<youpi>so pa_to_pte of course drops some bits of the address
<youpi>see damo22's function
<almuhs>I put a phystokv in rsdp start address
<almuhs>is this correct?
<youpi>phystokv doesn't hav alignemnt issues
<youpi>since it's just adding the segmentation offset
<almuhs>with alignment problems, do you refers that the structure doesn't fills in one page?
<damo22>the starting address is not on a page boundary
<youpi>I'm talking about the rsdt address
<youpi>it's not aligned on a page
<youpi>and thus mapping it needs to take care of this
<damo22>you can only map to nearest page
<youpi>which damo22's function does take care of
<youpi>almuhs: the problem is not that it doesn't fit (actually it does) but that the start is not aligned on a page start
<youpi>really, read the macros your are using
<youpi>see pa_to_pte
<youpi>see that it drops the rightmost bits
<almuhs>oh... now I understand
<youpi>so it can't be valid
<youpi>since it drops part of the address
<almuhs>then, do I copy the damo22 function and try It with this?
<almuhs>how can I call It?
<damo22>it returns a new pointer to a mapped address
<almuhs>yes, but I don't know what pass as parameters
<almuhs>what must I put in the parameters?
<damo22>physical address and size of mapping
<damo22>you get back a mapped pointer that should just work
<almuhs>ok, I go to try It
<almuhs>../i386/i386at/acpi_parse_apic.c:60:27: error: ‘kernel_map’ undeclared (first use in this function)
<damo22>#include <vm/vm_kern.h>
<youpi>almuhs: you really need to learn to use grep
<damo22>when you see errors like that, first "git grep kernel_map"
<almuhs>"git grep"
<youpi>| grep h:
<almuhs>I didn't know It
<almuhs>found rsdt in address 0
<damo22>put an infinite loop in gnumach after your prints so it doesnt try to boot
<almuhs>is this your prototype? pmap_hack (unsigned long offset, unsigned long size)
<damo22>void *
<almuhs>is offset the physical address?
<almuhs>this is my call
<damo22>not sure if you can assign a struct direct to an address
<almuhs>oh, really, I missed the casting
<youpi>you don't need a cast in C
<almuhs>then... where can be the fail?
<youpi>printf would tell
<damo22>you kind of cheated, by implicitly casting the memory address to a struct, that doesnt always work depending on padding and bitfield order sometimes
<almuhs>printf tell me that rsdt address is 0
<youpi>damo22: ?
<youpi>it's not a struct, it's a poniter to struct
<almuhs>this struct doesn't has any bitfield
<youpi>almuhs: I mean print inside pmap_hack
<youpi>to check how it behaves
<damo22>yes its a pointer to a struct but almuhs assigns the pointer and then dereferences the struct members straight out of the memory
<youpi>(and if you get lazy to add a print just because it's long to reboot with the rebuilt kernel, work on making rebuild+reboot faster, that will save time in the long run)
<youpi>rsdt = pmap_hack (rsdt_phys, sizeof(struct acpi_rsdt));
<youpi> printf("found rsdt in address %x\n", rsdt);
<youpi>that will print the pointer, won't it?
<almuhs>but prints 0
<damo22>almuhs: check the compiler warnings
<damo22>i just wrote that function without testing it
<almuhs>compiler warnings doesn't shows any advice about It
<damo22>almuhs: print more
<almuhs>yes, I'm in It
<almuhs>but I'm exhausted, and I work very slow now
<almuhs>2:09 AM in spain
<damo22>oh dear
<damo22>seems like youre getting null back from kmem_alloc_wired?
<almuhs>It's possible
<youpi>vm_mem_boostrap is called from setup_main only
<youpi>possibly vm_map_find_entry can't work earlier than that
<damo22>youre calling acpi_setup too early
<youpi>really, I don't see why you try to call it that early
<youpi>you'll only bump into troubles :)
<almuhs>I want to call before start the system
<almuhs>because damo22 told that It's necessary to configure IOAPIC even before harddisk drivers
<youpi>then you only need to call it before thread_create(kernel_task, &startup_thread);
<youpi>then before machine_init()
<damo22>put it in machine init
<youpi>since that's where you have all the drivers
<almuhs>ok, thanks
<almuhs>really, I asked about this a few hours ago
<damo22>you probably want to call it just after linux_init
<almuhs>inside machine_init()?
<damo22>thats where i put mine and it worked well
<almuhs>after init_fpu is well?
<damo22>in between linux_init and probe_io
<almuhs>just after, not just before
<damo22>(10:19:29) damo22: you probably want to call it just after linux_init
<almuhs>yes, but I read It bad
<damo22> linux_init();
<damo22> acpi_setup();
<damo22> for (;;);
<damo22>for (;; );
<damo22>i meant
<damo22>then you can inspect memory in qemu while its stuck in loop
<almuhs>now rsdt works
<almuhs>continues crashing, but now the fail can be in apic table
<almuhs>It's not mapped yet
<almuhs>but gnumach find rsdp and rsdt, and the signature check is correct
<almuhs>but I continues the work with apic tomorrow
<almuhs>I'm really exhausted
<almuhs>thanks damo22 and youpi
<almuhs>good morning for damo22 ;)
<youpi>damo22: I have just pushed a kmem_valloc, which should be used instead of kmem_alloc_wired (which wastes memory)
<almuhs>youpi: finally, tonight I get to find correctly the RSDT reference
<almuhs>youpi: do you know if is posible to use rsync to synchronize the host with the VM?
<almuhs>I want to avoid to use git to this synchronization
<youpi>rsync works yes
<almuhs>ok, thanks
<almuhs>do I need to configure something in Hurd to get that rsync works? I've installed rsync package and enabled the service, but I don't get to connect with the machine
<youpi>you can just use it over ssh
<almuhs>yes, but I don't get It
<almuhs>I usually connect to It using localhost and port 2222, but this doesn't works with rsync
<youpi>use .ssh/config to get the port automatically set up
<almuhs>now rsync works
<almuhs>It seems that apic access has been solved mapping the address.
<almuhs>but there are some problems in the apic table parsing
<almuhs>the apic checksum is successfull, but the code seems fails after
<almuhs>there aren't kernel panic, so the problem must be in a "return -1"
<almuhs>now the code seems to read APIC without errors. But the lapic and ioapic values are not correct
<almuhs>all lapic and ioapic have apic_id=0