Re: [edk2] Grub error reading sector 0x600 on CD-RW and DVD+RW

Subject: Re: [edk2] Grub error reading sector 0x600 on CD-RW and DVD+RW

From: "David F." <df7729@gmail.com>

To: "edk2-devel@lists.sourceforge.net" <edk2-devel@lists.sourceforge.net>

Date: 2013-11-19 19:11:36

breaking it up to 512K size reads (256 sectors) did work - slower than
I thought it would be but works. Thanks.

On Tue, Nov 19, 2013 at 8:09 AM, Brian J. Johnson  wrote:
> FWIW, we saw similar problems with a 3rd party SAS driver as well.  It
> provided only the BLOCK_IO protocol, and would error out if asked to
> perform a read of 0x8000 or more blocks (16MB.)  That broke a particular
> version of Microsoft's boot loader, and there was nothing we could do
> about it in our BIOS.
>
> So it sounds like this sort of problem is widespread.
>
> Brian Johnson
>
> On 11/19/2013 03:10 AM, Mike Maslenkin wrote:
>> And we saw similar problems too.
>>
>> In our case the problem was in large PIO transfers.
>> Since edk2 code base uses PIO for ATAPI devices, we are unable to handle
>> such reads in our VM, because we have a 1MB bounce buffer for PIO.
>>
>> There were two solutions implemented:
>> 1. We have added DMA support.
>> 2. We have limited maximum transfer size for all block devices to 1 MB
>> (in ScsiDiskDxe).
>>     //
>>     // limit the data bytes that can be transferred by one Read(10) or
>> Read(16) Command
>>     //
>>     if (!ScsiDiskDevice->Cdb16Byte) {
>> -    MaxBlock         = 0xFFFF;
>> +    MaxBlock         = 0x200; // 1mb
>>     } else {
>>       MaxBlock         = 0xFFFFFFFF;
>>     }
>>
>> The second solution is not so good, and I started to think about
>> splitting request at
>> AtaAtapiPassThruDxe, before submitting it to ATA device.
>>
>> Hope it helps.
>>
>> On Mon, 2013-11-18 at 19:35 -0800, H. Peter Anvin wrote:
>>> On 11/18/2013 05:47 PM, David F. wrote:
>>>> Thanks - I found the grub option for set debug= (I couldn't use all
>>>> since it would lock up - but used disk,efidisk,modules,loader) and can
>>>> see it reads 0x100 sectors from sector 0x500 then reads 0x4C00 sectors
>>>> from sector 0x600.  So perhaps that's it.  Yes, legacy reads in the
>>>> same inirmfs.gz file (which occupies 0x5AF to 0x525C) but I'm sure it
>>>> does it in smaller chunks.
>>>
>>> We saw similar problems with extremely large reads while developing the
>>> Linux EFI boot stub.  We ended up capping the size of any one read call
>>> to 1 MB.  Sad but true.
>>>
>>>      -hpa
>>>
>
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel