1. 03 11月, 2007 1 次提交
    • T
      libata: increase 128 KB / cmd limit for ATAPI tape drives · f8d8e579
      Tony Battersby 提交于
      Commands sent to ATAPI tape drives via the SCSI generic (sg) driver are
      limited in the amount of data that they can transfer by the max_sectors
      value.  The max_sectors value is currently calculated according to the
      command set for disk drives, which doesn't apply to tape drives.  The
      default max_sectors value of 256 limits ATAPI tape drive commands to
      128 KB.  This patch against 2.6.24-rc1 increases the max_sectors value
      for tape drives to 65535, which permits tape drive commands to transfer
      just under 32 MB.
      
      Tested with a SuperMicro PDSME motherboard, AHCI, and a Sony SDX-570V
      SATA tape drive.
      
      Note that some of the chipset drivers also set their own max_sectors
      value, which may override the value set in libata-core.  I don't have
      any of these chipsets to test, so I didn't go messing with them.  Also,
      ATAPI devices other than tape drives may benefit from similar changes,
      but I have only tape drives and disk drives to test.
      Signed-off-by: NTony Battersby <tonyb@cybernetics.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      f8d8e579
  2. 02 11月, 2007 3 次提交
  3. 01 11月, 2007 2 次提交
  4. 31 10月, 2007 3 次提交
  5. 30 10月, 2007 6 次提交
  6. 29 10月, 2007 10 次提交
  7. 28 10月, 2007 2 次提交
  8. 26 10月, 2007 3 次提交
  9. 25 10月, 2007 8 次提交
  10. 24 10月, 2007 2 次提交
    • G
      [DCCP]: Convert Reset code into socket error number · d8ef2c29
      Gerrit Renker 提交于
      This adds support for converting the 11 currently defined Reset codes into system
      error numbers, which are stored in sk_err for further interpretation.
      
      This makes the externally visible API behaviour similar to TCP, since a client
      connecting to a non-existing port will experience ECONNREFUSED.
      
      * Code 0, Unspecified, is interpreted as non-error (0);
      * Code 1, Closed (normal termination), also maps into 0;
      * Code 2, Aborted, maps into "Connection reset by peer" (ECONNRESET);
      * Code 3, No Connection and
        Code 7, Connection Refused, map into "Connection refused" (ECONNREFUSED);
      * Code 4, Packet Error, maps into "No message of desired type" (ENOMSG);
      * Code 5, Option Error, maps into "Illegal byte sequence" (EILSEQ);
      * Code 6, Mandatory Error, maps into "Operation not supported on transport endpoint" (EOPNOTSUPP);
      * Code 8, Bad Service Code, maps into "Invalid request code" (EBADRQC);
      * Code 9, Too Busy, maps into "Too many users" (EUSERS);
      * Code 10, Bad Init Cookie, maps into "Invalid request descriptor" (EBADR);
      * Code 11, Aggression Penalty, maps into "Quota exceeded" (EDQUOT)
        which makes sense in terms of using more than the `fair share' of bandwidth.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Acked-by: NIan McDonald <ian.mcdonald@jandi.co.nz>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d8ef2c29
    • G
      [DCCP]: Retrieve packet sequence number for error reporting · fde20105
      Gerrit Renker 提交于
      This fixes a problem when analysing erroneous packets in dccp_v{4,6}_err:
      * dccp_hdr_seq currently takes an skb
      * however, the transport headers in the skb are shifted, due to the
        preceding IPv4/v6 header.
      Fixed for v4 and v6 by changing dccp_hdr_seq to take a struct dccp_hdr as
      argument. Verified that the correct sequence number is now reported in the
      error handler.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Acked-by: NIan McDonald <ian.mcdonald@jandi.co.nz>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      fde20105