Hello.
There appears to be a hardware bug in that it chokes on scatterlist
if the last item is larger than 164 bytes.
The patch that follows fixes my problem on 2.6.22.
I can't think of a way to avoid second pass over scatterlist without
duplicating code (ata_qc_prep() and ata_fill_sg() from
?
I.e., how did you determine the existence of this bug?
And please cc: the sata_promise maintainer on sata_promise patches.
(Hint: that's me)
And please choose a Subject: that makes it absolutely clear what
the post is about. Sata Sil3512 bug doesn't exactly sound like
something the sata_promise
Hello.
Tejun Heo wrote:
Does the attached patch help?
It does somehow force 1.5GB/s mode, and it does change the pattern of
'configured for UDMAxxx' messages that come along with errors, and it
causes the following error:
ata3: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xb t4
ata3:
Alexander Sabourenkov wrote:
Hello.
So, my bet for your second report is your hardware went through
something similar as above.
Thanks for the insight. Let's dismiss it then.
Back to the TX4, I tried libata-dev.git cloned at about 20:00 UTC 19.10,
no perceived difference - parallel read
Hello Alexander,
Friday, October 19, 2007, 11:06:02 PM, you wrote:
I don't know what to try next. Any ideas?
I'm no kernel hacker, so i'll take a shot.
I assume you have done most already...
* hardware (Tested/without/or used another: motherboard, videocard, memory,
hard drives, power
Hello.
So, my bet for your second report is your hardware went through
something similar as above.
Thanks for the insight. Let's dismiss it then.
Back to the TX4, I tried libata-dev.git cloned at about 20:00 UTC 19.10,
no perceived difference - parallel read from two drives causes a lot
Hello.
I have done some quick tests with 2.6.23/amd64 and unfortunately, the
very same problem persists.
By the way, 8 in (port_status 0x2008) stands for
PDC_OVERRUN_ERR = (1 19), /* S/G byte count larger
than HD requires */
Does by any chance 'S/G' here somehow relate to
Hello,
Wednesday, October 3, 2007, 10:31:17 AM, you wrote:
Mikael Pettersson wrote:
I'm thinking of replacing both 3512 controllers with a Promise SATA300
TX4. Do you know if there are problems with this device?
(please don't top-post)
There are no known data-corruption issues with
Hello Alexander,
Wednesday, October 17, 2007, 2:54:25 PM, you wrote:
Log file got lost. Please post relevant parts inline.
Sorry, i totally forgot to include them.
I can not reproduce the errors. Last times hda did not give errors. So i'm
not sure if it is related to each other. (in the thread
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
MisterE wrote:
Oct 13 13:01:26 fileserver kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr
0x240 action 0x0
Oct 13 13:01:26 fileserver kernel: ata4.00: (BMDMA2 stat 0x650001)
Oct 13 13:01:26 fileserver kernel: ata4.00: cmd
ca/00:f8:47:e1:5e/00:00:00:00:00/e4 tag 0 cdb 0x0 data 126976
MisterE wrote:
Hello,
Alexander, does these problems with the Promise SATA300 TX4 happen to
everyone?
Most probably not, as I think it would have been fixed much faster then.
I was waiting for a) release of 2.6.23, and b) me completing the move to
another flat
to retest all the latest
Hello,
Alexander, does these problems with the Promise SATA300 TX4 happen to
everyone?
The only alternatives are
using soft-raid products as normal controllers. Does anyone have experiences
with the following products?
* Highpoint RocketRAID 1640 (150 MB/s)
* Highpoint RocketRAID 1740 (300 MB/s)
Hello Tejun,
unfortunately. I today tried to build the array (4x500GB, so it is still
building) and i got again a error:
Oct 13 12:17:56 fileserver kernel: raid5: device sdc1 operational as raid disk 2
Oct 13 12:17:56 fileserver kernel: raid5: device sdb1 operational as raid disk 1
Oct 13
On Tue, 2 Oct 2007 21:20:23 +0200, MisterE wrote:
I build another setup with almost the same hardware.
This motherboard had already the latest bios.
I notice that the computer does almost never find the hard drive
although the controller is found every time (with lspci). So i get no
drive
Mikael Pettersson wrote:
I'm thinking of replacing both 3512 controllers with a Promise SATA300
TX4. Do you know if there are problems with this device?
(please don't top-post)
There are no known data-corruption issues with Promise SATA cards.
However, some of them, especially the 2nd
Hello Alexander,
Wednesday, October 3, 2007, 10:31:17 AM, you wrote:
Mikael Pettersson wrote:
I'm thinking of replacing both 3512 controllers with a Promise SATA300
TX4. Do you know if there are problems with this device?
(please don't top-post)
There are no known data-corruption
That is not hopefull. Highpoint does not have sata controllers (Except
softraid controllers). Other (real raid controllers) brands are too
There are pretty much no real RAID controllers in the ATA world except
the very high end pricy ones.
-
To unsubscribe from this list: send the line
There are pretty much no real RAID controllers in the ATA world
except the very high end pricy ones.
Can anyone comment on the reliability or otherwise of Marvell 885X6081
controllers?
Supermicro do a reasonably priced non-RAID 8 drive SATA card using it:
Hello,
MisterE wrote:
I build another setup with almost the same hardware.
This motherboard had already the latest bios.
I notice that the computer does almost never find the hard drive
although the controller is found every time (with lspci).
What do you mean by almost never? Does it find
Hello Tejun,
I build another setup with almost the same hardware.
This motherboard had already the latest bios.
I notice that the computer does almost never find the hard drive
although the controller is found every time (with lspci). So i get no
drive (sda) assigned. I don't always see the bios
Hello Tejun,
I've tried with 2 sata cables. Cables which don't give problems with
the Asus motherboard.
I also now use a new decent power supply (corsair vx450) for the
intel. Before it, i used an Fortron supply. But it had no sata
connectors so i used converter adapters. But replacing the supply
Alan Cox wrote:
sda1 are corrupted (2 to 4 blocks missing). Copying that data back to
Windows and it give the same results in Quickpar. So reading does not
have problems. The data written to hda1 is correct.
We've got a whole pile of reports like this with the 3512 and almost
always Nvidia
sda1 are corrupted (2 to 4 blocks missing). Copying that data back to
Windows and it give the same results in Quickpar. So reading does not
have problems. The data written to hda1 is correct.
We've got a whole pile of reports like this with the 3512 and almost
always Nvidia chipset, plus
Hello,
MisterE wrote:
I've tried the controller in another motherboard, the ASUS CUSL2 (with
similar specs)
and i don't have any problems. Can you help? I've included some logs
with may be of use.
Did you use the same cable on both machines? Also, does the problem go
away if you power the
Hello,
First off, i'm quite new to linux. I don't know the official way's to
report bugs. I'm not even sure that the bug is sata driver related. I
hope you can do some suggestions.
I recently bought 2 Sweex Sata controllers (without raid). This device
contains the Sil3512 chip.
I connected it to
26 matches
Mail list logo
