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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ST31000340NS (1000G) Capacity equal 33MB issue.
On Feb 17, 2008 2:18 PM, Mark Lord [EMAIL PROTECTED] wrote: Richard Liu wrote: Dear Mark: 2008/2/16, Mark Lord [EMAIL PROTECTED]: Mark Lord wrote: Richard Liu wrote: Thanks. By running the above data through hdparm --Istdin, I see that the drive is indeed identifying itself as a 33MB drive. Probably because it has been told to do so by either the factory defaults, or the BIOS, having enabled these features (which can cause it to report fake values for various things): *Host Protected Area feature set *Device Configuration Overlay feature set So that's why the 1TB drive appears as a 33MB drive. In the near future, I will be enhancing hdparm to query more detailed data from underneath those artificial features. But you'll have to enable the entire 1TB capacity if you want Linux to use it. It is currently disabled in the drive, and Linux respects that. .. Okay, hdparm-8.1 is now available from sourceforge.net. Download it, build it (make), and see what you get from hdparm -N /dev/sdc Thanks I downloaded hdparm-8.1 and here is output information. # ./hdparm -N /dev/sdc /dev/sdc: max sectors = 65134/1953525168, HPA is enabled .. Yes, pretty much as expected there. You can safely now try this: ./hdparm -N1953525168 /dev/sdc If that works, it will have temporarily restored access to the entire drive. Then you can try to make it permanent by doing this: ./hdparm -Np1953525168 /dev/sdc If *that* also works, then reboot and things should be fine, unless your machine BIOS changes it back again on boot.. :/ If either of those *fails*, then it is because your BIOS (or possibly the system startup scripts) have frozen the configuration to prevent changes. Dunno why they would do that, but it's possible. In which case, you could move the drive to another machine temporarily, and then issue that same command there. Cheers Mark, Very cool new functionality in 8.1 Looking forward to testing it this week. Thanks for your efforts. I assume DCO is still able to hide sectors from us? 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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ST31000340NS (1000G) Capacity equal 33MB issue.
On Thu, Feb 14, 2008 at 1:18 PM, Richard Liu [EMAIL PROTECTED] wrote: Hello all: I bought a Seagate ES.2 ST31000340NS (1000GB) and run at Gentoo Linux kernel 2.6.24. But Linux kernel report the disk size only 33MB. I tried Intel ICH5 and Sil3112, but get the same result. I don't know this issue was caused by libsata or scsi layer . Don't ignore the controllers themselves. I am in the process of upgrading the firmware on several 4 month old sig 3512s because they won't even let the computer boot with a 1TB drive connected. ie. they lockup during the bios phase. Previously, I've also had to upgrade older SIG PATA controllers to get them to see past 500GB. Sig has new firmware on their site, but you have to do the upload from DOS. (or supposedly windows. Don't know about that.). ie. use a boot floppy or a boot thumb drive. 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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Trouble with hdparm -d on Dell D610
On Jan 11, 2008 4:34 PM, Alan Cox [EMAIL PROTECTED] wrote: most of the machines I encounter (and with both SATA and IDE drives), except for the Dell D610 and HP 7700 (small desktop pc). The models I just mentioned run the shred really slow, which I believe is due to the DMA problem I was having (outlined in my previous emails). Any thoughts? If your shred program is relying on DMA then you are using the wrong tool for the job. The correct way to erase a disk is to send it a security erase command. Rewriting over the data may not do what is wanted. Alan, I was talking to Kristin this morning about doing that. I was concerned that there is not anybody certifying that each individual disk drive model / firmware release is properly implementing the Security Erase function. Are you aware of testing body, etc. that publishes a white-list of drives that are known to have a proper implementation of Security Erase? Lacking something like that and realizing how rarely it is used, I'm not sure it should be trusted. Performing both a Security Erase and calling shred on the drive might be the ultimate one-two punch. 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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Trouble with hdparm -d on Dell D610
On Jan 11, 2008 4:49 PM, Kristin Vadas Marsicano [EMAIL PROTECTED] wrote: On 1/11/08, Alan Cox [EMAIL PROTECTED] wrote: My concern with disabling the new drivers is as follows: I use this linux kernel and config image to boot machines over PXE and call a shred program on each of the harddrives. If I turn off CONFIG_ATA, will this limit my ability to support various new IDE and SATA drives for running shred? So far, the configuration I have works well with Yes. In that case you can build without CONFIG_IDE_PIIX and with the CONFIG_ATA_PIIX driver and you should be fine too (but your disk will move to /dev/sda on that box). The PIIX is an awkward case as in some modes it combines both the SATA and PATA onto one 'device'. Can I set this option through make menuconfig, or do I need to take some other action? I poked around the menu config a big and wasn't sure I found the properties you are refering to. Would all my disks then be listed as sd[a-z] on every machine? Or just some? most of the machines I encounter (and with both SATA and IDE drives), except for the Dell D610 and HP 7700 (small desktop pc). The models I just mentioned run the shred really slow, which I believe is due to the DMA problem I was having (outlined in my previous emails). Any thoughts? If your shred program is relying on DMA then you are using the wrong tool for the job. The correct way to erase a disk is to send it a security erase command. Rewriting over the data may not do what is wanted. For now, my desired action is to overwrite the drives with random characters. My understanding is that security erase commands are implemented in the firmware, and that it may be buggy. Please correct me if my understanding is incorrect. Also, is there a way to invoke the firmware security erase with a linux command? Kristin, you can issue Security Erase via hdparm, but don't forget that the Security Erase command is blocked by significant number of BIOS implentations, so switching to it would be a fundamental change to what you do now even if you had confidence that it did work 100% of the time. 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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Enabling MSI in sata_nv
On Dec 2, 2007 10:07 PM, Philip Langdale [EMAIL PROTECTED] wrote: Hi all, At least for my hardware (MCP55), the sata controller supports MSI and it seems that turning it on is as simple as inserting the call to pci_enable_msi - after that it Just Works(tm). Are there any gotchas that I'm missing? Would a patch to do this be accepted? --phil I don't know if it is relevant, but I had to disable MSI to get a MCP55 NIC to work under 2.6.22. See https://bugzilla.novell.com/show_bug.cgi?id=287017#c1 for details if your curious. 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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SAS v SATA interface performance
On Dec 1, 2007 2:43 AM, Richard Scobie [EMAIL PROTECTED] wrote: Alan Cox wrote: If you want really high performance use multiple drives, on multiple PCIE controllers. Just make sure your backup planning of raid 1+0 setup is done right as many drives means a lot more drive fails. Thanks again. For what it's worth, I shall be attempting this with SATA drives in a RAID 50 configuration - 2 x 8 drives, using md RAID and an 8 lane PCIe SAS HBA. I suspect many of us will be curious of the performance results. Also, if you have Port Multiplexers (PMPs) in use, that would be interesting to know. I don't even know if PMPs are supported via SAS controllers in 2.6.24 or not. ie. PMP support is new to 2.6.24 and only a few Sata controllers will have PMP support in 2.6.24. 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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Bart's efforts?
Jeff / Alan, I mostly lurk here, but I know there is a long term effort/ToDo to move libata away from the SCSI infrastructure. I've also seen that Bart has been making a large number of improvements to drivers/ide over the last little while. From my limited perspective, many changes appear to be to the core infrastructure. My question is if the drivers/ide infrastructure is slowly moving in the direction of being leverageable by libata when/if it moves out of scsi. Or does the drivers/ide code simply have the wrong kind of plumbing for libata to ever use. 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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bart's efforts?
Thanks, I was just curious. On 11/3/07, Jeff Garzik [EMAIL PROTECTED] wrote: Greg Freemyer wrote: Jeff / Alan, I mostly lurk here, but I know there is a long term effort/ToDo to move libata away from the SCSI infrastructure. I've also seen that Bart has been making a large number of improvements to drivers/ide over the last little while. From my limited perspective, many changes appear to be to the core infrastructure. My question is if the drivers/ide infrastructure is slowly moving in the direction of being leverageable by libata when/if it moves out of scsi. Or does the drivers/ide code simply have the wrong kind of plumbing for libata to ever use. One of my key goals with libata was to make a driver look like a driver and greatly improve upon the IDE driver API, which was a complete and utter piece of garbage (this is no reflection on Bart, he inherited it). As a result, each driver is a fully fledged PCI/SCSI/ATA/platform driver, without anything getting in the way. That made things like controller hotplug trivial to support from day one. Bart has definitely made many good improvements, but I don't think people would be surprised that I feel CONFIG_IDE is legacy... Jeff -- 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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SATA_SIL
On 10/30/07, Frans de Boer [EMAIL PROTECTED] wrote: Dear Sir, I know, I am not the only one to find out that we can't upgrade to a newer kernel when using SUSE 10.3. It seems that in 2.6.23 the sil modules have been updated (newer versions) and thus render the current system mostly unuseable. I noticed that in the sata_sil24.c source there where a significant number of chances, which are probally not easy to change. Overwriting the newer versions with the versions from 2.6.22.9 might work, but for how long. Is this a problem SUSE introduced, you forgot to take legacy into account or is it a feature. Is this problem adjusted in 2.6.24-rc1? Kind regards, Frans de Boer. Did you try a SUSE factory kernel or a kotd (kernel of the day, 2.6.23.1 based currently) You can find the kotd kernels on thier mirrors. ie. ftp://suse.mirrors.tds.net/pub/projects/kernel/kotd/HEAD is in the US. I don't know if they have released 2.6.23 factory kernels yet. 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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Polling (was Re: [PATCHSET 2/2] implement PMP support, take 6)
On 9/28/07, Jeff Garzik [EMAIL PROTECTED] wrote: (my last response only addressed -mm) Mark Lord wrote: I believe the point was that getting things into libata is glacial IMHO would say that there are two causes of that: 1) I am sometimes slow in merging, part of which is my own fault, and I can only promise to try and do better there. Part of which is a result of stuff being dependent on -mm (which requires plenty of time hand-merging) rather than libata-dev.git#upstream. 2) I have been intentionally staging major libata behavior changes between Linux releases. Luckily most of these are behind us, but, in several cases with things like ACPI on/off (hopefully 'on' in 2.6.24), probing changes (switchover to new EH for probing via hotplug, etc.), interrupt handling changes. I dislike getting too much into a single release, because of the difficulty of getting large scale feedback without a major kernel release. So far I think the kernel releases have been pretty darn successful in not breaking everybody but that clearly conflicts with desired development speed, given the glacial pace of each kernel release. If each kernel release were 1-2 months apart, we would have many more testing points, and I think you guys and I would both be happy. But that's not the reality today, with 3+ month kernel release cycles (ugh!!). I'm very much interested in hearing suggestions and comments. Jeff Perhaps you could more fully leverage the various distro alpha/beta/rcs/release kernels. Specific to the PMP patches, they went into the openSUSE beta/rc kernels (2.6.23 based) in early Aug. I think. So they have already been through a significant set of Novell internal and community testing. Likely similar testing to what it would get in -mm. I believe they are part of the OpenSUSE 10.3 (2.6.23 based) full release that is set for Thursday (Oct. 4) and thus will see a huge amount of public testing. 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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.22-rc6] sata_inic162x: add big fat warning about broken LBA48 support
On 6/28/07, Tejun Heo [EMAIL PROTECTED] wrote:
sata_inic162x can't do LBA48 properly yet. Whine loudly about it to
reduce confusion.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/sata_inic162x.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
Index: work/drivers/ata/sata_inic162x.c
===
--- work.orig/drivers/ata/sata_inic162x.c
+++ work/drivers/ata/sata_inic162x.c
@@ -664,8 +664,12 @@ static int inic_init_one(struct pci_dev
void __iomem * const *iomap;
int i, rc;
- if (!printed_version++)
+ if (!printed_version++) {
dev_printk(KERN_DEBUG, pdev-dev, version DRV_VERSION \n);
+ printk(KERN_WARNING WARNING: sata_inic162x doesn't support
+ LBA48 yet. Devices larger than\n
+ 2^28 - 1 sectors (~127GiB) won't work.\n);
+ }
/* alloc host */
host = ata_host_alloc_pinfo(pdev-dev, ppi, NR_PORTS);
-
Does it simply fail? Or does it corrupt?
In my Windows experience, if you try to write data past ~128GiB and
you don't have LBA48 support you get a wraparound effect that causes
corruption of the data below ~128GiB. I've seen it happen several
times under Win2K in particular.
Greg
--
Greg Freemyer
The Norcross Group
Forensics for the 21st Century
-
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
Re: [PATCH 2.6.22-rc6] sata_inic162x: add big fat warning about broken LBA48 support
On 6/28/07, Tejun Heo [EMAIL PROTECTED] wrote: Greg Freemyer wrote: Does it simply fail? Or does it corrupt? In my Windows experience, if you try to write data past ~128GiB and you don't have LBA48 support you get a wraparound effect that causes corruption of the data below ~128GiB. I've seen it happen several times under Win2K in particular. It will probably wrap and corrupt data. The driver is already marked HIGHLY EXPERIMENTAL. Do you think we need bigger hammer? -- tejun At a minimum the error msg should be much stronger than won't work. Something like will be horribly corrupted and all your valuable data will be lost. Even better from my perspective would be to simply cause a 128GiB drive to be ignored and totally unaccessible. Obviously it should have a message to that effect. ie. Assume you have a partition that spans the 128 GiB barrier. If you allow access to the first half of the partition and not the last, you have another major corruption possibility even though you don't have any wrap-around affects. Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century - 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
Re: sata_promise ata exceptions (2.6.20.6)
On 4/9/07, Phil Dibowitz [EMAIL PROTECTED] wrote: Mikael, Thanks for the quick response. I appreciate your help. I guess I'm buying a SATA PCI card! Looks like my choice of reasonably-priced known-brands is Highpoint and Promise (specifically a Highpoint ROCKETRAID1520 or a Promise SATA300 TX4) - are one of these brands better from a Linux compatibility or hardware-bug standpoint? Quoting an old e-mail from Tejun Heo: === I primarily work on sil controllers and ICH7R piix/ahci because I have access to the hardware and docs. So, those tend to get new features first and get a lot of testing. If you're planning on using Port Multiplier, sil3124/32 would be the best bet ATM. === Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century - 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
Re: libata Patches
On 12/11/06, Kasimir Müller [EMAIL PROTECTED] wrote: Hi Tejun, I have tested your patches with the vanilla 2.6.18.1 - Kernel and it works like a charm. I have spent hours of copying, reading and deleting data to a software-raid-5 on a Machine with Mainboard: Elitegroup K8T890-A Prozessor: Athlon64 Addonics 5X1 eSATA Port Multiplier (PM) (AD5SAPM-E) Addonics SATA-Controller PCIe-Card ADSA3GPX1-2E System: openSuse 10.1 Because Suse uses a patched kernel I cannot apply your patch to the standard-kernel from the openSUSE-Distribution. As far as I can see (I'm not a programmer), the driver-sources are already in the ata-directory of the kernel, so the patch generates a lot of errors. Could give any advice (on your wiki), how to deal with this ? I believe the openSUSE 10.2 kernel will work with openSUSE 10.1 userland tools. Therefore I would get the openSUSE 10.2 kernel (2.6.18 based) and try that. If you then want to apply even more patches you should not have too much trouble applying patches targetting 2.6.18 http://download.opensuse.org/distribution/10.2/repo/src-oss/suse/src/kernel-source-2.6.18.2-34.src.rpm Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century - 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
Re: Host protected area on suspend/resume
On 7/12/05, Tejun Heo wrote: Matthew Garrett wrote: On boot, Linux will attempt to disable the host protected area on a disk. After a suspend/resume cycle, the BIOS may reenable it (seen on a Thinkpad T40 and R40). As a result, the kernel is now unable to access the HPA. Is there any issue with just adding a call to idedisk_check_hpa() in the IDE resume code? This has come up several times now. One thing I'm curious about is why we are disabling HPA on boot without consent from the user. AFAIK, HPA is mostly used to implement hidden recovery/suspend storage areas and disabling automatically on boot increases the likeliness of destroying them. What do we gain by disabling HPA on boot? Are there some dumb machines which unnecessarily sets HPA and reduces the capacity of drives excessively? Even in such cases, wouldn't it be better to do idedisk_check_hpa() only when kernel parameter explicitly says so? -- tejun Crawling out from under my rock, I agree with Tejun. Always enabling access to HPA seems very strange. It also eliminates the ability to use the IDE Offset feature. IIUC, the offset feature is a boolean flag that, when true, basically tells the drive that all LBA references are into the HPA area. By using the HPA in conjunction with the Offset flag, one has the ability to have two complete disk layouts. Each could have its own boot sector, partition table, and partitions. I have never used this feature, but I do have DOS based tools that supposidely control the HPA config. and the state of the offset boolean. I routinely perform forensic image aquires. Normally that is a simple dd if=/dev/hdx.. For me the untlimate would be to have Linux support for something like: disable offset dd normal sectors enable offset dd hpa sectors That way I capture the areas as seperate images and if 2 boot sectors, partition tables, partitions etc. exist I can analyse them seperately. Conclusion, automatically overriding HPA seems to be outside of the normal Linux way of doing things. At a minimum, there should be a flag to prevent it from happening. If it is needed there are existing userspace linux tools that can modify the HPA config. FYI: In addition to HPA potentially reducing usable disk size, the size can also be artificially reduced via DCO. I am not aware of any Linux tools for addressing/eliminating artificial DCO restrictions. Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century - 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
Re: Readahead with softraid1
On 7/8/05, Danny Cox wrote: Erik, On Fri, 2005-07-08 at 14:00 +0200, Erik Slagter wrote: I am using softraid 1 on two sata disks and I'm trying to get the best possible performance. IMHO read actions (if properly addressed) should be split over the two drivers and performed independently. However, I don't notice anything to back this up. The read performance (with the dreaded hdparm) shows read performance on sda,sdb and md0 exactly the same. ... What am I doing wrong here??? Nothing. I'll take a shot at answering this one instead of lurking this time. Then, I'll crawl back under my rock. The raid1 driver keeps a last visited block for each drive. This is the block number that was most recently read or written by that drive. When a read request arrives, the driver examines each drive for the nearest last visited block to the one requested. Guess what? If the read starts with drive sda, then it will *always* be the one chosen to service the read in the future, because the last visited block number is only one off. This would only change if there are multiple processes performing I/O on the md device. Then, it may switch to another drive. In any case, it will *tend* to stick with the same drive. Did I explain that well, or only muddy the waters? -- Daniel S. Cox Internet Commerce Corporation Interesting. Unfortunately, I do a lot of sequential reading with little or no other computer activity and had wondered about the slow speed of RAID 1 on read. Does anyone know if that a common implementation on Hardware Raid controllers too? I have actually been working mostly with 3ware 7000 series cards, so the md implementation does not affect me, but if that is a common design then the 3ware card may have a similar algorithm. Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century - 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
Re: Bug: Resume with Host Protected Area
IMHO, if you are going to put live data in the HPA, you really should just kill the HPA permanently not depend on Linux to do a volitile reset on every reboot/resume. See setmax at http://www.win.tue.nl/~aeb/linux/setmax.c You can compile that and use it to permanently modify your HPA setting. use the -m (--max) option to permanently modify your HPA setting. You can also use -d to make volitile changes. IIRC, volitile changes to are reset on every power cycle of the drive. HTH, Greg -- Greg Freemyer On 4/19/05, Shane Hathaway [EMAIL PROTECTED] wrote: Until today, I haven't been able to reliably put my ThinkPad T41 to sleep. After resuming, it generated lots of disk errors, and only a reboot would bring it back to sanity. Today I finally realized what's going on. This laptop has a 3.5 GB protected area at the end of the drive. Linux disables the protection on bootup (making the whole drive available), but the laptop apparently re-enables the protection during the sleep cycle. So I moved my partitions out of the protected area and now the laptop finally resumes correctly. Yehaw! The bugfix should be simple: call idedisk_check_hpa() during resume. I'm not subscribed to this list, so please CC me on replies. Shane - 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 The Norcross Group Forensics for the 21st Century - 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
Re: 'hdparm -C' problems with libata-dev
On Apr 12, 2005 10:00 AM, John W. Linville [EMAIL PROTECTED] wrote:
On Fri, Apr 08, 2005 at 04:03:21PM +0200, Gerald Hopf wrote:
Is there anything i can do to make this ('hdparm -C') work? Is this a
libata bug or missing feature? A Seagate Firmware bug? A hdparm problem?
Or just not possible with SATA Drives?
Sounds like a bug w/ my implementation of HDIO_DRIVE_CMD for libata.
However, I have yet to take the opportunity to track it down. Plus,
I'll be taking a little vacation over the coming weekend, so I likely
won't get to this until sometime next week... :-(
Until then, please feel free to experiment more w/ hdparm to see if
there are any other problems w/ hdparm on SATA. Please copy me on
reports of any such problems (or send them to me directly). Thanks!
John
--
John W. Linville
[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
I reported that hdparm -r was not working with PATA drives a couple
months ago. I got no feedback, but if someone can test it with SATA I
would be curious if it works.
Greg
--
Greg Freemyer
The Norcross Group
Forensics for the 21st Century
-
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
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-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
