> 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
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.

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to