controller card so I could try swapping them. Do you have any
suggestions for what I should try next?
Best regards,
Peter
Mikael Pettersson wrote:
Peter Favrholdt writes:
If it is not too much of a hassle, could you please make a 1.5Gbps patch
for 2.6.24 for me to try out? If it solves
Hi Mikael list,
I have previously reported problems with my setup:
SATA300TX4 + 4 Seagate Barracuda ES 500GB
I just tested with 2.6.24. After copying approx 25GB of each drive using
dd if=/dev/sd[abcd] of=/dev/null bs=1M
sda failed with the following message:
[ 1060.069489] ata1: SError: {
Hi Mikael,
Thanks for your reply :-)
Mikael Pettersson wrote:
Mysterious. What you have there is a transmission error between the
controller and the disk, which is bad in and by itself, but then there's
a sequence of COMRESETs that fail to bring the port or disk back to life.
The original
] disk 3, o:1, dev:sdb
01:20:49 mdadm: Fail event detected on md device /dev/md0, component
device /dev/sda
01:20:49 mdadm: RebuildFinished event detected on md device /dev/md0
Best regards,
Peter
Peter Favrholdt wrote:
The problem is solved in 2.6.23.1 regarding the port slow to respond
issue
Hi,
MisterE wrote:
Tonight i will try the Asus motherboard with 1 drive and much I/O. And
i will create a new array which takes 7 hours. But how often/hours do
you need to try something to prove it does not fail :P
On one box I had problems with the SATA300 TX4 using 2.6.21 through
2.6.22
Hi
Mikael Pettersson wrote:
However, I don't see how the sata_promise changes from 2.6.22 to 2.6.23
can explain this. The only functional changes there are a critical fix
for FastTrack TX4200 (not your card), and support for SATA hotplugging
(not happening here).
So I'm suspecting something in
/null bs=1M
dd if=/dev/sdc of=/dev/null bs=1M
dd if=/dev/sdd of=/dev/null bs=1M
And it just runs perfectly to the end with no hickups :-)
Thank you very much :-)
Best regards,
Peter
Peter Favrholdt wrote:
Hi,
I'm still experiencing the same port is slow to respond problem using
Mikael Pettersson wrote:
nForce2. Hmm..
Peter Favrholdt wrote:
11: 27474XT-PIC-XTlibata, 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
Hi,
I'm still experiencing the same port is slow to respond problem using
sata_promise in linux-2.6.22.6 with my Promise Technology, Inc. PDC40718
(SATA 300 TX4) (rev 02) and 4 Seagate 500GB ES drives:
Model Number: ST3500630NS
Firmware Revision: 3.AEE
(with
Hi Mikael Pettersson wrote:
I'm easily able to reproduce this problem on my sata_promise test rig.
Using 2.6.23-rc5 to dd read a single Seagate disk on a SATA300 TX4 card
quickly fails as Peter described.
Applying the 1.5Gbps patch to the driver appears to make things stable.
Those SATAII
Just testet 2.6.22 on my setup. Unfortunately the problem is still there.
Interesting part of dmesg:
[ 33.036786] sata_promise :01:08.0: applying SATAII TX4 port
numbering workaround
[ 33.036926] scsi0 : sata_promise
[ 33.037032] scsi1 : sata_promise
[ 33.037125] scsi2 :
Tomi Orava wrote:
Have you had time to check if the latest patch fixes our problems
with promise-controller ?
http://bugzilla.kernel.org/attachment.cgi?id=11694action=view
The above patch seems to apply to the latest rc4 kernel.
I have not found the time to reboot my own server as of yet.
Hi Tomi,
Thanks for the reply :-)
I don't know if this would be possible for you, but I think it would be
interesting to see what would happen if you swapped the SATA cable on
one of your problem drives with one which is ok. In my system (four
identical drives) I have the feeling the problem
Hi,
I have tried exchanging SATA cables, but still have the problem with
sata_promise using 2.6.21-git16.
HW info:
Promise Technology, Inc. PDC40718 (SATA 300 TX4) (rev 02)
with 4 Seagate 500GB ES drives:
Model Number: ST3500630NS
Firmware Revision: 3.AEE
(with
Replying to my own post:
Wanted to add that the ata1 port just died even without doing any
smartctl's - and not recovering.
BR Peter
Peter Favrholdt wrote:
Hi,
I've tested with 2.6.21.1 with the following patches (which applied
cleanly):
http://user.it.uu.se/~mikpe/linux/patches/2.6/patch
5329152
Next I'll try with the 1.5Gbps patch...
BR Peter
Mikael Pettersson wrote:
On Thu, 10 May 2007 21:41:32 +0200, Peter Favrholdt wrote:
I would like to help by testing the most recent version of the
sata_promise driver on my
Promise Technology, Inc. PDC40718 (SATA 300 TX4) (rev 02
Hi,
I would like to help by testing the most recent version of the
sata_promise driver on my
Promise Technology, Inc. PDC40718 (SATA 300 TX4) (rev 02)
with 4 Seagate 500GB ES drives:
Model Number: ST3500630NS
Firmware Revision: 3.AEE
(with 1.5/3.0Gbps jumper
shows under
certain lucky circumstances - maybe the robustness of 2.6.21-rc2+p is
due to local-apic not being enabled or some other subtle kernel build thing?
Any suggestion on what I could do to help track this down is much
appreciated?
Best regards,
Peter Favrholdt
-
To unsubscribe from
Hi again,
Peter Favrholdt wrote:
My feeling is this is not caused by 1.5Gbps or 3.0Gbps operation.
...snip
My next test will be a plain 2.6.21rc2. Then I'll apply the patches one
by one.
I've tested 2.6.21-rc2 which fails (sdc down after 27 minutes sdd down
after 46 minutes).
Then I
Hi Tomi,
My experiences are in accordance with yours:
1) it doesn't matter if IO-APIC is enabled or not.
2) using Mikaels patch bundle the channel may die then recovers ok.
(This can be triggered by using smartctl when loaded).
3) It is never the first port that dies. It seems to be always
Hi,
I've seen intermittent problems with Promise SATA300 TX4 controllers
and Linux kernel 2.6.19 (through 2.6.20-rc2 with some additional
patches).
Sometimes the TX4 will loose a port - a reboot brings the drive back up
again. I'm quite sure the harddrives are not at fault.
I have
21 matches
Mail list logo
