Re: Disk spin down issue on shut down/suspend to disk
Henrique de Moraes Holschuh wrote: On Tue, 07 Aug 2007, Tejun Heo wrote: Michael Sedkowski wrote: Hmmm... If the problem only shows up on nx6325, it might be that ACPI is pulling unnecessary stunt. Please apply the attached patch and report when the disk spins down and up. Disk spins down on Pre-shutdown prepare and then goes up and down on Power down. Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether it spins down the disk correctly. Does emergency unload count increase after each power down? Also, please post the result of 'dmidecode'. You know, this actually make a lot of sense, and one can't even complain about firmware that pulls that off. Well, I'm complaining. I think the problem here is that it isn't clear which one is who's responsibility. There's a Korean saying which approximately translates into if you have too many boatmen on a ship, it goes to mountain. We also have a bunch of Toshiba laptops which want the ATA controller to be in enabled state when ACPI suspend is invoked because the suspend method apparently wants to execute some commands before going to sleep. I wish ACPI spec carries a big fat sign saying stay f*** away from anything which isn't essential to the requested operation. Any chances of changing things so that we inspect/snoop all tasks sent to the device, and filter them out, or react to them accordingly? No, we can't unless we snoop ACPI method execution and detect accesses to IO ports or iomem regions. It's not going through any driver. This is a gross mess. -- 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: Disk spin down issue on shut down/suspend to disk
Michael Sedkowski wrote: Dnia 07-08-2007, Wt o godzinie 03:43 +0900, Tejun Heo napisał(a): Does emergency unload count increase after each power down? I think I got it. Using smartctl I've done a test and shut down, then repeted the test. The only values that where diffrent are temperatures and Hardware_ECC_Recovered which rised by 6 points. However I have no idea which of those is the emergency count... Full results in attachment. 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age Always - 388 I think this is the one. You can test it by forcefully powering off the machine (press power button for several secs or disconnect AC and battery) and see whether the count increases. -- 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: [stable] [PATCH] ata_piix: update map 10b for ich8m
On Tue, Aug 07, 2007 at 02:43:27AM +0900, Tejun Heo wrote:
Fix map entry 10b for ich8. It's [P0 P2 IDE IDE] like ich6 / ich6m.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Cc: Kristen Carlson Accardi [EMAIL PROTECTED]
---
Many users can be hit by this. Please consider for -stable. Thanks.
drivers/ata/ata_piix.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index a78832e..c5b4509 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -436,7 +436,7 @@ static const struct piix_map_db ich8_map_db = {
/* PM PS SM SS MAP */
{ P0, P2, P1, P3 }, /* 00b (hardwired when in AHCI) */
{ RV, RV, RV, RV },
- { IDE, IDE, NA, NA }, /* 10b (IDE mode) */
+ { P0, P2, IDE, IDE }, /* 10b (IDE mode) */
{ RV, RV, RV, RV },
},
};
Did this ever make it into Linus's tree?
thanks,
greg k-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: [stable] [PATCH] ata_piix: update map 10b for ich8m
Greg KH wrote:
On Tue, Aug 07, 2007 at 02:43:27AM +0900, Tejun Heo wrote:
Fix map entry 10b for ich8. It's [P0 P2 IDE IDE] like ich6 / ich6m.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Cc: Kristen Carlson Accardi [EMAIL PROTECTED]
---
Many users can be hit by this. Please consider for -stable. Thanks.
drivers/ata/ata_piix.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index a78832e..c5b4509 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -436,7 +436,7 @@ static const struct piix_map_db ich8_map_db = {
/* PM PS SM SS MAP */
{ P0, P2, P1, P3 }, /* 00b (hardwired when in AHCI) */
{ RV, RV, RV, RV },
-{ IDE, IDE, NA, NA }, /* 10b (IDE mode) */
+{ P0, P2, IDE, IDE }, /* 10b (IDE mode) */
{ RV, RV, RV, RV },
},
};
Did this ever make it into Linus's tree?
Not yet. Hmmm... Should I have mailed -stable separately after Jeff's ACK?
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: [stable] [PATCH] ata_piix: update map 10b for ich8m
On Tue, Aug 07, 2007 at 05:09:08PM +0900, Tejun Heo wrote:
Greg KH wrote:
On Tue, Aug 07, 2007 at 02:43:27AM +0900, Tejun Heo wrote:
Fix map entry 10b for ich8. It's [P0 P2 IDE IDE] like ich6 / ich6m.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Cc: Kristen Carlson Accardi [EMAIL PROTECTED]
---
Many users can be hit by this. Please consider for -stable. Thanks.
drivers/ata/ata_piix.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index a78832e..c5b4509 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -436,7 +436,7 @@ static const struct piix_map_db ich8_map_db = {
/* PM PS SM SS MAP */
{ P0, P2, P1, P3 }, /* 00b (hardwired when in AHCI) */
{ RV, RV, RV, RV },
- { IDE, IDE, NA, NA }, /* 10b (IDE mode) */
+ { P0, P2, IDE, IDE }, /* 10b (IDE mode) */
{ RV, RV, RV, RV },
},
};
Did this ever make it into Linus's tree?
Not yet. Hmmm... Should I have mailed -stable separately after Jeff's ACK?
Yeah, that would be best, as we need to wait until the patches go into
Linus's tree before adding them to ours to make sure we don't get out of
sync.
thanks,
greg k-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 1/2] hpt366: fix PCI clock detection for HPT374
On Mon, 2007-08-06 at 21:18 +0400, Sergei Shtylyov wrote: Hm, well, this is indeed tough case but at least it prodded me to fix some issues. Maybe it's worth for you to file a bug at bugzilla.kernel.org... I've raised bug 8851: http://bugzilla.kernel.org/show_bug.cgi?id=8851 Bob - 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: Disk spin down issue on shut down/suspend to disk
Dnia 07-08-2007, Wt o godzinie 15:56 +0900, Tejun Heo napisał(a): 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age Always - 388 I think this is the one. You can test it by forcefully powering off the machine (press power button for several secs or disconnect AC and battery) and see whether the count increases. When I forcefully power off using the power button the raw value [last one] rise by 1 point from 389 to 390. When I power off normally with linux it remains constant. Now could some one please explain to me what does that mean and am I in danger of data loss? - 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/1] AVR32 PATA driver
Hi everybody, My PATA driver for AVR32 is now working in all PIO modes. I have tested the driver for two weeks and it seems pretty stable, there are no file corruption or fatal errors. This is a typical result by running Bonnie in PIO4 (file size 104857600): ---Sequential Output ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 100 1599 80.5 5305 20.4 2581 17.4 1385 78.0 5068 14.8 45.8 1.9 Yet there are still some issues: 1) In PIO1 and PIO2 there are rare freezes: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata3.00: cmd 20/00:00:d3:7e:5d/00:00:00:00:00/e1 tag 0 cdb 0x0 data 131072 in res 58/00:01:d2:7f:5d/00:00:01:00:00/e1 Emask 0x2 (HSM violation) The freezes happen close to each other in time. The freezes does not make file operations fail. 2) After being in operation for a long time (+24 hours) the disk reports wrong identity: ata4.00: model number mismatch 'IC35L060AVV207-0' != '' ata4.00: revalidation failed (errno=-19) ata4.00: limiting speed to PIO2 ata4: failed to recover some devices, retrying in 5 secs ata4.00: model number mismatch 'IC35L060AVV207-0' != 'AV07-0 *GARBEL* This has happend with both the devices I am testing, the 'Quantum Fireball' reported it self to be 'Quanpum Fiveball' after 24 hours of testing. I also have a question regrding INTRQ / IRQ handeling. Since I am not using DMA, there seems to be no reason to handle interrupts, so I set the polling flag. Not using the polling flag gives a lot of interrupts that does not seem to do anything except eating my CPU cycles. Is this correct? If so, what shall I do when activating the host to not get irq 65: nobody cared ... Disabling IRQ #65. Should I give an negative irq number? Any help and reviews of my code would be appriciate :) -- Kristoffer Nyborg Gregertsen MSc. student / Summer intern Atmel Norway - 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/1] AVR32 PATA driver
This patch adds support for PATA devices on the AVR32 using the CompactFlash
controller in 'True IDE mode'. DMA is currently not supported due to lack of
DMACK pins on the current AP7000 series.
Tested on AP7000 / STK1000.
Signed-off-by: Kristoffer Nyborg Gregertsen [EMAIL PROTECTED]
---
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 4ad8675..7de15e6 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -199,6 +199,15 @@ config PATA_ARTOP
If unsure, say N.
+config PATA_AT32
+ tristate Atmel AVR32 PATA support (Very Experimental)
+ depends on AVR32 PLATFORM_AT32AP EXPERIMENTAL
+ help
+ This option enables support for the IDE devices on the
+ Atmel AT32AP platform.
+
+ If unsure, say N.
+
config PATA_ATIIXP
tristate ATI PATA support (Experimental)
depends on PCI EXPERIMENTAL
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index 8149c68..7c5e319 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_PDC_ADMA)+= pdc_adma.o
obj-$(CONFIG_PATA_ALI) += pata_ali.o
obj-$(CONFIG_PATA_AMD) += pata_amd.o
obj-$(CONFIG_PATA_ARTOP) += pata_artop.o
+obj-$(CONFIG_PATA_AT32)+= pata_at32.o
obj-$(CONFIG_PATA_ATIIXP) += pata_atiixp.o
obj-$(CONFIG_PATA_CMD640_PCI) += pata_cmd640.o
obj-$(CONFIG_PATA_CMD64X) += pata_cmd64x.o
diff --git a/drivers/ata/pata_at32.c b/drivers/ata/pata_at32.c
new file mode 100644
index 000..3f57624
--- /dev/null
+++ b/drivers/ata/pata_at32.c
@@ -0,0 +1,569 @@
+/*
+ * AVR32 SMC/CFC PATA Driver
+ *
+ * Copyright (C) 2007 Atmel Norway
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ */
+#define DEBUG
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/device.h
+#include linux/platform_device.h
+#include linux/delay.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include scsi/scsi_host.h
+#include linux/ata.h
+#include linux/libata.h
+#include linux/err.h
+#include linux/io.h
+
+#include asm/gpio.h
+#include asm/arch/board.h
+#include asm/arch/smc.h
+
+#define DRV_NAME pata_at32
+#define DRV_VERSION 0.0.2
+
+/*
+ * CompactFlash controller memory layout relative to the base address:
+ *
+ * Attribute memory: - 003f
+ * Common memory: 0040 - 007f
+ * I/O memory:0080 - 00bf
+ * True IDE Mode: 00c0 - 00df
+ * Alt IDE Mode: 00e0 - 00ff
+ *
+ * Only True IDE and Alt True IDE mode are needed for this driver.
+ *
+ * True IDE mode = CS0 = 0, CS1 = 1 (cmd, error, stat, etc)
+ * Alt True IDE mode = CS0 = 1, CS1 = 0 (ctl, alt_stat)
+ */
+#define CF_IDE_OFFSET0x00c0
+#define CF_ALT_IDE_OFFSET 0x00e0
+#define CF_RES_SIZE 2048
+
+/*
+ * Define DEBUG_BUS if you are doing debugging of your own EBI - PATA
+ * adaptor with a logic analyzer or similar.
+ */
+#undef DEBUG_BUS
+
+/*
+ * ATA PIO modes
+ *
+ * Name| Mb/s | Min cycle time | Mask
+ * +---++
+ * Mode 0 | 3.3 | 600 ns | 0x01
+ * Mode 1 | 5.2 | 383 ns | 0x03
+ * Mode 2 | 8.3 | 240 ns | 0x07
+ * Mode 3 | 11.1 | 180 ns | 0x0f
+ * Mode 4 | 16.7 | 120 ns | 0x1f
+ *
+ * This parameter allows users to set max PIO mode.
+ */
+static int max_pio = 4;
+module_param(max_pio, int, 0444);
+MODULE_PARM_DESC(max_pio, Max PIO mode, range 0..4, default 4);
+
+/*
+ * Return PIO mask as given by parameter max_pio.
+ */
+static int pata_at32_get_pio_mask(void)
+{
+ switch (max_pio) {
+ case 0:
+ return 0x01;
+ case 1:
+ return 0x03;
+ case 2:
+ return 0x07;
+ case 3:
+ return 0x0f;
+ case 4:
+ return 0x1f;
+ default:
+ return 0x01;
+ }
+}
+
+/*
+ * Struct containing private information about device.
+ */
+struct at32_ide_info {
+ unsigned intirq;
+ struct resource res_ide;
+ struct resource res_alt;
+ void __iomem*ide_addr;
+ void __iomem*alt_addr;
+ unsigned intcs;
+ struct smc_config smc_8;
+ struct smc_config smc_16;
+ int smc_pio_mode;
+};
+
+/*
+ * Computes SMC timing for the given ATA timing and bus width.
+ */
+static void pata_at32_compute_smc_timing(struct device *dev,
+struct smc_config *smc,
+const struct ata_timing *timing,
+int bus_width)
+{
+ /* These two values are found through testing */
+ const int min_recover =
Re: Disk spin down issue on shut down/suspend to disk
Dnia 07-08-2007, Wt o godzinie 15:56 +0900, Tejun Heo napisał(a): You can test it by forcefully powering off the machine (press power button for several secs or disconnect AC and battery) and see whether the count increases. Forgot to mention that double spin down does not happen when the laptop is powered down forcefully and as my friend described who has te same model it sounds right... - 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: Disk spin down issue on shut down/suspend to disk
Michael Sedkowski wrote: Dnia 07-08-2007, Wt o godzinie 15:56 +0900, Tejun Heo napisał(a): 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age Always - 388 I think this is the one. You can test it by forcefully powering off the machine (press power button for several secs or disconnect AC and battery) and see whether the count increases. When I forcefully power off using the power button the raw value [last one] rise by 1 point from 389 to 390. When I power off normally with linux it remains constant. Now could some one please explain to me what does that mean and am I in danger of data loss? So, the ACPI routine puts the disk into the standby mode before powering off. That's good. On power off, the r/w heads in a disk should be unloaded (parked). This is usually achieved by either putting the disk into standby/sleep mode during shutdown. However, all modern disks can automatically unload their heads when the power is removed abruptly. This is called emergency unload. Emergency unload does shorten the lifespan of the disk but you don't have to worry too much about it. Disks are designed to withstand certain number of emergency unloads. -- 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 11/11] ide: remove -ide_dma_check
On Monday 06 August 2007, Sergei Shtylyov wrote:
Bartlomiej Zolnierkiewicz wrote:
Index: b/drivers/ide/arm/icside.c
===
--- a/drivers/ide/arm/icside.c
+++ b/drivers/ide/arm/icside.c
@@ -309,14 +309,6 @@ static int icside_dma_on(ide_drive_t *dr
return 0;
}
-static int icside_dma_check(ide_drive_t *drive)
-{
- if (ide_tune_dma(drive))
- return 0;
-
- return -1;
-}
-
static int icside_dma_end(ide_drive_t *drive)
{
ide_hwif_t *hwif = HWIF(drive);
Hm, looks like there's going to be some functionality change for this
driver -- it didn't fallback to PIO before this patch... ;-)
It won't because this driver lacks -set_pio_mode method... :-)
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
答复: Disk spin down issue on s hut down/suspend to disk
Tejun Heo wrote: Michael Sedkowski wrote: Dnia 07-08-2007, Wt o godzinie 15:56 +0900, Tejun Heo napisał(a): 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age Always - 388 [snip] On power off, the r/w heads in a disk should be unloaded (parked). This is usually achieved by either putting the disk into standby/sleep mode during shutdown. However, all modern disks can automatically unload their heads when the power is removed abruptly. This is called emergency unload. Emergency unload does shorten the lifespan of the disk but you don't have to worry too much about it. Disks are designed to withstand certain number of emergency unloads. Out of interest, does Power-Off_Retract_Count attribute only record emergency unloads rather than normal power off by Linux shutdown command? Thanks in advance, Sam - 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: Disk spin down issue on shut down/suspend to disk
On Tue, 07 Aug 2007, Tejun Heo wrote: Henrique de Moraes Holschuh wrote: On Tue, 07 Aug 2007, Tejun Heo wrote: Michael Sedkowski wrote: Hmmm... If the problem only shows up on nx6325, it might be that ACPI is pulling unnecessary stunt. Please apply the attached patch and report when the disk spins down and up. Disk spins down on Pre-shutdown prepare and then goes up and down on Power down. Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether it spins down the disk correctly. Does emergency unload count increase after each power down? Also, please post the result of 'dmidecode'. You know, this actually make a lot of sense, and one can't even complain about firmware that pulls that off. Well, I'm complaining. I think the problem here is that it isn't clear which one is who's responsibility. There's a Korean saying which The BIOS *has* to do it when in DOS mode, the HD manuals are very very clear about it. Doing it through ACPI ATA objects is at least non-broken as far as these things go, as one knows when to do it directly (non-ACPI mode), and one doesn't talk to the disk directly. approximately translates into if you have too many boatmen on a ship, it goes to mountain. We also have a bunch of Toshiba laptops which Yeah, that's a problem. But we can avoid it if we start snooping what ACPI is asking us to deliver to the disks, which IMO is an extremely good idea anyway. want the ATA controller to be in enabled state when ACPI suspend is invoked because the suspend method apparently wants to execute some commands before going to sleep. That's just broken, since it is not even using a OS-backed SATA/ATA ACPI method to do it. I wish ACPI spec carries a big fat sign saying stay f*** away from anything which isn't essential to the requested operation. Shutting down disks *is* essential to the power off operation. ACPI would have to mandate who is to do it, instead (ACPI table or OSI by itself). Any chances of changing things so that we inspect/snoop all tasks sent to the device, and filter them out, or react to them accordingly? No, we can't unless we snoop ACPI method execution and detect accesses to IO ports or iomem regions. It's not going through any driver. This is a gross mess. I don't mean fixing the stuff clowns like Toshiba did. The correct fix for that is to blacklist the hell out of that crap and patch their DSDT into something remotely sane. I do mean snooping the ACPI methods that *return* a taskset to send to the driver, and we send that taskset ourselves in libata and libpata(?). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - 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: Disk spin down issue on shut down/suspend to disk
On Tue, 07 Aug 2007, Tejun Heo wrote: emergency unload. Emergency unload does shorten the lifespan of the disk but you don't have to worry too much about it. Disks are designed to withstand certain number of emergency unloads. You *do* have to worry about it in any box you turn off daily. Desktop HDs will croak fast in that scenario, laptop HDs less so, but still too fast. A very good laptop HD can last about 20k emergency unloads (this is a unit that can do about 600k normal unloads in its lifetime). Desktop and server HDs don't even come close to those numbers, last time I checked. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - 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: Disk spin down issue on shut down/suspend to disk
On Tue, 2007-08-07 at 09:51 -0300, Henrique de Moraes Holschuh wrote: On Tue, 07 Aug 2007, Tejun Heo wrote: Henrique de Moraes Holschuh wrote: On Tue, 07 Aug 2007, Tejun Heo wrote: Michael Sedkowski wrote: ---snip--- Any chances of changing things so that we inspect/snoop all tasks sent to the device, and filter them out, or react to them accordingly? No, we can't unless we snoop ACPI method execution and detect accesses to IO ports or iomem regions. It's not going through any driver. This is a gross mess. I don't mean fixing the stuff clowns like Toshiba did. The correct fix for that is to blacklist the hell out of that crap and patch their DSDT into something remotely sane. I do mean snooping the ACPI methods that *return* a taskset to send to the driver, and we send that taskset ourselves in libata and libpata(?). I haven't read the whole thread in every detail, but this sounds like a very intrusive, overdosed workaround. Are the DSDT/SSDTs already lying around somewhere (collecting them in a bug assigned to ACPI component should be a good idea)? Could someone give me a pointer where this happens (best in code and DSDT). Thanks, Thomas - 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: Disk spin down issue on shut down/suspend to disk
Hello, Henrique. Henrique de Moraes Holschuh wrote: approximately translates into if you have too many boatmen on a ship, it goes to mountain. We also have a bunch of Toshiba laptops which Yeah, that's a problem. But we can avoid it if we start snooping what ACPI is asking us to deliver to the disks, which IMO is an extremely good idea anyway. If it were done that way (by asking OS driver to deliver commands TFs), I wouldn't have any problem at all. The spin down command is issued from deep down in the acpi power off method - entering S5 directly issues ATA commands bypassing the whole OS except for the ACPI interpreter. It's just like the toshiba suspend crap and there's no standard way to tell whether the acpi power off method is gonna do it or not. We'll just have to blacklist it. 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: Disk spin down issue on shut down/suspend to disk
On Tue, 07 Aug 2007, Tejun Heo wrote: Henrique de Moraes Holschuh wrote: approximately translates into if you have too many boatmen on a ship, it goes to mountain. We also have a bunch of Toshiba laptops which Yeah, that's a problem. But we can avoid it if we start snooping what ACPI is asking us to deliver to the disks, which IMO is an extremely good idea anyway. If it were done that way (by asking OS driver to deliver commands TFs), I wouldn't have any problem at all. The spin down command is issued from deep down in the acpi power off method - entering S5 directly issues ATA commands bypassing the whole OS except for the ACPI interpreter. It's just like the toshiba suspend crap and there's no standard way to tell whether the acpi power off method is gonna do it or not. We'll just have to blacklist it. Urk. I see. I'd also suggest adding a FAIL to the Linux firmware toolkit to any DSDT doing this. Who should we prod to add that check? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - 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: Disk spin down issue on shut down/suspend to disk
Henrique de Moraes Holschuh wrote: On Tue, 07 Aug 2007, Tejun Heo wrote: Henrique de Moraes Holschuh wrote: approximately translates into if you have too many boatmen on a ship, it goes to mountain. We also have a bunch of Toshiba laptops which Yeah, that's a problem. But we can avoid it if we start snooping what ACPI is asking us to deliver to the disks, which IMO is an extremely good idea anyway. If it were done that way (by asking OS driver to deliver commands TFs), I wouldn't have any problem at all. The spin down command is issued from deep down in the acpi power off method - entering S5 directly issues ATA commands bypassing the whole OS except for the ACPI interpreter. It's just like the toshiba suspend crap and there's no standard way to tell whether the acpi power off method is gonna do it or not. We'll just have to blacklist it. Urk. I see. I'd also suggest adding a FAIL to the Linux firmware toolkit to any DSDT doing this. Who should we prod to add that check? Dunno how the firmware toolkit works but this one can be pretty difficult to test (if it were easy, we could test it in libata) as it involves entering S5. If it's possible, I'm all for it. Also, it would be nice if we can test the same thing for S3 and S4. Thomas, who should we ask things about the Linux firmware toolkit? 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: Disk spin down issue on shut down/suspend to disk
Thomas Renninger wrote: Any chances of changing things so that we inspect/snoop all tasks sent to the device, and filter them out, or react to them accordingly? No, we can't unless we snoop ACPI method execution and detect accesses to IO ports or iomem regions. It's not going through any driver. This is a gross mess. I don't mean fixing the stuff clowns like Toshiba did. The correct fix for that is to blacklist the hell out of that crap and patch their DSDT into something remotely sane. I do mean snooping the ACPI methods that *return* a taskset to send to the driver, and we send that taskset ourselves in libata and libpata(?). I haven't read the whole thread in every detail, but this sounds like a very intrusive, overdosed workaround. Are the DSDT/SSDTs already lying around somewhere (collecting them in a bug assigned to ACPI component should be a good idea)? Could someone give me a pointer where this happens (best in code and DSDT). The toshiba problem is already taken care of. It's the issue that we talked over beer. Let me look up the bug number... It's 7780. http://bugzilla.kernel.org/show_bug.cgi?id=7780 This was worked around by blacklisting the systems using dmi. 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: Disk spin down issue on shut down/suspend to disk
On Tue, 2007-08-07 at 22:32 +0900, Tejun Heo wrote: Henrique de Moraes Holschuh wrote: On Tue, 07 Aug 2007, Tejun Heo wrote: Henrique de Moraes Holschuh wrote: approximately translates into if you have too many boatmen on a ship, it goes to mountain. We also have a bunch of Toshiba laptops which Yeah, that's a problem. But we can avoid it if we start snooping what ACPI is asking us to deliver to the disks, which IMO is an extremely good idea anyway. If it were done that way (by asking OS driver to deliver commands TFs), I wouldn't have any problem at all. The spin down command is issued from deep down in the acpi power off method - entering S5 directly issues ATA commands bypassing the whole OS except for the ACPI interpreter. It's just like the toshiba suspend crap and there's no standard way to tell whether the acpi power off method is gonna do it or not. We'll just have to blacklist it. Urk. I see. I'd also suggest adding a FAIL to the Linux firmware toolkit to any DSDT doing this. Who should we prod to add that check? Dunno how the firmware toolkit works but this one can be pretty difficult to test (if it were easy, we could test it in libata) as it involves entering S5. If it's possible, I'm all for it. Also, it would be nice if we can test the same thing for S3 and S4. Thomas, who should we ask things about the Linux firmware toolkit? Thanks. firmwarekit-discuss [EMAIL PROTECTED] (added to CC list) see: http://linuxfirmwarekit.org/ But if I understand this problem right, this won't be easy. The ACPI tables are just parsed with system (iasl ...) and syntactical errors/warnings are printed out. I also thought about a test, interpreting the DSDT and read out values of cpufreq tables and sanity check them. AFAIK the linuxfirmwarekit is not designed for that atm. You need to compile in most parts of the acpica code and parse and interpret DSDT/SSDT code yourself in the firmwarekit core or inside a plugin, then do a walk_namespace call or whatever to find the functions/parts you like to examine. This is a lot work and needs a proper design (providing an interface to plugins to let them easily check specific AML/ASL code). Thomas - 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: Disk spin down issue on shut down/suspend to disk
Thomas Renninger wrote: I'd also suggest adding a FAIL to the Linux firmware toolkit to any DSDT doing this. Who should we prod to add that check? Dunno how the firmware toolkit works but this one can be pretty difficult to test (if it were easy, we could test it in libata) as it involves entering S5. If it's possible, I'm all for it. Also, it would be nice if we can test the same thing for S3 and S4. Thomas, who should we ask things about the Linux firmware toolkit? Thanks. firmwarekit-discuss [EMAIL PROTECTED] (added to CC list) see: http://linuxfirmwarekit.org/ But if I understand this problem right, this won't be easy. The ACPI tables are just parsed with system (iasl ...) and syntactical errors/warnings are printed out. I also thought about a test, interpreting the DSDT and read out values of cpufreq tables and sanity check them. AFAIK the linuxfirmwarekit is not designed for that atm. You need to compile in most parts of the acpica code and parse and interpret DSDT/SSDT code yourself in the firmwarekit core or inside a plugin, then do a walk_namespace call or whatever to find the functions/parts you like to examine. This is a lot work and needs a proper design (providing an interface to plugins to let them easily check specific AML/ASL code). Furthermore, we don't really know what we're looking for. How can you tell a given write to an ioport is issuing STANDBYNOW to an ATA disk or trying to power the machine off? Adding to the fun, many modern ATA controller have more than one way to issue a command. Maybe we can match accesses inside regions specified by PCI BARs :-( -- 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: Disk spin down issue on shut down/suspend to disk
Tejun Heo wrote: Robert Hancock wrote: Tejun Heo wrote: Michael Sedkowski wrote: Hmmm... If the problem only shows up on nx6325, it might be that ACPI is pulling unnecessary stunt. Please apply the attached patch and report when the disk spins down and up. Disk spins down on Pre-shutdown prepare and then goes up and down on Power down. Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether it spins down the disk correctly. Does emergency unload count increase after each power down? Also, please post the result of 'dmidecode'. I know that my Compaq X1000-series laptop does do some kind of ACPI games with the disk on ACPI power off (I assume it is putting the disk in standby before power-off at least). It also does this if you boot into DOS, GRUB, etc. and then hit the power button. Could be if the disk is dumb enough to spin up for sync cache and standby when there is nothing to flush, and the kernel does its own standby, this could cause an extra spinup/down.. Yeah, that seems to be what's going on. I don't think we have any other choice than blacklisting those notebooks. This is a mess. How does the other OS cope with this? Quite possible that it gets a double spindown with these laptop/drive combinations as well. I don't think it's particularly harmful as long as there's no emergency unload.. I'm thinking about using DMI vendor/product match to detect the affected systems but I think it would be better to match the ACPI implementation directly. Is there a way to match specific ACPI implementation? Don't think it would be very easy, it's presumably being done off some SMI code triggered from the ACPI power off register or something, so I'm assuming it's nothing the kernel sees in its ACPI tables.. -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disk spin down issue on shut down/suspend to disk
Robert Hancock wrote: Tejun Heo wrote: Yeah, that seems to be what's going on. I don't think we have any other choice than blacklisting those notebooks. This is a mess. How does the other OS cope with this? Quite possible that it gets a double spindown with these laptop/drive combinations as well. I don't think it's particularly harmful as long as there's no emergency unload.. I heard that spinning a harddrive back up while the platter is still spinning from the previous spindown can have pretty bad affect on the harddisk. This is from a Samsung HDD service guy and I'm not sure how credible it is at all. 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: Disk spin down issue on shut down/suspend to disk
On Tue, 2007-08-07 at 15:41 +0900, Tejun Heo wrote: Robert Hancock wrote: Tejun Heo wrote: Michael Sedkowski wrote: Hmmm... If the problem only shows up on nx6325, it might be that ACPI is pulling unnecessary stunt. Please apply the attached patch and report when the disk spins down and up. Disk spins down on Pre-shutdown prepare and then goes up and down on Power down. Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether it spins down the disk correctly. Does emergency unload count increase after each power down? Also, please post the result of 'dmidecode'. I know that my Compaq X1000-series laptop does do some kind of ACPI games with the disk on ACPI power off (I assume it is putting the disk in standby before power-off at least). It also does this if you boot into DOS, GRUB, etc. and then hit the power button. Could be if the disk is dumb enough to spin up for sync cache and standby when there is nothing to flush, and the kernel does its own standby, this could cause an extra spinup/down.. Yeah, that seems to be what's going on. I don't think we have any other choice than blacklisting those notebooks. This is a mess. How does the other OS cope with this? I'm thinking about using DMI vendor/product match to detect the affected systems but I think it would be better to match the ACPI implementation directly. Is there a way to match specific ACPI implementation? I opened a new bug to collect dmi and acpidump outputs: http://bugzilla.kernel.org/show_bug.cgi?id=8855 Thought this is the easiest way to get this all a bit together. Would be great if you tell all affected people and let them attach dmidecode and acpidump output there... Thanks, Thomas - 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: implement BROKEN_HPA horkage and apply it to HDS724040KLSA80
Em Tue, 7 Aug 2007 14:42:50 +0900
Tejun Heo [EMAIL PROTECTED] escreveu:
| HDS724040KLSA80 reports that it supports HPA LBA48 but craps itself
| on READ_NATIVE_MAX_EXT. Implement BROKEN_HPA horkage and apply it to
| the drive. If the horkage is set, all HPA operations are skipped.
|
| While at it, make HPA test a bit more reliable by also checking
| ata_id_has_hpa().
Tejun, is the following patch ok for 2.6.22.1?
--- linux-2.6.22.orig/drivers/ata/libata-core.c
+++ linux-2.6.22/drivers/ata/libata-core.c
@@ -1939,7 +1939,8 @@ int ata_dev_configure(struct ata_device
dev-flags |= ATA_DFLAG_FLUSH_EXT;
}
- if (ata_id_hpa_enabled(dev-id))
+ if (!(dev-horkage ATA_HORKAGE_BROKEN_HPA)
+ ata_id_has_hpa(id) ata_id_hpa_enabled(dev-id))
dev-n_sectors = ata_hpa_resize(dev);
/* config NCQ */
@@ -3800,6 +3801,7 @@ static const struct ata_blacklist_entry
{ HTS541612J9SA00,SBDIC7JP, ATA_HORKAGE_NONCQ, },
{ Hitachi HTS541616J9SA00, SB4OC70P, ATA_HORKAGE_NONCQ, },
{ WDC WD740ADFD-00NLR1, NULL, ATA_HORKAGE_NONCQ, },
+ { HDS724040KLSA80,KFAOA20N, ATA_HORKAGE_BROKEN_HPA, },
/* Devices with NCQ limits */
--- linux-2.6.22.orig/include/linux/libata.h
+++ linux-2.6.22/include/linux/libata.h
@@ -298,6 +298,7 @@ enum {
ATA_HORKAGE_NODMA = (1 1), /* DMA problems */
ATA_HORKAGE_NONCQ = (1 2), /* Don't use NCQ */
ATA_HORKAGE_MAX_SEC_128 = (1 3), /* Limit max sects to 128 */
+ ATA_HORKAGE_BROKEN_HPA = (1 4), /* Broken HPA */
};
enum hsm_task_states {
--
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: [PATCH] libata: implement BROKEN_HPA horkage and apply it to HDS724040KLSA80
Luiz Fernando N. Capitulino wrote: Em Tue, 7 Aug 2007 14:42:50 +0900 Tejun Heo [EMAIL PROTECTED] escreveu: | HDS724040KLSA80 reports that it supports HPA LBA48 but craps itself | on READ_NATIVE_MAX_EXT. Implement BROKEN_HPA horkage and apply it to | the drive. If the horkage is set, all HPA operations are skipped. | | While at it, make HPA test a bit more reliable by also checking | ata_id_has_hpa(). Tejun, is the following patch ok for 2.6.22.1? Yeah, looks okay to me but -stable needs to wait for upstream merge. 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: [PATCH] libata: implement BROKEN_HPA horkage and apply it to HDS724040KLSA80
Em Wed, 08 Aug 2007 00:00:28 +0900 Tejun Heo [EMAIL PROTECTED] escreveu: | Luiz Fernando N. Capitulino wrote: | Em Tue, 7 Aug 2007 14:42:50 +0900 | Tejun Heo [EMAIL PROTECTED] escreveu: | | | HDS724040KLSA80 reports that it supports HPA LBA48 but craps itself | | on READ_NATIVE_MAX_EXT. Implement BROKEN_HPA horkage and apply it to | | the drive. If the horkage is set, all HPA operations are skipped. | | | | While at it, make HPA test a bit more reliable by also checking | | ata_id_has_hpa(). | | Tejun, is the following patch ok for 2.6.22.1? | | Yeah, looks okay to me but -stable needs to wait for upstream merge. Okay, I'll that version in Mandriva. Thanks a lot, Tejun. -- 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: [PATCH] libata: implement BROKEN_HPA horkage and apply it to HDS724040KLSA80
On Tue, 7 Aug 2007 14:42:50 +0900 Tejun Heo [EMAIL PROTECTED] wrote: HDS724040KLSA80 reports that it supports HPA LBA48 but craps itself on READ_NATIVE_MAX_EXT. Implement BROKEN_HPA horkage and apply it to the drive. If the horkage is set, all HPA operations are skipped. I'd rather know what is going on here. A drive can legitimately support LBA48 and HPA and refuse READ_NATIVE_MAX_EXT. In addition just about every OS I know queries the HPA which means that something other than HPA support being broken is probably at the root. We thus want to find the real fix. What do the actual traces look like ? Does it crap out of it gets READ_NATIVE_MAX ? While at it, make HPA test a bit more reliable by also checking ata_id_has_hpa(). - if (ata_id_hpa_enabled(dev-id)) + if (!(dev-horkage ATA_HORKAGE_BROKEN_HPA) + ata_id_has_hpa(id) ata_id_hpa_enabled(dev-id)) dev-n_sectors = ata_hpa_resize(dev); A drive cannot set hpa_enabled without setting has_hpa so this does nothing and I've never seen a drive d what you try to cover here. I'd like to see actual evidence. - 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: implement BROKEN_HPA horkage and apply it to HDS724040KLSA80
Alan Cox wrote: On Tue, 7 Aug 2007 14:42:50 +0900 Tejun Heo [EMAIL PROTECTED] wrote: HDS724040KLSA80 reports that it supports HPA LBA48 but craps itself on READ_NATIVE_MAX_EXT. Implement BROKEN_HPA horkage and apply it to the drive. If the horkage is set, all HPA operations are skipped. I'd rather know what is going on here. A drive can legitimately support LBA48 and HPA and refuse READ_NATIVE_MAX_EXT. READ_NATIVE_MAX_EXT is mandatory if HPA LBA48, no? In addition just about every OS I know queries the HPA which means that something other than HPA support being broken is probably at the root. We thus want to find the real fix. What do the actual traces look like ? Does it crap out of it gets READ_NATIVE_MAX ? Haven't tried that but the problem is that the drive times out READ_NATIVE_MAX_EXT so it doesn't really matter whether the drive succeeds READ_NATIVE_MAX or not. For more detail, please read the following thread. http://thread.gmane.org/gmane.linux.ide/21322 While at it, make HPA test a bit more reliable by also checking ata_id_has_hpa(). -if (ata_id_hpa_enabled(dev-id)) +if (!(dev-horkage ATA_HORKAGE_BROKEN_HPA) +ata_id_has_hpa(id) ata_id_hpa_enabled(dev-id)) dev-n_sectors = ata_hpa_resize(dev); A drive cannot set hpa_enabled without setting has_hpa so this does nothing and I've never seen a drive d what you try to cover here. I'd like to see actual evidence. Well, it's what the ide driver does. BTW, according to the spec, we need to test bit 14 and 15 of word 87 before trusting any value the device reports in words 85-87 and 120, which libata currently doesn't do. Are we leaving this out intentionally (for broken devices) or just did we just miss it? 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
libata-core.c: ata_fill_sg() ... sanity check on arithmentic ?
Could someone more knowledgeable than me please reassure me ... Referring to code in linux-2.6.22.1: libata-core.c (kernel.org), in ata_fill_sg(): if sg_dma_address(sg) is 64k-aligned and sg_dma_len(sg) is 64k (0x1), then in the while loop, the if ((offset... test is false, since it tests for *greater than* 64k So then ap-prd[idx].flags_len gets set to (0x1 0x) = 0 ! So this sg element ends up with a zero length, even though the transfer size should be 64k. Is this correct behaviour, if not, should it be corrected ? Sorry if I'm just being paranoid ! Thanks, MikeW - 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: implement BROKEN_HPA horkage and apply it to HDS724040KLSA80
People should check out Ben C's HPA fixes and cleanups, too. (attached)
I was hoping one of the original libata HPA authors would review that in
depth and integrate. (it no longer applies cleanly)
Jeff
From: Ben Collins [EMAIL PROTECTED]
The original HPA patch that Kyle worked on has gone into current git
without some fixes that we worked through late in the Ubuntu feisty
release. Here's the main copy of the notes I sent to Alan a few weeks ago
in regards to the original patch, and a repatch against current git to fix
things up. Note we have released feisty with the patch attached (albeit we
have HPA enabled by default), and we have not had any reports directly
attributed to it. However, in gutsy (devel for next release, based on
current stock linux-2.6.git), we are already seeing reports of the same
issues we already fixed.
The issues we saw were mainly that some controllers didn't return the
correct size from the SET_MAX command (sata_nv is a good example). So I
added a re IDENTIFY after the SET_MAX, and compared all the numbers. If
re-id was correct, but return value from SET_MAX wasn't we print a warning
and use the IDENTIFY value regardless (since that's what the device is
going to use).
ata_hpa_resize() was changed to handle everything in a single call (checks
for HPA support of the device, and whether ignore_hpa is set or not), and
it also sets dev-n_sectors before returning.
So far with this patch, we were able to fix all the problems we were seeing
with it (except the sata_nv issue where we had to revert to not using adma
for NO_DATA transactions, already reported to libata-dev). We've not had
any reports of further problems.
Cc: Kyle McMartin [EMAIL PROTECTED]
Signed-off-by: Ben Collins [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/ata/libata-core.c | 140 +---
1 files changed, 100 insertions(+), 40 deletions(-)
diff -puN drivers/ata/libata-core.c~cleanup-libata-hpa-support
drivers/ata/libata-core.c
--- a/drivers/ata/libata-core.c~cleanup-libata-hpa-support
+++ a/drivers/ata/libata-core.c
@@ -819,16 +819,19 @@ void ata_id_c_string(const u16 *id, unsi
static u64 ata_tf_to_lba48(struct ata_taskfile *tf)
{
- u64 sectors = 0;
+ u64 sectors;
+ u32 high, low;
- sectors |= ((u64)(tf-hob_lbah 0xff)) 40;
- sectors |= ((u64)(tf-hob_lbam 0xff)) 32;
- sectors |= (tf-hob_lbal 0xff) 24;
- sectors |= (tf-lbah 0xff) 16;
- sectors |= (tf-lbam 0xff) 8;
- sectors |= (tf-lbal 0xff);
+ high = (tf-hob_lbah 16) |
+ (tf-hob_lbam 8) |
+ tf-hob_lbal;
+ low = (tf-lbah 16) |
+ (tf-lbam 8) |
+ tf-lbal;
- return ++sectors;
+ sectors = ((u64)high 24) | low;
+
+ return sectors + 1;
}
static u64 ata_tf_to_lba(struct ata_taskfile *tf)
@@ -970,52 +973,107 @@ static u64 ata_set_native_max_address(st
}
/**
+ * ata_hpa_get_native_size - Get the native size of a disk
+ * @dev: Device to get the size for
+ *
+ * Read the size of an LBA28 or LBA48 disk with HPA features and
+ * return the native size. Caller must check that the drive has HPA
+ * feature set enabled.
+ */
+static u64 ata_hpa_get_native_size(struct ata_device *dev)
+{
+ if (ata_id_has_lba48(dev-id))
+ return ata_read_native_max_address_ext(dev);
+ else
+ return ata_read_native_max_address(dev);
+}
+
+
+static u64 ata_hpa_set_native_size(struct ata_device *dev, u64 new_sectors)
+{
+ if (ata_id_has_lba48(dev-id))
+ return ata_set_native_max_address_ext(dev, new_sectors);
+ else
+ return ata_set_native_max_address(dev, new_sectors);
+}
+
+static unsigned long long sectors_to_MB(unsigned long long n)
+{
+ n = 9;/* make it bytes */
+ do_div(n, 100); /* make it MB */
+ return n;
+}
+
+static u64 ata_id_n_sectors(const u16 *id);
+
+/**
* ata_hpa_resize - Resize a device with an HPA set
* @dev: Device to resize
*
* Read the size of an LBA28 or LBA48 disk with HPA features and resize
- * it if required to the full size of the media. The caller must check
- * the drive has the HPA feature set enabled.
+ * it if required to the full size of the media.
*/
-static u64 ata_hpa_resize(struct ata_device *dev)
+static int ata_hpa_resize(struct ata_device *dev)
{
- u64 sectors = dev-n_sectors;
u64 hpa_sectors;
- if (ata_id_has_lba48(dev-id))
- hpa_sectors = ata_read_native_max_address_ext(dev);
- else
- hpa_sectors = ata_read_native_max_address(dev);
+ if (!ata_id_hpa_enabled(dev-id))
+ return 0;
+
+ hpa_sectors = ata_hpa_get_native_size(dev);
- /* if no hpa, both should be equal */
- ata_dev_printk(dev, KERN_INFO, %s 1: sectors =
Re: [PATCH 1/1] AVR32 PATA driver
+static int pata_at32_get_pio_mask(void)
+{
+ switch (max_pio) {
+ case 0:
+ return 0x01;
+ case 1:
+ return 0x03;
+ case 2:
+ return 0x07;
+ case 3:
+ return 0x0f;
+ case 4:
+ return 0x1f;
+ default:
+ return 0x01;
What is wrong with just using (1 max_pio) - 1 as the range is only
0-4 anyway.
+static void pata_at32_data_xfer(struct ata_device *adev, unsigned char *buf,
+ unsigned int buflen, int write_data)
+{
+ struct at32_ide_info *info = adev-ap-host-private_data;
+
+ /* Set SMC to data transfer speed */
+ if (info-smc_pio_mode 3)
+ smc_restore_registers(info-cs, info-smc_16.reg);
+
+ /* Transfer data */
+ ata_data_xfer(adev, buf, buflen, write_data);
+
+ /* Set SMC back to register transfer speed */
+ if (info-smc_pio_mode 3)
+ smc_restore_registers(info-cs, info-smc_8.reg);
Should be safe currently for IRQ driven behaviour, might be for polled but
remember that without locking you could end up reading the status before
you switch the clock back so I'm not 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 0/1] AVR32 PATA driver
1) In PIO1 and PIO2 there are rare freezes: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata3.00: cmd 20/00:00:d3:7e:5d/00:00:00:00:00/e1 tag 0 cdb 0x0 data 131072 in res 58/00:01:d2:7f:5d/00:00:01:00:00/e1 Emask 0x2 (HSM violation) The freezes happen close to each other in time. The freezes does not make file operations fail. Are you 100% sure all your timings are right and there are no I/O posting prolems that might lead the various required delays to come out wrong ? 2) After being in operation for a long time (+24 hours) the disk reports wrong identity: ata4.00: model number mismatch 'IC35L060AVV207-0' != '' ata4.00: revalidation failed (errno=-19) ata4.00: limiting speed to PIO2 ata4: failed to recover some devices, retrying in 5 secs ata4.00: model number mismatch 'IC35L060AVV207-0' != 'AV07-0 *GARBEL* This has happend with both the devices I am testing, the 'Quantum Fireball' reported it self to be 'Quanpum Fiveball' after 24 hours of testing. That sounds to me like your hardware - heat, clock drift ? I also have a question regrding INTRQ / IRQ handeling. Since I am not using DMA, there seems to be no reason to handle interrupts, so I set the polling flag. Not using the polling flag gives a lot of interrupts that does not seem to do anything except eating my CPU cycles. Is this correct? If so, what shall I do when activating the host to not get irq 65: nobody cared ... Disabling IRQ #65. Should I give an negative irq number? When you get an IRQ you need to clear the IRQ status. Good question why you are getting them but you may well do in the resetting phases even with nIEN in use. OTOH if you get one or two per command then someone must have nIEN wrong on command issue. Either way you need to clear down IRQs that occur - some hardware doesn't get nIEN right and interrupts anyway in some cases. - 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 RE-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_passthru16 and invert
its meaning 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]
---
Alright, the winner is atapi_passthru16.
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 60e78be..0ccac23 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_passthru16 = 1;
+module_param(atapi_passthru16, int, 0444);
+MODULE_PARM_DESC(atapi_passthru16, Enable ATA_16 passthru for ATAPI devices,
on by default (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-scsi.c b/drivers/ata/libata-scsi.c
index e836476..b9a67c1 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_passthru16)) {
+ /* 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..bdee8c2 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_passthru16;
extern int libata_fua;
extern int libata_noacpi;
extern struct ata_queued_cmd *ata_qc_new_init(struct ata_device *dev);
-
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: implement BROKEN_HPA horkage and apply it to HDS724040KLSA80
I'd rather know what is going on here. A drive can legitimately support LBA48 and HPA and refuse READ_NATIVE_MAX_EXT. READ_NATIVE_MAX_EXT is mandatory if HPA LBA48, no? No - and we hit this specific case in old IDE with some Maxtor drives. Haven't tried that but the problem is that the drive times out READ_NATIVE_MAX_EXT so it doesn't really matter whether the drive succeeds READ_NATIVE_MAX or not. For more detail, please read the following thread. http://thread.gmane.org/gmane.linux.ide/21322 Thanks will do: device reports in words 85-87 and 120, which libata currently doesn't do. Are we leaving this out intentionally (for broken devices) or just did we just miss it? We missed it. I assume the drive in the blacklist sets it correctly however ? 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] libata: implement BROKEN_HPA horkage and apply it to HDS724040KLSA80
On Tue, 07 Aug 2007 11:47:38 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:
People should check out Ben C's HPA fixes and cleanups, too. (attached)
I was hoping one of the original libata HPA authors would review that in
depth and integrate. (it no longer applies cleanly)
Looks basically sound but we should still probably move over this bit of
the old IDE paranoia as well:
/*
* Bits 10 of command_set_1 and cfs_enable_1 must be equal,
* so on non-buggy drives we need test only one.
* However, we should also check whether these fields are valid.
*/
static inline int idedisk_supports_hpa(const struct hd_driveid *id)
{
return (id-command_set_1 0x0400) (id-cfs_enable_1 0x0400); }
---
-
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: implement BROKEN_HPA horkage and apply it to HDS724040KLSA80
I'd rather know what is going on here. A drive can legitimately support LBA48 and HPA and refuse READ_NATIVE_MAX_EXT. READ_NATIVE_MAX_EXT is mandatory if HPA LBA48, no Ok the report in that thread is different. The offending Maxtor simply aborts the read_native_max_ext - 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: implement BROKEN_HPA horkage and apply it to HDS724040KLSA80
Alan Cox wrote: On Tue, 07 Aug 2007 11:47:38 -0400 Jeff Garzik [EMAIL PROTECTED] wrote: People should check out Ben C's HPA fixes and cleanups, too. (attached) I was hoping one of the original libata HPA authors would review that in depth and integrate. (it no longer applies cleanly) Looks basically sound but we should still probably move over this bit of the old IDE paranoia as well: Oh quite agreed... 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] libata: implement BROKEN_HPA horkage and apply it to HDS724040KLSA80
Alan Cox wrote: I'd rather know what is going on here. A drive can legitimately support LBA48 and HPA and refuse READ_NATIVE_MAX_EXT. READ_NATIVE_MAX_EXT is mandatory if HPA LBA48, no? No - and we hit this specific case in old IDE with some Maxtor drives. Hmmm... Looking up the spec... This is from ATA8-ACS 4.11.1. A device that implements the Host Protected Area feature set and supports the 48-bit Address feature set shall implement the following additional set of commands: a) READ NATIVE MAX ADDRESS EXT b) SET MAX ADDRESS EXT Devices supporting this feature set shall set IDENTIFY DEVICE data word 82 bit 10 to one. Did older specs specify it differently? Haven't tried that but the problem is that the drive times out READ_NATIVE_MAX_EXT so it doesn't really matter whether the drive succeeds READ_NATIVE_MAX or not. For more detail, please read the following thread. http://thread.gmane.org/gmane.linux.ide/21322 Thanks will do: device reports in words 85-87 and 120, which libata currently doesn't do. Are we leaving this out intentionally (for broken devices) or just did we just miss it? We missed it. I assume the drive in the blacklist sets it correctly however ? Yes, it does. -- 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: libata-core.c: ata_fill_sg() ... sanity check on arithmentic ?
So then ap-prd[idx].flags_len gets set to (0x1 0x) = 0 ! So this sg element ends up with a zero length, even though the transfer size should be 64k. Is this correct behaviour, if not, should it be corrected ? The specification says that 0x means 64K. A couple of controllers do get this wrong and we did recently add a second sg list builder for those. Perhaps a comment or two is in order ? - 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/1] AVR32 PATA driver
On Tuesday 07 August 2007 17:54:09 Alan Cox wrote:
+static int pata_at32_get_pio_mask(void)
+{
+ switch (max_pio) {
+ case 0:
+ return 0x01;
+ case 1:
+ return 0x03;
+ case 2:
+ return 0x07;
+ case 3:
+ return 0x0f;
+ case 4:
+ return 0x1f;
+ default:
+ return 0x01;
What is wrong with just using (1 max_pio) - 1 as the range is only
0-4 anyway.
Since max_pio is a module argument it may be invalid. Perhaps:
if (0 = max_pio max_pio = 4)
return (1 max_pio) - 1;
else
return 0x01;
Or is it common to trust the module arguments to be sane?
+static void pata_at32_data_xfer(struct ata_device *adev, unsigned char
*buf, + unsigned int buflen, int write_data)
+{
+ struct at32_ide_info *info = adev-ap-host-private_data;
+
+ /* Set SMC to data transfer speed */
+ if (info-smc_pio_mode 3)
+ smc_restore_registers(info-cs, info-smc_16.reg);
+
+ /* Transfer data */
+ ata_data_xfer(adev, buf, buflen, write_data);
+
+ /* Set SMC back to register transfer speed */
+ if (info-smc_pio_mode 3)
+ smc_restore_registers(info-cs, info-smc_8.reg);
Should be safe currently for IRQ driven behaviour, might be for polled but
remember that without locking you could end up reading the status before
you switch the clock back so I'm not 100% sure.
I now see that things can get messed up. I can alter the hardware so that a
seperate SMC memory space for data and register transfer can be used, each
with their respective timing set at all times. This will cost one extra chip
select pin and an AND port on the adaptor, but it might be worth it?
--
With kind regards
Kristoffer Nyborg Gregertsen
Student, Department of Engineering Cybernetics
Norwegian University of Science and Technology
Trondheim, Norway
-
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/1] AVR32 PATA driver
Kristoffer Nyborg Gregertsen wrote:
On Tuesday 07 August 2007 17:54:09 Alan Cox wrote:
+static int pata_at32_get_pio_mask(void)
+{
+ switch (max_pio) {
+ case 0:
+ return 0x01;
+ case 1:
+ return 0x03;
+ case 2:
+ return 0x07;
+ case 3:
+ return 0x0f;
+ case 4:
+ return 0x1f;
+ default:
+ return 0x01;
What is wrong with just using (1 max_pio) - 1 as the range is only
0-4 anyway.
Since max_pio is a module argument it may be invalid. Perhaps:
if (0 = max_pio max_pio = 4)
return (1 max_pio) - 1;
else
return 0x01;
Or is it common to trust the module arguments to be sane?
Well, a higher level issue, you should not have a max_pio module
parameter at all. Other drivers do not have such a thing.
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 0/1] AVR32 PATA driver
On Tuesday 07 August 2007 17:58:12 Alan Cox wrote: 1) In PIO1 and PIO2 there are rare freezes: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata3.00: cmd 20/00:00:d3:7e:5d/00:00:00:00:00/e1 tag 0 cdb 0x0 data 131072 in res 58/00:01:d2:7f:5d/00:00:01:00:00/e1 Emask 0x2 (HSM violation) The freezes happen close to each other in time. The freezes does not make file operations fail. Are you 100% sure all your timings are right and there are no I/O posting prolems that might lead the various required delays to come out wrong ? I've looked at the signals with a logic analyzer, they seem to be correct. The timings are computed by ata_timing_compute. I've also added pull-up resistors on all the control signals just to make sure they are always sane. Since the there is no problems for PIO3 and 4, perhaps this error is related to the problem of pata_at32_data_xfer being non-atomic while changing the SMC timings that you addressed in your other mail? + /* Set SMC to data transfer speed */ + if (info-smc_pio_mode 3) + smc_restore_registers(info-cs, info-smc_16.reg); + + /* Transfer data */ + ata_data_xfer(adev, buf, buflen, write_data); + + /* Set SMC back to register transfer speed */ + if (info-smc_pio_mode 3) + smc_restore_registers(info-cs, info-smc_8.reg); I'll test to see if this is causing the errors. If so I'll setup different memory spaces for data and register transfers as described in the my last mail. 2) After being in operation for a long time (+24 hours) the disk reports wrong identity: ata4.00: model number mismatch 'IC35L060AVV207-0' != '' ata4.00: revalidation failed (errno=-19) ata4.00: limiting speed to PIO2 ata4: failed to recover some devices, retrying in 5 secs ata4.00: model number mismatch 'IC35L060AVV207-0' != 'AV07-0 *GARBEL* This has happend with both the devices I am testing, the 'Quantum Fireball' reported it self to be 'Quanpum Fiveball' after 24 hours of testing. That sounds to me like your hardware - heat, clock drift ? Perhaps it's heat. The disks lie on my desk with no ventilation besides the air circulating in the room. Turning them off for a little while solves the problem. I also have a question regrding INTRQ / IRQ handeling. Since I am not using DMA, there seems to be no reason to handle interrupts, so I set the polling flag. Not using the polling flag gives a lot of interrupts that does not seem to do anything except eating my CPU cycles. Is this correct? If so, what shall I do when activating the host to not get irq 65: nobody cared ... Disabling IRQ #65. Should I give an negative irq number? When you get an IRQ you need to clear the IRQ status. Good question why you are getting them but you may well do in the resetting phases even with nIEN in use. OTOH if you get one or two per command then someone must have nIEN wrong on command issue. Either way you need to clear down IRQs that occur - some hardware doesn't get nIEN right and interrupts anyway in some cases. I just read in the ATA spec and realize that I need to add a pull-down resistor on the INTRQ signal. The signal is now floating when nIEN is set. I feel silly, sorry to bother you with HW design faults :) -- With kind regards Kristoffer Nyborg Gregertsen Student, Department of Engineering Cybernetics Norwegian University of Science and Technology Trondheim, Norway - 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/1] AVR32 PATA driver
On Tuesday 07 August 2007 20:14:27 Jeff Garzik wrote: Well, a higher level issue, you should not have a max_pio module parameter at all. Other drivers do not have such a thing. OK, I'll remove it then. It was very convenient during automated testing of all PIO modes, but I guess that's not needed by the end users. -- With kind regards Kristoffer Nyborg Gregertsen Student, Department of Engineering Cybernetics Norwegian University of Science and Technology Trondheim, Norway - 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: No equivalent for ide-scsi available with the new PATA drivers?
I have a PATA tape drive here somewhere. -EBUSY Does anyone out there want it, with the understanding that it be used to test/improve libata tape support? I'm happy to help someone else doing the work who needs info on libata etc but I've no time to work on whats a very obscure corner case. - 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: implement BROKEN_HPA horkage and apply it to HDS724040KLSA80
On 08/07/2007 11:36 AM, Tejun Heo wrote: Alan Cox wrote: On Tue, 7 Aug 2007 14:42:50 +0900 Tejun Heo [EMAIL PROTECTED] wrote: HDS724040KLSA80 reports that it supports HPA LBA48 but craps itself on READ_NATIVE_MAX_EXT. Implement BROKEN_HPA horkage and apply it to the drive. If the horkage is set, all HPA operations are skipped. I'd rather know what is going on here. A drive can legitimately support LBA48 and HPA and refuse READ_NATIVE_MAX_EXT. READ_NATIVE_MAX_EXT is mandatory if HPA LBA48, no? In addition just about every OS I know queries the HPA which means that something other than HPA support being broken is probably at the root. We thus want to find the real fix. What do the actual traces look like ? Does it crap out of it gets READ_NATIVE_MAX ? Haven't tried that but the problem is that the drive times out READ_NATIVE_MAX_EXT so it doesn't really matter whether the drive succeeds READ_NATIVE_MAX or not. For more detail, please read the following thread. http://thread.gmane.org/gmane.linux.ide/21322 There's also this Fedora bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=251047#c2 ...where after an error on the slave device the master starts throwing HPA errors after the port is reset. Don't know if it's related or not... - 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: Disk spin down issue on shut down/suspend to disk
I did some additional checking today... On kernels prior to 2.6.22 line, the bug exists and manifests itself exactly the same way. However, when I removed the -h flag from /etc/init.d/halt, the drive spins down only once on Power down message and there is no sign of the bug and the emergency unload count remains constant. I've verified this on kernels 2.6.21.6; 2.6.20.4; 2.6.18-4-686-Etch. The obvious conclusion is that something must have changed it the 2.6.22 kernels, so that removing the -h has no effect. I dunno if my observations are of any value, but I thought You should know... Regards, Michael - 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: implement BROKEN_HPA horkage and apply it to HDS724040KLSA80
There's also this Fedora bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=251047#c2 ...where after an error on the slave device the master starts throwing HPA errors after the port is reset. Don't know if it's related or not... Looks unrelated. You get a timeout ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.01: cmd a0/00:00:00:00:20/00:00:00:00:00/b0 tag 0 cdb 0x43 data 12 in res 40/00:03:00:00:20/00:00:00:00:00/b0 Emask 0x4 (timeout) and then the entire system shits itself ata2.00: qc timeout (cmd 0xf8) ata2.00: failed to set xfermode (err_mask=0x40) Looks like the bus didn't come back from whatever broke it. - 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: Disk spin down issue on shut down/suspend to disk
2007/8/7, Michael Sedkowski [EMAIL PROTECTED]: I did some additional checking today... On kernels prior to 2.6.22 line, the bug exists and manifests itself exactly the same way. However, when I removed the -h flag from /etc/init.d/halt, the drive spins down only once on Power down message and there is no sign of the bug and the emergency unload count remains constant. I've verified this on kernels 2.6.21.6; 2.6.20.4; 2.6.18-4-686-Etch. The obvious conclusion is that something must have changed it the 2.6.22 kernels, so that removing the -h has no effect. I dunno if my observations are of any value, but I thought You should know... I confirm this. First 2.6.21-rcx works OK (if I remember). In 2.6.22(.1) remove -h option doesn't help - only warning message dissapear, and double spin down also exists in suspend to disk. The same laptop, bios, Debian etc. -- Maciej Rutecki http://www.maciek.unixy.pl - 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: Disk spin down issue on shut down/suspend to disk
On Tuesday, 7 August 2007 22:09, Maciej Rutecki wrote:
2007/8/7, Michael Sedkowski [EMAIL PROTECTED]:
I did some additional checking today...
On kernels prior to 2.6.22 line, the bug exists and manifests itself
exactly the same way. However, when I removed the -h flag
from /etc/init.d/halt, the drive spins down only once on Power down
message and there is no sign of the bug and the emergency unload count
remains constant. I've verified this on kernels 2.6.21.6; 2.6.20.4;
2.6.18-4-686-Etch.
The obvious conclusion is that something must have changed it the 2.6.22
kernels, so that removing the -h has no effect.
I dunno if my observations are of any value, but I thought You should
know...
I confirm this. First 2.6.21-rcx works OK (if I remember). In
2.6.22(.1) remove -h option doesn't help - only warning message
dissapear, and double spin down also exists in suspend to disk.
Well, on my box (nx6325) with the appended (experimental) patch applied
on top of 2.6.23-rc1 with the patchset from
http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc2/patches/ , the
double spin down doesn't occur during hibernation and the system is shut down
notceably faster.
Greetings,
Rafael
---
kernel/power/disk.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
Index: linux-2.6.23-rc2/kernel/power/disk.c
===
--- linux-2.6.23-rc2.orig/kernel/power/disk.c 2007-08-06 14:04:07.0
+0200
+++ linux-2.6.23-rc2/kernel/power/disk.c2007-08-07 21:10:59.0
+0200
@@ -223,15 +223,23 @@ int hibernation_platform_enter(void)
int error;
if (hibernation_ops) {
- kernel_shutdown_prepare(SYSTEM_SUSPEND_DISK);
/*
* We have cancelled the power transition by running
* hibernation_ops-finish() before saving the image, so we
* should let the firmware know that we're going to enter the
* sleep state after all
*/
- error = hibernation_ops-prepare();
- sysdev_shutdown();
+ error = hibernation_ops-start();
+ if (!error) {
+ suspend_console();
+ error = device_suspend(PMSG_SUSPEND);
+ }
+ if (!error)
+ error = hibernation_ops-prepare();
+ if (!error)
+ error = disable_nonboot_cpus();
+ if (!error)
+ error = device_power_down(PMSG_SUSPEND);
if (!error)
error = hibernation_ops-enter();
} 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
[2.6.22.2 review 67/84] libata: add FUJITSU MHV2080BH to NCQ blacklist
From: Tejun Heo [EMAIL PROTECTED]
Please warmly welcome the first member from FUJITSU to the prestigious
NCQ spurious completion club.
This is reported by Serge Van Thillo in bugzilla bug 8730.
http://bugzilla.kernel.org/show_bug.cgi?id=8730
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Cc: Serge van Thillo [EMAIL PROTECTED]
Cc: Jeff Garzik [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---
drivers/ata/libata-core.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3800,6 +3800,7 @@ static const struct ata_blacklist_entry
{ HTS541612J9SA00,SBDIC7JP, ATA_HORKAGE_NONCQ, },
{ Hitachi HTS541616J9SA00, SB4OC70P, ATA_HORKAGE_NONCQ, },
{ WDC WD740ADFD-00NLR1, NULL, ATA_HORKAGE_NONCQ, },
+ { FUJITSU MHV2080BH, 00840028, ATA_HORKAGE_NONCQ, },
/* Devices with NCQ limits */
--
-
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: Disk spin down issue on shut down/suspend to disk
Well, on my box (nx6325) with the appended (experimental) patch applied on top of 2.6.23-rc1 with the patchset from s/2.6.23-rc1/2.6.23-rc2/ HP nx 6310, _old_ shutdown 2.6.23-rc2+above patches: 1. Before: rutek:/home/maciek# /usr/sbin/smartctl --all -d ata /dev/sda | grep Power-Off_Retract_Count 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age Always - 61 2. Try suspend to disk, double spin down doesn't exist 3. Normal shutdown, double spin down exists, BUT NOTE: I have still old shutdown utility from Debian package. 4. After: rutek:/home/maciek# /usr/sbin/smartctl --all -d ata /dev/sda | grep Power-Off_Retract_Count 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age Always - 61 (it doesn't change=61). I wait for Michael, He has new shutdown from Sidux, and the same notebook. -- Maciej Rutecki http://www.maciek.unixy.pl - 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: implement BROKEN_HPA horkage and apply it to HDS724040KLSA80
Well, it's what the ide driver does. BTW, according to the spec, we need to test bit 14 and 15 of word 87 before trusting any value the device reports in words 85-87 and 120, which libata currently doesn't do. Are we leaving this out intentionally (for broken devices) or just did we just miss it? Much of our testing was short checks on validity bits [although thats really all paranoia]. Fixed in my tree and also made the hpa check match drivers/ide and check both. Verified the rest, fixed the dword_io check. Think our flush_cache handling is still buggy in both old and new IDE btw. - 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.22.2 review 06/84] Add a PCI ID for santa rosas PATA controller.
On Tuesday, 7. August 2007, Greg KH wrote:
From: Christian Lamparter [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.
Signed-off-by: Christian Lamparter [EMAIL PROTECTED]
Signed-off-by: Jeff Garzik [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
I did not receive any complains. I guess it's stable enough for -stable ;-) ...
---
Not OT:
There is another outstanding issue with ata_piix.c.
Intel has never officially supported anything faster than PATA 100MB/s.
But, the ata_piix.c driver define the ICH5 ICH7 as UDMA6 (aka 133MB/s)
capable.
[ Well, no one has probably noticed it before, because there is bug in
do_pata_set_dmamode...
Just look at libata_atapiix_enable_real_udma133.patch and you'll see what wrong
with it. ]
Here are Intel's datasheets for the affected chipsets:
ICH5 Datasheet: http://www.intel.com/design/chipsets/datashts/252516.htm
(See note on page 183: ... the ICH5 supports reads at the maximum rate of
100MB/s.)
ICH7 Datasheet: http://www.intel.com/design/chipsets/datashts/307013.htm
(See first note on page 190: ... the ICH7 supports reads at the maximum rate
of 100MB/s.)
-
They are two different ways to deal with it:
- Either -
1. replace all ich_pata_133 with ich_pata_100.
(libata_atapiix_disable_udma6.diff - diff from 2.6.22 )
- Or -
2. keep all ich_pata_133 and fix the bug in do_pata_set_dmamode.
(libata_atapiix_enable_real_udma133.patch - diff from 2.6.22)
If there are any concerns about the safety of the patch patch:
http://lkml.org/lkml/2007/7/6/292 (It was already tested by an Intel
employee,
but I guess a bit more user input is necessary here... )
Both ways have their pros and cons. Unfortunately, I don't have the time to
follow this
discussion right now, so here's a:
Signed-off-by: Christian Lamparter [EMAIL PROTECTED]
(Just in case, if one of the patches really gets merged!)
Thanks,
Chr.
--- a/drivers/ata/ata_piix.c 2007-08-08 00:52:52.0 +0200
+++ b/drivers/ata/ata_piix.c 2007-08-08 00:55:45.0 +0200
@@ -122,7 +122,7 @@ enum {
ich_pata_33 = 1, /* ICH up to UDMA 33 only */
ich_pata_66 = 2, /* ICH up to 66 Mhz */
ich_pata_100 = 3, /* ICH up to UDMA 100 */
- ich_pata_133 = 4, /* ICH up to UDMA 133 */
+ /* ICH up to UDMA 133 is not supported */
ich5_sata = 5,
ich6_sata = 6,
ich6_sata_ahci = 7,
@@ -190,7 +190,7 @@ static const struct pci_device_id piix_p
{ 0x8086, 0x24CA, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_100 },
{ 0x8086, 0x24CB, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_100 },
/* Intel ICH5 */
- { 0x8086, 0x24DB, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_133 },
+ { 0x8086, 0x24DB, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_100 },
/* C-ICH (i810E2) */
{ 0x8086, 0x245B, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_100 },
/* ESB (855GME/875P + 6300ESB) UDMA 100 */
@@ -198,7 +198,7 @@ static const struct pci_device_id piix_p
/* ICH6 (and 6) (i915) UDMA 100 */
{ 0x8086, 0x266F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_100 },
/* ICH7/7-R (i945, i975) UDMA 100*/
- { 0x8086, 0x27DF, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_133 },
+ { 0x8086, 0x27DF, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_100 },
{ 0x8086, 0x269E, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_100 },
/* NOTE: The following PCI ids must be kept in sync with the
@@ -479,7 +479,7 @@ static struct ata_port_info piix_port_in
.port_ops = ich_pata_ops,
},
- /* ich_pata_133: 4 ICH with full UDMA6 */
+ /* ich_pata_133: 4 - Not supported - */
{
.sht = piix_sht,
.flags = PIIX_PATA_FLAGS | PIIX_FLAG_CHECKINTR,
--- a/drivers/ata/ata_piix.c 2007-08-08 00:52:52.0 +0200
+++ b/drivers/ata/ata_piix.c 2007-08-08 00:53:03.0 +0200
@@ -765,8 +765,8 @@ static void do_pata_set_dmamode (struct
* except UDMA0 which is 00
*/
u_speed = min(2 - (udma 1), udma);
- if (udma == 5)
- u_clock = 0x1000; /* 100Mhz */
+ if (udma = 5)
+ u_clock = 0x1000; /* 133Mhz */
else if (udma 2)
u_clock = 1; /* 66Mhz */
else
Re: Disk spin down issue on shut down/suspend to disk
Henrique de Moraes Holschuh wrote: On Tue, 07 Aug 2007, Tejun Heo wrote: emergency unload. Emergency unload does shorten the lifespan of the disk but you don't have to worry too much about it. Disks are designed to withstand certain number of emergency unloads. You *do* have to worry about it in any box you turn off daily. Desktop HDs will croak fast in that scenario, laptop HDs less so, but still too fast. A very good laptop HD can last about 20k emergency unloads (this is a unit that can do about 600k normal unloads in its lifetime). Desktop and server HDs don't even come close to those numbers, last time I checked. It only matters on hard drives which actually use load-unload heads. Lots of desktop/server drives (perhaps some laptop ones as well) still use contact start/stop, which doesn't remove the heads from the platters on shutdown but just parks the heads over the landing zone. I don't think arbitrary power-offs make too much difference on those drives. (However, these generally aren't rated to handle as many start/stop cycles, which is why laptop drives generally use load/unload instead.) -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disk spin down issue on shut down/suspend to disk
Henrique de Moraes Holschuh wrote: On Tue, 07 Aug 2007, Tejun Heo wrote: Henrique de Moraes Holschuh wrote: On Tue, 07 Aug 2007, Tejun Heo wrote: Michael Sedkowski wrote: Hmmm... If the problem only shows up on nx6325, it might be that ACPI is pulling unnecessary stunt. Please apply the attached patch and report when the disk spins down and up. Disk spins down on Pre-shutdown prepare and then goes up and down on Power down. Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether it spins down the disk correctly. Does emergency unload count increase after each power down? Also, please post the result of 'dmidecode'. You know, this actually make a lot of sense, and one can't even complain about firmware that pulls that off. Well, I'm complaining. I think the problem here is that it isn't clear which one is who's responsibility. There's a Korean saying which The BIOS *has* to do it when in DOS mode, the HD manuals are very very clear about it. Doing it through ACPI ATA objects is at least non-broken as far as these things go, as one knows when to do it directly (non-ACPI mode), and one doesn't talk to the disk directly. approximately translates into if you have too many boatmen on a ship, it goes to mountain. We also have a bunch of Toshiba laptops which Yeah, that's a problem. But we can avoid it if we start snooping what ACPI is asking us to deliver to the disks, which IMO is an extremely good idea anyway. Problem is I don't think we can do this. As far as I can tell, on my Compaq at least, it's not being done through ACPI AML in the DSDT, like in the _PTS function (which the kernel executes and can snoop), but when we actually do the power-off we write a value to a magic ACPI register. That likely triggers the BIOS to take control in SMM mode and access the controller directly before triggering the power off, which we have no control or knowledge of. want the ATA controller to be in enabled state when ACPI suspend is invoked because the suspend method apparently wants to execute some commands before going to sleep. That's just broken, since it is not even using a OS-backed SATA/ATA ACPI method to do it. I wish ACPI spec carries a big fat sign saying stay f*** away from anything which isn't essential to the requested operation. Shutting down disks *is* essential to the power off operation. ACPI would have to mandate who is to do it, instead (ACPI table or OSI by itself). Any chances of changing things so that we inspect/snoop all tasks sent to the device, and filter them out, or react to them accordingly? No, we can't unless we snoop ACPI method execution and detect accesses to IO ports or iomem regions. It's not going through any driver. This is a gross mess. I don't mean fixing the stuff clowns like Toshiba did. The correct fix for that is to blacklist the hell out of that crap and patch their DSDT into something remotely sane. I do mean snooping the ACPI methods that *return* a taskset to send to the driver, and we send that taskset ourselves in libata and libpata(?). -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] pata_hpt37x: actually clock HPT374 by 50 MHz DPLL
Alan Cox wrote: /* Compute DPLL */ - dpll = 2; - if (port-udma_mask 0xE0) - dpll = 3; + dpll = (port-udma_mask 0xC0) ? 3 : 2; Gak, I'd much rather people kept to the nice easy to read if() but fine is_author_p()?Signed-off-by:Acked-by Alan Cox [EMAIL PROTECTED] Does your ACK stand, even though it still locks up for Bob Ham? 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] ata_piix: update map 10b for ich8m
Tejun Heo wrote: Fix map entry 10b for ich8. It's [P0 P2 IDE IDE] like ich6 / ich6m. Signed-off-by: Tejun Heo [EMAIL PROTECTED] Cc: Kristen Carlson Accardi [EMAIL PROTECTED] --- Many users can be hit by this. Please consider for -stable. Thanks. drivers/ata/ata_piix.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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
pata_ali: trouble with DVD combo
Hi, I just compiled 2.6.23-rc1-mm2 with libata for the first time. I chose CONFIG_ATA, CONFIG_ATA_ACPI and CONFIG_PATA_ALI. CONFIG_BLK_DEV_SD and CONFIG_BLK_DEV_SR are enabled, too. My hardware is: 00:04.0 IDE interface: ALi Corporation M5229 IDE (rev c4) (prog-if fa) Subsystem: ALi Corporation M5229 IDE Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 64 (500ns min, 1000ns max) Interrupt: pin A routed to IRQ 0 Region 0: [virtual] Memory at 01f0 (32-bit, non-prefetchable) [disabled] [size=8] Region 1: [virtual] Memory at 03f0 (type 3, non-prefetchable) [disabled] [size=1] Region 2: [virtual] Memory at 0170 (32-bit, non-prefetchable) [disabled] [size=8] Region 3: [virtual] Memory at 0370 (type 3, non-prefetchable) [disabled] [size=1] Region 4: I/O ports at a000 [size=16] Capabilities: [60] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:07.0 ISA bridge: ALi Corporation M1533/M1535 PCI to ISA Bridge [Aladdin IV/V/V+] Subsystem: ALi Corporation ALi M1533 Aladdin IV/V ISA Bridge Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Capabilities: [a0] Power Management version 1 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- The boot process takes several minutes when trying to configure the Combo drive with UDMA/33 and finally settles with UDMA/25: scsi0 : pata_ali scsi1 : pata_ali ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001a000 irq 14 ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001a008 irq 15 ata1.00: ATA-6: FUJITSU MHS2040AT D, 8405, max UDMA/100 ata1.00: 78140160 sectors, multi 16: LBA ata1.00: configured for UDMA/100 ata2.00: ATAPI: Slimtype COMBO LSC-24081M, 3MC1, max UDMA/33 ata2.00: configured for UDMA/33 scsi 0:0:0:0: Direct-Access ATA FUJITSU MHS2040A 8405 PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 78140160 512-byte hardware sectors (40008 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 78140160 512-byte hardware sectors (40008 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sda5 sda6 sda4 sd 0:0:0:0: [sda] Attached SCSI disk ata1.00: Unable to set Link PM policy scsi 1:0:0:0: CD-ROMSlimtype COMBO LSC-24081M 3MC1 PQ: 0 ANSI: 5 ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x5a data 128 in res 40/00:03:00:00:20/00:00:00:00:00/a0 Emask 0x4 (timeout) ata2: port is slow to respond, please be patient (Status 0xd0) ata2: device not ready (errno=-16), forcing hardreset ata2: soft resetting port ata2.00: configured for UDMA/33 ata2: EH complete ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x5a data 128 in res 40/00:03:00:00:20/00:00:00:00:00/a0 Emask 0x4 (timeout) ata2: port is slow to respond, please be patient (Status 0xd0) ata2: device not ready (errno=-16), forcing hardreset ata2: soft resetting port ata2.00: configured for UDMA/33 ata2: EH complete ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x5a data 128 in res 40/00:03:00:00:20/00:00:00:00:00/a0 Emask 0x4 (timeout) ata2: port is slow to respond, please be patient (Status 0xd0) ata2: device not ready (errno=-16), forcing hardreset ata2: soft resetting port ata2.00: configured for UDMA/33 ata2: EH complete ata2.00: limiting speed to UDMA/25:PIO4 ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x5a data 128 in res 40/00:03:00:00:20/00:00:00:00:00/a0 Emask 0x4 (timeout) ata2: port is slow to respond, please be patient (Status 0xd0) ata2: device not ready (errno=-16), forcing hardreset ata2: soft resetting port ata2.00: configured for UDMA/25 ata2: EH complete sr0: scsi-1 drive Uniform CD-ROM driver Revision: 3.20 sr 1:0:0:0: Attached scsi CD-ROM sr0 ata2.00: Unable to set Link PM policy The thing goes on when I try to mount a CD. But this time it always configures UDMA/25. I had to kill the mount
[git patches] libata fixes
The only non-fix are two sata_mv PCI ID additions.
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|2 +-
drivers/ata/pata_isapnp.c |2 ++
drivers/ata/sata_mv.c |3 +++
3 files changed, 6 insertions(+), 1 deletions(-)
Alan Cox (1):
sata_mv: PCI IDs for Hightpoint RocketRaid 1740/1742
Jeff Garzik (1):
[libata] pata_isapnp: replace missing module device table
Tejun Heo (1):
ata_piix: update map 10b for ich8m
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index a78832e..c5b4509 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -436,7 +436,7 @@ static const struct piix_map_db ich8_map_db = {
/* PM PS SM SS MAP */
{ P0, P2, P1, P3 }, /* 00b (hardwired when in AHCI) */
{ RV, RV, RV, RV },
- { IDE, IDE, NA, NA }, /* 10b (IDE mode) */
+ { P0, P2, IDE, IDE }, /* 10b (IDE mode) */
{ RV, RV, RV, RV },
},
};
diff --git a/drivers/ata/pata_isapnp.c b/drivers/ata/pata_isapnp.c
index 5525518..91a396f 100644
--- a/drivers/ata/pata_isapnp.c
+++ b/drivers/ata/pata_isapnp.c
@@ -139,6 +139,8 @@ static struct pnp_device_id isapnp_devices[] = {
{.id = }
};
+MODULE_DEVICE_TABLE(pnp, isapnp_devices);
+
static struct pnp_driver isapnp_driver = {
.name = DRV_NAME,
.id_table = isapnp_devices,
diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index 8ec5208..3acf65e 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -621,6 +621,9 @@ static const struct pci_device_id mv_pci_tbl[] = {
{ 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 },
{ PCI_VDEVICE(MARVELL, 0x6040), chip_604x },
{ PCI_VDEVICE(MARVELL, 0x6041), chip_604x },
-
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/2] pata_hpt37x: actually clock HPT374 by 50 MHz DPLL
On Tue, 07 Aug 2007 20:49:34 -0400 Jeff Garzik [EMAIL PROTECTED] wrote: Alan Cox wrote: /* Compute DPLL */ - dpll = 2; - if (port-udma_mask 0xE0) - dpll = 3; + dpll = (port-udma_mask 0xC0) ? 3 : 2; Gak, I'd much rather people kept to the nice easy to read if() but fine is_author_p()?Signed-off-by:Acked-by Alan Cox [EMAIL PROTECTED] Does your ACK stand, even though it still locks up for Bob Ham? Its a real fix for a real bug. The 374 needs a bit more stuff which is sitting in my tree and I'll push for Sergei to comment tomorrow - 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: pata_ali: trouble with DVD combo
The boot process takes several minutes when trying to configure the Combo drive with UDMA/33 and finally settles with UDMA/25: Known problem. Still under investigation and not yet understood fully. Is this a problem with my drive? It works fine with alim15x3, so. Did I forget to enable something in the kernel? Please send me an lspci -vvxxx after booting both the libata and non libata kernel. 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 1/2] pata_hpt37x: actually clock HPT374 by 50 MHz DPLL
Alan Cox wrote:
On Tue, 07 Aug 2007 20:49:34 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:
Alan Cox wrote:
/* Compute DPLL */
- dpll = 2;
- if (port-udma_mask 0xE0)
- dpll = 3;
+ dpll = (port-udma_mask 0xC0) ? 3 : 2;
Gak, I'd much rather people kept to the nice easy to read if() but fine
is_author_p()?Signed-off-by:Acked-by Alan Cox [EMAIL PROTECTED]
Does your ACK stand, even though it still locks up for Bob Ham?
Its a real fix for a real bug. The 374 needs a bit more stuff which is
sitting in my tree and I'll push for Sergei to comment tomorrow
OK, thanks. Do you also ACK
[PATCH 2/2] pata_hpt{37x|3x2n}: fix clock reporting
?
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: pata_ali: trouble with DVD combo
Please send me an lspci -vvxxx after booting both the libata and non libata kernel. There you go. With libata: 00:00.0 Host bridge: ATI Technologies Inc AGP Bridge [IGP 320M] (rev 13) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 64 Region 0: Memory at ec00 (32-bit, prefetchable) [size=64M] Region 1: Memory at e880 (32-bit, prefetchable) [size=4K] Region 2: I/O ports at a010 [disabled] [size=4] Capabilities: [a0] AGP version 2.0 Status: RQ=16 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4 Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=none 00: 02 10 b0 ca 06 00 30 02 13 00 00 06 00 40 00 00 10: 08 00 00 ec 08 00 80 e8 11 a0 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 0b 03 00 00 00 00 00 00 04 0d 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: bd 0c a6 85 24 36 e2 56 00 00 00 00 f0 01 06 c1 70: e0 0d 20 31 84 84 84 84 00 00 00 00 00 00 00 00 80: 00 00 00 00 96 10 83 00 33 00 30 00 03 00 00 00 90: 00 00 00 00 1f 1d 05 00 00 00 e4 7f 80 00 00 00 a0: 02 00 20 00 17 02 00 0f 00 00 00 00 03 00 00 00 b0: 00 00 02 00 08 00 00 00 04 04 04 04 00 00 00 00 c0: 00 00 00 ff 5a 15 05 0f 00 1c ff 1f 00 00 84 00 d0: eb 7b 0f 00 eb 7b 4f 00 6a 00 60 10 00 00 00 ff e0: 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 00 ff f0: 1f 00 09 00 00 00 00 ff 00 08 10 18 00 00 00 00 00:01.0 PCI bridge: ATI Technologies Inc PCI Bridge [IGP 320M] (rev 01) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 99 Bus: primary=00, secondary=01, subordinate=01, sec-latency=68 I/O behind bridge: b000-bfff Memory behind bridge: e850-e85f Prefetchable memory behind bridge: f000-f7ff Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort+ SERR- PERR- BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- Reset- FastB2B- 00: 02 10 0f 70 07 00 20 02 01 00 04 06 00 63 01 00 10: 00 00 00 00 00 00 00 00 00 01 01 44 b1 b1 20 22 20: 50 e8 50 e8 00 f0 f0 f7 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 0c 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:02.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) (prog-if 10 [OHCI]) Subsystem: ALi Corporation USB 1.1 Controller Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 64 (2ns max) Interrupt: pin A routed to IRQ 9 Region 0: Memory at e840 (32-bit, non-prefetchable) [size=4K] Capabilities: [60] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: b9 10 37 52 17 00 90 02 03 10 03 0c 00 40 00 00 10: 00 00 40 e8 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 b9 10 37 52 30: 00 00 00 00 60 00 00 00 00 00 00 00 0b 01 00 50 40: 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 01 00 02 80 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:03.0 Modem: ALi Corporation M5457 AC'97 Modem Controller (prog-if 00 [Generic]) Subsystem: Fujitsu Siemens Computer GmbH Unknown device 100a Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Re: [PATCH 1/2] pata_hpt37x: actually clock HPT374 by 50 MHz DPLL
Its a real fix for a real bug. The 374 needs a bit more stuff which is
sitting in my tree and I'll push for Sergei to comment tomorrow
OK, thanks. Do you also ACK
[PATCH 2/2] pata_hpt{37x|3x2n}: fix clock reporting
Yep
-
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: implement BROKEN_HPA horkage and apply it to HDS724040KLSA80
Alan Cox wrote: I'd rather know what is going on here. A drive can legitimately support LBA48 and HPA and refuse READ_NATIVE_MAX_EXT. READ_NATIVE_MAX_EXT is mandatory if HPA LBA48, no Ok the report in that thread is different. The offending Maxtor simply aborts the read_native_max_ext I'll resend sans ata_id_has_hpa() change. Does that sound okay? I don't really think we can do anything other than blacklisting it. -- 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: Disk spin down issue on shut down/suspend to disk
Michael Sedkowski wrote: I did some additional checking today... On kernels prior to 2.6.22 line, the bug exists and manifests itself exactly the same way. However, when I removed the -h flag from /etc/init.d/halt, the drive spins down only once on Power down message and there is no sign of the bug and the emergency unload count remains constant. I've verified this on kernels 2.6.21.6; 2.6.20.4; 2.6.18-4-686-Etch. The obvious conclusion is that something must have changed it the 2.6.22 kernels, so that removing the -h has no effect. I dunno if my observations are of any value, but I thought You should know... Yeah, till 2.6.22, libata didn't spindown disks on suspend or power off which incremented emergency unload count on all normal systems, so only the ACPI S5 routine is spinning down the disk on you system. The problem here is that now that libata is fixed there are two entities trying to spin down the disk and the disk is dumb enough to spin back up when FLUSH CACHE or STANDBYNOW is received while spun down. :-( 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: Disk spin down issue on shut down/suspend to disk
On Tue, 07 Aug 2007, Robert Hancock wrote: You *do* have to worry about it in any box you turn off daily. Desktop HDs will croak fast in that scenario, laptop HDs less so, but still too fast. A very good laptop HD can last about 20k emergency unloads (this is a unit that can do about 600k normal unloads in its lifetime). Desktop and server HDs don't even come close to those numbers, last time I checked. It only matters on hard drives which actually use load-unload heads. Lots of desktop/server drives (perhaps some laptop ones as well) still use contact start/stop, which doesn't remove the heads from the platters on I am not so sure about that. Please correct me if I am wrong, but contact stop in an emergency retract shakes the head assembly badly as well. It subjects the head assembly to higher acceleration than a normal seek, and a nasty impulse at impact with the stopper. And I very much doubt it is nice to the heads to slide into the parking zone at high speed and hit the bumper while over it. Unless I missed something, I don't why an emergency retract would not be as big a problem as an emergency unload. Maybe we should hunt down some proper datasheets for drives lacking head load/unload technology, and check what they say about emergency unloads... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - 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: Disk spin down issue on shut down/suspend to disk
Henrique de Moraes Holschuh wrote: On Tue, 07 Aug 2007, Robert Hancock wrote: You *do* have to worry about it in any box you turn off daily. Desktop HDs will croak fast in that scenario, laptop HDs less so, but still too fast. A very good laptop HD can last about 20k emergency unloads (this is a unit that can do about 600k normal unloads in its lifetime). Desktop and server HDs don't even come close to those numbers, last time I checked. It only matters on hard drives which actually use load-unload heads. Lots of desktop/server drives (perhaps some laptop ones as well) still use contact start/stop, which doesn't remove the heads from the platters on I am not so sure about that. Please correct me if I am wrong, but contact stop in an emergency retract shakes the head assembly badly as well. It subjects the head assembly to higher acceleration than a normal seek, and a nasty impulse at impact with the stopper. And I very much doubt it is nice to the heads to slide into the parking zone at high speed and hit the bumper while over it. Unless I missed something, I don't why an emergency retract would not be as big a problem as an emergency unload. Maybe we should hunt down some proper datasheets for drives lacking head load/unload technology, and check what they say about emergency unloads... I did a bit of a look and didn't find any mention of the subject for drives using contact start/stop. I did find mention that the unload torque needed is quite a bit higher on load/unload systems, so I would imagine that having to extract or store that energy for emergency unloads would be more of a demanding task and might be a rougher process. Just judging from the sound, though, hard power-offs on a desktop Seagate Barracuda 7200.10, for example, which is contact start/stop, don't really sound any different from a commanded standby. On the laptop drives I've seen you can really tell the difference. -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2 #upstream] libata: assume ATA_DEV_ATA on diagnostic failure
Certain device which reports diagnostic failure also reports invalid
device signature. Assume ATA_DEV_ATA on diagnostic failure if reset
indicates device presence.
This is fix for bugzilla bug 8784.
http://bugzilla.kernel.org/show_bug.cgi?id=8784
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Cc: Alan Cox [EMAIL PROTECTED]
Cc: Edward Amsden [EMAIL PROTECTED]
---
drivers/ata/libata-core.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
Index: work/drivers/ata/libata-core.c
===
--- work.orig/drivers/ata/libata-core.c
+++ work/drivers/ata/libata-core.c
@@ -746,10 +746,20 @@ unsigned int ata_dev_try_classify(struct
/* determine if device is ATA or ATAPI */
class = ata_dev_classify(tf);
- if (class == ATA_DEV_UNKNOWN)
- return ATA_DEV_NONE;
- if ((class == ATA_DEV_ATA) (ata_chk_status(ap) == 0))
- return ATA_DEV_NONE;
+ if (class == ATA_DEV_UNKNOWN) {
+ /* If the device failed diagnostic, it's likely to
+* have reported incorrect device signature too.
+* Assume ATA device if the device seems present but
+* device signature is invalid with diagnostic
+* failure.
+*/
+ if (present (dev-horkage ATA_HORKAGE_DIAGNOSTIC))
+ class = ATA_DEV_ATA;
+ else
+ class = ATA_DEV_NONE;
+ } else if ((class == ATA_DEV_ATA) (ata_chk_status(ap) == 0))
+ class = ATA_DEV_NONE;
+
return class;
}
-
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/2 #upstream] libata: udpate ata_dev_try_classify() arguments
Make ata_dev_try_classify() take a pointer to ata_device instead of
ata_port/port_number combination for consistency and add @present
argument. @present indicates whether the device seems present during
reset. It's the result of TF access during softreset and link
onlineness during hardreset. @present will be used to improve
diagnostic failure handling.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/libata-core.c | 31 +--
drivers/ata/pata_scc.c|6 --
drivers/ata/sata_mv.c |2 +-
include/linux/libata.h|3 ++-
4 files changed, 24 insertions(+), 18 deletions(-)
Index: work/drivers/ata/libata-core.c
===
--- work.orig/drivers/ata/libata-core.c
+++ work/drivers/ata/libata-core.c
@@ -696,8 +696,8 @@ unsigned int ata_dev_classify(const stru
/**
* ata_dev_try_classify - Parse returned ATA device signature
- * @ap: ATA channel to examine
- * @device: Device to examine (starting at zero)
+ * @dev: ATA device to classify (starting at zero)
+ * @present: device seems present
* @r_err: Value of error register on completion
*
* After an event -- SRST, E.D.D., or SATA COMRESET -- occurs,
@@ -715,15 +715,15 @@ unsigned int ata_dev_classify(const stru
* RETURNS:
* Device type - %ATA_DEV_ATA, %ATA_DEV_ATAPI or %ATA_DEV_NONE.
*/
-
-unsigned int
-ata_dev_try_classify(struct ata_port *ap, unsigned int device, u8 *r_err)
+unsigned int ata_dev_try_classify(struct ata_device *dev, int present,
+ u8 *r_err)
{
+ struct ata_port *ap = dev-ap;
struct ata_taskfile tf;
unsigned int class;
u8 err;
- ap-ops-dev_select(ap, device);
+ ap-ops-dev_select(ap, dev-devno);
memset(tf, 0, sizeof(tf));
@@ -733,12 +733,12 @@ ata_dev_try_classify(struct ata_port *ap
*r_err = err;
/* see if device passed diags: if master then continue and warn later */
- if (err == 0 device == 0)
+ if (err == 0 dev-devno == 0)
/* diagnostic fail : do nothing _YET_ */
- ap-device[device].horkage |= ATA_HORKAGE_DIAGNOSTIC;
+ dev-horkage |= ATA_HORKAGE_DIAGNOSTIC;
else if (err == 1)
/* do nothing */ ;
- else if ((device == 0) (err == 0x81))
+ else if ((dev-devno == 0) (err == 0x81))
/* do nothing */ ;
else
return ATA_DEV_NONE;
@@ -3176,9 +3176,10 @@ void ata_bus_reset(struct ata_port *ap)
/*
* determine by signature whether we have ATA or ATAPI devices
*/
- ap-device[0].class = ata_dev_try_classify(ap, 0, err);
+ ap-device[0].class = ata_dev_try_classify(ap-device[0], dev0, err);
if ((slave_possible) (err != 0x81))
- ap-device[1].class = ata_dev_try_classify(ap, 1, err);
+ ap-device[1].class = ata_dev_try_classify(ap-device[1],
+ dev1, err);
/* is double-select really necessary? */
if (ap-device[1].class != ATA_DEV_NONE)
@@ -3415,9 +3416,11 @@ int ata_std_softreset(struct ata_port *a
}
/* determine by signature whether we have ATA or ATAPI devices */
- classes[0] = ata_dev_try_classify(ap, 0, err);
+ classes[0] = ata_dev_try_classify(ap-device[0],
+ devmask (1 0), err);
if (slave_possible err != 0x81)
- classes[1] = ata_dev_try_classify(ap, 1, err);
+ classes[1] = ata_dev_try_classify(ap-device[1],
+ devmask (1 1), err);
out:
DPRINTK(EXIT, classes[0]=%u [1]=%u\n, classes[0], classes[1]);
@@ -3535,7 +3538,7 @@ int sata_std_hardreset(struct ata_port *
ap-ops-dev_select(ap, 0); /* probably unnecessary */
- *class = ata_dev_try_classify(ap, 0, NULL);
+ *class = ata_dev_try_classify(ap-device, 1, NULL);
DPRINTK(EXIT, class=%u\n, *class);
return 0;
Index: work/drivers/ata/pata_scc.c
===
--- work.orig/drivers/ata/pata_scc.c
+++ work/drivers/ata/pata_scc.c
@@ -636,9 +636,11 @@ static int scc_std_softreset (struct ata
}
/* determine by signature whether we have ATA or ATAPI devices */
- classes[0] = ata_dev_try_classify(ap, 0, err);
+ classes[0] = ata_dev_try_classify(ap-device[0],
+ devmask (1 0), err);
if (slave_possible err != 0x81)
- classes[1] = ata_dev_try_classify(ap, 1, err);
+ classes[1] = ata_dev_try_classify(ap-device[1],
+ devmask (1 1), err);
out:
DPRINTK(EXIT, classes[0]=%u [1]=%u\n, classes[0], classes[1]);
Index:
