Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 4 Jan 2018 09:10:37 +0100
From:      Michael Tuexen <tuexen@freebsd.org>
To:        Warner Losh <imp@bsdimp.com>
Cc:        "O. Hartmann" <ohartmann@walstatt.org>, FreeBSD CURRENT <freebsd-current@freebsd.org>
Subject:   Re: r327359: cylinder checksum failed: cg0, cgp: 0x4515d2a3 != bp: 0xd9fba319 Dec 30 23:29:24 <0.2>
Message-ID:  <23651B78-E31C-4BDD-BCA3-408B8F907884@freebsd.org>
In-Reply-To: <CANCZdfoMdgCrAAXadc-G6v1r0wA-qv=Ms_XKYPd7cFqSc5%2B9GQ@mail.gmail.com>
References:  <20171231004137.4f9ad496@thor.intern.walstatt.dynvpn.de> <CANCZdfoMdgCrAAXadc-G6v1r0wA-qv=Ms_XKYPd7cFqSc5%2B9GQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> On 31. Dec 2017, at 02:45, Warner Losh <imp@bsdimp.com> wrote:
>=20
> On Sat, Dec 30, 2017 at 4:41 PM, O. Hartmann <ohartmann@walstatt.org> =
wrote:
>=20
>> On most recent CURRENT I face the error shwon below on /tmp =
filesystem
>> (UFS2) residing
>> on a Samsung 850 Pro SSD:
>>=20
>> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: =
0x4515d2a3 !=3D
>> bp: 0xd9fba319
>> handle_workitem_freefile: got error 5 while accessing filesystem
>> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: =
0x4515d2a3
>> !=3D bp: 0xd9fba319
>> handle_workitem_freefile: got error 5 while accessing filesystem
>> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: =
0x4515d2a3
>> !=3D bp: 0xd9fba319
>> handle_workitem_freefile: got error 5 while accessing filesystem
>> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: =
0x4515d2a3
>> !=3D bp: 0xd9fba319
>> handle_workitem_freefile: got error 5 while accessing filesystem
>> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: =
0x4515d2a3
>> !=3D bp: 0xd9fba319
>> handle_workitem_freefile: got error 5 while accessing filesystem
>>=20
>> I've already formatted the /tmp filesystem, but obviously without any
>> success.
>>=20
>> Since I face such strange errors also on NanoBSD images dd'ed to SD =
cards,
>> I guess there
>> is something fishy ...
>=20
>=20
> 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.

You can check using tunefs -p devname if soft update journaling is =
enabled or
not.

Best regards
Michael
>=20
> Warner
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to =
"freebsd-current-unsubscribe@freebsd.org"




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?23651B78-E31C-4BDD-BCA3-408B8F907884>