Hi Heyi,
On Tue, Jan 10, 2017 at 10:14:39PM +0800, Heyi Guo wrote:
That's true; it makes no difference between 1 or 2 drives. Right now we only saw the direct reason that grub failed to get correct data, but we have not been clear about why OS puts boot data in high sectors sometimes. As Chase reported, bug 2393 also happened on board with only one drive, and what we found during reproducing was that it would be easily reproduced by installing Debian after installing CentOS, without acpi=force kernel option while installing. The reason why acpi=force option impacts the reproducing rate is even harder to explain.
I don't believe acpi=force has any effect on this either. The Debian RP image always uses ACPI, and the fault is completely isolated to UEFI Boot Services, which are no longer active when the kernel starts looking for hardware description.
So I guess there is some strategy in Linux file system (the default file system Debian chooses) to place file data segments, maybe depending on time stamp, random seed, etc. And will Linux also use the other drive to make raid if it is spare? I might see CentOS made something to the spare drive, but I'm not so sure about it.
It does not even have to be spare drive - if the partition layout for any reason changes to keep all the files needed by GRUB below 2TB, then the system will work fine. If intricasies of the filesystem format causes reads above 2TB, the boot fails.
The problematic aspect of the bug report was that it claimed that sometimes Debian booted successfully when having been installed in a system with a single drive, but not when having been installed in the same system when two or more drives were connected.
Additional factors, such as partition layout, were most likely different between these cases. Possibly some confusion between installing CentOS and having it working (or re-using the partitioning from CentOS) and then adding a disk and installing Debian and having it not working.
Maybe some expert of Linux file system could help to explain?
Not needed. If we want to look into this further, what we need is a validation protocol of different configurations to run through.
First of all we would need to establish exact steps for installing a Debian system that boots successfully with the old SAS driver. And then we would need to re-run exactly the same steps one the same machine with another disk connected. If you can provide that, this may be worth looking into.
But from my point of view, we can close the bug and apply this patch. I only need your opinions on my comments on the commit message.
Regards,
Leif
Regards,
Heyi
On 10 January 2017 at 20:02, Leif Lindholm leif.lindholm@linaro.org wrote:
On Tue, Jan 10, 2017 at 02:06:47PM +0800, Heyi Guo wrote:
Hi Leif,
That make sense, thanks.
I refine the commit message acorrding to your comment.
Much improved, thanks. But a suggestion and a couple of requests for clarifications:
That could be found in my branch ssh://git@git.linaro.org/people/heyi.guo/OpenPlatformPkg.git.
Thanks and Regards.
Hisilicon D03/D05: add SCSI cdb16 command
Suggest add:
The D03/D05 SAS driver will fail to access disks beyond 2^32 sectors. Symptoms can include the system entering grub rescue mode...
The system may enter grub rescure mode if the user use a HDD largerthan
2TB. The issue log like this:
error: file `/boot/grub/arm64-efi/normal.mod' not found. Entering rescue mode... grub rescue> This is because the sas driver in uefi always use CDB10 SCSI command, which is a 32 bit value, this command is used to read install datafrom
sectors, if the sector index higher than 4G, for such data read, the uefi sas
Perhaps better worded as 2^32 than 4G, to reduce risk of confusion.
driver previous will drop the higher bits. The sector index is passed from LBA in Block IO protocol. The sector size is 512 bytes, so when the HDD larger than 2TB will trigger this issue.
This version we switch CDB16(64bit) mode for accessing disks of size larger than 2TB.Larger than 2TB (regardless of sector size) or larger than 2^32 sectors?
This commit resolves the issueWhile this is a clear fix, and should definitely go in - I still do not understand how this can resolve #2393 as described. The CDB16 support should make no difference between 1 or 2 drives being connected, right?
Do you have any ideas?
Regards,
Leif
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Chenhui Sun <sunchenhui@huawei.com> Signed-off-by: Jason Zhang <zhangjinsong2@huawei.com> Signed-off-by: Heyi Guo <heyi.guo@linaro.org>在 2017/1/10 1:11, Leif Lindholm 写道:
Hi Heyi,
(You forgot to add me to cc on the original submission - quite likely I would have missed this without the separate email.)
On Mon, Jan 09, 2017 at 02:11:36PM +0800, Heyi Guo wrote:
This patch resolves the issue 2393: https://bugs.linaro.org. The cdb16 command should be used if the hard disk size larger than 4TB.
Since I have no source code to reconciliate the commit message against, the commit message needs to be more detailed than this. It should contain the following:
- The user-visible problem that was seen before.
- What type of internal failure caused that problem.
- Why this change resolves the issue.
The Linaro bug is usful to include for reference, but it is not part of the description - it should go last in the commit message.
The summary (subject line) is fine and does not need changing.
Regards,
Leif
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Chenhui Sun sunchenhui@huawei.com Signed-off-by: Jason Zhang zhangjinsong2@huawei.com
.../Binary/D03/Drivers/Sas/SasDriverDxe.efi | Bin 210752 ->
208288 bytes
.../Binary/D05/Drivers/Sas/SasDriverDxe.efi | Bin 210400 ->
230912 bytes
2 files changed, 0 insertions(+), 0 deletions(-)
diff --git a/Platforms/Hisilicon/Binary/D03/Drivers/Sas/SasDriverDxe.efi
b/Platforms/Hisilicon/Binary/D03/Drivers/Sas/SasDriverDxe.efi
index b956b19..19cd038 100644 Binary files a/Platforms/Hisilicon/Binary/
D03/Drivers/Sas/SasDriverDxe.efi and b/Platforms/Hisilicon/Binary/ D03/Drivers/Sas/SasDriverDxe.efi differ
diff --git a/Platforms/Hisilicon/Binary/D05/Drivers/Sas/SasDriverDxe.efi
b/Platforms/Hisilicon/Binary/D05/Drivers/Sas/SasDriverDxe.efi
index 6021d12..8d9ecd2 100644 Binary files a/Platforms/Hisilicon/Binary/
D05/Drivers/Sas/SasDriverDxe.efi and b/Platforms/Hisilicon/Binary/ D05/Drivers/Sas/SasDriverDxe.efi differ
-- 1.9.1
Linaro-uefi mailing list Linaro-uefi@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-uefi