Re: [PATCH 0/3] AHCI updates: Marvell AHCI PATA works; pata_marvell fate?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/26/2009 11:13 PM, Raman Gupta wrote:
Jeff Garzik<jeff<at>  garzik.org>  writes:
This is an update of the recent libahci patchset, currently available
on the 'libahci' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
[...]
The mv-ahci code is obviously still a bit raw with "#if 0" in places,
but it is nonetheless ready for testing.

I tested the libata-dev kernel as of commit c3939cc09. I had to comment out a
bunch of code (for example, code related to the sntf board in ahci.c and some
other stuff) and add a cap2 variable to the ahci_host_priv struct in ahci.h in
order to successfully compile the branch.

I also had to comment out the pata_enable check in mv-ahci.c:mv_ahci_init_one in
order to get the mv_ahci module to initialize my hardware, even though I have
the pata_marvell module blacklisted.

My test hardware:

Intel D75XBX2 motherboard with 2 onboard SATA controllers
- ICH7 controller in AHCI mode
   - 3 disks (2 x ST3320620AS, 1 x ST3500418AS)
- Marvell 88SE6145 controller, using AHCI (ahci.marvell_enable=1)
   - 3 disks (3 x ST3500418AS)

I used "fio surface-scan" for my test (is that a good way to test this?) and I
found no regressions from the stock Fedora 12 kernel 2.6.31.6-166.fc12.x86_64.
However, I was hoping the latest libata-dev branch resolved this issue:

https://bugzilla.redhat.com/show_bug.cgi?id=549981

It did not. I continue to get the same error as described in my bugzilla report
with libata-dev.

I wouldn't expect any bug fixes to be in that branch, it's just a code reorganization.

From your last post on the Bugzilla report, it looks like all 3 drives basically stopped talking to the point they wouldn't respond to IDENTIFY commands. That seems really strange to me. You mentioned you were doing a surface scan at the time, which presumably would involve all disks being accessed simultaneously. I'd have a good look at the hardware on that system, specifically the power supply. We've seen a number of cases where running multiple HDs on a system can trigger such problems with SATA links because of voltage sags (even momentary). HDs draw much higher peak power under certain conditions than when idle so such problems may not be obvious unless you stress multiple drives at once.

I'm not sure if that's related to the SMART issue you were seeing or not..
--
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

[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux