***Server sets mode: +nt
<damo22>vendor 8086 product 2922 (SATA mass storage, AHCI 1.0, revision 0x02) at pci0 dev 31 function 2 not configured <damo22>its very close to booting, but i am struggling to figure out why its failing to probe <damo22>it works inside hurd with pci-arbiter, but without the arbiter as a boot task it fails <damo22>maybe i should try inside hurd without the arbiter <damo22>ahcisata0 at pci0 dev 31 function 2: vendor.... <damo22>youpi: is the "intr" stuff merged into master gnumach-sv ? <damo22>i am getting a hang on device_intr_register <damo22>its trying to register the interrupt handler i think <youpi>no, the intr RPC stuff has not been cleaned up yet from the work of Zheng Da, it's still full of TODOs <damo22>!! so my code might work if i patch my kernel <damo22>i passed through the host-priv-port to ext2fs and gave it -T typed part:2: device:/dev/wd0 <damo22>but usually i give it device:@/dev/rump:/dev/wd0 <youpi>and you passed it the rumpdisk port as master device port ? <youpi>(did you make it call it in libdiskfs?) <damo22>i didnt use --master-device-port= <youpi>it shall get it from its bootstrap port <damo22>because it needs to pick it up from bootstrap port <damo22>it appears the rump side is working <youpi>(I mean, the fsys_getpriv RPC) <damo22>its a bit hairy doing development on the same disk as the booting filesystem <damo22>trivfs_S_fsys_getpriv is not being called <youpi>make sure the code you added to call it does get called :) <damo22>maybe i should push my code somwhere <youpi>it could be useful to keep it in a safe place yes <youpi>and I can probably already apply some of it <damo22>can i create a branch on git.savannah.gnu.org/git/hurd/hurd.git? otherwise i might have to use github or something <damo22>or you cant force push to those i guess <damo22>maybe i will set up my own git daemon <youpi>yes you can create whaever damo/foobar branch you like <damo22>woot i can push with ssh:// now !! <damo22>and you can clone my repos publically <damo22>youpi: it is calling trivfs_S_fsys_getpriv now, but dies after <damo22>all i had to do was set `--multiboot-command-line=something` on the ext2fs task, and it then runs the code path to call fsys_getpriv using the console.c <youpi>ah yes you need the command line otherwise it doesn't think it's at boot <youpi>but the getpriv is not supposed to come only from console.c <youpi>but from the trivfs function I mentioned <damo22>im confused now, do i need to change libdiskfs at all? <youpi>there's a change needed in libdiskfs <youpi>I mentioned that a few time in the past days <youpi>« , you also need to change libdiskfs to call fsys_getpriv <youpi>since for now it assumes it's geting the device master port from the command line (bootstrap case) or from the proc server (non-bootstrap case) <youpi>ah, because of the console_stdio call inside init_main <youpi>does device_open() get called then? <youpi>then track between libdiskfs's working piece and libstore's device_open call <damo22>i saw machdev's fsys_getpriv call not libdiskfs' <damo22>ok i will put machprint in libdiskfs <youpi>by "working piece", I mean whatever you saw running <damo22>but what calls machdev's fsys_getpriv <youpi>like you said, libdiskfs does it when opening the console <damo22>i think i know what the problem is, diskfs is opening the console from device master, but we only want to open the disk device from rumpdisk master, as rumpdisk has no console <youpi>ah, you didn't implement device_open forwarding to the kernel device master port yet? <damo22>device_open needs to be called on two device masters <damo22>one on rump bootstrap master and one (console) on real kernel master <youpi>so make the machdev one make the second call <damo22>but diskfs opens the console as well as the disk, and how does it know <youpi>you implement the forwarding inside machdev <youpi>if librump can't find the device, make adevice_open call on the kernel master device port <damo22>machdev_is_master_device checks if port is in trivfs_protid_class, but i think i put it in the wrong bucket <damo22>i think i used trivfs_cntl_class <damo22>rumpdisk is still running but ext2fs died <damo22>is this what i do for fallback to kernel? <damo22> get_privileged_ports(NULL, &dev_master); <damo22> err = device_open (dev_master, mode, name, devp); <damo22> *devicePoly = MACH_MSG_TYPE_MAKE_SEND; <youpi>not make_send, but move_send <youpi>you're transferring the send right <youpi>#define MACH_MSG_TYPE_MAKE_SEND.. 20. /* Must hold receive rights * <youpi>you don't have a receive right, only a send right <youpi>(send as in "be able to send RPC requests") <damo22>but no log after rump: device open the 3rd time <youpi>damo22: you don't need to patch pci_device_x86_unmap_range, munmap should work fine since it's essentially vm_map <youpi>concerning the remapping of region, it's odd that it'd fail, that should be investigated later on <youpi>I believe libpciaccess will prefer to make sure mapping works before letting probe return success <damo22>something is setting the .memory to non null and it causes the next map to fail <youpi>so for upstreaming patches we'd have to make the remapping work <damo22>because there is a check for if its null <damo22>i think it checks the cached version <youpi>(there are several map_range functions) <youpi>well, yes, if' it's already mapped there is no need to map it again <damo22>yes, but if its already mapped in the previous line it sets the mapping to NULL <youpi>(as in: the mapping already done in the probe function should just already work) <youpi>oh, then that's the bug indeed <damo22>so i worked around it by avoiding to map during probe <damo22>i wasnt sure if i could reuse the mapping <youpi>linux's sysfs-based probe doesn't seem to be doing the mapping <youpi>which would explain why the bug is not seen by others <youpi>perhaps in /* Read BAR `reg_num' in `dev' and map the data if any */ <youpi>the "map the data if any" is not actually what it should do <damo22>but probing for regions is not necessary to map the region <damo22>that is done in a separate call anywa <damo22>when you want to use the region you must map it <youpi>you mean the converse ? (mapping the region to probe for regions) <youpi>I'd say that change makes sense to align on the other OSes, but it should be reported that that line 314 seems bogus, it should actually reuse the mapping <youpi>(and leave it at that, up to then to fix it) <youpi>concerning switching between x86 and hurd backends, actually a simple way could be to check whether _hurd_ports[INIT_PORT_CRDIR] is non-null <youpi>if it's null it'd mean that we don't have a / filesystem <youpi>and thus no way to lookup for a pci-arbiter, thus fallback to x86 <youpi>I'm not 100% sure for the port being null during bootstrap, but I don't see what else it could be anyway <youpi>perhaps try to print it during one of your tests <damo22>last line is rump: device_open: /dev/wd0 <damo22>it opens console and time before that <youpi>machdev_trivfs_server should be just given the port, not a pointer to the port <damo22>one thing we need to be careful is that if we take off the /dev/ prefix from the device path, it might resolve other devices to internal rump devices <damo22>because rump has a whole bunch of posix-y stuff in /dev/ <youpi>we'd have to filter that in rumpdisk before calling librump then <damo22>i think console and time failed because /console and /time dont exist in rump <youpi>better have rumpdisk's device_open only call librump for device names known to be disks in rump <damo22>its weird it never returned from device_open <damo22>im guessing its stuck in a stupid while loop <youpi>possibly it's not managing to do some i/o or such <damo22>more likely block-rump.c that i wrote is broken <youpi>I don't see why it would be related <youpi>block-rump.c is roughly only code that's called after device_open completes <damo22>block-rump.c: device_open() is stuck in there <youpi>yes but it's the rump_sys_open() call which is stuck, right? <youpi>I don't see much that could be wrong just before that would have been magically working before trying to do this during bootstrap <youpi>you can print dev_name to be sure <youpi>dev_mode_to_rump_mode() returned value would have a hard time being wrong <youpi>so I don't see how anything passed to rump_sys_open could be wrong here <youpi>so if that is stuck, then that's inside it that something odd is happening <damo22>if block_head is uninitalised, that will go on a wild goose chase looking for next pointers <youpi>I thought you were sure that rump_sys_open() was getting called? <youpi>(and block_head can't be uninitialized, it's a static variable, it'll be NULL at startup) <youpi>I mean I don't recommned trying to look for errors randomly <youpi>in very bogus code that can be useful <youpi>but I don't think your code is that bogus <youpi>and thus first look for where you are getting stuck <youpi>that's a way more efficient approach than staring at source code <damo22>hmm im missing something, im not even getting to the "rump_sys_open...returned" <damo22>i added a mach print before and after the rumpsysopen call <youpi>don't be saving on adding mach_print()s :) <youpi>? is it looping over the same element over and over ? <youpi>(I don't see how that can be, except the allocation in machdev_create_device_port() getting bogus, such as wrong size, or getting freed at some point etc.) <youpi>ah, actually that last "getting freed at some point" can make sense <youpi>since you add bd to the list even when you return a failure <youpi>you should add it to the list only when it's really sure to be a success <damo22>typed:part:2:device:/dev/wd0 on / type ext2fs (rw) <damo22>because pci-arbiter doesnt use the same pciaccess <youpi>you can use an in-kernel network driver <damo22>how do i hook up the bootstrapped rumpdisk to use it to mount another partition on the same device? <damo22>because now i cant use a separate rumpdisk instance to control the same controller <youpi>you just device_open("/dev/wd1") <youpi>since you passed the rumpdisk device master port to ext2fs <youpi>it transmitted it to all processes <youpi>i.e. you can create /dev/wd0 wd1 etC. entries <damo22># settrans -fga /dev/wd0s3 /hurd/storeio -T typed part:3:device:/dev/wd0 <damo22>ds_device_open fallback to kernel <youpi>perhaps your rump handle reuse doesn't work <youpi>too bad, it would possibly have been easier to test with it :) <youpi>I'm not completely surprised <youpi>you probably need to register rmpdisk to the startup translator <youpi>not even init telling that it shuts down services? <youpi>I'm surprised, that part should be completely independent from translators <damo22>something crashed while booting up <youpi>do you properly pass the host port to ext2fs? <youpi>otherwise userland can't access i/o <youpi>the console client needs it to access vga <damo22>i'll have to check tomorrow, ive made decent progress, but need to sleep <youpi>(answer: normally yes, because rumpdisk's main sets _hurd_host_priv, and trivfs_S_fsys_getpriv uses get_privileged_ports which reads there) ***Emulatorman__ is now known as Emulatorman
<jrtc27>hm, seems (struct foo) { ... } is regarded as non-constant by gcc, but { ... } on its own is fine <jrtc27>jrtc27@exodar:~$ printf '#include <pthread.h>\npthread_once_t crc32c_once_sw = (struct __pthread_once) { 0, 0 };\n' | gcc -x c - -o /dev/null -S -pedantic -std=gnu11 <jrtc27><stdin>:2:33: warning: initializer element is not constant [-Wpedantic] <jrtc27>jrtc27@exodar:~$ printf '#include <pthread.h>\npthread_once_t crc32c_once_sw = { 0, 0 };\n' | gcc -x c - -o /dev/null -S -pedantic -std=gnu11 <jrtc27>if you -Wno-pedantic you should be fine ***justan0theruser is now known as justanotheruser
