<youpi>gnu_srs2: mach_print should be working anywhere ***Server sets mode: +nt
<damo22>youpi: i have netdde working and rumpdisk with new RPCs <damo22>BUT irq sharing is broken with compat <damo22>if all irqs are distinct, everything seems to work fine <damo22>but junlingm here reported irq hanging when sharing <junlingm>in fact, when my program is running, it is ok. The network hangs is I quit my program. Maybe I forgot to replease the receive_port for irq? <junlingm>I did release it. My network card and ehci shared an interrupt line. <junlingm>youpi: if two devices share an interrupt line, show both ack the line in do_device_intr_notify? <jrtc27>all drivers sharing an interrupt line must ACK the kernel, and the kernel should only send EOI to the PIC once all drivers have responded <jrtc27>(since there's no way to know which device triggered the interrupt) <junlingm>ok. Then I don't know why my network hangs after I quick my program. <damo22>jrtc27: im not sure if that functionality is implemented <jrtc27>well, I have no clue what's implemented :D <damo22>there are counters that count how many times an interrupt on the same line is used <jrtc27>so yeah if there's no refcounting or other stuff like that then I could easily see terminating one process causing the other to not get interrupts <junlingm>my netdde uses the old interface, while my program uses the new irq device. Would that be a problem? <damo22>junlingm: i need youpi to help because i dont fully understand how he made both interfaces work simultaneously <youpi>damo22: the intr_receive_ports array is a hack, I'm not surprised that shared irq doesn't work. that was actually the problem with the old lookup by intr line rather by port <youpi>I don't really think we want to try to care, but rather make netdde/rump just use the new interface and be done <damo22>i have sent a patch for libddekit to the ml, and i have similar patchset for rump already <damo22>i dont know how to proceed for pci-arbiter support <damo22>currently rump boots / without the arbiter, but network obv needs the arbiter <youpi>for the pci-arbiter at bootstrap, as I mentioned we can use the same bootstrap port passing as between rumpdisk and ext2fs <youpi>the difficulty here being that it's libpciaccess which needs to be told the port to use the pci-arbiter <youpi>but I'd say that libpciaccess can use a weak reference to a variable that contains the port to be used <damo22>youpi: junlingm seems to have found that netfs may be missing io_remap (?) would that make it difficult to map pci regions using the arbiter? <youpi>trans/fakeroot.c defines it for instance <youpi>but what the arbiter would return is a kernel memory object anyway <damo22>im wondering what the best way forward is, should i get it all to a working state and then we refactor ? <damo22>or can we make it work without the arbiter first and polish that, then introduce the arbiter <youpi>I'd say make it work without the arbiter first <youpi>before making the arbiter part of the bootstrap <youpi>we don't actually have arbitration concerns since rump will be starting strictly between gnumach and netdde <youpi>so pragmatically speaking, it should be a way that already works fine <damo22>i have it barebones working with rump booting / i need to polish the patches <youpi>so we can get that finished, commited, before continuing <youpi>btw, just a comment on the gnumach support for intr, there were two uninitialized variables which were making things hang <youpi>the n_unacked field, and ... <youpi>(can't remember the other one without looking) <damo22>it seems you did a lot of polishing before committing <youpi>which surprised me, we should have been getting a warning for that one <youpi>well, mostly the documentation <youpi>(which Zheng Da should have done upfront :/ ) <youpi>ah yes also I dropped the magic flag value <youpi>we can only support drivers that support shared irqs anyway <damo22>yeah one thing i noticed there, should it be set to SA_INTERRUPT | SA_SHIRQ <youpi>SA_INTERRUPT is really an oldie, we usually don't need it <damo22>it causes no cli(); to be called <youpi>queue_intr already uses splhigh() to handle concurrency <youpi>cli() was really only used for really dumb hardware that required timely reaction to interrupts <damo22>i did review your code changes in gnumach and thats all i could see <damo22>i thought SA_INTERRUPT was a needed flag <youpi> I had the same reaction a minute ago when you mentioned the flag actually <youpi>then thought 'nah that'd be a dumb flag since it's necesasrily an interrup' <youpi>then I remembered that cli() oldie <youpi>and SA_INTERRUPT meaning "don't interrupt me again while I'm handling the interrupt" <damo22>another unrelated thing, in rumpkernel i had to add : <damo22>+ appendvar EXTRA_CWARNFLAGS -Wno-sign-compare <damo22>due to device RPC having strange typing <damo22>i dont remember the exact warning but it was a warning->error <damo22>it occurred when building the pci-userspace component of rump with the new irq RPCs <damo22>youpi: thank you again for your great help <damo22>i tried to get things over the line but it always seems to need a little extra <youpi>well, you already did a huge lot without me :) <damo22>my goal is for people to be able to run a hurd system one day for day to day activities <rekado_>damo22: there is no *one* GNU system, so that’s unlikely. ***rekado_ is now known as rekado
<rekado>damo22: there is no *one* GNU system, so that’s unlikely. <gnu_srs2>rekado: The original plan was to call gnumach+hurd+glibc GNU. Now it might be called GNU/Hurd as GNU/Linux is. <jrtc27>yeah the triple's i386-gnu which makes some people unhappy <jrtc27>in 2020 i386-hurd-gnu likely makes more sense (as has been "faked" in the LLVM world to appease them) ***junlingm is now known as 18VAA78V0
***roptat_ is now known as roptat
<gnu_srs2>youpi: Sorry, but mach_print does not work for the cases I tried :( <youpi>gnu_srs2: did you cross check that in another binary it does work? <youpi>are you properly running a -dbg kernel ? <gnu_srs2>Yes, without the mach_print changes (and some new test code, after the mach_prints) Yes I do run a -dbg kernel. I even added the to mach_print code to proc/wait.c. No successful boot. <youpi>"in another binary it does work": I mean, adding mach_print in another program and try to run that <youpi>to check that mach_print works at all with the kernel you use