Mikael Pettersson wrote:
nForce2. Hmm..
Peter Favrholdt wrote:
> 11: 27474 XT-PIC-XT libata, libata, ohci_hcd:usb3,
> NVidia nForce2
That "mystery" device makes me strongly suspect that you've
loaded the binary-only nvidia drivers. If that's true, then
the machine's problems may just as well be caused by that driver,
not sata_promise. (We've seen that happen before.)
I didn't load any special NVidia driver - vanilla kernel only. The
graphics card is Matrox G550. The nForce2 could be the nForce2 SMBus or
the nForce2 IDE. Here is the result of dmesg | grep -i nforce
[ 26.379422] NFORCE2: IDE controller at PCI slot 0000:00:09.0
[ 26.379481] NFORCE2: chipset revision 162
[ 26.379525] NFORCE2: not 100% native mode: will probe irqs later
[ 26.379575] NFORCE2: BIOS didn't set cable bits correctly. Enabling
workaround.
[ 26.379634] NFORCE2: 0000:00:09.0 (rev a2) UDMA133 controller
[ 31.861284] i2c_adapter i2c-0: nForce2 SMBus adapter at 0x5000
[ 31.861391] i2c_adapter i2c-1: nForce2 SMBus adapter at 0x5500
I can reproduce it on an Intel 440BX chipset machine with a PIII.
However, that chipset, while very good in its day, is rather old now.
I believe the problem here only shows if all four sata ports are
stressed simultaneously (I should test this thoroughly). The dependence
on Barracuda 7200.10 could be because these disks are faster than the
others tested, this needed in order for the PCI contention to arise?
(I'm still wild-guessing here).
Best regards,
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
