***Server sets mode: +nt
***Server sets mode: +nt
***Emulatorman__ is now known as Emulatorman
***Emulatorman_ is now known as Emulatorman
<damo22>youpi: what can i put in hurd code to trigger a kernel db> <damo22>assert_perror_backtrace(FALSE) ? <damo22>i want to know if a code path is being executed and my mach_print is too verbose <youpi>damo22: you can break into the debugger with control-alt-d, and there put type <youpi>w debug_all_traps_with_kdb 1 <youpi>and then trigger a process crash from userland, which will trigger the dbg instead of sending the exception to userland <damo22>im guessing i need to add the server stubs for i386_io_perm* to libtrivfs <damo22>theres some mig magic going on that will allow it to be called i think <youpi>you need to call the demuxer from your demuxer loop yes <damo22>/usr/bin/ld: ../libmachdev/libmachdev.so: undefined reference to `S_i386_io_perm_create' <damo22>how do i make it use the trivfs_S prefix <youpi>there's a mig option for that, look in other Makefiles <damo22>ive already written the stubs for trivfs_S_i386_io_perm* in libtrivfs and i was able to link libtrivfs <damo22>somehow trivfs_S_fsys_* works but trivfs_S_i386_io_perm_* does not <youpi>did you add the demux call in your demuxer loop? <damo22>i havent pushed my latest changes anywhere yet <youpi>(I don't think you want to put them in libtrivfs, most probably rather in libmachdev) <damo22>fsysopts: /servers/socket/2: -i /dev/eth0: (ipc/mig) server died <damo22>Error getting interfaces; Translator died <damo22>i think it tried to open io ports at the same time as the arbiter? <youpi>you can start netdde by hand, see the debian setup page <damo22>i did service networking restart <youpi>really see that page to start netdde by hand <damo22>eth%d: i82596 initialization timed out <damo22>maybe there is a timeout and the mach_print causes it to time out <damo22>i wrote a custom qemu patch to disable built in ahci in q35 machine <damo22>but i was not using it, so i had an extra ahci controller <damo22>now i am getting something interesting: <damo22>device_intr_register returns -303 <damo22><3>0000:00:02.0: eth0: Unable to allocate interrupt, Error: -16 <damo22>youpi: what patches do i need for device_intr_register? is it the old debian ones? <youpi>device_intr_register is still only a patch in the debian package <youpi>(with a lot of XXX and FIXMEs...) <damo22>i applied it to gnumach and rumpdisk works, but netdde fails on device_intr_register with -303 <youpi>is rumpdisk using intr registration? <youpi>it's odd that one would be able to register, and the other get BAD_ID <damo22>is it possible to have irq working without that? <youpi>just to make sure, you are not using the patch from the master-user_level_drivers branch, which is using different ids than the debian patch? <damo22>#define INTR_NOTIFY_MSGH_SEQNO 0 <damo22>unless my netdde was built with different /usr/include/device/intr.h <youpi>damo22: I don't know for your netdde, but the one shipped in debian uses these values <youpi>and that's what the debian dde patch uses <youpi>when you say "it must be" about irq working <youpi>are you really talking about a userland process using irqs ? <youpi>device_intr_register is done on the master device port <youpi>so you'd have to forward that to the kernel as well <youpi>otherwise it's your device master port interposing that returns bad_id <damo22>pci-userspace part of rump uses it <youpi>I'm thinking that all these RPCs introduced on the master device port should actually be moved to a separate device, that you'd first get with a device_open call <youpi>yes but that's inside rumpdisk, isn't it? <youpi>which directly talks with the kernel <damo22>but i thought my device_open falls back to kernel <youpi>yes, but these device_intr* are done on the master device, not on a deivce opened with device_open <youpi>thjat's precisely what I mentioned above: we should move that <youpi>i.e. userland first device_open("irq") and then use intr_register on the obatined device port <damo22>i wonder what else should be a device <youpi>there are the demux calls in ipc_kobject_server <youpi>that's where the i386-specific plugs (and thus shouldn't, rather go along lpr com etc. <youpi>and that's also where intr plugs (ditto) <youpi>that should be checked, but probably there aren't really others <youpi>(first step being to make glibc first try to open the device and call the perm RPC on the obtained port, and if the device is not found, fallback on making the RPC on the master device port itself) <youpi>(so we have backward compatibility)