Reboots/crashes - RRF ≤3.5.0-rc1

Exerqtor

@dc42 Ok let's see, I've installed those last binaries and the "normal" 3.5.0rc1+ release on the 1LC.

After that I tried one of the jobs that failed earlier, and it completed without reversing the extruder (or crashing).

I'll try some of the other jobs that has failed too now and see of they also complete.

Should i still leave the "stuff" we put in daemon.g be there for a while btw?

(Copying this response to the other thread too, since it's refering to the same binaries)

dc42

@Exerqtor I don't think the stuff in daemon.g is relevant.

Are you able to take a Wireshark trace of your browser talking to the Duet? I have a theory that the "0.6<CR>" may be from the Accept-Language header that Chrome is sending

Exerqtor

@dc42 said in Reboots/crashes - RRF 3.5.0-rc1:

@Exerqtor I don't think the stuff in daemon.g is relevant.

Are you able to take a Wireshark trace of your browser talking to the Duet? I have a theory that the "0.6<CR>" may be from the Accept-Language header that Chrome is sending

Okol, i'll remove the G4 before the loop in daemon.g, and keep the rest.

And I will try to look into the Wireshark trace. Have to read up on what it is first

But I do also think the issue is Chrome, the last 24 hours I have only had two instances of Orca Slicer with the "Device" tab open and it haven't crashed once. If i do the same thing with two chrome tabs open it would have.

Exerqtor

@dc42 said in Reboots/crashes - RRF 3.5.0-rc1:

@Exerqtor ~~I don't think the stuff in daemon.g is relevant.~~

Are you able to take a Wireshark trace of your browser talking to the Duet? I have a theory that the "0.6<CR>" may be from the Accept-Language header that Chrome is sending

I THINK, I've managed to do that trace now. But i can't see "0.6<CR>" in any of the data I managed to grab, or should i keep a trace going until it crashes and track it down?

Here is a HTTP trace from Chrome:

Frame 456: 475 bytes on wire (3800 bits), 475 bytes captured (3800 bits) on interface \Device\NPF_{DF4300F0-1489-452B-B73B-3870E63C20C9}, id 0
Ethernet II, Src: LiteonTechno_0e:23:17 (c8:ff:28:0e:23:17), Dst: Espressif_ce:91:93 (c4:5b:be:ce:91:93)
Internet Protocol Version 4, Src: 192.168.10.xx, Dst: 192.168.10.x
Transmission Control Protocol, Src Port: 63171, Dst Port: 80, Seq: 1, Ack: 1, Len: 421
Hypertext Transfer Protocol
    GET /rr_model?flags=d99fno HTTP/1.1\r\n
    Host: 192.168.10.x\r\n
    Connection: keep-alive\r\n
    X-Session-Key: 1319375919\r\n
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36\r\n
    Accept: */*\r\n
    Referer: http://192.168.10.x/\r\n
    Accept-Encoding: gzip, deflate\r\n
    Accept-Language: nb-NO,nb;q=0.9,no;q=0.8,nn;q=0.7,en-US;q=0.6,en;q=0.5,sv;q=0.4,da;q=0.3,de;q=0.2,pt;q=0.1\r\n
    \r\n
    [Full request URI: http://192.168.10.x/rr_model?flags=d99fno]
    [HTTP request 1/1]
    [Response in frame: 470]

And one from Orca Slicer:

Frame 457: 479 bytes on wire (3832 bits), 479 bytes captured (3832 bits) on interface \Device\NPF_{DF4300F0-1489-452B-B73B-3870E63C20C9}, id 0
Ethernet II, Src: LiteonTechno_0e:23:17 (c8:ff:28:0e:23:17), Dst: Espressif_ce:91:93 (c4:5b:be:ce:91:93)
Internet Protocol Version 4, Src: 192.168.10.xx, Dst: 192.168.10.x
Transmission Control Protocol, Src Port: 63170, Dst Port: 80, Seq: 1, Ack: 1, Len: 425
Hypertext Transfer Protocol
    GET /rr_model?flags=d99fno HTTP/1.1\r\n
    Host: 192.168.10.x\r\n
    Connection: keep-alive\r\n
    X-Session-Key: 4102879531\r\n
    User-Agent: BBL-Slicer/v01.07.07.89 (dark) Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36 Edg/107.0.1418.52\r\n
    Accept: */*\r\n
    Referer: http://192.168.10.x/\r\n
    Accept-Encoding: gzip, deflate\r\n
    Accept-Language: nb,no;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6\r\n
    \r\n
    [Full request URI: http://192.168.10.x/rr_model?flags=d99fno]
    [HTTP request 1/1]
    [Response in frame: 466]

NeoDue

@Exerqtor sorry for chiming in once more...: I use Vivaldi here which is also Chromium-based, and I noticed that it works fine on my Desktop PC, but opened DWC tabs frequently crash on my notebook (either reloading endlessly or showing that "dead bird" symbol which is Vivaldi's replacement of the "Aw, snap" crash message of a Chromium tab) if the computer goes to some sleep or hibernation state (which the desktop PC does not do) and is resurrected later by moving the mouse or pressing a keyboard key.

With your finding here, I now see that as far as I can remember all the sudden crashes of my Duet which I blamed to "well, 3.5 is still in beta..." happened when the notebook was in use... don't know if that really means something though.

Exerqtor

@NeoDue Interesting! Well if it turns out that it's something chrome/chromium sends that's causing the crashes i guess it might explain it 😅

@dc42 I let one chrome and one Orca Slicer tab open over night with the wireshark trace going (so we maybe could see which of them sends the "CR") .

And when I woke up today I saw that the machine had crashed at least once, so I checked the debug log and it turns out it crashed 4 times from 20:30 until I got up at 5:45.

I've stoped and saved the trace data, but haven't had time to through it yet.

Here is a fresh M122 at least:

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.5.0-rc.1++wdb (2023-12-11 09:30:48) running on Duet 3 Mini5plus WiFi (standalone mode)
Board ID: XNHXF-HR6KL-K65J0-409N2-K9W1Z-RV2MZ
Used output buffers: 1 of 40 (40 max)
=== RTOS ===
Static ram: 102844
Dynamic ram: 122040 of which 0 recycled
Never used RAM 13676, free system stack 182 words
Tasks: NETWORK(1,ready,22.7%,239) HEAT(3,nWait,0.0%,331) Move(4,nWait,0.0%,358) CanReceiv(6,nWait,0.0%,774) CanSender(5,nWait,0.0%,336) CanClock(7,delaying,0.0%,350) TMC(4,nWait,0.7%,108) MAIN(1,running,70.5%,670) IDLE(0,ready,5.1%,29) AIN(4,delaying,0.8%,264), total 100.0%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 01:34:18 ago, cause: software
Last software reset at 2023-12-12 04:54, reason: AssertionFailed, Gcodes spinning, available RAM 13676, slot 0
Software reset code 0x4123 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00487000 BFAR 0xe000ed38 SP 0x20011fbc Task NETW Freestk 495 ok
Stack: 00000919 000af3d0 0002de6f 2002bed4 00000001 000001ae 2002c100 20031c70 2002c118 2001e888 a5a5a5a5 a5a5a5a5 0a0d312e 00000000 00000000 00000000 20031c7c 00000800 20035970 2002c100 20018678 2002bf9d 20018678 2001e888 0003010f 00000000 00000000
Error status: 0x04
Aux0 errors 0,0,0
MCU revision 3, ADC conversions started 5659109, completed 5659109, timed out 0, errs 0
MCU temperature: min 34.4, current 34.7, max 37.6
Supply voltage: min 22.2, current 24.1, max 26.8, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/23, heap memory allocated/used/recyclable 2048/1364/1052, gc cycles 10814
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 18, read errors 0, write errors 1, ifcnt 20, reads 35673, writes 13, timeouts 0, DMA errors 0, CC errors 0
Driver 1: standstill, SG min 2, read errors 0, write errors 1, ifcnt 18, reads 35673, writes 13, timeouts 0, DMA errors 0, CC errors 0
Driver 2: standstill, SG min 2, read errors 0, write errors 1, ifcnt 157, reads 35672, writes 13, timeouts 1, DMA errors 0, CC errors 0, failedOp 0x72
Driver 3: standstill, SG min 0, read errors 0, write errors 1, ifcnt 159, reads 35672, writes 13, timeouts 0, DMA errors 0, CC errors 0
Driver 4: standstill, SG min 2, read errors 0, write errors 1, ifcnt 154, reads 35673, writes 13, timeouts 0, DMA errors 0, CC errors 0
Driver 5: not present
Driver 6: not present
Date/time: 2023-12-12 06:29:12
Cache data hit count 4294967295
Slowest loop: 13.56ms; fastest: 0.13ms
=== Storage ===
Free file entries: 18
SD card 0 detected, interface speed: 22.5MBytes/sec
SD card longest read time 7.7ms, write time 4.0ms, max retries 0
=== Move ===
DMs created 83, segments created 0, maxWait 0ms, bed compensation in use: none, height map offset 0.000, max steps late 0, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0
=== DDARing 0 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== DDARing 1 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Movement locks held by null, null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is doing "G4 P10" in state(s) 0 0, running macro
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x0000803
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== Filament sensors ===
in 0 notIn 0
Extruder 0 sensor: no filament
=== CAN ===
Messages queued 50942, received 116052, lost 0, errs 1, boc 0
Longest wait 2ms for reply type 6031, peak Tx sync delay 270, free buffers 26 (min 25), ts 28296/28295/0
Tx timeouts 0,0,0,0,0,0
=== Network ===
Slowest loop: 6.33ms; fastest: 0.00ms
Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 3 of 8
=== WiFi ===
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notrdy 0, noresp 0
Firmware version 2.1beta4
MAC address c4:5b:be:ce:91:93
Module reset reason: Power up, Vcc 3.38, flash size 2097152, free heap 36268
WiFi IP address 192.168.10.x
Signal strength -46dBm, channel 6, mode 802.11n, reconnections 0
Clock register 00002001
Socket states: 0 0 0 0 0 0 0 0

dc42

@Exerqtor when I say <CR> I mean the control character carriage return. Wireshark displays it as \r so OrcaSlicer does indeed send that sequence at the end of the Accept-Language header.

Do you get any crashes if you connect Chrome to the Duet but not OrcaSlicer?

Exerqtor

@dc42 said in Reboots/crashes - RRF 3.5.0-rc1:

@Exerqtor when I say <CR> I mean the control character carriage return. Wireshark displays it as \r so OrcaSlicer does indeed send that sequence at the end of the Accept-Language header.

Oh there you go (this is out of my depth so sorry for the missunderstanding 😅).

Do you get any crashes if you connect Chrome to the Duet but not OrcaSlicer?

I'll give it a try later today, remove the IP adress from Orca Slicer entirely to rule it out.

Just out of curiosity, if this turns out being the reason for the crashing. Is it a Duet 3 Mini WiFi specific issue, or does it apply to Duet 2 WiFi / Duet 3 6HC WiFi as well?

NeoDue

@Exerqtor I have a 3 6HC here. Thus, if my assumption from yesterday is correct this applies to that board as well. But I guess it might be heavily dependent on how Chromium works on the corresponding computer, including anything that might be affecting this, such as e.g. how the computer handles standby states.

I will only be able to test my assumption in about a week since I am not at home, but I will follow this thread and try to recreate that issue both on my Duet 3 6HC as well as on my old Duet 2 then unless you already found a solution by then - you two are working really fast at the moment

Exerqtor

@dc42 said in Reboots/crashes - RRF 3.5.0-rc1:

@Exerqtor ~~when I say <CR> I mean the control character carriage return. Wireshark displays it as \r so OrcaSlicer does indeed send that sequence at the end of the Accept-Language header.~~

Do you get any crashes if you connect Chrome to the Duet but not OrcaSlicer?

The IP address is now removed from Orca Slicer, and I've got two DWC instances opened in chrome.

So lets play the waiting game and see what happens.

Exerqtor

@dc42 said in Reboots/crashes - RRF 3.5.0-rc1:

@Exerqtor ~~when I say <CR> I mean the control character carriage return. Wireshark displays it as \r so OrcaSlicer does indeed send that sequence at the end of the Accept-Language header.~~

Do you get any crashes if you connect Chrome to the Duet but not OrcaSlicer?

It's not Orca Slicer or "just" Orca Slicer thats causing the crashes, it happened again with it closed/not connected:

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.5.0-rc.1++wdb (2023-12-11 09:30:48) running on Duet 3 Mini5plus WiFi (standalone mode)
Board ID: XNHXF-HR6KL-K65J0-409N2-K9W1Z-RV2MZ
Used output buffers: 2 of 40 (39 max)
=== RTOS ===
Static ram: 102844
Dynamic ram: 123224 of which 208 recycled
Never used RAM 12284, free system stack 180 words
Tasks: NETWORK(2,nWait,193.2%,215) HEAT(3,nWait,0.2%,327) Move(4,nWait,0.0%,352) CanReceiv(6,nWait,0.4%,774) CanSender(5,nWait,0.0%,336) CanClock(7,delaying,0.1%,350) TMC(4,nWait,6.4%,108) MAIN(1,running,250.4%,670) IDLE(0,ready,42.9%,29) AIN(4,delaying,7.6%,264), total 501.1%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 03:34:40 ago, cause: software
Last software reset at 2023-12-13 02:36, reason: AssertionFailed, Gcodes spinning, available RAM 11124, slot 1
Software reset code 0x4123 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x20011fbc Task NETW Freestk 495 ok
Stack: 00000919 000af3d0 0002de6f 2002bed4 2002be01 000001af 2002c100 20031458 2002c118 2001e888 0d0a0d31 a5a5a5a5 0d312e30 00000000 00000000 00000000 20031464 00000800 20035970 2002c100 20018678 2002bf9d 20018678 2001e888 0003010f 00000000 00000000
Error status: 0x00
Aux0 errors 0,0,0
MCU revision 3, ADC conversions started 12881155, completed 12881155, timed out 0, errs 0
MCU temperature: min 33.6, current 33.8, max 37.3
Supply voltage: min 21.9, current 24.0, max 27.2, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/27, heap memory allocated/used/recyclable 2048/708/356, gc cycles 26104
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 2, read errors 0, write errors 1, ifcnt 50, reads 22552, writes 13, timeouts 0, DMA errors 0, CC errors 0
Driver 1: standstill, SG min 16, read errors 0, write errors 1, ifcnt 48, reads 22552, writes 13, timeouts 0, DMA errors 0, CC errors 0
Driver 2: standstill, SG min 2, read errors 0, write errors 1, ifcnt 176, reads 22552, writes 13, timeouts 0, DMA errors 0, CC errors 0
Driver 3: standstill, SG min 0, read errors 0, write errors 1, ifcnt 178, reads 22551, writes 13, timeouts 0, DMA errors 0, CC errors 0
Driver 4: standstill, SG min 2, read errors 0, write errors 1, ifcnt 172, reads 22552, writes 13, timeouts 0, DMA errors 0, CC errors 0
Driver 5: not present
Driver 6: not present
Date/time: 2023-12-13 06:11:01
Cache data hit count 4294967295
Slowest loop: 12.69ms; fastest: 0.13ms
=== Storage ===
Free file entries: 18
SD card 0 detected, interface speed: 22.5MBytes/sec
SD card longest read time 4.9ms, write time 4.5ms, max retries 0
=== Move ===
DMs created 83, segments created 0, maxWait 0ms, bed compensation in use: none, height map offset 0.000, max steps late 0, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0
=== DDARing 0 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== DDARing 1 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Movement locks held by null, null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is doing "G4 P10" in state(s) 0 0, running macro
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x0000803
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== Filament sensors ===
in 0 notIn 0
Extruder 0 sensor: no filament
=== CAN ===
Messages queued 115938, received 264103, lost 0, errs 1, boc 0
Longest wait 2ms for reply type 6053, peak Tx sync delay 276, free buffers 26 (min 25), ts 64405/64404/0
Tx timeouts 0,0,0,0,0,0
=== Network ===
Slowest loop: 6.29ms; fastest: 0.00ms
Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 3 of 8
=== WiFi ===
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notrdy 0, noresp 0
Firmware version 2.1beta4
MAC address c4:5b:be:ce:91:93
Module reset reason: Power up, Vcc 3.38, flash size 2097152, free heap 39692
WiFi IP address 192.168.10.x
Signal strength -47dBm, channel 6, mode 802.11n, reconnections 0
Clock register 00002001
Socket states: 0 0 0 0 0 0 0 0

Doing the same with Orca Slicer now, no chrome connections and two Orca Slicer.

NeoDue

@Exerqtor may I ask about the computer you ran Chrome on in that test? Which OS? Notebook or Desktop? Screensaver, sleep or hibernation / energy saving mode enabled or disabled? Unless I overlook something, one of these things probably made the difference here.

timschneider

@dc42
Hi david, I'm reading this thread as bystander. I asked myself if it is possible that the error occurs when the connection is interrupted but the socket is not closed and RRF is running in an timeout?

Maybe I'm totally off, but as far as I know the RRF is opening an DMA channel to the WiFi/Network stack and the socket handling is done over there.

What will happen if a client is sending a partially delayed http header like

GET /rr_model?flags=d99fno HTTP/1.1\r\n
    Host: 192.168.10.x\r\n
    Connection: keep-alive\r\n
    X-Session-Key: 4102879531\r\n
    User-Agent: BBL-Slicer/v01.07.07.89 (dark) Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36 Edg/107.0.1418.52\r\n
    Accept: */*\r\n
    Referer: http://192.168.10.x/\r\n
<VERY LONG DELAY>
    Accept-Encoding: gzip, deflate\r\n
    Accept-Language: nb,no;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6\r\n
\r\n

The socket will stay open and later on run into an timeout, but the DMA channel is still open and partially written. The buffer gets freed (on stack), but the client or WiFi/Network stack keeps writing to that address via the opened DMA after the <very long delay>.

Maybe the idea is totally off, then just ignore it.

I was just thinking about another behaviour I observed when using DWC over an VPN tunnel, sometimes the RRF just stopped after I checked the status of the print and disconnected the VPN.

Edit:

No timeout in the Network stack
Timeout in the RRF
Open DMA channel

Exerqtor

@NeoDue said in Reboots/crashes - RRF 3.5.0-rc1:

@Exerqtor may I ask about the computer you ran Chrome on in that test? Which OS? Notebook or Desktop? Screensaver, sleep or hibernation / energy saving mode enabled or disabled? Unless I overlook something, one of these things probably made the difference here.

It's on a desktop running windows 10 pro x64, hibernation/powersaving has been turned off since i'm running these tests.

So it's eiter chrome thats making the issues OR both. That we will see if it crashes with only Orca Slicer running (as it is now).

@dc42 So i just came home, and it's been no crashes since 05:50 this morning at least, this is with only Orca Slicer open. Gonna let it stay idle like this until tomorrow morning and see what happens. But i got a sneaking feeling Orca Slicer (by itself at least) ain't the cause of the crashes.

dc42

@Exerqtor have you ever seen this issue when running DuetWiFiServer 1.27? If you haven't, or you are not sure, please try it.

Exerqtor

@dc42 Not sure, but i'm pretty sure it came after moving from 1.27. I'll revert to it now, shouldn't be an issue to run 1.27 with 3.5x on everything else?

T3P3Tony

@Exerqtor you can use 1.27 with 3.5x

Exerqtor

Ok, with that it's now on WiFiServer 1.27, and i'm back to having two tabs with chrome and one Orca Slicer instance (since that seem to be what made it crash most often). #waitinggame

Exerqtor

@T3P3Tony & @dc42 Just had a crash on WiFiServer 1. 27 as well:

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.5.0-rc.1++wdb (2023-12-11 09:30:48) running on Duet 3 Mini5plus WiFi (standalone mode)
Board ID: XNHXF-HR6KL-K65J0-409N2-K9W1Z-RV2MZ
Used output buffers: 1 of 40 (40 max)
=== RTOS ===
Static ram: 102844
Dynamic ram: 123224 of which 0 recycled
Never used RAM 12492, free system stack 182 words
Tasks: NETWORK(1,ready,23.6%,219) HEAT(3,nWait,0.0%,352) Move(4,nWait,0.0%,358) CanReceiv(6,nWait,0.0%,797) CanSender(5,nWait,0.0%,336) CanClock(7,delaying,0.0%,350) TMC(4,nWait,0.7%,108) MAIN(1,running,69.2%,670) IDLE(0,ready,5.6%,29) AIN(4,delaying,0.8%,264), total 100.0%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:28:00 ago, cause: software
Last software reset at 2023-12-13 19:25, reason: AssertionFailed, Gcodes spinning, available RAM 10924, slot 2
Software reset code 0x4123 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x20011fbc Task NETW Freestk 495 ok
Stack: 00000919 000af3d0 0002de6f 2002bed4 2002be01 000001af 2002c100 20030c40 2002c118 2001e888 a5a5a5a5 0d0a0d36 0d312e30 00000000 00000000 00000000 20030c4c 00000800 20035970 2002c100 20018678 2002bf9d 20018678 2001e888 0003010f 00000000 00000000
Error status: 0x04
Aux0 errors 0,0,0
MCU revision 3, ADC conversions started 1680921, completed 1680920, timed out 0, errs 0
MCU temperature: min 35.5, current 36.2, max 39.1
Supply voltage: min 11.5, current 24.1, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/27, heap memory allocated/used/recyclable 2048/404/52, gc cycles 3230
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0, read errors 0, write errors 1, ifcnt 97, reads 22904, writes 13, timeouts 0, DMA errors 0, CC errors 0
Driver 1: standstill, SG min 2, read errors 0, write errors 1, ifcnt 95, reads 22904, writes 13, timeouts 0, DMA errors 0, CC errors 0
Driver 2: standstill, SG min 0, read errors 0, write errors 1, ifcnt 200, reads 22904, writes 13, timeouts 0, DMA errors 0, CC errors 0
Driver 3: standstill, SG min 2, read errors 0, write errors 1, ifcnt 203, reads 22903, writes 13, timeouts 0, DMA errors 0, CC errors 0
Driver 4: standstill, SG min 0, read errors 0, write errors 1, ifcnt 197, reads 22904, writes 13, timeouts 0, DMA errors 0, CC errors 0
Driver 5: not present
Driver 6: not present
Date/time: 2023-12-13 19:53:05
Cache data hit count 2936262464
Slowest loop: 10.26ms; fastest: 0.13ms
=== Storage ===
Free file entries: 18
SD card 0 detected, interface speed: 22.5MBytes/sec
SD card longest read time 7.6ms, write time 4.6ms, max retries 0
=== Move ===
DMs created 83, segments created 0, maxWait 0ms, bed compensation in use: none, height map offset 0.000, max steps late 0, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0
=== DDARing 0 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== DDARing 1 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Movement locks held by null, null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is doing "G4 P10" in state(s) 0 0, running macro
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x0000803
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== Filament sensors ===
in 0 notIn 0
Extruder 0 sensor: no filament
=== CAN ===
Messages queued 15138, received 34498, lost 0, errs 0, boc 0
Longest wait 3ms for reply type 6053, peak Tx sync delay 265, free buffers 26 (min 25), ts 8405/8404/0
Tx timeouts 0,0,0,0,0,0
=== Network ===
Slowest loop: 13.65ms; fastest: 0.00ms
Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 4 of 8
=== WiFi ===
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notrdy 0, noresp 0
Firmware version 1.27
MAC address c4:5b:be:ce:91:93
Module reset reason: Power up, Vcc 3.38, flash size 2097152, free heap 25464
WiFi IP address 192.168.10.x
Signal strength -55dBm, channel 0, mode 802.11n, reconnections 0
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

NeoDue

@Exerqtor thanks! Let me add my observations in detail, maybe they do help someone here - I honestly don't know what happens in detail when the browser is open on a "sleeping" computer:

Desktop PC running MX Linux or Linux Mint with Vivaldi open and no kind of powersaving except turning the monitor off active: dwc tabs do not crash, Duet does not crash.
Notebook (in my case an old MacBook Air) running Windows 10 x64 with the same Vivaldi version active, hibernation turned off, but higher sleep modes active: tabs with DWC frequently do not recover if the computer is woken from sleep. Duet crashes occur (on a Duet 3 6HC running RRF 3.5.0 beta 4 or 3.5.0rc1), but not every time the browser tab crashes. Several browser tab crashes seem to increase the risk for the Duet itself crashing however, as far as I remember.

I still have my old printer here which runs on a Duet 2 Wifi with RRF 3.3 or an early 3.4 version. If it helps anyone, I could try to recreate those crashes in the new board and then check if the old one might be affected as well.