Re: hdparm-8.2 now available
Mark, What kernel level is needed to support the new -N arg? Tried it on a Suse 2.6.22 kernel (possibly not patched with all the current security updates). Failed with: The Running Kernel Lack CONFIG_IDE_TASK_IOCTL Support. Thanks Greg On Mon, Feb 18, 2008 at 7:25 PM, Mark Lord <[EMAIL PROTECTED]> wrote: > hdparm for SATA/PATA has now been updated to version 8.2. > > Upgrading is strongly recommended for all users. > This version fixes several bugs in earlier 7.x/8.x releases > that could cause issues when advanced features are attempted > on devices being driven by the old drivers/ide subsystem. > > libata devices were unaffected, but drivers/ide devices could > misbehave or even be corrupted by some operations. > > hdparm-8.2 is available at http://sourceforge.net/projects/hdparm/ > > Upgrading from any earlier 7.x or 8.x version > is strongly recommended for all users. > > Cheers > -- > Mark Lord > Real-Time Remedies Inc. > [EMAIL PROTECTED] > - > To unsubscribe from this list: send the line "unsubscribe linux-ide" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm-8.2 now available
Mark, What kernel level is needed to support the new -N arg? Tried it on a Suse 2.6.22 kernel (possibly not patched with all the current security updates). Failed with: The Running Kernel Lack CONFIG_IDE_TASK_IOCTL Support. Thanks Greg On Mon, Feb 18, 2008 at 7:25 PM, Mark Lord [EMAIL PROTECTED] wrote: hdparm for SATA/PATA has now been updated to version 8.2. Upgrading is strongly recommended for all users. This version fixes several bugs in earlier 7.x/8.x releases that could cause issues when advanced features are attempted on devices being driven by the old drivers/ide subsystem. libata devices were unaffected, but drivers/ide devices could misbehave or even be corrupted by some operations. hdparm-8.2 is available at http://sourceforge.net/projects/hdparm/ Upgrading from any earlier 7.x or 8.x version is strongly recommended for all users. Cheers -- Mark Lord Real-Time Remedies Inc. [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence Technology http://www.norcrossgroup.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Make_bad_sector
On Jan 28, 2008 3:43 PM, Mark Lord <[EMAIL PROTECTED]> wrote: > Gene Heskett wrote: > > On Monday 28 January 2008, Mark Lord wrote: > >.. > >> Another way is to use the "make_bad_sector" utility that > >> is included in the source tarball for hdparm-7.7, as follows: > >> > >> make_bad_sector --readback /dev/sda 474507 > >> > > Apparently not in the rpm, darnit. > .. > > That's okay. It should still be in the SRPM source file. > And it's a tiny download from sourceforge.net: > > http://sourceforge.net/search/?type_of_search=soft_of_search=soft=hdparm > Mark, I asked on the SUSE list and was informed by Philipp Thomas of Novell (cc'ed) that the only mention of make_bad_sector in the hdparm-7.7 source is in a todo list. Sounds like a useful tool, so I was hoping to encourage suse to include it with future releases. Thanks Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Make_bad_sector
On Jan 28, 2008 3:43 PM, Mark Lord [EMAIL PROTECTED] wrote: Gene Heskett wrote: On Monday 28 January 2008, Mark Lord wrote: .. Another way is to use the make_bad_sector utility that is included in the source tarball for hdparm-7.7, as follows: make_bad_sector --readback /dev/sda 474507 Apparently not in the rpm, darnit. .. That's okay. It should still be in the SRPM source file. And it's a tiny download from sourceforge.net: http://sourceforge.net/search/?type_of_search=softtype_of_search=softwords=hdparm Mark, I asked on the SUSE list and was informed by Philipp Thomas of Novell (cc'ed) that the only mention of make_bad_sector in the hdparm-7.7 source is in a todo list. Sounds like a useful tool, so I was hoping to encourage suse to include it with future releases. Thanks Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence Technology http://www.norcrossgroup.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ATA bus error with external hd on esata
On Dec 17, 2007 5:53 AM, Andrew Morton <[EMAIL PROTECTED]> wrote: > On Sat, 15 Dec 2007 21:10:47 +0100 Zsolt Barat <[EMAIL PROTECTED]> wrote: > > > Zsolt Barat schrieb: > > > hi list, > > Let's cc the IDE development list. > > > > i just bought a "MyBook" called external HD with a fixed enclosure, from > > > WD. Connected to the SATA port i constantly get "ATA bus error" messages > > > in the kernel log. Is this a known issue? > > > As an FYI: I've had a lot of problems with the big prepackaged drives in the last 6 months even from Windows, so I would not be too quick to blame Linux. ie. I bought several 500GB / 1000GB Buffalo Drives last month with plans to use them from Windows via USB. I attempted to do a lot of heavy file copying to/from them. I was getting a bunch of "Delayed Write Failures", I finally gave up. The 500GB drives had a single hard drive internally, so I opened the case, removed the drive and connected them via standalone external carriers I had around. In that mode the drives worked fine (from Windows). I've used both standalone eSata external carriers and standalone USB external carriers with these same physical drives with no issues. My conclusion is that the electronics in the prepackaged external units is just not up to the job if your doing heavy i/o. Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ATA bus error with external hd on esata
On Dec 17, 2007 5:53 AM, Andrew Morton [EMAIL PROTECTED] wrote: On Sat, 15 Dec 2007 21:10:47 +0100 Zsolt Barat [EMAIL PROTECTED] wrote: Zsolt Barat schrieb: hi list, Let's cc the IDE development list. i just bought a MyBook called external HD with a fixed enclosure, from WD. Connected to the SATA port i constantly get ATA bus error messages in the kernel log. Is this a known issue? As an FYI: I've had a lot of problems with the big prepackaged drives in the last 6 months even from Windows, so I would not be too quick to blame Linux. ie. I bought several 500GB / 1000GB Buffalo Drives last month with plans to use them from Windows via USB. I attempted to do a lot of heavy file copying to/from them. I was getting a bunch of Delayed Write Failures, I finally gave up. The 500GB drives had a single hard drive internally, so I opened the case, removed the drive and connected them via standalone external carriers I had around. In that mode the drives worked fine (from Windows). I've used both standalone eSata external carriers and standalone USB external carriers with these same physical drives with no issues. My conclusion is that the electronics in the prepackaged external units is just not up to the job if your doing heavy i/o. Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence Technology http://www.norcrossgroup.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with IDE on linux 2.6.22.X
On 8/30/07, Rene Herman <[EMAIL PROTECTED]> wrote: > On 08/30/2007 09:31 PM, Jan Engelhardt wrote: > > > On Aug 28 2007 19:05, Rene Herman wrote: > > >> Sheesh. How could anyone _not_ understand you need SCSI CD-ROM support > >> for your IDE DVD-RW drive... > > > > Welcome to the wonderful world of SCSIfying ATA. (Don't talk about ATAPI, > > USB/Firewire, it's a different matter.) > > Well -- the world where ATA, SCSI, USB, Firewire and what have you are > low-level drivers to a unifying storage layer is under non too obscure > definitions sort of not non-wonderful... > USB / Firewire / FC / iSCSI are all SCSI transports and fit within the SCSI subsystem by design. ie. Just like ethernet, DSL, T-1, etc can all carry IP traffic with no conceptual conflict, many media by design carry SCSI traffic. The PATA and SATA physical layer typically carry ATA commands and having them tied into the SCSI stack is an aberration that I hope will be eliminated some day. ATAPI is an exception. Not sure where that would end up in a perfect world. Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with IDE on linux 2.6.22.X
On 8/30/07, Rene Herman [EMAIL PROTECTED] wrote: On 08/30/2007 09:31 PM, Jan Engelhardt wrote: On Aug 28 2007 19:05, Rene Herman wrote: Sheesh. How could anyone _not_ understand you need SCSI CD-ROM support for your IDE DVD-RW drive... Welcome to the wonderful world of SCSIfying ATA. (Don't talk about ATAPI, USB/Firewire, it's a different matter.) Well -- the world where ATA, SCSI, USB, Firewire and what have you are low-level drivers to a unifying storage layer is under non too obscure definitions sort of not non-wonderful... USB / Firewire / FC / iSCSI are all SCSI transports and fit within the SCSI subsystem by design. ie. Just like ethernet, DSL, T-1, etc can all carry IP traffic with no conceptual conflict, many media by design carry SCSI traffic. The PATA and SATA physical layer typically carry ATA commands and having them tied into the SCSI stack is an aberration that I hope will be eliminated some day. ATAPI is an exception. Not sure where that would end up in a perfect world. Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer The Norcross Group The Intersection of Evidence Technology http://www.norcrossgroup.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Loud "pop" coming from hard drive on reboot
On 4/18/07, Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote: On Wednesday 18 April 2007, Chuck Ebbert wrote: > Mark Lord wrote: > > Mark Lord wrote: > >> > >> With the patch applied, I don't see *any* new activity in those > >> S.M.A.R.T. > >> attributes over multiple hibernates (Linux "suspend-to-disk"). > > > > Scratch that -- operator failure. ;) > > The patch makes no difference over hibernates in the SMART logs. > > > > It's still logging extra Power-Off_Retract_Count pegs, > > which it DID NOT USED TO DO not so long ago. > > > > Just to add to the fun, my problems are happening with the "old" > IDE drivers... The issue you are experiencing results in the same problem (disk doing power off retract) but it has a totally different root cause - your notebook loses power on reboot. It is actually a hardware problem and as you have reported the same problem is present when using "the other" OS. I think that the issue needs to be fixed (by detecting affected notebook(s) using DMI?) in Linux PM handling and not in IDE subsystem because: * there may be some other hardware devices affected by the power loss (== they require shutdown sequence) * the same problem will bite if somebody decides to use libata (FC7?) Bart OpenSUSE 10.3 is still in Alpha stage (at least a few months away from release), but they too have switched to libata by default. (You can override by adding a boot param). Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Loud pop coming from hard drive on reboot
On 4/18/07, Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] wrote: On Wednesday 18 April 2007, Chuck Ebbert wrote: Mark Lord wrote: Mark Lord wrote: With the patch applied, I don't see *any* new activity in those S.M.A.R.T. attributes over multiple hibernates (Linux suspend-to-disk). Scratch that -- operator failure. ;) The patch makes no difference over hibernates in the SMART logs. It's still logging extra Power-Off_Retract_Count pegs, which it DID NOT USED TO DO not so long ago. Just to add to the fun, my problems are happening with the old IDE drivers... The issue you are experiencing results in the same problem (disk doing power off retract) but it has a totally different root cause - your notebook loses power on reboot. It is actually a hardware problem and as you have reported the same problem is present when using the other OS. I think that the issue needs to be fixed (by detecting affected notebook(s) using DMI?) in Linux PM handling and not in IDE subsystem because: * there may be some other hardware devices affected by the power loss (== they require shutdown sequence) * the same problem will bite if somebody decides to use libata (FC7?) Bart OpenSUSE 10.3 is still in Alpha stage (at least a few months away from release), but they too have switched to libata by default. (You can override by adding a boot param). Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch ide-dev 3/9] merge LBA28 and LBA48 Host Protected Area support code
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
<[EMAIL PROTECTED]> wrote:
> On Thu, 24 Feb 2005 17:30:55 +0100, Bartlomiej Zolnierkiewicz
> <[EMAIL PROTECTED]> 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
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch ide-dev 3/9] merge LBA28 and LBA48 Host Protected Area support code
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
[EMAIL PROTECTED] wrote:
On Thu, 24 Feb 2005 17:30:55 +0100, Bartlomiej Zolnierkiewicz
[EMAIL PROTECTED] 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
6hdc: max request size: 1024KiB
6hdc: Host Protected Area detected.
4 current capacity is 50001 sectors (25 MB)
4 native capacity is 160836480 sectors (82348 MB)
4hdc: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
4hdc: task_no_data_intr: error=0x04 { DriveStatusError }
4ide: failed opcode was: 0x37
6hdc: 50001 sectors (25 MB) w/1719KiB Cache, CHS=49/255/63, UDMA(100)
7hdc: 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch ide-dev 3/9] merge LBA28 and LBA48 Host Protected Area support code
On Thu, 24 Feb 2005 17:30:55 +0100, Bartlomiej Zolnierkiewicz
<[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch ide-dev 3/9] merge LBA28 and LBA48 Host Protected Area support code
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.
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.
Is there some reason for this behavior or is one case or the other a bug?
Does this patch somehow address the inconsistency?
Am I right in assuming this behavior also exists in the vanilla
kernels?. ie. I doubt that vendors are patching this behavior.
Thanks
Greg
--
Greg Freemyer
On Thu, 24 Feb 2005 15:39:51 +0100 (CET), Bartlomiej Zolnierkiewicz
<[EMAIL PROTECTED]> wrote:
>
> * merge idedisk_read_native_max_address()
> and idedisk_read_native_max_address_ext()
> * merge idedisk_set_max_address()
> and idedisk_set_max_address_ext()
>
> diff -Nru a/drivers/ide/ide-disk.c b/drivers/ide/ide-disk.c
> --- a/drivers/ide/ide-disk.c2005-02-19 17:22:44 +01:00
> +++ b/drivers/ide/ide-disk.c2005-02-19 17:22:44 +01:00
> @@ -325,32 +325,7 @@
> * Queries for true maximum capacity of the drive.
> * Returns maximum LBA address (> 0) of the drive, 0 if failed.
> */
> -static unsigned long idedisk_read_native_max_address(ide_drive_t *drive)
> -{
> - ide_task_t args;
> - struct ata_taskfile *tf =
> - unsigned long addr = 0;
> -
> - /* Create IDE/ATA command request structure */
> - memset(, 0, sizeof(ide_task_t));
> -
> - tf->device = 0x40;
> - tf->command = WIN_READ_NATIVE_MAX;
> -
> - args.command_type = IDE_DRIVE_TASK_NO_DATA;
> - args.handler= _no_data_intr;
> - /* submit command request */
> - ide_raw_taskfile(drive, , NULL);
> -
> - /* if OK, compute maximum address value */
> - if ((tf->command & 1) == 0) {
> - addr = (u32)ide_tf_get_address(tf);
> - addr++; /* since the return value is (maxlba - 1), we add 1 */
> - }
> - return addr;
> -}
> -
> -static unsigned long long idedisk_read_native_max_address_ext(ide_drive_t
> *drive)
> +static u64 idedisk_read_native_max_address(ide_drive_t *drive, unsigned int
> lba48)
> {
> ide_task_t args;
> struct ata_taskfile *tf =
> @@ -360,13 +335,15 @@
> memset(, 0, sizeof(ide_task_t));
>
> tf->device = 0x40;
> - tf->command = WIN_READ_NATIVE_MAX_EXT;
> + if (lba48) {
> + tf->command = WIN_READ_NATIVE_MAX_EXT;
> + tf->flags |= ATA_TFLAG_LBA48;
> + } else
> + tf->command = WIN_READ_NATIVE_MAX;
>
> args.command_type = IDE_DRIVE_TASK_NO_DATA;
> args.handler= _no_data_intr;
>
> - tf->flags |= ATA_TFLAG_LBA48;
> -
> /* submit command request */
> ide_raw_taskfile(drive, , NULL);
>
> @@ -382,35 +359,7 @@
> * Sets maximum virtual LBA address of the drive.
> * Returns new maximum virtual LBA address (> 0) or 0 on failure.
> */
> -static unsigned long idedisk_set_max_address(ide_drive_t *drive, unsigned
> long addr_req)
> -{
> - ide_task_t args;
> - struct ata_taskfile *tf =
> - unsigned long addr_set = 0;
> -
> - addr_req--;
> - /* Create IDE/ATA command request structure */
> - memset(, 0, sizeof(ide_task_t));
> -
> - tf->lbal= addr_req;
> - tf->lbam= addr_req >> 8;
> - tf->lbah= addr_req >> 16;
> - tf->device = ((addr_req >> 24) & 0xf) | 0x40;
> - tf->command = WIN_SET_MAX;
> -
> - args.command_type = IDE_DRIVE_TASK_NO_DATA;
> - args.handler= _no_data_intr;
> - /* submit command request */
> - ide_raw_taskfile(drive, , NULL);
> - /* if OK, read new maximum address value */
> - if ((tf->command & 1) == 0) {
> - addr_set = (u32)ide_tf_get_address(tf);
> - addr_set++;
> - }
> - return addr_set;
> -}
> -
> -static unsigned long long idedisk_set_max_address_ext(ide_drive_t *drive,
> unsigned long long addr_req)
> +static u64 idedisk_set_max_address(ide_drive_t *drive, u64 addr_req,
> unsigned int lba48)
> {
> ide_task_t args;
> struct ata_taskfile *tf =
> @@ -423,17 +372,22 @@
> tf->lbal= addr_req;
> tf
Re: [patch ide-dev 3/9] merge LBA28 and LBA48 Host Protected Area support code
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.
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.
Is there some reason for this behavior or is one case or the other a bug?
Does this patch somehow address the inconsistency?
Am I right in assuming this behavior also exists in the vanilla
kernels?. ie. I doubt that vendors are patching this behavior.
Thanks
Greg
--
Greg Freemyer
On Thu, 24 Feb 2005 15:39:51 +0100 (CET), Bartlomiej Zolnierkiewicz
[EMAIL PROTECTED] wrote:
* merge idedisk_read_native_max_address()
and idedisk_read_native_max_address_ext()
* merge idedisk_set_max_address()
and idedisk_set_max_address_ext()
diff -Nru a/drivers/ide/ide-disk.c b/drivers/ide/ide-disk.c
--- a/drivers/ide/ide-disk.c2005-02-19 17:22:44 +01:00
+++ b/drivers/ide/ide-disk.c2005-02-19 17:22:44 +01:00
@@ -325,32 +325,7 @@
* Queries for true maximum capacity of the drive.
* Returns maximum LBA address ( 0) of the drive, 0 if failed.
*/
-static unsigned long idedisk_read_native_max_address(ide_drive_t *drive)
-{
- ide_task_t args;
- struct ata_taskfile *tf = args.tf;
- unsigned long addr = 0;
-
- /* Create IDE/ATA command request structure */
- memset(args, 0, sizeof(ide_task_t));
-
- tf-device = 0x40;
- tf-command = WIN_READ_NATIVE_MAX;
-
- args.command_type = IDE_DRIVE_TASK_NO_DATA;
- args.handler= task_no_data_intr;
- /* submit command request */
- ide_raw_taskfile(drive, args, NULL);
-
- /* if OK, compute maximum address value */
- if ((tf-command 1) == 0) {
- addr = (u32)ide_tf_get_address(tf);
- addr++; /* since the return value is (maxlba - 1), we add 1 */
- }
- return addr;
-}
-
-static unsigned long long idedisk_read_native_max_address_ext(ide_drive_t
*drive)
+static u64 idedisk_read_native_max_address(ide_drive_t *drive, unsigned int
lba48)
{
ide_task_t args;
struct ata_taskfile *tf = args.tf;
@@ -360,13 +335,15 @@
memset(args, 0, sizeof(ide_task_t));
tf-device = 0x40;
- tf-command = WIN_READ_NATIVE_MAX_EXT;
+ if (lba48) {
+ tf-command = WIN_READ_NATIVE_MAX_EXT;
+ tf-flags |= ATA_TFLAG_LBA48;
+ } else
+ tf-command = WIN_READ_NATIVE_MAX;
args.command_type = IDE_DRIVE_TASK_NO_DATA;
args.handler= task_no_data_intr;
- tf-flags |= ATA_TFLAG_LBA48;
-
/* submit command request */
ide_raw_taskfile(drive, args, NULL);
@@ -382,35 +359,7 @@
* Sets maximum virtual LBA address of the drive.
* Returns new maximum virtual LBA address ( 0) or 0 on failure.
*/
-static unsigned long idedisk_set_max_address(ide_drive_t *drive, unsigned
long addr_req)
-{
- ide_task_t args;
- struct ata_taskfile *tf = args.tf;
- unsigned long addr_set = 0;
-
- addr_req--;
- /* Create IDE/ATA command request structure */
- memset(args, 0, sizeof(ide_task_t));
-
- tf-lbal= addr_req;
- tf-lbam= addr_req 8;
- tf-lbah= addr_req 16;
- tf-device = ((addr_req 24) 0xf) | 0x40;
- tf-command = WIN_SET_MAX;
-
- args.command_type = IDE_DRIVE_TASK_NO_DATA;
- args.handler= task_no_data_intr;
- /* submit command request */
- ide_raw_taskfile(drive, args, NULL);
- /* if OK, read new maximum address value */
- if ((tf-command 1) == 0) {
- addr_set = (u32)ide_tf_get_address(tf);
- addr_set++;
- }
- return addr_set;
-}
-
-static unsigned long long idedisk_set_max_address_ext(ide_drive_t *drive,
unsigned long long addr_req)
+static u64 idedisk_set_max_address(ide_drive_t *drive, u64 addr_req,
unsigned int lba48)
{
ide_task_t args;
struct ata_taskfile *tf = args.tf;
@@ -423,17 +372,22 @@
tf-lbal= addr_req;
tf-lbam= addr_req 8;
tf-lbah= addr_req 16;
- tf-device = 0x40;
- tf-command = WIN_SET_MAX_EXT;
- tf-hob_lbal= addr_req 24;
- tf-hob_lbam= addr_req 32;
- tf-hob_lbah= addr_req 40;
+ if (lba48) {
+ tf-hob_lbal= addr_req 24;
+ tf-hob_lbam= addr_req 32;
+ tf-hob_lbah= addr_req 40;
+ tf-device = 0x40
Re: [patch ide-dev 3/9] merge LBA28 and LBA48 Host Protected Area support code
On Thu, 24 Feb 2005 17:30:55 +0100, Bartlomiej Zolnierkiewicz
[EMAIL PROTECTED] 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
6hdc: max request size: 1024KiB
6hdc: Host Protected Area detected.
4 current capacity is 50001 sectors (25 MB)
4 native capacity is 160836480 sectors (82348 MB)
4hdc: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
4hdc: task_no_data_intr: error=0x04 { DriveStatusError }
4ide: failed opcode was: 0x37
6hdc: 50001 sectors (25 MB) w/1719KiB Cache, CHS=49/255/63, UDMA(100)
7hdc: 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
