r327359: cylinder checksum failed: cg0, cgp: 0x4515d2a3 != bp: 0xd9fba319 Dec 30 23:29:24 <0.2>

[O. Hartmann]

Am Mon, 8 Jan 2018 09:12:16 -0700
Warner Losh <imp at bsdimp.com> schrieb:

> On Jan 8, 2018 8:34 AM, "Mark Johnston" <markj at freebsd.org> wrote:
> 
> On Thu, Jan 04, 2018 at 09:10:37AM +0100, Michael Tuexen wrote:
> > > On 31. Dec 2017, at 02:45, Warner Losh <imp at bsdimp.com> wrote:
> > >
> > > On Sat, Dec 30, 2017 at 4:41 PM, O. Hartmann <ohartmann at walstatt.org>  
> wrote:
> > >  
> > >> On most recent CURRENT I face the error shwon below on /tmp filesystem
> > >> (UFS2) residing
> > >> on a Samsung 850 Pro SSD:
> > >>
> > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp:  
> 0x4515d2a3 !=
> > >> bp: 0xd9fba319
> > >> handle_workitem_freefile: got error 5 while accessing filesystem
> > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3
> > >> != bp: 0xd9fba319
> > >> handle_workitem_freefile: got error 5 while accessing filesystem
> > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3
> > >> != bp: 0xd9fba319
> > >> handle_workitem_freefile: got error 5 while accessing filesystem
> > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3
> > >> != bp: 0xd9fba319
> > >> handle_workitem_freefile: got error 5 while accessing filesystem
> > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3
> > >> != bp: 0xd9fba319
> > >> handle_workitem_freefile: got error 5 while accessing filesystem
> > >>
> > >> I've already formatted the /tmp filesystem, but obviously without any
> > >> success.
> > >>
> > >> Since I face such strange errors also on NanoBSD images dd'ed to SD  
> cards,
> > >> I guess there
> > >> is something fishy ...  
> > >
> > >
> > > It indicates a problem. We've seen these 'corruptions' on data in  
> motion at
> > > work, but I hacked fsck to report checksum mismatches (it silently  
> corrects
> > > them today) and we've not seen any mismatch when we unmount and fsck the
> > > filesystem.  
> > Not sure this helps: But we have seen this also after system panics
> > when having soft update journaling enabled. Having soft update journaling
> > disabled, we do not observed this after several panics.
> > Just to be clear: The panics are not related to this issue,
> > but to other network development we do.  
> 
> I saw the same issue this morning on a mirrored root filesystem after my
> workstation came up following a power failure. fsck recovered using the
> journal, and I subsequently saw a number of these checksum failures.
> Upon shutdown, I saw the same handle_workitem_freefile errors as above.
> I then ran a full fsck from single-user mode, which didn't turn up any
> inconsistencies, and after that the checksum failure errors disappeared,
> presumably because fsck fixed them.
> 
> 
> Yes. Fsck automatically fixes issues like that. It does it silently. I have
> patched to make it noisy, and the dozen cases I saw the errors, fsck was
> silent with my whiny patches. I can put them up for review if people want...
> 
> Warner


within the past couple of weeks - or since the first occurence of these strange reports,
I have had mysterious crashes: when installing FreeBSD even the proper (recommended) way,
the box suddenly crashes out of the blue. The symptoms are always the same and the result
is also always the same: the box is unusable, the boot process is stuck at BTX halted
with a list of dumped CPU registers (I guess it is the CPU registers) and the filesystem
is corrupt. I have had this strange problem on several hosts with SSDs - I reported end
November/beginning of December 2017 of those crashes. On on machine I refomated the SSD
and did a playback from ab 'dump'-backup - since then those crashes went away. The box
now in question is the last of them not being traeted that way. it seems, there is
somewhere/somehow a minefield hidden and I have no clue what it could be :-(

I'm going to do the very same soon with the SSD of the remaining box - dump and restore.

I just wanted to note this for the record.

The crash happend with  FreeBSD 12.0-CURRENT #14 r328409: Thu Jan 25 20:40:27 CET amd64.

Kind regards,

Oliver
2018 

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 313 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20180125/c5ff88a2/attachment.sig>