07:17 <sturmflut2> sb0: Without, I just took the "android-4.0" branch and booted it regularly, with the default Ubuntu kernel cmdline.

07:27 <sb0> sturmflut2, I forgot to checkout the android-4.0 branch... so I was running regular 4.0, which does have the eMMC bug

07:28 <sturmflut2> sb0: Ah, yes, that is probably the reason.

07:28 <sb0> sturmflut2, I switched to to android-4.0, but now I have the "sudden freeze" bug that is also present on arch linux kernels

07:28 <sb0> this one simply blocks the machine suddenly and completely, no message, even the cursor stops blinking in text mode, and no response to network or anything else

07:29 <sturmflut2> That happened to me once, under very high load. I have no idea where it is coming from :/

07:29 <sb0> ah, could be CPU indeed. compiling a kernel seems to cause it

07:30 <sb0> I'll try something CPU-intensive without any disk IO and see if it freezes

07:34 <sb0> with the non-crashing older kernels, I get overheating machine check exceptions under high load - but the kernel deals with those and reduces the cpu frequency

07:34 <sb0> I haven't seen any of them with android-4.0, maybe it just freezes instead of controlling the frequency

07:35 <sb0> oh, or i can just put the tablet in the freezer while compiling a kernel

07:36 <sturmflut2> Haha

07:37 <sb0> I remember doing that once years ago to let one of my laptops finish its fpga compilation without shutting down

07:57 <sb0> been compiling in the freezer for a while - still not crashed. could be a cpu thermal management issue indeed...

08:00 <sb0> intel has invented another related mostrosity that seems related to that (IOSF-MBI), i wouldn't be surprised if it was buggy

08:18 <sb0> still compiling...

08:19 <sb0> maybe i should do a proper statistical analysis of those problems. gut feeling is often wrong there.

11:18 <cr1901_modern> Hey _florent_, I've been meaning to ask: what exactly did I break when I added Windows simulation support?

11:20 <_florent_> Hi cr1902_modern

11:21 <_florent_> in fact you did not break anything

11:21 <_florent_> (The linux simulation was still working)

11:21 <_florent_> it's just that the Windows simulation was not working correctly

11:22 <_florent_> there was an issue when multiple packets were grouped together with TCP (the remaining bytes after the first packets were ignored)

11:24 <_florent_> but I only saw it on large simulations, on simple simulation your code was working

11:29 <cr1901_modern> I see... I guess I didn't test enough. The idea was to fake "SOCK_SEQPACKET", by sending the length

11:29 <cr1901_modern> But I guess I didn't code the logic to handle multiple packets coming in correctly

11:35 <_florent_> I just changed that point, and now it seems to be fine :), you've done most of the work, so thanks! (I use it to avoid changing machine when I need to do P&R on a Windows machine and test my changes)

11:40 <cr1901_modern> Sure, np :). It makes it easier to use Migen on Windows.

11:41 <cr1901_modern> Incidentally, I still haven't actually used simulations yet b/c I'm still trying to learn Migen. For whatever reason, I seem to have trouble doing anything complicated

13:00 <cr1901_modern> Assuming I'm reading the generated verilog code for simple_gpio.py correctly, why does the CSR bus output data on the read bus while simultaneously being written on the write bus?

13:04 <cr1901_modern> I'm really used to shared/bidirectional data buses apparently

14:59 <sb0> sturmflut2, the full linux kernel build completed successfully while in the fridge.

14:59 <sb0> I've never been able to do that without crashing on a 4.x kernel ...

14:59 <sb0> so yeah, it looks like there could be some CPU thermal management bug

15:00 <sb0> before that I ran either into the eMMC or the sudden freeze bug (which I thought was the eMMC, but they are probably two different issues)

15:06 <sturmflut2> sb0: Goddamned, Intel. It's like they WANT to screw up in the mobile market. It's 2015, how can CPUs still overheat and lock up?

15:28 <ysionneau> sb0: in session.c, for flash storage related messages, when validating the key len, what should I do if the key is too long (missing \0 for instance)? log() some error + send back an error message ? (means adding REMOTEMSG_TYPE_FLASH_KEYERROR_REPLY?)

15:48 <sb0> yes

15:48 <sb0> just one type of error message is enough

15:49 <sb0> sturmflut2, should do more testing with and without cooling...

15:49 <sb0> those random bugs are tricky