> No, why are they to be expected with SATA2 mode? Is the defect
> specific to the SATA2 circuitry? I guess it could be a temporary
> workaround provided they would eventually fix the problem in
> firmware, but I'm getting new drives, so I guess I can't complain :-)
Probably your new disks do
Hi, do you have disks connected in sata1/2? With
WD2003FYYS-01T8B0/WD20EADS-00S2B0/WD1001FALS-00J7B1/WD1002FBYS-01A6B0
these timeouts are to be expected if disk is in SATA2 mode,
No, why are they to be expected with SATA2 mode? Is the defect
specific to the SATA2 circuitry? I guess it could be
...
>
> I have identified the culprit is the Western Digital drive WD2002FYPS-01U1B0.
> It's not clear if they can fix it in firmware, but Western Digital is
> replacing my drives.
> Feb 17 04:45:10 thecratewall scsi_status=0x0, ioc_status=0x804b,
> scsi_state=0xc
> Feb 17 04:45:10 thecratewall
At 11:19 AM +1000 2/19/10, James C. McPherson wrote:
On 19/02/10 12:51 AM, Maurice Volaski wrote:
For those who've been suffering this problem and who have non-Sun
jbods, could you please let me know what model of jbod and cables
(including length thereof) you have in your configuration.
For th
Hello.
We are seeing the problem on both Sun and non-Sun hardware. On our Sun thumper
x4540, we can reproduce it on all 3 devices. Our configuration is large stripes
with only 2 vdevs. Doing a simple scrub will show the typical mpt timeout.
We are running snv_131.
Somebody observed similar p
On 19/02/10 12:51 AM, Maurice Volaski wrote:
For those who've been suffering this problem and who have non-Sun
jbods, could you please let me know what model of jbod and cables
(including length thereof) you have in your configuration.
For those of you who have been running xVM without MSI suppo
> >>For those who've been suffering this problem and
> who have non-Sun
> >>jbods, could you please let me know what model of
> jbod and cables
> >>(including length thereof) you have in your
> configuration.
> >>
We are seeing the problem on both Sun and non-Sun hardware. On our Sun thumper
x454
For those who've been suffering this problem and who have non-Sun
jbods, could you please let me know what model of jbod and cables
(including length thereof) you have in your configuration.
For those of you who have been running xVM without MSI support,
could you please confirm whether the devic
For those who've been suffering this problem and who have non-Sun
jbods, could you please let me know what model of jbod and cables
(including length thereof) you have in your configuration.
For those of you who have been running xVM without MSI support,
could you please confirm whether the devic
For those who've been suffering this problem and who have non-Sun
jbods, could you please let me know what model of jbod and cables
(including length thereof) you have in your configuration.
For those of you who have been running xVM without MSI support,
could you please confirm whether the devic
Hi Simon
> I.e. you'll have to manually intervene
> if a consumer drive causes the system to hang, and
> replace it, whereas the RAID edition drives will
> probably report the error quickly and then ZFS will
> rewrite the data elsewhere, and thus maybe not kick
> the drive.
IMHO the relevant aspe
Hi Tonmaus,
> they are the new revision.
OK.
> I got the impression as well that the complaints you
> reported were mainly related to embedded Linux
> systems probably running LVM / mda. (thecus, Qnap,
> ) Other reports I had seen related to typical HW
> raids. I don't think the situation i
Hi Simon,
they are the new revision.
I got the impression as well that the complaints you reported were mainly
related to embedded Linux systems probably running LVM / mda. (thecus, Qnap,
) Other reports I had seen related to typical HW raids. I don't think the
situation is comparable to Z
Looks like I got the textbook response from Western Digital:
---
Western Digital technical support only provides jumper configuration and
physical installation support for hard drives used in systems running the
Linux/Unix operating systems. For setup questions beyond physical installation
of yo
If I'm not mistaken then the WD2002FYPS is an enterprise model: WD RE4-GP (RAID
Edition, Green Power), so you almost certainly have the firmware that allows
(1) the idle time before spindown to be modified with WDIDLE3.EXE and (2) the
error reporting time to be modified with WDTLER.EXE.
So I e
> That's good to hear. Which revision are they: 00R6B0
> or 00P8B0? It's marked on the drive top.
Interesting. I wonder if this is the issue too with the 01U1B0 2.0TB drives?
I have 24 WD2002FYPS-01U1B0 drives under OpenSolaris with an LSI 1068E
controller that have weird timeout issues and I
Hi Tonmaus,
That's good to hear. Which revision are they: 00R6B0 or 00P8B0? It's marked on
the drive top.
>From what I've seen elsewhere, people seem to be complaining about the newer
>00P8B0 revision, so I'd be interested to hear from you. These revision numbers
>are listed in the first post
Hi Simon,
I am running 5 WD20EADS in a raidz-1+spare on ahci controller without any
problems I could relate to TLER or head parking.
Cheers,
Tonmaus
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
> My timeout issue is definitely the WD10EARS disks.
> WD has chosen to cripple their consumer grade disks
> when used in quantities greater than one.
>
> I'll now need to evaluate alternative supplers of low
> cost disks for low end high volume storage.
>
> Mark.
>
> typo ST32000542AS not NS
T
The results are in:
My timeout issue is definitely the WD10EARS disks.
Although differences in the error rate was seen with different LSI firmware
revisions, the errors persisted. The more disks on the expander, the higher the
number with iostat errors.
This then causes zpool issues (disk failur
An update:
Well things didn't quite turn out as expected.
I decided to follow the path right to the disks for clues.
Digging into the adapter diags with LSIUTIL, revealed an Adapter Link issue.
Adapter Phy 5: Link Down
Invalid DWord Count 5,969,575
Running D
I would definitely be interested to see if the newer firmware fixes the problem
for you. I have a very similar setup to yours, and finally forcing the
firmware flash to 1.26.00 of my on-board LSI 1068E on a SuperMicro H8DI3+
running snv_131 seemed to address the issue. I'm still waiting to see
I can produce the timeout error on multiple, similar servers.
These are storage servers, so no zones or gui running.
Hardware:
Supermicro X7DWN with AOC-USASLP-L8i controller
E1 (single port) backplanes (16 & 24 bay)
(LSILOGICSASX28 A.0 and LSILOGICSASX36 A.1)
up to 36 1Tb WD Sata disks
This serv
Can't say when the problems may have been introduced, but it looks like we've
got my report (b104) and another report from b111 of issues with the 1068E.
The IR firmware seems to do some sort of internal multipathing while the IT
firmware doesn't do any. With the IT firmware, I enabled multipat
I'm glad I was able to help someone.
My card is also a 3081E-R (B3). It shipped to me with the IR firmware, and I
immediately flashed the IT firmware on it because I had heard it was supposed
to be (better, faster, stable, shiny) with Solaris and ZFS.
The motherboard on that server has an LSI
I've spent all weekend fighting this problem on our storage server after
installing a ZFS log device, and your suggestion fixed it!
I also have a LSI 3081E-R adapter (B3 revision) connected to a SAS expander
backplane with 7 drives on it. None of the /etc/system options mentioned in
this thre
I was under the impression that the problem affecting most of us was introduced
much later than b104,
sometime between ~114 and ~118. When I first started using my LSI 3081 cards,
they had the IR firmware
on them, and it caused me all kinds of problems. The disks showed up but I
couldn't write
I found this thread after fighting the same problem in Nexenta which uses the
OpenSolaris kernel from b104. Thankfully, I think I have (for the moment)
solved my problem.
Background:
I have an LSI 3081e-R (1068E based) adapter which experiences the same
disconnected command timeout error unde
Perhaps. As I noted though, it also occurs on the onboard NVidia SATA
controller when MSI is enabled. I had already put a line in /etc/system to
disable MSI for that controller per a forum thread and it worked great. I'm now
running with all MSI disabled via XVM as the mpt controller is giving m
Just an update, my scrub completed without any timeout errors in the log. XVM
with MSI disabled globally.
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/z
> Chenbro 16 hotswap bay case. It has 4 mini backplanes that each connect via
> an SFF-8087 cable
> StarTech HSB430SATBK
hmm, both are passive backplanes with one SATA tunnel per link...
no SAS Expanders (LSISASx36) like those found in SuperMicro or J4x00 with 4
links per connection.
wonder
> (1) disabling MSI support in xVM makes the problem go
> away
Yes here.
> (6) mpt(7d) without MSI support is sloow.
That does seem to be the case. It's not so bad overall, and at least the
performance is consistent. It would be nice if this were improved.
> For those of you who have b
Hi,
I just posted a summary of a similiar issue I'm having with non-Sun hardware.
For the record, it's in a Chenbro RM41416 chassis with 4 chenbro SAS backplanes
but no expanders (each backplane is 4 disks connected by SFF-8087 cable). Each
of my LSI brand SAS3081E PCI-E cards is connected to two
Hi all,
I believe it's an accurate summary of the emails on this thread
over the last 18 hours to say that
(1) disabling MSI support in xVM makes the problem go away
(2) disabling MSI support on bare metal when you only have
disks internal to your host (no jbods), makes the problem
go aw
Carson Gaspar wrote:
Mark Johnson wrote:
I think there are two different bugs here...
I think there is a problem with MSIs and some variant of mpt
card on xVM. These seem to be showing up as timeout errors.
Disabling MSIs for this adapter seems to fix this problem.
For folks seeing this probl
On Nov 30, 2009, at 2:14 PM, Carson Gaspar wrote:
Mark Johnson wrote:
I think there are two different bugs here...
I think there is a problem with MSIs and some variant of mpt
card on xVM. These seem to be showing up as timeout errors.
Disabling MSIs for this adapter seems to fix this proble
Mark Johnson wrote:
I think there are two different bugs here...
I think there is a problem with MSIs and some variant of mpt
card on xVM. These seem to be showing up as timeout errors.
Disabling MSIs for this adapter seems to fix this problem.
For folks seeing this problem, what HBA adapter a
> o The problems are not seen with Sun's version of
> this card
Unable to comment as I don't have a Sun card here. If Sun would like to send me
one, I would be willing to test it compared to the cards I do have. I'm running
Supermicro USAS-L8i cards (LSI 1068e based).
> o The problems are not
> Can folks confirm/deny each of these?
>
> o The problems are not seen with Sun's version of
> this card
On the Thumper x4540 (which uses 6 of the same LSI 1068E controller chips), we
do not see this problem. Then again, it uses a one-to-one mapping of controller
PHY ports to internal disks;
James C. McPherson wrote:
Adam Cheal wrote:
I thought you had just set
set xpv_psm:xen_support_msi = -1
which is different, because that sets the
xen_support_msi variable
which lives inside the xpv_psm module.
Setting mptsas:* will have no effect on your system
if you do not
have an mptsas
Tru Huynh wrote:
On Sat, Nov 21, 2009 at 07:08:20PM +1000, James C. McPherson wrote:
If you and everybody else who is seeing this problem could provide
details about your configuration (output from cfgadm -lva, raidctl
-l, prtconf -v, what your zpool configs are, and the firmware rev
of each dis
Adam Cheal wrote:
I thought you had just set
set xpv_psm:xen_support_msi = -1
which is different, because that sets the
xen_support_msi variable
which lives inside the xpv_psm module.
Setting mptsas:* will have no effect on your system
if you do not
have an mptsas card installed. The mptsas ca
>
> I thought you had just set
>
> set xpv_psm:xen_support_msi = -1
>
> which is different, because that sets the
> xen_support_msi variable
> which lives inside the xpv_psm module.
>
> Setting mptsas:* will have no effect on your system
> if you do not
> have an mptsas card installed. The mpts
Adam Cheal wrote:
Hi Adam,
thanks for this info. I've talked with my colleagues
in Beijing (since
I'm in Beijing this week) and we'd like you to try
disabling MSI/MSI-X
for your mpt instances. In /etc/system, add
set mpt:mpt_enable_msi = 0
then regen your boot archive and reboot.
I had alrea
> Hi Adam,
> thanks for this info. I've talked with my colleagues
> in Beijing (since
> I'm in Beijing this week) and we'd like you to try
> disabling MSI/MSI-X
> for your mpt instances. In /etc/system, add
>
> set mpt:mpt_enable_msi = 0
>
> then regen your boot archive and reboot.
>
I had alre
Adam Cheal wrote:
Thankyou for all who've procvided data about this. I've updated the
bugs mentioned earlier and I believe we can now make progress on
diagnosis.
The new synopsis (should show up on b.o.o tomorrow) is as follows:
6894775 mpt's msi support is suboptimal with xVM
FYI, as the or
Thankyou for all who've procvided data about this. I've updated
the bugs mentioned earlier and I believe we can now make progress
on diagnosis.
The new synopsis (should show up on b.o.o tomorrow) is as follows:
6894775 mpt's msi support is suboptimal with xVM
James C. McPherson
--
Senior Ke
> Travis Tabbal wrote:
> > I have a possible workaround. Mark Johnson
> has
> > been emailing me today about this issue and he
> proposed the
> > following:
> >
> >> You can try adding the following to /etc/system,
> then rebooting...
> >> set xpv_psm:xen_support_msi = -1
>
> I am also running
>
> On Nov 23, 2009, at 7:28 PM, Travis Tabbal wrote:
>
> > I have a possible workaround. Mark Johnson
>
> > has been emailing me today about this issue and he
> proposed the
> > following:
> >
> >> You can try adding the following to /etc/system,
> then rebooting...
> >> set xpv_psm:xen_sup
On Nov 23, 2009, at 7:28 PM, Travis Tabbal wrote:
I have a possible workaround. Mark Johnson
has been emailing me today about this issue and he proposed the
following:
You can try adding the following to /etc/system, then rebooting...
set xpv_psm:xen_support_msi = -1
would this change
Travis Tabbal wrote:
I have a possible workaround. Mark Johnson has
been emailing me today about this issue and he proposed the
following:
You can try adding the following to /etc/system, then rebooting...
set xpv_psm:xen_support_msi = -1
I am also running XVM, and after modifying /etc/syste
I have a possible workaround. Mark Johnson has been
emailing me today about this issue and he proposed the following:
> You can try adding the following to /etc/system, then rebooting...
> set xpv_psm:xen_support_msi = -1
I have been able to format a ZVOL container from a VM 3 times while oth
Travis Tabbal wrote:
I will give you all of this information on monday.
This is great news :)
Indeed. I will also be posting this information when I get to the server
tonight. Perhaps it will help. I don't think I want to try using that old
driver though, it seems too risky for my taste.
D
> I will give you all of this information on monday.
> This is great news :)
Indeed. I will also be posting this information when I get to the server
tonight. Perhaps it will help. I don't think I want to try using that old
driver though, it seems too risky for my taste.
Is there a command
On Nov 21, 2009, at 1:08 AM, James C. McPherson wrote:
We currently have two bugs open on what I believe to be the same
issue, namely
6894775 mpt driver timeouts and bus resets under load
6900767 Server hang with LSI 1068E based SAS controller under load
If you and everybody else who is seeing
Carson Gaspar wrote:
For all of those suffering from mpt timeouts in snv_127, I decided to
give the ancient itmpt driver a whirl. It works fine, and in my brief
testing a zfs scrub that would generate about 1 timeout every 2 minutes
or so now runs with no problems.
The downside is that lsiutil
For all of those suffering from mpt timeouts in snv_127, I decided to
give the ancient itmpt driver a whirl. It works fine, and in my brief
testing a zfs scrub that would generate about 1 timeout every 2 minutes
or so now runs with no problems.
The downside is that lsiutil and raidctl both fai
57 matches
Mail list logo
