shamoe has quit [Quit: Connection closed for inactivity]
vagrantc has quit [Quit: leaving]
EchelonX has quit [Quit: Leaving]
<sorear>
is it just me, or are the wavedrom bit diagrams in unpriv-isa-asciidoc vastly preferable to the bytefield-svg bit diagrams in priv-isa-asciidoc
HumanG33k has quit [Ping timeout: 264 seconds]
notgull has quit [Ping timeout: 246 seconds]
notgull has joined #riscv
gdd has quit [Ping timeout: 240 seconds]
notgull has quit [Ping timeout: 260 seconds]
notgull has joined #riscv
heat has quit [Ping timeout: 246 seconds]
HumanG33k has joined #riscv
notgull has quit [Ping timeout: 264 seconds]
Stat_headcrabed has joined #riscv
notgull has joined #riscv
gdd has joined #riscv
notgull has quit [Ping timeout: 276 seconds]
Stat_headcrabed has quit [Quit: Stat_headcrabed]
MaxGanzII has quit [Ping timeout: 255 seconds]
jacklsw has joined #riscv
KREYREN has joined #riscv
BootLayer has joined #riscv
KREYREN has quit [Ping timeout: 255 seconds]
ntwk has quit [Ping timeout: 240 seconds]
shamoe has joined #riscv
KREYREN has joined #riscv
q66 has quit [Ping timeout: 255 seconds]
Starfoxxes has joined #riscv
jmdaemon has quit [Ping timeout: 240 seconds]
BootLayer has quit [Quit: Leaving]
q66 has joined #riscv
davidlt has joined #riscv
jobol has joined #riscv
crossdev has joined #riscv
shamoe has quit [Quit: Connection closed for inactivity]
<sorear>
kisp capstone is interesting, they managed to weld a capability derivation and revocation system very similar to sel4's onto cheri's data model. i wonder if they looked into two-color concurrent GCs instead of refcounting
zkrx has joined #riscv
pabs3 has quit [Read error: Connection reset by peer]
pabs3 has joined #riscv
jacklsw has quit [Ping timeout: 260 seconds]
crabbedhaloablut has quit []
crabbedhaloablut has joined #riscv
loki_val has joined #riscv
crabbedhaloablut has quit [Ping timeout: 256 seconds]
ezulian has quit [Quit: ezulian]
prabhakarlad has joined #riscv
notgull has joined #riscv
ezulian has joined #riscv
prabhakarlad has quit [Quit: Client closed]
Andre_Z has joined #riscv
ntwk has joined #riscv
rvalles has quit [Quit: rvalles]
prabhakar has quit [Ping timeout: 252 seconds]
loki_val has quit [Ping timeout: 264 seconds]
crabbedhaloablut has joined #riscv
rvalles has joined #riscv
benh has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
benh has joined #riscv
prabhakarlad has joined #riscv
prabhakar has joined #riscv
epony has quit [Remote host closed the connection]
psydroid has joined #riscv
epony has joined #riscv
epony has quit [Excess Flood]
epony has joined #riscv
hightower2 has joined #riscv
prabhakarlad has quit [Ping timeout: 250 seconds]
kaaliakahn2 is now known as kaaliakahn
Tenkawa has joined #riscv
Orac has joined #riscv
Tenkawa has quit [Ping timeout: 264 seconds]
mwette has joined #riscv
foton has quit [Ping timeout: 264 seconds]
foton has joined #riscv
Leopold has quit [Quit: No Ping reply in 180 seconds.]
heat has joined #riscv
Leopold has joined #riscv
cwittlut_ is now known as cwittlut
Orac is now known as Tenkawa
* bjdooks
is off towards FOSDEM
<geertu>
bjdooks: CU soon!
Andre_Z has quit [Quit: Leaving.]
balrog has quit [Quit: Bye]
courmisch has quit [Read error: Connection reset by peer]
courmisch has joined #riscv
ntwk has quit [Read error: Connection reset by peer]
balrog has joined #riscv
Andre_Z has joined #riscv
foton has quit [Read error: Connection reset by peer]
Tenkawa has quit [Quit: Was I really ever here?]
foton has joined #riscv
BootLayer has joined #riscv
crossdev has quit [Ping timeout: 260 seconds]
jmdaemon has joined #riscv
Tenkawa has joined #riscv
billchenchina has joined #riscv
zBeeble42 has quit [Remote host closed the connection]
zBeeble has joined #riscv
unnick has quit [Ping timeout: 256 seconds]
unnick has joined #riscv
jmdaemon has quit [Ping timeout: 268 seconds]
shamoe has joined #riscv
unnick has quit [Ping timeout: 256 seconds]
theruran has joined #riscv
mlw has quit [Ping timeout: 268 seconds]
mlw has joined #riscv
Andre_Z has quit [Quit: Leaving.]
billchenchina has quit [Quit: Leaving]
heat has quit [Read error: Connection reset by peer]
heat has joined #riscv
jmdaemon has joined #riscv
ntwk has joined #riscv
heat_ has joined #riscv
zv has quit [Ping timeout: 252 seconds]
zv has joined #riscv
heat has quit [Read error: Connection reset by peer]
heat_ is now known as heat
mwette has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.1)]
JanC has quit [Killed (lithium.libera.chat (Nickname regained by services))]
JanC_ is now known as JanC
Tenkawa has joined #riscv
jfsimon1981 has joined #riscv
mlw has quit [Ping timeout: 260 seconds]
crossdev has quit [Remote host closed the connection]
jmdaemon has joined #riscv
<palmer>
does anyone have a Pioneer? I'm worried that kernel fence/fairness bug hits userspace too, as folks have been complaining about things going oddly slowly
mwette has quit [Ping timeout: 260 seconds]
<conchuod>
palmer: yes but I have still got the thing running what they shipped it with
jmdaemon has quit [Ping timeout: 260 seconds]
jobol has quit [Quit: Leaving]
junaid_ has joined #riscv
crossdev has joined #riscv
epony has quit [Remote host closed the connection]
<conchuod>
palmer: If there's some specific shit that needs tested or w/e I can do it though. Or I could prob give ssh access to you.
<palmer>
I think running the vendor kernel is OK for this, as it's a userspace lock I'm worried about
<palmer>
looks like stress-ng's atomic tests are the easiest way to start
crossdev has quit [Remote host closed the connection]
<davidlt>
conchuod, try something like: stress-ng --verbose --aggressive --atomic 64 --timeout 600 (I don't recall what is default timeout)
<conchuod>
davidlt: On the vendor kernel?
<davidlt>
I am using Fedora 38 image, newer one from their forums (not on their download page)
<conchuod>
(and vendor userspace etc too obviously)
<davidlt>
But otherwise everything vendor (incl. their repos)
crossdev has joined #riscv
<conchuod>
Oke, I can give that a go once I am done eating
<davidlt>
Basically what test does not terminate at timeout, ignore kill signal, but finishes after a long time IIRC.
<davidlt>
I didn't test, but I wonder how xz multi-threaded compression scales.
<davidlt>
I have rpmbuild spinning 64-cores 100% load for hours trying to write out glibc RPMs, and overall it's taking more time than Unmatched.
unnick has joined #riscv
<davidlt>
The board likes to hang sometimes too (lost two GCC builds, one golang build, etc)
<davidlt>
But that seems somewhat random.
ezulian has quit [Ping timeout: 260 seconds]
<conchuod>
davidlt: I'll turn on the leafblower
<davidlt>
:D
<davidlt>
I lost the small fan within 20 hours, and one of the bigger ones 80mm is already screaming at me
<davidlt>
ok, I am off for tonight
theruran has quit [Quit: Connection closed for inactivity]
<conchuod>
Okay I love this
<conchuod>
The official docs for the board use the username "neko"
davidlt has quit [Ping timeout: 264 seconds]
<conchuod>
Ayaya
___nick___ has quit [Ping timeout: 264 seconds]
junaid_ has quit [Remote host closed the connection]
ntwk has quit [Ping timeout: 252 seconds]
Tenkawa has quit [Quit: Was I really ever here?]
Tenkawa has joined #riscv
ntwk has joined #riscv
<conchuod>
palmer: Do you know what I am supposed to be looking for with these tests?
<palmer>
my general theory is that magic fence that Guo proposed for the kernel spinlocks is also necessary in userspace, it's just that userspace is more tolerant of random hangs so nobody's bothered to figure it out yet
<conchuod>
palmer: I mean what do you want to see from my stress-ng run
<palmer>
let me try and write a simpler test for it...
<mps>
on pioneer?
<conchuod>
Build me a stress-ng binary :)
<palmer>
if I cross-build a static binary it might work, I can try?
<conchuod>
also dk just walked past me in wow called "dirtypalmer"
<sorear>
the stress-ng output gave near-identical responses for 8/16/32/64, which makes me think that any hypothetical workaround is also needed for lr/sc
<palmer>
sorear: no idea, but it'd end up as a vendor-specific workaround (though I guess it's a bit more of a headache if go-fast on T-Head is go-slow everywhere else...)
Tenkawa has quit [Quit: Was I really ever here?]
<sorear>
if that's actually the best we can do it
<sorear>
'd make more sense to be in opensbi
<sorear>
...accidentally breaking there completely changes the meaning
<palmer>
ya, mabye? Right now I'm just trying to figure out what this HW actually does...
<jrtc27>
re interrupt causing stores that flush things out, that was my assumption reading the thread
<jrtc27>
presumably if you get unlucky you have interrupts masked at just the wrong point in your spinlock code though?
<conchuod>
palmer: what do you want (if anything) done with that program you linked?
<jrtc27>
but agreed that knowing the actual hardware issue would be rather useful...
<palmer>
conchuod: OK, so I think my theory was wrong?
<sorear>
it's possible that the underlying bug is a failure of FIFO prioritization, and you'll need to add some stores to the inner loop and get the hardware to prefer the decoy stores over the sync stores somehow
<conchuod>
I re-ran boring again after magic and got ~identical output
<conchuod>
~indentical to the magic output*
<conchuod>
and then another magic which was faster again :)
<palmer>
ya, it'd have to be way off for something interesting here
<sorear>
so... stress-ng?
<palmer>
ya, but we don't really know if stress-ng is actually slow because of this, or if it's just something else