diff options
Diffstat (limited to 'results/classifier/118/graphic/1896342')
| -rw-r--r-- | results/classifier/118/graphic/1896342 | 113 |
1 files changed, 113 insertions, 0 deletions
diff --git a/results/classifier/118/graphic/1896342 b/results/classifier/118/graphic/1896342 new file mode 100644 index 000000000..bed5551dd --- /dev/null +++ b/results/classifier/118/graphic/1896342 @@ -0,0 +1,113 @@ +graphic: 0.874 +peripherals: 0.832 +semantic: 0.811 +assembly: 0.799 +user-level: 0.774 +permissions: 0.766 +network: 0.758 +performance: 0.753 +architecture: 0.746 +virtual: 0.743 +debug: 0.738 +socket: 0.736 +device: 0.732 +register: 0.728 +PID: 0.726 +files: 0.715 +risc-v: 0.690 +hypervisor: 0.682 +kernel: 0.670 +TCG: 0.663 +arm: 0.643 +VMM: 0.643 +mistranslation: 0.641 +ppc: 0.606 +x86: 0.590 +vnc: 0.587 +KVM: 0.571 +boot: 0.565 +i386: 0.490 + +IDE ATA IDENTIFY WORD 106 + +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 + +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 might be right, though at present it seems like it doesn't hurt anything that I am aware of to claim that our mapping is 1:1 in such cases. + +Patches welcome; especially if there is any proof that this has caused any problems anywhere. + +--js + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + |