IRC channel logs


back to list of logs

<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
<jrtc27>just what _should_ be there
<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
<damo22>also, im "at work" now
<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>using these patches for hurd and these for rumpkernel
<damo22>i dont know how to proceed for pci-arbiter support
<damo22>currently rump boots / without the arbiter, but network obv needs the arbiter
<damo22>youpi: ^
<youpi>yep, seen the patches
<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>it does have netfs_S_io_map
<youpi>trans/fakeroot.c defines it for instance
<damo22>okay so it should work then
<youpi>but what the arbiter would return is a kernel memory object anyway
<youpi>(I guess)
<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>for what part ?
<damo22>well, for rump booting /
<youpi>I'd say make it work without the arbiter first
<youpi>and polish that
<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
<damo22>which ones? do you recall?
<youpi>the n_unacked field, and ...
<damo22>oh ok
<youpi>(can't remember the other one without looking)
<damo22>no worries
<youpi>ah, ret in irq_çack
<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
<damo22>i overlooked the docs
<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>wherer ?
<damo22>let me find the line
<youpi>I mean
<youpi>in netdde ?
<youpi>in the RPC stub ?
<youpi>SA_INTERRUPT is really an oldie, we usually don't need it
<damo22>it causes no cli(); to be called
<youpi>that's fine
<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>that was unusual to me
<youpi>what was unusual?
<damo22>i thought SA_INTERRUPT was a needed flag
<damo22>to say this is an interrupt
<youpi>it's an interrupt anyway :)
<damo22>no worries
<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
<damo22>i couldnt do it without you
<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
<damo22>will it be called GNU?
<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