> We don't understand the bug yet. It might not even be in sc. Do you only > see problems for shutdown? The shutdown environment is special for > locking. Yes, only for reboot/shutdown. The system does not do anythings wrong even under high load. On reboot or hang those lines are never printed: kernel: Waiting (max 60 seconds) for system process `vnlru' to stop...done kernel: Waiting (max 60 seconds) for system process `bufdaemon' to stop...done kernel: Waiting (max 60 seconds) for system process `syncer' to stop... kernel: Syncing disks, vnodes remaining...5 3 0 1 0 0 done kernel: All buffers synced. (it is from 10-stable sample, old -current samples are lost) Moreover, GELI swap deactivation lines are never printed too (I already mention that I change swap to normal, but nothing is changed). > A hang in sc means that deadlock occurred and sc's new deadlock detection > didn't work. Hangs are rare. Most common are premature reboots. > Check that ddb works before shutdown, or just put a lot of printfs in I can't check it ddb because I can't enter ddb in sc mode, as I already write, nothing happens. Only vt mode allows Ctrl-Alt-ESC, but the bug does not exist in vt mode, so it is pointless. >>> You might have entered ddb in a context which used to race or deadlock. >> >> No. I try about 20 times on machine which does nothing and can't enter >> KDB in sc only mode, but got one dead hang instead, when start to repeat >> it too fast. > > Even earlier than shutdown, and when booting? I mean in normal operation mode after booting, earlier than shutdown. Shutdown with premature reboot is too fast to press anything at the right time. I don't try to enter ddb when booting yet, but tell you results later. > I call this line-drawing characters for cp437, and use them occasionally, > but I don't know the termcap method for using them very well. See ac, as, ae.Received on Thu Mar 30 2017 - 07:23:53 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:11 UTC