My BIOS is setup to enable booting from USB devices. This works fine when a bootable device (like a thumb drive) is plugged in.
Yesterday, I accidently left in my firelite USB external data drive when I rebooted my machine.
The system tried to boot from the USB data drive and then hung with a flashing cursor. I assumed the BIOS would have inspected the USB drive, not found a bootable partition and then gone onto the next device listed in the BIOS setup screen. If not, I would have at least expected an error message (like when a not boot floppy is left in the drive) and not just a blinking cursor on a blank screen.
Am I incorrect? Should the BIOS just hang and not boot my machine just because I have a USB data device plugged in?
USB Boot Hang
-
irritated_user
- Legit Little One
- Posts: 1
- Joined: Mon Feb 09, 2009 7:03 am
Re: USB Boot Hang
I have the same problem with an Intel motherboard--D865GLC--and BIOSes BF86510A.86A.0071.P22 through …0077.P25.
In my case, the problem was partially resolved by killing USB 1.1.legacy support. In the BIOS under peripherals/USB or such [hopefully] you'll find 'USB 1.1 Legacy Support: Enable/Disable' (or similar). Normally this setting is 'Enabled' so just disable it.
Right, you now have no USB 1.1 legacy support, but this ought not be a major problem as most devices are now version 2. Suggestion: if you have any v1.1 USB devices (or simply as a reminder), put a note on your PC with words to the effect 'To run USB 1.1 devices re-enable USB 1.1 Support in BIOS etc. etc.'
There's little or no excuse for this s@#$ programming/hardware implementation, it's just shoddy workmanship of the first order. Instead of increasing the polling--waiting sufficient time--for the external USB device to become ready the port hardware is held off and cannot be initialized. The result is that the 'held-down' USB port hardware remains in that state which, in turn, locks up the support chip hardware. Moreover, no one has bothered to put error hooks or delay routines within the USB subsystem to resolve the problem.
I've never much liked USB as it's half-baked, and this is a typical example of its weakness. A more serious example comes with Windows' handling of very large USB drives--250GB-1TB etc. If you have a lot of data on these now-popular external 'USB' drives then ensure that your machine has plenty of reserve and don't do anything to run out of resources whilst the drive is being updated. That's to say: if the drive is being updated (written to) then DO NOT invoke/run any program that will temporarily rob the PC of resources during the HD write cycle--simply, USB is insufficient robust to handle these drives.
Very unfortunately, I have a number of drives whose MFT/directory info has been garbled with the loss of hundreds of gigabytes of data because Windows and USB/HD subsystem couldn't hack the pace.
Hope this note helps.
](./images/smilies/eusa_wall.gif "Brick wall")
In my case, the problem was partially resolved by killing USB 1.1.legacy support. In the BIOS under peripherals/USB or such [hopefully] you'll find 'USB 1.1 Legacy Support: Enable/Disable' (or similar). Normally this setting is 'Enabled' so just disable it.
Right, you now have no USB 1.1 legacy support, but this ought not be a major problem as most devices are now version 2. Suggestion: if you have any v1.1 USB devices (or simply as a reminder), put a note on your PC with words to the effect 'To run USB 1.1 devices re-enable USB 1.1 Support in BIOS etc. etc.'
There's little or no excuse for this s@#$ programming/hardware implementation, it's just shoddy workmanship of the first order. Instead of increasing the polling--waiting sufficient time--for the external USB device to become ready the port hardware is held off and cannot be initialized. The result is that the 'held-down' USB port hardware remains in that state which, in turn, locks up the support chip hardware. Moreover, no one has bothered to put error hooks or delay routines within the USB subsystem to resolve the problem.
I've never much liked USB as it's half-baked, and this is a typical example of its weakness. A more serious example comes with Windows' handling of very large USB drives--250GB-1TB etc. If you have a lot of data on these now-popular external 'USB' drives then ensure that your machine has plenty of reserve and don't do anything to run out of resources whilst the drive is being updated. That's to say: if the drive is being updated (written to) then DO NOT invoke/run any program that will temporarily rob the PC of resources during the HD write cycle--simply, USB is insufficient robust to handle these drives.
Very unfortunately, I have a number of drives whose MFT/directory info has been garbled with the loss of hundreds of gigabytes of data because Windows and USB/HD subsystem couldn't hack the pace.
Hope this note helps.