[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMHSBOXuX1U8uPyN136AQ_LRW85Ex8EUu1-_hdBqnSMtdmg+0Q@mail.gmail.com>
Date: Fri, 23 Mar 2012 16:31:24 +0800
From: Gwendal Grignou <gwendal@...gle.com>
To: "ANEZAKI, Akira" <fireblade1230@...oo.co.jp>
Cc: "IDE/ATA development list" <linux-ide@...r.kernel.org>,
Mark Lord <kernel@...savvy.com>,
Linux Kernel <linux-kernel@...r.kernel.org>,
Jeff Garzik <jgarzik@...ox.com>
Subject: Re: Fwd: libata-pmp patch for 3.2.x and later for eSATA Port
Multiplier Sil3726
On Fri, Mar 23, 2012 at 2:40 PM, ANEZAKI, Akira
<fireblade1230@...oo.co.jp> wrote:
> Hello Gwendal,
>
> (2012/03/23 14:14), Gwendal Grignou wrote:
>> On Fri, Mar 23, 2012 at 1:55 AM, ANEZAKI, Akira
>> <fireblade1230@...oo.co.jp> wrote:
>>> Hello Gwendal,
>>>
>>> Thank you for your information.
>>> I think ata8 might different from other 3 PMPs. I'll try to update all
>>> firmware but it is running resync on broken RAID now. So I can't do it soon.
>>> By the way, both of ata8 and ata9 loses some HDDs also. Are those
>>> affected by PMPs on ata7 and ata10? Why 3.1.x driver can work?
>>>
>>> Best Regards,
>>> Akira
>>>
>>>> Now I see your problem. Indeed on ata7, ata10, we have a problem.
>> I should have said ata7-ata10. The PMP on these 4 enclosures do not
>> like SRST at all.
>> It works with 3.1.x because it does not send SRST with this PMP; but
>> as I said before, that is not a good behavior [no staggered spin-up,
>> problem with drives slow to spin-up]
>
> You pointd out about power consumption, but I think most of SiI3726 are
> used in HDD boxes. If no staggered sign-up causes some voltage drop, it
> will affect only in HDD box, perhaps it is 12V power line drop. SiI3726
> will use 5V power line with regulator (IO = 3.3V, core=1.8V) so
> influence will be small.
I think my explanations were not clear enough. Here is another one
from a Fujistu white paper:
http://www.fujitsu.com/downloads/COMP/fcpa/hdd/mobile-sata-single_wp.pdf
"""Staggered spin-up is a simple mechanism by which the storage
subsystem controller
can sequence hard disk drive initialization and spin-up. Having this
feature not only
provides greater reliability, but it allows the system to avoid power
surges if all of the
HDDs spin up simultaneously during system power up (in a multi-drive
environment).
Another benefit to having staggered spin-up is the use of more
cost-effective power
supplies, which prevents power supply damage and system brownouts."""
> Whether send SRST or not, no HDDs are linked up at that time and it must
> wait for a while with repeating hard reset. Current behavior is "try 3
> times and ignore". If the behavior is changed to "try 4 times and
> ignore", the behavior of most HDD box wont be changed because all HDDs
> are linked up before 4th try. For users who has slow spin-up HDDs, they
> get more some seconds. I think it is convenient for most users and
> easier than trace/fix my problem. Of course the solution that solves my
> problem with SRST is best!
Once again, using SRST and fixed delays improves consistency. Without
it, the time between retries will depend of the controller you use and
the number of disks behind the PMP.
>
>> Gwendal.
>>>> I notice however some messages I did not see before:
>>>>>> [ 4.856382] ata7.15: Port Multiplier 1.1, 0x1095:0x3726 r23, 6 ports, feat 0x1/0x9
>>>>>> [ 4.858742] ata7.00: hard resetting link
>>>>>> [ 14.843039] ata7.00: softreset failed (timeout)
>>>>>> [ 17.836402] ata7.15: qc timeout (cmd 0xe4)
>>>> The later indicates that the PMP is stuck and the host can not read
>>>> its internal register.
>>>> Is it possible that the PMP in these 4 enclosures you are using have a
>>>> different firmware than the other ones?
>>>> Firmware 1.0114 is available at:
>>>> http://www.siliconimage.com/support/searchresults.aspx?pid=26&cat=23
>>>>
>>>> From the release notes:
>>>> """- Fix SRST and initial two RegFIS Problem."""
>
> I'm still fixing broken RAID. Sorry for my slow response.
>
> Best Regards,
> Akira
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists