From owner-freebsd-current@FreeBSD.ORG Tue Apr 13 06:07:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E32316A4CE for ; Tue, 13 Apr 2004 06:07:31 -0700 (PDT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5334843D60 for ; Tue, 13 Apr 2004 06:07:30 -0700 (PDT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i3DD5Can043875 for freebsd-current@freebsd.org.checked; (8.12.8/vak/2.1) Tue, 13 Apr 2004 17:05:12 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru with ESMTP id i3DD3tNn043673; (8.12.8/vak/2.1) Tue, 13 Apr 2004 17:03:55 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <407BE532.8060608@cronyx.ru> Date: Tue, 13 Apr 2004 17:03:46 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce Evans References: <4061E207.8070406@cronyx.ru> <407995BF.7060504@cronyx.ru> <20040413101307.D1606@gamplex.bde.org> In-Reply-To: <20040413101307.D1606@gamplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: ATA/CHS problem (path + new information) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2004 13:07:31 -0000 Bruce Evans wrote: >On Sun, 11 Apr 2004, Roman Kurakin wrote: > > >>I remind you that now I have two problems. First one that FreeBSD uses >>wrong assumption about which device should be CHS and which LBA: >> >>if (!ad_version(atadev->param->version_major) || >>!(atadev->param->atavalid & ATA_FLAG_54_58) || !lbasize) >>atadev->flags |= ATA_D_USE_CHS; >> >>True ATA device may not have ATA_FLAG_54_58 valid bit, and also due >>to last ATA standard this bit is obsoleted. >> >>I also want to know why ata driver doesn't check LBA support from word 49? >>May be this one check could solve my problems and didn't breake code for >>non-ATA devices. >> >> >Possibly for similar reasons. It's hard to tell what's in the LBA bit for >pre-ATA devices older than LBA. Similarly for the lbasize words, but it's >easier to do a sanity check on a 32-bit values that a 1-bit flag. > > But since ATA_FLAG_54_58 bit from the fist spec means 1 - "valid" and 0 - "may be valid" this check is initialy incorrect. According to ATA-5 it is depricated. But in later revisions of ST380021A (according to their datasheet, I don't have one) Seagate changed this bit to 1 back, I may guess that this was done since probably others uses the same check. :-( Anyway, it seems that Soren already removed this check. So my ST380021A should back to the life. >>Second one, that only 20G part of my hard disk works with CHS. This is other >>side of the same problem. Device should work in CHS mode. And it works >>witch ICH5 controller. But with ICH2 it doesn't with out hack. >> >>I've checked standard again and I sew command 91h (Initialize drive >>parameters). >> >> > >Check out the commands for limiting the (apparent) disk size. IIRC, >the CHS limit can be set independently of the LBA limit, and some >settings are harder than others so that they can't be cleared by old >commands like 0x91. The limits may be set to prevent old drivers which >only understand old commands from becoming confused by trying to actually >use the whole disk. > > This is good idea. I sew only LBA limits, but I didn't see anytihng about CHS limits. I'll try to check for some more commands. I can't get how ATA controller could affect on this. Brobably this is not controller problem but BIOS, but changing its settings didn't affect. Thanks for reply, I hope your suggestions will help me. Since Soren removed first bug I'll keep digging from obstinacy :-) rik