IRC channel logs
2025-06-07.log
back to list of logs
<damo22>now i guess i need to compile libslirp again with a small change to remove verbosity <damo22>qemu: info: Slirp: arp_table_add... <damo22>qemu: info: Slirp: ip = 10.0.2.15 <damo22>qemu: info: Slirp: hw addr = 52:54:00:12:34:56 <damo22>i think it fails to add the arp entry because if i try dhclient it almost gets an ip but cannot contact the client <damo22>it looks like it offered 10.0.2.15 via dhcp <damo22>so it must have received the bootp frame <damo22>the udp response from dhcp server is getting lost? <damo22>i dont see any frames from 52:55:0a:00:02:02 on the hurd side <damo22>its like all incoming packets are filtered out <damo22>youpi: rump_dhcpclient from netbsd seems to open /dev/bpf in O_NONBLOCK mode, but then it would consume a lot of cpu reading nothing? <damo22>Cannot find a physical address for vaddr 0x20268800, returning 0 <damo22>youpi: is there a new-ish RPC that fetches a physical address from a virtual address? <damo22>i compiled gnumach from master source and i still get that error <damo22>seems like the new rpc is not working? <damo22>i upgraded librump* and gnumach and still get that error <damo22>since it is printing that message, it must be failing the vm_pages_phys rpc and falling back to an old method and still failing <damo22>Pellescours: do you know about vm_pages_phys? <damo22>something seems fixed with hurd, i was able to compile rumpkernel with sync=5 filesystem mount <youpi>damo22: even with NONBLOCK, you can probably select() on it to avoid busy-looping <youpi>vm_page_phys is used by rumpdisk, otherwise we wouldn't have DMA <youpi>do you pass it a rounded address and such? <damo22>can i make the vm_page_phys accept a non-page aligned address? <damo22>or do we need to round it every time we use it <youpi>it's better to have the caller align address to force it remember that physical addresses are page-related <damo22>so pci-userspace/src-gnu/pci_user.c needs adjusting <damo22>when it looks up a physical address <damo22>no its not, its given any address with size of a page <youpi>but it's coming from a page allocation <damo22>Cannot find a physical address for vaddr 0x20224800 <youpi>pages are 4096 on x86, so that's three hex digits indeed <damo22>yeah so something in rumpnet is calling the hypercall rumpcomp_pci_mach_to_virt with a non-page aligned address <damo22>so we need to align it, and then add the offset to the result? <youpi>but also check what the caller is doing <youpi>how large it thinks the result will be valid <youpi>since it's obviously not a page-large question <damo22>since rumpdev_bus_dma.c is the only caller of that api <damo22>since the segment size is computed by PAGE_SIZE - something <damo22>sgsize = PAGE_SIZE - ((u_long)vaddr & PGOFSET); <damo22>if the length of the segment is less than a page, if we find the page for the unaligned request, that page will contain the whole region? <youpi>depends on the starting offset <damo22>the request is exactly half way through a page? <damo22>i think the request only assumes the memory is valid for PAGE_SIZE - (vaddr & 0xfff) <damo22>so if we align the request down to the nearest virtual page, and give it one page, then the resulting physical page will contain the starting address plus sgsize ? <damo22>i modded it, and now i get another packet but it crashes before printing the new packet <damo22>hmm it received a packet with 64 bytes <damo22>i fixed the segfault on my end something dumb, but now the received packet is empty full of zeroes <damo22>something wrong with the alignment ? <damo22>if the request is less than a page in size, wont 2 pages rounded down always be enough? <damo22>when i ssh into the hurd box i receive a packet of 60 bytes of zeroes <damo22>so something must be wrong with rumpdev_bus_dma.c <damo22>the caller should not be calling rumpcomp_pci_virt_to_mach with an unaligned vaddress ? <azert>damo22: where does the address comes from?