Tried - the screen stays as it was, no movement whatsoever. No network activity, the keyboard is also dead - does not respond to CtrlAltEsc, even the lights are off and CapsLock/NumLock does not trigger anything.
Weird. I guess next thing is to try ddb through the serial console. Chavdar On 5 November 2013 00:33, Chavdar Ivanov <[email protected]> wrote: > I've got similar behaviour on my 6.99.25 amd64 box - complete freeze > during building of Firefox 25 - easily repeatable. The system was > stable until 6.99.24, something happened later. Unmodified GENERIC > kernel, I couldn't break and get a dump, only hard reset brings it > back. I'll try the blind trigger suggestion tomorrow. > > On the other hand, my build box (XEN3_DOMU under XenServer) gets > updated at the same time as the above box and continues to work as > before. > > Chavdar > > On 2 November 2013 14:43, Mindaugas Rasiukevicius <[email protected]> wrote: >> Thomas Klausner <[email protected]> wrote: >>> <...> >>> >>> Please note that the machine doesn't panic -- otherwise I'd have seen >>> reboots instead. >>> >>> I'm regularly updating, so I think this problem is rather new (last >>> month or so). I was usually running with clang; using libc++ is new, >>> no idea if this is related or not (I guess not). >>> >>> Does anyone have any ideas about this? >> >> Just a few.. >> >> Can you get into DDB during a lockup (blindly triggering it and typing >> call ddb_vgapost)? If you can, inspecting the LWPs (with ps/l) to see >> what are they doing would be useful. >> >> During the glitches, you can try to inspect the LWPs using crash(8). >> Also, it would be useful to monitor vmstat -e counters, perhaps some >> interrupt rates increase to unusual levels. When glitches start to >> happen, you might try to run constant snapshots of lockstat sleep 15, >> perhaps some lock contention would indicate what is going on. >> >>> >>> Thanks, >>> Thomas >> >> -- >> Mindaugas > > > > -- > ---- -- ----
