IRC channel logs

<damo22>youpi: i upgraded to your 0~20250111-2 version of librump* and i still get the zero filled packets, we still have a problem in rump i guess

<damo22>but it receives packets, instead of not receiving anything

<youpi>that's expected: as I mentioned, the fallback path does support offset already

<damo22>no, without latest version, i get no packets received

<youpi>? I thought you were already receiving zeros

<damo22>no

<damo22>i patched my own rumpkernel to get any packets

<youpi>patched how?

<damo22>something similar to your patch for vm_pages_phys

<youpi>that's very surprising, the fallback really does support offset

<damo22>it was printing after the fallback failed

<youpi>failed?

<damo22>printf("Cannot find a physical address for vaddr %p, returning 0\n", virt);

<youpi>that doesn't change anything it what I said :)

<youpi>that's very surprising, the fallback really does support offset

<youpi>I'm not claiming it does work

<youpi>I'm claiming it does support it

<youpi>bugs can exist of course

<youpi>but I'm really surprised because that *is* already getting exercised in rumpdisk

<youpi>I got non-aligned requests when I was trying the other day

<damo22>is there a chance the vaddr being passed to the hypercall was not allocated with vm_allocate_contiguous() in rump?

<youpi>I don't know

<damo22>so the assumption of contiguous memory could be false

<youpi>It would really not make sense for the caller to call for the physical memory if it's not contiguous

<youpi>but again, bugs can exist

<damo22>i mean, rump doesnt know about mach's paging

<youpi>but it does have paging for itself

<youpi>when the bsd code is used alone in a kernel

<youpi>so drivers have to behave anyway

<damo22>ok

<damo22>but dont we have an extra complexity because of mach's paging as well?

<youpi>again, bsd does have paging as well

<youpi>so bsd drivers have to behave

<youpi>paging being done by mach doesn't change anything there

<damo22>there is a separate call for bus_dmamap_load_mbuf for mbufs apparently that are used for packet buffers?

<youpi>possibly the dma buf api is not completely properly plugged

<damo22>thats probably why it exhibits different behavior to the disk driver?

<damo22>do we need to #define POOL_VTOPHYS

<damo22>it adds in some more logic for pooling virtual -> physical addresses in the mbuf call

<youpi>I guess that would mostly add complexity to the problem

<youpi>("pool" usually refers to optimization, not correctness)

<damo22>ok

<youpi>again, bsd does have the question as well

<youpi>having an option that makes the kernel work at all wouldn't make sense

<damo22>rump/librump/rumpkern/arch/x86/rump_x86_pmap.c has

<damo22>vtophys(vaddr_t va)

<damo22>{

<damo22> return (paddr_t)va;

<damo22>and POOL_VTOPHYS(x) is usually defined as vtophys(x)

<damo22>but we dont define it

<azeem>The postgres test suite keeps hanging my Hurd VM (probably because it hammers it) - I guess I'd need to attach a serial console to get some crash output somewhere?

<youpi>damo22: that looks bogus indeed, it should use rumpcomp_pci_virt_to_mach (or actually put the rumpcomp_pci_virt_to_mach implementation into vtophys, and make callers of rumpcomp_pci_virt_to_mach use that instead)

<azeem>I can report that if I tweak the Postgres buildfarm client to not run the regression testsuite (which runs fine with submitted patches if I run it manually), the other stages mostly run fine as well except for two other occasions which are likely timer-resolution issues as well

<youpi>good :)

<azeem>I need to figure out why the VM hangs/dies during the make check phase

<azeem>I've ugpraded to current unstable, but the Postgres timer-resolution tests still fail - is there something I need to configure in order to use those higher-resolution timers?

<azert>azeem: maybe you need to enable APIC or ACPI or both?

<azert>Maybe try the smp kernel

IRC channel logs

2025-06-11.log