Problem with usb-storage and /dev/sd?

Problem with usb-storage and /dev/sd?

[DervishD]

    Hi all :)

    If I plug my MP3 player (USB), the usb-storage module assigns it
device /dev/sda, which is right because I have it configured as such
in my /etc/fstab. Well, another day, another boot and I plug my USB
memory stick, and usb-storage assigns it device /dev/sda, quite cool
because I have it configured as such in my /etc/fstab, too.

    The problem is that if I plug my USB memory, unplug it and plug
my MP3 player, it gets /dev/sdb this time, not /dev/sda. The mess is
even greater if I plug my card reader, which has four LUN's...

    I'm not using hotplug currently so... how can I make the USB
subsystem to assign always the same /dev/sd? entry to my USB Mass
storage devices? For example, I will assign /dev/sda to my MP3
player, no matter if it is the first or the last USB gadget plugged,
etc. I would like fixed assignations, not the current way of 'first
item plugged gets /dev/sda and you have to remove the module if you
want the next item to be placed in /dev/sda'. I've googled a bit
without any success :(

    Thanks a lot in advance :)

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...

Re: Problem with usb-storage and /dev/sd?

[Tomasz Torcz]

[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]

On Wed, Aug 10, 2005 at 09:22:43PM +0200, DervishD wrote:
>     If I plug my MP3 player (USB), the usb-storage module assigns it
> device /dev/sda, which is right because I have it configured as such
> in my /etc/fstab. Well, another day, another boot and I plug my USB
> memory stick, and usb-storage assigns it device /dev/sda, quite cool
> because I have it configured as such in my /etc/fstab, too.
> 
>     The problem is that if I plug my USB memory, unplug it and plug
> my MP3 player, it gets /dev/sdb this time, not /dev/sda. The mess is
> even greater if I plug my card reader, which has four LUN's...

 That's what udev is for. Example rule to give my memory stick
persistent name:

BUS="usb", SYSFS_serial="5B4B06010122", NAME="pendriveZDZ%n", GROUP="floppy", MODE="0662", RUN+= "/sbin/udev_run_hotplugd"

 Go figure how to udev-enable your distribution.

-- 
Tomasz Torcz               "Never underestimate the bandwidth of a station
zdzichu@irc.-nie.spam-.pl    wagon filled with backup tapes." -- Jim Gray


[-- Attachment #2: Type: application/pgp-signature, Size: 229 bytes --]

Re: Problem with usb-storage and /dev/sd?

[DervishD]

    Hi Tomasz :)

 * Tomasz Torcz <zdzichu@irc.pl> dixit:
> On Wed, Aug 10, 2005 at 09:22:43PM +0200, DervishD wrote:
> >     The problem is that if I plug my USB memory, unplug it and plug
> > my MP3 player, it gets /dev/sdb this time, not /dev/sda. The mess is
> > even greater if I plug my card reader, which has four LUN's...
>  That's what udev is for.

    I know, but I use a 2.4.x kernel (which I didn't mention in my
original message, sorry O:)), and udev needs a 2.6.x kernel, am I
wrong?

>  Go figure how to udev-enable your distribution.

    I have a do-it-yourself Linux box, so setting up udev is not much
of a problem as long as the kernel supports it. If udev doesn't use
any kernel magic (that is, it only uses /sbin/hotplug), how the heck
does it know which /dev/sd? the *kernel* assigned to my recently
plugged USB device? How can it influenciate which device is assigned
*by the kernel*? I assume that it needs some magic from the kernel
and so it only works for 2.6.x :???? In fact, if it uses sysfs, it
still needs a 2.6.x for that, am I wrong?

    I'll take a look anyway, thanks a lot for your message and help :)

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...

Re: Problem with usb-storage and /dev/sd?

[Greg KH]

On Thu, Aug 11, 2005 at 12:06:16AM +0200, DervishD wrote:
>     Hi Tomasz :)
> 
>  * Tomasz Torcz <zdzichu@irc.pl> dixit:
> > On Wed, Aug 10, 2005 at 09:22:43PM +0200, DervishD wrote:
> > >     The problem is that if I plug my USB memory, unplug it and plug
> > > my MP3 player, it gets /dev/sdb this time, not /dev/sda. The mess is
> > > even greater if I plug my card reader, which has four LUN's...
> >  That's what udev is for.
> 
>     I know, but I use a 2.4.x kernel (which I didn't mention in my
> original message, sorry O:)), and udev needs a 2.6.x kernel, am I
> wrong?

That is correct, udev needs 2.6.  So, with 2.4 you are on your own here,
sorry.

thanks,

greg k-h

Re: Problem with usb-storage and /dev/sd?

[DervishD]

    Hi Greg :)

 * Greg KH <greg@kroah.com> dixit:
> On Thu, Aug 11, 2005 at 12:06:16AM +0200, DervishD wrote:
> >  * Tomasz Torcz <zdzichu@irc.pl> dixit:
> > >  That's what udev is for.
> >     I know, but I use a 2.4.x kernel (which I didn't mention in my
> > original message, sorry O:)), and udev needs a 2.6.x kernel, am I
> > wrong?
> That is correct, udev needs 2.6.  So, with 2.4 you are on your own here,
> sorry.

    Any way of forcing usb-storage to assign a particular device to a
recently plugged USB gadget? Wait a minute: hotplug events *include*
the name of the assigned device, am I wrong? Then I can deal with the
issue...

    I'll post my solution to the list, if any ;)

    Thanks :)

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...

Re: Problem with usb-storage and /dev/sd?

[Pete Zaitcev]

On Wed, 10 Aug 2005 21:22:43 +0200, DervishD <lkml@dervishd.net> wrote:

>     I'm not using hotplug currently so... how can I make the USB
> subsystem to assign always the same /dev/sd? entry to my USB Mass
> storage devices? [...]

You cannot. Just mount by label or something... Better yet, install
something like Fedora Core 4, which uses HAL, and forget about it.
The fstab-sync takes care of the rest.

-- Pete

Re: Problem with usb-storage and /dev/sd?

[DervishD]

    Hi Pete :)

 * Pete Zaitcev <zaitcev@redhat.com> dixit:
> On Wed, 10 Aug 2005 21:22:43 +0200, DervishD <lkml@dervishd.net> wrote:
> >     I'm not using hotplug currently so... how can I make the USB
> > subsystem to assign always the same /dev/sd? entry to my USB Mass
> > storage devices? [...]
> You cannot. Just mount by label or something...

    Mounting by label won't work, the problem is the /dev entry,
which changes every time.

> Better yet, install something like Fedora Core 4, which uses HAL,
> and forget about it. The fstab-sync takes care of the rest.

    Oh no, thanks, I've already used Fedora and it only reinforced my
feeling about distros: I prefer my do-it-yourself box ;)

    Thanks :)))

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...

Re: Problem with usb-storage and /dev/sd?

[Horst von Brand]

DervishD <lkml@dervishd.net> wrote:
>  * Pete Zaitcev <zaitcev@redhat.com> dixit:
> > On Wed, 10 Aug 2005 21:22:43 +0200, DervishD <lkml@dervishd.net> wrote:
> > >     I'm not using hotplug currently so... how can I make the USB
> > > subsystem to assign always the same /dev/sd? entry to my USB Mass
> > > storage devices? [...]
> > You cannot. Just mount by label or something...

>     Mounting by label won't work, the problem is the /dev entry,
> which changes every time.

That's why you should mount by label...

> > Better yet, install something like Fedora Core 4, which uses HAL,
> > and forget about it. The fstab-sync takes care of the rest.
> 
>     Oh no, thanks, I've already used Fedora and it only reinforced my
> feeling about distros: I prefer my do-it-yourself box ;)

In Fedora rawhide it just works. I can't see how the knot you are tying
yourself into by diy is any better...
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: Problem with usb-storage and /dev/sd?

[Bodo Eggert]

Horst von Brand <vonbrand@inf.utfsm.cl> wrote:
> DervishD <lkml@dervishd.net> wrote:
>>  * Pete Zaitcev <zaitcev@redhat.com> dixit:
>> > On Wed, 10 Aug 2005 21:22:43 +0200, DervishD <lkml@dervishd.net> wrote:

>> > >     I'm not using hotplug currently so... how can I make the USB
>> > > subsystem to assign always the same /dev/sd? entry to my USB Mass
>> > > storage devices? [...]
>> > You cannot. Just mount by label or something...
> 
>>     Mounting by label won't work, the problem is the /dev entry,
>> which changes every time.
> 
> That's why you should mount by label...

Which label will a random USB stick have?
-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

Re: Problem with usb-storage and /dev/sd?

[Pete Zaitcev]

On Fri, 12 Aug 2005 12:49:28 +0200, Bodo Eggert <harvested.in.lkml@7eggert.dyndns.org> wrote:

> Which label will a random USB stick have?

GUID, I presume. Ask Andries Brouwer, he hacked on that, IIRC.
Actually msdos has on-disk format for user-settable labels in
the way analoguous to tune2fs -L label. I just do not know if
our implementation recognizes them.

-- Pete

Re: Problem with usb-storage and /dev/sd?

[DervishD]

    Hi Pete :)

 * Pete Zaitcev <zaitcev@redhat.com> dixit:
> > Which label will a random USB stick have?
> GUID, I presume. Ask Andries Brouwer, he hacked on that, IIRC.
> Actually msdos has on-disk format for user-settable labels in
> the way analoguous to tune2fs -L label. I just do not know if
> our implementation recognizes them.

    My vfat's in my MP3 player and the USB stick doesn't have a
label, at least not one usable by 'mount' (which only uses ext2/3
labels and xfs labels AFAIK).

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...

Re: Problem with usb-storage and /dev/sd?

[Bodo Eggert]

On Fri, 12 Aug 2005, Pete Zaitcev wrote:

> On Fri, 12 Aug 2005 12:49:28 +0200, Bodo Eggert <harvested.in.lkml@7eggert.dyndns.org> wrote:
> 
> > Which label will a random USB stick have?
> 
> GUID, I presume.

A global unique ID won't work out to make all USB mass storage devices
appear under a common mountpoint, especially if it is recreated while
"formating" it.

-- 
The enemy diversion you have been ignoring will be the main attack. 

Re: Problem with usb-storage and /dev/sd?

[Pete Zaitcev]

On Sat, 13 Aug 2005 12:06:16 +0200 (CEST), Bodo Eggert <7eggert@gmx.de> wrote:
> On Fri, 12 Aug 2005, Pete Zaitcev wrote:
> > On Fri, 12 Aug 2005 12:49:28 +0200, Bodo Eggert <harvested.in.lkml@7eggert.dyndns.org> wrote:
> > 
> > > Which label will a random USB stick have?
> > 
> > GUID, I presume.
> 
> A global unique ID won't work out to make all USB mass storage devices
> appear under a common mountpoint, especially if it is recreated while
> "formating" it.

That is correct, but not what Dervish wanted. He wanted to mount them
on separate pre-assigned mount points. If you want all of them to mount
on the same place, just use /dev/sda1!

-- Pete

Re: Problem with usb-storage and /dev/sd?

[DervishD]

    Hi Pete :)

 * Pete Zaitcev <zaitcev@redhat.com> dixit:
> > A global unique ID won't work out to make all USB mass storage devices
> > appear under a common mountpoint, especially if it is recreated while
> > "formating" it.
> That is correct, but not what Dervish wanted. He wanted to mount them
> on separate pre-assigned mount points. If you want all of them to mount
> on the same place, just use /dev/sda1!

    That's not possible. sd_mod will assign different devices for
different USB gadgets, and that's my problem in the first case!. If I
plug my USB-whatever, it gets assigned /dev/sda1 (for the first
partition, I mean). If I unplug it and, after that, I plug any other
USB device, it gets assigned /dev/sdb1, etc. Don't know if the
culprit is usb-storage or sd_mod :? The problem is that I cannot know
about which device was assigned (at least in 2.4.x) so I can modify
fstab or even mount it.

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...

Re: Problem with usb-storage and /dev/sd?

[Willy Tarreau]

Hi Raul,

On Sun, Aug 14, 2005 at 09:32:57AM +0200, DervishD wrote:
>     Hi Pete :)
> 
>  * Pete Zaitcev <zaitcev@redhat.com> dixit:
> > > A global unique ID won't work out to make all USB mass storage devices
> > > appear under a common mountpoint, especially if it is recreated while
> > > "formating" it.
> > That is correct, but not what Dervish wanted. He wanted to mount them
> > on separate pre-assigned mount points. If you want all of them to mount
> > on the same place, just use /dev/sda1!
> 
>     That's not possible. sd_mod will assign different devices for
> different USB gadgets, and that's my problem in the first case!. If I
> plug my USB-whatever, it gets assigned /dev/sda1 (for the first
> partition, I mean). If I unplug it and, after that, I plug any other
> USB device, it gets assigned /dev/sdb1, etc. Don't know if the
> culprit is usb-storage or sd_mod :? The problem is that I cannot know
> about which device was assigned (at least in 2.4.x) so I can modify
> fstab or even mount it.

I've been suffering from the same problem for a long time until I found
a patch from Erik Andersen which automatically unregisters the sd device
once you unplug the USB device. It has changed my life :-)

Here it is for 2.4. I even wonder why we would not put this into mainline,
since having orphan devices brings nothing but confusion.

Regards,
Willy

----

This patch has been in use locally for quite some time now and
makes working with USB and 1394 mass-storage devices in 2.4.x a
much less painful experience.  When devices are plugged in, they
are automagically connected up to the scsi subsystem without the
need to rescan all scsi busses or echo things into
/proc/scsi/scsi.  When devices are unplugged, they are
automagically removed from the scsi subsystem, instead of hanging
around registered but with no media actually present.

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Signed-off-by: Erik Andersen <andersen@codepoet.org>

--- orig/drivers/usb/storage/usb.c	Fri Sep 17 15:34:38 2004
+++ linux-2.4.27/drivers/usb/storage/usb.c	Fri Sep 17 15:34:38 2004
@@ -744,6 +744,11 @@
 		/* unlock the device pointers */
 		up(&(ss->dev_semaphore));
 
+		/* Try to re-connect ourselves to the SCSI subsystem */
+		if (scsi_add_single_device(ss->host, 0, 0, 0))
+		    printk(KERN_WARNING "Unable to connect USB device to the SCSI subsystem\n");
+		else
+		    printk(KERN_WARNING "USB device connected to the SCSI subsystem\n");
 	} else { 
 		/* New device -- allocate memory and initialize */
 		US_DEBUGP("New GUID " GUID_FORMAT "\n", GUID_ARGS(guid));
@@ -1057,6 +1062,12 @@
 	/* lock access to the device data structure */
 	down(&(ss->dev_semaphore));
 
+	/* Try to un-hook ourselves from the SCSI subsystem */
+	if (scsi_remove_single_device(ss->host, 0, 0, 0))
+	    printk(KERN_WARNING "Unable to disconnect USB device from the SCSI subsystem\n");
+	else
+	    printk(KERN_WARNING "USB device disconnected from the SCSI subsystem\n");
+
 	/* release the IRQ, if we have one */
 	if (ss->irq_urb) {
 		US_DEBUGP("-- releasing irq URB\n");
--- orig/drivers/ieee1394/sbp2.c	Fri Sep 17 15:34:38 2004
+++ linux-2.4.27/drivers/ieee1394/sbp2.c	Fri Sep 17 15:34:38 2004
@@ -231,7 +231,7 @@
  * enable this define to make use of it. This provides better hotplug
  * support. The mentioned patch is not part of the kernel proper though,
  * because it is considered somewhat of a hack. */
-//#define SBP2_USE_SCSI_ADDREM_HACK
+#define SBP2_USE_SCSI_ADDREM_HACK
 
 
 /*
--- orig/drivers/scsi/scsi_syms.c	Fri Sep 17 15:34:38 2004
+++ linux-2.4.27/drivers/scsi/scsi_syms.c	Fri Sep 17 15:34:38 2004
@@ -104,3 +104,9 @@
 extern int scsi_delete_timer(Scsi_Cmnd *);
 EXPORT_SYMBOL(scsi_add_timer);
 EXPORT_SYMBOL(scsi_delete_timer);
+
+/* Support for hot plugging and unplugging devices -- safe for
+ * ieee1394 or USB devices, but probably not for normal SCSI... */
+EXPORT_SYMBOL(scsi_add_single_device);
+EXPORT_SYMBOL(scsi_remove_single_device);
+
--- orig/drivers/scsi/hosts.h	Fri Sep 17 15:34:38 2004
+++ linux-2.4.27/drivers/scsi/hosts.h	Fri Sep 17 15:34:38 2004
@@ -535,6 +535,13 @@
 int scsi_register_device(struct Scsi_Device_Template * sdpnt);
 void scsi_deregister_device(struct Scsi_Device_Template * tpnt);
 
+/* Support for hot plugging and unplugging devices -- safe for
+ * ieee1394 or USB devices, but probably not for normal SCSI... */
+extern int scsi_add_single_device(struct Scsi_Host *shpnt,
+	int channel, int id, int lun);
+extern int scsi_remove_single_device(struct Scsi_Host *shpnt,
+	int channel, int id, int lun);
+
 /* These are used by loadable modules */
 extern int scsi_register_module(int, void *);
 extern int scsi_unregister_module(int, void *);
--- orig/drivers/scsi/scsi.c	Fri Sep 17 15:34:38 2004
+++ linux-2.4.27/drivers/scsi/scsi.c	Fri Sep 17 15:34:38 2004
@@ -1554,6 +1554,156 @@
     }
 }
 
+
+static DECLARE_MUTEX(scsi_host_internals_lock);
+/*
+ * Function:    scsi_add_single_device()
+ *
+ * Purpose:     Support for hotplugging SCSI devices.  This function
+ *              implements the actual functionality for
+ *                  echo "scsi add-single-device 0 1 2 3" >/proc/scsi/scsi
+ *
+ * Arguments:   shpnt   - pointer to the SCSI host structure
+ *              channel - channel of the device to add
+ *              id      - id of the device to add
+ *              lun     - lun of the device to add
+ *
+ * Returns:     0 on success or an error code
+ *
+ * Lock status: None needed.
+ *
+ * Notes:       This feature is probably unsafe for standard SCSI devices,
+ *              but is perfectly normal for things like ieee1394 or USB
+ *              drives since these busses are designed for hotplugging.
+ *              Use at your own risk....
+ */
+int scsi_add_single_device(struct Scsi_Host *shpnt, int channel,
+	int id, int lun)
+{
+	Scsi_Device *scd;
+
+	/* Do a bit of sanity checking */
+	if (shpnt==NULL) {
+		return  -ENXIO;
+	}
+
+	/* We call functions that can sleep, so use a semaphore to
+	 * avoid racing with scsi_remove_single_device().  We probably
+	 * need to also apply this lock to scsi_register*(),
+	 * scsi_unregister*(), sd_open(), sd_release() and anything
+	 * else that might be messing with with the Scsi_Host or other
+	 * fundamental data structures.  */
+	down(&scsi_host_internals_lock);
+
+	/* Check if they asked us to add an already existing device.
+	 * If so, ignore their misguided efforts. */
+	for (scd = shpnt->host_queue; scd; scd = scd->next) {
+		if ((scd->channel == channel && scd->id == id && scd->lun == lun)) {
+			break;
+		}
+	}
+	if (scd) {
+		up(&scsi_host_internals_lock);
+		return -ENOSYS;
+	}
+
+	scan_scsis(shpnt, 1, channel, id, lun);
+	up(&scsi_host_internals_lock);
+	return 0;
+}
+
+/*
+ * Function:    scsi_remove_single_device()
+ *
+ * Purpose:     Support for hot-unplugging SCSI devices.  This function
+ *              implements the actual functionality for
+ *                  echo "scsi remove-single-device 0 1 2 3" >/proc/scsi/scsi
+ *
+ * Arguments:   shpnt   - pointer to the SCSI host structure
+ *              channel - channel of the device to add
+ *              id      - id of the device to add
+ *              lun     - lun of the device to add
+ *
+ * Returns:     0 on success or an error code
+ *
+ * Lock status: None needed.
+ *
+ * Notes:       This feature is probably unsafe for standard SCSI devices,
+ *              but is perfectly normal for things like ieee1394 or USB
+ *              drives since these busses are designed for hotplugging.
+ *              Use at your own risk....
+ */
+int scsi_remove_single_device(struct Scsi_Host *shpnt, int channel,
+	int id, int lun)
+{
+	Scsi_Device *scd;
+	struct Scsi_Device_Template *SDTpnt;
+
+	/* Do a bit of sanity checking */
+	if (shpnt==NULL) {
+		return  -ENODEV;
+	}
+
+	/* We call functions that can sleep, so use a semaphore to
+	 * avoid racing with scsi_add_single_device().  We probably
+	 * need to also apply this lock to scsi_register*(),
+	 * scsi_unregister*(), sd_open(), sd_release() and anything
+	 * else that might be messing with with the Scsi_Host or other
+	 * fundamental data structures.  */
+	down(&scsi_host_internals_lock);
+
+	/* Make sure the specified device is in fact present */
+	for (scd = shpnt->host_queue; scd; scd = scd->next) {
+		if ((scd->channel == channel && scd->id == id && scd->lun == lun)) {
+			break;
+		}
+	}
+	if (scd==NULL) {
+		up(&scsi_host_internals_lock);
+		return -ENODEV;
+	}
+
+	/* See if the specified device is busy.  Doesn't this race with
+	 * sd_open(), sd_release() and similar?  Why don't they lock
+	 * things when they increment/decrement the access_count? */
+	if (scd->access_count) {
+		up(&scsi_host_internals_lock);
+		return -EBUSY;
+	}
+
+	SDTpnt = scsi_devicelist;
+	while (SDTpnt != NULL) {
+		if (SDTpnt->detach)
+			(*SDTpnt->detach) (scd);
+		SDTpnt = SDTpnt->next;
+	}
+
+	if (scd->attached == 0) {
+		/* Nobody is using this device, so we
+		 * can now free all command structures.  */
+		if (shpnt->hostt->revoke)
+			shpnt->hostt->revoke(scd);
+		devfs_unregister (scd->de);
+		scsi_release_commandblocks(scd);
+
+		/* Now we can remove the device structure */
+		if (scd->next != NULL)
+			scd->next->prev = scd->prev;
+
+		if (scd->prev != NULL)
+			scd->prev->next = scd->next;
+
+		if (shpnt->host_queue == scd) {
+			shpnt->host_queue = scd->next;
+		}
+		blk_cleanup_queue(&scd->request_queue);
+		kfree((char *) scd);
+	}
+
+	up(&scsi_host_internals_lock);
+	return 0;
+}
+
 #ifdef CONFIG_PROC_FS
 static int scsi_proc_info(char *buffer, char **start, off_t offset, int length)
 {
@@ -1606,8 +1756,6 @@
 static int proc_scsi_gen_write(struct file * file, const char * buf,
                               unsigned long length, void *data)
 {
-	struct Scsi_Device_Template *SDTpnt;
-	Scsi_Device *scd;
 	struct Scsi_Host *HBA_ptr;
 	char *p;
 	int host, channel, id, lun;
@@ -1722,13 +1870,12 @@
 	/*
 	 * Usage: echo "scsi add-single-device 0 1 2 3" >/proc/scsi/scsi
 	 * with  "0 1 2 3" replaced by your "Host Channel Id Lun".
-	 * Consider this feature BETA.
+	 *
+	 * Consider this feature pre-BETA.
+	 *
 	 *     CAUTION: This is not for hotplugging your peripherals. As
 	 *     SCSI was not designed for this you could damage your
-	 *     hardware !
-	 * However perhaps it is legal to switch on an
-	 * already connected device. It is perhaps not
-	 * guaranteed this device doesn't corrupt an ongoing data transfer.
+	 *     hardware and thoroughly confuse the SCSI subsystem.
 	 */
 	if (!strncmp("add-single-device", buffer + 5, 17)) {
 		p = buffer + 23;
@@ -1746,33 +1893,11 @@
 				break;
 			}
 		}
-		err = -ENXIO;
-		if (!HBA_ptr)
-			goto out;
-
-		for (scd = HBA_ptr->host_queue; scd; scd = scd->next) {
-			if ((scd->channel == channel
-			     && scd->id == id
-			     && scd->lun == lun)) {
-				break;
-			}
-		}
-
-		err = -ENOSYS;
-		if (scd)
-			goto out;	/* We do not yet support unplugging */
-
-		scan_scsis(HBA_ptr, 1, channel, id, lun);
-
-		/* FIXME (DB) This assumes that the queue_depth routines can be used
-		   in this context as well, while they were all designed to be
-		   called only once after the detect routine. (DB) */
-		/* queue_depth routine moved to inside scan_scsis(,1,,,) so
-		   it is called before build_commandblocks() */
-
-		err = length;
+		if ((err=scsi_add_single_device(HBA_ptr, channel, id, lun))==0)
+		    err = length;
 		goto out;
 	}
+
 	/*
 	 * Usage: echo "scsi remove-single-device 0 1 2 3" >/proc/scsi/scsi
 	 * with  "0 1 2 3" replaced by your "Host Channel Id Lun".
@@ -1782,7 +1907,6 @@
 	 *     CAUTION: This is not for hotplugging your peripherals. As
 	 *     SCSI was not designed for this you could damage your
 	 *     hardware and thoroughly confuse the SCSI subsystem.
-	 *
 	 */
 	else if (!strncmp("remove-single-device", buffer + 5, 20)) {
 		p = buffer + 26;
@@ -1798,58 +1922,8 @@
 				break;
 			}
 		}
-		err = -ENODEV;
-		if (!HBA_ptr)
-			goto out;
-
-		for (scd = HBA_ptr->host_queue; scd; scd = scd->next) {
-			if ((scd->channel == channel
-			     && scd->id == id
-			     && scd->lun == lun)) {
-				break;
-			}
-		}
-
-		if (scd == NULL)
-			goto out;	/* there is no such device attached */
-
-		err = -EBUSY;
-		if (scd->access_count)
-			goto out;
-
-		SDTpnt = scsi_devicelist;
-		while (SDTpnt != NULL) {
-			if (SDTpnt->detach)
-				(*SDTpnt->detach) (scd);
-			SDTpnt = SDTpnt->next;
-		}
-
-		if (scd->attached == 0) {
-			/*
-			 * Nobody is using this device any more.
-			 * Free all of the command structures.
-			 */
-                        if (HBA_ptr->hostt->revoke)
-                                HBA_ptr->hostt->revoke(scd);
-			devfs_unregister (scd->de);
-			scsi_release_commandblocks(scd);
-
-			/* Now we can remove the device structure */
-			if (scd->next != NULL)
-				scd->next->prev = scd->prev;
-
-			if (scd->prev != NULL)
-				scd->prev->next = scd->next;
-
-			if (HBA_ptr->host_queue == scd) {
-				HBA_ptr->host_queue = scd->next;
-			}
-			blk_cleanup_queue(&scd->request_queue);
-			kfree((char *) scd);
-		} else {
-			goto out;
-		}
-		err = 0;
+		err=scsi_remove_single_device(HBA_ptr, channel, id, lun);
+		goto out;
 	}
 out:
 	
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


> 
>     Raúl Núñez de Arenas Coronado
> 
> -- 
> Linux Registered User 88736 | http://www.dervishd.net
> http://www.pleyades.net & http://www.gotesdelluna.net
> It's my PC and I'll cry if I want to...
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Problem with usb-storage and /dev/sd?

[DervishD]

    Hi Willy :)

 * Willy Tarreau <willy@w.ods.org> dixit:
> >     That's not possible. sd_mod will assign different devices for
> > different USB gadgets, and that's my problem in the first case!. If I
> > plug my USB-whatever, it gets assigned /dev/sda1 (for the first
> > partition, I mean). If I unplug it and, after that, I plug any other
> > USB device, it gets assigned /dev/sdb1, etc. Don't know if the
> > culprit is usb-storage or sd_mod :? The problem is that I cannot know
> > about which device was assigned (at least in 2.4.x) so I can modify
> > fstab or even mount it.
> I've been suffering from the same problem for a long time until I found
> a patch from Erik Andersen which automatically unregisters the sd device
> once you unplug the USB device. It has changed my life :-)

    Thanks! Unfortunately, it solves only half of my problem. If I
plug *two* USB storage devices, the second will fail (well, it won't
be assigned the correct device). The perfect solution is to always
use the same dev entry for the same USB device, but I need sysfs for
that (AFAIK), just like udev does.
 
> Here it is for 2.4. I even wonder why we would not put this into mainline,
> since having orphan devices brings nothing but confusion.

    Don't know :????

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...