Slackware linux 2.6.13.2 and SATA, not working too well

[seank]

I am having big problems using SATA on my linux machine.

- Slackware 10 w/ linux-2.6.13.2
- Abit KT7, Thunderbird 1.33ghz, 512mb RAM, 16mb S3 AGP video card
- PCI Promise SATA-II 150 TX2plus
w/ two Western Digital 320GB SATA 8MB Cache 7200RPM (WD3200JD)
- PCI Promise ATA133 20268 (not being used at the moment)
- LiteOn CDRW

I built a new Slackware computer with this PCI Promise SATAII-150 tx2plus card. I compiled a new 2.6.13.2 kernel with support for this chipset. I installed 2 SATA hd's from Western Digital and I am getting the errors you see below with dmesg when I try to access 2 particular directories on the partition, or when running e2fsck. This was the extent of my testing before I made this post. Everything on the SATA's is ghosted from IDE disks so I'm not too worried about the data. Most of the data on one 170GB partition is able to be verified by .sfv files, and using cfv I can see that there is zero corruption. The hdd just locks up.

When I e2fsck the disk, the disk locks up and I have to shutdown to stop it.

I tried downloading these drivers: http://www.promise.com/support/downl...productID=126#
But it kept giving this error when doing insmod:
# insmod ulsata2.ko
insmod: error inserting 'ulsata2.ko': -1 Unknown symbol in module

This is dmesg when e2fsck'ing (repeating):

ata2: status=0x51 { DriveReady SeekComplete Error }
ata2: error=0x40 { UncorrectableError }
ata2: status=0x51 { DriveReady SeekComplete Error }
ata2: error=0x40 { UncorrectableError }
ata2: status=0x51 { DriveReady SeekComplete Error }
ata2: error=0x40 { UncorrectableError }
ata2: status=0x51 { DriveReady SeekComplete Error }
ata2: error=0x40 { UncorrectableError }
ata2: status=0x51 { DriveReady SeekComplete Error }
ata2: error=0x40 { UncorrectableError }
SCSI error : <1 0 0 0> return code = 0x8000002
sdb: Current: sense key=0x3
ASC=0x11 ASCQ=0x4
end_request: I/O error, dev sdb, sector 282367
ata2: status=0x51 { DriveReady SeekComplete Error }
ata2: error=0x40 { UncorrectableError }
SCSI error : <1 0 0 0> return code = 0x8000002
sdb: Current: sense key=0x3
ASC=0x11 ASCQ=0x4
end_request: I/O error, dev sdb, sector 282375
ata2: status=0x51 { DriveReady SeekComplete Error }
ata2: error=0x40 { UncorrectableError }
SCSI error : <1 0 0 0> return code = 0x8000002
sdb: Current: sense key=0x3
ASC=0x11 ASCQ=0x4
end_request: I/O error, dev sdb, sector 282383
ata2: status=0x51 { DriveReady SeekComplete Error }
ata2: error=0x40 { UncorrectableError }
SCSI error : <1 0 0 0> return code = 0x8000002
sdb: Current: sense key=0x3
ASC=0x11 ASCQ=0x4

xxxx

Thanks for any help you can provide...

[kern]

bad cabling?

any reason you rolled your own kernel instead of using the 2.6.13 package on cd2?

if you did use the binary package on cd2 you wouldn't need to compile again, it'd automatically be upgraded when you upgrade slack.

I can see why if you need specific support for the promise SATA drivers.

modprobe is usually preferred over insmod too

[seank]

bad cabling?

any reason you rolled your own kernel instead of using the 2.6.13 package on cd2?

if you did use the binary package on cd2 you wouldn't need to compile again, it'd automatically be upgraded when you upgrade slack.

I can see why if you need specific support for the promise SATA drivers.

modprobe is usually preferred over insmod too

It can't be bad cabling... one of the examples I mentioned is that it's 2 specific dirs causing errors. 2 areas on the disk, you know? Funny you ask about using the 2.6 off CD2... it was just that i was kind of excited about having an excuse to use 2.6 now (for the SATA support). I wanted to see what all the hype was about. I like it. The kernel I upgraded from was 2.4.26.

I understand modprobe should have been used, but I decided to use insmod as per the driver installation directions in the README.

Here is modprobe:
# modprobe ulsata2
FATAL: Error inserting ulsata2 (/lib/modules/2.6.13.2/kernel/drivers/scsi/ulsata2.ko): Unknown symbol in module, or unknown parameter (see dmesg)

and dmesg...

ulsata2: Unknown symbol scsi_set_device

[seank]

I think I'm going to put my old IDE drives back in. It may have been silly of me to think that I, with my linux noobness, would be able to get a relatively new SATA working correctly...

[seank]

I've ordered a new PCI controller

Silicon Image 3112. 2 ports, regular SATA, and it seems to be supported by linux well. Lets see how it goes...

[durval]

The original problem is due to the fact that the poster (seank) is trying to use the Promise "proprietary" driver with kernel 2.6.13, instead of the built-in libsata-based driver. The Promise driver depends on scsi_set_device, a "mid-to-low" internal kernel function which was removed on the transition from kernel 2.6.12 to kernel 2.6.13. I too am trying to use the "proprietary" (I put it between quotes because they supply full source code) promise driver with kernel 2.6.13, because the libsata driver behaves badly when a disk goes bad (starts reporting errors on the *other* disks connected to the same controller, which definitelly isn't good, and is even worse when those disks are in a RAID5 as is my case). I will research further and if I find a solution, I will come back and post it here.

Cheers,
Durval Menezes.

[durval]

The original problem is due to the fact that the poster (seank) is trying to use the Promise "proprietary" driver with kernel 2.6.13, instead of the built-in libsata-based driver. The Promise driver depends on scsi_set_device, a "mid-to-low" internal kernel function which was removed on the transition from kernel 2.6.12 to kernel 2.6.13. I too am trying to use the "proprietary" (I put it between quotes because they supply full source code) promise driver with kernel 2.6.13, because the libsata driver behaves badly when a disk goes bad (starts reporting errors on the *other* disks connected to the same controller, which definitelly isn't good, and is even worse when those disks are in a RAID5 as is my case). I will research further and if I find a solution, I will come back and post it here.

Cheers,
Durval Menezes.

Dear folks,

I have investigated the above problem a little more and discovered that, apparently, the call to scsi_set_device is no longer necessary on a 2.6.13+ kernel. So I produced the following little patch to Promise's code:

diff -ruN ut_mod.orig-20051026/pdc-ulsata2.c ut_mod/pdc-ulsata2.c
--- ut_mod.orig-20051026/pdc-ulsata2.c  2005-07-06 23:27:35.000000000 -0300
+++ ut_mod/pdc-ulsata2.c        2005-10-26 08:26:51.000000000 -0200
@@ -1279,7 +1279,11 @@
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,0)
        ulsata2_adapter_t *pada = &ulsata2_adapter[ua];
        ulsata2_pci_dev = pada->pci_dev;
-       scsi_set_device(shpnt, &ulsata2_pci_dev->dev);
+       #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,13)
+               /* do nothing */
+       #else
+               scsi_set_device(shpnt, &ulsata2_pci_dev->dev);
+       #endif
 #elif LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,4)
                scsi_set_pci_device(shpnt, ulsata2_pci_dev);
 #endif

Use at your own risk, etc etc but it's working great on my test machine (RHEL4.2 compatible distro with custom-compiled kernel 2.6.13.4, running with a Promise SATAII150TX4 controller with 3 Seagate ST3250823AS, which are being mounted on a RAID5 array using the standard linux md driver, and onto which I'm defining an LVM2 group and volumes). The above patch was generated on the source tree obtained from expanding the 3_sataii150-300-tx-series-linux2.6-src-x86_v1.01.0.20.tar.gz
tarfile downloaded from Promise's site, just before running the "make clean" and "make DRIVER_SRC_DIR=`pwd`" commands.


Now I will proceed to test the promise driver behavior when one disk goes bad (which I'm simulating by pulling out the serial ATA signal cable for this disk on the controller end)...

[durval]

Good news, folks.

The tests with my patched ulsata2 driver were more than satisfactory: I pulled out the disk and the RAID5 did *not* stop, unlike the builtin libata/promise driver which simply quit on all 3 disks. The array (and the rest of the system) just kept chugging along, without even a flicker.

I will be documenting this further, and submitting (the patch) to the Promise developers, and (the multiple disk failure problem) to the LIBATA folks.

Cheers,
--
Durval Menezes.

The original problem is due to the fact that the poster (seank) is trying to use the Promise "proprietary" driver with kernel 2.6.13, instead of the built-in libsata-based driver. The Promise driver depends on scsi_set_device, a "mid-to-low" internal kernel function which was removed on the transition from kernel 2.6.12 to kernel 2.6.13. I too am trying to use the "proprietary" (I put it between quotes because they supply full source code) promise driver with kernel 2.6.13, because the libsata driver behaves badly when a disk goes bad (starts reporting errors on the *other* disks connected to the same controller, which definitelly isn't good, and is even worse when those disks are in a RAID5 as is my case). I will research further and if I find a solution, I will come back and post it here.

Cheers,
Durval Menezes.

Dear folks,

I have investigated the above problem a little more and discovered that, apparently, the call to scsi_set_device is no longer necessary on a 2.6.13+ kernel. So I produced the following little patch to Promise's code:

diff -ruN ut_mod.orig-20051026/pdc-ulsata2.c ut_mod/pdc-ulsata2.c
--- ut_mod.orig-20051026/pdc-ulsata2.c  2005-07-06 23:27:35.000000000 -0300
+++ ut_mod/pdc-ulsata2.c        2005-10-26 08:26:51.000000000 -0200
@@ -1279,7 +1279,11 @@
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,0)
        ulsata2_adapter_t *pada = &ulsata2_adapter[ua];
        ulsata2_pci_dev = pada->pci_dev;
-       scsi_set_device(shpnt, &ulsata2_pci_dev->dev);
+       #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,13)
+               /* do nothing */
+       #else
+               scsi_set_device(shpnt, &ulsata2_pci_dev->dev);
+       #endif
 #elif LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,4)
                scsi_set_pci_device(shpnt, ulsata2_pci_dev);
 #endif

Use at your own risk, etc etc but it's working great on my test machine (RHEL4.2 compatible distro with custom-compiled kernel 2.6.13.4, running with a Promise SATAII150TX4 controller with 3 Seagate ST3250823AS, which are being mounted on a RAID5 array using the standard linux md driver, and onto which I'm defining an LVM2 group and volumes). The above patch was generated on the source tree obtained from expanding the 3_sataii150-300-tx-series-linux2.6-src-x86_v1.01.0.20.tar.gz
tarfile downloaded from Promise's site, just before running the "make clean" and "make DRIVER_SRC_DIR=`pwd`" commands.


Now I will proceed to test the promise driver behavior when one disk goes bad (which I'm simulating by pulling out the serial ATA signal cable for this disk on the controller end)...