[PATCH UPDATED] libata: add support for ATA_16 on ATAPI
From: Mark Lord <[EMAIL PROTECTED]>
Add support for issuing ATA_16 passthru commands to ATAPI devices
managed by libata. It requires the previous CDB length fix patch.
A boot/module parameter, "atapi_scmd85=1" can be used to globally
disable this feature, if ever desired.
tj: renamed ata16_passthru module param to atapi_scmd85 to reduce
confusion
tj: restructured __ata_scsi_queuecmd() according to Jeff's suggestion.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
Jeff, Mark, are you guys okay with the modified version?
Thanks.
drivers/ata/libata-core.c |4 +++
drivers/ata/libata-scsi.c | 52 +++---
drivers/ata/libata.h |1
3 files changed, 41 insertions(+), 16 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 6001aae..d8c6789 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -86,6 +86,10 @@ int atapi_dmadir = 0;
module_param(atapi_dmadir, int, 0444);
MODULE_PARM_DESC(atapi_dmadir, "Enable ATAPI DMADIR bridge support (0=off,
1=on)");
+int atapi_scmd85 = 0;
+module_param(atapi_scmd85, int, 0444);
+MODULE_PARM_DESC(atapi_scmd85, "Enable relay of SCSI opcode 0x85 and disable
ATA_16 passthrough to ATAPI devices (0=off, 1=on)");
+
int libata_fua = 0;
module_param_named(fua, libata_fua, int, 0444);
MODULE_PARM_DESC(fua, "FUA support (0=off, 1=on)");
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 12ac0b5..568180b 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -2746,28 +2746,48 @@ static inline int __ata_scsi_queuecmd(struct scsi_cmnd
*scmd,
void (*done)(struct scsi_cmnd *),
struct ata_device *dev)
{
+ u8 scsi_op = scmd->cmnd[0];
+ ata_xlat_func_t xlat_func;
int rc = 0;
- if (unlikely(!scmd->cmd_len || scmd->cmd_len > dev->cdb_len)) {
- DPRINTK("bad CDB len=%u, max=%u\n",
- scmd->cmd_len, dev->cdb_len);
- scmd->result = DID_ERROR << 16;
- done(scmd);
- return 0;
- }
-
if (dev->class == ATA_DEV_ATA) {
- ata_xlat_func_t xlat_func = ata_get_xlat_func(dev,
- scmd->cmnd[0]);
+ if (unlikely(!scmd->cmd_len || scmd->cmd_len > dev->cdb_len))
+ goto bad_cdb_len;
- if (xlat_func)
- rc = ata_scsi_translate(dev, scmd, done, xlat_func);
- else
- ata_scsi_simulate(dev, scmd, done);
- } else
- rc = ata_scsi_translate(dev, scmd, done, atapi_xlat);
+ xlat_func = ata_get_xlat_func(dev, scsi_op);
+ } else {
+ if (unlikely(!scmd->cmd_len))
+ goto bad_cdb_len;
+
+ xlat_func = NULL;
+ if (likely((scsi_op != ATA_16) || atapi_scmd85)) {
+ /* relay SCSI command to ATAPI device */
+ if (unlikely(scmd->cmd_len > dev->cdb_len))
+ goto bad_cdb_len;
+
+ xlat_func = atapi_xlat;
+ } else {
+ /* ATA_16 passthru, treat as an ATA command */
+ if (unlikely(scmd->cmd_len > 16))
+ goto bad_cdb_len;
+
+ xlat_func = ata_get_xlat_func(dev, scsi_op);
+ }
+ }
+
+ if (xlat_func)
+ rc = ata_scsi_translate(dev, scmd, done, xlat_func);
+ else
+ ata_scsi_simulate(dev, scmd, done);
return rc;
+
+ bad_cdb_len:
+ DPRINTK("bad CDB len=%u, scsi_op=0x%02x, max=%u\n",
+ scmd->cmd_len, scsi_op, dev->cdb_len);
+ scmd->result = DID_ERROR << 16;
+ done(scmd);
+ return 0;
}
/**
diff --git a/drivers/ata/libata.h b/drivers/ata/libata.h
index 564cd23..59a71fc 100644
--- a/drivers/ata/libata.h
+++ b/drivers/ata/libata.h
@@ -56,6 +56,7 @@ extern unsigned int ata_print_id;
extern struct workqueue_struct *ata_aux_wq;
extern int atapi_enabled;
extern int atapi_dmadir;
+extern int atapi_scmd85;
extern int libata_fua;
extern int libata_noacpi;
extern struct ata_queued_cmd *ata_qc_new_init(struct ata_device *dev);
diff --git a/include/linux/libata.h b/include/linux/libata.h
-
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 3/4] Enable link power management for ata drivers
Kristen Carlson Accardi wrote:
> libata drivers can define a function (enable_pm) that will
> perform hardware specific actions to enable whatever power
> management policy the user set up from the scsi sysfs
> interface if the driver supports it. This power management
> policy will be activated after all disks have been
> enumerated and intialized. Drivers should also define
> disable_pm, which will turn off link power management, but
> not change link power management policy.
>
> Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
Please update the patch against the current libata-dev#upstream and
there are several lines where tab follows space and git-applymbox isn't
happy about it. Those lines are in other patches too.
> +int ata_scsi_set_link_pm_policy(struct Scsi_Host *shost,
> + enum scsi_host_link_pm policy)
> +{
> + struct ata_port *ap = ata_shost_to_port(shost);
> + int rc = -EINVAL;
> + int i;
> +
> + /*
> + * make sure no broken devices are on this port,
> + * and that all devices support interface power
> + * management
> + */
> + for (i = 0; i < ATA_MAX_DEVICES; i++) {
> + struct ata_device *dev = &ap->device[i];
> +
> + /* only check drives which exist */
> + if (!ata_dev_enabled(dev))
> + continue;
> +
> + /*
> + * do we need to handle the case where we've hotplugged
> + * a broken drive (since hotplug and ALPM are mutually
> + * exclusive) ?
> + *
> + * If so, if we detect a broken drive on a port with
> + * alpm already enabled, then we should reset the policy
> + * to off for the entire port.
> + */
> + if ((dev->horkage & ATA_HORKAGE_ALPM) ||
> + !(dev->flags & ATA_DFLAG_IPM)) {
> + ata_dev_printk(dev, KERN_ERR,
> + "Unable to set Link PM policy\n");
> + ap->pm_policy = SHOST_MAX_PERFORMANCE;
> + }
> + }
> +
> + if (ap->ops->enable_pm)
> + rc = ap->ops->enable_pm(ap, policy);
> +
> + if (!rc)
> + shost->shost_link_pm_policy = ap->pm_policy;
> + return rc;
> +}
> +EXPORT_SYMBOL_GPL(ata_scsi_set_link_pm_policy);
This function is directly called from SCSI sysfs write, right? You
can't do this without synchronizing with EH. The best way is to define
an EH action and ask EH to transit between powersave states.
> @@ -2021,6 +2021,9 @@ int ata_dev_configure(struct ata_device
> if (dev->flags & ATA_DFLAG_LBA48)
> dev->max_sectors = ATA_MAX_SECTORS_LBA48;
>
> + if (ata_id_has_hipm(dev->id) || ata_id_has_dipm(dev->id))
> + dev->flags |= ATA_DFLAG_IPM;
Is it safe to use ALPM on a device which only claims to support DIPM?
> @@ -2046,6 +2049,13 @@ int ata_dev_configure(struct ata_device
> dev->max_sectors = min_t(unsigned int, ATA_MAX_SECTORS_128,
>dev->max_sectors);
>
> + if (ata_device_blacklisted(dev) & ATA_HORKAGE_ALPM) {
> + dev->horkage |= ATA_HORKAGE_ALPM;
I think this should be ATA_HORKAGE_IPM.
> @@ -6385,6 +6426,8 @@ int ata_host_register(struct ata_host *h
> struct ata_port *ap = host->ports[i];
>
> ata_scsi_scan_host(ap);
> + ata_scsi_set_link_pm_policy(ap->scsi_host,
> + ap->pm_policy);
Again, this should be done from EH.
> @@ -321,6 +321,8 @@ struct ata_taskfile {
> ((u64) (id)[(n) + 0]) )
>
> #define ata_id_cdb_intr(id) (((id)[0] & 0x60) == 0x20)
> +#define ata_id_has_hipm(id) ((id)[76] & (1 << 9))
> +#define ata_id_has_dipm(id) ((id)[78] & (1 << 3))
We probably need !0x test here.
--
tejun
-
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 1/4] Store interrupt value
Kristen Carlson Accardi wrote: > Use a stored value for which interrupts to enable. Changing this allows > us to selectively turn off certain interrupts later and have them > stay off. > > Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]> Acked-by: Tejun Heo <[EMAIL PROTECTED]> -- tejun - 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
ST340823A disk size issue
Hello,
(More details at http://bugzilla.kernel.org/show_bug.cgi?id=8816 )
My home server disk doesn't work with latest kernels since its size is
reported or probed correctly. With 2.6.22.1 I get:
Probing IDE interface ide1...
hdd: ST340823A, ATA DISK drive
hdd: selected mode 0x42
...
hdd: max request size: 128KiB
hdd: Host Protected Area detected.
current capacity is 78165360 sectors (40020 MB)
native capacity is 78165361 sectors (40020 MB)
hdd: Host Protected Area disabled.
hdd: 78165361 sectors (40020 MB) w/1024KiB Cache, CHS=65535/16/63,
UDMA(33)
hdd: cache flushes not supported
hdd: hdd1 hdd2 hdd3
hdd: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdd: dma_intr: error=0x10 { SectorIdNotFound }, LBAsect=78165360,
sector=78165360
ide: failed opcode was: unknown
hdd: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdd: dma_intr: error=0x10 { SectorIdNotFound }, LBAsect=78165360,
sector=78165360
ide: failed opcode was: unknown
hdd: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdd: dma_intr: error=0x10 { SectorIdNotFound }, LBAsect=78165360,
sector=78165360
...
And as said shows in bugzilla, badblocks, fsck and smartctl think the
drive is not broken or going to die too soon.
What's the difference between the size formats of
WIN_READ_NATIVE_MAX_EXT read by
ide-disk.c/idedisk_read_native_max_address_ext() and (hdreg.h)
hd_driveid->lba_capacity_2 read by, if I read drivers/ide/* code
correctly, ide-probe.c/do_identify()?
If this disk is reporting one of these wrong, which fix could be
applied?
Both disabling 'stroke' and removing addr++ in
ide-disk.c/idedisk_read_native_max_address*() fix the problem, but if
kernel code is correct and standard compliant, these fixes are out of
the question.
Perhaps a boot parameter to kernel could force the disk sector count to
some value for buggy drives?
-Mikko
-
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 3/4] Enable link power management for ata drivers
On 8/1/07, Tejun Heo <[EMAIL PROTECTED]> wrote: > > > > + if (ata_id_has_hipm(dev->id) || ata_id_has_dipm(dev->id)) > > + dev->flags |= ATA_DFLAG_IPM; > > Is it safe to use ALPM on a device which only claims to support DIPM? I have tested on a Dell Inspiron 6400, it has ICH7-M (82801GBM) chipset. The harddisk claims to support only DIPM, and the ALPM patches work with it. Kristen said either DIPM or HIPM will work with ALPM accord to the spec, see this email: http://www.bughost.org/pipermail/power/2007-June/000691.html --Edwin - 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/4] Expose Power Management Policy option to users
Tejun Heo wrote: > Arjan van de Ven wrote: >>> They were hardware problems. I don't think any amount of proper >>> implementation can fix them. I have one DVD RAM somewhere in my pile of >>> hardware which locks up solidly if any link PS mode is used and had a >> and the AHCI ALPM code decides to use power savings on this device? if >> so, please give us the idents so that we can add it to the blacklist as >> the first entry... (or can buy it to check it in detail first) > > Yeap, lemme check. > > It's "TSSTcorpCD/DVDW SH-S183A" with firmware revision "SB01". Wanna > check ID capability bits but 'hdparm -I /dev/sr0' is still broken and > it's already past 3 am here. I'll report back tomorrow. Oops, that was the wrong one. Locking up one was HL-DT-STDVD-RAM GSA-H30N and it correctly reports that it doesn't support IPM. Here are some test results. Controller is ICH9. 00:1f.2 SATA controller [Class 0106]: Intel Corporation Unknown device [8086:2922] (rev 02) 1. HL-DT-STDVD-RAM GSA-H30N ATAPI CD-ROM, with removable media Model Number: HL-DT-STDVD-RAM GSA-H30N Serial Number: Firmware Revision: 1.00 Standards: Likely used CD-ROM ATAPI-1 Configuration: DRQ response: 50us. Packet size: 12 bytes Capabilities: LBA, IORDY(can be disabled) DMA: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120 This device doesn't claim to support HIPM nor DIPM. # echo min_power > link_power_management_policy [ 752.761751] ata1.00: Unable to set Link PM policy [ 784.510218] ata1.00: exception Emask 0x50 SAct 0x0 SErr 0xd0800 action 0x6 frozen [ 784.530266] ata1.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x43 data 12 in [ 784.530270] res 40/00:03:00:00:20/00:00:00:00:00/a0 Emask 0x54 (ATA bus error) [ 784.571175] ata1: hard resetting port [ 790.489486] ata1: port is slow to respond, please be patient (Status 0x80) [ 794.594247] ata1: COMRESET failed (errno=-16) [ 794.611174] ata1: hard resetting port [ 800.541562] ata1: port is slow to respond, please be patient (Status 0x80) [ 804.646316] ata1: COMRESET failed (errno=-16) [ 804.663284] ata1: hard resetting port [ 810.593623] ata1: port is slow to respond, please be patient (Status 0x80) [ 839.654644] ata1: COMRESET failed (errno=-16) [ 839.672576] ata1: limiting SATA link speed to 1.5 Gbps [ 839.691024] ata1: hard resetting port [ 844.726659] ata1: COMRESET failed (errno=-16) [ 844.744064] ata1: reset failed, giving up [ 844.761614] ata1.00: disabled [ 844.761639] ata1: EH complete The device doesn't respond till power is physically removed and restored. It seems something in ahci_disable_alpm() path upsets the device. 2. TSSTcorpCD/DVDW SH-S183A ATAPI CD-ROM, with removable media Model Number: TSSTcorpCD/DVDW SH-S183A Serial Number: Firmware Revision: SB01 Standards: Likely used CD-ROM ATAPI-1 Configuration: DRQ response: 50us. Packet size: 12 bytes Capabilities: LBA, IORDY(can be disabled) DMA: mdma0 mdma1 mdma2 udma0 udma1 *udma2 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120ns Commands/features: Enabled Supported: *SATA-I signaling speed (1.5Gb/s) *Host-initiated interface power management *Phy event counters Device-initiated interface power management unknown 78[5] *Software settings preservation This one claims to support HIPS. # echo min_power > link_power_management_policy [ 1301.917248] ata1.00: exception Emask 0x10 SAct 0x0 SErr 0x5 action 0x2 [ 1301.938338] ata1.00: irq_stat 0x4001 [ 1301.956955] ata1.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x43 data 12 in [ 1301.956959] res 51/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x10 (ATA bus error) [ 1304.189565] ata1: soft resetting port [ 1304.207745] ata1: SATA link down (SStatus 611 SControl 300) [ 1304.228076] ata1: failed to recover some devices, retrying in 5 secs [ 1309.245599] ata1: hard resetting port [ 1314.773227] ata1: port is slow to respond, please be patient (Status 0x80) [ 1319.269677] ata1: COMRESET failed (errno=-16) [ 1319.289639] ata1: hard resetting port [ 1319.781285] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 1320.115569] ata1.00: configured for UDMA/33 [ 1320.134780] ata1: EH complete And hotplug works fine after EH is done with itself. Dunno why. 3. PLEXTOR DVDR PX-716A ATAPI CD-ROM, w
Re: [PATCH 1/2] [IDE] Platform IDE driver
Hello. Segher Boessenkool wrote: This doesn't mean that shift is better anyway. If everyone considers it better, I give up. But be warned that shift (stride) is not the only property characterizing register accesses -- the regs might be only accessible as 16/32-bit quantities, for example (16-bit is a real world example -- from Amiga or smth of that sort, IIRC). More importantly, "reg-shift" doesn't say what part of the bigger words to access. A common example is byte-wide registers on a 32-bit-only bus; it's about 50%-50% between connecting the registers to the low byte vs. connecting it to the byte with the lowest address. We already have "big-endian" prop used in MPIC nodes, IIRC. Could try to "reuse" it here as well... The only realistic way to handle all this is to put some knowledge into the device driver. This does of course also mean that no "reg-shift" property is needed; the device driver can look at your "compatible" property, instead. Why the heck should we care about the UART code taling about IDE?! Consistency? We're not obliged to be consistent with every piece of the kernel code. It would be nice to not name similar properties in the device tree dissimilarly. Kernel code doesn't come into the picture here. The "reg-shift" prop is yet unaccepted ad-hockery at this point. ;-) So, I don't see why we have to be consistent with it. Segher WBR, Sergei - 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/2] [POWERPC] MPC8349E-mITX: use platform IDE driver for CF interface
Hello.
Segher Boessenkool wrote:
+[EMAIL PROTECTED] {
+compatible = "mmio-ide";
+device_type = "ide";
Why not "ata"?
The hardware is called (E)IDE, the protocol is called ATA.
Sorry for not denouncing this earlier. :-)
ATA is the name of ANSI standard describing IDE.
Or that's what I was told --
Re-check your sources. ;-)
> I think there's some historic revisionism involved, too.
IDE was probably an initial name of the infamous disk hardware/protocol
later standardized as ATA, EIDE (being more of a trademark) more or less
equals to ATA-2.
Also, what mmio-ide in the compat properly means in the context of
ide_platform which is able to handle both port and memory mapped IDE.
I think
we must get rid with this crap, and since this IDE register mapping is
pretty
much board specific, call it something like "mpc8349emitx-ide" instead.
"mmio-ide" simply is not specific enough. The device_type
Yes.
should go, too.
If this IDE interface is board-specific, thee "compatible"
It's "thy", not "thee". ;-)
property should include the board vendor name and board
name. Oh, that's what "emitx" tries to do -- it could be
a bit clearer perhaps ;-)
Yeah, I forgot about the vondor's "fsl," prefix.
Segher
MBR, Sergei
-
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] sata_mv: Test patch for Hightpoint RocketRaid 1740/1742
Alan Cox wrote:
Underneath all the HPT packaging, PCI identifiers, binary driver modules
and stuff you find that ...
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
--- drivers/ata/sata_mv.c~ 2007-07-09 13:19:57.003052904 +0100
+++ drivers/ata/sata_mv.c 2007-07-09 13:19:57.004052752 +0100
@@ -573,6 +573,9 @@
{ PCI_VDEVICE(MARVELL, 0x5041), chip_504x },
{ PCI_VDEVICE(MARVELL, 0x5080), chip_5080 },
{ PCI_VDEVICE(MARVELL, 0x5081), chip_508x },
+ /* RocketRAID 1740/174x have different identifiers */
+ { PCI_VDEVICE(TTI, 0x1740), chip_508x },
+ { PCI_VDEVICE(TTI, 0x1742), chip_508x },
Is this still a test patch, or can it go upstream?
Jeff
-
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: Early ATA devices
Alan Cox wrote: #1 We assume identify works. Early ATA actually lists this command as optional ITYM we assume identify command exists on the device? We certainly do not assume IDENTIFY command, if exists, succeeds. What is the proper probing method -- notice if command-aborted is returned and do something from there? #2 We don't allow for INIT_DEV_PARAMS failing which it may do on some early IDE pre ATA devices Suggested handling? Ignore device, since we don't know what state its in, if this fails? We check ATA < 4 || non-LBA capable when deciding whether to issue INIT_DEV_PARAMS. ATA 4+ however mandate LBA so the second case isn't theoretically at least possible. I agree, though I figured that the current code was more robust, in case some weirdo device decided to forget its LBA-ness. No strong opinions here, though. So in theory we can persuade libata to drive original MFM/RLL disks with relatively few changes Crazy :) Jeff - 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: hpt374 sata (Highpoint Rocket 1540)
Hello.
Bartlomiej Zolnierkiewicz wrote:
I've had a Highpoint Rocket 1540 (not "RocketRAID") SATA controller for
a while now, using a proprietary binary driver from Highpoint in a linux
2.4 kernel. The chipset is an hpt374. The hpt366 driver freezes on
boot, as reported by others.
Can we see a bootlog please?
... and the output of 'lspci -v' too.
If possible, turn off that driver, rebuild the kernel, and reboot using
some other IDE driver (or NFS), then post that output...
The machine locks hard when the driver is loaded so I can't give a full
transcription, but here is the driver's output:
HPT374: IDE controller at PCI slot :00:0d.0
ACPI: PCI Interrupt :00:0d.0[A] -> GSI 16 (level, low) -> IRQ 16
HPT374: chipset revision 7
HPT374: DPLL base: 48 MHz, f_CNT: 141, assuming 33 MHz PCI
HPT374: using 50 MHz DPLL clock
HPT374: 100% native mode on irq 16
ide2: BM-DMA at 0xec00-0xec07, BIOS settings: hde:DMA, hdf:pio
ide3: BM-DMA at 0xec08-0xec0f, BIOS settings: hdg:DMA, hdh:pio
ACPI: PCI Interrupt :00:0d.1[A] -> GSI 16 (level, low) -> IRQ 16
HPT374: no clock data saved by BIOS
HPT374: DPLL base: 48 MHz, f_CNT: 93, assuming 33 MHz PCI
HPT374: using 50 MHz DPLL clock
ide4: BM-DMA at 0xed00-0xed07, BIOS settings: hdi:DMA, hdj:pio
ide5: BM-DMA at 0xed08-0xed0f, BIOS settings: hdk:DMA, hdl:pio
That "f_CNT: 93" on the 2nd HPT374 function looks *very* suspicious -- at
first I thought that DPLL is shared between 2 functions but the datasheet
denied it...
Well, the 1st function doesn't complain about the clock data being unsaved
by BIOS, so I guess it's only saved for this function, and for 2nd one the
driver resorts to reading the f_CNT register itself -- which is already spoilt
by the HPT BIOS' own DPLL calibration. Will post a patch to try soon...
The pata_hpt37x driver is refusing to work as well but it doesn't crash
the machine. Here is the relevant error message:
hpt37x: DPLL did not stabilize.
pata_hpt37x: BIOS has not set timing clocks.
hpt37x: DPLL did not stabilize.
Does this patch change anything?
Heh, did you *really* hope it will? :-D
[PATCH] hpt366: always tune PIO
Index: b/drivers/ide/pci/hpt366.c
===
--- a/drivers/ide/pci/hpt366.c
+++ b/drivers/ide/pci/hpt366.c
@@ -1,5 +1,5 @@
/*
- * linux/drivers/ide/pci/hpt366.c Version 1.10Jun 29, 2007
+ * linux/drivers/ide/pci/hpt366.c Version 1.11Jul 29, 2007
*
* Copyright (C) 1999-2003 Andre Hedrick <[EMAIL PROTECTED]>
* Portions Copyright (C) 2001 Sun Microsystems, Inc.
@@ -1265,10 +1265,10 @@ static void __devinit init_hwif_hpt366(i
if (new_mcr != old_mcr)
pci_write_config_byte(dev, hwif->select_data + 1, new_mcr);
- if (!hwif->dma_base) {
- hwif->drives[0].autotune = hwif->drives[1].autotune = 1;
+ hwif->drives[0].autotune = hwif->drives[1].autotune = 1;
+
+ if (hwif->dma_base == 0)
return;
- }
hwif->ultra_mask = hwif->cds->udma_mask;
hwif->mwdma_mask = 0x07;
Concerning the patch (I lacked time to look at the driver to refresh my
memory before -- was looking at the new Disk-on-chip H3 driver to be submitted
for comments soon, BTW): it makes little sense in its current form since
setting any DMA mode also sets 8-bit PIO timings now (and if DMA can't be set,
the driver will fallback to PIO anyway)
I have a patch that changes this behavior and switches to always
auto-tuning PIO but I've changed my mind on how the DMA/PIO timing register
sharing should be handled now -- however, since I was unable to come up with
anything better all that time, I'll consider pushing out this version when I
have a spare time...
WBR, Sergei
-
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: ST340823A disk size issue
On Wed, 1 Aug 2007 12:29:04 +0300 Mikko Rapeli <[EMAIL PROTECTED]> wrote: > Hello, > > (More details at http://bugzilla.kernel.org/show_bug.cgi?id=8816 ) > > My home server disk doesn't work with latest kernels since its size is > reported or probed correctly. With 2.6.22.1 I get: You've got an odd sized disk. If you have that, old IDE, and you also have anything which tries to read the last sector (eg GPT partitioning) it'll break as it tries to read 1K block sizes. Vendors normally clip the drive to an even size which seems to be the case on your box with the HPA left alone. It *should* all "just work" with the libata drivers but needs more testing of odd sizes to be 100% sure - 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 UPDATED] libata: add support for ATA_16 on ATAPI
Jeff Garzik wrote: > Tejun Heo wrote: >> From: Mark Lord <[EMAIL PROTECTED]> >> >> Add support for issuing ATA_16 passthru commands to ATAPI devices >> managed by libata. It requires the previous CDB length fix patch. >> >> A boot/module parameter, "atapi_scmd85=1" can be used to globally >> disable this feature, if ever desired. >> >> tj: renamed ata16_passthru module param to atapi_scmd85 to reduce >> confusion >> >> tj: restructured __ata_scsi_queuecmd() according to Jeff's suggestion. >> >> Signed-off-by: Mark Lord <[EMAIL PROTECTED]> >> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> >> --- >> Jeff, Mark, are you guys okay with the modified version? > > Close! Thanks for revising! > > My only comment now is that I dislike atapi_scmd85. That means nothing > to me. > > I liked the old name better. Or maybe use atapi_passthru16. The problem with ata16_passthru is that it suggests the opposite of what it does. The default value 0 allows ATA_16 passthrough command while setting it to 1 disallows ATA_16 passthrough and passes through SCSI Command 0x85 which shares command byte with ATA_16. Maybe it's because I'm not a native speaker but the last sentence is pretty difficult to digest. So, IMHO, atapi_scmd85 is slightly better in that it means nothing rather than suggesting the opposite. How about keeping the old name (or use atapi_passthru16) but flipping the meaning so that it defaults to 1. It just makes hell lot of sense that "ata16_passthru=1" means allowing ATA_16 passthrough not the other way around. Thanks. -- tejun - 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: Access beyond end of device
Em Wed, 1 Aug 2007 01:12:26 +0100 Alan Cox <[EMAIL PROTECTED]> escreveu: | On Tue, 31 Jul 2007 15:15:46 -0300 | "Luiz Fernando N. Capitulino" <[EMAIL PROTECTED]> wrote: | | > Em Tue, 31 Jul 2007 15:04:14 -0300 | > "Luiz Fernando N. Capitulino" <[EMAIL PROTECTED]> escreveu: | > | > | Since I've started using the pata_via driver in 2.6.22, I'm getting | > | zillions of these messages: | > | | > | """ | > | attempt to access beyond end of device | > | sda: rw=0, want=156367809, limit=156365903 | > | printk: 22 messages suppressed | > | Buffer I/O error on device sda1, logical block 78183872 | | Does your disk have a host protected area set and if so are you telling | libata to disable it ? Ok, the disk has a host protected area and now I'm telling libata to disable it. The error messages has disappeared. But... Is it safe to do it? I've read somewhere that the BIOS and other softwares may use that area. Also, I remember that with the IDE driver I wasn't seeing that messages, which means either: it was disabling it by default or was just ignoring it. -- Luiz Fernando N. Capitulino - 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: Boot fails on Intel SATA controller
-- Original message -- From: Tejun Heo <[EMAIL PROTECTED]> > Hello, > > Luiz Fernando N. Capitulino wrote: > > Hi there, > > > > A Mandriva user is reporting that his machine hangs while booting > > kernels 2.6.22.1 and 2.6.23-rc1. > > > > But boots fine with 2.6.21. > > > > ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) > > ata1.00: qc timeout (cmd 0x27) > > ata1.00: ata_hpa_resize 1: hpa sectors (0) is smaller than sectors > > (781422768) > > ata1.00: ATA-7: HDS724040KLSA80, KFAOA20N, max UDMA/133 > > ata1.00: 781422768 sectors, multi 8: LBA48 > > ata1.00: failed to set xfermode (err_mask=0x40) > > ata1: failed to recover some devices, retrying in 5 secs > > What happens after this? > It basically retries a few times, then fails to boot. Here is a more complete log with 2.6.23-rc1: ata1: SATA max UDMA/133 cmd 0xf881ad00 ctl 0x bmdma 0x irq 18^M ata2: SATA max UDMA/133 cmd 0xf881ad80 ctl 0x bmdma 0x irq 18^M ata3: SATA max UDMA/133 cmd 0xf881ae00 ctl 0x bmdma 0x irq 18^M ata4: SATA max UDMA/133 cmd 0xf881ae80 ctl 0x bmdma 0x irq 18^M ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)^M ata1.00: qc timeout (cmd 0x27)^M ata1.00: ata_hpa_resize 1: hpa sectors (0) is smaller than sectors (781422768)^M ata1.00: ATA-7: HDS724040KLSA80, KFAOA20N, max UDMA/133^M ata1.00: 781422768 sectors, multi 8: LBA48 ^M ata1.00: failed to set xfermode (err_mask=0x40)^M ata1: failed to recover some devices, retrying in 5 secs^M ata1: port is slow to respond, please be patient (Status 0x80)^M ata1: COMRESET failed (errno=-16)^M ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)^M ata1.00: qc timeout (cmd 0x27)^M ata1.00: ata_hpa_resize 1: hpa sectors (0) is smaller than sectors (781422768)^M ata1.00: configured for UDMA/133^M ata1: EH pending after completion, repeating EH (cnt=4)^M ata1: soft resetting port^M ata1: failed to reset engine (errno=-95)<6>ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)^M ata1.00: qc timeout (cmd 0xec)^M ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)^M ata1.00: revalidation failed (errno=-5)^M ata1: failed to recover some devices, retrying in 5 secs^M ata1: hard resetting port^M ata1: port is slow to respond, please be patient (Status 0x80)^M ata1: COMRESET failed (errno=-16)^M ata1: hard resetting port^M ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)^M ata1.00: qc timeout (cmd 0x27)^M ata1.00: ata_hpa_resize 1: hpa sectors (0) is smaller than sectors (781422768)^M ata1.00: failed to set xfermode (err_mask=0x40)^M ata1: limiting SATA link speed to 1.5 Gbps^M ata1.00: limiting speed to UDMA/133:PIO3^M ata1: failed to recover some devices, retrying in 5 secs^M ata1: hard resetting port^M ata1: port is slow to respond, please be patient (Status 0x80)^M ata1: COMRESET failed (errno=-16)^M ata1: hard resetting port^M ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)^M ata1.00: qc timeout (cmd 0x27)^M ata1.00: ata_hpa_resize 1: hpa sectors (0) is smaller than sectors (781422768)^M ata1.00: failed to set xfermode (err_mask=0x40)^M ata1.00: disabled^M ata1: EH pending after completion, repeating EH (cnt=3)^M ata1: soft resetting port^M ata1: failed to reset engine (errno=-95)<6>ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)^M ata1: EH complete^M ata2: SATA link down (SStatus 0 SControl 300)^M ata3: SATA link down (SStatus 0 SControl 300)^M ata4: SATA link down (SStatus 0 SControl 300)^M Loading ata_piixACPI: PCI Interrupt :00:1f.1[A] -> .ko module^M GSI 16 (level, low) -> IRQ 16^M scsi4 : ata_piix^M scsi5 : ata_piix^M ata5: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001ffa0 irq 14^M ata6: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001ffa8 irq 15^M ata5.00: ATAPI: GCR-8483B, 1.09, max UDMA/33^M ata5.01: ATAPI: PHILIPS DVD+/-RW DVD8631, GD30, max UDMA/33^M ata5.00: configured for UDMA/33^M ata5.01: configured for UDMA/33^M scsi 4:0:0:0: CD-ROMHL-DT-ST CD-ROM GCR-8483B 1.09 PQ: 0 ANSI: 5^M scsi 4:0:1:0: CD-ROMPHILIPS DVD+-RW DVD8631 GD30 PQ: 0 ANSI: 5^M Loading sd_mod.ko module^M Loading jbd.ko module^MKernel panic - not syncing: Attempted to kill init!^M Loading ext3.ko module^M Mounting /proc filesystem^M Mounting sys - 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] mark PCI resource with start 0 as unassigned
Segher Boessenkool wrote: setup-pci is for SFF8038i devices. It therefore knows that for assigned resources they must be I/O. It also assumes that zero is not a valid I/O port just like zero is not a valid IRQ. Stick a real IDE resource at zero and drivers/ide can't cope. But 0 _is_ a valid PCI I/O address. Do we now have to start I wasn't in PCI 2.1 (later the corresponding passage have disppeared). using "virtual I/O addresses", analogue to the IRQ situation, or can these bad assumptions be fixed instead? Segher WBR, Sergei - 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] pata_sis: fix MWDMA for <= UDMA66 chipsets and UDMA for UDMA33 chipsets
Bartlomiej Zolnierkiewicz wrote: * Fix MWDMA timings setup in sis_old_set_dmamode() and sis_66_set_dmamode(). The old timings were overclocked (even worse behavior than sis5513 IDE driver which depends on BIOS to program correct timings), the new timings are taken from the datasheet (they match timings from ATA spec). * Fix UDMA timings setup in sis_old_set_dmamode(). Misplaced pci_write_config_word() call resulted in UDMA timings never being set. * Fix comments for sis_133_early_set_dmamode() and sis_133_set_dmamode(): - only the former function handles early SiS 961 bridges - both functions lack MWDMA timings setup * Fix typos in sis_100_set_piomode() and sis_133_set_piomode() comments. * Bump driver version. Cc: Alan Cox <[EMAIL PROTECTED]> Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> --- Sergei: Yes, I'm working on sis5513 IDE driver. :) drivers/ata/pata_sis.c | 20 +--- 1 file changed, 9 insertions(+), 11 deletions(-) applied to #upstream-fixes - 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] libata: blacklist SAMSUNG HD401LJ / ZZ100-15 for NCQ
Tejun Heo wrote: SAMSUNG HD401LJ / ZZ100-15 does spurious completion of NCQ commands. Disable NCQ. Reported by Ulrich in bugzilla #8805. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> Cc: Ulrich <[EMAIL PROTECTED]> --- And, finally one from samsung. How come vendors got this right previously but screw up on new ones? drivers/ata/libata-core.c |1 + 1 file changed, 1 insertion(+) applied to #upstream-fixes - 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] pci: rename __pci_reenable_device() to pci_reenable_device()
Tejun Heo wrote: Rename __pci_reenable_device() to pci_reenable_device(). Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> --- Jeff, Greg wanted to drop the preceding underscores before exporting the function and the updated patch was posted but the earlier version was applied. This patch renames the function. applied these three to #upstream-fixes - 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 1/4] Store interrupt value
Kristen Carlson Accardi wrote: Use a stored value for which interrupts to enable. Changing this allows us to selectively turn off certain interrupts later and have them stay off. Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]> ACK. Regenerate against current kernel and I'll apply immediately (tried to do so just now) - 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 UPDATED] libata: add support for ATA_16 on ATAPI
Tejun Heo wrote: From: Mark Lord <[EMAIL PROTECTED]> Add support for issuing ATA_16 passthru commands to ATAPI devices managed by libata. It requires the previous CDB length fix patch. A boot/module parameter, "atapi_scmd85=1" can be used to globally disable this feature, if ever desired. tj: renamed ata16_passthru module param to atapi_scmd85 to reduce confusion tj: restructured __ata_scsi_queuecmd() according to Jeff's suggestion. Signed-off-by: Mark Lord <[EMAIL PROTECTED]> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> --- Jeff, Mark, are you guys okay with the modified version? Close! Thanks for revising! My only comment now is that I dislike atapi_scmd85. That means nothing to me. I liked the old name better. Or maybe use atapi_passthru16. Jeff - 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] pata_cmd64x: Correct the speed ranges
Alan Cox wrote: I must have been half asleep when doing the original code Signed-off-by: Alan Cox <[EMAIL PROTECTED]> applied to #upstream-fixes - 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] libata-sff; Unbreak non DMA capable controllers again
Alan Cox wrote: Seems nobody else is checking/testing this case as it keeps getting horked. If we have no BAR4 mapping on an SFF controller this is *NOT* an error, it just means it isn't doing BMDMA. Signed-off-by: Alan Cox <[EMAIL PROTECTED]> applied to #upstream-fixes - 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: Boot fails on Intel SATA controller
Em Wed, 01 Aug 2007 23:36:07 +0900 Tejun Heo <[EMAIL PROTECTED]> escreveu: | Quel Qun wrote: | > -- Original message -- | > From: Tejun Heo <[EMAIL PROTECTED]> | >> Hello, | >> | >> Luiz Fernando N. Capitulino wrote: | >>> Hi there, | >>> | >>> A Mandriva user is reporting that his machine hangs while booting | >>> kernels 2.6.22.1 and 2.6.23-rc1. | >>> | >>> But boots fine with 2.6.21. | >>> | >>> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) | >>> ata1.00: qc timeout (cmd 0x27) | >>> ata1.00: ata_hpa_resize 1: hpa sectors (0) is smaller than sectors (781422768) | >>> ata1.00: ATA-7: HDS724040KLSA80, KFAOA20N, max UDMA/133 | >>> ata1.00: 781422768 sectors, multi 8: LBA48 | >>> ata1.00: failed to set xfermode (err_mask=0x40) | >>> ata1: failed to recover some devices, retrying in 5 secs | >> What happens after this? | >> | > It basically retries a few times, then fails to boot. Here is a more complete log with 2.6.23-rc1: | | Does the attached patch change anything? Quel Qun, if you can't patch the kernel for some reason I can generate a Mandriva kernel package with the patch for you. Just ask. -- Luiz Fernando N. Capitulino - 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: Boot fails on Intel SATA controller
Quel Qun wrote: > -- Original message -- > From: Tejun Heo <[EMAIL PROTECTED]> >> Hello, >> >> Luiz Fernando N. Capitulino wrote: >>> Hi there, >>> >>> A Mandriva user is reporting that his machine hangs while booting >>> kernels 2.6.22.1 and 2.6.23-rc1. >>> >>> But boots fine with 2.6.21. >>> >>> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) >>> ata1.00: qc timeout (cmd 0x27) >>> ata1.00: ata_hpa_resize 1: hpa sectors (0) is smaller than sectors >>> (781422768) >>> ata1.00: ATA-7: HDS724040KLSA80, KFAOA20N, max UDMA/133 >>> ata1.00: 781422768 sectors, multi 8: LBA48 >>> ata1.00: failed to set xfermode (err_mask=0x40) >>> ata1: failed to recover some devices, retrying in 5 secs >> What happens after this? >> > It basically retries a few times, then fails to boot. Here is a more complete > log with 2.6.23-rc1: Does the attached patch change anything? -- tejun diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index d8c6789..af5db69 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -1915,8 +1915,8 @@ int ata_dev_configure(struct ata_device *dev) dev->flags |= ATA_DFLAG_FLUSH_EXT; } - if (ata_id_hpa_enabled(dev->id)) -dev->n_sectors = ata_hpa_resize(dev); + //if (ata_id_hpa_enabled(dev->id)) + // dev->n_sectors = ata_hpa_resize(dev); /* config NCQ */ ata_dev_config_ncq(dev, ncq_desc, sizeof(ncq_desc));
Re: Early ATA devices
On Wed, 01 Aug 2007 09:47:49 -0400 Jeff Garzik <[EMAIL PROTECTED]> wrote: > Alan Cox wrote: > > #1 We assume identify works. Early ATA actually lists this command > > as optional > > ITYM we assume identify command exists on the device? > > We certainly do not assume IDENTIFY command, if exists, succeeds. We assume that it exists and that it will succeed. In any other situation we skip the device. > What is the proper probing method -- notice if command-aborted is > returned and do something from there? Yes. A good question is what as we then don't know geometry. I know understand how PC BIOS geometry reporting works in detail so one option is to write a drivers/firmware/pc_geometry.c library which knows how to handle this crap for us. Thankfully any even prehistoric might still boot Linux PC should have EDD2.0 and anything older we care about FDPT tables. We'd end up with an API something like int pcgeo_get_geometry_isa(ioport, devno, struct ...) int pcgeo_get_geometry_pci(pci_dev, devno, ) which means we can also push user configuration of geometry into that module and share it between hd, oldide, old scsi, whatever. [and this stuff is more screwed up than IDE ...] > > #2 We don't allow for INIT_DEV_PARAMS failing which it may do on > > some early IDE pre ATA devices > > Suggested handling? Ignore device, since we don't know what state its > in, if this fails? I stuck a test patch in my tree and emulating this sequence it works to just skip the aborted command. A drive which lacks this is fixed geometry so the geometry we want to set is already set and a failure is meaningless (which is different to an early ATA drive which may have multiple emulated geometries). Alan - 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/4] Expose Power Management Policy option to users
On Wed, 01 Aug 2007 12:24:44 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote: > It would be *really* great if we can find more about how they do it. > How and when it's enabled and on which systems. Is it possible to find > this out? No - it's really not a good idea for us to go and ask other OS's how they implement things in this level of detail. - 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: hpt374 sata (Highpoint Rocket 1540)
Bob Ham wrote: I've had a Highpoint Rocket 1540 (not "RocketRAID") SATA controller for a while now, using a proprietary binary driver from Highpoint in a linux 2.4 kernel. The chipset is an hpt374. The hpt366 driver freezes on boot, as reported by others. Can we see a bootlog please? ... and the output of 'lspci -v' too. If possible, turn off that driver, then post that output... This is the output of the boot using the pata_hpt37x driver: Hrm... what I asked for was 'lspci -v' output. :-) hpt37x: DPLL did not stabilize. pata_hpt37x: BIOS has not set timing clocks. hpt37x: DPLL did not stabilize. Yes, this ia a known issue, and the fix for it is in the -mm tree: http://kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%2Fpeople%2Fakpm%2Fpatches%2F2.6%2F2.6.23-rc1%2F2.6.23-rc1-mm2%2F2.6.23-rc1-mm2.bz2;z=950 WBR, Sergei - 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] sata_mv: Test patch for Hightpoint RocketRaid 1740/1742
On Wed, 01 Aug 2007 09:49:19 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Alan Cox wrote:
> > Underneath all the HPT packaging, PCI identifiers, binary driver modules
> > and stuff you find that ...
> >
> > Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
> >
> > --- drivers/ata/sata_mv.c~ 2007-07-09 13:19:57.003052904 +0100
> > +++ drivers/ata/sata_mv.c 2007-07-09 13:19:57.004052752 +0100
> > @@ -573,6 +573,9 @@
> > { PCI_VDEVICE(MARVELL, 0x5041), chip_504x },
> > { PCI_VDEVICE(MARVELL, 0x5080), chip_5080 },
> > { PCI_VDEVICE(MARVELL, 0x5081), chip_508x },
> > + /* RocketRAID 1740/174x have different identifiers */
> > + { PCI_VDEVICE(TTI, 0x1740), chip_508x },
> > + { PCI_VDEVICE(TTI, 0x1742), chip_508x },
>
> Is this still a test patch, or can it go upstream?
Upstream
-
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] mark PCI resource with start 0 as unassigned
On Wed, 01 Aug 2007 18:22:36 +0400 Sergei Shtylyov <[EMAIL PROTECTED]> wrote: > Segher Boessenkool wrote: > > >> setup-pci is for SFF8038i devices. It therefore knows that for assigned > >> resources they must be I/O. It also assumes that zero is not a valid I/O > >> port just like zero is not a valid IRQ. Stick a real IDE resource at > >> zero and drivers/ide can't cope. > > > But 0 _is_ a valid PCI I/O address. Do we now have to start > > I wasn't in PCI 2.1 (later the corresponding passage have disppeared). SFF controllers often use 0 to indicate a channel isn't configured and present. Libata and old IDE both assume these semantics for an SFF IDE device reporting address zero. It matches the hardware behaviour. I would suggest you don't map one at I/O zero on your PCI. Alan - 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: hpt374 sata (Highpoint Rocket 1540)
> The pata_hpt37x driver is refusing to work as well but it doesn't crash > the machine. Here is the relevant error message: > > hpt37x: DPLL did not stabilize. > pata_hpt37x: BIOS has not set timing clocks. > hpt37x: DPLL did not stabilize. Should be fixed in the latest updates. - 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
[git patches] libata fixes
The only notable: GregKH wanted the pci_reenable_device() change
associated with ata_piix to go in before the release, to avoiding
release with an imperfect API.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ata_piix.c| 74 +
drivers/ata/libata-core.c |1 +
drivers/ata/libata-sff.c |4 ++
drivers/ata/pata_cmd64x.c |8 ++--
drivers/ata/pata_sis.c| 20 +---
drivers/pci/pci-driver.c |2 +-
drivers/pci/pci.c |7 ++--
include/linux/pci.h |2 +-
8 files changed, 64 insertions(+), 54 deletions(-)
Alan Cox (2):
pata_cmd64x: Correct the speed ranges
libata-sff; Unbreak non DMA capable controllers again
Bartlomiej Zolnierkiewicz (1):
pata_sis: fix MWDMA for <= UDMA66 chipsets and UDMA for UDMA33 chipsets
Tejun Heo (4):
pci: rename __pci_reenable_device() to pci_reenable_device()
ata_piix: implement piix_borken_suspend()
ata_piix: add Tecra M3 to broken suspend blacklist
libata: blacklist SAMSUNG HD401LJ / ZZ100-15 for NCQ
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index ad07086..a78832e 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -890,37 +890,46 @@ static void ich_set_dmamode (struct ata_port *ap, struct
ata_device *adev)
}
#ifdef CONFIG_PM
-static struct dmi_system_id piix_broken_suspend_dmi_table[] = {
- {
- .ident = "TECRA M5",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
- DMI_MATCH(DMI_PRODUCT_NAME, "TECRA M5"),
- },
- },
- {
- .ident = "Satellite U200",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
- DMI_MATCH(DMI_PRODUCT_NAME, "Satellite U200"),
+static int piix_broken_suspend(void)
+{
+ static struct dmi_system_id sysids[] = {
+ {
+ .ident = "TECRA M5",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "TECRA M5"),
+ },
},
- },
- {
- .ident = "Satellite U205",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
- DMI_MATCH(DMI_PRODUCT_NAME, "Satellite U205"),
+ {
+ .ident = "Satellite U205",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Satellite U205"),
+ },
},
- },
- {
- .ident = "Portege M500",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
- DMI_MATCH(DMI_PRODUCT_NAME, "PORTEGE M500"),
+ {
+ .ident = "Portege M500",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "PORTEGE M500"),
+ },
},
- },
- { }
-};
+ { }
+ };
+ static const char *oemstrs[] = {
+ "Tecra M3,",
+ };
+ int i;
+
+ if (dmi_check_system(sysids))
+ return 1;
+
+ for (i = 0; i < ARRAY_SIZE(oemstrs); i++)
+ if (dmi_find_device(DMI_DEV_TYPE_OEM_STRING, oemstrs[i], NULL))
+ return 1;
+
+ return 0;
+}
static int piix_pci_device_suspend(struct pci_dev *pdev, pm_message_t mesg)
{
@@ -937,8 +946,7 @@ static int piix_pci_device_suspend(struct pci_dev *pdev,
pm_message_t mesg)
* cycles and power trying to do something to the sleeping
* beauty.
*/
- if (dmi_check_system(piix_broken_suspend_dmi_table) &&
- mesg.event == PM_EVENT_SUSPEND) {
+ if (piix_broken_suspend() && mesg.event == PM_EVENT_SUSPEND) {
pci_save_state(pdev);
/* mark its power state as "unknown", since we don't
@@ -973,10 +981,10 @@ static int piix_pci_device_resume(struct pci_dev *pdev)
pci_restore_state(pdev);
/* PCI device wasn't disabled during suspend. Use
-* __pci_reenable_device() to avoid affecting the
-* enable count.
+* pci_reenable_device() to avoid affecting the enable
+* count.
*/
- rc = __pci_reenable_device(pdev);
+ rc = pci_reenable_device(pdev);
if (rc)
dev_printk(KERN_ERR, &pdev->dev, "failed to enable "
Re: hpt374 sata (Highpoint Rocket 1540)
On Wed, 2007-08-01 at 17:40 +0400, Sergei Shtylyov wrote: > Hello. > > Bartlomiej Zolnierkiewicz wrote: > > >I've had a Highpoint Rocket 1540 (not "RocketRAID") SATA controller for > >a while now, using a proprietary binary driver from Highpoint in a linux > >2.4 kernel. The chipset is an hpt374. The hpt366 driver freezes on > >boot, as reported by others. > > Can we see a bootlog please? > > >>>... and the output of 'lspci -v' too. > > If possible, turn off that driver, > then post that output... This is the output of the boot using the pata_hpt37x driver: Linux version 2.6.22.1 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #6 Tue Jul 31 20:23:11 BST 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e4000 - 0010 (reserved) BIOS-e820: 0010 - 1ff4 (usable) BIOS-e820: 1ff4 - 1ff5 (ACPI data) BIOS-e820: 1ff5 - 2000 (ACPI NVS) BIOS-e820: ff7c - 0001 (reserved) 511MB LOWMEM available. found SMP MP-table at 000ff780 Entering add_active_range(0, 0, 130880) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 130880 early_node_map[1] active PFN ranges 0:0 -> 130880 On node 0 totalpages: 130880 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 990 pages used for memmap Normal zone: 125794 pages, LIFO batch:31 DMI 2.3 present. ACPI: RSDP 000F91A0, 0014 (r0 ACPIAM) ACPI: RSDT 1FF4, 0030 (r1 A M I OEMRSDT 9000424 MSFT 97) ACPI: FACP 1FF40200, 0081 (r2 A M I OEMFACP 9000424 MSFT 97) ACPI: DSDT 1FF40350, 373D (r1 A0008 A0008705 705 INTL 2002026) ACPI: FACS 1FF5, 0040 ACPI: APIC 1FF40300, 004A (r1 A M I OEMAPIC 9000424 MSFT 97) ACPI: OEMB 1FF50040, 003F (r1 A M I OEMBIOS 9000424 MSFT 97) ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 6:8 APIC version 16 ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 1, version 3, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 3000 (gap: 2000:df7c) Built 1 zonelists. Total pages: 129858 Kernel command line: root=/dev/sda1 ro devfs=mount vga=0x313 mapped APIC to d000 (fee0) mapped IOAPIC to c000 (fec0) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 2048 (order: 11, 8192 bytes) Detected 1666.560 MHz processor. Console: colour VGA+ 132x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 511900k/523520k available (2566k kernel code, 11044k reserved, 1040k data, 188k init, 0k highmem) virtual kernel memory layout: fixmap : 0xfffb7000 - 0xf000 ( 288 kB) vmalloc : 0xe080 - 0xfffb5000 ( 503 MB) lowmem : 0xc000 - 0xdff4 ( 511 MB) .init : 0xc0488000 - 0xc04b7000 ( 188 kB) .data : 0xc0381845 - 0xc0485c04 (1040 kB) .text : 0xc010 - 0xc0381845 (2566 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 3336.73 BogoMIPS (lpj=6673476) Mount-cache hash table entries: 512 CPU: After generic identify, caps: 0383fbff c1cbfbff CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After all inits, caps: 0383fbff c1cbfbff 0420 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. Compat vDSO mapped to e000. CPU: AMD Sempron(tm) 2400+ stepping 01 Checking 'hlt' instruction... OK. ACPI: Core revision 20070126 ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xf0031, last bus=1 PCI: Using configuration type 1 Setting up standard PCI resources ACPI: Interpreter enabled ACPI: (supports S0 S1 S3 S4 S5) ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI: Probing PCI hardware (bus 00) PCI: enabled onboard AC97/MC97 devices ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs *3 4 5 7 10 11 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 7 10 11 14 15)
Re: [patch 2/4] Expose Power Management Policy option to users
On Wed, 01 Aug 2007 18:23:21 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote: > Tejun Heo wrote: > > Arjan van de Ven wrote: > >>> They were hardware problems. I don't think any amount of proper > >>> implementation can fix them. I have one DVD RAM somewhere in my pile of > >>> hardware which locks up solidly if any link PS mode is used and had a > >> and the AHCI ALPM code decides to use power savings on this device? if > >> so, please give us the idents so that we can add it to the blacklist as > >> the first entry... (or can buy it to check it in detail first) > > > > Yeap, lemme check. > > > > It's "TSSTcorpCD/DVDW SH-S183A" with firmware revision "SB01". Wanna > > check ID capability bits but 'hdparm -I /dev/sr0' is still broken and > > it's already past 3 am here. I'll report back tomorrow. > > Oops, that was the wrong one. Locking up one was HL-DT-STDVD-RAM > GSA-H30N and it correctly reports that it doesn't support IPM. Here > are some test results. > > Controller is ICH9. > > 00:1f.2 SATA controller [Class 0106]: Intel Corporation Unknown device > [8086:2922] (rev 02) > > > > 1. HL-DT-STDVD-RAM GSA-H30N > > ATAPI CD-ROM, with removable media > Model Number: HL-DT-STDVD-RAM GSA-H30N > Serial Number: > Firmware Revision: 1.00 > Standards: > Likely used CD-ROM ATAPI-1 > Configuration: > DRQ response: 50us. > Packet size: 12 bytes > Capabilities: > LBA, IORDY(can be disabled) > DMA: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 > udma4 *udma5 > Cycle time: min=120ns recommended=120ns > PIO: pio0 pio1 pio2 pio3 pio4 > Cycle time: no flow control=120ns IORDY flow control=120 > > This device doesn't claim to support HIPM nor DIPM. Are you sure you are using the latest version of the patch? This seems like a bug, if the device doesn't support HIPM or DIPM it shouldn't attempt to use ALPM. There was a check for this put into the patch on about the second or third version - maybe I'm not doing it right. (from the patch located here: http://www.kernel.org/pub/linux/kernel/people/kristen/patches/SATA/alpm/libata-enable-pm if (ata_id_has_hipm(dev->id) || ata_id_has_dipm(dev->id)) + dev->flags |= ATA_DFLAG_IPM; + > > 2. TSSTcorpCD/DVDW SH-S183A > > ATAPI CD-ROM, with removable media > Model Number: TSSTcorpCD/DVDW SH-S183A > Serial Number: > Firmware Revision: SB01 > Standards: > Likely used CD-ROM ATAPI-1 > Configuration: > DRQ response: 50us. > Packet size: 12 bytes > Capabilities: > LBA, IORDY(can be disabled) > DMA: mdma0 mdma1 mdma2 udma0 udma1 *udma2 > Cycle time: min=120ns recommended=120ns > PIO: pio0 pio1 pio2 pio3 pio4 > Cycle time: no flow control=120ns IORDY flow control=120ns > Commands/features: > Enabled Supported: >*SATA-I signaling speed (1.5Gb/s) >*Host-initiated interface power management >*Phy event counters > Device-initiated interface power management > unknown 78[5] >*Software settings preservation > > This one claims to support HIPS. > > # echo min_power > link_power_management_policy > [ 1301.917248] ata1.00: exception Emask 0x10 SAct 0x0 SErr 0x5 action > 0x2 > [ 1301.938338] ata1.00: irq_stat 0x4001 > [ 1301.956955] ata1.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb > 0x43 data 12 in > [ 1301.956959] res 51/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x10 > (ATA bus error) > [ 1304.189565] ata1: soft resetting port > [ 1304.207745] ata1: SATA link down (SStatus 611 SControl 300) > [ 1304.228076] ata1: failed to recover some devices, retrying in 5 secs > [ 1309.245599] ata1: hard resetting port > [ 1314.773227] ata1: port is slow to respond, please be patient (Status > 0x80) > [ 1319.269677] ata1: COMRESET failed (errno=-16) > [ 1319.289639] ata1: hard resetting port > [ 1319.781285] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) > [ 1320.115569] ata1.00: configured for UDMA/33 > [ 1320.134780] ata1: EH complete > > And hotplug works fine after EH is done with itself. Dunno why. It works because after EH you've reset the port, and when you reset the port you turn off ipm (note the value of SControl). I left this the way it was without attempting to renable link pm after a reset because I figured if there was something bad happening and we needed to reset we should leave ipm off. As far as the failure you are seeing goes - this may not actually be a hardware problem but just a case of us not understanding which bits we need to clear out of the Interrupt status register once we enable ALPM. The value of SErr indicates that this device has gotten PhyRdy - which is normal for power state changes, and the interru
Re: Access beyond end of device
> Ok, the disk has a host protected area and now I'm telling libata to > disable it. > > The error messages has disappeared. > > But... Is it safe to do it? I've read somewhere that the BIOS and > other softwares may use that area. On some systems. Its also used for different things on others (rounding off disk sizes nicely, clipping to avoid bios limits etc) > Also, I remember that with the IDE driver I wasn't seeing that > messages, which means either: it was disabling it by default or > was just ignoring it. Old IDE disables it by default, libata is more conservative. Personally I think libata should disable it by default too but thats an argument to have with Jeff - 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/4] Expose Power Management Policy option to users
On Tue, Jul 31, 2007 at 09:18:08AM -0500, James Bottomley wrote: > The other comment is that power saving seems to be a property of the > transport rather than the host. If you do it in the transport classes, > then you can expose all the knobs the actual transport possesses (which > is, unfortunately, none for quite a few SCSI transports). Would it save any power to negotiate down to, say, FAST-20 for the SPI transport? Or to negotiate narrow instead of wide, so fewer cables have to be powered? -- "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - 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: NV Cache Feature Support in libata
Did you refer to "HDIO_DRIVE_CMD ioctl" in old IDE code? I couldn't get it working on libata. Based on libata-scsi code, only PIO data in and Non-data protocol are supported for HDIO_DRIVE_CMD while NV Cache commands requires DMA based on ATA8 spec. I tried to use ATA pass through command for NV Cache commands. For instance, I implemented Add LBA to Pinned Set command just like Write DMA Extended with the differences in command, feature and LBA register bit 0, but I got "protocol mismatch" error from device. I would appreciate any information in regard to libata support on NV Cache commands. Thanks, Fajun On 2/9/07, Timothy Bisson <[EMAIL PROTECTED]> wrote: > > > On Feb 9, 2007, at 10:25 AM, Fajun Chen wrote: > > > I'm not aware of any NV cache (vista feature documented in > > ata-atapi-8) support in libata. Is this supported or any plan to > > support it in the future? > It is already supported through the HDIO_DRIVE_CMD ioctl - pass 0xb6 as the > command register value. > > I think the interesting question is, how can we leverage the NV Cache in the > block and file system layers to improve power and performance. One probably > obvious option is to enter NV Cache Power Mode when laptop mode is enabled. > > Tim - 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/4] Expose Power Management Policy option to users
On Wed, 2007-08-01 at 10:53 -0600, Matthew Wilcox wrote: > On Tue, Jul 31, 2007 at 09:18:08AM -0500, James Bottomley wrote: > > The other comment is that power saving seems to be a property of the > > transport rather than the host. If you do it in the transport classes, > > then you can expose all the knobs the actual transport possesses (which > > is, unfortunately, none for quite a few SCSI transports). > > Would it save any power to negotiate down to, say, FAST-20 for the SPI > transport? Or to negotiate narrow instead of wide, so fewer cables have > to be powered? Mechanically, I don't believe so. I'm not sure I can find any reports on it; however, I believe the power wastage SPI comes from the transcievers and terminators. There's the passive power from simply powering the resistive bus and then the RMS power from sending commands over an impedance circuit. simple physics on a 5v bus tells me that the former is likely to be far greater than the latter. Finally, if you think about what the bus is doing during signalling, the power drain is independent of the frequency so I think the faster you squirt your data, the lower the energy drain (hence high speed busses are actually lower energy than low speed ones if the number of bits you have to transfer remains constant). James - 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: hpt374 sata (Highpoint Rocket 1540)
Bob Ham wrote: I've had a Highpoint Rocket 1540 (not "RocketRAID") SATA controller for a while now, using a proprietary binary driver from Highpoint in a linux 2.4 kernel. The chipset is an hpt374. The hpt366 driver freezes on boot, as reported by others. Can we see a bootlog please? ... and the output of 'lspci -v' too. If possible, turn off that driver, then post that output... This is the output of the boot using the pata_hpt37x driver: Hrm... what I asked for was 'lspci -v' output. :-) lspci gives: 00:0d.0 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07) Subsystem: Triones Technologies, Inc. Unknown device 0001 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16 I/O ports at efa0 [size=8] I/O ports at ef9c [size=4] I/O ports at ef90 [size=8] I/O ports at ef98 [size=4] I/O ports at ec00 [size=256] Expansion ROM at fe70 [disabled] [size=128K] Capabilities: [60] Power Management version 2 00:0d.1 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07) Subsystem: Triones Technologies, Inc. Unknown device 0001 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16 I/O ports at eff0 [size=8] I/O ports at efe4 [size=4] I/O ports at efa8 [size=8] I/O ports at efe0 [size=4] I/O ports at ed00 [size=256] Capabilities: [60] Power Management version 2 Too bad, this is the standard HPT subsystem ID of 0x0001... So, nothing comes to my mind other than add a module parameter to hpt366.c to specify that we're using the crippled SATA bridge... well, maybe it would also make sense to scan the BIOS for the signatures... WBR, Sergei - 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: Early ATA devices
> > So in theory we can persuade libata to drive original MFM/RLL disks with
> > relatively few changes
>
> Crazy :)
Would look something like this (but with geometry handling and some setup
work)
/**
* An original IDE/ST412/ST506 driver for libata
*
* Information for hardware archeologists
* - IDE is the original pre ATA and 'EIDE' specification interface
*emulating ST412 with some oddments nailed on
* - ST412 is the normal PC/AT attachment
* - ST506 is the prehistoric version
*
* This driver will not (currently) handle ST506 unless you set the
* precomp value. Nor will it handle the original '8 head' protocol, nor
* drives not capable of the 35uS stepper rate. I might fix this for
* fun one day if I can find an old enough drive that still works
*
* How we work the compatibility ATA to ST412
* --
*
* Mostly this works as pass through to libata as IDE and ATA were
* designed to be compatible in the IDE->ATA direction. The ST412
* interface ctrl register maps to the ATA ctl register (which is why it
* has lots of 'obsolete' bits). nIEN and SRST map to the IRQ mask
* bit on the controller and the controller soft reset.
*
* Original IDE works on the same command set as ST412 as far as we
* care (we don't do formatting etc). Some later IDE drives insist
* that we tell them their geometry (Initialize Drive) and they also
* support better error handling (DIAGNOSE), but we can do that as
* it'll just get rejected by the MFM era controller.
*
* The drive select is also cunning arranged so that '512 bytes with ECC'
* to the controller is in fact 0xA0 (aka the 'obsolete' bits in ATA)
*
* The big limit on original IDE is that only the BIOS knows the c/h/s
* parameters for the drive. For MFM/RLL you can sneak a peek at the
* partition table and guess but not alas for early IDE as it requires
* you set the geometry before it'll let you look!
*
* ST506
* -
*
* ST506 requires we set 8 v 16 heads correctly and that we provide
* write precomp and a couple of other additional values. If you have
* a specific application involving rescuing such an ancient disk in
* a lab somewhere then let me know, although its probably easier and
* safer to read a disk that old in a data recovery lab
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define DRV_NAME "pata_hd"
#define DRV_VERSION "0.0.1"
#define NR_HOST 2
struct platform_device *atahd_device[NR_HOST];
static struct ata_host *atahd_host[NR_HOST];
struct atahd_disk {
/* Geometry for faking IDENTIFY */
u16 cyls;
u8 heads;
u8 sectors;
/* Not currently supported - 35uS always used */
u8 seekrate;
/* Precompensation for older ST506 */
u8 wprecomp;
unsigned int legacy:1; /* Drive is actually ATA-1+ */
unsigned int ide:1; /* Drive is original IDE */
unsigned int lba:1; /* Original IDE in LBA mode */
u8 bios_ident; /* BIOS id of drive */
}
static struct atahd_param {
struct atahd_disk param[2]; /* Drive parameters */
int device; /* Tracking current device */
int present;/* Mask of present devices */
};
static struct atahd_param atahd_param[NR_HOST];
static int nr_atahd_host;
static int bios_ident = 0x80;
/**
* atahd_tf_load - send taskfile registers to host controller
* @ap: Port to which output is sent
* @tf: ATA taskfile register set
*
* Outputs ATA taskfile to ST506/414 host controller.
*
* LOCKING:
* Inherited from caller.
*/
void atahd_tf_load(struct ata_port *ap, const struct ata_taskfile *tf)
{
struct ata_ioports *ioaddr = &ap->ioaddr;
unsigned int is_addr = tf->flags & ATA_TFLAG_ISADDR;
if (!p->param[p->device].legacy) {
ata_tf_load(ap, tf);
return;
}
if (tf->ctl != ap->last_ctl) {
iowrite8(tf->ctl, ioaddr->ctl_addr);
ap->last_ctl = tf->ctl;
ata_wait_idle(ap);
}
if (is_addr) {
/* ST-506 requires the precomp value is loaded, ST-412, IDE
and later it is done by the drive. This causes no problem
for ST-506 driving IDE but for IDE driving ST we need to
fill in the blanks. Later ST-506 drives don't generally
use the hardware precomp signal either */
if (p->param[p->device].wprecomp)
iowrite8(p->param[p.device].wprecomp,
ioaddr->feature_addr);
else
iowrite8(tf->feature, ioaddr->feature_addr);
iowrite8(tf->nsect, ioaddr->nsect_addr);
Re: hpt374 sata (Highpoint Rocket 1540)
On Wed, 2007-08-01 at 19:58 +0400, Sergei Shtylyov wrote: > Bob Ham wrote: > > >>>I've had a Highpoint Rocket 1540 (not "RocketRAID") SATA controller for > >>>a while now, using a proprietary binary driver from Highpoint in a > >>>linux > >>>2.4 kernel. The chipset is an hpt374. The hpt366 driver freezes on > >>>boot, as reported by others. > > >> Can we see a bootlog please? > > > ... and the output of 'lspci -v' too. > > >>If possible, turn off that driver, > >>then post that output... > > > This is the output of the boot using the pata_hpt37x driver: > > Hrm... what I asked for was 'lspci -v' output. :-) On Tue, 2007-07-31 at 22:22 +0100, Bob Ham wrote: > lspci gives: > > 00:0d.0 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07) > Subsystem: Triones Technologies, Inc. Unknown device 0001 > Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16 > I/O ports at efa0 [size=8] > I/O ports at ef9c [size=4] > I/O ports at ef90 [size=8] > I/O ports at ef98 [size=4] > I/O ports at ec00 [size=256] > Expansion ROM at fe70 [disabled] [size=128K] > Capabilities: [60] Power Management version 2 > > 00:0d.1 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07) > Subsystem: Triones Technologies, Inc. Unknown device 0001 > Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16 > I/O ports at eff0 [size=8] > I/O ports at efe4 [size=4] > I/O ports at efa8 [size=8] > I/O ports at efe0 [size=4] > I/O ports at ed00 [size=256] > Capabilities: [60] Power Management version 2 I'll check out the patch you pointed to. -- Bob Ham <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Marvell 7042 (sata_mv) fails to initialize drive
Hi Markus, On 31/07/07, Markus Gutschke <[EMAIL PROTECTED]> wrote: > I just tried hooking up a Hitachi 1TB SATA-II drive to a Marvell 7042 > based controller, and the most recent Linux kernel (2.6.23-rc1) fails to > properly initialize the interface. Does 2.6.22.1 work? > Here are the relevant kernel messages: > > > kernel: [43.312417] sata_mv :06:00.0: version 0.81 > > kernel: [43.312752] ACPI: PCI Interrupt Link [APC5] enabled at IRQ 16 > > kernel: [43.312757] ACPI: PCI Interrupt :06:00.0[A] -> Link [APC5] -> > > GSI 16 (level, low) -> IRQ 16 > > kernel: [43.312788] sata_mv :06:00.0: Applying 60X1C0 workarounds to > > unknown rev > > kernel: [43.314443] sata_mv :06:00.0: Gen-IIE 32 slots 4 ports SCSI > > mode IRQ via INTx > > kernel: [43.314535] scsi0 : sata_mv > > kernel: [43.314581] scsi1 : sata_mv > > kernel: [43.314614] scsi2 : sata_mv > > kernel: [43.314640] scsi3 : sata_mv > > kernel: [43.314660] ata1: SATA max UDMA/133 cmd 0x ctl > > 0xc20003522120 bmdma 0x irq 16 > > kernel: [43.314663] ata2: SATA max UDMA/133 cmd 0x ctl > > 0xc20003524120 bmdma 0x irq 16 > > kernel: [43.314666] ata3: SATA max UDMA/133 cmd 0x ctl > > 0xc20003526120 bmdma 0x irq 16 > > kernel: [43.314669] ata4: SATA max UDMA/133 cmd 0x ctl > > 0xc20003528120 bmdma 0x irq 16 > > kernel: [53.409086] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > > kernel: [59.741602] ata1: EH pending after completion, repeating EH (cnt=4) > > kernel: [59.777642] ata2: SATA link down (SStatus 0 SControl 300) > > kernel: [59.809752] ata3: SATA link down (SStatus 0 SControl 300) > > kernel: [59.841740] ata4: SATA link down (SStatus 0 SControl 300) > > The kernel never even registers the drive as an available disk device, > whereas everything appears to work fine, if I connect the disk to one of > the other controllers (JMicron AHCI, or NVidia sata_nv) on this motherboard. > > As I have two of those disks (in a RAID-1 array) and multiple > independent controllers, it is relatively easy for me to do some testing > here. The worst case scenario is that I need to wait a couple of hours > for the array to rebuild itself after I am done experimenting. > > Let me know, if there is anything I can do to help you diagnose the root > cause, or whether this is a known bug and you don't need any help > testing at this point. > > > Markus Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - 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: 2.6.23-rc1-mm2 (checks-for-80wire-cable-use-in-pata_via)
Le 01.08.2007 08:09, Andrew Morton a écrit : > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc1/2.6.23-rc1-mm2/ ... > +libata-acpi-checks-for-80wire-cable-use-in-pata_via.patch ... > sata/pata things Alan, this does not work after a suspend-resume cycle, I get a " ACPI get timing mode failed (AE 0x1001)" error. $ dmesg | grep ata ... scsi0 : pata_via scsi1 : pata_via ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001b800 irq 14 ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001b808 irq 15 ata1.00: ATA-5: ST340016A, 3.75, max UDMA/100 ata1.00: 78165360 sectors, multi 16: LBA ata1.01: ATA-7: Maxtor 6Y080L0, YAR41BW0, max UDMA/133 ata1.01: 160086528 sectors, multi 16: LBA ata1.00: configured for UDMA/100 ata1.01: configured for UDMA/100 ata2.00: ATAPI: HL-DT-ST DVDRAM GSA-4165B, DL03, max UDMA/33 ata2.01: ATAPI: CD-950E/AKU, A4Q, max MWDMA2, CDB intr ata2.00: configured for UDMA/33 ata2.01: configured for MWDMA2 ata1.00: Unable to set Link PM policy ata1.01: Unable to set Link PM policy ata2.00: Unable to set Link PM policy ata2.01: Unable to set Link PM policy ... [ suspend-to-disk/resume cycle happens here ] ... ata1.00: Unable to set Link PM policy ata1.01: Unable to set Link PM policy ata2.00: Unable to set Link PM policy ata2.01: Unable to set Link PM policy ata1: ACPI get timing mode failed (AE 0x1001) <== ata1.00: limited to UDMA/33 due to 40-wire cable ata1.01: limited to UDMA/33 due to 40-wire cable ata1.00: configured for UDMA/33 ata1.01: configured for UDMA/33 ata2: ACPI get timing mode failed (AE 0x1001) ata2.00: configured for UDMA/33 ata2.01: configured for MWDMA2 Anyway, long before 2.6.23-rc1-mm2, 80-wire cable detection was already wrong after a suspend-resume cycle. So I cooked the following patch 2 days ago. It may be the wrong approach but it works for me. -- pata_via: preserve cable detection bits in via_do_set_mode via_cable_detect performs cable detection by checking bits in PCI layer. But via_do_set_mode overwrites these bits. This behaviour breaks cable detection after suspend/resume cycle. So let's teach via_do_set_mode to preserve cable detection bits. Signed-off-by: Laurent Riffard <[EMAIL PROTECTED]> --- drivers/ata/pata_via.c |7 +++ 1 file changed, 7 insertions(+) Index: linux-2.6-mm/drivers/ata/pata_via.c === --- linux-2.6-mm.orig/drivers/ata/pata_via.c +++ linux-2.6-mm/drivers/ata/pata_via.c @@ -238,6 +238,7 @@ static void via_do_set_mode(struct ata_p unsigned long T = 10 / via_clock; unsigned long UT = T/tdiv; int ut; + u8 cable80_status; int offset = 3 - (2*ap->port_no) - adev->devno; @@ -287,6 +288,12 @@ static void via_do_set_mode(struct ata_p ut = t.udma ? (0xe0 | (FIT(t.udma, 2, 9) - 2)) : 0x07; break; } + + /* Preserve cable detection bit */ + pci_read_config_byte(pdev, 0x50 + offset, &cable80_status); + cable80_status &= 0x10; + ut |= cable80_status; + /* Set UDMA unless device is not UDMA capable */ if (udma_type) pci_write_config_byte(pdev, 0x50 + offset, ut); - 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: ST340823A disk size issue
Hi,
On Wednesday 01 August 2007, Mikko Rapeli wrote:
> Hello,
>
> (More details at http://bugzilla.kernel.org/show_bug.cgi?id=8816 )
>
> My home server disk doesn't work with latest kernels since its size is
> reported or probed correctly. With 2.6.22.1 I get:
>
> Probing IDE interface ide1...
> hdd: ST340823A, ATA DISK drive
> hdd: selected mode 0x42
> ...
> hdd: max request size: 128KiB
> hdd: Host Protected Area detected.
> current capacity is 78165360 sectors (40020 MB)
> native capacity is 78165361 sectors (40020 MB)
> hdd: Host Protected Area disabled.
> hdd: 78165361 sectors (40020 MB) w/1024KiB Cache, CHS=65535/16/63,
> UDMA(33)
> hdd: cache flushes not supported
> hdd: hdd1 hdd2 hdd3
> hdd: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hdd: dma_intr: error=0x10 { SectorIdNotFound }, LBAsect=78165360,
> sector=78165360
> ide: failed opcode was: unknown
> hdd: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hdd: dma_intr: error=0x10 { SectorIdNotFound }, LBAsect=78165360,
> sector=78165360
> ide: failed opcode was: unknown
> hdd: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hdd: dma_intr: error=0x10 { SectorIdNotFound }, LBAsect=78165360,
> sector=78165360
> ...
>
> And as said shows in bugzilla, badblocks, fsck and smartctl think the
> drive is not broken or going to die too soon.
>
> What's the difference between the size formats of
> WIN_READ_NATIVE_MAX_EXT read by
> ide-disk.c/idedisk_read_native_max_address_ext() and (hdreg.h)
> hd_driveid->lba_capacity_2 read by, if I read drivers/ide/* code
> correctly, ide-probe.c/do_identify()?
>
> If this disk is reporting one of these wrong, which fix could be
> applied?
>
> Both disabling 'stroke' and removing addr++ in
> ide-disk.c/idedisk_read_native_max_address*() fix the problem, but if
> kernel code is correct and standard compliant, these fixes are out of
> the question.
>
> Perhaps a boot parameter to kernel could force the disk sector count to
> some value for buggy drives?
Could you try attached patch?
[PATCH] ide-disk: workaround for buggy HPA support on ST340823A
This disk reports total number of sectors instead of maximum sector address
in response to READ_NATIVE_MAX_ADDRESS command and also happily accepts
SET_MAX_ADDRESS command with the bogus value. This results in +1 sector
capacity being used and errors on attempts to use the last sector.
...
hdd: Host Protected Area detected.
    current capacity is 78165360 sectors (40020 MB)
    native  capacity is 78165361 sectors (40020 MB)
hdd: Host Protected Area disabled.
...
hdd: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdd: dma_intr: error=0x10 { SectorIdNotFound }, LBAsect=78165360,
sector=78165360
...
Add hpa_list[] table and workaround the issue in idedisk_check_hpa().
Fixes kernel bugzilla bug #8816.
Thanks to Mikko for investigating the issue and testing this patch.
Cc: Mikko Rapeli <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ide-disk.c | 17 +
1 file changed, 17 insertions(+)
Index: b/drivers/ide/ide-disk.c
===
--- a/drivers/ide/ide-disk.c
+++ b/drivers/ide/ide-disk.c
@@ -481,6 +481,14 @@ static inline int idedisk_supports_lba48
&& id->lba_capacity_2;
}
+/*
+ * Some disks report total number of sectors instead of
+ * maximum sector address. We list them here.
+ */
+static const struct drive_list_entry hpa_list[] = {
+ { "ST340823A", NULL },
+};
+
static void idedisk_check_hpa(ide_drive_t *drive)
{
unsigned long long capacity, set_max;
@@ -492,6 +500,15 @@ static void idedisk_check_hpa(ide_drive_
else
set_max = idedisk_read_native_max_address(drive);
+ if (ide_in_drive_list(drive->id, hpa_list)) {
+ /*
+* Since we are inclusive wrt to firmware revisions do this
+* extra check and apply the workaround only when needed.
+*/
+ if (set_max == capacity + 1)
+ set_max--;
+ }
+
if (set_max <= capacity)
return;
-
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
[PATCH 3/3] aec62xx: always tune PIO
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/pci/aec62xx.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
Index: b/drivers/ide/pci/aec62xx.c
===
--- a/drivers/ide/pci/aec62xx.c
+++ b/drivers/ide/pci/aec62xx.c
@@ -1,5 +1,5 @@
/*
- * linux/drivers/ide/pci/aec62xx.c Version 0.24May 24, 2007
+ * linux/drivers/ide/pci/aec62xx.c Version 0.25Aug 1, 2007
*
* Copyright (C) 1999-2002 Andre Hedrick <[EMAIL PROTECTED]>
* Copyright (C) 2007 MontaVista Software, Inc. <[EMAIL PROTECTED]>
@@ -207,10 +207,10 @@ static void __devinit init_hwif_aec62xx(
} else
hwif->set_dma_mode = &aec6260_set_mode;
- if (!hwif->dma_base) {
- hwif->drives[0].autotune = hwif->drives[1].autotune = 1;
+ hwif->drives[0].autotune = hwif->drives[1].autotune = 1;
+
+ if (hwif->dma_base == 0)
return;
- }
hwif->ultra_mask = hwif->cds->udma_mask;
hwif->mwdma_mask = 0x07;
-
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
[PATCH 2/3] sis5513: always tune PIO
* Always set ->autotune in init_hwif_sis5513(), this means practically
no change in behavior since PIO was always tuned in ->ide_dma_check
and >autotune was always set for ->dma_base == 0 case.
* Bump driver version.
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/pci/sis5513.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
Index: b/drivers/ide/pci/sis5513.c
===
--- a/drivers/ide/pci/sis5513.c
+++ b/drivers/ide/pci/sis5513.c
@@ -1,5 +1,5 @@
/*
- * linux/drivers/ide/pci/sis5513.c Version 0.28Aug 1, 2007
+ * linux/drivers/ide/pci/sis5513.c Version 0.29Aug 1, 2007
*
* Copyright (C) 1999-2000 Andre Hedrick <[EMAIL PROTECTED]>
* Copyright (C) 2002 Lionel Bouton <[EMAIL PROTECTED]>, Maintainer
@@ -603,11 +603,6 @@ static void sis_set_dma_mode(ide_drive_t
static int sis5513_config_xfer_rate(ide_drive_t *drive)
{
- /*
-* TODO: always set PIO mode and remove this
-*/
- ide_set_max_pio(drive);
-
drive->init_speed = 0;
if (ide_tune_dma(drive))
@@ -841,11 +836,11 @@ static void __devinit init_hwif_sis5513
if (chipset_family >= ATA_133)
hwif->udma_filter = sis5513_ata133_udma_filter;
- if (!(hwif->dma_base)) {
- hwif->drives[0].autotune = 1;
- hwif->drives[1].autotune = 1;
+ hwif->drives[0].autotune = 1;
+ hwif->drives[1].autotune = 1;
+
+ if (hwif->dma_base == 0)
return;
- }
hwif->atapi_dma = 1;
-
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
[PATCH 1/3] sis5513: DMA setup fixes
* Add sis_ata133_get_base() helper function for obtaining the address of
the drive control registers on chipset_family == ATA_133 chipsets.
* Add three helper functions for programming PIO/MWDMA timings:
- sis_ata16_program_timings() (for ATA_16/33/66/100a chipset families)
- sis_ata100_program_timings() (for ATA_100/133a chipset families)
- sis_ata133_program_timings() (for ATA_133 chipset family)
MWDMA timings are taken from datasheets and they match ATA spec.
* Add generic helper function sis_program_timings() and use it in
->set_pio_mode and ->set_dma_mode methods (previously the driver
depended on BIOS to program the correct MWDMA timings).
* Remove redundant !chipset_family check from init_hwif_sis5513()
(init_chipset_sis5513() guarantees that we will never get here if
chipset_family cannot be determined).
* SWDMA seems to be unsupported by SiS chipsets (no info about SWDMA in
datasheets and for SWDMA0 mode timing requirements are impossible to
fulfill) so remove ->swdma_mask from init_hwif_sis5513() and handling
of SWDMA modes from sis_set_dma_mode().
* Enable DMA support for chipset_family == ATA_16.
* Bump driver version.
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/pci/sis5513.c | 214 ++
1 file changed, 106 insertions(+), 108 deletions(-)
Index: b/drivers/ide/pci/sis5513.c
===
--- a/drivers/ide/pci/sis5513.c
+++ b/drivers/ide/pci/sis5513.c
@@ -1,5 +1,5 @@
/*
- * linux/drivers/ide/pci/sis5513.c Version 0.27Jul 14, 2007
+ * linux/drivers/ide/pci/sis5513.c Version 0.28Aug 1, 2007
*
* Copyright (C) 1999-2000 Andre Hedrick <[EMAIL PROTECTED]>
* Copyright (C) 2002 Lionel Bouton <[EMAIL PROTECTED]>, Maintainer
@@ -433,6 +433,95 @@ static int sis_get_info (char *buffer, c
/*
* Configuration functions
*/
+
+static u8 sis_ata133_get_base(ide_drive_t *drive)
+{
+ struct pci_dev *dev = drive->hwif->pci_dev;
+ u32 reg54 = 0;
+
+ pci_read_config_dword(dev, 0x54, ®54);
+
+ return ((reg54 & 0x4000) ? 0x70 : 0x40) + drive->dn * 4;
+}
+
+static void sis_ata16_program_timings(ide_drive_t *drive, const u8 mode)
+{
+ struct pci_dev *dev = drive->hwif->pci_dev;
+ u16 t1 = 0;
+ u8 drive_pci = 0x40 + drive->dn * 2;
+
+ const u16 pio_timings[] = { 0x000, 0x607, 0x404, 0x303, 0x301 };
+ const u16 mwdma_timings[] = { 0x008, 0x302, 0x301 };
+
+ pci_read_config_word(dev, drive_pci, &t1);
+
+ /* clear active/recovery timings */
+ t1 &= ~0x070f;
+ if (mode >= XFER_MW_DMA_0) {
+ if (chipset_family > ATA_16)
+ t1 &= ~0x8000; /* disable UDMA */
+ t1 |= mwdma_timings[mode - XFER_MW_DMA_0];
+ } else
+ t1 |= pio_timings[mode - XFER_PIO_0];
+
+ pci_write_config_word(dev, drive_pci, t1);
+}
+
+static void sis_ata100_program_timings(ide_drive_t *drive, const u8 mode)
+{
+ struct pci_dev *dev = drive->hwif->pci_dev;
+ u8 t1, drive_pci = 0x40 + drive->dn * 2;
+
+ /* timing bits: 7:4 active 3:0 recovery */
+ const u8 pio_timings[] = { 0x00, 0x67, 0x44, 0x33, 0x31 };
+ const u8 mwdma_timings[] = { 0x08, 0x32, 0x31 };
+
+ if (mode >= XFER_MW_DMA_0) {
+ u8 t2 = 0;
+
+ pci_read_config_byte(dev, drive_pci, &t2);
+ t2 &= ~0x80;/* disable UDMA */
+ pci_write_config_byte(dev, drive_pci, t2);
+
+ t1 = mwdma_timings[mode - XFER_MW_DMA_0];
+ } else
+ t1 = pio_timings[mode - XFER_PIO_0];
+
+ pci_write_config_byte(dev, drive_pci + 1, t1);
+}
+
+static void sis_ata133_program_timings(ide_drive_t *drive, const u8 mode)
+{
+ struct pci_dev *dev = drive->hwif->pci_dev;
+ u32 t1 = 0;
+ u8 drive_pci = sis_ata133_get_base(drive), clk, idx;
+
+ pci_read_config_dword(dev, drive_pci, &t1);
+
+ t1 &= 0xc0c00fff;
+ clk = (t1 & 0x08) ? ATA_133 : ATA_100;
+ if (mode >= XFER_MW_DMA_0) {
+ t1 &= ~0x04;/* disable UDMA */
+ idx = mode - XFER_MW_DMA_0 + 5;
+ }
+ idx = mode - XFER_PIO_0;
+ t1 |= ini_time_value[clk][idx] << 12;
+ t1 |= act_time_value[clk][idx] << 16;
+ t1 |= rco_time_value[clk][idx] << 24;
+
+ pci_write_config_dword(dev, drive_pci, t1);
+}
+
+static void sis_program_timings(ide_drive_t *drive, const u8 mode)
+{
+ if (chipset_family < ATA_100) /* ATA_16/33/66/100a */
+ sis_ata16_program_timings(drive, mode);
+ else if (chipset_family < ATA_133) /* ATA_100/133a */
+ sis_ata100_program_timings(drive, mode);
+ else/* ATA_133 */
+ sis_ata133_program_timings(drive, mode);
+}
+
/* Enables per-drive prefetch and postwrite */
st
Re: hpt374 sata (Highpoint Rocket 1540)
Bartlomiej Zolnierkiewicz wrote:
On Wednesday 01 August 2007, Sergei Shtylyov wrote:
Does this patch change anything?
Heh, did you *really* hope it will? :-D
Well, ugh, yes? :)
Here we have some really nasty screw-up I'm afraid...
[PATCH] hpt366: always tune PIO
Index: b/drivers/ide/pci/hpt366.c
===
--- a/drivers/ide/pci/hpt366.c
+++ b/drivers/ide/pci/hpt366.c
@@ -1,5 +1,5 @@
/*
- * linux/drivers/ide/pci/hpt366.c Version 1.10Jun 29, 2007
+ * linux/drivers/ide/pci/hpt366.c Version 1.11Jul 29, 2007
*
* Copyright (C) 1999-2003 Andre Hedrick <[EMAIL PROTECTED]>
* Portions Copyright (C) 2001 Sun Microsystems, Inc.
@@ -1265,10 +1265,10 @@ static void __devinit init_hwif_hpt366(i
if (new_mcr != old_mcr)
pci_write_config_byte(dev, hwif->select_data + 1, new_mcr);
- if (!hwif->dma_base) {
- hwif->drives[0].autotune = hwif->drives[1].autotune = 1;
+ hwif->drives[0].autotune = hwif->drives[1].autotune = 1;
+
+ if (hwif->dma_base == 0)
return;
- }
hwif->ultra_mask = hwif->cds->udma_mask;
hwif->mwdma_mask = 0x07;
Concerning the patch (I lacked time to look at the driver to refresh my
memory before -- was looking at the new Disk-on-chip H3 driver to be submitted
for comments soon, BTW): it makes little sense in its current form since
setting any DMA mode also sets 8-bit PIO timings now (and if DMA can't be set,
the driver will fallback to PIO anyway)
Without ->autotune timings for PIO data transfers are never set and we need
The will get overwritten by DMA timings anyway. Although... you're right,
with UltraDMA 16-bit PIO timings aren't going to be changed from the defaults.
to have a valid settings for some commands (IDENTIFY, SMART data) even if
DMA is not going to be used. Thus why I was hoping that this patch might be
of some help.
There's always default settings. ;-)
I have a patch that changes this behavior and switches to always
auto-tuning PIO but I've changed my mind on how the DMA/PIO timing register
sharing should be handled now -- however, since I was unable to come up with
anything better all that time, I'll consider pushing out this version when I
have a spare time...
Please do.
In my copious free time. :-)
Thanks,
Bart
MBR, Sergei
-
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 3/4] Enable link power management for ata drivers
On Wed, 01 Aug 2007 17:27:39 +0900
Tejun Heo <[EMAIL PROTECTED]> wrote:
> Kristen Carlson Accardi wrote:
> Is it safe to use ALPM on a device which only claims to support DIPM?
Yes - I doubled checked this with the AHCI people - and of course you
have Edvin's testing to prove it does fine.
> I think this should be ATA_HORKAGE_IPM.
OK - I changed it.
> > @@ -321,6 +321,8 @@ struct ata_taskfile {
> > ((u64) (id)[(n) + 0]) )
> >
> > #define ata_id_cdb_intr(id)(((id)[0] & 0x60) == 0x20)
> > +#define ata_id_has_hipm(id)((id)[76] & (1 << 9))
> > +#define ata_id_has_dipm(id)((id)[78] & (1 << 3))
>
> We probably need !0x test here.
Thanks, I fixed that too.
As far as moving the enable/disable_pm calls to EH - can you take
a look at the other patch I sent which implements the shost_attrs
to see if I still need to do this? I really don't know much about
the EH stuff - can you explain why we need to use it to set the
link pm?
thanks for your review,
Kristen
-
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 12/12] hpt366: always tune PIO
Bartlomiej Zolnierkiewicz wrote: Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]> MBR, Sergei - 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/4] Expose Power Management Policy option to users
I was able to duplicate Tejun's problem on an ATAPI device I had here.
this updated patch fixed my problem. These devices are just setting
PhyReady (N) and CommWake (W) in Serror on power state changes, ignoring
them seems to be fine, and fixed the problem for me.
Enable Aggressive Link Power management for AHCI controllers.
This patch will set the correct bits to turn on Aggressive
Link Power Management (ALPM) for the ahci driver. This
will cause the controller and disk to negotiate a lower
power state for the link when there is no activity (see
the AHCI 1.x spec for details). This feature is mutually
exclusive with Hot Plug, so when ALPM is enabled, Hot Plug
is disabled. ALPM will be enabled by default, but it is
settable via the scsi host syfs interface. Possible
settings for this feature are:
Setting Effect
--
min_power ALPM is enabled, and link set to enter
lowest power state (SLUMBER) when idle
Hot plug not allowed.
max_performance ALPM is disabled, Hot Plug is allowed
medium_powerALPM is enabled, and link set to enter
second lowest power state (PARTIAL) when
idle. Hot plug not allowed.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
Index: 2.6-git/drivers/ata/ahci.c
===
--- 2.6-git.orig/drivers/ata/ahci.c
+++ 2.6-git/drivers/ata/ahci.c
@@ -48,6 +48,9 @@
#define DRV_NAME "ahci"
#define DRV_VERSION"2.3"
+static int ahci_enable_alpm(struct ata_port *ap,
+ enum link_pm policy);
+static int ahci_disable_alpm(struct ata_port *ap);
enum {
AHCI_PCI_BAR= 5,
@@ -98,6 +101,7 @@ enum {
/* HOST_CAP bits */
HOST_CAP_SSC= (1 << 14), /* Slumber capable */
HOST_CAP_CLO= (1 << 24), /* Command List Override support */
+ HOST_CAP_ALPM = (1 << 26), /* Aggressive Link PM support */
HOST_CAP_SSS= (1 << 27), /* Staggered Spin-up */
HOST_CAP_SNTF = (1 << 29), /* SNotification register */
HOST_CAP_NCQ= (1 << 30), /* Native Command Queueing */
@@ -153,6 +157,8 @@ enum {
PORT_IRQ_PIOS_FIS | PORT_IRQ_D2H_REG_FIS,
/* PORT_CMD bits */
+ PORT_CMD_ASP= (1 << 27), /* Aggressive Slumber/Partial */
+ PORT_CMD_ALPE = (1 << 26), /* Aggressive Link PM enable */
PORT_CMD_ATAPI = (1 << 24), /* Device is ATAPI */
PORT_CMD_LIST_ON= (1 << 15), /* cmd list DMA engine running */
PORT_CMD_FIS_ON = (1 << 14), /* FIS DMA engine running */
@@ -244,6 +250,11 @@ static int ahci_pci_device_suspend(struc
static int ahci_pci_device_resume(struct pci_dev *pdev);
#endif
+static struct class_device_attribute *ahci_shost_attrs[] = {
+ &class_device_attr_link_power_management_policy,
+ NULL
+};
+
static struct scsi_host_template ahci_sht = {
.module = THIS_MODULE,
.name = DRV_NAME,
@@ -261,6 +272,7 @@ static struct scsi_host_template ahci_sh
.slave_configure= ata_scsi_slave_config,
.slave_destroy = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
+ .shost_attrs= ahci_shost_attrs,
};
static const struct ata_port_operations ahci_ops = {
@@ -292,6 +304,8 @@ static const struct ata_port_operations
.port_suspend = ahci_port_suspend,
.port_resume= ahci_port_resume,
#endif
+ .enable_pm = ahci_enable_alpm,
+ .disable_pm = ahci_disable_alpm,
.port_start = ahci_port_start,
.port_stop = ahci_port_stop,
@@ -778,6 +792,156 @@ static void ahci_power_up(struct ata_por
writel(cmd | PORT_CMD_ICC_ACTIVE, port_mmio + PORT_CMD);
}
+static int ahci_disable_alpm(struct ata_port *ap)
+{
+ void __iomem *port_mmio = ahci_port_base(ap);
+ u32 cmd, scontrol;
+ struct ahci_port_priv *pp = ap->private_data;
+
+ /*
+* disable Interface Power Management State Transitions
+* This is accomplished by setting bits 8:11 of the
+* SATA Control register
+*/
+ scontrol = readl(port_mmio + PORT_SCR_CTL);
+ scontrol |= (0x3 << 8);
+ writel(scontrol, port_mmio + PORT_SCR_CTL);
+
+ /* get the existing command bits */
+ cmd = readl(port_mmio + PORT_CMD);
+
+ /* disable ALPM and ASP */
+ cmd &= ~PORT_CMD_ASP;
+ cmd &= ~PORT_CMD_ALPE;
+
+ /* force the interface back to active */
+ cmd |= PORT_CMD_ICC_ACTIVE;
+
+ /* write out new cmd value */
+ writel(cmd, port_mmio + PORT_CMD);
+ cmd = readl(port_mmio + PORT_CMD);
+
+ /* wait 10ms to be sure we've come out of any low p
Re: [patch 1/4] Store interrupt value
Store interrupt value
Use a stored value for which interrupts to enable. Changing this allows
us to selectively turn off certain interrupts later and have them
stay off.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
Index: 2.6-git/drivers/ata/ahci.c
===
--- 2.6-git.orig/drivers/ata/ahci.c
+++ 2.6-git/drivers/ata/ahci.c
@@ -175,6 +175,7 @@ enum {
AHCI_FLAG_32BIT_ONLY= (1 << 28), /* force 32bit */
AHCI_FLAG_MV_PATA = (1 << 29), /* PATA port */
AHCI_FLAG_NO_MSI= (1 << 30), /* no PCI MSI */
+ AHCI_FLAG_NO_HOTPLUG= (1 << 31), /* ignore PxSERR.DIAG.N */
AHCI_FLAG_COMMON= ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
ATA_FLAG_MMIO | ATA_FLAG_PIO_DMA |
@@ -215,6 +216,7 @@ struct ahci_port_priv {
unsigned intncq_saw_d2h:1;
unsigned intncq_saw_dmas:1;
unsigned intncq_saw_sdb:1;
+ u32 intr_mask; /* interrupts to enable */
};
static int ahci_scr_read(struct ata_port *ap, unsigned int sc_reg, u32 *val);
@@ -1518,6 +1520,7 @@ static void ahci_thaw(struct ata_port *a
void __iomem *mmio = ap->host->iomap[AHCI_PCI_BAR];
void __iomem *port_mmio = ahci_port_base(ap);
u32 tmp;
+ struct ahci_port_priv *pp = ap->private_data;
/* clear IRQ */
tmp = readl(port_mmio + PORT_IRQ_STAT);
@@ -1525,7 +1528,7 @@ static void ahci_thaw(struct ata_port *a
writel(1 << ap->port_no, mmio + HOST_IRQ_STAT);
/* turn IRQ back on */
- writel(DEF_PORT_IRQ, port_mmio + PORT_IRQ_MASK);
+ writel(pp->intr_mask, port_mmio + PORT_IRQ_MASK);
}
static void ahci_error_handler(struct ata_port *ap)
@@ -1679,6 +1682,12 @@ static int ahci_port_start(struct ata_po
pp->cmd_tbl = mem;
pp->cmd_tbl_dma = mem_dma;
+ /*
+* Save off initial list of interrupts to be enabled.
+* This could be changed later
+*/
+ pp->intr_mask = DEF_PORT_IRQ;
+
ap->private_data = pp;
/* engage engines, captain */
-
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: Marvell 7042 (sata_mv) fails to initialize drive
I have done some more testing, and it now looks as if this was actually a hardware fault. Reseating the PCI-E card made the problem go away (knock on wood). I am a little puzzled that it is possible for the card to show up on the PCI bus, and for the driver to be able to detect whether a disk is connected, but then for it to fail to communicate with the disk. But oh well, I guess if just some of the PCI-E signals aren't connected, strange error modes are to be expected. Sorry for the false alarm. And just for the record, if any you need any more testing done with 7042 controllers, feel free to ask me for help -- I think I read somewhere that Jeff was looking for testers that have access to this hardware. Markus - 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/4] Expose Power Management Policy option to users
On Wed, 01 Aug 2007 12:24:44 +0900
Tejun Heo <[EMAIL PROTECTED]> wrote:
> Kristen Carlson Accardi wrote:
> >> I don't think the interface you're suggesting is a good one. Do you?
> >
> > I think if it's applicable to SCSI at all it is fine. If it is not, then
> > I think we need to make do with the interface we are given. I do not think
> > we should hold up a feature for libata sysfs integration.
>
> Well, I guess we'll have to agree to disagree here and leave the
> decision to James and Jeff.
A compromise to avoiding having this in SCSI is to use the
shost_attrs array in the scsi host template. This will not change the way
the interface will look, it will just remove any link power management
stuff from the scsi subsystem directly and have it be an ATA only attribute.
I did go ahead and leave the Documentation file in the scsi directory
because that is where the attribute winds up being visible to the user.
Here's the patch, and this series is also available at
http://www.kernel.org/pub/linux/kernel/people/kristen/patches/SATA/alpm:
Enable link power management for ata drivers
libata drivers can define a function (enable_pm) that will
perform hardware specific actions to enable whatever power
management policy the user set up from the scsi sysfs
interface if the driver supports it. This power management
policy will be activated after all disks have been
enumerated and intialized. Drivers should also define
disable_pm, which will turn off link power management, but
not change link power management policy.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
Index: 2.6-git/drivers/ata/libata-scsi.c
===
--- 2.6-git.orig/drivers/ata/libata-scsi.c
+++ 2.6-git/drivers/ata/libata-scsi.c
@@ -110,6 +110,78 @@ static struct scsi_transport_template at
.user_scan = ata_scsi_user_scan,
};
+static const struct {
+ enum link_pmvalue;
+ char*name;
+} link_pm_policy[] = {
+ { NOT_AVAILABLE, "max_performance" },
+ { MIN_POWER, "min_power" },
+ { MAX_PERFORMANCE, "max_performance" },
+ { MEDIUM_POWER, "medium_power" },
+};
+
+const char *ata_scsi_link_pm_policy(enum link_pm policy)
+{
+ int i;
+ char *name = NULL;
+
+ for (i = 0; i < ARRAY_SIZE(link_pm_policy); i++) {
+ if (link_pm_policy[i].value == policy) {
+ name = link_pm_policy[i].name;
+ break;
+ }
+ }
+ return name;
+}
+
+static ssize_t store_link_pm_policy(struct class_device *class_dev,
+ const char *buf, size_t count)
+{
+ struct Scsi_Host *shost = class_to_shost(class_dev);
+ struct ata_port *ap = ata_shost_to_port(shost);
+ enum link_pm policy = 0;
+ int i;
+
+ /*
+* we are skipping array location 0 on purpose - this
+* is because a value of NOT_AVAILABLE is displayed
+* to the user as max_performance, but when the user
+* writes "max_performance", they actually want the
+* value to match MAX_PERFORMANCE.
+*/
+ for (i = 1; i < ARRAY_SIZE(link_pm_policy); i++) {
+ const int len = strlen(link_pm_policy[i].name);
+ if (strncmp(link_pm_policy[i].name, buf, len) == 0 &&
+ buf[len] == '\n') {
+ policy = link_pm_policy[i].value;
+ break;
+ }
+ }
+ if (!policy)
+ return -EINVAL;
+
+ if (ata_scsi_set_link_pm_policy(ap, policy))
+ return -EINVAL;
+ return count;
+}
+
+static ssize_t
+show_link_pm_policy(struct class_device *class_dev, char *buf)
+{
+ struct Scsi_Host *shost = class_to_shost(class_dev);
+ struct ata_port *ap = ata_shost_to_port(shost);
+ const char *policy =
+ ata_scsi_link_pm_policy(ap->pm_policy);
+
+ if (!policy)
+ return -EINVAL;
+
+ return snprintf(buf, 23, "%s\n", policy);
+}
+CLASS_DEVICE_ATTR(link_power_management_policy, S_IRUGO | S_IWUSR,
+ show_link_pm_policy, store_link_pm_policy);
+EXPORT_SYMBOL_GPL(class_device_attr_link_power_management_policy);
+
static void ata_scsi_invalid_field(struct scsi_cmnd *cmd,
void (*done)(struct scsi_cmnd *))
{
@@ -2904,6 +2976,47 @@ void ata_scsi_simulate(struct ata_device
}
}
+int ata_scsi_set_link_pm_policy(struct ata_port *ap,
+ enum link_pm policy)
+{
+ int rc = -EINVAL;
+ int i;
+
+ /*
+* make sure no broken devices are on this port,
+* and that all devices support interface power
+* management
+*/
+ for (i = 0; i < ATA_MAX_DEVICES; i++) {
+ struct ata_device *dev = &ap->device[i];
+
+ /* only check drives which exist */
+ if (!ata_dev_enabled(dev))
+ con
Re: hpt374 sata (Highpoint Rocket 1540)
Hi,
On Wednesday 01 August 2007, Sergei Shtylyov wrote:
> > Does this patch change anything?
>
> Heh, did you *really* hope it will? :-D
Well, ugh, yes? :)
> > [PATCH] hpt366: always tune PIO
>
> > Index: b/drivers/ide/pci/hpt366.c
> > ===
> > --- a/drivers/ide/pci/hpt366.c
> > +++ b/drivers/ide/pci/hpt366.c
> > @@ -1,5 +1,5 @@
> > /*
> > - * linux/drivers/ide/pci/hpt366.c Version 1.10Jun 29, 2007
> > + * linux/drivers/ide/pci/hpt366.c Version 1.11Jul 29, 2007
> > *
> > * Copyright (C) 1999-2003 Andre Hedrick <[EMAIL PROTECTED]>
> > * Portions Copyright (C) 2001 Sun Microsystems, Inc.
> > @@ -1265,10 +1265,10 @@ static void __devinit init_hwif_hpt366(i
> > if (new_mcr != old_mcr)
> > pci_write_config_byte(dev, hwif->select_data + 1, new_mcr);
> >
> > - if (!hwif->dma_base) {
> > - hwif->drives[0].autotune = hwif->drives[1].autotune = 1;
> > + hwif->drives[0].autotune = hwif->drives[1].autotune = 1;
> > +
> > + if (hwif->dma_base == 0)
> > return;
> > - }
> >
> > hwif->ultra_mask = hwif->cds->udma_mask;
> > hwif->mwdma_mask = 0x07;
>
> Concerning the patch (I lacked time to look at the driver to refresh my
> memory before -- was looking at the new Disk-on-chip H3 driver to be
> submitted
> for comments soon, BTW): it makes little sense in its current form since
> setting any DMA mode also sets 8-bit PIO timings now (and if DMA can't be
> set,
> the driver will fallback to PIO anyway)
Without ->autotune timings for PIO data transfers are never set and we need
to have a valid settings for some commands (IDENTIFY, SMART data) even if
DMA is not going to be used. Thus why I was hoping that this patch might be
of some help.
> I have a patch that changes this behavior and switches to always
> auto-tuning PIO but I've changed my mind on how the DMA/PIO timing register
> sharing should be handled now -- however, since I was unable to come up with
> anything better all that time, I'll consider pushing out this version when I
> have a spare time...
Please do.
Thanks,
Bart
-
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: hpt374 sata (Highpoint Rocket 1540)
Bob Ham wrote: hpt37x: DPLL did not stabilize. pata_hpt37x: BIOS has not set timing clocks. hpt37x: DPLL did not stabilize. Yes, this ia a known issue, and the fix for it is in the -mm tree: I applied just that pata_hpt37x.c patch, not the whole -mm tree. It locks the machine hard again. Here is the transcribed output: hpt37x: Bus clock 66 MHz, using DPLL. Oh?! hpt366.c detected 33 MHz... :-O ACPI: PCI Interrupt :00:0d.0[A] -> GSI 16 (level, low) -> IRQ 17 scsi2: pata_hpt37x scsi3: pata_hpt37x ata3: PATA max UDMA/100 cmd 0x0001efa0 ctl 0x0001ef9e bmdma 0x0001ec00 irq 17 ata4: PATA max UDMA/100 cmd 0x0001ef90 ctl 0x0001ef9a bmdma 0x0001ec00 irq 17 MBR, Sergei - 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: hpt374 sata (Highpoint Rocket 1540)
On Wed, 2007-08-01 at 19:58 +0400, Sergei Shtylyov wrote: > > hpt37x: DPLL did not stabilize. > > pata_hpt37x: BIOS has not set timing clocks. > > hpt37x: DPLL did not stabilize. > >Yes, this ia a known issue, and the fix for it is in the -mm tree: I applied just that pata_hpt37x.c patch, not the whole -mm tree. It locks the machine hard again. Here is the transcribed output: hpt37x: Bus clock 66 MHz, using DPLL. ACPI: PCI Interrupt :00:0d.0[A] -> GSI 16 (level, low) -> IRQ 17 scsi2: pata_hpt37x scsi3: pata_hpt37x ata3: PATA max UDMA/100 cmd 0x0001efa0 ctl 0x0001ef9e bmdma 0x0001ec00 irq 17 ata4: PATA max UDMA/100 cmd 0x0001ef90 ctl 0x0001ef9a bmdma 0x0001ec00 irq 17 -- Bob Ham <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: [PATCH] fix runtogether printk's in cmd64x IDE driver
On Sunday 29 July 2007, Meelis Roos wrote: > Fix a couple of runtogether printks in cmd64x.c IDE driver by adding > proper newlines. > > Signed-off-by: Meelis Roos <[EMAIL PROTECTED]> applied - 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: hpt374 sata (Highpoint Rocket 1540)
On Wednesday 01 August 2007, Sergei Shtylyov wrote:
> Bartlomiej Zolnierkiewicz wrote:
> > On Wednesday 01 August 2007, Sergei Shtylyov wrote:
>
> >>>Does this patch change anything?
>
> >>Heh, did you *really* hope it will? :-D
>
> > Well, ugh, yes? :)
>
> Here we have some really nasty screw-up I'm afraid...
>
> >>>[PATCH] hpt366: always tune PIO
>
> >>>Index: b/drivers/ide/pci/hpt366.c
> >>>===
> >>>--- a/drivers/ide/pci/hpt366.c
> >>>+++ b/drivers/ide/pci/hpt366.c
> >>>@@ -1,5 +1,5 @@
> >>> /*
> >>>- * linux/drivers/ide/pci/hpt366.c Version 1.10Jun 29, 2007
> >>>+ * linux/drivers/ide/pci/hpt366.c Version 1.11Jul 29, 2007
> >>> *
> >>> * Copyright (C) 1999-2003Andre Hedrick <[EMAIL
> >>> PROTECTED]>
> >>> * Portions Copyright (C) 2001Sun Microsystems, Inc.
> >>>@@ -1265,10 +1265,10 @@ static void __devinit init_hwif_hpt366(i
> >>> if (new_mcr != old_mcr)
> >>> pci_write_config_byte(dev, hwif->select_data + 1, new_mcr);
> >>>
> >>>- if (!hwif->dma_base) {
> >>>- hwif->drives[0].autotune = hwif->drives[1].autotune = 1;
> >>>+ hwif->drives[0].autotune = hwif->drives[1].autotune = 1;
> >>>+
> >>>+ if (hwif->dma_base == 0)
> >>> return;
> >>>- }
> >>>
> >>> hwif->ultra_mask = hwif->cds->udma_mask;
> >>> hwif->mwdma_mask = 0x07;
> >>
> >>Concerning the patch (I lacked time to look at the driver to refresh my
> >>memory before -- was looking at the new Disk-on-chip H3 driver to be
> >>submitted
> >>for comments soon, BTW): it makes little sense in its current form since
> >>setting any DMA mode also sets 8-bit PIO timings now (and if DMA can't be
> >>set,
> >>the driver will fallback to PIO anyway)
>
> > Without ->autotune timings for PIO data transfers are never set and we need
>
> The will get overwritten by DMA timings anyway. Although... you're
> right,
Shouldn't be a real issue - for the usual case (PIO4/MWDMA2) it is not
a problem since PIO data and DMA timings match and I also don't remember
seeing devices which would allow S/MWDMA timings shorter than PIO timings.
> with UltraDMA 16-bit PIO timings aren't going to be changed from the defaults.
Bart
-
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
[patch 0/3] Updated ALPM patches
Hi, This is an updated series of ALPM patches. I moved all link power management stuff out of scsi sysfs and just use the shost_addr pointer in the host template to create the sysfs files. This provides the same interface as before, without requiring any scsi changes. I also fixed a bug in the handling of the interrupts for some devices (mostly ATAPI it seems) which will need some bits out of Serror cleared on power state changes, and I also modified the code slightly based on feedback from tejun. please review, Thanks, Kristen -- - 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
[patch 1/3] Store interrupt value
Use a stored value for which interrupts to enable. Changing this allows
us to selectively turn off certain interrupts later and have them
stay off.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
Index: 2.6-git/drivers/ata/ahci.c
===
--- 2.6-git.orig/drivers/ata/ahci.c
+++ 2.6-git/drivers/ata/ahci.c
@@ -175,6 +175,7 @@ enum {
AHCI_FLAG_32BIT_ONLY= (1 << 28), /* force 32bit */
AHCI_FLAG_MV_PATA = (1 << 29), /* PATA port */
AHCI_FLAG_NO_MSI= (1 << 30), /* no PCI MSI */
+ AHCI_FLAG_NO_HOTPLUG= (1 << 31), /* ignore PxSERR.DIAG.N */
AHCI_FLAG_COMMON= ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
ATA_FLAG_MMIO | ATA_FLAG_PIO_DMA |
@@ -215,6 +216,7 @@ struct ahci_port_priv {
unsigned intncq_saw_d2h:1;
unsigned intncq_saw_dmas:1;
unsigned intncq_saw_sdb:1;
+ u32 intr_mask; /* interrupts to enable */
};
static int ahci_scr_read(struct ata_port *ap, unsigned int sc_reg, u32 *val);
@@ -1518,6 +1520,7 @@ static void ahci_thaw(struct ata_port *a
void __iomem *mmio = ap->host->iomap[AHCI_PCI_BAR];
void __iomem *port_mmio = ahci_port_base(ap);
u32 tmp;
+ struct ahci_port_priv *pp = ap->private_data;
/* clear IRQ */
tmp = readl(port_mmio + PORT_IRQ_STAT);
@@ -1525,7 +1528,7 @@ static void ahci_thaw(struct ata_port *a
writel(1 << ap->port_no, mmio + HOST_IRQ_STAT);
/* turn IRQ back on */
- writel(DEF_PORT_IRQ, port_mmio + PORT_IRQ_MASK);
+ writel(pp->intr_mask, port_mmio + PORT_IRQ_MASK);
}
static void ahci_error_handler(struct ata_port *ap)
@@ -1679,6 +1682,12 @@ static int ahci_port_start(struct ata_po
pp->cmd_tbl = mem;
pp->cmd_tbl_dma = mem_dma;
+ /*
+* Save off initial list of interrupts to be enabled.
+* This could be changed later
+*/
+ pp->intr_mask = DEF_PORT_IRQ;
+
ap->private_data = pp;
/* engage engines, captain */
--
-
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
[patch 2/3] Enable link power management for ata drivers
libata drivers can define a function (enable_pm) that will
perform hardware specific actions to enable whatever power
management policy the user set up from the scsi sysfs
interface if the driver supports it. This power management
policy will be activated after all disks have been
enumerated and intialized. Drivers should also define
disable_pm, which will turn off link power management, but
not change link power management policy.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
Index: 2.6-git/drivers/ata/libata-scsi.c
===
--- 2.6-git.orig/drivers/ata/libata-scsi.c
+++ 2.6-git/drivers/ata/libata-scsi.c
@@ -110,6 +110,78 @@ static struct scsi_transport_template at
.user_scan = ata_scsi_user_scan,
};
+static const struct {
+ enum link_pmvalue;
+ char*name;
+} link_pm_policy[] = {
+ { NOT_AVAILABLE, "max_performance" },
+ { MIN_POWER, "min_power" },
+ { MAX_PERFORMANCE, "max_performance" },
+ { MEDIUM_POWER, "medium_power" },
+};
+
+const char *ata_scsi_link_pm_policy(enum link_pm policy)
+{
+ int i;
+ char *name = NULL;
+
+ for (i = 0; i < ARRAY_SIZE(link_pm_policy); i++) {
+ if (link_pm_policy[i].value == policy) {
+ name = link_pm_policy[i].name;
+ break;
+ }
+ }
+ return name;
+}
+
+static ssize_t store_link_pm_policy(struct class_device *class_dev,
+ const char *buf, size_t count)
+{
+ struct Scsi_Host *shost = class_to_shost(class_dev);
+ struct ata_port *ap = ata_shost_to_port(shost);
+ enum link_pm policy = 0;
+ int i;
+
+ /*
+* we are skipping array location 0 on purpose - this
+* is because a value of NOT_AVAILABLE is displayed
+* to the user as max_performance, but when the user
+* writes "max_performance", they actually want the
+* value to match MAX_PERFORMANCE.
+*/
+ for (i = 1; i < ARRAY_SIZE(link_pm_policy); i++) {
+ const int len = strlen(link_pm_policy[i].name);
+ if (strncmp(link_pm_policy[i].name, buf, len) == 0 &&
+ buf[len] == '\n') {
+ policy = link_pm_policy[i].value;
+ break;
+ }
+ }
+ if (!policy)
+ return -EINVAL;
+
+ if (ata_scsi_set_link_pm_policy(ap, policy))
+ return -EINVAL;
+ return count;
+}
+
+static ssize_t
+show_link_pm_policy(struct class_device *class_dev, char *buf)
+{
+ struct Scsi_Host *shost = class_to_shost(class_dev);
+ struct ata_port *ap = ata_shost_to_port(shost);
+ const char *policy =
+ ata_scsi_link_pm_policy(ap->pm_policy);
+
+ if (!policy)
+ return -EINVAL;
+
+ return snprintf(buf, 23, "%s\n", policy);
+}
+CLASS_DEVICE_ATTR(link_power_management_policy, S_IRUGO | S_IWUSR,
+ show_link_pm_policy, store_link_pm_policy);
+EXPORT_SYMBOL_GPL(class_device_attr_link_power_management_policy);
+
static void ata_scsi_invalid_field(struct scsi_cmnd *cmd,
void (*done)(struct scsi_cmnd *))
{
@@ -2904,6 +2976,47 @@ void ata_scsi_simulate(struct ata_device
}
}
+int ata_scsi_set_link_pm_policy(struct ata_port *ap,
+ enum link_pm policy)
+{
+ int rc = -EINVAL;
+ int i;
+
+ /*
+* make sure no broken devices are on this port,
+* and that all devices support interface power
+* management
+*/
+ for (i = 0; i < ATA_MAX_DEVICES; i++) {
+ struct ata_device *dev = &ap->device[i];
+
+ /* only check drives which exist */
+ if (!ata_dev_enabled(dev))
+ continue;
+
+ /*
+* do we need to handle the case where we've hotplugged
+* a broken drive (since hotplug and ALPM are mutually
+* exclusive) ?
+*
+* If so, if we detect a broken drive on a port with
+* alpm already enabled, then we should reset the policy
+* to off for the entire port.
+*/
+ if ((dev->horkage & ATA_HORKAGE_IPM) ||
+ !(dev->flags & ATA_DFLAG_IPM)) {
+ ata_dev_printk(dev, KERN_ERR,
+ "Unable to set Link PM policy\n");
+ ap->pm_policy = MAX_PERFORMANCE;
+ }
+ }
+
+ if (ap->ops->enable_pm)
+ rc = ap->ops->enable_pm(ap, policy);
+ return rc;
+}
+EXPORT_SYMBOL_GPL(ata_scsi_set_link_pm_policy);
+
int ata_scsi_add_hosts(struct ata_host *host, struct scsi_host_template *sht)
{
int i, rc;
Index: 2.6-git/include/linux/libata.h
==
[patch 3/3] Enable Aggressive Link Power management for AHCI controllers.
This patch will set the correct bits to turn on Aggressive
Link Power Management (ALPM) for the ahci driver. This
will cause the controller and disk to negotiate a lower
power state for the link when there is no activity (see
the AHCI 1.x spec for details). This feature is mutually
exclusive with Hot Plug, so when ALPM is enabled, Hot Plug
is disabled. ALPM will be enabled by default, but it is
settable via the scsi host syfs interface. Possible
settings for this feature are:
Setting Effect
--
min_power ALPM is enabled, and link set to enter
lowest power state (SLUMBER) when idle
Hot plug not allowed.
max_performance ALPM is disabled, Hot Plug is allowed
medium_powerALPM is enabled, and link set to enter
second lowest power state (PARTIAL) when
idle. Hot plug not allowed.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
Index: 2.6-git/drivers/ata/ahci.c
===
--- 2.6-git.orig/drivers/ata/ahci.c
+++ 2.6-git/drivers/ata/ahci.c
@@ -48,6 +48,9 @@
#define DRV_NAME "ahci"
#define DRV_VERSION"2.3"
+static int ahci_enable_alpm(struct ata_port *ap,
+ enum link_pm policy);
+static int ahci_disable_alpm(struct ata_port *ap);
enum {
AHCI_PCI_BAR= 5,
@@ -98,6 +101,7 @@ enum {
/* HOST_CAP bits */
HOST_CAP_SSC= (1 << 14), /* Slumber capable */
HOST_CAP_CLO= (1 << 24), /* Command List Override support */
+ HOST_CAP_ALPM = (1 << 26), /* Aggressive Link PM support */
HOST_CAP_SSS= (1 << 27), /* Staggered Spin-up */
HOST_CAP_SNTF = (1 << 29), /* SNotification register */
HOST_CAP_NCQ= (1 << 30), /* Native Command Queueing */
@@ -153,6 +157,8 @@ enum {
PORT_IRQ_PIOS_FIS | PORT_IRQ_D2H_REG_FIS,
/* PORT_CMD bits */
+ PORT_CMD_ASP= (1 << 27), /* Aggressive Slumber/Partial */
+ PORT_CMD_ALPE = (1 << 26), /* Aggressive Link PM enable */
PORT_CMD_ATAPI = (1 << 24), /* Device is ATAPI */
PORT_CMD_LIST_ON= (1 << 15), /* cmd list DMA engine running */
PORT_CMD_FIS_ON = (1 << 14), /* FIS DMA engine running */
@@ -244,6 +250,11 @@ static int ahci_pci_device_suspend(struc
static int ahci_pci_device_resume(struct pci_dev *pdev);
#endif
+static struct class_device_attribute *ahci_shost_attrs[] = {
+ &class_device_attr_link_power_management_policy,
+ NULL
+};
+
static struct scsi_host_template ahci_sht = {
.module = THIS_MODULE,
.name = DRV_NAME,
@@ -261,6 +272,7 @@ static struct scsi_host_template ahci_sh
.slave_configure= ata_scsi_slave_config,
.slave_destroy = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
+ .shost_attrs= ahci_shost_attrs,
};
static const struct ata_port_operations ahci_ops = {
@@ -292,6 +304,8 @@ static const struct ata_port_operations
.port_suspend = ahci_port_suspend,
.port_resume= ahci_port_resume,
#endif
+ .enable_pm = ahci_enable_alpm,
+ .disable_pm = ahci_disable_alpm,
.port_start = ahci_port_start,
.port_stop = ahci_port_stop,
@@ -778,6 +792,156 @@ static void ahci_power_up(struct ata_por
writel(cmd | PORT_CMD_ICC_ACTIVE, port_mmio + PORT_CMD);
}
+static int ahci_disable_alpm(struct ata_port *ap)
+{
+ void __iomem *port_mmio = ahci_port_base(ap);
+ u32 cmd, scontrol;
+ struct ahci_port_priv *pp = ap->private_data;
+
+ /*
+* disable Interface Power Management State Transitions
+* This is accomplished by setting bits 8:11 of the
+* SATA Control register
+*/
+ scontrol = readl(port_mmio + PORT_SCR_CTL);
+ scontrol |= (0x3 << 8);
+ writel(scontrol, port_mmio + PORT_SCR_CTL);
+
+ /* get the existing command bits */
+ cmd = readl(port_mmio + PORT_CMD);
+
+ /* disable ALPM and ASP */
+ cmd &= ~PORT_CMD_ASP;
+ cmd &= ~PORT_CMD_ALPE;
+
+ /* force the interface back to active */
+ cmd |= PORT_CMD_ICC_ACTIVE;
+
+ /* write out new cmd value */
+ writel(cmd, port_mmio + PORT_CMD);
+ cmd = readl(port_mmio + PORT_CMD);
+
+ /* wait 10ms to be sure we've come out of any low power state */
+ msleep(10);
+
+ /* clear out any PhyRdy stuff from interrupt status */
+ writel(PORT_IRQ_PHYRDY, port_mmio + PORT_IRQ_STAT);
+
+ /* go ahead and clean out PhyRdy Change from Serror too */
+ ahci_scr_write(ap, SCR_ERROR, ((1 << 16) | (1 << 18)));
+
+ /*
+* Clear flag to in
Re: ST340823A disk size issue
On Wed, Aug 01, 2007 at 10:34:03PM +0200, Bartlomiej Zolnierkiewicz wrote:
> Could you try attached patch?
>
> [PATCH] ide-disk: workaround for buggy HPA support on ST340823A
Umh, it's getting late but some makefile magic maybe missing, or I
should do a clean build?
$ make drivers/ide/ide-disk.ko V=1
rm -f include/config/kernel.release
echo 2.6.22.1 > include/config/kernel.release
set -e; echo ' CHK include/linux/version.h'; mkdir -p
include/linux/; (echo \#define LINUX_VERSION_CODE 132630; echo
'#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))';) <
/home/mcfrisk/src/linux/linux-2.6.22.1.new/Makefile >
include/linux/version.h.tmp; if [ -r include/linux/version.h ] && cmp -s
include/linux/version.h include/linux/version.h.tmp; then rm -f
include/linux/version.h.tmp; else echo ' UPD
include/linux/version.h'; mv -f include/linux/version.h.tmp
include/linux/version.h; fi
CHK include/linux/version.h
set -e; echo ' CHK include/linux/utsrelease.h'; mkdir -p
include/linux/; if [ `echo -n "2.6.22.1" | wc -c ` -gt 64 ]; then echo
'"2.6.22.1" exceeds 64 characters' >&2; exit 1; fi; (echo \#define
UTS_RELEASE \"2.6.22.1\";) < include/config/kernel.release >
include/linux/utsrelease.h.tmp; if [ -r include/linux/utsrelease.h ] &&
cmp -s include/linux/utsrelease.h include/linux/utsrelease.h.tmp; then
rm -f include/linux/utsrelease.h.tmp; else echo ' UPD
include/linux/utsrelease.h'; mv -f include/linux/utsrelease.h.tmp
include/linux/utsrelease.h; fi
CHK include/linux/utsrelease.h
make -f scripts/Makefile.build obj=scripts/basic
make -f scripts/Makefile.build obj=.
mkdir -p arch/i386/kernel/
make -f scripts/Makefile.build obj=. missing-syscalls
/bin/sh scripts/checksyscalls.sh gcc -m32
-Wp,-MD,./.missing-syscalls.d -nostdinc -isystem
/usr/lib/gcc/i486-linux-gnu/4.1.3/include -D__KERNEL__ -Iinclude
-include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes
-Wno-trigraphs -fno-strict-aliasing -fno-common -Os -pipe -msoft-float
-mregparm=3 -freg-struct-return -mpreferred-stack-boundary=2
-march=i486 -mtune=generic -ffreestanding -maccumulate-outgoing-args
-DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1
-Iinclude/asm-i386/mach-default -fomit-frame-pointer -g
-fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign
-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(missing_syscalls)"
-D"KBUILD_MODNAME=KBUILD_STR(missing_syscalls)"
make -f scripts/Makefile.build obj=scripts
make -f scripts/Makefile.build obj=scripts/genksyms
make -f scripts/Makefile.build obj=scripts/mod
make KBUILD_MODULES=1 \
-f scripts/Makefile.build obj=drivers/ide drivers/ide/ide-disk.o
make -f
/home/mcfrisk/src/linux/linux-2.6.22.1.new/scripts/Makefile.modpost
scripts/mod/modpost -m -o
/home/mcfrisk/src/linux/linux-2.6.22.1.new/Module.symvers
ERROR: "ide_in_drive_list" [drivers/ide/ide-disk.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [drivers/ide/ide-disk.ko] Error 2
Based on Alan's comments I'm already running 2.6.22.1 with this:
diff -ru linux-2.6.22.1/drivers/ide/ide-disk.c
linux-2.6.22.1.new/drivers/ide/ide-disk.c
--- linux-2.6.22.1/drivers/ide/ide-disk.c 2007-07-10 21:56:30.0
+0300
+++ linux-2.6.22.1.new/drivers/ide/ide-disk.c 2007-08-01 22:59:47.0
+0300
@@ -502,6 +502,17 @@
capacity, sectors_to_MB(capacity),
set_max, sectors_to_MB(set_max));
+ if ((set_max % 2) && (set_max == capacity + 1)) {
+ printk(KERN_INFO "Old drive detected, keeping current
capacity.\n");
+ return;
+ }
+
if (lba48)
set_max = idedisk_set_max_address_ext(drive, set_max);
else
-
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
[git patches] IDE fixes
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/bart/ide-2.6.git/
to receive the following updates:
drivers/ide/arm/icside.c |3 +-
drivers/ide/ide-tape.c |2 +-
drivers/ide/pci/alim15x3.c |2 +-
drivers/ide/pci/cmd64x.c |4 +-
drivers/ide/pci/cs5520.c |2 +-
drivers/ide/pci/cs5535.c | 42 +-
drivers/ide/pci/it8213.c | 33 ---
drivers/ide/pci/jmicron.c | 21 +++
drivers/ide/pci/piix.c | 17 ++--
drivers/ide/pci/scc_pata.c | 61 ++-
drivers/ide/pci/sis5513.c |1 +
drivers/ide/pci/slc90e66.c | 15 +--
drivers/scsi/ide-scsi.c| 10 +++
13 files changed, 85 insertions(+), 128 deletions(-)
Bartlomiej Zolnierkiewicz (7):
alim15x3: Correct HP detect
cs5520: fix PIO auto-tuning in ->ide_dma_check method
cs5535: PIO fixes
it8213: PIO fixes (take 2)
jmicron: PIO fixes
piix/slc90e66: fix PIO1 handling in ->speedproc method (take 2)
scc_pata: PIO fixes
David Lamparter (1):
sis5513: Add FSC Amilo A1630 PCI subvendor/dev to laptops
Jordan Crouse (1):
ide: Fix an overrun found in the CS5535 IDE driver
Mariusz Kozlowski (2):
drivers/ide/arm/icside.c: kmalloc + memset conversion to kzalloc
drivers/scsi/ide-scsi.c: kmalloc + memset conversion to kzalloc
Meelis Roos (1):
ide: fix runtogether printk's in cmd64x IDE driver
Stephen Rothwell (1):
ide: eliminate warnings in ide-tape.c
diff --git a/drivers/ide/arm/icside.c b/drivers/ide/arm/icside.c
index c89b5f4..8a9b98f 100644
--- a/drivers/ide/arm/icside.c
+++ b/drivers/ide/arm/icside.c
@@ -693,13 +693,12 @@ icside_probe(struct expansion_card *ec, const struct
ecard_id *id)
if (ret)
goto out;
- state = kmalloc(sizeof(struct icside_state), GFP_KERNEL);
+ state = kzalloc(sizeof(struct icside_state), GFP_KERNEL);
if (!state) {
ret = -ENOMEM;
goto release;
}
- memset(state, 0, sizeof(state));
state->type = ICS_TYPE_NOTYPE;
state->dev = &ec->dev;
diff --git a/drivers/ide/ide-tape.c b/drivers/ide/ide-tape.c
index e82bfa5..1fa5794 100644
--- a/drivers/ide/ide-tape.c
+++ b/drivers/ide/ide-tape.c
@@ -640,7 +640,7 @@ typedef enum {
} idetape_chrdev_direction_t;
struct idetape_bh {
- unsigned short b_size;
+ u32 b_size;
atomic_t b_count;
struct idetape_bh *b_reqnext;
char *b_data;
diff --git a/drivers/ide/pci/alim15x3.c b/drivers/ide/pci/alim15x3.c
index 5511c86..025689d 100644
--- a/drivers/ide/pci/alim15x3.c
+++ b/drivers/ide/pci/alim15x3.c
@@ -593,7 +593,7 @@ static struct dmi_system_id cable_dmi_table[] = {
.ident = "HP Pavilion N5430",
.matches = {
DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
- DMI_MATCH(DMI_BOARD_NAME, "OmniBook N32N-736"),
+ DMI_MATCH(DMI_BOARD_VERSION, "OmniBook N32N-736"),
},
},
{ }
diff --git a/drivers/ide/pci/cmd64x.c b/drivers/ide/pci/cmd64x.c
index 19633c5..0e3b5de 100644
--- a/drivers/ide/pci/cmd64x.c
+++ b/drivers/ide/pci/cmd64x.c
@@ -475,11 +475,11 @@ static unsigned int __devinit init_chipset_cmd64x(struct
pci_dev *dev, const cha
switch (rev) {
case 0x07:
case 0x05:
- printk("%s: UltraDMA capable", name);
+ printk("%s: UltraDMA capable\n", name);
break;
case 0x03:
default:
- printk("%s: MultiWord DMA force limited", name);
+ printk("%s: MultiWord DMA force limited\n", name);
break;
case 0x01:
printk("%s: MultiWord DMA limited, "
diff --git a/drivers/ide/pci/cs5520.c b/drivers/ide/pci/cs5520.c
index bccedf9..b89e816 100644
--- a/drivers/ide/pci/cs5520.c
+++ b/drivers/ide/pci/cs5520.c
@@ -133,7 +133,7 @@ static void cs5520_tune_drive(ide_drive_t *drive, u8 pio)
static int cs5520_config_drive_xfer_rate(ide_drive_t *drive)
{
/* Tune the drive for PIO modes up to PIO 4 */
- cs5520_tune_drive(drive, 4);
+ cs5520_tune_drive(drive, 255);
/* Then tell the core to use DMA operations */
return 0;
diff --git a/drivers/ide/pci/cs5535.c b/drivers/ide/pci/cs5535.c
index ce44e38..082ca7d 100644
--- a/drivers/ide/pci/cs5535.c
+++ b/drivers/ide/pci/cs5535.c
@@ -2,6 +2,7 @@
* linux/drivers/ide/pci/cs5535.c
*
* Copyright (C) 2004-2005 Advanced Micro Devices, Inc.
+ * Copyright (C) 2007 Bartlomiej Zolnierkiewicz
*
* History:
* 09/20/2005 - Jaya Kumar <[EMAIL PROTECTED]>
@@ -83,14 +84,17 @@ static void cs5535_set_speed(ide_drive_t *drive, u8 speed)
/* Set the PIO timings */
if
Re: ST340823A disk size issue
> Could you try attached patch? > > [PATCH] ide-disk: workaround for buggy HPA support on ST340823A Title is wrong. The disc is performing correctly but if you dump the request you should see a 1024 byte request for the last odd sector number and the drive response is likewise correct. Thus NAK the change Fix ide-disk to issue requests for the last sector correctly instead (or at least complete them properly) - 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: ST340823A disk size issue
On Wednesday 01 August 2007, Mikko Rapeli wrote:
> On Wed, Aug 01, 2007 at 10:34:03PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > Could you try attached patch?
> >
> > [PATCH] ide-disk: workaround for buggy HPA support on ST340823A
>
> Umh, it's getting late but some makefile magic maybe missing, or I
> should do a clean build?
[...]
> ERROR: "ide_in_drive_list" [drivers/ide/ide-disk.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [drivers/ide/ide-disk.ko] Error 2
There is "EXPORT_SYMBOL(ide_in_drive_list);" missing from ide-dma.c.
I overlooked it since here ide-disk is built-in, sorry for that.
> Based on Alan's comments I'm already running 2.6.22.1 with this:
Ah, I see it now.
> diff -ru linux-2.6.22.1/drivers/ide/ide-disk.c
> linux-2.6.22.1.new/drivers/ide/ide-disk.c
> --- linux-2.6.22.1/drivers/ide/ide-disk.c 2007-07-10 21:56:30.0
> +0300
> +++ linux-2.6.22.1.new/drivers/ide/ide-disk.c 2007-08-01 22:59:47.0
> +0300
> @@ -502,6 +502,17 @@
>capacity, sectors_to_MB(capacity),
>set_max, sectors_to_MB(set_max));
>
> + if ((set_max % 2) && (set_max == capacity + 1)) {
> + printk(KERN_INFO "Old drive detected, keeping current
> capacity.\n");
Please either remove this printk() or change it to:
"Buggy HPA implementation, keeping current capacity."
The disk is not odd sized since the command to read the last sectors fail
with "SectorIdNotFound". This is a buggy HPA implementation as explained in
the description of my patch.
BTW libata wouldn't help since HPA code is almost a direct copy of the code
from ide-disk (I did the comparision before writing my patch)
> + return;
> + }
> +
> if (lba48)
> set_max = idedisk_set_max_address_ext(drive, set_max);
> else
Otherwise this patch looks fine and is a bit simpler than my patch.
If you fix the printk, add patch description (can use the one from my patch)
and add "Signed-off-by:" I would happily apply it and dump mine version.
Thanks,
Bart
-
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: ST340823A disk size issue
> If you fix the printk, add patch description (can use the one from my patch) > and add "Signed-off-by:" I would happily apply it and dump mine version. Sorry but the patch is wrong - plain and simple. It works over the bug but its not the real problem. ide-disk needs to spot a 1K request for the last 512 bytes, issue a 512 byte request and complete the 512 bytes only. Alan - 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: hpt374 sata (Highpoint Rocket 1540)
> > hpt37x: Bus clock 66 MHz, using DPLL. > > Oh?! hpt366.c detected 33 MHz... :-O Interesting as it should be using the same algorithm as hpt366 now. > > ACPI: PCI Interrupt :00:0d.0[A] -> GSI 16 (level, low) -> IRQ 17 > > scsi2: pata_hpt37x > > scsi3: pata_hpt37x > > ata3: PATA max UDMA/100 cmd 0x0001efa0 ctl 0x0001ef9e bmdma 0x0001ec00 irq > > 17 > > ata4: PATA max UDMA/100 cmd 0x0001ef90 ctl 0x0001ef9a bmdma 0x0001ec00 irq > > 17 > and it also knows about the bridge knobbling stuff. Most curious - 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: hpt374 sata (Highpoint Rocket 1540)
> Too bad, this is the standard HPT subsystem ID of 0x0001... So, nothing > comes to my mind other than add a module parameter to hpt366.c to specify > that > we're using the crippled SATA bridge... well, maybe it would also make sense > to scan the BIOS for the signatures... Since you don't do a reset is it not sufficient to check word93 on the initial identify scan in PIO. Or if you do a reset the signature. - 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: ST340823A disk size issue
On Thursday 02 August 2007, Alan Cox wrote:
> > If you fix the printk, add patch description (can use the one from my patch)
> > and add "Signed-off-by:" I would happily apply it and dump mine version.
>
> Sorry but the patch is wrong - plain and simple. It works over the bug
> but its not the real problem. ide-disk needs to spot a 1K request for the
> last 512 bytes, issue a 512 byte request and complete the 512 bytes only.
block/ll_rw_blk.c:
static inline void __generic_make_request(struct bio *bio)
{
...
int ret, nr_sectors = bio_sectors(bio);
...
/* Test device or partition size, when known. */
maxsector = bio->bi_bdev->bd_inode->i_size >> 9;
if (maxsector) {
sector_t sector = bio->bi_sector;
if (maxsector < nr_sectors || maxsector - nr_sectors < sector) {
/*
* This may well happen - the kernel calls bread()
* without checking the size of the device, e.g., when
* mounting a device.
*/
handle_bad_sector(bio);
goto end_io;
so low-level-driver should never see such requests.
Additionally fs/partitions/check.c:rescan_partitions() should warn if the
partition exceeds device size and we are not seeing any such warning.
Mikko, could you please revert any patches that you have applied, uncomment
#define DEBUG in ide-disk.c, recompile and note the sectors count in the
"hdd: reading: block=78165360 sectors=..."
debug message?
Thanks,
Bart
-
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: ST340823A disk size issue
On Thursday 02 August 2007, Bartlomiej Zolnierkiewicz wrote: > Otherwise this patch looks fine and is a bit simpler than my patch. > > If you fix the printk, add patch description (can use the one from my patch) > and add "Signed-off-by:" I would happily apply it and dump mine version. On the second thought - there may be real devices which have +1 native capacity so we are better off with sticking to the version with extra drive model check (this is of course given that the approach is right - yet to be verified). Thanks, Bart - 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 3/4] Enable link power management for ata drivers
Kristen Carlson Accardi wrote: > On Wed, 01 Aug 2007 17:27:39 +0900 > Tejun Heo <[EMAIL PROTECTED]> wrote: > >> Kristen Carlson Accardi wrote: > >> Is it safe to use ALPM on a device which only claims to support DIPM? > > Yes - I doubled checked this with the AHCI people - and of course you > have Edvin's testing to prove it does fine. Alright. > As far as moving the enable/disable_pm calls to EH - can you take > a look at the other patch I sent which implements the shost_attrs > to see if I still need to do this? I really don't know much about > the EH stuff - can you explain why we need to use it to set the > link pm? Unfortunately, yes, you still need to. Only two threads of execution (one is not a real thread tho) are allowed to access a libata port - command execution and EH, and the two are mutually exclusive. Invoking something from the outside is done by doing the following. 1. recording what to do in ehi->[dev_]action, ap->pflags or dev->flags 2. schedule EH by calling either ata_port_schedule_eh(), ata_port_abort() or ata_port_freeze(). The first one waits for the currently in-flight commands to finish before entering EH. The second one aborts all in-flight commands and enters EH. The third one aborts all commands and freezes the port and enters EH. 3. wait for EH to finish by calling ata_port_wait_eh(). This achieves correct synchronization and other EH functionalities can be easily used. e.g. Resuming requires resetting the bus and revalidating the attached devices, so the resume handler can just request such actions together. For link PS, I think it would probably be a good idea to revalidate after mode change to make sure the device works in the new mode. If revalidation fails, it can reset and back off. EH is done in three large steps - autopsy, report and recover. To implement an action, the 'recover' stage needs to be extended. It basically comes down to hooking the enable/disable functions into the right places in ata_eh_recover(). Unconditionally disabling link PS prior to reset and enabling it back again before revalidation would be a pretty good choice, but haven't thought about it too hard so take it with a grain of salt. I'm not sure whether it would be necessary now but it would be nice to have a proper recovery logic later. e.g. If more than certain number of ATA bus occurs in certain mount of time, disable link PS. This kind of logic is used during autopsy to determine whether stepping down link/transfer speed is needed. Please take a look at ata_eh_speed_down(). It might be enough to piggy back on ata_eh_speed_down() tho such that the first step of speeding down is turning off link PS. Hope the brief introduction to libata-EH-hacking helps. -- tejun - 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
[PATCH] hook ACPI _PSx method to IDE power on/off
ACPI spec defines the sequence of IDE power on/off:
Powering down:
Call _GTM.
Power down drive (calls _PS3 method and turns off power planes).
Powering up:
Power up drive (calls _PS0 method if present and turns on power planes).
Call _STM passing info from _GTM (possibly modified), with ID data from
each drive.
Initialize the channel.
May modify the results of _GTF.
For each drive:
Call _GTF.
Execute task file (possibly modified).
This patch adds the missed _PS0/_PS3 methods call.
Signed-off-by: Shaohua Li <[EMAIL PROTECTED]>
Index: linux/drivers/ide/ide-acpi.c
===
--- linux.orig/drivers/ide/ide-acpi.c 2007-08-02 13:34:43.0 +0800
+++ linux/drivers/ide/ide-acpi.c2007-08-02 13:51:21.0 +0800
@@ -612,6 +612,46 @@ void ide_acpi_push_timing(ide_hwif_t *hw
EXPORT_SYMBOL_GPL(ide_acpi_push_timing);
/**
+ * ide_acpi_set_state - set the channel power state
+ * @hwif: target IDE interface
+ * @on: state, on/off
+ *
+ * This function executes the _PS0/_PS3 ACPI method to set the power state.
+ * ACPI spec requires _PS0 when IDE power on and _PS3 when power off
+ */
+void ide_acpi_set_state(ide_hwif_t *hwif, int on)
+{
+ int unit;
+
+ if (ide_noacpi)
+ return;
+
+ DEBPRINT("ENTER:\n");
+
+ if (!hwif->acpidata) {
+ DEBPRINT("no ACPI data for %s\n", hwif->name);
+ return;
+ }
+ /* channel first and then drives for power on and verse versa for power
off */
+ if (on)
+ acpi_bus_set_power(hwif->acpidata->obj_handle, ACPI_STATE_D0);
+ for (unit = 0; unit < MAX_DRIVES; ++unit) {
+ ide_drive_t *drive = &hwif->drives[unit];
+
+ if (!drive->acpidata->obj_handle)
+ drive->acpidata->obj_handle =
ide_acpi_drive_get_handle(drive);
+
+ if (drive->acpidata->obj_handle && drive->present) {
+ acpi_bus_set_power(drive->acpidata->obj_handle,
+ on? ACPI_STATE_D0: ACPI_STATE_D3);
+ }
+ }
+ if (!on)
+ acpi_bus_set_power(hwif->acpidata->obj_handle, ACPI_STATE_D3);
+}
+EXPORT_SYMBOL_GPL(ide_acpi_set_state);
+
+/**
* ide_acpi_init - initialize the ACPI link for an IDE interface
* @hwif: target IDE interface (channel)
*
@@ -679,6 +719,8 @@ void ide_acpi_init(ide_hwif_t *hwif)
return;
}
+ /* ACPI _PS0 before _STM */
+ ide_acpi_set_state(hwif, 1);
/*
* ACPI requires us to call _STM on startup
*/
Index: linux/drivers/ide/ide.c
===
--- linux.orig/drivers/ide/ide.c2007-08-02 13:34:43.0 +0800
+++ linux/drivers/ide/ide.c 2007-08-02 13:35:28.0 +0800
@@ -914,6 +914,7 @@ static int generic_ide_suspend(struct de
struct request rq;
struct request_pm_state rqpm;
ide_task_t args;
+ int ret;
/* Call ACPI _GTM only once */
if (!(drive->dn % 2))
@@ -930,7 +931,14 @@ static int generic_ide_suspend(struct de
mesg.event = PM_EVENT_FREEZE;
rqpm.pm_state = mesg.event;
- return ide_do_drive_cmd(drive, &rq, ide_wait);
+ ret = ide_do_drive_cmd(drive, &rq, ide_wait);
+ /* only call ACPI _PS3 after both drivers are suspended */
+ if (!ret && (((drive->dn % 2) && hwif->drives[0].present
+&& hwif->drives[1].present)
+|| !hwif->drives[0].present
+|| !hwif->drives[1].present))
+ ide_acpi_set_state(hwif, 0);
+ return ret;
}
static int generic_ide_resume(struct device *dev)
@@ -943,8 +951,10 @@ static int generic_ide_resume(struct dev
int err;
/* Call ACPI _STM only once */
- if (!(drive->dn % 2))
+ if (!(drive->dn % 2)) {
+ ide_acpi_set_state(hwif, 1);
ide_acpi_push_timing(hwif);
+ }
ide_acpi_exec_tfs(drive);
Index: linux/include/linux/ide.h
===
--- linux.orig/include/linux/ide.h 2007-08-02 13:34:43.0 +0800
+++ linux/include/linux/ide.h 2007-08-02 13:35:28.0 +0800
@@ -1337,11 +1337,13 @@ extern int ide_acpi_exec_tfs(ide_drive_t
extern void ide_acpi_get_timing(ide_hwif_t *hwif);
extern void ide_acpi_push_timing(ide_hwif_t *hwif);
extern void ide_acpi_init(ide_hwif_t *hwif);
+extern void ide_acpi_set_state(ide_hwif_t *hwif, int on);
#else
static inline int ide_acpi_exec_tfs(ide_drive_t *drive) { return 0; }
static inline void ide_acpi_get_timing(ide_hwif_t *hwif) { ; }
static inline void ide_acpi_push_timing(ide_hwif_t *hwif) { ; }
static inline void ide_acpi_init(ide_hwif_t *hwif) { ; }
+static inline void ide_acpi_set_state(ide_hwif_t *h
[PATCH] Add a PCI ID for santa rosa's PATA controller.
From: Christian Lamparter <[EMAIL PROTECTED]>
Signed-off-by: Christian Lamparter <[EMAIL PROTECTED]>
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
---
This is commit c1e6f28cc5de37dcd113b9668a185c0b9334ba8a which is
merged during 23-rc1 window. Considering the popularity of these
chips, I think including it in -stable release would be good idea.
Thanks.
drivers/ata/ata_piix.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 924e447..76cbdf0 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -200,6 +200,8 @@ static const struct pci_device_id piix_pci_tbl[] = {
/* ICH7/7-R (i945, i975) UDMA 100*/
{ 0x8086, 0x27DF, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_133 },
{ 0x8086, 0x269E, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_100 },
+ /* ICH8 Mobile PATA Controller */
+ { 0x8086, 0x2850, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_100 },
/* NOTE: The following PCI ids must be kept in sync with the
* list in drivers/pci/quirks.c.
--
1.5.0.3
-
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
