IRC channel logs
2022-02-20.log
back to list of logs
<damo22>youpi: ok, so rump does not call vm_allocate_contiguous to make a bounce buffer for unaligned/large accesses. I think i understand now <damo22>i think the timeouts are related to NCQ enabled on the disk <damo22>(09:47:37) jmcneill: On at least one board I have, the "reserved" bits override bus cache attributes and caused all sorts of havoc <damo22>(09:48:51) jmcneill: And that change fixed a lot of other SATA bugs <youpi>damo22: a debian install now goes fine with rump :) <youpi>it's getting uploaded as the latest daily image <youpi>I'll try to find time to make a new labelled-as-tested image <youpi>it's a bit slower to make a full install (7:30 instead of 7:00) but it's not that bad <Pellescours>youpi: I don't know if that will happened with a proper rump install but when I manually used rump from my exiqint VM, the apt upgrade was failing to upgrade gnumach do to the postinstall grub hook <Pellescours>i disabled the hook to do the upgrade locally, that's fine for me but i want to notice tgat it can happen to someone else <Pellescours>If I understood correctly the problem it's the defaut grub config template that is not able to handle the new services to boot <youpi>grub isn't updated yet indeed <luckyluke>about mig and 64 bit... would it be ok to remove the dependency on the gnumach headers, and have the size of mach_msg_header_t and such hardcoded for a given platform? In this way we could choose whether to generate code for 32-bit rpc or 64 bit rpc (or for user/kernel stubs) with a command line option, instead of depending on how mig was compiled. <luckyluke>of course there should be a sanity check in the generated code, with static asserts <luckyluke>btw, some assumptions are already embedded in mig, for example about the size of mach_port_t, mach_msg_type_number_t being the "word size", that is integer_t <Pellescours>luckyluke: in this case you should define the size of theses types for all platform that you want to support and they’ll have to be the same as <Pellescours>what gnumach declare, I don’t know if the benefit is worth <luckyluke>some of these assumptions are actually already in mig, in my opinion the size of types should either be fully configurable at compile time (so deriving them from gnumach headers) or at execution time (with an option, hardcoding the sizes) <luckyluke>also, I suppose that once an architecture is supported, these numbers are unlikely to change <luckyluke>For example, currently you can't have a 64-bit mach_port_t alone, you need to change also other types, everything that is supposed to be "word size" <Pellescours>yeah someone played with my keyboard as the same time I tried to prevent him <youpi>damo22: next step for rumpdisk would be to go multithread <youpi>that'll allow to avoid serializing all reads/writes <youpi>so basically use the manage multithread function, and protect whatever needs to be :) <sobkas>Hi, when there will be updated hurd package that uses rumpdisk by default? <sobkas>O today showed up: 20220220192303.irc52kqryt76txjf@begin