Hi,

Vincent Legoll <vincent.leg...@gmail.com> writes:

> Hello Vagrant & other guixers,
>
> On Sat, Dec 14, 2024 at 7:56 AM Vagrant Cascadian <vagr...@debian.org>
> wrote:
>
>> On 2024-12-12, Vincent Legoll wrote:
>> > that file looks corrupted
>> >
>> > For example the first error:
>> >
>> > 2057 |         .hw.init = &(struct clk_init_da|a) {
>> >
>> > that should be "clk_init_data", see:
>> >
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/meson/gxbb.c#n2051
>> >
>> > 2168 |                 .parent_hws = (const str}ct clk_hw *[]) {
>> >
>> > here it's "struct"
>>
>> You are right! Somehow the source tarballs had gotten corrupted.
>>
>
> 166 246 A6 10100110 ¦ &#166; Pipe
> 116 164 74 01110100 t &#116; Lowercase t
>
> 125 175 7D 01111101 } &#125; Closing brace
> 117 165 75 01110101 u &#117; Lowercase u
>
> while the "u" -> "}" may be a single bit flip error,
> the "t" -> "|" is more complicated than that...
>
>
>> The worried part of me wonders if there is bad hardware, ram, disk or
>> cpu...
>>
>
> I hope for you that it's not, and for the rest of us that it is (and not a
> hard to
> track down SW bug)...
>
>
>> But seems to be working for now!
>>
>
> I'd be reluctant to trust that HW, from now on, I'd keep a close eye on
> it...
> Does it have ECC RAM ?

Also, a checksummed file system like Btrfs can help detect corruption on
disk (it won't help when the data was written corrupted already, which
is the part where ECC RAM would help).

-- 
Thanks,
Maxim



Reply via email to