qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug 1896342] Re: IDE ATA IDENTIFY WORD 106


From: John Snow
Subject: [Bug 1896342] Re: IDE ATA IDENTIFY WORD 106
Date: Fri, 02 Oct 2020 19:54:45 -0000

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

-- 
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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]