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

From: Roger Heflin
Date: Thu Nov 09 2006 - 17:15:09 EST


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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/