On Sat, Mar 24, 2012 at 03:07:08PM +1100, Anthony Shipman wrote:
On Sat, 24 Mar 2012 01:56:05 pm Craig Sanders wrote:
more details required... I've got lots if you want:
Asus P8H67 motherboard.
Linux 2.6.32-220.2.1.el6.x86_64 #1 SMP Fri Dec 23 02:21:33 CST 2011 x86_64 x86_64 x86_64 GNU/Linux
01:00.0 VGA compatible controller: nVidia Corporation GF119 [GeForce GT 520] (rev a1) (prog-if 00 [VGA controller])
OK, so fairly new then. i somehow had the impression it was older gear. btw, what version of the nvidia driver are you running? support for the GT 520 was added in version 285.x.x - it may have worked before then, but maybe not.
please show output of lspci, and 'lspci -v' for you nvidia card. what brand/model card is it? does your BIOS have IOMMU support enabled? (i've found that that can cause problems for the nvidia driver)
The EFI manual talks about an Intel VT-d thingy which is disabled by default. I expect it is still disabled.
VT-d is completely unrelated. VT-d is virtualisation support. if you ever want to run kvm or virtualbox or similar you'll need it enabled. the IOMMU is the memory manager unit. some BIOSes allow enabling it for 64-bit linux with a 64MB buffer for transfers to/from 32-bit devices. i've found it's best to turn it off, and make sure Memory Hole remapping is enabled in the bios.
also details on your kernel version and hardware would be useful, including details your motherboard, disk controller, on the drives used by your XFS fs. also is XFS on raw disk partition(s) or LVM?
The XFS fs is on a raw disk partition (/dev/sdb5). This is a GPT partition on a WD SATA drive.
what kind of controller? ahci or ide mode? or "RAID" mode? in my experience, it's best to set the BIOS to ahci mode for all drives. and to avoid "RAID" mode like the pestilential POS that it is (linux software raid is *much* better).. what happens if you do something like 'dd if=/dev/sdb5 of=/dev/null' - does it run to completion or does it trigger a fault? if the latter, then it's the controller or the disk itself, not the fs. if the former, well, cause is still unknown. similarly, try a write test with dd direct to a disk partition if you have one available to be wiped/overwritten - maybe turn off your swap partition temporarily and use that. e.g. swapoff /dev/XXXX dd if=/dev/random of=/dev/XXXX where XXXX is your swap partition. remember to mkswap it before you use it as swap again. probably best to make note of the UUID first and re-create it with the same UUID like so: mkswap -U [uuid] /dev/XXXX you can get the current uuid with blkid. e.g. # blkid /dev/sda2 /dev/sda2: UUID="1ac8f2ba-39c7-43b4-8c26-a039d3eda76e" TYPE="swap" craig ps: i've been using XFS on numerous systems for years. can't remember when, exactly, late 90s probably. anyway, I've never seen anything like the problems you describe, so my current favorite guess as to the cause is that it's caused by faulty hardware or faulty bios settings. the only serious outstanding problem with XFS that i know of is that, under some rare and not very-well defined circumstances, NFS activity on an NFS-exported XFS volume can cause the nfs server to lock up. there's some kind of conflict with the XFS code and the NFS code. -- craig sanders <cas@taz.net.au> BOFH excuse #14: sounds like a Windows problem, try calling Microsoft support