1. 17 Dec, 2003 1 commit
    • Jeff Garzik's avatar
      [libata promise] fix another ugly bug · 845937ba
      Jeff Garzik authored
      For the SX4, only one Host DMA (local DIMM) engine is on the hardware,
      while there is an ATA engine for each SATA port.  This means that
      Host DMA transactions must be queued.  When previously fixing this problem
      (the driver had previously assumed an HDMA engine per port), I stored
      the HDMA packet queue in a per-port data structure.
      
      This was incorrect:  this patch changes it to correctly use a
      per-host data structure, not a per-port structure.
      845937ba
  2. 16 Dec, 2003 3 commits
  3. 05 Dec, 2003 2 commits
    • Jeff Garzik's avatar
      [libata promise] Properly initialize DIMM, on SX4 · f143781b
      Jeff Garzik authored
      On-board DIMM should be sized and initialized by the driver.  Previously,
      a single DIMM size was simply (and incorrectly) assumed, and
      initialization was presumed to have been done by the card's BIOS.
      
      Contributed by Promise, updated by David Milburn @ Red Hat.
      f143781b
    • Jeff Garzik's avatar
      [libata] fix use-after-free · dbdb6f6f
      Jeff Garzik authored
      Fixes oops some were seeing on module unload.
      
      Caught by Jon Burgess.
      dbdb6f6f
  4. 30 Nov, 2003 2 commits
  5. 26 Nov, 2003 3 commits
    • Jeff Garzik's avatar
      [libata] Fix PDC20621: we only have one Host DMA engine, not one per port · b6248157
      Jeff Garzik authored
      Whoops.  So, we need to queue HDMA transactions internally.
      b6248157
    • Linus Torvalds's avatar
      Linux 2.6.0-test11 · e689bf58
      Linus Torvalds authored
      e689bf58
    • Ben Collins's avatar
      [PATCH] Lastminute IEEE-1394 fixes · 9b67c27b
      Ben Collins authored
      I've got a lot more changes than what's included here.  I've put this
      down to the bear minimum to get things working sanely.
      
      Mainly, I just want to get all the people hit by this a chance to use
      2.6.0 without having to get our tree. Changes itemized:
      
       - Fix deadlock possibility in csr.c:read_maps()
       - Fix kmalloc to use ATOMIC in highlevel.c.
       - s/in_interrupt/irqs_disabled/ in ieee1394_transactions.c to fix
         warnings when transactions occured.
       - Introduce a release callback for the host driver and use it correctly.
       - Reorganize the nodemgr probe so we do an initial scan to discover
         devices, check IRM/CycleMaster, then do a final full probe when things
         are kosher. Fixes a problem where device registration and hotplug
         would cause some serious problems when a bus reset was forced in the
         middle of the probe.
      9b67c27b
  6. 25 Nov, 2003 15 commits
  7. 24 Nov, 2003 9 commits
  8. 23 Nov, 2003 3 commits
  9. 22 Nov, 2003 2 commits
    • James Bottomley's avatar
      Updated state model for SCSI devices · 9b22a8fb
      James Bottomley authored
      I've been looking at enforcing lifetime phases for SCSI devices
      (primarily to try to get the mid layer to offload as much of the device
      creation and hotplug pieces as it can).
      
      I've hijacked the sdev_state field of the struct scsi_device (formerly
      this was a bitmap, now it becomes an enumerated state).
      
      I've also begun adding references sdev_gendev into the code to pin the
      scsi_device---initially in the queue function, but possibly this should
      also be done in the scsi_command_get/put, the idea being to prevent
      scsi_device freeing while there's still device activity.
      
      The object phases I identified are:
      
      1. SDEV_CREATED - we've just allocated the device.  It may respond to
      internally generated commands, but not to user ones (the user should
      actually have no way to access a device in this state, but just in
      case).
      
      2. SDEV_RUNNING - the device is fully operational
      
      3. SDEV_CANCEL - The device is cleanly shutting down.  It may respond to
      internally generated commands (for cancellation/recovery) only; all user
      commands are errored unless they have already been queued (QUEUE_FULL
      handling and the like).
      
      4. SDEV_DEL - The device is gone. *all* commands are errored out.
      
      Ordinarily, the device should move through all four phases from creation
      to destruction, but moving SDEV_RUNNING->SDEV_DEL because of surprise
      ejection should work.
      
      It's starting to look like the online flag should be absorbed into this
      (offlined devices move essentially to SDEV_CANCEL and could be
      reactivated by moving to SDEV_RUNNING).
      
      I haven't altered the similar bitmap model that scsi_host has, although
      this too should probably move to an enumerated state model.
      
      I've tested this by physically yanking a module out from underneath a
      running filesystem with no ill effects (other than a slew of I/O
      errors).
      
      The obvious problem is that this kills possible user error handling, but
      we don't do any of that yet.
      9b22a8fb
    • Jeff Garzik's avatar
      Merge redhat.com:/spare/repo/linux-2.5 · da7c7841
      Jeff Garzik authored
      into redhat.com:/spare/repo/libata-2.5
      da7c7841