IRC channel logs


back to list of logs

***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
<gnu_srs>damo22: Is that a good sign?
<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>hmm lets see what happens now
<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>ext2fs died
<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 it call fsys_getpriv ?
<youpi>(did you make it call it in libdiskfs?)
<damo22>i think so
<damo22>i need to check allt hat
<damo22>i didnt use --master-device-port=
<damo22>for ext2fs
<youpi>yes, that's expected
<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>is it getting called?
<damo22>but handoff to ext2fs is broken
<youpi>(I mean, the fsys_getpriv RPC)
<damo22>i'll put a mach_print in there
<damo22>its a bit hairy doing development on the same disk as the booting filesystem
<damo22>trivfs_S_fsys_getpriv is not being called
<damo22>in libmachdev
<youpi>make sure the code you added to call it does get called :)
<damo22>maybe i should push my code somwhere
<youpi>and on the bootstrap port
<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 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
*youpi powerdown
<damo22>youpi: i wont lose my work now:
<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
<youpi>err, diskfs function
<damo22>im confused now, do i need to change libdiskfs at all?
<damo22>i havent touched that
<youpi>there's a change needed in libdiskfs
<youpi>I mentioned that a few time in the past days
<damo22>i thought you retracted that
<youpi>« , you also need to change libdiskfs to call fsys_getpriv
<youpi>like I mentioned earlier
<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> (in diskfs_init_main() )
<youpi>ah, because of the console_stdio call inside init_main
<youpi>does device_open() get called then?
<damo22>no i havent seen device open
<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>ah ok
<damo22>btw, if you want to see my code, it's all here
<youpi>I saw in the log yes
<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>i dont think so
<youpi>you need to :)
<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
<youpi>and pass that
<damo22>but diskfs opens the console as well as the disk, and how does it know
<youpi>it doesn't
<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
<youpi>and return the result
<damo22>nice idea
<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
<youpi>I'd say make it accept both
<youpi>that'll be simpler
<damo22>rump: device_open
<damo22>rump_sys_open failed
<damo22>now im getting somewhere
<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>somehow i am in userspace
<damo22>when i dropped with kdb
<damo22>all tasks are running
<damo22>but no log after rump: device open the 3rd time
<youpi>did rump_sys_open() return?
<damo22>goo q
<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>in map_range
<damo22>i think it checks the cached version
<youpi>which check exactly?
<youpi>(there are several map_range functions)
<damo22>i'll find it
<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)
<damo22>it doesnt reuse the mapping
<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>that being said
<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)
<damo22>sorry yes
<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>ah :/
<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>which was only luck :)
<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>and its using 100% cpu
<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
<damo22>i printed name it was /dev/wd0
<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> while (bd)
<damo22> {
<damo22> if (!strcmp (bd->name, name))
<damo22> return bd;
<damo22> bd = bd->next;
<damo22> }
<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
<damo22>neither are printed
<youpi>don't be saving on adding mach_print()s :)
<damo22>i must be getting close
<damo22>stuck in while loop
<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>it booted
<damo22>stuck in zillions of log
<damo22>i need to install old librump
<damo22>then i can test boot
<damo22>hmm old debs dont work
<damo22>ah yes, a small librump patch
<damo22>typed:part:2:device:/dev/wd0 on / type ext2fs (rw)
<youpi>yeha :D
<damo22>i had to skip netdde
<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
<youpi>with the storeio translator
<youpi>see showtrans /dev/hd0
<damo22># settrans -fga /dev/wd0s3 /hurd/storeio -T typed part:3:device:/dev/wd0
<youpi>that looks like it yes
<damo22>it failed to open
<damo22>i ran e2fsck on it
<damo22>rump: device_open: /dev/wd0
<damo22>rump device_open exit (fail)
<damo22>ds_device_open fallback to kernel
<youpi>perhaps your rump handle reuse doesn't work
<damo22>ok i see
<youpi>do you have a wd1?
<damo22>no i dont
<youpi>too bad, it would possibly have been easier to test with it :)
<damo22>this is pretty cool
<damo22>except reboot command is stuck
<youpi>where does it get stuck
<youpi>I'm not completely surprised
<youpi>you probably need to register rmpdisk to the startup translator
<damo22># reboot
<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
<damo22>something with a lot of options
<damo22>-vga -console -kbd
<damo22>but couldnt read it all
<youpi>that's the console client
<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
<youpi>(I mean, in fsys_getpriv)
<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)
<gnu_srs>Hi, need some help:
***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
<jrtc27>(or don't pass -pedantic)
***justan0theruser is now known as justanotheruser