Skip to content

L
linux
Switch branch/tag
  1. 26 Nov, 2003 21 commits
  3. 25 Nov, 2003 3 commits
  5. 24 Nov, 2003 9 commits
  7. 23 Nov, 2003 3 commits
  9. 22 Nov, 2003 4 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
    • Mike Anderson's avatar
      [PATCH] scsi device ref count (update) · e4df9910
      Mike Anderson authored 
      This patch is against scsi-bugfixes-2.6. I updated it based on comments
received. It breaks up the reference count initialization for scsi_device
and restores calling slave_destroy for all scsi_devices configured or
not. I ran a small regression using the scsi_debug, aic7xxx, and qla2xxx
driver. I also had a debug patch for more verbose kobject cleanup and
patch for a badness check on atomic_dec going negative (previously
provided by Linus).

The object cleanup appears to being functioning correctly. I only saw
previously reported badness output:
	- Synchronizing SCSI cache fails on cleanup.
	- scsi_debug.c missing release (I believe Doug posted a patch)
	- aic7xxx warnings on rmmod due to ahc_platform_free calling
	  scsi_remove_host with ahc_list_lock held.


This patch splits the scsi device struct device register into init and
add. It also addresses memory leak issues of not calling slave_destroy
on scsi_devices that are not configured in.

Details:
* Make scsi_device_dev_release extern for scsi_scan to use in
alloc_sdev.
* Move scsi_free_sdev code to scsi_device_dev_release. Have
previous callers of scsi_free_sdev call slave_destroy plus put_device.
* Changed name of scsi_device_register to scsi_sysfs_add_sdev to
match host call and align with split struct device init.
* Move sdev_gendev device and class init to scsi_alloc_sdev.

Thu Nov 20 22:56:11 PST 2003

 drivers/scsi/scsi_priv.h  |    4 +-
 drivers/scsi/scsi_scan.c  |   63 +++++++++++++++++++++-------------------------
 drivers/scsi/scsi_sysfs.c |   58 ++++++++++++++++++++++--------------------
 3 files changed, 62 insertions(+), 63 deletions(-)
      e4df9910
    • Davide Libenzi's avatar
      [PATCH] More SiS interrupt routing · f6967f9a
      Davide Libenzi authored 
      It turns out that the SiS irq routing logic doesn't go by chipset
after all - it's just that some pirq entries are "legacy" numbers,
while others are raw offsets into PCI config space (and the legacy
numbers are more commonly used with the older chipsets, which
explains the correlations).

This simplifies the router code substantially.
      f6967f9a
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7