Re: panic: lockmgr: locking against myself

• Previous message: Bernd Walter: "SCHED_ULE takes only one CPU?"
• In reply to: Daniel C. Sobral: "panic: lockmgr: locking against myself"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Tue, 20 May 2003 08:54:05 -0700
To: "Daniel C. Sobral" <dcs@tcoip.com.br>

"Daniel C. Sobral" wrote:
> This is an easily reproducable panic. Whenever my system panics for some
> reason, that panic will follow during the background fsck afterwards.
>
> I'm inclined to disable background fsck, only that would be just masking
> the problem, not solving it. I *thought* this had been solved. :-(

No. I suggested a counter to force a FG fsck; someone claimed it
was already implemented, I looked, it wasn't, and it would take a
superblock change (you would need a new "don't care about mismatch"
region; wish people had put in the space reservation API I had
suggested, when they were rewriting UFS to UFS2...).

> When this stuff happens, I always boot single user and run fsck by hand,
> so I can't see how it could be inconsistent state left by an early panic
> _during_ a background fsck.

If you crash with unwritten buffers because write caching is
enabled on an ATA drive, or you end up trashing a few sectors
or a track because of a genuine power loss, or because your
ACPI settings don't delay "shutdown -p" until after a drive
flush so that the write cache is guaranteed to be syned to
disk, soft updates will not guarantee drive consistency (it's
kind of hard to do if your power is off).

In that case, the FS can have data structures SPAM'med by the
poor design, and the only way to recover is a full fsck. The
basic assumptions with the BG fsck is that the only thing that
could be SPAM'med is the cylinder group bitmaps... and in the
above cases, that's not true. Any panic you get will *usually*
be the result of taking the snapshot for the BG fsck, or as a
result of mounting and using the disk as if it were safe to do,
when it's not.

If you can adjust your ACPI settings to ensure that the power
doesn't actually go off until the disks write cache is flushed,
and verify that there is a request being posted for the write
cache to be flushed prior to a power-down or sleep event, then
that should "resolve" your problem, unless you are getting a
genuine external power failure.

Really, the correct thing to do is set a counter in the FS
superblock at clean shutdown (e.g. a "tunefs" option would do
the trick), and decrement it each time you start a BG fsck.
When it gets to 0, you force a full fsck instead. Basically,
this would mean you panic at most 3 times before the FG fsck
takes over and cleans up the BG fsck-unrecoverable problem
for you.

Short of writing that code, your only chance is to keep the
data on the disk from being bogofied in the first place (per
avoiding the situations in the first paragraph, above).

-- Terry
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

• Previous message: Bernd Walter: "SCHED_ULE takes only one CPU?"
• In reply to: Daniel C. Sobral: "panic: lockmgr: locking against myself"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]