Linux.com

rajashek

rajashek

  • Linux.com Member
  • Posts: 4
  • Member Since: 01 Feb 13
  • Last Logged In: 30 Jul 13

Latest Posts

Posted by
Topic
Post Preview
Posted
  • rajashek
    Linux driver infrastructure tools
    Hello, Greetings...! Can anyone uses Linux driver infrastructure tools ? 1. Code checker for Linux ? (I knew "Prefast" for Windows, but I dont know for Linux) 2. Boundary condition Linux driver checker (memory etc) ? (For Windows "Drv verifier") 3. Code Coverage (% code that was executed) for Linux ? (I knew for Windows "Testwell CTC++" 4. Error inject for Linux ? (For Windows "Drv verifier") Kindly help! Thanks & Regards, Mahesh
    Link to this post 30 Jul 13

    Hello,

    Greetings...!

    Can anyone uses Linux driver infrastructure tools ?

    1. Code checker for Linux ? (I knew "Prefast" for Windows, but I dont know for Linux)
    2. Boundary condition Linux driver checker (memory etc) ? (For Windows "Drv verifier")
    3. Code Coverage (% code that was executed) for Linux ? (I knew for Windows "Testwell CTC++"
    4. Error inject for Linux ? (For Windows "Drv verifier")

    Kindly help!

    Thanks & Regards,
    Mahesh

  • rajashek
    Query on linux libsas/libata releases/updates
    Hello, Greetings..! We have a driver which is connected with SCSI upper layers libsas/libata drivers. When we use the updated libsas/libata libraries like those in RHEL 6.3, medium error handling works fine. When we use kernels with older libsas/libata libraries with medium error (details below) the system crashes My question is: - Is there a recommend way to release our driver with these updated libraries? - If there are none, is there an easy solution for customers’ to update only these components instead of the entire kernel? Thanks in advance for your help! Mahesh ==================================================== Details of the issue: 1. If a target/drive has medium error and IO has been aborted, during this phase LibATA has some issues in this Error Handling Path and system eventually crashes. a. This is very consistent with SUSE11SP2 (3.0.13) Kernel b. This very same issue with Debian 6.0.3 till 6.0.6 c. With RHEL6.3 everything is working fine, since the Libsas/LibATA changes are back-ported from 3.4 kernels to their RHEL6.3 Kernel (2.6.32-279). Sequence: - Medium Error Reported by drive for an IO either Read/Write_FPDMA (NCQ Command) - Firmware Raise NCQ Event - Holds the IO expects RLE and puts the drive into Error State - Internally driver is issuing RLE because we don’t have the IO Context - FW/Drive processes RLE - Driver Receives RLE Response - Issues Abort ALL (as per SATA Spec) - FW releases all IO’s by completing as IO Aborted - Driver Completes these to Midlayer In the Successful case the sequence follows: - Receives RLE, but driver is faking it now - then receives Hard-Resetting Link - Domain Revalidation - Rediscover - IO’s Successfully restarted. In the Failure case the sequence follows: - System hangs
    Link to this post 11 Feb 13

    Hello,

    Greetings..!

    We have a driver which is connected with SCSI upper layers libsas/libata drivers. When we use the updated libsas/libata libraries like those in RHEL 6.3, medium error handling works fine. When we use kernels with older libsas/libata libraries with medium error (details below) the system crashes

    My question is:
    - Is there a recommend way to release our driver with these updated libraries?
    - If there are none, is there an easy solution for customers’ to update only these components instead of the entire kernel?

    Thanks in advance for your help!
    Mahesh

    ====================================================

    Details of the issue:
    1. If a target/drive has medium error and IO has been aborted, during this phase LibATA has some issues in this Error Handling Path and system eventually crashes.
    a. This is very consistent with SUSE11SP2 (3.0.13) Kernel
    b. This very same issue with Debian 6.0.3 till 6.0.6
    c. With RHEL6.3 everything is working fine, since the Libsas/LibATA changes are back-ported from 3.4 kernels to their RHEL6.3 Kernel (2.6.32-279).
    Sequence:
    - Medium Error Reported by drive for an IO either Read/Write_FPDMA (NCQ Command)
    - Firmware Raise NCQ Event
    - Holds the IO expects RLE and puts the drive into Error State
    - Internally driver is issuing RLE because we don’t have the IO Context
    - FW/Drive processes RLE
    - Driver Receives RLE Response
    - Issues Abort ALL (as per SATA Spec)
    - FW releases all IO’s by completing as IO Aborted
    - Driver Completes these to Midlayer

    In the Successful case the sequence follows:
    - Receives RLE, but driver is faking it now
    - then receives Hard-Resetting Link
    - Domain Revalidation
    - Rediscover
    - IO’s Successfully restarted.

    In the Failure case the sequence follows:
    - System hangs

  • rajashek
    Query on linux libsas/libata updates/releases
    Hello, Greetings..! We have a driver which is connected with SCSI upper layers libsas/libata drivers. When we use the updated libsas/libata libraries like those in RHEL 6.3, medium error handling works fine. When we use kernels with older libsas/libata libraries with medium error (details below) the system crashes My question is: - Is there a recommend way to release our driver with these updated libraries? - If there are none, is there an easy solution for customers’ to update only these components instead of the entire kernel? Thanks in advance for your help! Mahesh ==================================================== Details of the issue: 1. If a target/drive has medium error and IO has been aborted, during this phase LibATA has some issues in this Error Handling Path and system eventually crashes. a. This is very consistent with SUSE11SP2 (3.0.13) Kernel b. This very same issue with Debian 6.0.3 till 6.0.6 c. With RHEL6.3 everything is working fine, since the Libsas/LibATA changes are back-ported from 3.4 kernels to their RHEL6.3 Kernel (2.6.32-279). Sequence: - Medium Error Reported by drive for an IO either Read/Write_FPDMA (NCQ Command) - Firmware Raise NCQ Event - Holds the IO expects RLE and puts the drive into Error State - Internally driver is issuing RLE because we don’t have the IO Context - FW/Drive processes RLE - Driver Receives RLE Response - Issues Abort ALL (as per SATA Spec) - FW releases all IO’s by completing as IO Aborted - Driver Completes these to Midlayer In the Successful case the sequence follows: - Receives RLE, but driver is faking it now - then receives Hard-Resetting Link - Domain Revalidation - Rediscover - IO’s Successfully restarted. In the Failure case the sequence follows: - System hangs
    Link to this post 07 Feb 13

    Hello,

    Greetings..!

    We have a driver which is connected with SCSI upper layers libsas/libata drivers. When we use the updated libsas/libata libraries like those in RHEL 6.3, medium error handling works fine. When we use kernels with older libsas/libata libraries with medium error (details below) the system crashes

    My question is:
    - Is there a recommend way to release our driver with these updated libraries?
    - If there are none, is there an easy solution for customers’ to update only these components instead of the entire kernel?

    Thanks in advance for your help!
    Mahesh

    ====================================================

    Details of the issue:
    1. If a target/drive has medium error and IO has been aborted, during this phase LibATA has some issues in this Error Handling Path and system eventually crashes.
    a. This is very consistent with SUSE11SP2 (3.0.13) Kernel
    b. This very same issue with Debian 6.0.3 till 6.0.6
    c. With RHEL6.3 everything is working fine, since the Libsas/LibATA changes are back-ported from 3.4 kernels to their RHEL6.3 Kernel (2.6.32-279).
    Sequence:
    - Medium Error Reported by drive for an IO either Read/Write_FPDMA (NCQ Command)
    - Firmware Raise NCQ Event
    - Holds the IO expects RLE and puts the drive into Error State
    - Internally driver is issuing RLE because we don’t have the IO Context
    - FW/Drive processes RLE
    - Driver Receives RLE Response
    - Issues Abort ALL (as per SATA Spec)
    - FW releases all IO’s by completing as IO Aborted
    - Driver Completes these to Midlayer

    In the Successful case the sequence follows:
    - Receives RLE, but driver is faking it now
    - then receives Hard-Resetting Link
    - Domain Revalidation
    - Rediscover
    - IO’s Successfully restarted.

    In the Failure case the sequence follows:
    - System hangs

  • rajashek
    Query on 4K sector boot support
    Hi, Greetings...! Can anyone please let me know which of the following recent released Linux distributions support OS installations on 4K sectors drives? 1. RHEL /CentOS 2. Fedora 3. Ubuntu 4. Debian Thanks, Mahesh
    Link to this post 01 Feb 13

    Hi,

    Greetings...!

    Can anyone please let me know which of the following recent released Linux distributions support OS installations on 4K sectors drives?

    1. RHEL /CentOS
    2. Fedora
    3. Ubuntu
    4. Debian

    Thanks,
    Mahesh

Who we are ?

The Linux Foundation is a non-profit consortium dedicated to the growth of Linux.

More About the foundation...

Frequent Questions

Join / Linux Training / Board