IRC channel logs

***Server sets mode: +nt

<damo221>youpi: nice job with interrupts, i will test your changes later tonight

<damo221>as im at work

<damo22>youpi: im getting this printed once per second on average:

<damo22>irq handler 11: release dead delivery 0 unacked irqs

<damo22>after i run rump twice

<damo22>(once and then stop, then again)

<damo22>is there an off by one bug that tries to release even though there are zero unacked irqs?

<damo22>or did i screw up something in pci-userspace in rump?

<youpi>ah, that's because the gnumach code doesn't clean yet until an actual irq happens. It's harmless, just noisy. I'll fix that

<damo22>but it somehow prevents rump from working again the second time

<damo22>with my old patchset i was able to run my test rump program many times

<damo22>it opens the block device and dumps first sector

<youpi>it's surprising that you can't run a second time

<youpi>I did test that with netdde, it was working fine

<youpi>where is your rump code?

<damo22>its all in incubator

<damo22>i added some patches from debian for gnumach on top of origin/master-user_level_drivers-debian

<youpi>I don't see intr_register/enable calls in there

<youpi>the rump branch in the incubator, right?

<damo22>yeah but it refers to external code from github

<damo22>i didnt want to include all of it

<youpi>well, that's what I need to see, the code that manages irqs :)

<damo22>let me find it

<damo22> https://github.com/zamaudio/pci-userspace/tree/upstreaming-rump-hurd

<damo22>im on that branch

<youpi>ok, the intr_register/enable code looks ok

<youpi>what actually happens on the second run?

<youpi>does it just not get interrupts?

<youpi>I guess you should add printfs in the gnumach user-level interrupts code to make sure what is happening

<damo22>ok

<damo22>how do i build a debug kernel without debian packaging

<youpi>--enable-kdb

<damo22>does mach_print work without that?

<youpi>no

<damo22>ok thats why then

<damo22>what about using s = splhi() and splx(s) instead of cli/sti in device/intr.c

<damo22>is that appropriate? wont it restore the previous flags

<youpi>that'd probably be better yes

<youpi>the people who wrote the code probably didn't know about spl etc.

<damo22>ok

<damo22>something is still fishy with interrupts, or theres a bug in rump

<damo22>maybe i should revert my changes to the netbsd source that limits the timeouts

<damo22>maybe we just fixed everything

<damo22>arggh i cant make rump link with pciaccess anymore

<damo22>"LDFLAGS += -lpciaccess" doesnt work in the Makefile.inc

<damo22>fixed

<damo22>LDFLAGS += -Wl,--no-as-needed -lpciaccess -Wl,--as-needed

<damo22>irq fired: 11

<damo22>k_handle...k_done

<damo22>task /hurd/rumpdisk(2128) deallocating a bogus port 107, probably a bug

<damo22>thats the last 3 lines of output from mounting a disk

<youpi>more printfs would probably be useful

<youpi>damo22: not only using splhigh/splx instead of cli/sti in intr.c is better, it actually is now needed

<youpi>previously the code wasn't calling code that uses splhigh/splx, but now it is

<youpi>and thus we need proper nesting

<youpi>I have pushed updated branches, I'll upload a fixed package

<youpi>I have been high by the issue on buildds

<youpi>s/high/hit/

<youpi>I have fixed another issue with crashed netdde

<youpi>see latest push, and I'll upload a fixed debian package again.

IRC channel logs

2019-11-12.log