[PATCH -mm] sata_nv: add suspend/resume support
The attached patch is against 2.6.18-rc6-mm1, to be applied on top of
the patch "sata_nv: fix ATAPI in ADMA mode" which Andrew and Jeff
already have in their trees. I've only been able to test this myself by
doing an aborted suspend and immediate resume and verifying it doesn't
blow up in that case (suspend-to-RAM is broken on my box and something
isn't configured properly for suspend-to-disk to work). However, since
resume will definitely not work on some of these controllers without
this patch, I think it's an improvement in any case..
---
This patch adds the necessary callbacks to support suspend/resume
properly in sata_nv. Most of the controllers don't need any specific
handling but CK804/MCP04 controllers, whether ADMA is enabled or not,
need some additional setup on resume.
As well as the additional storage of the controller type needed for
proper resume handling, this also removes the inline helper functions
for getting ADMA register locations by storing the pointers so we don't
have to keep calculating them all the time.
Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>
---
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
--- linux-2.6.19-rc6-mm1-admafixnoresume/drivers/ata/sata_nv.c 2006-11-26
00:53:44.0 -0600
+++ linux-2.6.19-rc6-mm1-admafix/drivers/ata/sata_nv.c 2006-11-29
18:42:17.0 -0600
@@ -49,7 +49,7 @@
#include
#define DRV_NAME "sata_nv"
-#define DRV_VERSION"3.2"
+#define DRV_VERSION"3.3"
#define NV_ADMA_DMA_BOUNDARY 0xUL
@@ -213,12 +213,21 @@ struct nv_adma_port_priv {
dma_addr_t cpb_dma;
struct nv_adma_prd *aprd;
dma_addr_t aprd_dma;
+ void __iomem * ctl_block;
+ void __iomem * gen_block;
+ void __iomem * notifier_clear_block;
u8 flags;
};
+struct nv_host_priv {
+ unsigned long type;
+};
+
#define NV_ADMA_CHECK_INTR(GCTL, PORT) ((GCTL) & ( 1 << (19 + (12 * (PORT)
static int nv_init_one (struct pci_dev *pdev, const struct pci_device_id *ent);
+static void nv_remove_one (struct pci_dev *pdev);
+static int nv_pci_device_resume(struct pci_dev *pdev);
static void nv_ck804_host_stop(struct ata_host *host);
static irqreturn_t nv_generic_interrupt(int irq, void *dev_instance);
static irqreturn_t nv_nf2_interrupt(int irq, void *dev_instance);
@@ -239,6 +248,8 @@ static irqreturn_t nv_adma_interrupt(int
static void nv_adma_irq_clear(struct ata_port *ap);
static int nv_adma_port_start(struct ata_port *ap);
static void nv_adma_port_stop(struct ata_port *ap);
+static int nv_adma_port_suspend(struct ata_port *ap, pm_message_t mesg);
+static int nv_adma_port_resume(struct ata_port *ap);
static void nv_adma_error_handler(struct ata_port *ap);
static void nv_adma_host_stop(struct ata_host *host);
static void nv_adma_bmdma_setup(struct ata_queued_cmd *qc);
@@ -292,7 +303,9 @@ static struct pci_driver nv_pci_driver =
.name = DRV_NAME,
.id_table = nv_pci_tbl,
.probe = nv_init_one,
- .remove = ata_pci_remove_one,
+ .suspend= ata_pci_device_suspend,
+ .resume = nv_pci_device_resume,
+ .remove = nv_remove_one,
};
static struct scsi_host_template nv_sht = {
@@ -311,6 +324,8 @@ static struct scsi_host_template nv_sht
.slave_configure= ata_scsi_slave_config,
.slave_destroy = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
+ .suspend= ata_scsi_device_suspend,
+ .resume = ata_scsi_device_resume,
};
static struct scsi_host_template nv_adma_sht = {
@@ -330,6 +345,8 @@ static struct scsi_host_template nv_adma
.slave_configure= nv_adma_slave_config,
.slave_destroy = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
+ .suspend= ata_scsi_device_suspend,
+ .resume = ata_scsi_device_resume,
};
static const struct ata_port_operations nv_generic_ops = {
@@ -438,6 +455,8 @@ static const struct ata_port_operations
.scr_write = nv_scr_write,
.port_start = nv_adma_port_start,
.port_stop = nv_adma_port_stop,
+ .port_suspend = nv_adma_port_suspend,
+ .port_resume= nv_adma_port_resume,
.host_stop = nv_adma_host_stop,
};
@@ -476,6 +495,7 @@ static struct ata_port_info nv_port_info
{
.sht= &nv_adma_sht,
.flags = ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
+ ATA_FLAG_HRST_TO_RESUM
sata_sil
Hi, I just got a Cardbus / PCMCIA SATA controller using the Silicon Image 3512 chipset. It is not working with my external SATA enclosure housing a WD 250 GB Caviar drive. The first error I see in dmesg is about the cache line size not being set. I tried unloading the sata_sil and libata modules, then "sudo setpci -s 03:00.0 CACHE_LINE_SIZE=08" then reloading them - but I still can't see the drive and I still get the "PIO error" / "failed to IDENTIFY (I/O error)" errors below in the dmesg output. Any ideas? From lspci -v : 03:00.0 Mass storage controller: Silicon Image, Inc. SiI 3512 [SATALink/SATARaid] Serial ATA Controller (rev 01) Subsystem: Silicon Image, Inc. SiI 3512 SATALink Controller Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 11 I/O ports at 4010 [size=8] I/O ports at 4020 [size=4] I/O ports at 4018 [size=8] I/O ports at 4024 [size=4] I/O ports at 4000 [size=16] Memory at 5080 (32-bit, non-prefetchable) [size=512] Expansion ROM at 5040 [disabled] [size=512K] Capabilities: [60] Power Management version 2 From dmesg: libata version 1.20 loaded. sata_sil :03:00.0: version 0.9 PCI: Enabling device :03:00.0 ( -> 0003) ACPI: PCI interrupt :03:00.0[A] -> GSI 11 (level, low) -> IRQ 11 sata_sil :03:00.0: cache line size not set. Driver may not function sata_sil :03:00.0: Applying R_ERR on DMA activate FIS errata fix PCI: Setting latency timer of device :03:00.0 to 64 ata1: SATA max UDMA/100 cmd 0xF8E48080 ctl 0xF8E4808A bmdma 0xF8E48000 irq 11 ata2: SATA max UDMA/100 cmd 0xF8E480C0 ctl 0xF8E480CA bmdma 0xF8E48008 irq 11 ata1: SATA link down (SStatus 0) scsi9 : sata_sil ata2: SATA link up 1.5 Gbps (SStatus 113) ata2: PIO error ata2: dev 0 failed to IDENTIFY (I/O error) scsi10 : sata_sil - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ide_scsi: allow it to be used for non CD only
On 11/29/06, Alan <[EMAIL PROTECTED]> wrote: On Wed, 29 Nov 2006 23:05:56 +0100 "Bartlomiej Zolnierkiewicz" <[EMAIL PROTECTED]> wrote: > Hi, > > Nowadays, you can dynamically change driver bound to a device using > sysfs and it works just fine for IDE, ie: This isn't the point of this change. The point is to do this at discovery time. If you do it later then many horrible things happen as the device then "hdc=ide-cdrom" at a boot time should keep ide-scsi from binding to hdc for all cases (builtin/modular ide-cd/ide-scsi) names and renames itself while udev goes boom. Uh? I hope that udev people are informed about these horrible things... /dev/hdc stays there all the time /dev/sr? addition/removal should be handled by udev otherwise it looks like a udev bug Its a small clean patch and it'll solve the problem nicely until drivers/ide dies. No strong feelings here about the patch. It is indeed a clean hack. ;) I just wanted to point out that there are already more flexible ways to achieve the same thing. Bart - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ide_scsi: allow it to be used for non CD only
On Wed, 29 Nov 2006 23:05:56 +0100 "Bartlomiej Zolnierkiewicz" <[EMAIL PROTECTED]> wrote: > Hi, > > Nowadays, you can dynamically change driver bound to a device using > sysfs and it works just fine for IDE, ie: This isn't the point of this change. The point is to do this at discovery time. If you do it later then many horrible things happen as the device names and renames itself while udev goes boom. Its a small clean patch and it'll solve the problem nicely until drivers/ide dies. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ide_scsi: allow it to be used for non CD only
Hi,
Nowadays, you can dynamically change driver bound to a device using
sysfs and it works just fine for IDE, ie:
echo -n "1.0" > /sys/bus/ide/drivers/ide-scsi/unbind
echo -n "1.0" > /sys/bus/ide/drivers/ide-cdrom/bind
to unbind /dev/hdc from ide-scsi and bind to ide-cdrom
That was one of the main goals behind my old patches to convert
IDE device drivers to device-model.
Please don't add another module parameter for controlling driver binding
and making it more complicated than already is:
* "hdx=scsi" kernel parameter
* "hdx=driver" kernel parameter
* /proc/ide/hd?/driver interface
* ide_cd and "ignore" parameter
(actually all the above can go away).
Bart
On 11/29/06, Alan <[EMAIL PROTECTED]> wrote:
Some people want to use ide_cd for CD-ROM but still dynamically load
ide-scsi for things like tape drives. If you compile in the CD driver
this works out but if you want them modular you need an option to ensure
that whoever loads first the right things happen.
This replaces the original draft patch which leaked a scsi host reference
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --exclude-from /usr/src/exclude --new-file --recursive
linux.vanilla-2.6.19-rc6-mm1/drivers/scsi/ide-scsi.c
linux-2.6.19-rc6-mm1/drivers/scsi/ide-scsi.c
--- linux.vanilla-2.6.19-rc6-mm1/drivers/scsi/ide-scsi.c2006-11-24
13:58:08.0 +
+++ linux-2.6.19-rc6-mm1/drivers/scsi/ide-scsi.c2006-11-29
14:18:12.0 +
@@ -110,6 +110,7 @@
} idescsi_scsi_t;
static DEFINE_MUTEX(idescsi_ref_mutex);
+static int idescsi_nocd; /* Set by module param to skip
cd */
#define ide_scsi_g(disk) \
container_of((disk)->private_data, struct ide_scsi_obj, driver)
@@ -1127,11 +1128,14 @@
warned = 1;
}
+ if (idescsi_nocd && drive->media == ide_cdrom)
+ return -ENODEV;
+
if (!strstr("ide-scsi", drive->driver_req) ||
!drive->present ||
drive->media == ide_disk ||
!(host = scsi_host_alloc(&idescsi_template,sizeof(idescsi_scsi_t
return -ENODEV;
g = alloc_disk(1 << PARTN_BITS);
if (!g)
@@ -1187,6 +1192,7 @@
driver_unregister(&idescsi_driver.gen_driver);
}
+module_param(idescsi_nocd, int, 0600);
module_init(init_idescsi_module);
module_exit(exit_idescsi_module);
MODULE_LICENSE("GPL");
-
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.18 - AHCI detection pauses excessively
Berck E. Nash wrote: Tejun Heo wrote: Then, a series of obsolete STANDBY failures. Who's issuing these commands? It's not libata, libata uses STANDBY (0xe2). Is it some kind of gentoo thing? Nope, Debian/Unstable. Most probably my hdparm utility. It first tries the old STANDBY command, then tries the newer one if the first one fails. This should not cause anybody's system to lock up. Cheers - 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.18 - AHCI detection pauses excessively
Tejun Heo wrote: Hmm... this is difficult. The problem is that everything looks normal until command is issued. My primary suspect still is ahci powering down phy during initialization. Can you please test the attached patch again? No significant difference that I can tell. I've attached the whole log from boot to power-down. That's with both this patch and the previous patch. If you want just one, I can do that as well... Then, a series of obsolete STANDBY failures. Who's issuing these commands? It's not libata, libata uses STANDBY (0xe2). Is it some kind of gentoo thing? Nope, Debian/Unstable. Berck [0.00] Linux version 2.6.19-rc6-mm1 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)) #4 SMP PREEMPT Wed Nov 29 09:40:25 MST 2006 [0.00] Command line: root=/dev/sdc1 ro console=tty0 console=ttyS0,115200n8 BOOT_IMAGE=vmlinuz [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000e4000 - 0010 (reserved) [0.00] BIOS-e820: 0010 - 3ff8 (usable) [0.00] BIOS-e820: 3ff8 - 3ff8e000 (ACPI data) [0.00] BIOS-e820: 3ff8e000 - 3ffe (ACPI NVS) [0.00] BIOS-e820: 3ffe - 4000 (reserved) [0.00] BIOS-e820: ffb0 - 0001 (reserved) [0.00] end_pfn_map = 1048576 [0.00] DMI 2.4 present. [0.00] Zone PFN ranges: [0.00] DMA 0 -> 4096 [0.00] DMA324096 -> 1048576 [0.00] Normal1048576 -> 1048576 [0.00] early_node_map[2] active PFN ranges [0.00] 0:0 -> 159 [0.00] 0: 256 -> 262016 [0.00] ACPI: PM-Timer IO Port: 0x808 [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [0.00] Processor #0 (Bootup-CPU) [0.00] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) [0.00] Processor #1 [0.00] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled) [0.00] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled) [0.00] ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) [0.00] IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [0.00] Setting APIC routing to flat [0.00] ACPI: HPET id: 0x8086a201 base: 0xfed0 [0.00] Using ACPI (MADT) for SMP configuration information [0.00] Nosave address range: 0009f000 - 000a [0.00] Nosave address range: 000a - 000e4000 [0.00] Nosave address range: 000e4000 - 0010 [0.00] Allocating PCI resources starting at 5000 (gap: 4000:bfb0) [0.00] PERCPU: Allocating 32512 bytes of per cpu data [0.00] Built 1 zonelists. Total pages: 257375 [0.00] Kernel command line: root=/dev/sdc1 ro console=tty0 console=ttyS0,115200n8 BOOT_IMAGE=vmlinuz [0.00] Initializing CPU#0 [0.00] PID hash table entries: 4096 (order: 12, 32768 bytes) [ 57.051783] Console: colour VGA+ 80x25 [ 57.314953] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) [ 57.322333] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) [ 57.329293] Checking aperture... [ 57.340073] Memory: 1027700k/1048064k available (2281k kernel code, 19860k reserved, 999k data, 196k init) [ 57.409313] Calibrating delay using timer specific routine.. 5800.15 BogoMIPS (lpj=2900076) [ 57.417779] Mount-cache hash table entries: 256 [ 57.422423] CPU: L1 I cache: 32K, L1 D cache: 32K [ 57.427211] CPU: L2 cache: 2048K [ 57.430763] using mwait in idle threads. [ 57.434721] CPU: Physical Processor ID: 0 [ 57.438764] CPU: Processor Core ID: 0 [ 57.442465] CPU0: Thermal monitoring enabled (TM2) [ 57.447302] Freeing SMP alternatives: 24k freed [ 57.451874] ACPI: Core revision 20060707 [ 57.480782] Using local APIC timer interrupts. [ 57.519735] result 25877174 [ 57.522568] Detected 25.877 MHz APIC timer. [ 57.527253] Booting processor 1/2 APIC 0x1 [ 57.541734] Initializing CPU#1 [ 57.602132] Calibrating delay using timer specific routine.. 5796.48 BogoMIPS (lpj=2898240) [ 57.602137] CPU: L1 I cache: 32K, L1 D cache: 32K [ 57.602138] CPU: L2 cache: 2048K [ 57.602139] CPU: Physical Processor ID: 0 [ 57.602140] CPU: Processor Core ID: 1 [ 57.602144] CPU1: Thermal monitoring enabled (TM2) [ 57.602335] Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz step
Re: Scary Intel SATA errors..
On Wed, 29 Nov 2006 13:25:18 -0500 Mark Lord <[EMAIL PROTECTED]> wrote: > I'm betting that the ata_piix hardware has some kind of internal pipeline that > gets confused *sometimes* when a non-512 multiple passes through. Rarely, > though. It will do this if the FIFO setup is misconfigured. > I wonder if there's something on that device that we could bit-bang to reset > it's internal pipelines? That would cripple performance and just ask for more bizarre bugs. Firstly I think it makes sense to verify/play with the fifo and prefetch setup then verify the problem case and see what Intel think. 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: Scary Intel SATA errors..
Mmmm.. Tejun, here's a clue for what Linus saw on his system: Right now I'm implementing support for READ/WRITE LONG commands via libata. And the ata_piix driver gets into a non-recoverable state after successfully doing a READ LONG command for me, a very similar state to what Linus reported. But the ahci driver does NOT have this problem. I haven't tried others. The thing about R/W LONG, is that they transfer a single PIO sector of data, PLUS an extra 4 (or more) words at the end. Funny thing about ATAPI DVD/RW drives, is that they also transfer odd amounts of data, non-multiples of 512. I'm betting that the ata_piix hardware has some kind of internal pipeline that gets confused *sometimes* when a non-512 multiple passes through. Rarely, though. I wonder if there's something on that device that we could bit-bang to reset it's internal pipelines? Cheers - 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: Scary Intel SATA problem: "frozen"
On Wed, 29 Nov 2006, Tejun Heo wrote: > > You pushed your box really hard and the kernel can't get the memory it wants. > Not really relevant to SATA problem. And it's not even really a bug - the caller is supposed to be ok with it. It's a warning message that the kernel spits out just because we've had problems in the past with callers that did _not_ handle an allocation error gracefully, so the warnign is spit out to (a) let us know something happened and (b) if there's a subsequent oops due to dereferencing a NULL pointer, it becomes easier to pinpoint what the sequence of events was. So it's an atomic allocation that happens on the receive path in the network when you've run out of pages (because you're getting enough network traffic that earlier receives have used up all buffers, and so much disk IO that we haven't had time to clean any new pages yet), and getting an allocation failure there really is "normal", it's just "very unusual". So that particular dump _looks_ scary, but it happens to be totally a non-issue unless something else happens afterwards to imply that the caller had trouble with the allocation failure. It's also a sign of trouble if you can trigger it _easily_. It should be something that only triggers under very high load and under unusual circumstances. Linus - 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
Intel DQ965GF booted
OK OK... it seems to work, I noticed after two days of hacking(?), when I use "all-generic-ide root=5841" param for lilo... I guess LABEL would have been nice if I were using it before mobo crash. And lilo does not know about 5841 so I have to upgrade(?) to grub? -0009fbff : System RAM 0009fc00-0009 : reserved 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000f-000f : System ROM 0010-1ed84fff : System RAM 0010-004d3e40 : Kernel code 004d3e41-005f6a07 : Kernel data 1ed85000-1ed90fff : reserved 1ed91000-1ee36fff : System RAM 1ee37000-1eef1fff : ACPI Non-volatile Storage 1eef2000-1eef3fff : System RAM 1eef4000-1eefefff : ACPI Tables 1eeff000-1eef : System RAM 1ef0-1f7f : reserved 2000-2fff : :00:02.0 3000-300f : PCI Bus #06 3000-30003fff : :06:03.0 30004000-300047ff : :06:03.0 30004000-300047ff : ohci1394 3010-301f : PCI Bus #02 3010-301001ff : :02:00.0 3020-302f : :00:02.0 3030-3031 : :00:19.0 3030-3031 : e1000 3032-30323fff : :00:1b.0 3032-30323fff : ICH HD audio 30324000-30324fff : :00:19.0 30324000-30324fff : e1000 30325000-30325fff : :00:03.3 30326000-303263ff : :00:1d.7 30326000-303263ff : ehci_hcd 30326400-303267ff : :00:1a.7 30326400-303267ff : ehci_hcd 30326800-303268ff : :00:1f.3 30326900-3032690f : :00:03.0 3040-304f : PCI Bus #01 3050-305f : PCI Bus #03 3060-306f : PCI Bus #04 3070-307f : PCI Bus #05 ffe0- : reserved -001f : dma1 0020-0021 : pic1 0040-0043 : timer0 0050-0053 : timer1 0060-006f : keyboard 0070-0077 : rtc 0080-008f : dma page reg 00a0-00a1 : pic2 00c0-00df : dma2 00e1-00e1 : #ENUM hotswap signal register 00f0-00ff : fpu 0378-037a : parport0 03c0-03df : vga+ 03f8-03ff : serial 0cf8-0cff : PCI conf1 1000-1fff : PCI Bus #02 1000-100f : :02:00.0 1000-1007 : ide6 1008-100f : ide7 1010-1017 : :02:00.0 1018-101f : :02:00.0 1018-101f : ide6 1020-1023 : :02:00.0 1024-1027 : :02:00.0 1026-1026 : ide6 2000-201f : :00:1f.3 2000-201f : i801_smbus 2020-203f : :00:1d.2 2020-203f : uhci_hcd 2040-205f : :00:1d.1 2040-205f : uhci_hcd 2060-207f : :00:1d.0 2060-207f : uhci_hcd 2080-209f : :00:1a.1 2080-209f : uhci_hcd 20a0-20bf : :00:1a.0 20a0-20bf : uhci_hcd 20c0-20df : :00:19.0 20c0-20df : e1000 20e0-20ef : :00:1f.5 20f0-20ff : :00:1f.5 20f0-20f7 : ide4 20f8-20ff : ide5 2100-210f : :00:1f.2 2110-211f : :00:1f.2 2110-2117 : ide2 2118-211f : ide3 2120-212f : :00:03.2 2120-2127 : ide0 2128-212f : ide1 2130-2137 : :00:1f.5 2138-213f : :00:1f.5 2150-2157 : :00:03.3 2150-2157 : serial 2158-215f : :00:03.2 2160-2167 : :00:03.2 2168-216f : :00:02.0 2170-2173 : :00:1f.5 2174-2177 : :00:1f.5 2180-2183 : :00:03.2 2184-2187 : :00:03.2 00:00.0 Host bridge: Intel Corporation 82Q963/Q965 Memory Controller Hub (rev 02) Subsystem: Intel Corporation Unknown device 4f43 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [40] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s unlimited, L1 unlimited Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 1 Link: Latency L0s <1us, L1 <4us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x0 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug+ Surpise+ Slot: Number 1, PowerLimit 10.00 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Unknown, PwrInd Unknown, Power- Root: Correctable- Non-Fatal- Fatal- PME- Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable- Address: Data: Capabilities: [90] #0d [] Capabilities: [a0] 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: 86 80 3f 28 07 00 10 00 02 00 04 06 10 00 81 00 10: 00 00 00 00 00 00 00 00 00 01 01 00 f0 00 00 20 20: 40 30 40 30 f1 ff 01 00 00 00 00 00 00 00 00 00 30: 00 00 00 00
Re: pata_via in 2.6.19-rc6: UDMA/66 hdd downgraded to UDMA/33
Does this fix it --- drivers/ata/pata_via.c~ 2006-11-29 15:16:10.961387472 + +++ drivers/ata/pata_via.c 2006-11-29 15:17:08.784597008 + @@ -60,7 +60,7 @@ #include #define DRV_NAME "pata_via" -#define DRV_VERSION "0.2.0" +#define DRV_VERSION "0.2.1" /* * The following comes directly from Vojtech Pavlik's ide/pci/via82cxxx @@ -159,10 +159,13 @@ return -ENOENT; } - if ((config->flags & VIA_UDMA) >= VIA_UDMA_66) + if ((config->flags & VIA_UDMA) >= VIA_UDMA_100) ap->cbl = via_cable_detect(ap); - else + /* The UDMA66 series has no cable detect so do drive side detect */ + else if ((config->flags & VIA_UDMA) < VIA_UDMA_66) ap->cbl = ATA_CBL_PATA40; + + return ata_std_prereset(ap); } - 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] ide_scsi: allow it to be used for non CD only
Some people want to use ide_cd for CD-ROM but still dynamically load
ide-scsi for things like tape drives. If you compile in the CD driver
this works out but if you want them modular you need an option to ensure
that whoever loads first the right things happen.
This replaces the original draft patch which leaked a scsi host reference
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --exclude-from /usr/src/exclude --new-file --recursive
linux.vanilla-2.6.19-rc6-mm1/drivers/scsi/ide-scsi.c
linux-2.6.19-rc6-mm1/drivers/scsi/ide-scsi.c
--- linux.vanilla-2.6.19-rc6-mm1/drivers/scsi/ide-scsi.c2006-11-24
13:58:08.0 +
+++ linux-2.6.19-rc6-mm1/drivers/scsi/ide-scsi.c2006-11-29
14:18:12.0 +
@@ -110,6 +110,7 @@
} idescsi_scsi_t;
static DEFINE_MUTEX(idescsi_ref_mutex);
+static int idescsi_nocd; /* Set by module param to skip
cd */
#define ide_scsi_g(disk) \
container_of((disk)->private_data, struct ide_scsi_obj, driver)
@@ -1127,11 +1128,14 @@
warned = 1;
}
+ if (idescsi_nocd && drive->media == ide_cdrom)
+ return -ENODEV;
+
if (!strstr("ide-scsi", drive->driver_req) ||
!drive->present ||
drive->media == ide_disk ||
!(host = scsi_host_alloc(&idescsi_template,sizeof(idescsi_scsi_t
return -ENODEV;
g = alloc_disk(1 << PARTN_BITS);
if (!g)
@@ -1187,6 +1192,7 @@
driver_unregister(&idescsi_driver.gen_driver);
}
+module_param(idescsi_nocd, int, 0600);
module_init(init_idescsi_module);
module_exit(exit_idescsi_module);
MODULE_LICENSE("GPL");
-
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: Scary Intel SATA problem: "frozen"
Tejun Heo wrote: You pushed your box really hard and the kernel can't get the memory it wants. Not really relevant to SATA problem. ...unless the slowdown is due to extraordinarily high swap activity, because of the low-memory situation.. - 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.18 - AHCI detection pauses excessively
Berck E. Nash wrote:
Tejun Heo wrote:
Yeah, I did and forgot about this thread too. Sorry. This is on the
top of my to-do list now. I'm attaching the patch. TIA.
That didn't fix the problem, but did change the messages. I've attached
the entire log, including the weird errors on power-off from the same
device that gives problems on boot, which I suspect are related.
Hmm... this is difficult. The problem is that everything looks normal
until command is issued. My primary suspect still is ahci powering down
phy during initialization. Can you please test the attached patch again?
[--snip--]
Mounting root filesystem read-only...done.
Will now halt.
[ 9371.896444] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 9371.903036] ata2.00: (irq_stat 0x4001)
[ 9371.907228] ata2.00: cmd e0/00:00:00:00:00/00:00:00:00:00/00 tag 0 data 0 in
[ 9371.907229] res 51/04:00:01:01:80/00:00:00:00:00/a0 Emask 0x1
(device error)
[ 9371.931688] ata2.00: configured for UDMA/133
[ 9371.936073] ata2: EH complete
Weird, the drive is failing STANDBY IMMEDIATE.
[--snip--]
[ 9372.152310] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 9372.158882] ata2.00: (irq_stat 0x4001)
[ 9372.163079] ata2.00: cmd 94/00:00:00:00:00/00:00:00:00:00/00 tag 0 data 0 in
[ 9372.163080] res 51/04:00:01:01:80/00:00:00:00:00/a0 Emask 0x1
(device error)
[ 9372.187505] ata2.00: configured for UDMA/133
Then, a series of obsolete STANDBY failures. Who's issuing these
commands? It's not libata, libata uses STANDBY (0xe2). Is it some kind
of gentoo thing? Anyways, doesn't really matter although it's
surprising that the drive fails STANDBY IMMEDIATE.
Thanks.
--
tejun
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 8f75c60..6100cbc 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -612,9 +612,6 @@ static void ahci_power_down(void __iomem
static void ahci_init_port(void __iomem *port_mmio, u32 cap,
dma_addr_t cmd_slot_dma, dma_addr_t rx_fis_dma)
{
- /* power up */
- ahci_power_up(port_mmio, cap);
-
/* enable FIS reception */
ahci_start_fis_rx(port_mmio, cap, cmd_slot_dma, rx_fis_dma);
@@ -640,9 +637,6 @@ static int ahci_deinit_port(void __iomem
return rc;
}
- /* put device into slumber mode */
- ahci_power_down(port_mmio, cap);
-
return 0;
}
@@ -1321,7 +1315,9 @@ static int ahci_port_suspend(struct ata_
int rc;
rc = ahci_deinit_port(port_mmio, hpriv->cap, &emsg);
- if (rc) {
+ if (rc == 0)
+ ahci_power_down(port_mmio, hpriv->cap);
+ else {
ata_port_printk(ap, KERN_ERR, "%s (%d)\n", emsg, rc);
ahci_init_port(port_mmio, hpriv->cap,
pp->cmd_slot_dma, pp->rx_fis_dma);
@@ -1337,6 +1333,7 @@ static int ahci_port_resume(struct ata_p
void __iomem *mmio = ap->host->mmio_base;
void __iomem *port_mmio = ahci_port_base(mmio, ap->port_no);
+ ahci_power_up(port_mmio, hpriv->cap);
ahci_init_port(port_mmio, hpriv->cap, pp->cmd_slot_dma, pp->rx_fis_dma);
return 0;
@@ -1443,6 +1440,9 @@ static int ahci_port_start(struct ata_po
ap->private_data = pp;
+ /* power up port */
+ ahci_power_up(port_mmio, hpriv->cap);
+
/* initialize port */
ahci_init_port(port_mmio, hpriv->cap, pp->cmd_slot_dma, pp->rx_fis_dma);
