1. 29 4月, 2007 11 次提交
  2. 20 4月, 2007 1 次提交
    • A
      pata_sis: Fix oops on boot · f3769e9d
      Alan Cox 提交于
      A small number of SiS setups require special handling (not many judging
      by how long this dumb bug survived). A couple of Fedora 7 devel testers
      hit an Oops on pata_sis loading which is caused by terminal confusion
      between chipset as 'the chipset we have found' and chipset as 'array
      iterator'
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      f3769e9d
  3. 04 4月, 2007 6 次提交
  4. 31 3月, 2007 1 次提交
  5. 28 3月, 2007 5 次提交
    • P
      ata: NCQ is broken on Maxtor 6L250S0 · 7acfaf30
      Paul Rolland 提交于
      With this applied, my machine has stopped all those painful messages.
      dmesg now says :
      
      root@riri:/Kernels# dmesg | grep LBA
      ata1.00: 490234752 sectors, multi 0: LBA48 NCQ (not used)
      ata2.00: 640 sectors, multi 1: LBA
      ata3.00: 490234752 sectors, multi 0: LBA48 NCQ (not used)
      Signed-off-by: NPaul Rolland <rol@as2917.net>
      Acked-by: NAlan Cox <alan@redhat.com>
      Cc: Jeff Garzik <jeff@garzik.org>
      Cc: Tejun Heo <htejun@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      7acfaf30
    • A
      pata_pdc202xx_old: LBA48 bug · 5e518810
      Alan Cox 提交于
      In LBA48 mode we have to help the controller to get anything to work. The
      chip provides a register giving word counts meant for ATAPI use which we
      can use. However we need to load the count in words not bytes..
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      5e518810
    • T
      libata: IDENTIFY backwards for drive side cable detection · 8c3c52a8
      Tejun Heo 提交于
      For drive side cable detection to work correctly, drives need to be
      identified backwards such that the slave device releases PDIAG- before
      the mater drive tries to detect cable type.  ata_bus_probe() was fixed
      by commit f31f0cc2 but the new EH path
      wasn't fixed.  This patch makes new EH path do IDENTIFY backwards.
      
      ata_dev_configure() for new devices are still performed master first.
      This is to keep the detection messages in forward order.
      Signed-off-by: NTejun Heo <htejun@gmail.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      8c3c52a8
    • C
      ahci.c: walkaround for SB600 SATA internal error issue · 55a61604
      Conke Hu 提交于
         There is a HW issue in ATI SB600 SATA that PxSERR.E should not be
      set on some conditions, for example, when there is no media in SATA
      CD/DVD drive or media is not ready, AHCI controller fails to execute
      ATAPI commands and reports PORT_IRQ_TF_ERR, but ATI SB600 SATA
      controller sets PxSERR.E at the
      same time, which is not necessary.
          This patch is just to ignore the INTERNAL ERROR in such case.
      Without this patch, ahci error handler will report many errors as
      below:
          ----------- cut from dmesg -----------
      ata9: soft resetting port
      ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
      ata9.00: configured for UDMA/33
      ata9: EH complete
      ata9.00: exception Emask 0x40 SAct 0x0 SErr 0x800 action 0x2
      ata9.00: (irq_stat 0x40000001)
      ata9.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0
              res 51/24:03:00:00:20/00:00:00:00:00/a0 Emask 0x40 (internal error)
      ata9: soft resetting port
      ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
      ata9.00: configured for UDMA/33
      ata9: EH complete
      ata9.00: exception Emask 0x40 SAct 0x0 SErr 0x800 action 0x2
      ata9.00: (irq_stat 0x40000001)
      ata9.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x43 data 12 in
              res 51/24:03:00:00:00/00:00:00:00:00/a0 Emask 0x40 (internal error)
          -------- end cut ---------
      Signed-off-by: NConke Hu <conke.hu@amd.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      55a61604
    • J
      [libata] Disable ACPI by default; fix namespace problems · d7d0dad6
      Jeff Garzik 提交于
      Not yet ready to turn on ATA ACPI by default, for either PATA or SATA.
      
      Also, rename the global-scope module parameter variable 'noacpi' to
      something more libata-specific, reducing the potential for namespace
      collision.
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      d7d0dad6
  6. 19 3月, 2007 7 次提交
  7. 15 3月, 2007 2 次提交
  8. 10 3月, 2007 1 次提交
  9. 09 3月, 2007 5 次提交
    • T
      libata: fix ata_host_release() free order · 1aa506e4
      Tejun Heo 提交于
      host->ops->host_stop() might access ports.  Free ports after
      host_stop.
      Signed-off-by: NTejun Heo <htejun@gmail.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      1aa506e4
    • R
      sata_nv: revert use of notifiers for now · 8ba5e4cb
      Robert Hancock 提交于
      Commit 721449bf added support for using the
      ADMA notifier bits to determine which commands to check for completion.
      However there have been reports that this causes command timeouts in certain
      cases. This is still being investigated. In addition, apparently the notifiers
      won't work if ADMA is disabled on the other port as a result of an ATAPI device
      being connected, and we don't handle this case properly.
      
      For now, just restore the previous behavior of checking all active commands
      to see if they are complete, without relying on the notifiers.
      Signed-off-by: NRobert Hancock <hancockr@shaw.ca>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      8ba5e4cb
    • P
      Fix simplex adapters with libata · 14d66ab7
      Petr Vandrovec 提交于
      Recently I got my hands on nVidia's MCP61 PM-AM board, and
      it contains IDE chip configured by BIOS with only primary
      channel enabled.  This confuses code which probes for
      device DMA capabilities - it gets 0x60 (happy duplex
      device) from primary channel BMDMA, but 0xFF (nobody here)
      from secondary channel BMDMA.  Due to this code then believes
      that chip is simplex.  I do not address this problem in
      my patch, as I'm not sure how to handle this.  Probably
      ata_pci_init_one should have bitmap of enabled/possible
      interfaces instead of their count, but it looks like
      quite intrusive change, and maybe we do not care - for device
      with only one channel simplex and regular DMA engines are
      same.
      
      But making device simplex pointed out that support for
      DMA on simplex devices is currently broken - ata_dev_xfermask
      tests whether device is simplex and if it is whether DMA
      engine was assigned to this port.  If not then it strips
      out DMA bits from device.  Problem is that code which assigns
      DMA engine to port in ata_set_mode first detect device
      mode and assigns DMA engine to channel only if some DMA
      capable device was found.
      
      And as xfermask stripped out DMA bits, host->simplex_claimed
      is always NULL with current implementation.
      
      By allowing DMA either if simplex_claimed is NULL or if it
      points to current port DMA can be finally used - it gets
      assigned to first port which contains any DMA capable
      device.
      
      Before:
      pata_amd 0000:00:06.0: version 0.2.8
      PCI: Setting latency timer of device 0000:00:06.0 to 64
      ata5: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001f000 irq 14
      ata6: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001f008 irq 15
      scsi4 : pata_amd
      ata5.00: ATAPI, max UDMA/66
      ata5.00: simplex DMA is claimed by other device, disabling DMA
      ata5.00: configured for PIO4
      scsi5 : pata_amd
      ata6: port disabled. ignoring.
      ata6: reset failed, giving up
      scsi 4:0:0:0: CD-ROM            ATAPI    DVD W  DH16W1P   LG12 PQ: 0 ANSI: 5
      
      After:
      pata_amd 0000:00:06.0: version 0.2.8
      PCI: Setting latency timer of device 0000:00:06.0 to 64
      ata5: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001f000 irq 14
      ata6: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001f008 irq 15
      scsi4 : pata_amd
      ata5.00: ATAPI, max UDMA/66
      ata5.00: configured for UDMA/33
      scsi5 : pata_amd
      ata6: port disabled. ignoring.
      ata6: reset failed, giving up
      scsi 4:0:0:0: CD-ROM            ATAPI    DVD W  DH16W1P   LG12 PQ: 0 ANSI: 5
      Signed-off-by: NPetr Vandrovec <petr@vandrovec.name>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      14d66ab7
    • A
      ata_piix: Remove ugly layering violation · 9a2eb709
      Alan Cox 提交于
      A while ago I modified the libata code so that drivers can return -ENOENT
      for unknown ports not fiddle with the EH flags and print stuff directly.
      Somewhere along the line ata_piix didn't get fully converted.
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      9a2eb709
    • A
      [PATCH] libata-acpi: Try and stop all the non PCI devices crashing · ca426635
      Alan Cox 提交于
      For 2.6.20 it mostly used to just not work, for 2.6.21-rc it crashes, this
      seems to be down to luck (bad or good). The libata-acpi code needs to
      avoid doing PCI work on non-PCI devices. This is one hack although it's
      not pretty and perhaps there is a "right" way to check if a struct device
      * is PCI ?
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ca426635
  10. 06 3月, 2007 1 次提交
    • B
      pata_pdc202xx_old: fix data corruption and other problems · 63ed7101
      Bartlomiej Zolnierkiewicz 提交于
      Fix wrong "port" calculations in pdc202xx_{configure_piomode,set_dmamode}()
      They were broken for all configurations except one (master device on primary
      channel, no other devices) and as a result device settings + PIO/DMA timings
      were being programmed into the wrong PCI registers.  This could result in
      a large variety of problems including data corruption, hangs etc. (depending
      on devices used and your luck :-).
      
        ap->port_no   ap->devno   used PCI registers   correct PCI registers
                  0           0            0x60-0x62               0x60-0x62
                  0           1            0x62-0x64               0x64-0x66
                  1           0            0x64-0x66               0x68-0x6a
                  1           1            0x66-0x68               0x6c-0x6e
      
      Also forward port recent fixes from drivers/ide pdc202xx_old driver:
      
      * fix XFER_MW_DMA0 timings (they were overclocked, use the official ones)
      
      * fix bitmasks for clearing bits of register B:
      
        - when programming DMA mode bit 0x10 of register B was cleared which
          resulted in overclocked PIO timing setting (iff PIO0 was used)
      
        - when programming PIO mode bits 0x18 weren't cleared so suboptimal
          timings were used for PIO1-4 if PIO0 was previously set (bit 0x10)
          and for PIO0/3/4 if PIO1/2 was previously set (bit 0x08)
      
      and finally bump driver version.
      Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      63ed7101