03:09
_whitelogger has joined #m-labs
04:09
rohitksingh_work has joined #m-labs
04:24
sb0 has joined #m-labs
05:10
sb0 has quit [Quit: Leaving]
06:45
_whitelogger has joined #m-labs
06:51
_whitelogger has joined #m-labs
07:44
m4ssi has joined #m-labs
08:16
<
rjo >
sb0: suservo has an rtio address that's wider than 8 bit. but the data is 24 bit iirc, i.e. you can move address bits into the data word.
09:15
sb0 has joined #m-labs
09:21
<
GitHub-m-labs >
migen/master 28a5f32 whitequark: genlib/fsm: add basic FSM tests.
10:07
<
rjo >
sb0: i don't foresee any. but please don't take that to mean that you don't have to look at the code.
10:30
<
GitHub-m-labs >
migen/master 1fdf5db Florent Kermarrec: lattice/diamond: use build_name as top name
10:30
<
GitHub-m-labs >
migen/master 48023fa Florent Kermarrec: lattice: fix Misc constraints
10:30
<
GitHub-m-labs >
migen/master 2dc085d Florent Kermarrec: lattice/common: no need to differentiate nbits==1 and nbits > 1
10:57
<
sb0 >
okay the weird unittest breakage is due to the removal of the now save/restore mechanism in 8caea0e6d3a91e625f84172e455229920dca930f
10:58
<
GitHub-m-labs >
migen/master 319d3cd Florent Kermarrec: build: use default toolchain_path on all backends when toolchain_path passed value is None
11:52
<
GitHub-m-labs >
artiq/new 59033d2 Sebastien Bourdeauducq: firmware: workaround for RPC failures
11:52
<
sb0 >
bb-m-labs: force build --branch=new artiq
11:52
<
bb-m-labs >
build forced [ETA 1h05m36s]
11:52
<
bb-m-labs >
I'll give a shout when the build finishes
12:07
<
sb0 >
whitequark: could it be another bug with this double-mailbox async RPC mechanism?
12:08
<
whitequark >
sb0: that seems unlikely
12:08
<
whitequark >
how would it interact?
12:09
<
sb0 >
this bug is unexpected, so i don't know. something is wrong somewhere.
12:09
<
sb0 >
and it seems to be triggered by RPCs
12:09
<
sb0 >
and it is hidden by messing with the mailbox in the same way that the now save/restore mechanism does
12:10
<
whitequark >
ok, I see
12:10
<
whitequark >
this line of thinking makes sense to me
12:10
<
whitequark >
not sure what the bug is though, I've spent quite a while on the async RPC mechanism...
12:10
<
whitequark >
what if you disable async RPCs?
12:35
sb0 has quit [Quit: Leaving]
12:36
rohitksingh_work has quit [Read error: Connection reset by peer]
12:53
d_n|a_ has joined #m-labs
12:55
d_n|a__ has joined #m-labs
12:56
d_n|a has quit [Ping timeout: 246 seconds]
12:58
d_n|a_ has quit [Ping timeout: 246 seconds]
13:06
sb0 has joined #m-labs
13:13
<
sb0 >
rjo: what to move into the data? profile?
13:14
<
sb0 >
rjo: that would still limit channel to 3
13:23
rohitksingh has joined #m-labs
13:29
<
rjo >
or profile (5 bits) and the three coefficient selection bits
14:46
<
sb0 >
whitequark: what is the purpose of LAST in mailbox.rs?
14:47
<
whitequark >
sb0: you wrote that code, actually
14:47
<
whitequark >
I mean, the C code was the same
14:47
<
whitequark >
and it took me a while to understand how it works.
14:47
<
whitequark >
I then tried to remove LAST but it was very persistent, so I kept it.
14:48
<
whitequark >
I think the idea is to make it work as half-duplex.
14:48
<
whitequark >
so, you send something, if you read back the same thing, it means there's no reply or ack.
15:03
<
sb0 >
ffs this bug makes no sense at all
15:05
<
sb0 >
symptom: prints None
15:08
<
sb0 >
whitequark: any ideas?
15:09
<
sb0 >
flushing the dcache or calling kern_acknowledge in session.rs kern::RunFinished has no effect
15:10
<
whitequark >
can you give me lock?
15:11
<
sb0 >
whitequark: done
15:11
<
sb0 >
or use the kc705
15:14
<
whitequark >
definitely async RPC related
15:14
<
whitequark >
it's a race I think
15:14
<
whitequark >
let me see if I can fix it
15:20
<
whitequark >
sb0: are you building a branch?
15:20
<
sb0 >
whitequark: "new" branch
15:26
<
sb0 >
so what is happening? the kernel dies before the async rpc completes?
15:26
<
whitequark >
it's a TOCTTOU
15:29
<
whitequark >
actually, not quite
15:29
<
whitequark >
it's more of an ordering issue
15:31
<
GitHub-m-labs >
artiq/new 0edae64 whitequark: firmware: fix TOCTTOU race in sync/async RPC code....
15:35
<
whitequark >
hm, now that I think about it, there is
*another* race condition there, much more subtle
15:35
<
whitequark >
and the easiest way to fix it is just to have a dummy request that flushes the async RPC queue
15:42
<
sb0 >
is it difficult to have only 1 mailbox for everything?
15:42
<
GitHub-m-labs >
artiq/new 583bba8 whitequark: Revert "firmware: workaround for RPC failures"...
15:42
<
GitHub-m-labs >
artiq/new dd829af whitequark: firmware: fix another TOCTTOU race in sync/async RPC code.
15:46
<
whitequark >
I recall there being some issue with it, but it's been a while
16:28
mauz555 has joined #m-labs
16:52
<
sb0 >
bb-m-labs: force build --branch=new artiq
16:52
<
bb-m-labs >
build forced [ETA 1h04m21s]
16:52
<
bb-m-labs >
I'll give a shout when the build finishes
16:52
<
sb0 >
whitequark: still using the board?
16:54
<
whitequark >
sorry, no
16:54
<
whitequark >
released
16:58
<
GitHub-m-labs >
artiq/master 68aad3e whitequark: firmware: fix TOCTTOU race in sync/async RPC code....
16:58
<
GitHub-m-labs >
artiq/master 248c1cf whitequark: firmware: fix another TOCTTOU race in sync/async RPC code.
16:59
<
sb0 >
whitequark: thanks
17:00
<
GitHub-m-labs >
artiq/release-3 ae88c13 whitequark: firmware: fix TOCTTOU race in sync/async RPC code....
17:00
<
GitHub-m-labs >
artiq/release-3 dbd1cb9 whitequark: firmware: fix another TOCTTOU race in sync/async RPC code.
17:05
m4ssi has quit [Quit: Leaving]
17:47
mauz555 has quit [Remote host closed the connection]
18:41
mauz555 has joined #m-labs
18:47
rohitksingh has quit [Ping timeout: 246 seconds]
19:08
mauz555 has quit [Remote host closed the connection]
20:09
cr1901_modern has quit [Ping timeout: 246 seconds]
20:47
mauz555 has joined #m-labs
21:40
mauz555 has quit [Read error: Connection reset by peer]
21:40
cr1901_modern has joined #m-labs
21:52
mauz555 has joined #m-labs
22:42
mauz555 has quit [Read error: Connection reset by peer]