> 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
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
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
> 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.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"