Re: laptop reboots right after hibernation
on., 05.12.2007 kl. 16.46 +0900, skrev Tejun Heo: Kjartan Maraas wrote: fr., 30.11.2007 kl. 19.39 +0900, skrev Tejun Heo: Kjartan Maraas wrote: on., 28.11.2007 kl. 10.09 +0900, skrev Tejun Heo: Kjartan Maraas wrote: I get this exact error message on a normal first time boot here. I'm using the latest fedora development kernel which is 2.6.24-rc2-git6 based. And I have the latest BIOS from HP IIRC. This is an HP nc6400 intel based laptop: Care to post boot dmesg? Or does harddisk detection fail because of this? Here you go. It shows the error two times and then it gets it right and continues to boot. No other problems arise from this that I can see. I'm attaching two patches. Please apply each on top of clean 2.6.24-rc3 and report kernel boot logs for both. I tried to do that but recent kernels hang on boot here after TSC: clocksource installed. Filed a bug here: https://bugzilla.redhat.com/show_bug.cgi?id=405721 but it also happens on the plain rc3 kernel... Can you please give a shot at -rc4 kernel? Sure. It seems the bug above was caused by the compiler and has been fixed in rawhide now so I'll give it a try. Cheers Kjartan - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sata_sil issue on 2.6.22
Tejun Heo wrote: Mark Paulus wrote: Well, I feel foolish. One problem is that the prebuilt kernel is using an initrd image, so I made your patch changes, and put them into /lib/modules/`uname -r`/kernel/drivers/ata/sata_sil.ko, and guess what, they never got loaded. Foolishness on my part. Anyway, this time I got to the single boot prompt, where I did a 'rmmod sata_sil', and a 'modprobe sata_sil', and I know it loaded the new version, because you can see the 'sata_sil :02:0b.0: version 2.2b', which I put in to verify what the heck is going on. This machine is pretty slow to compile the kernel, which is why I was trying to short cut the build/install some, but I might try to build the kernel on a faster machine and see if I can get the initrd image rebuilt also. This one is good enough, thanks. It seems the controller is raising spurious SATA_IRQ. I wonder why. You're using a SATA-PATA bridge, right? What chip are you using? Yes, I am. It's a SD-ADSAIDE-S1, with a sil3611ct80 chip on board. My question would be, what makes the 2.6.22 kernel different enough than the 2.6.18 kernel that this setup is causing problems in .22. Is .18 masking the problems, or is .22 just looking at things with tighter tolerences, so it's more sensitive? -- Mark Paulus 2424 Garden of the Gods Rd | Phone: v622-5578 / 719-535-5578 0419/117 - LEC Access ; D5-1010 | FAX:719-535-1665 Colo Springs, CO 80919| 1800PageMCI / 1406052 AIM : mgpaulus1/ sametime : mark.paulus begin:vcard fn:Mark Paulus n:Paulus;Mark org:MCI;Lec Interfaces / 40419 adr;dom:;;2424 Garden of the Gods Rd;Colorado Springs;CO;80919 email;internet:[EMAIL PROTECTED] title:Mark Paulus tel;work:719-535-5578 tel;pager:800-pagemci / 1406052 tel;home:v622-5578 version:2.1 end:vcard
Re: [PATCH 14/14] libata: use PIO for misc ATAPI commands
Well, if we change that in #upstream now, -mm will receive it and after 2.6.24 is released, it will end up in -rc1. We can change it back if the damage is too grave. Getting it in -rc is going to mess up other testing. It's perfect for -mm testing not -rc testing. Yeah, ALi seems to be genuine driver problem. I don't think using PIO for misc ATAPI commands is extreme considering Windows is doing it. Windows does a lot of things that are bad and ugly workarounds for messes in the past. We have the ability to do a lot better than that. Another thing is check_atapi_dma in sata_promise. It mentions losing interrupt which is exactly what happens if the drive tries to transfer more data but DMA buffer is short on several controllers. I wonder whether this is unnecessary with DMA draining added. Is it like the inic where you must do transfers in specific chunk sizes ? - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sata_sil issue on 2.6.22
Mark Paulus wrote: Well, I feel foolish. One problem is that the prebuilt kernel is using an initrd image, so I made your patch changes, and put them into /lib/modules/`uname -r`/kernel/drivers/ata/sata_sil.ko, and guess what, they never got loaded. Foolishness on my part. Anyway, this time I got to the single boot prompt, where I did a 'rmmod sata_sil', and a 'modprobe sata_sil', and I know it loaded the new version, because you can see the 'sata_sil :02:0b.0: version 2.2b', which I put in to verify what the heck is going on. This machine is pretty slow to compile the kernel, which is why I was trying to short cut the build/install some, but I might try to build the kernel on a faster machine and see if I can get the initrd image rebuilt also. This one is good enough, thanks. It seems the controller is raising spurious SATA_IRQ. I wonder why. You're using a SATA-PATA bridge, right? What chip are you using? -- 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: laptop reboots right after hibernation
on., 05.12.2007 kl. 16.46 +0900, skrev Tejun Heo: Kjartan Maraas wrote: fr., 30.11.2007 kl. 19.39 +0900, skrev Tejun Heo: Kjartan Maraas wrote: on., 28.11.2007 kl. 10.09 +0900, skrev Tejun Heo: Kjartan Maraas wrote: I get this exact error message on a normal first time boot here. I'm using the latest fedora development kernel which is 2.6.24-rc2-git6 based. And I have the latest BIOS from HP IIRC. This is an HP nc6400 intel based laptop: Care to post boot dmesg? Or does harddisk detection fail because of this? Here you go. It shows the error two times and then it gets it right and continues to boot. No other problems arise from this that I can see. I'm attaching two patches. Please apply each on top of clean 2.6.24-rc3 and report kernel boot logs for both. I tried to do that but recent kernels hang on boot here after TSC: clocksource installed. Filed a bug here: https://bugzilla.redhat.com/show_bug.cgi?id=405721 but it also happens on the plain rc3 kernel... Can you please give a shot at -rc4 kernel? Here you go. Cheers Kjartan Initializing cgroup subsys cpuset Linux version 2.6.24-rc4 ([EMAIL PROTECTED]) (gcc version 4.1.2 20071124 (Red Hat 4.1.2-35)) #1 SMP Wed Dec 5 12:18:44 CET 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - bf7d (usable) BIOS-e820: bf7d - bf7e5600 (reserved) BIOS-e820: bf7e5600 - bf7f8000 (ACPI NVS) BIOS-e820: bf7f8000 - bf80 (reserved) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fed2 - fed9b000 (reserved) BIOS-e820: feda - fedc (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ffb0 - ffc0 (reserved) BIOS-e820: fff0 - 0001 (reserved) 2167MB HIGHMEM available. 896MB LOWMEM available. Entering add_active_range(0, 0, 784336) 0 entries of 256 used Zone PFN ranges: DMA 0 - 4096 Normal 4096 - 229376 HighMem229376 - 784336 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 - 784336 On node 0 totalpages: 784336 DMA zone: 56 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4040 pages, LIFO batch:0 Normal zone: 3080 pages used for memmap Normal zone: 00 pages, LIFO batch:31 HighMem zone: 7587 pages used for memmap HighMem zone: 547373 pages, LIFO batch:31 Movable zone: 0 pages used for memmap DMI 2.4 present. Using APIC driver default ACPI: RSDP 000F78B0, 0024 (r2 HP) ACPI: XSDT BF7E57C8, 007C (r1 HPQOEM SLIC-MPC1 HP 1) ACPI: FACP BF7E5684, 00F4 (r4 HP 30AD3 HP 1) ACPI: DSDT BF7E5ACC, FE7B (r1 HP nc64001 MSFT 10E) ACPI: FACS BF7F7E80, 0040 ACPI: SLIC BF7E5844, 0176 (r1 HPQOEM SLIC-MPC1 HP 1) ACPI: HPET BF7E59BC, 0038 (r1 HP 30AD1 HP 1) ACPI: APIC BF7E59F4, 0068 (r1 HP 30AD1 HP 1) ACPI: MCFG BF7E5A5C, 003C (r1 HP 30AD1 HP 1) ACPI: TCPA BF7E5A98, 0032 (r2 HP 30AD1 HP 1) ACPI: SSDT BF7F5947, 0059 (r1 HP HPQNLP1 MSFT 10E) ACPI: SSDT BF7F59A0, 032D (r1 HP HPQSAT1 MSFT 10E) ACPI: SSDT BF7F64E0, 025F (r1 HP Cpu0Tst 3000 INTL 20060317) ACPI: SSDT BF7F673F, 00A6 (r1 HP Cpu1Tst 3000 INTL 20060317) ACPI: SSDT BF7F67E5, 04D7 (r1 HPCpuPm 3000 INTL 20060317) ACPI: PM-Timer IO Port: 0x1008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 6:15 APIC version 20 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 6:15 APIC version 20 ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1]) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 1, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs ACPI: HPET id: 0x8086a201 base: 0xfed0 Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at c000 (gap: bf80:3f40) swsusp: Registered nosave memory region: 0009f000 - 000a swsusp: Registered nosave memory region: 000a - 000e swsusp: Registered nosave memory region: 000e - 0010 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 773613 Kernel command line: ro root=LABEL=/1 rhgb quiet pci=assign-busses
Re: [PATCH 14/14] libata: use PIO for misc ATAPI commands
On Thu, Dec 06, 2007 at 12:13:18AM +0900, Tejun Heo wrote: Alan Cox wrote: It eventually has to end up in -rc. If not for 2.6.25-rc1 is too early, we can put it in #testing and put it into #upstream later. Nobody cares about libata git trees. If you want some initial test coverage put it in -mm. 99% incorrect. #for-testing ends up in #ALL which Andrew always includes in -mm. #upstream also ends up in #ALL but is different in that it will get into mainline when the next -rc1 opens. Jeff, right? 100% correct. 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 v2 1/4] [libata] pata_platform: make probe and remove functions device type neutral
On Tue, Dec 04, 2007 at 08:06:25PM +0300, Anton Vorontsov wrote:
Split pata_platform_{probe,remove} into two pieces:
1. pata_platform_{probe,remove} -- platform_device-dependant bits;
2. __ptata_platform_{probe,remove} -- device type neutral bits.
This is done to not duplicate code for the OF-platform driver.
Paul, do you have any objections regarding that one?
If there is no objections, could you stamp Acked-by on it?
Thus I can resend this set one more time for the merge, w/o
fourth patch.
/**
- * pata_platform_probe - attach a platform interface
- * @pdev: platform device
+ * __pata_platform_probe - attach a platform interface
+ * @dev: device
+ * @io_res: Resource representing I/O base
+ * @ctl_res: Resource representing CTL base
+ * @irq_res: Resource representing IRQ and its flags
+ * @ioport_shift: I/O port shift
+ * @__pio_mask: PIO mask
^^^ added
Thanks,
--
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
-
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
Comments - using the qc_defer hook for serializing controllers ?
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.24-rc3-mm2/drivers/ata/pata_sl82c105.c
linux-2.6.24-rc3-mm2/drivers/ata/pata_sl82c105.c
--- linux.vanilla-2.6.24-rc3-mm2/drivers/ata/pata_sl82c105.c2007-11-30
17:43:24.0 +
+++ linux-2.6.24-rc3-mm2/drivers/ata/pata_sl82c105.c2007-12-05
15:14:42.437347728 +
@@ -26,7 +26,7 @@
#include linux/libata.h
#define DRV_NAME pata_sl82c105
-#define DRV_VERSION 0.3.2
+#define DRV_VERSION 0.3.3
enum {
/*
@@ -206,6 +206,37 @@
sl82c105_set_piomode(ap, qc-dev);
}
+/**
+ * sl82c105_qc_defer - implement serialization
+ * @qc: command
+ *
+ * We must issue one command per host not per channel because
+ * of the reset bug.
+ *
+ * Q: is the scsi host lock sufficient ?
+ */
+
+static int sl82c105_qc_defer(struct ata_queued_cmd *qc)
+{
+ struct ata_host *host = qc-ap-host;
+ int rc;
+
+ /* First apply the usual rules */
+ rc = ata_std_qc_defer(qc);
+ if (rc != 0)
+ return rc;
+
+ /* Now apply serialization rules. Only allow a command if the
+ other channel state machine is idle */
+ if (host-port[0] != qc-ap
+ host-port[0]-hsm_task_state != HSM_ST_IDLE)
+ return ATA_DEFER_PORT;
+ if (host-port[1] != qc-ap
+ host-port[1]-hsm_task_state != HSM_ST_IDLE)
+ return ATA_DEFER_PORT;
+ return 0;
+}
+
static struct scsi_host_template sl82c105_sht = {
.module = THIS_MODULE,
.name = DRV_NAME,
@@ -245,6 +276,7 @@
.bmdma_stop = sl82c105_bmdma_stop,
.bmdma_status = ata_bmdma_status,
+ .qc_defer = sl82c105_qc_defer,
.qc_prep= ata_qc_prep,
.qc_issue = ata_qc_issue_prot,
@@ -312,7 +344,7 @@
};
/* for now use only the first port */
const struct ata_port_info *ppi[] = { info_early,
- ata_dummy_port_info };
+ NULL };
u32 val;
int rev;
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sata_mv: Fix broken Marvell 7042 support.
Hein-Pieter van Braam wrote: I zero'd all the disks, and now they show up as 'new' in the highpoint BIOS again... so, I guess there IS some reserved part somewhere that's accessible with the sata_mv driver. .. Yeah, that's my suspicion too.. they must have just simply moved the metadata to near the end instead of sector-8. Mmm... I'll try a smaller drive here, and zero the entire drive, then reboot with it on the Highpoint board, and then see what sector it modified. This'll take a while. 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: [PATCH 14/14] libata: use PIO for misc ATAPI commands
It eventually has to end up in -rc. If not for 2.6.25-rc1 is too early, we can put it in #testing and put it into #upstream later. Nobody cares about libata git trees. If you want some initial test coverage put it in -mm. primarily worried about. Command type dependent quick fallback might help but ancient controllers are more likely to bring the whole machine down when a DMA transaction goes south. Quite the reverse in my experience - the dumber the controller the more likely that ATAPI DMA and LBA48 and other stuff just works anyway. 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: a question about interrupt of IDE controller( bug 5637)
Hello. Alan Cox wrote: When IDE device works in legacy mode, the IRQ of IDE is fixed at 14/15 for the two channel. But IDE controller is a PCI device, OS will assign an interrupt number for the PCI device in which IDE controller resides. This is realized by calling ide_pci_enable, which will call pcibios_enable_irq. And pcibios_enable_irq should see interrupt in as 0 in that case. It also Should doesn't mean it actually does. I've just looked at my 82801DB configuration, see yourself: [EMAIL PROTECTED] etc]# lspci -x -s 0:1f.1 00:1f.1 IDE interface: Intel Corp. 82801DB ICH4 IDE (rev 02) 00: 86 80 cb 24 07 00 80 02 02 8a 01 01 00 00 00 00 10: 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 20: 01 f0 00 00 00 00 00 20 00 00 00 00 43 10 89 80 30: 00 00 00 00 00 00 00 00 00 00 00 00 09 01 00 00 The controller is in legacy mode (programming i/f is 0x8a), yet it requests IRQ (interrupt pin = 1) and got assigned IRQ9. MBR, Sergei - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/14] libata: use PIO for misc ATAPI commands
Alan Cox wrote: Well, if we change that in #upstream now, -mm will receive it and after 2.6.24 is released, it will end up in -rc1. We can change it back if the damage is too grave. Getting it in -rc is going to mess up other testing. It's perfect for -mm testing not -rc testing. It eventually has to end up in -rc. If not for 2.6.25-rc1 is too early, we can put it in #testing and put it into #upstream later. Yeah, ALi seems to be genuine driver problem. I don't think using PIO for misc ATAPI commands is extreme considering Windows is doing it. Windows does a lot of things that are bad and ugly workarounds for messes in the past. We have the ability to do a lot better than that. I agree. It's double edged sword tho. We're not gonna get much test coverage over those messes of the past and as I said, those are what I'm primarily worried about. Command type dependent quick fallback might help but ancient controllers are more likely to bring the whole machine down when a DMA transaction goes south. Another thing is check_atapi_dma in sata_promise. It mentions losing interrupt which is exactly what happens if the drive tries to transfer more data but DMA buffer is short on several controllers. I wonder whether this is unnecessary with DMA draining added. Is it like the inic where you must do transfers in specific chunk sizes ? I don't think so. It does READ_CD and READ_DVD_STRUCTURE via DMA. The first one isn't 2k aligned the second is of variable size. I think the driver was just working around buggy userland which issues commands like mode sense with longer allocation size than actual buffer size. -- 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 15/15] libata: use PIO for misc ATAPI commands
Private command type / transfer length filtering in sata_promise, pata_it821x and pata_pdc2027x are removed as core layer filtering is more conservative. Signed-off-by: Tejun Heo [EMAIL PROTECTED] NAK same reasons as the three previous times it was posted. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sata_mv: Fix broken Marvell 7042 support.
Mark Lord wrote: Hein-Pieter van Braam wrote: I zero'd all the disks, and now they show up as 'new' in the highpoint BIOS again... so, I guess there IS some reserved part somewhere that's accessible with the sata_mv driver. .. Yeah, that's my suspicion too.. they must have just simply moved the metadata to near the end instead of sector-8. Mmm... I'll try a smaller drive here, and zero the entire drive, then reboot with it on the Highpoint board, and then see what sector it modified. This'll take a while. .. Actually, it doesn't take long at all, with some creative use of fdisk. And I haven't yet figured out their logic, but here's what I've found. They write their RAID metadata near-ish to the end of the drive. On my 320GB drives, it ended up at about -199853 sectors from the end of the drive. I have no idea what logic leads to them choosing such a peculiar location for it. That's NOT an even cylinder or anything else I can figure out. But if you leave the last 100KB of the drive unallocated for any partitions, then your data might survive. This needs more research, and probably another patch of some kind in the driver for #upstream-fixes. I'm busy with a course all week, this won't happen (from me) until the weekend. What a screwy BIOS. -ml - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sata_mv: Fix broken Marvell 7042 support.
Mark Lord wrote: Mark Lord wrote: Hein-Pieter van Braam wrote: I zero'd all the disks, and now they show up as 'new' in the highpoint BIOS again... so, I guess there IS some reserved part somewhere that's accessible with the sata_mv driver. .. Yeah, that's my suspicion too.. they must have just simply moved the metadata to near the end instead of sector-8. Mmm... I'll try a smaller drive here, and zero the entire drive, then reboot with it on the Highpoint board, and then see what sector it modified. This'll take a while. .. Actually, it doesn't take long at all, with some creative use of fdisk. And I haven't yet figured out their logic, but here's what I've found. They write their RAID metadata near-ish to the end of the drive. On my 320GB drives, it ended up at about -199853 sectors from the end of the drive. I have no idea what logic leads to them choosing such a peculiar location for it. .. Correction: Metadata begins at sector -191192 on my drive. That's NOT an even cylinder or anything else I can figure out. But if you leave the last 100KB of the drive unallocated for any partitions, then your data might survive. This needs more research, and probably another patch of some kind in the driver for #upstream-fixes. I'm busy with a course all week, this won't happen (from me) until the weekend. What a screwy BIOS. - 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 14/14] libata: use PIO for misc ATAPI commands
Alan Cox wrote: It eventually has to end up in -rc. If not for 2.6.25-rc1 is too early, we can put it in #testing and put it into #upstream later. Nobody cares about libata git trees. If you want some initial test coverage put it in -mm. #for-testing ends up in #ALL which Andrew always includes in -mm. #upstream also ends up in #ALL but is different in that it will get into mainline when the next -rc1 opens. Jeff, right? -- 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 v2 2/4] [libata] pata_of_platform: OF-Platform PATA device driver
On Wed, Dec 05, 2007 at 09:48:41AM +0900, Paul Mundt wrote: On Tue, Dec 04, 2007 at 02:01:21PM -0600, Olof Johansson wrote: On Tue, Dec 04, 2007 at 10:49:21PM +0300, Anton Vorontsov wrote: tristate Generic platform device PATA support - depends on EMBEDDED || ARCH_RPC + depends on EMBEDDED || ARCH_PPC It needs to be || PPC, not || ARCH_PPC. Wrong. It needs to be EMBEDDED || ARCH_RPC || PPC. Why is it dependent on anything other than platform bus support and ATA? -Scott - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sata_mv: Fix broken Marvell 7042 support.
Mark Lord wrote: To do so, requires that we perhaps do a similar capacity truncation in sata_mv, but only if we see a metadata block at the expected location (because a Legacy mode drive will use the *real* capacity, placing the metadata in the 9th sector instead. Definitely _not_. This is a core Linux maxim: export what the hardware exports, no more no less. We drive the bare metal. OTOH it is quite reasonable to explore auto-loading DM on top of the bare drive, and populating a DM table, if you see that particular BIOS signature or [insert other detection method]. 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: a question about interrupt of IDE controller( bug 5637)
When IDE device works in legacy mode, the IRQ of IDE is fixed at 14/15
for the two channel. But IDE controller is a PCI device, OS will assign
an interrupt number for the PCI device in which IDE controller resides.
This is realized by calling ide_pci_enable, which will call
pcibios_enable_irq.
And pcibios_enable_irq should see interrupt in as 0 in that case. It also
knows about this but it seems the ACPI one doesn't.
I don't have a problem system but this would be my guess as to what we need
--- drivers/acpi/pci_irq.c~ 2007-12-05 14:07:47.389727744 +
+++ drivers/acpi/pci_irq.c 2007-12-05 14:07:47.389727744 +
@@ -429,6 +429,13 @@
polarity, link,
acpi_pci_allocate_irq);
+ if (irq 0) {
+ /* IDE legacy mode controller IRQs are magic. Why do compat
+ extensions always make such a nasty mess */
+ if (dev-class 8 == PCI_CLASS_STORAGE_IDE
+ (dev-class 0x05) == 0)
+ return 0;
+ }
/*
* No IRQ known to the ACPI subsystem - maybe the BIOS /
* driver reported one, then use it. Exit in any 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: sata_sil issue on 2.6.22
Well, I feel foolish. One problem is that the prebuilt kernel is using an initrd image, so I made your patch changes, and put them into /lib/modules/`uname -r`/kernel/drivers/ata/sata_sil.ko, and guess what, they never got loaded. Foolishness on my part. Anyway, this time I got to the single boot prompt, where I did a 'rmmod sata_sil', and a 'modprobe sata_sil', and I know it loaded the new version, because you can see the 'sata_sil :02:0b.0: version 2.2b', which I put in to verify what the heck is going on. This machine is pretty slow to compile the kernel, which is why I was trying to short cut the build/install some, but I might try to build the kernel on a faster machine and see if I can get the initrd image rebuilt also. Tejun Heo wrote: Mark Paulus wrote: I applied the patch, and not much difference. Still the same issue, and here is the new dmesg output. Weird, okay, here's updated patch. Please try this one and report the dmesg. FYI, it won't fix the problem. It's just to find out what's going on. -- Mark Paulus 2424 Garden of the Gods Rd | Phone: v622-5578 / 719-535-5578 0419/117 - LEC Access ; D5-1010 | FAX:719-535-1665 Colo Springs, CO 80919| 1800PageMCI / 1406052 AIM : mgpaulus1/ sametime : mark.paulus Linux version 2.6.22-3-686 (Debian 2.6.22-5~bpo.1) ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Wed Oct 31 16:15:58 UTC 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - 1ffd (usable) BIOS-e820: 1ffd - 1fff (ACPI NVS) BIOS-e820: 1fff - 2000 (usable) BIOS-e820: feea - 0001 (reserved) 0MB HIGHMEM available. 512MB LOWMEM available. found SMP MP-table at 000f9bf0 Entering add_active_range(0, 0, 131072) 0 entries of 256 used Zone PFN ranges: DMA 0 - 4096 Normal 4096 - 131072 HighMem131072 - 131072 early_node_map[1] active PFN ranges 0:0 - 131072 On node 0 totalpages: 131072 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 992 pages used for memmap Normal zone: 125984 pages, LIFO batch:31 HighMem zone: 0 pages used for memmap DMI 2.3 present. ACPI: RSDP 000E0010, 0014 (r0 COMPAQ) ACPI: RSDT 000E0080, 005C (r1 COMPAQ CPQ0005 20020913 0) ACPI: FACP 000E0130, 0074 (r1 COMPAQ SOLANO 1 0) ACPI: DSDT 000E0204, 12F5 (r1 COMPAQ DSDT1 MSFT 10D) ACPI: FACS 000E0040, 0040 ACPI: SSDT 000E14F9, 0174 (r1 COMPAQ CORE_UTL1 MSFT 10D) ACPI: SSDT 000E166D, 0D1C (r1 COMPAQ VILLTBL11 MSFT 10D) ACPI: SSDT 000E33B3, 005D (r1 COMPAQ FHUB1 MSFT 10D) ACPI: APIC 000E01A4, 0060 (r1 COMPAQ SOLANO 1 0) ACPI: SSDT 000E333D, 0076 (r1 COMPAQ APIC1 MSFT 10D) ACPI: SSDT 000E2389, 06AD (r1 COMPAQ PNP_PRSS1 MSFT 10D) ACPI: SSDT 000E2A94, 01A4 (r1 COMPAQ S31 MSFT 10D) ACPI: SSDT 000E2C38, 0158 (r1 COMPAQ PIDETM1 MSFT 10D) ACPI: SSDT 000E2EED, 010B (r1 COMPAQ GTF01 MSFT 10D) ACPI: SSDT 000E2FF8, 0117 (r1 COMPAQ GTF11 MSFT 10D) ACPI: SSDT 000E2D90, 015D (r1 COMPAQ SIDETM1 MSFT 10D) ACPI: SSDT 000E310F, 0117 (r1 COMPAQ GTF21 MSFT 10D) ACPI: SSDT 000E349B, 004E (r1 COMPAQFINIS1 MSFT 10D) ACPI: PM-Timer IO Port: 0xf808 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 6:8 APIC version 17 ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1]) ACPI: IOAPIC (id[0x08] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 8, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 3000 (gap: 2000:deea) Built 1 zonelists. Total pages: 130048 Kernel command line: root=/dev/hda1 ro mapped APIC to d000 (fee0) mapped IOAPIC to c000 (fec0) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 2048 (order: 11, 8192 bytes) Detected 996.822 MHz processor. Console: colour VGA+ 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 510088k/524288k available (1689k kernel code, 13380k reserved, 648k
Re: [PATCH 14/14] libata: use PIO for misc ATAPI commands
Alan Cox wrote: This is about time we make decision on this. If we're gonna go I thought everyone but you had made a decision ;) Hey, at least Mark was loosely on my side! 8-P DMA-for-everything way, we should lift 16 byte default masking for -mm and -rc's as that only makes debugging difficult and try to blacklist offending devices and controllers individually. Would be a useful experiment for -mm not really I think for -rc. Well, if we change that in #upstream now, -mm will receive it and after 2.6.24 is released, it will end up in -rc1. We can change it back if the damage is too grave. My primary concern is about not achieving enough test coverage and isolated cases where it's difficult to tell whether it's the device or the controller. e.g. Loading recent distro on an ancient and/or strange machine, scratching head while cursing and giving up. Watching the Fedora bugzilla I don't see things that match up to your descriptions and fixes. Indeed I've now got verification that the weird ALi ATAPI problem a few people have isn't even fixed by your extreme changes. Yeah, ALi seems to be genuine driver problem. I don't think using PIO for misc ATAPI commands is extreme considering Windows is doing it. Another thing is check_atapi_dma in sata_promise. It mentions losing interrupt which is exactly what happens if the drive tries to transfer more data but DMA buffer is short on several controllers. I wonder whether this is unnecessary with DMA draining added. 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 27/28] blk_end_request: changing scsi mid-layer for bidi (take 3)
Hi Boaz,
On Tue, 04 Dec 2007 15:39:12 +0200, Boaz Harrosh [EMAIL PROTECTED] wrote:
On Sat, Dec 01 2007 at 1:35 +0200, Kiyoshi Ueda [EMAIL PROTECTED] wrote:
This patch converts bidi of scsi mid-layer to use blk_end_request().
rq-next_rq represents a pair of bidi requests.
(There are no other use of 'next_rq' of struct request.)
For both requests in the pair, end_that_request_chunk() should be
called before end_that_request_last() is called for one of them.
Since the calls to end_that_request_first()/chunk() and
end_that_request_last() are packaged into blk_end_request(),
the handling of next_rq completion has to be moved into
blk_end_request(), too.
Bidi sets its specific value to rq-data_len before the request is
completed so that upper-layer can read it.
This setting must be between end_that_request_chunk() and
end_that_request_last(), because rq-data_len may be used
in end_that_request_chunk() by blk_trace and so on.
To satisfy the requirement, use blk_end_request_callback() which
is added in PATCH 25 only for the tricky drivers.
If bidi didn't reuse rq-data_len and added new members to request
for the specific value, it could set before end_that_request_chunk()
and use the standard blk_end_request() like below.
void scsi_end_bidi_request(struct scsi_cmnd *cmd)
{
struct request *req = cmd-request;
rq-resid = scsi_out(cmd)-resid;
rq-next_rq-resid = scsi_in(cmd)-resid;
if (blk_end_request(req, 1, req-data_len))
BUG();
scsi_release_buffers(cmd);
scsi_next_command(cmd);
}
...
snip
...
rq-data_len = scsi_out(cmd)-resid is Not Just a problem of bidi
it is a General problem of scsi residual handling, and user code.
Even today before any bidi. at scsi_lib.c at scsi_io_completion()
we do req-data_len = scsi_get_resid(cmd);
( or: req-data_len = cmd-resid; depends which version you look)
And then call scsi_end_request() which calls __end_that_request_first/last
So it is assumed even today that req-data_len is not touched by
__end_that_request_first/last unless __end_that_request_first returned
that there is more work to do and the command is resubmitted in which
case the resid information is discarded.
So if the regular resid handling is acceptable - Set req-data_len
before the call to __end_that_request_first/last, or blk_end_request()
in your case, then here goes your second client of the _callback and
it can be removed.
But if it is found that req-data_len is touched and the resid information
gets lost, than it should be fixed for the common uni-io case, by - for
example
- pass resid to the blk_end_request() function.
(So in any way the _callback can go)
Thank you for the explanation of scsi's rq-data_len usage.
I see that scsi usually uses rq-data_len for cmd-resid.
I have investigated the possibility of setting data_len before
the call to blk_end_request.
But no matter whether data_len is touched or not, we need a callback
for bidi. So I would like to go with the current patch.
I explained the reason and some details below.
As far as I can see, rq-data_len is just referenced
by blk_add_trace_rq() in __end_that_request_first(), not modified.
And I don't change any logic around there in the block-layer.
So there shouldn't be any critical problem for scsi residual handing.
(although I'm not sure that scsi expectes cmd-resid to be traced
by blk_trace.)
Anyway, I see that it is no critical problem for bidi to set cmd-resid
to rq-data_len before blk_end_request() call.
But if I do that, blk_end_request() can't get the next_rq's size
to complete in its code below.
+ /* Bidi request must be completed as a whole */
+ if (blk_bidi_rq(rq)
+ __end_that_request_first(rq-next_rq, uptodate,
+ blk_rq_bytes(rq-next_rq)))
+ return 1;
So I will have to move next_rq completion to bidi and use _callback()
anyway like the following.
-
static int dummy_cb(struct request *rq)
{
return 1;
}
void scsi_end_bidi_request(struct scsi_cmnd *cmd)
{
struct request *req = cmd-request;
unsigned int dlen = req-data_len;
unsigned int next_dlen = req-next_rq-data_len;
req-data_len = scsi_out(cmd)-resid;
req-next_rq-data_len = scsi_in(cmd)-resid;
/* Complete only DATA of next_rq using _callback and dummy function */
if (!blk_end_request_callback(req-next_rq, 1, next_dlen, dummy_cb))
BUG();
if (blk_end_request(req, 1, dlen))
BUG();
scsi_release_buffers(cmd);
scsi_next_command(cmd);
}
-
I prefer the current patch rather than the code like above,
since the code calls blk_end_request twice and looks trickier.
So I'd like to leave the
Re: a question about interrupt of IDE controller( bug 5637)
On Wed, 2007-12-05 at 14:18 +, Alan Cox wrote:
When IDE device works in legacy mode, the IRQ of IDE is fixed at 14/15
for the two channel. But IDE controller is a PCI device, OS will assign
an interrupt number for the PCI device in which IDE controller resides.
This is realized by calling ide_pci_enable, which will call
pcibios_enable_irq.
And pcibios_enable_irq should see interrupt in as 0 in that case. It also
knows about this but it seems the ACPI one doesn't.
I don't have a problem system but this would be my guess as to what we need
--- drivers/acpi/pci_irq.c~ 2007-12-05 14:07:47.389727744 +
+++ drivers/acpi/pci_irq.c2007-12-05 14:07:47.389727744 +
@@ -429,6 +429,13 @@
polarity, link,
acpi_pci_allocate_irq);
+ if (irq 0) {
+ /* IDE legacy mode controller IRQs are magic. Why do compat
+extensions always make such a nasty mess */
+ if (dev-class 8 == PCI_CLASS_STORAGE_IDE
+ (dev-class 0x05) == 0)
+ return 0;
+ }
/*
* No IRQ known to the ACPI subsystem - maybe the BIOS /
* driver reported one, then use it. Exit in any case.
The above patch can fix the issue in bug 5637. But if the interrupt of
other PCI device is routed to 14/15, this patch won't fix it.
Thanks.
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sata_sil issue on 2.6.22
Mark Paulus wrote: Yes, I am. It's a SD-ADSAIDE-S1, with a sil3611ct80 chip on board. My question would be, what makes the 2.6.22 kernel different enough than the 2.6.18 kernel that this setup is causing problems in .22. Is .18 masking the problems, or is .22 just looking at things with tighter tolerences, so it's more sensitive? That's to be investigated. There's another report of similar problem. Can you please add yourself to the following bugzilla and add your log there? http://bugzilla.kernel.org/show_bug.cgi?id=9505 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 01/28] blk_end_request: add new request completion interface (take 3)
On Tue, Dec 04 2007, Kiyoshi Ueda wrote: Hi Boaz and Jens, On Tue, 04 Dec 2007 15:56:32 +0200, Boaz Harrosh [EMAIL PROTECTED] wrote: +/** + * blk_end_request - Helper function for drivers to complete the request. + * @rq: the request being processed + * @uptodate: 1 for success, 0 for I/O error, 0 for specific error + * @nr_bytes: number of bytes to complete + * + * Description: + * Ends I/O on a number of bytes attached to @rq. + * If @rq has leftover, sets it up for the next range of segments. + * + * Return: + * 0 - we are done with this request + * 1 - still buffers pending for this request + **/ +int blk_end_request(struct request *rq, int uptodate, int nr_bytes) I always hated that uptodate boolean with possible negative error value. I guess it was done for backward compatibility of then users of end_that_request_first(). But since you are introducing a new API then this is not the case. Just have regular status int where 0 means ALL_OK and negative value means error code. Just my $0.02. Thank you for the comment. I think it's quite reasonable. By doing that, we don't need end_io_error() anymore. Jens, What do you think? I agree, the uptodate usage right now is horrible. If you agree with the interface change above, I would prefer to separate the patch-set from blk_end_request patch-set like below: o blk_end_request: remove end_that_request_* o change interface of 'uptodate' in blk_end_request to 'error' It makes the purpose of blk_end_request patch-set clear (and also, each patch of device drivers could be smaller). But, it doubles your merging work. So if you would like to get the changes at once, I'll merge them into blk_end_request patch-set. Twice the merging is not an issue for me. As for the patch inclusion, do you push the driver changes to Linus all at once? Or should I ask each maintainer to take the patch? Lets just try to get as many maintainer acks as possible, since the patches need to go in together. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sata_mv: Fix broken Marvell 7042 support.
Mark Lord wrote: ... Yeah, that's my suspicion too.. they must have just simply moved the metadata to near the end instead of sector-8. ... They write their RAID metadata near-ish to the end of the drive. On my 320GB drives, it ended up at about -199853 sectors from the end of the drive. I have no idea what logic leads to them choosing such a peculiar location for it. .. Correction: Metadata begins at sector -191192 on my drive. ... Okay, I figured it out. The final sector on the drive is at 625142448, which in hex is sector 0x2542eab0. The metadata on this drive is at sector 624951296, which in hex is sector 0x2540. Note that this corresponds to a nice round giga-byte value. So their RAID BIOS is just truncating the drive capacity down to an even gigabyte, and then putting the metadata right after that. I don't know what they might do with a drive whose capacity is exactly some gigabyte value, though -- probably they just subtract a gigabyte from that, to make room for the metadata. So.. I do want to make this board usable under Linux. To do so, requires that we perhaps do a similar capacity truncation in sata_mv, but only if we see a metadata block at the expected location (because a Legacy mode drive will use the *real* capacity, placing the metadata in the 9th sector instead. Jeff / Tejun / Alan: What do you think we (I) should do here? 0. Initially, we need to further beef-up the recently added boot-time warning about data-loss. Again, the BIOS will have *already* written metadata to the drive before we ever get to warn about it. We cannot prevent it, but we should at least warn the user about this absurdity. It would also be useful to print the max usable capacity as part of this warning (based on the calculation below). Now we have a choice as to what else to do: 1. Just clip the drive capacity similar to how the BIOS does it. clipped_sectors = ((physical_sectors - 1) ~0x000f); OR: 2. Check for the Highpoint BIOS signature at the metadata sector first, and only clip capacity if we see their signature there. OR: 3. Don't clip, but printk() WARNINGs whenever a write is performed to data beyond the theoretical clipped capacity. OR: 4. Something better (?). ? - 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: a question about interrupt of IDE controller( bug 5637)
On Wed, 2007-12-05 at 14:18 +, Alan Cox wrote:
When IDE device works in legacy mode, the IRQ of IDE is fixed at 14/15
for the two channel. But IDE controller is a PCI device, OS will assign
an interrupt number for the PCI device in which IDE controller resides.
This is realized by calling ide_pci_enable, which will call
pcibios_enable_irq.
And pcibios_enable_irq should see interrupt in as 0 in that case. It also
knows about this but it seems the ACPI one doesn't.
I don't have a problem system but this would be my guess as to what we need
--- drivers/acpi/pci_irq.c~ 2007-12-05 14:07:47.389727744 +
+++ drivers/acpi/pci_irq.c2007-12-05 14:07:47.389727744 +
@@ -429,6 +429,13 @@
polarity, link,
acpi_pci_allocate_irq);
+ if (irq 0) {
+ /* IDE legacy mode controller IRQs are magic. Why do compat
+extensions always make such a nasty mess */
+ if (dev-class 8 == PCI_CLASS_STORAGE_IDE
+ (dev-class 0x05) == 0)
+ return 0;
+ }
/*
* No IRQ known to the ACPI subsystem - maybe the BIOS /
* driver reported one, then use it. Exit in any case.
The above patch can fix the issue in Bug5637. But if IDE controller
works in legcay mode and PRT tells us the interrupt for some PCI devices
is 14/15, should we make it pci-like interrupt(level trigger, low
active)?
Thanks.
-
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] [libata] sata_mv: Remove PCI dependency
On 12/2/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
From: Saeed Bishara [EMAIL PROTECTED]
The integrated SATA controller is connected directly to the SoC's
internal bus, not via PCI interface. this patch removes the dependency
on the PCI interface.
Signed-off-by: Saeed Bishara [EMAIL PROTECTED]
---
drivers/ata/Kconfig |2 +-
drivers/ata/sata_mv.c | 113
++---
2 files changed, 71 insertions(+), 44 deletions(-)
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index ba63619..c60842b 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -69,7 +69,7 @@ config ATA_PIIX
config SATA_MV
tristate Marvell SATA support (HIGHLY EXPERIMENTAL)
- depends on PCI EXPERIMENTAL
+ depends on EXPERIMENTAL
help
This option enables support for the Marvell Serial ATA family.
Currently supports 88SX[56]0[48][01] chips.
diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index 97c3e11..cbd3f1b 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -421,7 +421,9 @@ static void mv_error_handler(struct ata_port *ap);
static void mv_post_int_cmd(struct ata_queued_cmd *qc);
static void mv_eh_freeze(struct ata_port *ap);
static void mv_eh_thaw(struct ata_port *ap);
+#ifdef CONFIG_PCI
static int mv_init_one(struct pci_dev *pdev, const struct pci_device_id
*ent);
+#endif
static void mv5_phy_errata(struct mv_host_priv *hpriv, void __iomem *mmio,
unsigned int port);
@@ -638,14 +640,14 @@ static const struct pci_device_id mv_pci_tbl[] = {
{ } /* terminate list */
};
-
+#ifdef CONFIG_PCI
static struct pci_driver mv_pci_driver = {
.name = DRV_NAME,
.id_table = mv_pci_tbl,
.probe = mv_init_one,
.remove = ata_pci_remove_one,
};
-
+#endif
static const struct mv_hw_ops mv5xxx_ops = {
.phy_errata = mv5_phy_errata,
.enable_leds= mv5_enable_leds,
@@ -665,45 +667,6 @@ static const struct mv_hw_ops mv6xxx_ops = {
};
/*
- * module options
- */
-static int msi;/* Use PCI msi; either zero (off, default) or
non-zero */
-
-
-/* move to PCI layer or libata core? */
-static int pci_go_64(struct pci_dev *pdev)
-{
- int rc;
-
- if (!pci_set_dma_mask(pdev, DMA_64BIT_MASK)) {
- rc = pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
- if (rc) {
- rc = pci_set_consistent_dma_mask(pdev, DMA_32BIT_MASK);
- if (rc) {
- dev_printk(KERN_ERR, pdev-dev,
-64-bit DMA enable failed\n);
- return rc;
- }
- }
- } else {
- rc = pci_set_dma_mask(pdev, DMA_32BIT_MASK);
- if (rc) {
- dev_printk(KERN_ERR, pdev-dev,
-32-bit DMA enable failed\n);
- return rc;
- }
- rc = pci_set_consistent_dma_mask(pdev, DMA_32BIT_MASK);
- if (rc) {
- dev_printk(KERN_ERR, pdev-dev,
-32-bit consistent DMA enable failed\n);
- return rc;
- }
- }
-
- return rc;
-}
-
-/*
* Functions
*/
@@ -2578,8 +2541,10 @@ static int mv_init_host(struct ata_host *host,
unsigned int board_idx)
mv_port_init(ap-ioaddr, port_mmio);
+#ifdef CONFIG_PCI
ata_port_pbar_desc(ap, MV_PRIMARY_BAR, -1, mmio);
ata_port_pbar_desc(ap, MV_PRIMARY_BAR, offset, port);
+#endif
}
for (hc = 0; hc n_hc; hc++) {
@@ -2616,6 +2581,47 @@ done:
return rc;
}
+#ifdef CONFIG_PCI
+
+/*
+ * module options
+ */
+static int msi;/* Use PCI msi; either zero (off, default) or
non-zero */
+
+
+/* move to PCI layer or libata core? */
+static int pci_go_64(struct pci_dev *pdev)
+{
+ int rc;
+
+ if (!pci_set_dma_mask(pdev, DMA_64BIT_MASK)) {
+ rc = pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
+ if (rc) {
+ rc = pci_set_consistent_dma_mask(pdev, DMA_32BIT_MASK);
+ if (rc) {
+ dev_printk(KERN_ERR, pdev-dev,
+64-bit DMA enable failed\n);
+ return rc;
+ }
+ }
+ } else {
+ rc = pci_set_dma_mask(pdev, DMA_32BIT_MASK);
+ if (rc) {
+ dev_printk(KERN_ERR, pdev-dev,
+32-bit DMA enable failed\n);
+ return rc;
+ }
+ rc = pci_set_consistent_dma_mask(pdev, DMA_32BIT_MASK);
+ if
Hard drives only detected when booting from CD on nVidia MCP67 SATA
With kernel 2.6.23 on an Acer 7220 notebook using nVidia MCP67 SATA, hard drives are only detected after first booting from a CD. Boot from hard drive No drives detected Boot live CD Detected Boot CD to GRUB menu, Detected then warm-boot from hard drive Non-detect case: ahci :00:09.0: version 2.3 ACPI: PCI Interrupt Link [LSI0] enabled at IRQ 23 ACPI: PCI Interrupt :00:09.0[A] - Link [LSI0] - GSI 23 (level, low) - IRQ 16 input: ImPS/2 Generic Wheel Mouse as /class/input/input2 ahci :00:09.0: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl IDE mode ahci :00:09.0: flags: 64bit sntf led clo pmp pio slum part PCI: Setting latency timer of device :00:09.0 to 64 scsi0 : ahci scsi1 : ahci scsi2 : ahci scsi3 : ahci ata1: SATA max UDMA/133 cmd 0xf8854100 ctl 0x bmdma 0x irq 221 ata2: SATA max UDMA/133 cmd 0xf8854180 ctl 0x bmdma 0x irq 221 ata3: SATA max UDMA/133 cmd 0xf8854200 ctl 0x bmdma 0x irq 221 ata4: SATA max UDMA/133 cmd 0xf8854280 ctl 0x bmdma 0x irq 221 ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata2: SATA link down (SStatus 0 SControl 300) ata3: SATA link down (SStatus 0 SControl 300) ata4: SATA link down (SStatus 0 SControl 300) Waiting for driver initialization But, if a LiveCD is used to boot or if a LiveCD was used before an hot reboot (without a power off), disks are correctly found : Loading ahci.ko ahci :00:09.0: version 2.3 ACPI: PCI Interrupt Link [LSI0] enabled at IRQ 23 ACPI: PCI Interrupt :00:09.0[A] - Link [LSI0] - GSI 23 (level, low) - IRQ 16 input: ImPS/2 Generic Wheel Mouse as /class/input/input2 ahci :00:09.0: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl IDE mode ahci :00:09.0: flags: 64bit sntf led clo pmp pio slum part PCI: Setting latency timer of device :00:09.0 to 64 scsi0 : ahci scsi1 : ahci scsi2 : ahci scsi3 : ahci ata1: SATA max UDMA/133 cmd 0xf8854100 ctl 0x bmdma 0x irq 221 ata2: SATA max UDMA/133 cmd 0xf8854180 ctl 0x bmdma 0x irq 221 ata3: SATA max UDMA/133 cmd 0xf8854200 ctl 0x bmdma 0x irq 221 ata4: SATA max UDMA/133 cmd 0xf8854280 ctl 0x bmdma 0x irq 221 ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: ATA-7: Hitachi HTS541612J9SA00, SBDOC70P, max UDMA/100 ata1.00: 234441648 sectors, multi 16: LBA48 NCQ (depth 0/32) ata1.00: configured for UDMA/100 ata2: SATA link down (SStatus 0 SControl 300) ata3: SATA link down (SStatus 0 SControl 300) ata4: SATA link down (SStatus 0 SControl 300) https://bugzilla.redhat.com/show_bug.cgi?id=411171 - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sata_sil issue on 2.6.22
Tejun Heo wrote:
Mark Paulus wrote:
Yes, I am. It's a SD-ADSAIDE-S1, with a sil3611ct80 chip on board.
My question would be, what makes the 2.6.22 kernel different enough
than the 2.6.18 kernel that this setup is causing problems in .22.
Is .18 masking the problems, or is .22 just looking at things with
tighter tolerences, so it's more sensitive?
That's to be investigated. There's another report of similar problem.
Can you please add yourself to the following bugzilla and add your log
there?
http://bugzilla.kernel.org/show_bug.cgi?id=9505
In case you don't like bugzilla, I'm attaching proposed patch here too.
Please test the attached patch and report whether it fixes the problem.
Thanks.
--
tejun
Index: work/drivers/ata/sata_sil.c
===
--- work.orig/drivers/ata/sata_sil.c
+++ work/drivers/ata/sata_sil.c
@@ -390,23 +390,19 @@ static void sil_host_intr(struct ata_por
sil_scr_read(ap, SCR_ERROR, serror);
sil_scr_write(ap, SCR_ERROR, serror);
- /* Trigger hotplug and accumulate SError only if the
- * port isn't already frozen. Otherwise, PHY events
- * during hardreset makes controllers with broken SIEN
- * repeat probing needlessly.
+ /* Sometimes spurious interrupts occur, double check
+ * it's PHYRDY CHG.
*/
- if (!(ap-pflags ATA_PFLAG_FROZEN)) {
- ata_ehi_hotplugged(ap-link.eh_info);
+ if (serror SERR_PHYRDY_CHG) {
ap-link.eh_info.serror |= serror;
+ goto freeze;
}
- goto freeze;
+ if (!(bmdma2 SIL_DMA_COMPLETE))
+ return;
}
- if (unlikely(!qc))
- goto freeze;
-
- if (unlikely(qc-tf.flags ATA_TFLAG_POLLING)) {
+ if (unlikely(!qc || (qc-tf.flags ATA_TFLAG_POLLING))) {
/* this sometimes happens, just clear IRQ */
ata_chk_status(ap);
return;
Index: work/drivers/ata/libata-core.c
===
--- work.orig/drivers/ata/libata-core.c
+++ work/drivers/ata/libata-core.c
@@ -3923,6 +3923,7 @@ void ata_std_postreset(struct ata_link *
/* clear SError */
if (sata_scr_read(link, SCR_ERROR, serror) == 0)
sata_scr_write(link, SCR_ERROR, serror);
+ link-eh_info.serror = 0;
/* is double-select really necessary? */
if (classes[0] != ATA_DEV_NONE)
Re: a question about interrupt of IDE controller( bug 5637)
The above patch can fix the issue in Bug5637. But if IDE controller works in legcay mode and PRT tells us the interrupt for some PCI devices is 14/15, should we make it pci-like interrupt(level trigger, low active)? If that occurs the BIOS is broken. 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: laptop reboots right after hibernation
Thanks. Almost there. Can you please try the attached two patches and
report the boot log?
--
tejun
Index: work/include/linux/libata.h
===
--- work.orig/include/linux/libata.h
+++ work/include/linux/libata.h
@@ -1013,18 +1013,18 @@ extern void ata_do_eh(struct ata_port *a
* printk helpers
*/
#define ata_port_printk(ap, lv, fmt, args...) \
- printk(lvata%u: fmt, (ap)-print_id , ##args)
+ printk(%sata%u: fmt, lv, (ap)-print_id , ##args)
#define ata_link_printk(link, lv, fmt, args...) do { \
if ((link)-ap-nr_pmp_links) \
- printk(lvata%u.%02u: fmt, (link)-ap-print_id, \
+ printk(%sata%u.%02u: fmt, lv, (link)-ap-print_id, \
(link)-pmp , ##args); \
else \
- printk(lvata%u: fmt, (link)-ap-print_id , ##args); \
+ printk(%sata%u: fmt, lv, (link)-ap-print_id , ##args); \
} while(0)
#define ata_dev_printk(dev, lv, fmt, args...) \
- printk(lvata%u.%02u: fmt, (dev)-link-ap-print_id, \
+ printk(%sata%u.%02u: fmt, lv, (dev)-link-ap-print_id, \
(dev)-link-pmp + (dev)-devno , ##args)
/*
Index: work/include/linux/ata.h
===
--- work.orig/include/linux/ata.h
+++ work/include/linux/ata.h
@@ -190,6 +190,8 @@ enum {
ATA_CMD_READ_LOG_EXT = 0x2f,
ATA_CMD_PMP_READ = 0xE4,
ATA_CMD_PMP_WRITE = 0xE8,
+ ATA_CMD_CONF_OVERLAY = 0xB1,
+ ATA_CMD_SEC_FREEZE_LOCK = 0xF5,
/* READ_LOG_EXT pages */
ATA_LOG_SATA_NCQ = 0x10,
@@ -239,6 +241,19 @@ enum {
SATA_AN = 0x05, /* Asynchronous Notification */
SATA_DIPM = 0x03, /* Device Initiated Power Management */
+ /* feature values for SET_MAX */
+ ATA_SET_MAX_ADDR = 0x00,
+ ATA_SET_MAX_PASSWD = 0x01,
+ ATA_SET_MAX_LOCK = 0x02,
+ ATA_SET_MAX_UNLOCK = 0x03,
+ ATA_SET_MAX_FREEZE_LOCK = 0x04,
+
+ /* feature values for DEVICE CONFIGURATION OVERLAY */
+ ATA_DCO_RESTORE = 0xC0,
+ ATA_DCO_FREEZE_LOCK = 0xC1,
+ ATA_DCO_IDENTIFY = 0xC2,
+ ATA_DCO_SET = 0xC3,
+
/* ATAPI stuff */
ATAPI_PKT_DMA = (1 0),
ATAPI_DMADIR = (1 2), /* ATAPI data dir:
Index: work/drivers/ata/libata-acpi.c
===
--- work.orig/drivers/ata/libata-acpi.c
+++ work/drivers/ata/libata-acpi.c
@@ -311,8 +311,8 @@ EXPORT_SYMBOL_GPL(ata_acpi_stm);
* EH context.
*
* RETURNS:
- * Number of taskfiles on success, 0 if _GTF doesn't exist or doesn't
- * contain valid data.
+ * Number of taskfiles on success, 0 if _GTF doesn't exist. -EINVAL
+ * if _GTF is invalid.
*/
static int ata_dev_get_GTF(struct ata_device *dev, struct ata_acpi_gtf **gtf,
void **ptr_to_free)
@@ -339,6 +339,7 @@ static int ata_dev_get_GTF(struct ata_de
ata_dev_printk(dev, KERN_WARNING,
_GTF evaluation failed (AE 0x%x)\n,
status);
+ rc = -EINVAL;
}
goto out_free;
}
@@ -350,6 +351,7 @@ static int ata_dev_get_GTF(struct ata_de
__FUNCTION__,
(unsigned long long)output.length,
output.pointer);
+ rc = -EINVAL;
goto out_free;
}
@@ -358,6 +360,7 @@ static int ata_dev_get_GTF(struct ata_de
ata_dev_printk(dev, KERN_WARNING,
_GTF unexpected object type 0x%x\n,
out_obj-type);
+ rc = -EINVAL;
goto out_free;
}
@@ -365,6 +368,7 @@ static int ata_dev_get_GTF(struct ata_de
ata_dev_printk(dev, KERN_WARNING,
unexpected _GTF length (%d)\n,
out_obj-buffer.length);
+ rc = -EINVAL;
goto out_free;
}
@@ -397,7 +401,7 @@ int ata_acpi_cbl_80wire(struct ata_port
int valid = 0;
/* No _GTM data, no information */
- if (ata_acpi_gtm(ap, gtm) 0)
+ if (!ap-acpi_handle || ata_acpi_gtm(ap, gtm) 0)
return 0;
/* Split timing, DMA enabled */
@@ -422,7 +426,7 @@ int ata_acpi_cbl_80wire(struct ata_port
EXPORT_SYMBOL_GPL(ata_acpi_cbl_80wire);
/**
- * taskfile_load_raw - send taskfile registers to host controller
+ * ata_acpi_run_tf - send taskfile registers to host controller
* @dev: target ATA device
* @gtf: raw ATA taskfile register set (0x1f1 - 0x1f7)
*
@@ -441,14 +445,17 @@ EXPORT_SYMBOL_GPL(ata_acpi_cbl_80wire);
* EH context.
*
* RETURNS:
- * 0 on success, -errno on failure.
+ * 1 if command is executed successfully. 0 if ignored or rejected,
+ * -errno on other errors.
*/
-static int taskfile_load_raw(struct ata_device *dev,
- const struct ata_acpi_gtf *gtf)
+static int ata_acpi_run_tf(struct ata_device *dev,
+ const struct ata_acpi_gtf *gtf)
{
- struct ata_port *ap = dev-link-ap;
struct ata_taskfile tf, rtf;
unsigned int err_mask;
+ const char *level;
+ char msg[60];
+ int rc;
if ((gtf-tf[0] == 0) (gtf-tf[1] == 0) (gtf-tf[2] == 0)
(gtf-tf[3] == 0) (gtf-tf[4] == 0) (gtf-tf[5] == 0)
@@ -468,29 +475,45 @@ static int taskfile_load_raw(struct ata_
tf.device = gtf-tf[5]; /* 0x1f6 */
tf.command = gtf-tf[6]; /* 0x1f7 */
- if (ata_msg_probe(ap))
- ata_dev_printk(dev, KERN_DEBUG, executing ACPI cmd
-
Re: [PATCH] sata_mv: Fix broken Marvell 7042 support.
Jeff Garzik wrote: Mark Lord wrote: To do so, requires that we perhaps do a similar capacity truncation in sata_mv, but only if we see a metadata block at the expected location (because a Legacy mode drive will use the *real* capacity, placing the metadata in the 9th sector instead. Definitely _not_. This is a core Linux maxim: export what the hardware exports, no more no less. We drive the bare metal. OTOH it is quite reasonable to explore auto-loading DM on top of the bare drive, and populating a DM table, if you see that particular BIOS signature or [insert other detection method]. .. We must remember that *data integrity* trumps all other principles here. If we don't strongly discourage/prevent the user from installing Linux or storing data in the corruptible region, they *will lose data*, and blame us. These are bootable cards, so people will install distro's from scratch directly to them, or to RAIDs configured onto them by the distro. So whatever we do has to be something *safe* for those situations. 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: [PATCH] sata_mv: Fix broken Marvell 7042 support.
Jeff Garzik wrote: Mark Lord wrote: To do so, requires that we perhaps do a similar capacity truncation in sata_mv, but only if we see a metadata block at the expected location (because a Legacy mode drive will use the *real* capacity, placing the metadata in the 9th sector instead. Definitely _not_. This is a core Linux maxim: export what the hardware exports, no more no less. We drive the bare metal. .. The hardware limitation here is the SATA controller card: it corrupts data at the last GB boundary. The drives themselves are not limited -- one can unplug them and reconnect to a different controller and have full use of them. 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: [PATCH] sata_mv: Fix broken Marvell 7042 support.
Mark Lord wrote: Jeff Garzik wrote: Mark Lord wrote: To do so, requires that we perhaps do a similar capacity truncation in sata_mv, but only if we see a metadata block at the expected location (because a Legacy mode drive will use the *real* capacity, placing the metadata in the 9th sector instead. Definitely _not_. This is a core Linux maxim: export what the hardware exports, no more no less. We drive the bare metal. .. The hardware limitation here is the SATA controller card: it corrupts data at the last GB boundary. The BIOS does that, not the controller card. If you pop the BIOS chip or plug the card into a non-x86 box (or any of several other alternatives), the problem is likely to go away. 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] sata_mv: Fix broken Marvell 7042 support.
Mark Lord wrote: Jeff Garzik wrote: Mark Lord wrote: To do so, requires that we perhaps do a similar capacity truncation in sata_mv, but only if we see a metadata block at the expected location (because a Legacy mode drive will use the *real* capacity, placing the metadata in the 9th sector instead. Definitely _not_. This is a core Linux maxim: export what the hardware exports, no more no less. We drive the bare metal. OTOH it is quite reasonable to explore auto-loading DM on top of the bare drive, and populating a DM table, if you see that particular BIOS signature or [insert other detection method]. .. We must remember that *data integrity* trumps all other principles here. If we don't strongly discourage/prevent the user from installing Linux or storing data in the corruptible region, they *will lose data*, and blame us. These are bootable cards, so people will install distro's from scratch directly to them, or to RAIDs configured onto them by the distro. So whatever we do has to be something *safe* for those situations. Then auto-load a device map that gets it right. The problem is not at the chip or device level, and this is the same problem as any number of other cards with softRAID on it. Not a new problem, not a new solution... 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
[PATCH #upstream-fixes] ahci: fix engine reset failed message
There isn't much point in reporting -EOPNOTSUPP as failure. Also the message was missing newline. Signed-off-by: Tejun Heo [EMAIL PROTECTED] --- drivers/ata/ahci.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: work/drivers/ata/ahci.c === --- work.orig/drivers/ata/ahci.c +++ work/drivers/ata/ahci.c @@ -1271,9 +1271,9 @@ static int ahci_do_softreset(struct ata_ /* prepare for SRST (AHCI-1.1 10.4.1) */ rc = ahci_kick_engine(ap, 1); - if (rc) + if (rc rc != -EOPNOTSUPP) ata_link_printk(link, KERN_WARNING, - failed to reset engine (errno=%d), rc); + failed to reset engine (errno=%d)\n, rc); ata_tf_init(link-device, tf); - 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 #upstream-fixes] ahci: don't attach if ICH6 is in combined mode
ICH6 R/Ms share PCI ID between piix and ahci modes and we've been
allowing ahci to attach regardless of how BIOS configured it.
However, enabling AHCI mode when the controller is in combined mode
can result in unexpected behavior. Don't attach if the controller is
in combined mode.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Cc: Bill Nottingham [EMAIL PROTECTED]
---
drivers/ata/ahci.c | 18 ++
1 file changed, 18 insertions(+)
Index: work/drivers/ata/ahci.c
===
--- work.orig/drivers/ata/ahci.c
+++ work/drivers/ata/ahci.c
@@ -193,6 +193,8 @@ enum {
ATA_FLAG_ACPI_SATA | ATA_FLAG_AN |
ATA_FLAG_IPM,
AHCI_LFLAG_COMMON = ATA_LFLAG_SKIP_D2H_BSY,
+
+ ICH_MAP = 0x90, /* ICH MAP register */
};
struct ahci_cmd_hdr {
@@ -2273,6 +2275,22 @@ static int ahci_init_one(struct pci_dev
if (rc)
return rc;
+ if (pdev-vendor == PCI_VENDOR_ID_INTEL
+ (pdev-device == 0x2652 || pdev-device == 0x2653)) {
+ u8 map;
+
+ /* ICH6s share the same PCI ID for both piix and ahci
+* modes. Enabling ahci mode while MAP indicates
+* combined mode is a bad idea. Yield to ata_piix.
+*/
+ pci_read_config_byte(pdev, ICH_MAP, map);
+ if (map 0x3) {
+ dev_printk(KERN_INFO, pdev-dev, controller is in
+ combined mode, can't enable AHCI mode\n);
+ return -ENODEV;
+ }
+ }
+
hpriv = devm_kzalloc(dev, sizeof(*hpriv), GFP_KERNEL);
if (!hpriv)
return -ENOMEM;
-
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 02/15] libata: zero xfer length on ATAPI data xfer IRQ is HSM violation
Tejun Heo wrote: From: Albert Lee [EMAIL PROTECTED] Treat zero xfer length as HSM violation. While at it, add unlikely()'s to ATAPI ireason and transfer length checks. tj: Formatted patch and added unlikely()'s. Signed-off-by: Albert Lee [EMAIL PROTECTED] Signed-off-by: Tejun Heo [EMAIL PROTECTED] --- drivers/ata/libata-core.c |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index 597e07c..88f7637 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -5280,12 +5280,15 @@ static void atapi_pio_bytes(struct ata_queued_cmd *qc) bytes = (bc_hi 8) | bc_lo; /* shall be cleared to zero, indicating xfer of data */ - if (ireason (1 0)) + if (unlikely(ireason (1 0))) goto err_out; /* make sure transfer direction matches expected */ i_write = ((ireason (1 1)) == 0) ? 1 : 0; - if (do_write != i_write) + if (unlikely(do_write != i_write)) + goto err_out; + + if (unlikely(!bytes)) goto err_out; VPRINTK(ata%u: xfering %d bytes\n, ap-print_id, bytes); Looks good. Acked-by: Albert Lee [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/15] libata: improve ATAPI draining
Tejun Heo wrote: For misc ATAPI commands which transfer variable length data to the host, overflow can occur due to application or hardware bug. Such overflows can be ignored safely as long as overflow data is properly drained. libata HSM implementation has this implemented in __atapi_pio_bytes() but it isn't enough. Improve drain logic such that... * Multiple PIO data phases are allowed. Not allowing this used to be okay when transfer chunk size was set to 8k unconditionally but with transfer hcunk size set to allocation size, treating extra PIO data phases as HSM violations cause a lot of trouble. * Limit the amount of draining to ATAPI_MAX_DRAIN (16k currently). * Don't whine if overflow is allowed and safe. When unexpected overflow occurs, trigger HSM violation and report the problem using ehi error description. * Properly calculate the number of bytes to be drained considering actual number of consumed bytes for partial draining. * Add and use ata_drain_page for draining. This change fixes the problem where LLDs which do 32bit IOs consumes 4 bytes on each 2 byte draining resulting in draining twice more data than requested. This patch fixes ATAPI regressions introduced by setting transfer chunk size to allocation size. Signed-off-by: Tejun Heo [EMAIL PROTECTED] Cc: Albert Lee [EMAIL PROTECTED] Acked-by: Albert Lee [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
