Re: ATA/CHS problem

From: S?ren Schmidt <sos_at_DeepCore.dk>
Date: Thu, 25 Mar 2004 08:32:18 +0100
Roman Kurakin wrote:

> This is not an LBA request. ATA driver thinks that I have 80G CHS 
> device, cause it's ATA_FLAG_54_58
> is zero. (This decision is incorrect, we shouldn't relay on this flag). 
> I've checked another seagate 80G drive in
> CHS mode(by driver hacking), and problematic one with LBA mode. I get 
> the same behavior on both with CHS.
> And both work fine in LBA mode. It also should be mentioned that I get 
> this problem on machine with
> ICH2 controller, and it seems that I don't have such problem on other 
> machine with ICH5

Hmm, we could loosen up this check (Se patch below) but that will 
probably break support for real old ATA disks (note that those old 
systems most likely will have trouble with -current anyways).
If I coul dhave my ways, we wouldn't even try to support disks that 
doesn't support LBA....

> PS. If you have any ideas, or if you have any materials (standards for 
> example) about ATA/ATAPI and you
> can share them with me, please let me know. I am not ata developer, so 
> this is a bit difficalt for me to
> dig this problem.

Go to t13.org they are the standards body for ATA etc...

Index: ata-disk.c
===================================================================
RCS file: /home/ncvs/src/sys/dev/ata/ata-disk.c,v
retrieving revision 1.171
diff -u -r1.171 ata-disk.c
--- ata-disk.c  1 Mar 2004 13:17:07 -0000       1.171
+++ ata-disk.c  25 Mar 2004 07:28:20 -0000
_at__at_ -104,8 +104,7 _at__at_
                ((u_int32_t)atadev->param->lba_size_2 << 16);

      /* does this device need oldstyle CHS addressing */
-    if (!ad_version(atadev->param->version_major) ||
-       !(atadev->param->atavalid & ATA_FLAG_54_58) || !lbasize)
+    if (!ad_version(atadev->param->version_major) || !lbasize)
         atadev->flags |= ATA_D_USE_CHS;

      /* use the 28bit LBA size if valid or bigger than the CHS mapping */


-S?ren
Received on Wed Mar 24 2004 - 22:32:39 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:48 UTC