[PATCH] Support booting USB drives with a write protect switch enabled
At least some USB drives with a write protect switch (e.g. Netac U335) could report "MEDIUM NOT PRESENT" for a while if a write protect is enabled. Do not stop the initialization attempts after getting this, and the initialization will be successful - likely on a 2nd attempt. Signed-off-by: Mike Banon <mikebdp2 at gmail.com> --- Note: see a seabios.log at the attachments for a relevant part of SeaBIOS boot log with this patch applied and Netac U335 drive ("USB MSC Drive Netac OnlyDisk 1100") with a write protect switch enabled plugged into AMD Lenovo G505S coreboot'ed laptop. --- diff --git a/src/hw/blockcmd.c b/src/hw/blockcmd.c index 1f15081..109a8e4 100644 --- a/src/hw/blockcmd.c +++ b/src/hw/blockcmd.c @@ -168,7 +168,6 @@ scsi_is_ready(struct disk_op_s *op) // Sense succeeded. if (sense.asc == 0x3a) { /* MEDIUM NOT PRESENT */ dprintf(1, "Device reports MEDIUM NOT PRESENT\n"); - return -1; } if (sense.asc == 0x04 && sense.ascq == 0x01 && !in_progress) {
On Tue, Jun 04, 2019 at 09:07:44PM +0300, Mike Banon wrote:
At least some USB drives with a write protect switch (e.g. Netac U335) could report "MEDIUM NOT PRESENT" for a while if a write protect is enabled.
Broken hardware. Lovely.
Do not stop the initialization attempts after getting this, and the initialization will be successful - likely on a 2nd attempt.
That change may drastically increase boot time. If you have an empty cdrom drive connected to your machine seabios will poll the device for five seconds no matter what for no good reason instead of simply stopping because no cdrom is inserted. So, no. Not going to happen. We need something else. I have no good idea how to handle that without a blacklist of known-broken devices though ... cheers, Gerd
Gerd, thank you very much for a review. I'll test more, and - if it turns out that it always initializes successfully on a 2nd attempt without any extra sleeps (or maybe 3rd in some really rare not-observed-yet cases), I could modify this patch so that it will still "return;" but only after i.e. 3rd attempt is unsuccessful ---> reducing the wasted time to a couple of milliseconds or even less. Hopefully this patch would be more acceptable in such a version. cheers, Mike On Wed, Jun 5, 2019 at 10:46 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
On Tue, Jun 04, 2019 at 09:07:44PM +0300, Mike Banon wrote:
At least some USB drives with a write protect switch (e.g. Netac U335) could report "MEDIUM NOT PRESENT" for a while if a write protect is enabled.
Broken hardware. Lovely.
Do not stop the initialization attempts after getting this, and the initialization will be successful - likely on a 2nd attempt.
That change may drastically increase boot time. If you have an empty cdrom drive connected to your machine seabios will poll the device for five seconds no matter what for no good reason instead of simply stopping because no cdrom is inserted.
So, no. Not going to happen. We need something else. I have no good idea how to handle that without a blacklist of known-broken devices though ...
cheers, Gerd
Thank you, here's a new version of this patch with an updated commit message. By the way, I noticed that my both laptop's internal and USB external DVD drives never report "medium not present" even when there is no DVD inside, and are being displayed at SeaBIOS boot menu! Either this scsi check is working incorrectly, or indeed we live in a broken hardware world :P [PATCHv2] Support booting USB drives with a write protect switch enabled At least some USB drives with a write protect switch (e.g. Netac U335) could report "MEDIUM NOT PRESENT" for a while if a write protect is enabled. Instead of stopping the initialization attempts immediately, stop only after getting this report for 3 times, to ensure the succesful initialization of such a "broken hardware". Signed-off-by: Mike Banon <mikebdp2 at gmail.com> --- diff --git a/src/hw/blockcmd.c b/src/hw/blockcmd.c index 1f15081..6b6fea9 100644 --- a/src/hw/blockcmd.c +++ b/src/hw/blockcmd.c @@ -144,8 +144,9 @@ scsi_is_ready(struct disk_op_s *op) dprintf(6, "scsi_is_ready (drive=%p)\n", op->drive_fl); /* Retry TEST UNIT READY for 5 seconds unless MEDIUM NOT PRESENT is - * reported by the device. If the device reports "IN PROGRESS", + * reported by the device 3 times. If the device reports "IN PROGRESS", * 30 seconds is added. */ + int tries = 3; int in_progress = 0; u32 end = timer_calc(5000); for (;;) { @@ -167,8 +168,11 @@ scsi_is_ready(struct disk_op_s *op) // Sense succeeded. if (sense.asc == 0x3a) { /* MEDIUM NOT PRESENT */ - dprintf(1, "Device reports MEDIUM NOT PRESENT\n"); - return -1; + tries--; + dprintf(1, "Device reports MEDIUM NOT PRESENT - %d tries left\n", + tries); + if (!tries) + return -1; } if (sense.asc == 0x04 && sense.ascq == 0x01 && !in_progress) { On Wed, Jun 5, 2019 at 4:49 PM Mike Banon <mikebdp2@gmail.com> wrote:
Gerd, thank you very much for a review. I'll test more, and - if it turns out that it always initializes successfully on a 2nd attempt without any extra sleeps (or maybe 3rd in some really rare not-observed-yet cases), I could modify this patch so that it will still "return;" but only after i.e. 3rd attempt is unsuccessful ---> reducing the wasted time to a couple of milliseconds or even less. Hopefully this patch would be more acceptable in such a version.
cheers, Mike
On Wed, Jun 5, 2019 at 10:46 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
On Tue, Jun 04, 2019 at 09:07:44PM +0300, Mike Banon wrote:
At least some USB drives with a write protect switch (e.g. Netac U335) could report "MEDIUM NOT PRESENT" for a while if a write protect is enabled.
Broken hardware. Lovely.
Do not stop the initialization attempts after getting this, and the initialization will be successful - likely on a 2nd attempt.
That change may drastically increase boot time. If you have an empty cdrom drive connected to your machine seabios will poll the device for five seconds no matter what for no good reason instead of simply stopping because no cdrom is inserted.
So, no. Not going to happen. We need something else. I have no good idea how to handle that without a blacklist of known-broken devices though ...
cheers, Gerd
participants (2)
-
Gerd Hoffmann -
Mike Banon