[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug 1896342] Re: IDE ATA IDENTIFY WORD 106
From: |
Benjamin David Lunt |
Subject: |
[Bug 1896342] Re: IDE ATA IDENTIFY WORD 106 |
Date: |
Sat, 19 Sep 2020 19:38:01 -0000 |
For more information, Annex-E of the ACS-2 explains this as well.
http://www.t13.org/Documents/UploadedDocuments/docs2009/d2015r2
-ATAATAPI_Command_set_-_2_ACS-2.pdf
See the statement on the top of page 165 as well. "If bit 13 is set,
then bits 3:0 are valid".
Page 119 of that same document states:
"13 1 = Device has multiple logical sectors per physical sector."
In my opinion, if bit 13 is set and bits 3:0 are valid, then bits 3:0
should be non-zero.
Therefore, I gather that in QEMU (assuming that get_physical_block_exp()
returns the same value shown in the example listing above):
1) if get_physical_block_exp() return a non-zero value, bit 13 must be set and
bits 3:0 will be non-zero.
2) if get_physical_block_exp() return a zero value, bit 13 must be clear and
bits 3:0 must be ignored.
Please correct me if I am wrong in these assumptions.
Thanks,
Ben
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1896342
Title:
IDE ATA IDENTIFY WORD 106
Status in QEMU:
New
Bug description:
The code at line 202 in hw/ide/core.c
(https://git.qemu.org/?p=qemu.git;a=blob;f=hw/ide/core.c;#l201)
hard codes bit 13 set. However, get_physical_block_exp() can and may return
0, which is a valid response. If get_physical_block_exp() does return zero, bit
13 should not be set.
ATAPI8 states (Section 7.17.7.73):
"Bit 13 of word 106 shall be set to one to indicate that the device has more
than one logical sector per physical sector"
and gives the examples:
Bits (3:0): 0 = 2^0 = 1 logical sector per physical sector
Bits (3:0): 1 = 2^1 = 2 logical sector per physical sector
Bits (3:0): 2 = 2^2 = 4 logical sector per physical sector
Bits (3:0): 3 = 2^3 = 8 logical sector per physical sector
Therefore, if bit 13 is set, bits 3:0 must be greater than zero.
If get_physical_block_exp() returns zero then there is a 1:1 ratio and
bit 13 must be 0.
Just my opinion.
Thanks,
Ben
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1896342/+subscriptions