From: Greg Freemyer <greg.freemyer@gmail.com>
To: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>
Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
Tejun Heo <htejun@gmail.com>
Subject: Re: [patch ide-dev 3/9] merge LBA28 and LBA48 Host Protected Area support code
Date: Fri, 25 Feb 2005 16:38:48 -0500 [thread overview]
Message-ID: <87f94c370502251338129eeb4e@mail.gmail.com> (raw)
In-Reply-To: <87f94c3705022412192629fc13@mail.gmail.com>
Retested with Hitachi drive and 2.6.10 vanilla kernel.
Same behavior, HPA is not reset to native max.
Greg
--
Greg Freemyer
On Thu, 24 Feb 2005 15:19:52 -0500, Greg Freemyer
<greg.freemyer@gmail.com> wrote:
> On Thu, 24 Feb 2005 17:30:55 +0100, Bartlomiej Zolnierkiewicz
> <bzolnier@elka.pw.edu.pl> wrote:
> > On Thursday 24 February 2005 17:10, Greg Freemyer wrote:
> > > I have generic question about HPA, not the patch.
> > >
> > > I have noticed with a SUSE 2.6.8 vendor kernel, the HPA behavior is
> > > not consistent.
> >
> > Please retry with vanilla kernel.
> >
> Will do. I assume 2.6.10 is fine?
>
> > > ie. With exactly the same computer/controller, but with different disk
> > > drives (models/manufacturers) the HPA behavior varies.
> > >
> > > In all my testing the HPA was always properly detected, but sometimes
> > > the max_address is set to the native_max_address during bootup and
> > > sometimes it is not.
> >
> > Please be more precise.
> >
> > What do you mean by 'sometimes'?
> >
> Seems to be disk drive specific.
>
> For instance my records show that for a:
> Maxtor model 32049h2
> 20 GB
> Manufactured Mar. 2001
> drive I was working with last week the maximum available capacity was
> set to the native max. At power on the max. avail. was slightly
> smaller than native max.
>
> With exactly the same computer I just tested a HPA test drive of mine:
> Hitachi Deskstar
> model HDS728080PLAT20
> 82.3 GB (per label)
> Manufactured Oct. 2004
> and the max. avail. was not reset. From boot.msg
>
> <6>hdc: max request size: 1024KiB
> <6>hdc: Host Protected Area detected.
> <4> current capacity is 50001 sectors (25 MB)
> <4> native capacity is 160836480 sectors (82348 MB)
> <4>hdc: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
> <4>hdc: task_no_data_intr: error=0x04 { DriveStatusError }
> <4>ide: failed opcode was: 0x37
> <6>hdc: 50001 sectors (25 MB) w/1719KiB Cache, CHS=49/255/63, UDMA(100)
> <7>hdc: cache flushes supported
> <6> hdc: hdc1
>
> Looking in /proc/ide/hdc/capacity after boot I show 50001 sectors.
>
> Note this is still with the SUSE 2.6.8 vendor kernel and I don't know
> what the Drive errors are, but they seem to be a driver issue, not a
> hardware issue. Concievably they are related to the behavior, but I
> don't know.
>
> > What are the exact differences between machines?
> >
> Same machine / OS, just connecting different drives. By chance, the
> machine had been powered off between the 2 tests. (It is a portable
> machine that is normally locked away when not in use.)
>
> > Are there any differences in software configurations
> > (i.e. kernel parameters) between this machines?
> >
> no
>
> > > Is there some reason for this behavior or is one case or the other a bug?
> >
> > Dunno, not enough info.
> >
> > > Does this patch somehow address the inconsistency?
> >
> > No.
> >
> > > Am I right in assuming this behavior also exists in the vanilla
> > > kernels?. ie. I doubt that vendors are patching this behavior.
> >
> > Recent vanilla kernels always set maximum available capacity.
> >
> Was 2.6.8 recent enough to have this behavior?
>
> Greg
> --
> Greg Freemyer
>
prev parent reply other threads:[~2005-02-25 21:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-24 14:39 [patch ide-dev 3/9] merge LBA28 and LBA48 Host Protected Area support code Bartlomiej Zolnierkiewicz
2005-02-24 16:10 ` Greg Freemyer
2005-02-24 16:30 ` Bartlomiej Zolnierkiewicz
2005-02-24 20:19 ` Greg Freemyer
2005-02-25 21:38 ` Greg Freemyer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87f94c370502251338129eeb4e@mail.gmail.com \
--to=greg.freemyer@gmail.com \
--cc=bzolnier@elka.pw.edu.pl \
--cc=htejun@gmail.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.