Booting from USB thumbdrives, older drives boot, newer drives don't.

[Dave Frodin]

I'm a new subscriber to seabios.org so feel free to straighten me out if needed.

I've been debugging an problem we've been seeing with not being able to boot (Ubuntu specifically) off
of a variety of "newer" USB thumb drives. I've been specifically looking at an older/newer pair of
Sandisk Cruzer 4GB drives. I've been adding dprintf's to narrow down the problem to the blockcmd.c file.
The function scsi_init_drive() queries the USB device to determine stuff like vendor/device/size/etc.
Near the end of the function is a call to cdb_mode_sense_geom(&dop, &geomdata) to retrieve the info
related to cyl/head type stuff. On the older/working thumbdrive it returns zeroes for all of the values
that get used by the code. The newer/failing drive generates a "stall" on the USB bus, which it never
recovers from. The cdb_mode_sense_geom() function is sending a SCSI CDB Mode Sense (CMD=0x5A) to the device.

As a hack of a test, I removed the call to cdb_mode_sense_geom() and filled the buffer it should have returned
with zeroes and the failing thumbdrive now boots.

I have some searching I need to do to find out...
1) Is there a SCSI command to determine what protocols are supported?
2) Is there another SCSI command that might return similar required data?

Has anyone out there experienced similar booting difficulties?
Or does anyone have any recommendations on what approach I should take?

thanks,
Dave

Booting from USB thumbdrives, older drives boot, newer drives don't.

[Fred .]

Maybe run: lsusb -v
and compare the output for the difference SanDisk Cruzer USB devices
if they're identical or different.

On Thu, Mar 1, 2012 at 12:38 AM, Dave Frodin  wrote:
> I'm a new subscriber to seabios.org so feel free to straighten me out if needed.
>
> I've been debugging an problem we've been seeing with not being able to boot (Ubuntu specifically) off
> of a variety of "newer" USB thumb drives. I've been specifically looking at an older/newer pair of
> Sandisk Cruzer 4GB drives. I've been adding dprintf's to narrow down the problem to the blockcmd.c file.
> The function scsi_init_drive() queries the USB device to determine stuff like vendor/device/size/etc.
> Near the end of the function is a call to cdb_mode_sense_geom(&dop, &geomdata) to retrieve the info
> related to cyl/head type stuff. On the older/working thumbdrive it returns zeroes for all of the values
> that get used by the code. The newer/failing drive generates a "stall" on the USB bus, which it never
> recovers from. The cdb_mode_sense_geom() function is sending a SCSI CDB Mode Sense (CMD=0x5A) to the device.
>
> As a hack of a test, I removed the call to cdb_mode_sense_geom() and filled the buffer it should have returned
> with zeroes and the failing thumbdrive now boots.
>
> I have some searching I need to do to find out...
> Is there a SCSI command to determine what protocols are supported?
> Is there another SCSI command that might return similar required data?
>
> Has anyone out there experienced similar booting difficulties?
> Or does anyone have any recommendations on what approach I should take?
>
> thanks,
> Dave
>
> SeaBIOS mailing list
> [e-mail]
> http://www.seabios.org/mailman/listinfo/seabios

[Dave Frodin]

I have some addition results and questions.

I changed the "page mode" value that is in the struct sent in the 
MODE SENSE command from the existing value of 04h (rigid disk) to
05h (flexible disk). This change increased the number of passing
USB thumbdrives from 6 to 10. I'm testing with a total of 12 different
vendor/size drives.

The two failing drives still send a USB stall but the failure mode is
different. With the page mode type set to 4 the failure sequence was ...
   1) send MODE SENSE command to drive => device accepts data and ACKs
   2) device stalls the USB bus
With the page mode set to 5 the failure sequence is ...
   1) send MODE SENSE command to drive => device accepts data and ACKs
   2) device sends response => host accepts data and ACKs
   3) device stalls the USB bus
Also, the device only sends 6 bytes instead of the requested 27 bytes.

I'm planning on seeing if there isn't something missing prior to the mode
sense command tomorrow.

On a related topic, I have a copy of the "Indispensable PC Hardware" book
that lists the return values for the mode page 4 request. It list the cyc/head
data as follows...
 offset   value
==================
   2     cyl(msb)
   3     cyl
   4     cyl(lsb)
   5     heads

the struct in the blockcmd.h file shows...
  struct cdbres_mode_sense_geom {
    u8 unused_00[3];
    u8 read_only;
    u32 unused_04;
    u8 page;
    u8 length;
    u8 cyl[3];     
    u8 heads;
    u8 precomp[3];
    u8 reduced[3];
    u16 step_rate;
    u8 landing[3];
    u16 rpm;
  } PACKED;
which would put cyl[3] at offset 10 thru 12 and heads at offset 13.
Am I missing something here?

USB thumbdrives that don't stall on the mode sense return values like
cyl = 10h 3Fh 02h
heads = 00h
???

The values for that drive have 00h at offsets 2 thru 5.

I'm looking forward to any insight into this from anyone knowledgeable on the subject.

Dave

----- Original Message -----
> From: "Dave Frodin" 
> To: [e-mail]
> Sent: Wednesday, February 29, 2012 4:38:21 PM
> Subject: [SeaBIOS] Booting from USB thumbdrives, older drives boot,	newer drives don't.
>
> I'm a new subscriber to seabios.org so feel free to straighten me out
> if needed.
>
> I've been debugging an problem we've been seeing with not being able
> to boot (Ubuntu specifically) off
> of a variety of "newer" USB thumb drives. I've been specifically
> looking at an older/newer pair of
> Sandisk Cruzer 4GB drives. I've been adding dprintf's to narrow down
> the problem to the blockcmd.c file.
> The function scsi_init_drive() queries the USB device to determine
> stuff like vendor/device/size/etc.
> Near the end of the function is a call to cdb_mode_sense_geom(&dop,
> &geomdata) to retrieve the info
> related to cyl/head type stuff. On the older/working thumbdrive it
> returns zeroes for all of the values
> that get used by the code. The newer/failing drive generates a
> "stall" on the USB bus, which it never
> recovers from. The cdb_mode_sense_geom() function is sending a SCSI
> CDB Mode Sense (CMD=0x5A) to the device.
>
> As a hack of a test, I removed the call to cdb_mode_sense_geom() and
> filled the buffer it should have returned
> with zeroes and the failing thumbdrive now boots.
>
> I have some searching I need to do to find out...
> Is there a SCSI command to determine what protocols are supported?
> Is there another SCSI command that might return similar required
>
> data?
>
> Has anyone out there experienced similar booting difficulties?
> Or does anyone have any recommendations on what approach I should
> take?
>
> thanks,
> Dave
>
> SeaBIOS mailing list
> [e-mail]
> http://www.seabios.org/mailman/listinfo/seabios

Booting from USB thumbdrives, older drives boot, newer drives don't.

[Paolo Bonzini]

Il 02/03/2012 01:34, Dave Frodin ha scritto:
> On a related topic, I have a copy of the "Indispensable PC Hardware" book
> that lists the return values for the mode page 4 request. It list the cyc/head
> data as follows...
>  offset   value
> ==================
>    2     cyl(msb)
>    3     cyl
>    4     cyl(lsb)
>    5     heads
>
> the struct in the blockcmd.h file shows...
>   struct cdbres_mode_sense_geom {
>     u8 unused_00[3];
>     u8 read_only;
>     u32 unused_04;
>     u8 page;
>     u8 length;
>     u8 cyl[3];     
>     u8 heads;
>     u8 precomp[3];
>     u8 reduced[3];
>     u16 step_rate;
>     u8 landing[3];
>     u16 rpm;
>   } PACKED;
> which would put cyl[3] at offset 10 thru 12 and heads at offset 13.
> Am I missing something here?

The first eight bytes are not part of the page, they are common to all
MODE SENSE responses.

Perhaps we could restrict the MODE SENSE to disks of 504MiB and less.  I
still have a couple of 256 MB pen drives around, I can test them.

Can you try "sg_modes -HHp 4 /dev/sda" (from Linux) on both those that
fail and those that work?

Paolo

[Dave Frodin]

Paolo,
Thanks for the reply.
I ran the sg_modes for pages 4 and 5 on 4 USB thumbdrives.
sandisk_old is a 4GB Sandisk Cruzer (yes, the old is ver=8.02)
sandisk_new is a 4GB Sandisk Cruzer
transcend   is a 2GB drive
verbatim    is a 2GB drive

If I use the unmodified "master" SeaBIOS ...
    sandisk_old   boots
    sandisk_new   stalls at mode sense
    transcend     stalls at mode sense
    verbatim      boots

If I change the mode page from 4 to 5 ...
    sandisk_old   boots
    sandisk_new   boots
    transcend     stalls at mode sense
    verbatim      boots

The mode page change from 4 to 5 allowed four of my none booting
drives to boot. Hopefully these logs will be helpful.

Thanks again,
dave

starting sandisk_old tests
   sudo sg_modes -HHp 4 /dev/sdb
    SanDisk   Cruzer            8.02   peripheral_type: disk [0x0]
    Mode parameter header from MODE SENSE(10):
    00     00 46 00 00 00 00 00 00                                     
    Mode data length=72, medium type=0x00, WP=0, DpoFua=0, longlba=0
    Block descriptor length=0
    >> page_code=0x0, page_control=0
    00     00 00                                                 
    Unexpectedly received extra mode page responses, ignore

sudo sg_modes -HHp 5 /dev/sdb
    SanDisk   Cruzer            8.02   peripheral_type: disk [0x0]
    Mode parameter header from MODE SENSE(10):
    00     00 26 00 00 00 00 00 00                                     
    Mode data length=40, medium type=0x00, WP=0, DpoFua=0, longlba=0
    Block descriptor length=0
    >> page_code=0x5, page_control=0
    00     05 1e 80 00 04 20 02 00  ef c0 00 00 00 00 00 00
    10     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

starting sandisk_new tests
   sudo sg_modes -HHp 4 /dev/sdb
    SanDisk  Cruzer   1.26   peripheral_type: disk [0x0]
    invalid field in cdb (perhaps page 0x4 not supported)

sudo sg_modes -HHp 5 /dev/sdb
    SanDisk  Cruzer   1.26   peripheral_type: disk [0x0]
    Mode parameter header from MODE SENSE(10):
    00     00 26 00 00 00 00 00 00                                     
    Mode data length=40, medium type=0x00, WP=0, DpoFua=0, longlba=0
    Block descriptor length=0
    >> page_code=0x5, page_control=0
    00     05 1e 00 00 10 3f 02 00  1e 4f 00 00 00 00 00 00
    10     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

starting transcend
   sudo sg_modes -HHp 4 /dev/sdb
    JetFlash  Transcend 2GB     8.07   peripheral_type: disk [0x0]
    Mode parameter header from MODE SENSE(10):
    00     00 06 00 00 00 00 00 00                                     
    Mode data length=8, medium type=0x00, WP=0, DpoFua=0, longlba=0
    Block descriptor length=0

sudo sg_modes -HHp 5 /dev/sdb
    JetFlash  Transcend 2GB     8.07   peripheral_type: disk [0x0]
    Mode parameter header from MODE SENSE(10):
    00     00 06 00 00 00 00 00 00                                     
    Mode data length=8, medium type=0x00, WP=0, DpoFua=0, longlba=0
    Block descriptor length=0

starting verbatim
   sudo sg_modes -HHp 4 /dev/sdb
    Verbatim  STORE N GO        5.00   peripheral_type: disk [0x0]
    Mode parameter header from MODE SENSE(10):
    00     00 06 00 00 00 00 00 00                                     
    Mode data length=8, medium type=0x00, WP=0, DpoFua=0, longlba=0
    Block descriptor length=0

sudo sg_modes -HHp 5 /dev/sdb
    Verbatim  STORE N GO        5.00   peripheral_type: disk [0x0]
    Mode parameter header from MODE SENSE(10):
    00     00 26 00 00 00 00 00 00                                     
    Mode data length=40, medium type=0x00, WP=0, DpoFua=0, longlba=0
    Block descriptor length=0
    >> page_code=0x5, page_control=0
    00     05 1e f0 00 ff 20 02 00  01 df 00 00 00 00 00 00
    10     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

----- Original Message -----
> From: "Paolo Bonzini" 
> To: [e-mail], [e-mail]
> Sent: Friday, March 2, 2012 7:20:28 AM
> Subject: Re: Booting from USB thumbdrives, older drives boot, newer drives don't.
>
> Il 02/03/2012 01:34, Dave Frodin ha scritto:
> > On a related topic, I have a copy of the "Indispensable PC
> > Hardware" book
> > that lists the return values for the mode page 4 request. It list
> > the cyc/head
> > data as follows...
> >  offset   value
> > ==================
> >    2     cyl(msb)
> >    3     cyl
> >    4     cyl(lsb)
> >    5     heads
> >
> > the struct in the blockcmd.h file shows...
> >   struct cdbres_mode_sense_geom {
> >     u8 unused_00[3];
> >     u8 read_only;
> >     u32 unused_04;
> >     u8 page;
> >     u8 length;
> >     u8 cyl[3];
> >     u8 heads;
> >     u8 precomp[3];
> >     u8 reduced[3];
> >     u16 step_rate;
> >     u8 landing[3];
> >     u16 rpm;
> >   } PACKED;
> > which would put cyl[3] at offset 10 thru 12 and heads at offset 13.
> > Am I missing something here?
>
> The first eight bytes are not part of the page, they are common to
> all
> MODE SENSE responses.
>
> Perhaps we could restrict the MODE SENSE to disks of 504MiB and less.
>  I
> still have a couple of 256 MB pen drives around, I can test them.
>
> Can you try "sg_modes -HHp 4 /dev/sda" (from Linux) on both those
> that
> fail and those that work?
>
> Paolo

[Dave Frodin]

Here are my latest results.
The sg_modes command has a "-a" option to dump out all of the supported page codes
   - it reports that none of the thumbdrives (tested 9) support page code = 4 
   - it reports that most of the thumbdrives (tested 9) support page code = 5
   - it commented that page code 5 is obsolete

the page_code=4 and 5 cyc/head info must be garbage
these are the types of values I get back. I haven't
found a spec yet for the page_code 5 geometry struct
so it could be bogus because of that.

cyc[0]/cyc[1]/cyc[2]  head
                -------------------------------  
                page_code 4       page_code 5
================================================
old_sandisk   00/00/00  0         80/00/04  20
new_sandisk      stall            00/00/10  3F
verbatim      66/b5/02  f         f0/00/ff  20
wintec        00/00/80  0         13/88/10  3F

I think the booting drives boot because ...
  A) using page_code=5 got rid of the stall (even though the data is bogus)
  B) the MBR is at sector 0, and 0 is 0 no matter what the geometry
  C) perhaps there is code later in seabios that understands it's booting
     from a USB drive and knows better than us what to do and uses something
     like linear sectors.

Marc suggested that I leave the page_code set to 4 in order to preserve functionality for
drives that actually report valid CHS geometry, and to add code that would clear the stall
from the USB controller and thumbdrive.

Questions:
  1) Any recommendations on my direction?
  2) Is there any way to differentiate between a USB thumbdrive and
     a USB-to-SATA adapter?

dave

----- Original Message -----
> From: "Dave Frodin" 
> To: [e-mail]
> Sent: Friday, March 2, 2012 8:53:54 AM
> Subject: Re: [SeaBIOS] Booting from USB thumbdrives, older drives boot,	newer drives don't.
>
> Paolo,
> Thanks for the reply.
> I ran the sg_modes for pages 4 and 5 on 4 USB thumbdrives.
> sandisk_old is a 4GB Sandisk Cruzer (yes, the old is ver=8.02)
> sandisk_new is a 4GB Sandisk Cruzer
> transcend   is a 2GB drive
> verbatim    is a 2GB drive
>
> If I use the unmodified "master" SeaBIOS ...
>    sandisk_old   boots
>    sandisk_new   stalls at mode sense
>    transcend     stalls at mode sense
>    verbatim      boots
>
> If I change the mode page from 4 to 5 ...
>    sandisk_old   boots
>    sandisk_new   boots
>    transcend     stalls at mode sense
>    verbatim      boots
>
> The mode page change from 4 to 5 allowed four of my none booting
> drives to boot. Hopefully these logs will be helpful.
>
> Thanks again,
> dave
>
> starting sandisk_old tests
>    sudo sg_modes -HHp 4 /dev/sdb
>    SanDisk   Cruzer            8.02   peripheral_type: disk [0x0]
>    Mode parameter header from MODE SENSE(10):
>    00     00 46 00 00 00 00 00 00
>    Mode data length=72, medium type=0x00, WP=0, DpoFua=0, longlba=0
>    Block descriptor length=0
> > > page_code=0x0, page_control=0
>
> 00     00 00
>    Unexpectedly received extra mode page responses, ignore
>
> sudo sg_modes -HHp 5 /dev/sdb
>    SanDisk   Cruzer            8.02   peripheral_type: disk [0x0]
>    Mode parameter header from MODE SENSE(10):
>    00     00 26 00 00 00 00 00 00
>    Mode data length=40, medium type=0x00, WP=0, DpoFua=0, longlba=0
>    Block descriptor length=0
> > > page_code=0x5, page_control=0
>
> 00     05 1e 80 00 04 20 02 00  ef c0 00 00 00 00 00 00
>    10     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>
> starting sandisk_new tests
>    sudo sg_modes -HHp 4 /dev/sdb
>    SanDisk  Cruzer   1.26   peripheral_type: disk [0x0]
>    invalid field in cdb (perhaps page 0x4 not supported)
>
> sudo sg_modes -HHp 5 /dev/sdb
>    SanDisk  Cruzer   1.26   peripheral_type: disk [0x0]
>    Mode parameter header from MODE SENSE(10):
>    00     00 26 00 00 00 00 00 00
>    Mode data length=40, medium type=0x00, WP=0, DpoFua=0, longlba=0
>    Block descriptor length=0
> > > page_code=0x5, page_control=0
>
> 00     05 1e 00 00 10 3f 02 00  1e 4f 00 00 00 00 00 00
>    10     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>
> starting transcend
>    sudo sg_modes -HHp 4 /dev/sdb
>    JetFlash  Transcend 2GB     8.07   peripheral_type: disk [0x0]
>    Mode parameter header from MODE SENSE(10):
>    00     00 06 00 00 00 00 00 00
>    Mode data length=8, medium type=0x00, WP=0, DpoFua=0, longlba=0
>    Block descriptor length=0
>
> sudo sg_modes -HHp 5 /dev/sdb
>    JetFlash  Transcend 2GB     8.07   peripheral_type: disk [0x0]
>    Mode parameter header from MODE SENSE(10):
>    00     00 06 00 00 00 00 00 00
>    Mode data length=8, medium type=0x00, WP=0, DpoFua=0, longlba=0
>    Block descriptor length=0
>
> starting verbatim
>    sudo sg_modes -HHp 4 /dev/sdb
>    Verbatim  STORE N GO        5.00   peripheral_type: disk [0x0]
>    Mode parameter header from MODE SENSE(10):
>    00     00 06 00 00 00 00 00 00
>    Mode data length=8, medium type=0x00, WP=0, DpoFua=0, longlba=0
>    Block descriptor length=0
>
> sudo sg_modes -HHp 5 /dev/sdb
>    Verbatim  STORE N GO        5.00   peripheral_type: disk [0x0]
>    Mode parameter header from MODE SENSE(10):
>    00     00 26 00 00 00 00 00 00
>    Mode data length=40, medium type=0x00, WP=0, DpoFua=0, longlba=0
>    Block descriptor length=0
> > > page_code=0x5, page_control=0
>
> 00     05 1e f0 00 ff 20 02 00  01 df 00 00 00 00 00 00
>    10     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>
> ----- Original Message -----
> > From: "Paolo Bonzini" 
> > To: [e-mail], [e-mail]
> > Sent: Friday, March 2, 2012 7:20:28 AM
> > Subject: Re: Booting from USB thumbdrives, older drives boot, newer
> > drives don't.
> >
> > Il 02/03/2012 01:34, Dave Frodin ha scritto:
> > > On a related topic, I have a copy of the "Indispensable PC
> > > Hardware" book
> > > that lists the return values for the mode page 4 request. It list
> > > the cyc/head
> > > data as follows...
> > >  offset   value
> > > ==================
> > >    2     cyl(msb)
> > >    3     cyl
> > >    4     cyl(lsb)
> > >    5     heads
> > >
> > > the struct in the blockcmd.h file shows...
> > >   struct cdbres_mode_sense_geom {
> > >     u8 unused_00[3];
> > >     u8 read_only;
> > >     u32 unused_04;
> > >     u8 page;
> > >     u8 length;
> > >     u8 cyl[3];
> > >     u8 heads;
> > >     u8 precomp[3];
> > >     u8 reduced[3];
> > >     u16 step_rate;
> > >     u8 landing[3];
> > >     u16 rpm;
> > >   } PACKED;
> > > which would put cyl[3] at offset 10 thru 12 and heads at offset
> > > 13.
> > > Am I missing something here?
> >
> > The first eight bytes are not part of the page, they are common to
> > all
> > MODE SENSE responses.
> >
> > Perhaps we could restrict the MODE SENSE to disks of 504MiB and
> > less.
> >  I
> > still have a couple of 256 MB pen drives around, I can test them.
> >
> > Can you try "sg_modes -HHp 4 /dev/sda" (from Linux) on both those
> > that
> > fail and those that work?
> >
> > Paolo
>
> SeaBIOS mailing list
> [e-mail]
> http://www.seabios.org/mailman/listinfo/seabios

Booting from USB thumbdrives, older drives boot, newer drives don't.

[Kevin O'Connor]

On Fri, Mar 02, 2012 at 03:10:33PM -0700, Dave Frodin wrote:
> Here are my latest results.
> The sg_modes command has a "-a" option to dump out all of the supported page codes
> it reports that none of the thumbdrives (tested 9) support page code = 4
> it reports that most of the thumbdrives (tested 9) support page code = 5
> it commented that page code 5 is obsolete

Thanks Dave.  I appreciate your detailed analysis.

The call to cdb_mode_sense_geom() was only recently added.  I'm
inclined to just remove the call.  Paolo, is there a use case where
having the "physical" chs info is important?  SeaBIOS should generate
good "virtual" chs info regardless, and the underlying "physical" info
is only exported in a couple of places.
> Marc suggested that I leave the page_code set to 4 in order to
> preserve functionality for drives that actually report valid CHS
> geometry, and to add code that would clear the stall from the USB
> controller and thumbdrive.

The SeaBIOS code really should know how to clear a stall.  However,
it's a bit of a pain to do that in the general case.  (In the general
case, we'd need to support clearing the stall from 16bit mode, which
would require the ability to send control messages to the drive in
16bit mode.)
> Is there any way to differentiate between a USB thumbdrive and
> a USB-to-SATA adapter?

I don't know of a way to detect it, but I haven't looked closely.

-Kevin

[Dave Frodin]

Kevin/Paolo,
Our concern was that actual rotating media (e.g. USB-to-SATA adapter) may have
problems without the cdb_mode_sense_geom(). I hope to have my hands on one 
tomorrow to do some testing.

Dave

----- Original Message -----
> From: "Kevin O'Connor" 
> To: "Dave Frodin" , "Paolo Bonzini" 
> Cc: [e-mail]
> Sent: Sunday, March 4, 2012 11:49:30 AM
> Subject: Re: [SeaBIOS] Booting from USB thumbdrives, older drives boot, newer drives don't.
>
> On Fri, Mar 02, 2012 at 03:10:33PM -0700, Dave Frodin wrote:
> > Here are my latest results.
> > The sg_modes command has a "-a" option to dump out all of the
> > supported page codes
> > it reports that none of the thumbdrives (tested 9) support
> >
> > page code = 4
> > it reports that most of the thumbdrives (tested 9) support
> >
> > page code = 5
> > it commented that page code 5 is obsolete
>
> Thanks Dave.  I appreciate your detailed analysis.
>
> The call to cdb_mode_sense_geom() was only recently added.  I'm
> inclined to just remove the call.  Paolo, is there a use case where
> having the "physical" chs info is important?  SeaBIOS should generate
> good "virtual" chs info regardless, and the underlying "physical"
> info
> is only exported in a couple of places.
> > Marc suggested that I leave the page_code set to 4 in order to
> > preserve functionality for drives that actually report valid CHS
> > geometry, and to add code that would clear the stall from the USB
> > controller and thumbdrive.
>
> The SeaBIOS code really should know how to clear a stall.  However,
> it's a bit of a pain to do that in the general case.  (In the general
> case, we'd need to support clearing the stall from 16bit mode, which
> would require the ability to send control messages to the drive in
> 16bit mode.)
> > Is there any way to differentiate between a USB thumbdrive and
> > a USB-to-SATA adapter?
>
> I don't know of a way to detect it, but I haven't looked closely.
>
> -Kevin

Booting from USB thumbdrives, older drives boot, newer drives don't.

[Kevin O'Connor]

On Sun, Mar 04, 2012 at 12:05:14PM -0700, Dave Frodin wrote:
> Kevin/Paolo,
> Our concern was that actual rotating media (e.g. USB-to-SATA adapter) may have
> problems without the cdb_mode_sense_geom(). I hope to have my hands on one 
> tomorrow to do some testing.

My understanding is that the call was added for QEmu users:

http://www.seabios.org/pipermail/seabios/2011-November/002566.html

-Kevin

Booting from USB thumbdrives, older drives boot, newer drives don't.

[Paolo Bonzini]

Il 04/03/2012 19:49, Kevin O'Connor ha scritto:
> > > The sg_modes command has a "-a" option to dump out all of the supported page codes
> > > it reports that none of the thumbdrives (tested 9) support page code = 4
> > > it reports that most of the thumbdrives (tested 9) support page code = 5
> > > it commented that page code 5 is obsolete
>
> Thanks Dave.  I appreciate your detailed analysis.
>
> The call to cdb_mode_sense_geom() was only recently added.  I'm
> inclined to just remove the call.  Paolo, is there a use case where
> having the "physical" chs info is important?  SeaBIOS should generate
> good "virtual" chs info regardless, and the underlying "physical" info
> is only exported in a couple of places.

MS-DOS doesn't boot if you do not export the physical chs.  I can remove
it, but it was the best testcase I had for SCSI support.

The simplest solution seems to be to look for page 4 support in page 0x3f.

Paolo

[Dave Frodin]

----- Original Message -----
> From: "Paolo Bonzini" 
> To: "Kevin O'Connor" 
> Cc: "Dave Frodin" , [e-mail]
> Sent: Monday, March 5, 2012 1:17:08 AM
> Subject: Re: Booting from USB thumbdrives, older drives boot, newer drives don't.
>
> Il 04/03/2012 19:49, Kevin O'Connor ha scritto:
> > > > The sg_modes command has a "-a" option to dump out all of the
> > > > supported page codes
> > > > it reports that none of the thumbdrives (tested 9) support
> > > >
> > > > page code = 4
> > > > it reports that most of the thumbdrives (tested 9) support
> > > >
> > > > page code = 5
> > > > it commented that page code 5 is obsolete
> >
> > Thanks Dave.  I appreciate your detailed analysis.
> >
> > The call to cdb_mode_sense_geom() was only recently added.  I'm
> > inclined to just remove the call.  Paolo, is there a use case where
> > having the "physical" chs info is important?  SeaBIOS should
> > generate
> > good "virtual" chs info regardless, and the underlying "physical"
> > info
> > is only exported in a couple of places.
>
> MS-DOS doesn't boot if you do not export the physical chs.  I can
> remove
> it, but it was the best testcase I had for SCSI support.
>
> The simplest solution seems to be to look for page 4 support in page
> 0x3f.

Except that none of the 12 devices I've tested support page 4.
There's also a good chance that some of the devices could generate the
stall on the page 3f request. That's what led us to thinking we should
leave the page 4 query in and just add support to clear the stall.
> Paolo