linux-kernel - Re: Strange write errors on FAT32 partition (maybe an FAT32 bug?!)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4553AA8A.5080705@scientia.net>
Date:	Thu, 09 Nov 2006 23:24:10 +0100
From:	Christoph Anton Mitterer <calestyo@...entia.net>
To:	Roger Heflin <rheflin@...pa.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: Strange write errors on FAT32 partition (maybe an FAT32 bug?!)

Roger Heflin wrote:
> Christoph Anton Mitterer wrote:
>   
>> Roger Heflin wrote:
>>     
>>> The mc part does pci parity, it is separate from the
>>> chipset driver,
>>>       
>> What? I thought the MC part does ECC and the pci part the parity stuff?
>>
>>     
>
> mc does pci parity all by itself, it is also the main module
> holding the ecc stuff together, but you get no ecc without the
> chipset/cpu specific module.
>
>   
>>> I have even used the _mc part on a
>>> Itanium with no chipset driver at all and had it report
>>> parity errors properly, so I expect just the mc driver
>>> to work.
>>>
>>> You would need the k8 module for the cpu, but that is
>>> only if you want ECC checking also.
>>>   
>>>       
>> Where do I get this only when patching from CVS?
>>     
>
> I don't know the status is of the k8 modules, some
> distro kernels include it, I don't know if vanilla has
> it yet.
>
> mcelog should also report ecc errors, but you would need
> to be running the mcelog userspace program every so often
> to realize that errors where happening.
>
>   
>>> If you got the _mc loaded do a "sysctl -a | grep mc" and
>>> see what things are set how, and reset if necessary
>>> check_pci_parity to 1.
>>>       
>> Well ok,.. module is loaded now:
>> I've set check_pci_parity to 1 everything else is 0 in sysfs...
>>
>>
>> # sysctl -a | grep mc
>> error: "Operation not permitted" reading key "net.ipv6.route.flush"
>> net.ipv6.neigh.eth1.mcast_solicit = 3
>> net.ipv6.neigh.eth0.mcast_solicit = 3
>> net.ipv6.neigh.lo.mcast_solicit = 3
>> net.ipv6.neigh.default.mcast_solicit = 3
>> net.ipv4.conf.ppp0.mc_forwarding = 0
>> net.ipv4.conf.eth1.mc_forwarding = 0
>> net.ipv4.conf.eth0.mc_forwarding = 0
>> net.ipv4.conf.lo.mc_forwarding = 0
>> net.ipv4.conf.default.mc_forwarding = 0
>> net.ipv4.conf.all.mc_forwarding = 0
>> net.ipv4.neigh.ppp0.mcast_solicit = 3
>> net.ipv4.neigh.eth1.mcast_solicit = 3
>> net.ipv4.neigh.eth0.mcast_solicit = 3
>> net.ipv4.neigh.lo.mcast_solicit = 3
>> net.ipv4.neigh.default.mcast_solicit = 3
>> error: "Operation not permitted" reading key "net.ipv4.route.flush"
>> error: "Invalid argument" reading key "fs.binfmt_misc.register"
>>
>>
>> But this has nothing to do with edac, has it?
>>
>> And I've already had diff errors again,..
>> so if there had been some parity issue it should have been logged, right?
>>     
>
> The names and locations may have change, I am more
> familiar with the older versions that had the sysctl stuff
> in them, the new parts may not have the sysctl stuff,
> but if you make the adjustment with the /sys filesystem,
> that should work just fine.
>   
Ahh now I see:
Parity Count:

        'pci_parity_count'

        This attribute file will display the number of parity errors that
        have been detected.


but this is zero ...
So would that mean that I don't have any parity errors?

btw: I'm still always getting diff errors at different files...

Chris.


View attachment "calestyo.vcf" of type "text/x-vcard" (156 bytes)