IRC channel logs


back to list of logs

<damo22>i cant explain quilt on irc
<damo22>but basically you need that
<Pellescours>the fact that I compile ata with sata support mean that I can’t compile rumpdisk with only libata and piixide (a method is missing). I don’t think it’s an issue for hurd but if we want the patches to be upstreamed to netbsd, this can be a problem
<Pellescours>I think I understood how to use quilt
<damo22>netbsd doesnt have ide/sata disk drivers in rump
<damo22>anything we provide is already better than nothing
<Pellescours>piixide is really slow really It look like I didn’t started qemu with kvm, but only for disk interraction
<Pellescours>it’s not all operations but git operations in rumpkernel, like rebase are so slow. I feel it faster with linux driver, I don’t know if it’s an impression or real
<Pellescours>I send the patch to the bug-hurd, damo22 can you test on real hardware to ensure it works.
<Pellescours>for the DMA problem with piixide, it’s still there, the error message is "piixide0:1: unable to allocate table DMA map for drive 0, error=1"
<Pellescours>ok, this error appear because rumpcomp_pci_dmamem_map is not able to handle map of more than 1 seg
<damo22>Pellescours: i think flags 0x0000 means no DMA allowed with the wd
<damo22>if you remove the flags it should work
<damo22>or might hit a different error
<Pellescours>no it’s 0x0002 that disable DMA
<Pellescours>It tried to dma but don’t work because the rumpcomp_pci_dmamem_map implementation is not able to handle mapping of multiple segments
<damo22>what is the size of a segment?
<damo22>you could try the suggestion from there
<damo22>ie, call mremap() using the parameters passed in
<damo22>so the mapping gets enlarged to totlen
<damo22>or nseg*totlen not sure
<Pellescours> it’s not for rump but shouldn’t we do the same kind of algo (pmam_enter)?
<damo22>mremap should be enough?
<damo22>or some kind of vmallocate_contiguous?
<Pellescours>we do vmallocate_contiguous for the dmalloc
<damo22>why cant the dmalloc be big enough
<damo22>why does rump want to extend it?
<Pellescours>I don’t know, I’m recompiling rumpkernel to have the informations
<damo22>what does mremap do? if it retains the base physical address and just makes the mapping bigger, that is sufficient
<Pellescours>All that I know for now, it’s that the part that emit the message is that line and the only way this call return non-zero is to have rumpcomp_pci_dmamem_map returning non-zero
<damo22>dig into bus_dmamem_alloc
<damo22>see how it implements it via the rump call
<damo22>as it already passes in nseg
<damo22>it may be that its already allocated and we can release the restriction, im not sure
<Pellescours>It’s a kalloc a foreach to initalize the struct and the rumpcomp_pci_map call
<damo22>or does it make nseg x rumpcomp_pci_map calls
<Pellescours>it calss rumpcomp_pci_map once
<damo22>yea bus_dmamem_alloc is currently a hack, and theres no rump hypercall that can give it scatter-gather memory
<damo22>i was talking to someone about this in netbsd
<damo22>it needs to be fixed but no one is working on it
<damo22>i think its an array of mappings that are physically contiguous
<damo22>so we could allocate it in one block using vmallocate_contiguous and break it up into chunks perhaps
<damo22>im not sure
<Pellescours>our rumpcomp_pci_dmalloc already do a vmallocate_contiguous, so the bus_dmamem_alloc already does it for us (split into chunks)
<damo22>yes but it only currently supports nseg =1
<damo22>i think its ignoring boundary and nsegs
<damo22>since that is not passed into the rump call
<damo22>maybe we can just allocate it in one chunk and ignore multiple segments?
<damo22>the problem is, bus_dmamem_map asks for multiple segments
<damo22>i think the alloc is allocating it in one chunk but the map is asking for the same region in smaller chunks
<Pellescours>can we just construct a map by just slicing the buffer and returning it? Or will this cause issues due to vmap <-> pmap correspondance?
<damo22>good q
<damo22>i think the underlying physical memory is contiguous, so the vm address should also be?
<damo22>because we use vmallocate_contiguous
<damo22>i think slicing the buffer would work
<Pellescours>Because we allocated contiguous memory containing all the asked pages, I think we can ignore nseg and always return the same stuff. It’s possible because we know that we allocated continuously, otherwise there is the pmap_enter to generate a contiguous buffer of discontinuous pages
<damo22>give it a try
<damo22>ohh but the "boundary" is a physical address that it wants the mapping to be at?
<damo22>im not sure what boundary is for
<Pellescours>according to the doc
<Pellescours>If I understood the code correctly, the map step should be a no-op (what is it currently). The map is useful only when the memory returned by alloc is not virtual.
<Pellescours>But in our case, we are in userland so we always have a virtual memory returned by alloc
<Pellescours>I don’t understand now it’s the vm_allocate_contiguous that fails (so a regression from before)
<damo22>youpi: can i use _Atomic int
<damo22>or do i need to call __atomic_add_fetch(refcnt, 1, __ATOMIC_SEQ_CST);
<Pellescours>damo22: actually it was always the alloc that was failing. I’m trying to get the align and size, but I fear it’s due to the limitation of vm_allocate_contiguous that makes the allocation failing
<damo22>see if you can get the params sent to the dmalloc in rump
<Pellescours>damo22: dma_table_size: 136 and dma_table_align: 65536
<Pellescours>the align is greater than page size so allocation fails
<Pellescours>time to sleep
<damo22>int interrupt_demuxer (mach_msg_header_t *inp, mach_msg_header_t *outp) <--- how do i expose this function that needs a struct irq passed in, but i cant change the function prototype??
<damo22>i dont think i can
<damo22>i need to put hooks in it
<Pellescours>damo22: for the vm_allocate_contiguous, can I transform the "if (palign == 0)" into a "if (palign % PAGE_SIZE == 0)"? That would fix the alloc for the dma
<Pellescours>with that modification DMA works and it’s super fast
<Pellescours>gnumach with APIC is still buggy, I have a lot of "lost interrupt", and at some point the machine "hang", the console cursor is still blinking but not keyboard input is accepted, even in ssh, and if it was doing something (like booting) nothing happen
***foggy68 is now known as foggy67