Find the answer to your Linux question:
Results 1 to 8 of 8
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 ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Sep 2005
    Posts
    5

    Slackware linux 2.6.13.2 and SATA, not working too well


    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...

  2. #2
    Linux Enthusiast
    Join Date
    Jun 2005
    Posts
    668
    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


  3. #3
    Just Joined!
    Join Date
    Sep 2005
    Posts
    5
    Quote Originally Posted by 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

    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

  4. $spacer_open
    $spacer_close
  5. #4
    Just Joined!
    Join Date
    Sep 2005
    Posts
    5
    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...

  6. #5
    Just Joined!
    Join Date
    Sep 2005
    Posts
    5
    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...

  7. #6
    Just Joined!
    Join Date
    Oct 2005
    Posts
    3
    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.

  8. #7
    Just Joined!
    Join Date
    Oct 2005
    Posts
    3

    Problem SOLVED

    Quote Originally Posted by 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:

    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&#58;27&#58;35.000000000 -0300
    +++ ut_mod/pdc-ulsata2.c        2005-10-26 08&#58;26&#58;51.000000000 -0200
    @@ -1279,7 +1279,11 @@
     #if LINUX_VERSION_CODE >= KERNEL_VERSION&#40;2,5,0&#41;
            ulsata2_adapter_t *pada = &ulsata2_adapter&#91;ua&#93;;
            ulsata2_pci_dev = pada->pci_dev;
    -       scsi_set_device&#40;shpnt, &ulsata2_pci_dev->dev&#41;;
    +       #if LINUX_VERSION_CODE >= KERNEL_VERSION&#40;2,6,13&#41;
    +               /* do nothing */
    +       #else
    +               scsi_set_device&#40;shpnt, &ulsata2_pci_dev->dev&#41;;
    +       #endif
     #elif LINUX_VERSION_CODE >= KERNEL_VERSION&#40;2,4,4&#41;
                    scsi_set_pci_device&#40;shpnt, ulsata2_pci_dev&#41;;
     #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)...

  9. #8
    Just Joined!
    Join Date
    Oct 2005
    Posts
    3

    Re: Problem SOLVED

    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.

    Quote Originally Posted by durval
    Quote Originally Posted by 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:

    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&#58;27&#58;35.000000000 -0300
    +++ ut_mod/pdc-ulsata2.c        2005-10-26 08&#58;26&#58;51.000000000 -0200
    @@ -1279,7 +1279,11 @@
     #if LINUX_VERSION_CODE >= KERNEL_VERSION&#40;2,5,0&#41;
            ulsata2_adapter_t *pada = &ulsata2_adapter&#91;ua&#93;;
            ulsata2_pci_dev = pada->pci_dev;
    -       scsi_set_device&#40;shpnt, &ulsata2_pci_dev->dev&#41;;
    +       #if LINUX_VERSION_CODE >= KERNEL_VERSION&#40;2,6,13&#41;
    +               /* do nothing */
    +       #else
    +               scsi_set_device&#40;shpnt, &ulsata2_pci_dev->dev&#41;;
    +       #endif
     #elif LINUX_VERSION_CODE >= KERNEL_VERSION&#40;2,4,4&#41;
                    scsi_set_pci_device&#40;shpnt, ulsata2_pci_dev&#41;;
     #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)...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •