There's no need to wait for disk spin-up for USB SSD devices. This
patch allow the SSD to skip waiting disk spin-up by passing sd_mod.ssd=1
during boot-up.
If there's a better way to handle this, please share.
Thanks,
Jeff
--- linux/drivers/scsi/sd.c 2015-05-25 07:29:44.000000000 +0800
+++ linux/drivers/scsi/sd.c 2015-06-19 22:17:35.000000000 +0800
@@ -92,6 +92,9 @@
MODULE_ALIAS_SCSI_DEVICE(TYPE_MOD);
MODULE_ALIAS_SCSI_DEVICE(TYPE_RBC);
+static int ssd = 0;
+module_param(ssd, int, 0);
+
#if !defined(CONFIG_DEBUG_BLOCK_EXT_DEVT)
#define SD_MINORS 16
#else
@@ -2738,7 +2741,9 @@
goto out;
}
- sd_spinup_disk(sdkp);
+ sd_printk(KERN_NOTICE, sdkp, "ssd %s\n", ssd == 0 ? "off" : "on");
+ if(!ssd)
+ sd_spinup_disk(sdkp);
/*
* Without media there is no reason to ask; moreover, some devices
On Mon, Jun 22, 2015 at 03:25:29PM +0800, Jeff Chua wrote:
>
> There's no need to wait for disk spin-up for USB SSD devices. This patch
> allow the SSD to skip waiting disk spin-up by passing sd_mod.ssd=1 during
> boot-up.
>
> If there's a better way to handle this, please share.
Module parameters are never a solution for a device-specific property,
sorry.
greg k-h
On Mon, Jun 22, 2015 at 11:36 PM, Greg Kroah-Hartman
<[email protected]> wrote:
> On Mon, Jun 22, 2015 at 03:25:29PM +0800, Jeff Chua wrote:
>>
>> There's no need to wait for disk spin-up for USB SSD devices. This patch
>> allow the SSD to skip waiting disk spin-up by passing sd_mod.ssd=1 during
>> boot-up.
>>
>> If there's a better way to handle this, please share.
>
> Module parameters are never a solution for a device-specific property,
> sorry.
Greg,
SSD is coming mainstream and it doesn't make sense wasting time
spinning up "disk" ...
Jeff.
Hi,
[proper In-Reply-To trail missing since lkml.org now fails to provide it]
> On Mon, Jun 22, 2015 at 11:36 PM, Greg Kroah-Hartman
> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > On Mon, Jun 22, 2015 at 03:25:29PM +0800, Jeff Chua wrote:
> >>
> >> There's no need to wait for disk spin-up for USB SSD devices. This
> >> patch
> >> allow the SSD to skip waiting disk spin-up by passing sd_mod.ssd=1
> >> during
> >> boot-up.
> >>
> >> If there's a better way to handle this, please share.
> >
> > Module parameters are never a solution for a device-specific property,
> > sorry.
This statement, while somewhat harsh, seems about correct,
from a data attribute structure/organization POV.
>
> Greg,
>
> SSD is coming mainstream and it doesn't make sense wasting time
> spinning up "disk" ...
...which probably is not truly being achieved
by providing a *custom* kernel parameter
which does apply to only those disk instances
which some users *specifically* care about.
Some things come to mind:
- at this scope, generally spoken
one shouldn't be concerned with whether "we are SSD",
but rather whether "we (do not) need spinup"
(which might apply to a ton of different SCSI-based storage devices,
even some SAN-based platter-based ones)
*This* is what this is about
(and this could then have been reflected in kernel parameter naming)
- AFAIR SCSI mode info pages might contain hints
as to whether a disk is "rotating"
(but possibly these are not fully reliably accessible pre-spinup,
and mode info page content probably is unreliable, too)
- projects such as smartmontools might be able to provide some hints
as to how to reliably detect *certain* non-rotating types (i.e., SSD)
- the kernel must already have some mechanisms to discern between (non-)platters
(e.g. perhaps for knowing whether to support SSD TRIM command)
- if we want to avoid doing spinup handling (I guess we do),
then that handling should be implemented *within* the function
that is doing that (sd_spinup_disk(),
or perhaps an outer wrapper of it, sd_try_spinup_disk())
rather than at one specific callsite of that function only
(think sd_spinup_disk() *will* be allowed to "pretend" a "success" result
for all storage types which simply do not need spinup)
- finally, it might be questionable *why* (whether) at certain points
we currently need (decide) to do spinup requests -
I guess it's in order to ensure in advance
that the disk will be ready once it actually will be needed, or so
Thank you very much for having come up with this issue & HTH,
Andreas Mohr
On Tue, Jun 23, 2015 at 5:02 PM, Jeff Chua <[email protected]> wrote:
> On Mon, Jun 22, 2015 at 11:36 PM, Greg Kroah-Hartman
> <[email protected]> wrote:
>> On Mon, Jun 22, 2015 at 03:25:29PM +0800, Jeff Chua wrote:
>>>
>>> There's no need to wait for disk spin-up for USB SSD devices. This patch
>>> allow the SSD to skip waiting disk spin-up by passing sd_mod.ssd=1 during
>>> boot-up.
>>>
>>> If there's a better way to handle this, please share.
>>
>> Module parameters are never a solution for a device-specific property,
>> sorry.
>
> Greg,
>
> SSD is coming mainstream and it doesn't make sense wasting time
> spinning up "disk" ...
I don't think Greg disputes that. He just objects to the solution (a
module parameter) you proposed. I'd guess that detecting that we're
talking to an SSD and then skipping the wait would make more sense, if
at all possible.
Frans
You might want to grep for QUEUE_FLAG_NONROT or queue_nonrot_entry...
Regards,
Marc
P.S: sent from mobile, might be short.
Am 23. Juni 2015 17:02:22 MESZ, schrieb Jeff Chua <[email protected]>:
>On Mon, Jun 22, 2015 at 11:36 PM, Greg Kroah-Hartman
><[email protected]> wrote:
>> On Mon, Jun 22, 2015 at 03:25:29PM +0800, Jeff Chua wrote:
>>>
>>> There's no need to wait for disk spin-up for USB SSD devices. This
>patch
>>> allow the SSD to skip waiting disk spin-up by passing sd_mod.ssd=1
>during
>>> boot-up.
>>>
>>> If there's a better way to handle this, please share.
>>
>> Module parameters are never a solution for a device-specific
>property,
>> sorry.
>
>Greg,
>
>SSD is coming mainstream and it doesn't make sense wasting time
>spinning up "disk" ...
>
>
>Jeff.
>--
>To unsubscribe from this list: send the line "unsubscribe linux-kernel"
>in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
Am Dienstag, 23. Juni 2015, 20:26:12 schriebst Du:
> Hi,
Hi,
> [proper In-Reply-To trail missing since lkml.org now fails to provide it]
[…]
> > Greg,
> >
> > SSD is coming mainstream and it doesn't make sense wasting time
> > spinning up "disk" ...
>
> ...which probably is not truly being achieved
> by providing a *custom* kernel parameter
> which does apply to only those disk instances
> which some users *specifically* care about.
>
> Some things come to mind:
>
> - at this scope, generally spoken
> one shouldn't be concerned with whether "we are SSD",
> but rather whether "we (do not) need spinup"
> (which might apply to a ton of different SCSI-based storage devices,
> even some SAN-based platter-based ones)
> *This* is what this is about
> (and this could then have been reflected in kernel parameter naming)
[…]
> - the kernel must already have some mechanisms to discern between
> (non-)platters (e.g. perhaps for knowing whether to support SSD TRIM
> command)
Yep, for the first SSD in this laptop:
merkaba:/sys> cat
./devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sda/queue/rotational
0
[…]
Thanks,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
On Wed, Jun 24, 2015 at 2:55 AM, Martin Steigerwald <[email protected]> wrote:
> Am Dienstag, 23. Juni 2015, 20:26:12 schriebst Du:
>> Hi,
>
> Hi,
>
>> [proper In-Reply-To trail missing since lkml.org now fails to provide it]
> […]
>> > Greg,
>> >
>> > SSD is coming mainstream and it doesn't make sense wasting time
>> > spinning up "disk" ...
>>
>> ...which probably is not truly being achieved
>> by providing a *custom* kernel parameter
>> which does apply to only those disk instances
>> which some users *specifically* care about.
>>
>> Some things come to mind:
>>
>> - at this scope, generally spoken
>> one shouldn't be concerned with whether "we are SSD",
>> but rather whether "we (do not) need spinup"
>> (which might apply to a ton of different SCSI-based storage devices,
>> even some SAN-based platter-based ones)
>> *This* is what this is about
>> (and this could then have been reflected in kernel parameter naming)
> […]
>> - the kernel must already have some mechanisms to discern between
>> (non-)platters (e.g. perhaps for knowing whether to support SSD TRIM
>> command)
>
> Yep, for the first SSD in this laptop:
>
> merkaba:/sys> cat
> ./devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sda/queue/rotational
> 0
It seems "rotational" is not reporting the correct status on USB devices ...
# cat /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/queue/rotational
0
# cat sys/devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0/host10/target10:0:0/10:0:0:0/block/sdb/queue/rotational
1
# dmesg
scsi host11: uas
scsi 10:0:0:0: Direct-Access JMicron Generic 0114 PQ: 0 ANSI: 6
# cat /sys/kernel/debug/usb/devices
T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=5000 MxCh= 0
D: Ver= 3.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1
P: Vendor=152d ProdID=0567 Rev= 1.14
S: Manufacturer=JMicron
S: Product=USB to ATA/ATAPI Bridge
S: SerialNumber=3186E514500030
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 8mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=uas
Both sda and sdb have the same SSD model.
Jeff
On Thu, Jun 25, 2015 at 12:22:47AM +0800, Jeff Chua wrote:
> On Wed, Jun 24, 2015 at 2:55 AM, Martin Steigerwald <[email protected]> wrote:
> > Am Dienstag, 23. Juni 2015, 20:26:12 schriebst Du:
> >> Hi,
> >
> > Hi,
> >
> >> [proper In-Reply-To trail missing since lkml.org now fails to provide it]
> > […]
> >> > Greg,
> >> >
> >> > SSD is coming mainstream and it doesn't make sense wasting time
> >> > spinning up "disk" ...
> >>
> >> ...which probably is not truly being achieved
> >> by providing a *custom* kernel parameter
> >> which does apply to only those disk instances
> >> which some users *specifically* care about.
> >>
> >> Some things come to mind:
> >>
> >> - at this scope, generally spoken
> >> one shouldn't be concerned with whether "we are SSD",
> >> but rather whether "we (do not) need spinup"
> >> (which might apply to a ton of different SCSI-based storage devices,
> >> even some SAN-based platter-based ones)
> >> *This* is what this is about
> >> (and this could then have been reflected in kernel parameter naming)
> > […]
> >> - the kernel must already have some mechanisms to discern between
> >> (non-)platters (e.g. perhaps for knowing whether to support SSD TRIM
> >> command)
> >
> > Yep, for the first SSD in this laptop:
> >
> > merkaba:/sys> cat
> > ./devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sda/queue/rotational
> > 0
>
>
> It seems "rotational" is not reporting the correct status on USB devices ...
>
> # cat /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/queue/rotational
> 0
> # cat sys/devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0/host10/target10:0:0/10:0:0:0/block/sdb/queue/rotational
> 1
>
> # dmesg
> scsi host11: uas
> scsi 10:0:0:0: Direct-Access JMicron Generic 0114 PQ: 0 ANSI: 6
>
> # cat /sys/kernel/debug/usb/devices
> T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=5000 MxCh= 0
> D: Ver= 3.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1
> P: Vendor=152d ProdID=0567 Rev= 1.14
> S: Manufacturer=JMicron
> S: Product=USB to ATA/ATAPI Bridge
> S: SerialNumber=3186E514500030
> C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 8mA
> I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=uas
>
>
> Both sda and sdb have the same SSD model.
That's a bug in your USB bridge chip, odds are it is not reporting the
value properly. There's nothing the scsi core or USB stack can do about
this, sorry. Please complain to the hardware manufacturer.
greg k-h
On Thu, Jun 25, 2015 at 12:28 AM, Greg Kroah-Hartman
<[email protected]> wrote:
> On Thu, Jun 25, 2015 at 12:22:47AM +0800, Jeff Chua wrote:
>> Both sda and sdb have the same SSD model.
>
> That's a bug in your USB bridge chip, odds are it is not reporting the
> value properly. There's nothing the scsi core or USB stack can do about
> this, sorry. Please complain to the hardware manufacturer.
There are workaround boot cmdline parameters for other things ... any
chance to consider one to fix broken rotational option? I'm not sure
how many out there are broken, but I really would like a faster way to
access my USB SSD without waiting for the "disk spinup".
Thanks,
Jeff.
On Thu, Jun 25, 2015 at 07:55:45AM +0800, Jeff Chua wrote:
> On Thu, Jun 25, 2015 at 12:28 AM, Greg Kroah-Hartman
> <[email protected]> wrote:
> > On Thu, Jun 25, 2015 at 12:22:47AM +0800, Jeff Chua wrote:
>
> >> Both sda and sdb have the same SSD model.
> >
> > That's a bug in your USB bridge chip, odds are it is not reporting the
> > value properly. There's nothing the scsi core or USB stack can do about
> > this, sorry. Please complain to the hardware manufacturer.
>
> There are workaround boot cmdline parameters for other things ... any
> chance to consider one to fix broken rotational option? I'm not sure
> how many out there are broken, but I really would like a faster way to
> access my USB SSD without waiting for the "disk spinup".
Just like module paramaters, boot command lines are not for device
specific attributes, sorry. Again, please contact the manufacturer to
get this fixed. We can't add a quirk for this bridge because it would
not work if you really put a rotational disk behind it.
Given the cheap cost of these types of bridges, I recommend just getting
one that works.
Best of luck,
greg k-h
Am Mittwoch, 24. Juni 2015, 18:41:52 schrieb Greg Kroah-Hartman:
> On Thu, Jun 25, 2015 at 07:55:45AM +0800, Jeff Chua wrote:
> > On Thu, Jun 25, 2015 at 12:28 AM, Greg Kroah-Hartman
> >
> > <[email protected]> wrote:
> > > On Thu, Jun 25, 2015 at 12:22:47AM +0800, Jeff Chua wrote:
> > >> Both sda and sdb have the same SSD model.
> > >
> > > That's a bug in your USB bridge chip, odds are it is not reporting the
> > > value properly. There's nothing the scsi core or USB stack can do
> > > about
> > > this, sorry. Please complain to the hardware manufacturer.
> >
> > There are workaround boot cmdline parameters for other things ... any
> > chance to consider one to fix broken rotational option? I'm not sure
> > how many out there are broken, but I really would like a faster way to
> > access my USB SSD without waiting for the "disk spinup".
>
> Just like module paramaters, boot command lines are not for device
> specific attributes, sorry. Again, please contact the manufacturer to
> get this fixed. We can't add a quirk for this bridge because it would
> not work if you really put a rotational disk behind it.
How about a way to override it in sysfs directly during runtime just for a
device individually, like choosing an I/O scheduler for example?
> Given the cheap cost of these types of bridges, I recommend just getting
> one that works.
That is an option as well and may educate hardware manufacturers to look a
bit better at the quality of those devices (at least then Linux market share
in that market increases).
Thanks,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
On Thu, Jun 25, 2015 at 2:08 PM, Martin Steigerwald <[email protected]> wrote:
> Am Mittwoch, 24. Juni 2015, 18:41:52 schrieb Greg Kroah-Hartman:
>> On Thu, Jun 25, 2015 at 07:55:45AM +0800, Jeff Chua wrote:
>> > On Thu, Jun 25, 2015 at 12:28 AM, Greg Kroah-Hartman
>> >
>> > <[email protected]> wrote:
>> > > On Thu, Jun 25, 2015 at 12:22:47AM +0800, Jeff Chua wrote:
>> > >> Both sda and sdb have the same SSD model.
>> > >
>> > > That's a bug in your USB bridge chip, odds are it is not reporting the
>> > > value properly. There's nothing the scsi core or USB stack can do
>> > > about
>> > > this, sorry. Please complain to the hardware manufacturer.
>> >
>> > There are workaround boot cmdline parameters for other things ... any
>> > chance to consider one to fix broken rotational option? I'm not sure
>> > how many out there are broken, but I really would like a faster way to
>> > access my USB SSD without waiting for the "disk spinup".
>>
>> Just like module paramaters, boot command lines are not for device
>> specific attributes, sorry. Again, please contact the manufacturer to
>> get this fixed. We can't add a quirk for this bridge because it would
>> not work if you really put a rotational disk behind it.
>
> How about a way to override it in sysfs directly during runtime just for a
> device individually, like choosing an I/O scheduler for example?
>
>> Given the cheap cost of these types of bridges, I recommend just getting
>> one that works.
>
> That is an option as well and may educate hardware manufacturers to look a
> bit better at the quality of those devices (at least then Linux market share
> in that market increases).
I just needed something. "throwing" those cheap USB3 ... like I've a
bunch of them. It's just a waste... and they are perfectly fast "uas"
interfaces!
Thanks,
Jeff.
On Mon, 22 Jun 2015, Jeff Chua wrote:
> There's no need to wait for disk spin-up for USB SSD devices. This patch
No, you have to, instead, wait for SSD firmware startup.
And looking at the contents of sd_spinup_disk(), I don't think it is safe to
just skip it, either. It would be be better to call it sd_start_device()...
sd_spinup_disk() should be really fast on anything that properly implements
TEST_UNIT_READY and returns "ok, I am ready" when it doesn't need further
waits or START_STOP, etc...
Anyway, if you get to see the "Spinning up disk..." printk, your unit did
not report it was ready, and sd_spinup_disk tried to issue a START_STOP
command to signal it to get ready for real work.
There's at least one msleep(1000) in the START_STOP path, though.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Thu, 2015-06-25 at 13:21 -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 22 Jun 2015, Jeff Chua wrote:
> > There's no need to wait for disk spin-up for USB SSD devices. This patch
>
> No, you have to, instead, wait for SSD firmware startup.
>
> And looking at the contents of sd_spinup_disk(), I don't think it is safe to
> just skip it, either. It would be be better to call it sd_start_device()...
>
> sd_spinup_disk() should be really fast on anything that properly implements
> TEST_UNIT_READY and returns "ok, I am ready" when it doesn't need further
> waits or START_STOP, etc...
>
> Anyway, if you get to see the "Spinning up disk..." printk, your unit did
> not report it was ready, and sd_spinup_disk tried to issue a START_STOP
> command to signal it to get ready for real work.
>
> There's at least one msleep(1000) in the START_STOP path, though.
It might be good to change the msleep(1000) there
to a shorter value like 100ms (or maybe less).
Perhaps something like this:
(with miscellaneous neatening)
o Remove unnecessary '.' continuation printk on delays
o Remove trailing whitespace
o Neaten whitespace and alignment
o Convert int spintime to bool and move for better alignment
o Remove "only do this at boot time" comment
o Remove unnecessary memset casts
o Move int retries declaration to inner loop
---
drivers/scsi/sd.c | 39 +++++++++++++++++----------------------
1 file changed, 17 insertions(+), 22 deletions(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 3b2fcb4..c59ed65 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -1744,22 +1744,20 @@ static void
sd_spinup_disk(struct scsi_disk *sdkp)
{
unsigned char cmd[10];
+ bool spintime = false;
unsigned long spintime_expire = 0;
- int retries, spintime;
unsigned int the_result;
struct scsi_sense_hdr sshdr;
int sense_valid = 0;
- spintime = 0;
-
- /* Spin up drives, as required. Only do this at boot time */
+ /* Spin up drives, as required. */
/* Spinup needs to be done for module loads too. */
do {
- retries = 0;
+ int retries = 0;
do {
cmd[0] = TEST_UNIT_READY;
- memset((void *) &cmd[1], 0, 9);
+ memset(&cmd[1], 0, 9);
the_result = scsi_execute_req(sdkp->device, cmd,
DMA_NONE, NULL, 0,
@@ -1777,15 +1775,15 @@ sd_spinup_disk(struct scsi_disk *sdkp)
if (the_result)
sense_valid = scsi_sense_valid(&sshdr);
retries++;
- } while (retries < 3 &&
+ } while (retries < 3 &&
(!scsi_status_is_good(the_result) ||
((driver_byte(the_result) & DRIVER_SENSE) &&
- sense_valid && sshdr.sense_key == UNIT_ATTENTION)));
+ sense_valid && sshdr.sense_key == UNIT_ATTENTION)));
if ((driver_byte(the_result) & DRIVER_SENSE) == 0) {
/* no sense, TUR either succeeded or failed
* with a status error */
- if(!spintime && !scsi_status_is_good(the_result)) {
+ if (!spintime && !scsi_status_is_good(the_result)) {
sd_print_result(sdkp, "Test Unit Ready failed",
the_result);
}
@@ -1812,7 +1810,7 @@ sd_spinup_disk(struct scsi_disk *sdkp)
sd_printk(KERN_NOTICE, sdkp, "Spinning up disk...");
cmd[0] = START_STOP;
cmd[1] = 1; /* Return immediately */
- memset((void *) &cmd[2], 0, 8);
+ memset(&cmd[2], 0, 8);
cmd[4] = 1; /* Start spin cycle */
if (sdkp->device->start_stop_pwr_cond)
cmd[4] |= 1 << 4;
@@ -1821,11 +1819,8 @@ sd_spinup_disk(struct scsi_disk *sdkp)
SD_TIMEOUT, SD_MAX_RETRIES,
NULL);
spintime_expire = jiffies + 100 * HZ;
- spintime = 1;
+ spintime = true;
}
- /* Wait 1 second for next try */
- msleep(1000);
- printk(".");
/*
* Wait for USB flash devices with slow firmware.
@@ -1833,24 +1828,25 @@ sd_spinup_disk(struct scsi_disk *sdkp)
* occur here. It's characteristic of these devices.
*/
} else if (sense_valid &&
- sshdr.sense_key == UNIT_ATTENTION &&
- sshdr.asc == 0x28) {
+ sshdr.sense_key == UNIT_ATTENTION &&
+ sshdr.asc == 0x28) {
if (!spintime) {
spintime_expire = jiffies + 5 * HZ;
- spintime = 1;
+ spintime = true;
}
- /* Wait 1 second for next try */
- msleep(1000);
} else {
/* we don't understand the sense code, so it's
* probably pointless to loop */
- if(!spintime) {
+ if (!spintime) {
sd_printk(KERN_NOTICE, sdkp, "Unit Not Ready\n");
sd_print_sense_hdr(sdkp, &sshdr);
}
break;
}
-
+
+ /* Wait a bit for next try */
+ msleep(100);
+
} while (spintime && time_before_eq(jiffies, spintime_expire));
if (spintime) {
@@ -1861,7 +1857,6 @@ sd_spinup_disk(struct scsi_disk *sdkp)
}
}
-
/*
* Determine whether disk supports Data Integrity Field.
*/