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

[Roger Heflin <rheflin@atipa.com>]

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.

                        Roger