Re: [PATCH RFC] sata_promise: make pdc_atapi_pkt() use values from qc->tf
On Mon, 03 Dec 2007 13:49:36 +0900, Tejun Heo wrote: > Mikael Pettersson wrote: > >> what was the outcome of this discussion? > >> > >> I haven't looked over the Promise datasheet nor checked my brain for > >> details, hoping Mikael would do that for me ;-) > > > > I've now tested this on top of 2.6.24-rc3, with no observable > > regressions. Blanking, writing, and mounting/reading CD-RWs > > on both SATAPI and PATAPI works (tested on a 300 TX2plus card). > > > > I can't find anything in Promise's public docs or reference driver > > about non-standard requirements on lbam/lbah in ATAPI packets. > > The values set by core layer should be good enough. The only thing I'm > worried about is setting transfer chunk size when protocol is DMA. As > setting this value hasn't caused any problem for other controllers and > it seems sata_promise doesn't seem to have problem with it either, I'm > leaning toward keeping this value but if setting this value to zero is > the right thing to do, we can definitely change that in the core layer. > One way or the other, I'd really like to keep sata_promise's behavior > in line with other libata drivers. > > So, Mikael, do you think it would be okay to include the patch for > #upstream and see how it works in -mm? Yes /Mikael - 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
problems with packet command
Hi, I'm developing an application that uses cd-rom IOCTL's. All is fine but I have one problem I can not set up a packet command, because I don't know exactly how to fill out the 12 byte command field. I searched the internet, looked in the cdrom.c driver, some other programs source code, but I don't have a clear picture about that. I just know that the first element cmd[0] is the command. Would somebody please explain me how to fill out the 12 bytes ? or if not then at least could point out a good online resource. You are my last hope Thanks Kantor Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now. http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ - 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.
Ack - works in my 'unique' setup as well...:-)...
Thank you Mark!
Tom Morrison
-Original Message-
From: Mark Lord [mailto:[EMAIL PROTECTED]
Sent: Saturday, December 01, 2007 1:07 PM
To: IDE/ATA development list; Jeff Garzik
Cc: Tejun Heo; Alan Cox; Morrison, Tom; Hein-Pieter van Braam
Subject: [PATCH] sata_mv: Fix broken Marvell 7042 support.
sata_mv: Fix broken Marvell 7042 support.
The Marvell 7042 chip is more or less the same as the 6042 internally,
but sports a PCIe bus. Despite having identical SATA cores, the 7042
does differ from its PCI bus counterparts in placment and layout of
certain bus related registers.
This patch fixes sata_mv to distinguish between the PCI bus registers
of earlier chips, and the PCIe bus registers of the 7042.
Specifically, move the offsets and bit patterns for the
PCI/PCIe interrupt cause/mask registers into the struct mv_host_priv,
as these values differ between the 6xxx and 7xxx series chips.
This fixes the driver to not access reserved PCI addresses,
and prevents the lockups reported in linux-2.6.24 with 7042 boards.
Also add a new PCI ID for the Highpoint 2300 7042-based board
that I'm using for testing this stuff here.
Tested with Marvell 6081 + 7042 chips, on x86 & x86_64.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
Patch is agains 2.6.24-rc3-git5, and should go into 2.6.24.
--- old/drivers/ata/sata_mv.c 2007-12-01 11:48:28.0 -0500
+++ linux/drivers/ata/sata_mv.c 2007-12-01 12:06:30.0 -0500
@@ -164,10 +164,14 @@
MV_PCI_ERR_ATTRIBUTE= 0x1d48,
MV_PCI_ERR_COMMAND = 0x1d50,
- PCI_IRQ_CAUSE_OFS = 0x1d58,
- PCI_IRQ_MASK_OFS= 0x1d5c,
+ PCI_IRQ_CAUSE_OFS = 0x1d58,
+ PCI_IRQ_MASK_OFS= 0x1d5c,
PCI_UNMASK_ALL_IRQS = 0x7f, /* bits 22-0 */
+ PCIE_IRQ_CAUSE_OFS = 0x1900,
+ PCIE_IRQ_MASK_OFS = 0x1910,
+ PCIE_UNMASK_ALL_IRQS= 0x70a,/* assorted bits */
+
HC_MAIN_IRQ_CAUSE_OFS = 0x1d60,
HC_MAIN_IRQ_MASK_OFS= 0x1d64,
PORT0_ERR = (1 << 0), /* shift by port # */
@@ -303,6 +307,7 @@
MV_HP_GEN_I = (1 << 6), /* Generation I: 50xx */
MV_HP_GEN_II= (1 << 7), /* Generation II: 60xx
*/
MV_HP_GEN_IIE = (1 << 8), /* Generation IIE:
6042/7042 */
+ MV_HP_PCIE = (1 << 9), /* PCIe bus/regs: 7042
*/
/* Port private flags (pp_flags) */
MV_PP_FLAG_EDMA_EN = (1 << 0), /* is EDMA engine
enabled? */
@@ -388,7 +393,15 @@
u32 pre;
};
-struct mv_host_priv;
+struct mv_host_priv {
+ u32 hp_flags;
+ struct mv_port_signal signal[8];
+ const struct mv_hw_ops *ops;
+ u32 irq_cause_ofs;
+ u32 irq_mask_ofs;
+ u32 unmask_all_irqs;
+};
+
struct mv_hw_ops {
void (*phy_errata)(struct mv_host_priv *hpriv, void __iomem
*mmio,
unsigned int port);
@@ -401,12 +414,6 @@
void (*reset_bus)(struct pci_dev *pdev, void __iomem *mmio);
};
-struct mv_host_priv {
- u32 hp_flags;
- struct mv_port_signal signal[8];
- const struct mv_hw_ops *ops;
-};
-
static void mv_irq_clear(struct ata_port *ap);
static int mv_scr_read(struct ata_port *ap, unsigned int sc_reg_in, u32
*val);
static int mv_scr_write(struct ata_port *ap, unsigned int sc_reg_in,
u32 val);
@@ -631,11 +638,13 @@
/* Adaptec 1430SA */
{ PCI_VDEVICE(ADAPTEC2, 0x0243), chip_7042 },
- { PCI_VDEVICE(TTI, 0x2310), chip_7042 },
-
- /* add Marvell 7042 support */
+ /* Marvell 7042 support */
{ PCI_VDEVICE(MARVELL, 0x7042), chip_7042 },
+ /* Highpoint RocketRAID PCIe series */
+ { PCI_VDEVICE(TTI, 0x2300), chip_7042 },
+ { PCI_VDEVICE(TTI, 0x2310), chip_7042 },
+
{ } /* terminate list */
};
@@ -1648,13 +1657,14 @@
static void mv_pci_error(struct ata_host *host, void __iomem *mmio)
{
+ struct mv_host_priv *hpriv = host->private_data;
struct ata_port *ap;
struct ata_queued_cmd *qc;
struct ata_eh_info *ehi;
unsigned int i, err_mask, printed = 0;
u32 err_cause;
- err_cause = readl(mmio + PCI_IRQ_CAUSE_OFS);
+ err_cause = readl(mmio + hpriv->irq_cause_ofs);
dev_printk(KERN_ERR, host->dev, "PCI ERROR; PCI IRQ
cause=0x%08x\n",
err_cause);
@@ -1662,7 +1672,7 @@
DPRINTK("All regs @ PCI error\n");
mv_dump_all_regs(mmio, -1, to_pci_dev(host->dev));
- writelfl(0, mmio + PCI_IRQ_CAUSE_OFS);
+ writelfl(0, mmio + hpriv->irq_cause_ofs);
for (i = 0; i < host->n_ports; i++) {
ap = host->ports[i];
@@ -1926,6 +1936,8 @@
#define ZERO(reg) writel(0, mmio + (reg)
[PATCH] ahci: add the Device IDs of MCP79 AHCI controller to ahci.c
Add the device IDs of legacy mode of MCP79 AHCI controller to ahci.c
The patch base on kernel 2.6.24-rc3
Signed-off-by: Peer Chen <[EMAIL PROTECTED]>
---
--- linux-2.6.24-rc3/drivers/ata/ahci.c.orig2007-12-03 16:20:15.0
-0500
+++ linux-2.6.24-rc3/drivers/ata/ahci.c 2007-12-03 16:32:11.0 -0500
@@ -536,6 +536,10 @@ static const struct pci_device_id ahci_p
{ PCI_VDEVICE(NVIDIA, 0x0ad9), board_ahci },/* MCP77 */
{ PCI_VDEVICE(NVIDIA, 0x0ada), board_ahci },/* MCP77 */
{ PCI_VDEVICE(NVIDIA, 0x0adb), board_ahci },/* MCP77 */
+ { PCI_VDEVICE(NVIDIA, 0x0ab4), board_ahci },/* MCP79 */
+ { PCI_VDEVICE(NVIDIA, 0x0ab5), board_ahci },/* MCP79 */
+ { PCI_VDEVICE(NVIDIA, 0x0ab6), board_ahci },/* MCP79 */
+ { PCI_VDEVICE(NVIDIA, 0x0ab7), board_ahci },/* MCP79 */
{ PCI_VDEVICE(NVIDIA, 0x0ab8), board_ahci },/* MCP79 */
{ PCI_VDEVICE(NVIDIA, 0x0ab9), board_ahci },/* MCP79 */
{ PCI_VDEVICE(NVIDIA, 0x0aba), board_ahci },/* MCP79 */
-
-
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.
I should've added that I am working with a 2.6.23.x (x=8 right now)
kernel/sata_mv.c. Which unless I am mistaken - has not change any
until this patch - so I didn't have a problem...I need to work
on the 2.6.23.x - because I am trying to stabilize my build to
release a kernel for my developers to use for our next generation
product...this was the last piece...and I am going through a
regression to make sure everything is working correctly right now...
I don't think there should be a difference with module versus a
built-in...
Tom
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, December 03, 2007 9:48 AM
To: Morrison, Tom
Cc: Mark Lord; IDE/ATA development list; Jeff Garzik; Tejun Heo; Alan
Cox
Subject: RE: [PATCH] sata_mv: Fix broken Marvell 7042 support.
It doesn't quite work for me, the system locks up without discernible
error messages (Highpoint RocketRaid 2300 PCIe) . The drives come up,
and immediately get hyper active, and I get dumped in an initrd
busybox shell, when I try to tail /dev/sda it hangs, pvscan doesn't
find any physical volumes for LVM, on the upside, I don't get the PCI
ERROR messages anymore :) I'll try and get netconsole to work to get a
proper log.
Not very useful feedback, I'll try and dig a little deeper this
evening, I tried 2.6.24-rc3 and 2.6.24-rc3-git6 (couldn't find -git5
patchset, but I probably didn't look in the right place)
-git6 doesn't boot at all, complaining about not being able to execute
init because it can't handle the binary format... but that's probably
entirely unrelated to the sata_mv module.
Should it matter if I build as module or not? I'm now letting ubuntu
hardware detection load the sata_mv.ko automatically from initrd,
should I build a more stripped kernel?
Citeren "Morrison, Tom" <[EMAIL PROTECTED]>:
> Ack - works in my 'unique' setup as well...:-)...
>
> Thank you Mark!
>
> Tom Morrison
>
>
> -Original Message-
> From: Mark Lord [mailto:[EMAIL PROTECTED]
> Sent: Saturday, December 01, 2007 1:07 PM
> To: IDE/ATA development list; Jeff Garzik
> Cc: Tejun Heo; Alan Cox; Morrison, Tom; Hein-Pieter van Braam
> Subject: [PATCH] sata_mv: Fix broken Marvell 7042 support.
>
> sata_mv: Fix broken Marvell 7042 support.
>
> The Marvell 7042 chip is more or less the same as the 6042 internally,
> but sports a PCIe bus. Despite having identical SATA cores, the 7042
> does differ from its PCI bus counterparts in placment and layout of
> certain bus related registers.
>
> This patch fixes sata_mv to distinguish between the PCI bus registers
> of earlier chips, and the PCIe bus registers of the 7042.
>
> Specifically, move the offsets and bit patterns for the
> PCI/PCIe interrupt cause/mask registers into the struct mv_host_priv,
> as these values differ between the 6xxx and 7xxx series chips.
>
> This fixes the driver to not access reserved PCI addresses,
> and prevents the lockups reported in linux-2.6.24 with 7042 boards.
>
> Also add a new PCI ID for the Highpoint 2300 7042-based board
> that I'm using for testing this stuff here.
>
> Tested with Marvell 6081 + 7042 chips, on x86 & x86_64.
>
> Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
> ---
>
> Patch is agains 2.6.24-rc3-git5, and should go into 2.6.24.
>
> --- old/drivers/ata/sata_mv.c 2007-12-01 11:48:28.0 -0500
> +++ linux/drivers/ata/sata_mv.c 2007-12-01 12:06:30.0
-0500
> @@ -164,10 +164,14 @@
> MV_PCI_ERR_ATTRIBUTE= 0x1d48,
> MV_PCI_ERR_COMMAND = 0x1d50,
>
> - PCI_IRQ_CAUSE_OFS = 0x1d58,
> - PCI_IRQ_MASK_OFS= 0x1d5c,
> + PCI_IRQ_CAUSE_OFS = 0x1d58,
> + PCI_IRQ_MASK_OFS= 0x1d5c,
> PCI_UNMASK_ALL_IRQS = 0x7f, /* bits 22-0 */
>
> + PCIE_IRQ_CAUSE_OFS = 0x1900,
> + PCIE_IRQ_MASK_OFS = 0x1910,
> + PCIE_UNMASK_ALL_IRQS= 0x70a,/* assorted bits */
> +
> HC_MAIN_IRQ_CAUSE_OFS = 0x1d60,
> HC_MAIN_IRQ_MASK_OFS= 0x1d64,
> PORT0_ERR = (1 << 0), /* shift by port # */
> @@ -303,6 +307,7 @@
> MV_HP_GEN_I = (1 << 6), /* Generation I: 50xx */
> MV_HP_GEN_II= (1 << 7), /* Generation II: 60xx
> */
> MV_HP_GEN_IIE = (1 << 8), /* Generation IIE:
> 6042/7042 */
> + MV_HP_PCIE = (1 << 9), /* PCIe bus/regs: 7042
> */
>
> /* Port private flags (pp_flags) */
> MV_PP_FLAG_EDMA_EN = (1 << 0), /* is EDMA engine
> enabled? */
> @@ -388,7 +393,15 @@
> u32 pre;
> };
>
> -struct mv_host_priv;
> +struct mv_host_priv {
> + u32 hp_flags;
> + struct mv_port_signal signal[8];
> + const struct mv_hw_ops *ops;
> + u32 irq_cause_ofs;
> + u32 irq_mask_ofs;
> + u32 unmask_all_irqs;
> +};
> +
> struct mv_hw_ops {
> void (*phy_er
RE: [PATCH] sata_mv: Fix broken Marvell 7042 support.
It doesn't quite work for me, the system locks up without discernible
error messages (Highpoint RocketRaid 2300 PCIe) . The drives come up,
and immediately get hyper active, and I get dumped in an initrd
busybox shell, when I try to tail /dev/sda it hangs, pvscan doesn't
find any physical volumes for LVM, on the upside, I don't get the PCI
ERROR messages anymore :) I'll try and get netconsole to work to get a
proper log.
Not very useful feedback, I'll try and dig a little deeper this
evening, I tried 2.6.24-rc3 and 2.6.24-rc3-git6 (couldn't find -git5
patchset, but I probably didn't look in the right place)
-git6 doesn't boot at all, complaining about not being able to execute
init because it can't handle the binary format... but that's probably
entirely unrelated to the sata_mv module.
Should it matter if I build as module or not? I'm now letting ubuntu
hardware detection load the sata_mv.ko automatically from initrd,
should I build a more stripped kernel?
Citeren "Morrison, Tom" <[EMAIL PROTECTED]>:
Ack - works in my 'unique' setup as well...:-)...
Thank you Mark!
Tom Morrison
-Original Message-
From: Mark Lord [mailto:[EMAIL PROTECTED]
Sent: Saturday, December 01, 2007 1:07 PM
To: IDE/ATA development list; Jeff Garzik
Cc: Tejun Heo; Alan Cox; Morrison, Tom; Hein-Pieter van Braam
Subject: [PATCH] sata_mv: Fix broken Marvell 7042 support.
sata_mv: Fix broken Marvell 7042 support.
The Marvell 7042 chip is more or less the same as the 6042 internally,
but sports a PCIe bus. Despite having identical SATA cores, the 7042
does differ from its PCI bus counterparts in placment and layout of
certain bus related registers.
This patch fixes sata_mv to distinguish between the PCI bus registers
of earlier chips, and the PCIe bus registers of the 7042.
Specifically, move the offsets and bit patterns for the
PCI/PCIe interrupt cause/mask registers into the struct mv_host_priv,
as these values differ between the 6xxx and 7xxx series chips.
This fixes the driver to not access reserved PCI addresses,
and prevents the lockups reported in linux-2.6.24 with 7042 boards.
Also add a new PCI ID for the Highpoint 2300 7042-based board
that I'm using for testing this stuff here.
Tested with Marvell 6081 + 7042 chips, on x86 & x86_64.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
Patch is agains 2.6.24-rc3-git5, and should go into 2.6.24.
--- old/drivers/ata/sata_mv.c 2007-12-01 11:48:28.0 -0500
+++ linux/drivers/ata/sata_mv.c 2007-12-01 12:06:30.0 -0500
@@ -164,10 +164,14 @@
MV_PCI_ERR_ATTRIBUTE= 0x1d48,
MV_PCI_ERR_COMMAND = 0x1d50,
- PCI_IRQ_CAUSE_OFS = 0x1d58,
- PCI_IRQ_MASK_OFS= 0x1d5c,
+ PCI_IRQ_CAUSE_OFS = 0x1d58,
+ PCI_IRQ_MASK_OFS= 0x1d5c,
PCI_UNMASK_ALL_IRQS = 0x7f, /* bits 22-0 */
+ PCIE_IRQ_CAUSE_OFS = 0x1900,
+ PCIE_IRQ_MASK_OFS = 0x1910,
+ PCIE_UNMASK_ALL_IRQS= 0x70a,/* assorted bits */
+
HC_MAIN_IRQ_CAUSE_OFS = 0x1d60,
HC_MAIN_IRQ_MASK_OFS= 0x1d64,
PORT0_ERR = (1 << 0), /* shift by port # */
@@ -303,6 +307,7 @@
MV_HP_GEN_I = (1 << 6), /* Generation I: 50xx */
MV_HP_GEN_II= (1 << 7), /* Generation II: 60xx
*/
MV_HP_GEN_IIE = (1 << 8), /* Generation IIE:
6042/7042 */
+ MV_HP_PCIE = (1 << 9), /* PCIe bus/regs: 7042
*/
/* Port private flags (pp_flags) */
MV_PP_FLAG_EDMA_EN = (1 << 0), /* is EDMA engine
enabled? */
@@ -388,7 +393,15 @@
u32 pre;
};
-struct mv_host_priv;
+struct mv_host_priv {
+ u32 hp_flags;
+ struct mv_port_signal signal[8];
+ const struct mv_hw_ops *ops;
+ u32 irq_cause_ofs;
+ u32 irq_mask_ofs;
+ u32 unmask_all_irqs;
+};
+
struct mv_hw_ops {
void (*phy_errata)(struct mv_host_priv *hpriv, void __iomem
*mmio,
unsigned int port);
@@ -401,12 +414,6 @@
void (*reset_bus)(struct pci_dev *pdev, void __iomem *mmio);
};
-struct mv_host_priv {
- u32 hp_flags;
- struct mv_port_signal signal[8];
- const struct mv_hw_ops *ops;
-};
-
static void mv_irq_clear(struct ata_port *ap);
static int mv_scr_read(struct ata_port *ap, unsigned int sc_reg_in, u32
*val);
static int mv_scr_write(struct ata_port *ap, unsigned int sc_reg_in,
u32 val);
@@ -631,11 +638,13 @@
/* Adaptec 1430SA */
{ PCI_VDEVICE(ADAPTEC2, 0x0243), chip_7042 },
- { PCI_VDEVICE(TTI, 0x2310), chip_7042 },
-
- /* add Marvell 7042 support */
+ /* Marvell 7042 support */
{ PCI_VDEVICE(MARVELL, 0x7042), chip_7042 },
+ /* Highpoint RocketRAID PCIe series */
+ { PCI_VDEV
Re: [PATCH 26/28] blk_end_request: changing ide-cd (take 3)
Bartlomiej Zolnierkiewicz wrote: [PATCH] ide-cd: remove dead post_transform_command() post_transform_command() call in cdrom_newpc_intr() has no effect because it is done after the request has already been fully completed (rq->bio and rq->data are always NULL). It was verified to be true regardless whether INQUIRY command is using DMA or PIO to transfer data (by using modified Tejun Heo's test-shortsg.c utility and adding a few printk()-s to ide-cd). This was uncovered thanks to the "blk_end_request: full I/O completion handler (take 3)" patch series from Kiyoshi Ueda. Cc: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Cc: Kiyoshi Ueda <[EMAIL PROTECTED] Cc: Jun'ichi Nomura <[EMAIL PROTECTED]> Cc: Tejun Heo <[EMAIL PROTECTED]> Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]> MBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possibly SATA related freeze killed networking and RAID
Tejun Heo wrote: Surprise, surprise. There's no way to tell whether the controller raised interrupt or not if command is not in progress. As I said before, there's no IRQ pending bit. While processing commands, you can tell by looking at other status registers but when there's nothing in flight and the controller determines it's a good time to raise a spurious interrupt, there's no way you can tell. That dang SFF interface is like 15+ years old. But we can still make things pretty robust. We're working on it. Thanks. It sounds like you mean that you know the controller did NOT raise the interrupt ( intentionally/correctly ) if there was no command in progress, as opposed to not being able to tell. Unless there is some condition under which it is valid for the controller to raise an interrupt when it had no commands in progress? And if that's the case and there's know way to know WHY, that's a broken design. - 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.
[EMAIL PROTECTED] wrote: It doesn't quite work for me, the system locks up without discernible error messages (Highpoint RocketRaid 2300 PCIe) . The drives come up, and immediately get hyper active, and I get dumped in an initrd busybox shell, when I try to tail /dev/sda it hangs, pvscan doesn't find any physical volumes for LVM, on the upside, I don't get the PCI ERROR messages anymore :) I'll try and get netconsole to work to get a proper log. ... Before this, you were booting from some other device, and the sata_mv mostly worked for you there, right ? Specifically, you wrote: Now, because the chip on the thing is a Marvell 7042 I figured I just add the PCI ID to the driver. I tried this, and, if I do not boot from the device it does seem to work. I did however get the following errors (a lot): 02:00.0 sata_mv PCI ERROR; PCI IRQ reason=0x I write this from memory, but the numbers are correct, sorry if they do not EXACTLY match. The disk drives do work, but they are dog slow, and when I try to boot my ubuntu 7.10 system with this driver, it hangs during boot, right after it tried to enable my software raid volumes. I have tried both the 'stock' ubuntu kernel 2.6.22-14-generic (I guess that won't mean much) but I also tried vanilla kernel.org 2.6.23.1 .. So at least that much should now be working much better for you. I have not actually ever booted from a sata_mv controller yet, so maybe there's still something peculiar about libata::sata_mv early in the boot stages ? I'm using sata_mv as a module here, but I *never* use initrd/initramfs images. They just complicate things needlessly once I know my hardware config. But it should work. I'll try booting from a sata_mv drive here on your board and see what's 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: Enabling MSI in sata_nv
Philip Langdale wrote: Hi all, At least for my hardware (MCP55), the sata controller supports MSI and it seems that turning it on is as simple as inserting the call to pci_enable_msi - after that it Just Works(tm). Are there any gotchas that I'm missing? Would a patch to do this be accepted? .. Don't even dream about it for now. The driver is unstable enough without throwing MSI into the works. Maybe in the new year, once we get it more up to spec. 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] ata: ahci: Enclosure Management via LED rev2
On Sat, 01 Dec 2007 18:28:54 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: > Kristen Carlson Accardi wrote: > > Enclosure Management via LED > > > > This patch implements Enclosure Management via the LED protocol as > > specified in AHCI specification. > > > > Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]> > > --- > > This revision makes the change to the comment requested by Mark > > Lord, fixes some bugs in the bit shifting for writing the new led > > state, and implements a show function so that led status can be > > read as well as written. > > Overall looks pretty good, from a technical review perspective. > > Two worries: > > 1) exporting ata_scsi_find_dev(), and assuming a scsi device is > attached. the latter can be fixed by a !NULL check (and should be), > but its a bit of a layering violation since long term we want to make > the SCSI simulator optional for all ATA devices. > > 2) vaguely related to #1, I'm not so sure the attributes should be > implemented directly in ahci. if this __or something like it__ > appears on non-Intel hardware, the code should be somewhere more > generic. > When I first started developing this patch, I did have a more generic approach - It adds lots of complexity that isn't needed for this simple protocol, and one of the problems I encountered was that for different EM protocols, you'd probably want to have a different set of attributes defined. Also, even using the same protocol, you may have hardware that supports more attributes. For example, in the case of this LED protocol, some implementations may support the Activity LED (software controlled), and some may not. For protocols like SGPIO, they have a lot of attributes defined by the spec, but I'm guessing hardware may not support all of them. When I tried to abstract hardware and protocol away and make some kind of generic enclosure management framework, it turned into this big ordeal. So, I can keep going along those lines, but to me it started to seem silly since I had no other hardware that I knew of that was going to be helped by all this. I thought maybe the right thing to do was to keep it simple and then wait for other the hardware to appear. - 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: [EMAIL PROTECTED] wrote: It doesn't quite work for me, the system locks up without discernible error messages (Highpoint RocketRaid 2300 PCIe) . The drives come up, and immediately get hyper active, and I get dumped in an initrd busybox shell, when I try to tail /dev/sda it hangs, pvscan doesn't find any physical volumes for LVM, on the upside, I don't get the PCI ERROR messages anymore :) I'll try and get netconsole to work to get a proper log. ... Before this, you were booting from some other device, and the sata_mv mostly worked for you there, right ? Specifically, you wrote: Now, because the chip on the thing is a Marvell 7042 I figured I just add the PCI ID to the driver. I tried this, and, if I do not boot from the device it does seem to work. I did however get the following errors (a lot): 02:00.0 sata_mv PCI ERROR; PCI IRQ reason=0x I write this from memory, but the numbers are correct, sorry if they do not EXACTLY match. The disk drives do work, but they are dog slow, and when I try to boot my ubuntu 7.10 system with this driver, it hangs during boot, right after it tried to enable my software raid volumes. I have tried both the 'stock' ubuntu kernel 2.6.22-14-generic (I guess that won't mean much) but I also tried vanilla kernel.org 2.6.23.1 .. So at least that much should now be working much better for you. I have not actually ever booted from a sata_mv controller yet, so maybe there's still something peculiar about libata::sata_mv early in the boot stages ? I'm using sata_mv as a module here, but I *never* use initrd/initramfs images. They just complicate things needlessly once I know my hardware config. But it should work. I'll try booting from a sata_mv drive here on your board and see what's up. .. Okay, I've attempted to boot from the RocketRAID 2300 card using a known-good boot hard disk. No such luck. The BIOS on the Highpoint RR 2300 *corrupts* the GRUB image, so GRUB won't boot for me there. I actually have to re-install GRUB after each attempt so that the drive is usable again with the onboard Intel (ahci) ports. So one then wonders exactly what the Highpoint BIOS is overwriting, and how that might affect your particular configuration.. ??? I'll try booting from another (non-Highpoint) 7042 board next. After I repair GRUB again, that is. 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: Enabling MSI in sata_nv
Mark Lord wrote: Philip Langdale wrote: Hi all, At least for my hardware (MCP55), the sata controller supports MSI and it seems that turning it on is as simple as inserting the call to pci_enable_msi - after that it Just Works(tm). Are there any gotchas that I'm missing? Would a patch to do this be accepted? .. Don't even dream about it for now. The driver is unstable enough without throwing MSI into the works. .. Oh, wait a minute.. I misread "sata_nv" as "sata_mv" there. No comment on "sata_nv". (we really oughta rename one of those two..) - 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: The BIOS on the Highpoint RR 2300 *corrupts* the GRUB image, so GRUB won't boot for me there. I actually have to re-install GRUB after each attempt so that the drive is usable again with the onboard Intel (ahci) ports. So one then wonders exactly what the Highpoint BIOS is overwriting, RAID metadata, one would assume from the 'RR'... I've no idea if the standard solution is applicable to HPT RR: going through BIOS setup and turning off RAID completely, or if not possible, putting it into JBOD mode. .. It's an add-on PCIe board, with it's own onboard "RAID management" BIOS. The onboard BIOS has the drive labelled as "Legacy", but it still seems to insist upon writing it's meta data at every startup. So to boot from it, we may need to find a way to keep our bootloader away from those same sector(s). 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.
Fwiw, I'm not running an add-on card or anything like it - no raid - nothing except a 7042 chip as the the front-end to 2-4 harddrives in my box) - in this case - I am not having a problem... I write this as perhaps a hint to the 'right' direction to go looking for the trouble... all the best~! -Original Message- From: Mark Lord [mailto:[EMAIL PROTECTED] Sent: Monday, December 03, 2007 1:32 PM To: Jeff Garzik Cc: [EMAIL PROTECTED]; Morrison, Tom; IDE/ATA development list; Tejun Heo; Alan Cox Subject: Re: [PATCH] sata_mv: Fix broken Marvell 7042 support. Jeff Garzik wrote: > Mark Lord wrote: >> The BIOS on the Highpoint RR 2300 *corrupts* the GRUB image, >> so GRUB won't boot for me there. I actually have to re-install >> GRUB after each attempt so that the drive is usable again >> with the onboard Intel (ahci) ports. >> >> So one then wonders exactly what the Highpoint BIOS is overwriting, > > RAID metadata, one would assume from the 'RR'... > > I've no idea if the standard solution is applicable to HPT RR: going > through BIOS setup and turning off RAID completely, or if not possible, > putting it into JBOD mode. .. It's an add-on PCIe board, with it's own onboard "RAID management" BIOS. The onboard BIOS has the drive labelled as "Legacy", but it still seems to insist upon writing it's meta data at every startup. So to boot from it, we may need to find a way to keep our bootloader away from those same sector(s). 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: ... Okay, I've attempted to boot from the RocketRAID 2300 card using a known-good boot hard disk. No such luck. The BIOS on the Highpoint RR 2300 *corrupts* the GRUB image, so GRUB won't boot for me there. I actually have to re-install GRUB after each attempt so that the drive is usable again with the onboard Intel (ahci) ports. So one then wonders exactly what the Highpoint BIOS is overwriting, and how that might affect your particular configuration.. ??? I'll try booting from another (non-Highpoint) 7042 board next. After I repair GRUB again, that is. ... No joy. My other 7042 and 6042 cards do not have bootable BIOSs. So to boot from a 7042 the only theoretical choice is the Highpoint board, and for that we need to somehow coax it into not overwriting GRUB every time the onboard BIOS reinitializes. Tricky to arrange, that. How are you doing it ? - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sata_mv: Fix broken Marvell 7042 support.
Mark Lord wrote: The BIOS on the Highpoint RR 2300 *corrupts* the GRUB image, so GRUB won't boot for me there. I actually have to re-install GRUB after each attempt so that the drive is usable again with the onboard Intel (ahci) ports. So one then wonders exactly what the Highpoint BIOS is overwriting, RAID metadata, one would assume from the 'RR'... I've no idea if the standard solution is applicable to HPT RR: going through BIOS setup and turning off RAID completely, or if not possible, putting it into JBOD mode. 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.
Morrison, Tom wrote: Fwiw, I'm not running an add-on card or anything like it - no raid - nothing except a 7042 chip as the the front-end to 2-4 harddrives in my box) - in this case - I am not having a problem... I write this as perhaps a hint to the 'right' direction to go looking for the trouble... .. Thanks Tom. So we know we *can* boot from a bare 7042, which is good! I've poked a little more at this here, and I *think* the BIOS is overwriting the 9th sector on the drive. I'll test that theory a little more. Any GRUB experts out there? How do I get GRUB to install the stage2 stuff on a partition, instead of in the first 63 sectors ? -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: Morrison, Tom wrote: Fwiw, I'm not running an add-on card or anything like it - no raid - nothing except a 7042 chip as the the front-end to 2-4 harddrives in my box) - in this case - I am not having a problem... I write this as perhaps a hint to the 'right' direction to go looking for the trouble... .. Thanks Tom. So we know we *can* boot from a bare 7042, which is good! I've poked a little more at this here, and I *think* the BIOS is overwriting the 9th sector on the drive. I'll test that theory a little more. .. Confirmed. It writes "lgcy" + stuff into the 9th sector of the drive (for my "Legacy" drive). Where does Linux softraid put it's stuff ? And Hein-Pieter: what are you using for a bootloader ? Any GRUB experts out there? How do I get GRUB to install the stage2 stuff on a partition, instead of in the first 63 sectors ? .. Technically, I suppose it's the stage 1.5 stuff that's getting nuked. Or something like that. - 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.
> Confirmed. It writes "lgcy" + stuff into the 9th sector of the drive > (for my "Legacy" drive). Thats quite nasty. Given that users putting volumes unpartitioned on drives may see actual data corruption and loss perhaps we should blacklist that controller variant with a large warning ? 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: Enabling MSI in sata_nv
On Dec 2, 2007 10:07 PM, Philip Langdale <[EMAIL PROTECTED]> wrote: > Hi all, > > At least for my hardware (MCP55), the sata controller supports MSI > and it seems that turning it on is as simple as inserting the call > to pci_enable_msi - after that it Just Works(tm). > > Are there any gotchas that I'm missing? Would a patch to do this > be accepted? > > --phil I don't know if it is relevant, but I had to disable MSI to get a MCP55 NIC to work under 2.6.22. See https://bugzilla.novell.com/show_bug.cgi?id=287017#c1 for details if your curious. Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sata_mv: Fix broken Marvell 7042 support.
Alan Cox wrote: Confirmed. It writes "lgcy" + stuff into the 9th sector of the drive (for my "Legacy" drive). Thats quite nasty. Given that users putting volumes unpartitioned on drives may see actual data corruption and loss perhaps we should blacklist that controller variant with a large warning ? .. Yeah, that's quite obnoxious of Highpoint to just arbitrarily overwrite data. Some warnings would probably be quite useful here. We could log a WARNING the first few times (after boot) whenever we see software writing to that sector. Do this with a hack in mv_qc_prep or mv_qc_issue ? Or even just fail any write to that sector, so that the error gets propagated all the way back to usermode where it might be visible? Plus some big nasty "awareness" messages at boot regardless. If software never writes to it, then it should work fine. Except when drives are imported from somewhere else.. as I just discovered with my GRUB disk. Then the disk is already corrupted before our kernel is even loaded. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Enabling MSI in sata_nv
Greg Freemyer wrote: On Dec 2, 2007 10:07 PM, Philip Langdale <[EMAIL PROTECTED]> wrote: Hi all, At least for my hardware (MCP55), the sata controller supports MSI and it seems that turning it on is as simple as inserting the call to pci_enable_msi - after that it Just Works(tm). Are there any gotchas that I'm missing? Would a patch to do this be accepted? --phil I don't know if it is relevant, but I had to disable MSI to get a MCP55 NIC to work under 2.6.22. MSI is pretty flaky, but we default it to 'on' for AHCI, which is the "enhanced mode" side of the sata_nv chip. So it is likely that it works on newer boards -- but even though Mark Lord's response was mistaken (he thought sata_mv was being discussed), he was right too... sata_nv has stability problems and I would prefer not to enable MSI just yet, until we cure the other problems. 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: Enabling MSI in sata_nv
Mark Lord wrote: Mark Lord wrote: Philip Langdale wrote: Hi all, At least for my hardware (MCP55), the sata controller supports MSI and it seems that turning it on is as simple as inserting the call to pci_enable_msi - after that it Just Works(tm). Are there any gotchas that I'm missing? Would a patch to do this be accepted? .. Don't even dream about it for now. The driver is unstable enough without throwing MSI into the works. .. Oh, wait a minute.. I misread "sata_nv" as "sata_mv" there. FWIW: Marvell says they run with MSI enabled on 6440 (mvsas) in their vendor driver, but not on any of the 50xx and 60xx variants supported by sata_mv. Maybe that's changed in the past year with 7042, I dunno. But that's the latest info I have. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [libata] sata_mv: Support integrated controllers
Mark Lord wrote: Also, I'm not sure I understand why there's a need for the new sata_mv.h file ? The embedded platform includes that, similar to include/linux/pata_platform.h. 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.
On Mon, 2007-12-03 at 13:30 -0500, Mark Lord wrote: > Mark Lord wrote: > ... > > > Okay, I've attempted to boot from the RocketRAID 2300 card > > using a known-good boot hard disk. > > > > No such luck. > > > > The BIOS on the Highpoint RR 2300 *corrupts* the GRUB image, > > so GRUB won't boot for me there. I actually have to re-install > > GRUB after each attempt so that the drive is usable again > > with the onboard Intel (ahci) ports. > > > > So one then wonders exactly what the Highpoint BIOS is overwriting, > > and how that might affect your particular configuration.. > > > > ??? > > > > I'll try booting from another (non-Highpoint) 7042 board next. > > After I repair GRUB again, that is. > ... > > No joy. My other 7042 and 6042 cards do not have bootable BIOSs. > > So to boot from a 7042 the only theoretical choice is the Highpoint board, > and for that we need to somehow coax it into not overwriting GRUB > every time the onboard BIOS reinitializes. > > Tricky to arrange, that. > > How are you doing it ? Personally, I put all the disks in JBOD mode, but I never had these disks connected to anything but my highpoint cards. Perhaps I should tell you what my setup's like: * In the system I've put 3 Highpoint RocketRaid 2300 cards. * Two of the cards each have 4 Hitachi 750GB disks * Each disk is put into JBOD mode in the 'Raid' Bios of the 2300 * On the drives I have 2 partitions, one 200MB partition and a partition spanning the rest of the 750GB * Both partitions are linux softraid * /dev/md0 is a mirror of all 8 disks and serves as /boot (200MB) * /dev/md1 contains an LVM volume that houses my other paritions (4.7TB) Right now with 2.6.23.9 + patched sata_mv the softraid seems to come up just fine but I pvscan is unable to locate the pv located on md1. I'll try and make a bootable USB stick with my patched 2.6.23.9 and see what the results are then. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - 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: Personally, I put all the disks in JBOD mode, but I never had these disks connected to anything but my highpoint cards. Perhaps I should tell you what my setup's like: * In the system I've put 3 Highpoint RocketRaid 2300 cards. * Two of the cards each have 4 Hitachi 750GB disks * Each disk is put into JBOD mode in the 'Raid' Bios of the 2300 * On the drives I have 2 partitions, one 200MB partition and a partition spanning the rest of the 750GB * Both partitions are linux softraid * /dev/md0 is a mirror of all 8 disks and serves as /boot (200MB) * /dev/md1 contains an LVM volume that houses my other paritions (4.7TB) Right now with 2.6.23.9 + patched sata_mv the softraid seems to come up just fine but I pvscan is unable to locate the pv located on md1. I'll try and make a bootable USB stick with my patched 2.6.23.9 and see what the results are then. .. How are you booting without the USB stick? Are you booting from the Highpoint card drives? What bootloader ? 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] sata_mv: Fix broken Marvell 7042 support.
> > > I'll try and make a bootable USB stick with my patched 2.6.23.9 and see > > what the results are then. > .. > > How are you booting without the USB stick? > Are you booting from the Highpoint card drives? > What bootloader ? > > Thanks > - Right now I just boot using GRUB really, perhaps the BIOS hides the 9th sector if it's in some form of RAID mode? I haven't had any trouble using GRUB... I haven't done anything special apart from putting the drives in JBOD mode, each disk is set to JBOD, it's set per disk, so not one large JBOD over 8 disks, but 8 separate JBOD volumes. Hope that helps... -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - 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:
Alan Cox wrote:
Confirmed. It writes "lgcy" + stuff into the 9th sector of the drive
(for my "Legacy" drive).
Thats quite nasty. Given that users putting volumes unpartitioned on
drives may see actual data corruption and loss perhaps we should
blacklist that controller variant with a large warning ?
..
Yeah, that's quite obnoxious of Highpoint to just arbitrarily overwrite
data.
Some warnings would probably be quite useful here.
We could log a WARNING the first few times (after boot)
whenever we see software writing to that sector.
Do this with a hack in mv_qc_prep or mv_qc_issue ?
Or even just fail any write to that sector, so that the error
gets propagated all the way back to usermode where it might be visible?
Plus some big nasty "awareness" messages at boot regardless.
...
Something like this, perhaps.
Comments, suggestions ?
It might be a good idea to also change qc_prep() semantics
to allow the LLD to fail a request from there, rather than
having to defer it to qc_issue(), (as done in this hack).
--- old/drivers/ata/libata-core.c 2007-12-03 15:29:42.0 -0500
+++ linux/drivers/ata/libata-core.c 2007-12-03 15:21:15.0 -0500
@@ -7568,6 +7568,7 @@
EXPORT_SYMBOL_GPL(sata_print_link_status);
EXPORT_SYMBOL_GPL(ata_tf_to_fis);
EXPORT_SYMBOL_GPL(ata_tf_from_fis);
+EXPORT_SYMBOL_GPL(ata_tf_read_block);
EXPORT_SYMBOL_GPL(ata_check_status);
EXPORT_SYMBOL_GPL(ata_altstatus);
EXPORT_SYMBOL_GPL(ata_exec_command);
--- old/drivers/ata/libata.h2007-12-03 15:29:37.0 -0500
+++ linux/drivers/ata/libata.h 2007-12-03 15:21:23.0 -0500
@@ -64,7 +64,6 @@
extern int ata_build_rw_tf(struct ata_taskfile *tf, struct ata_device *dev,
u64 block, u32 n_block, unsigned int tf_flags,
unsigned int tag);
-extern u64 ata_tf_read_block(struct ata_taskfile *tf, struct ata_device *dev);
extern void ata_dev_disable(struct ata_device *dev);
extern void ata_port_flush_task(struct ata_port *ap);
extern unsigned ata_exec_internal(struct ata_device *dev,
--- old/drivers/ata/sata_mv.c 2007-12-03 15:29:43.0 -0500
+++ linux/drivers/ata/sata_mv.c 2007-12-03 15:33:17.0 -0500
@@ -308,6 +308,7 @@
MV_HP_GEN_II= (1 << 7), /* Generation II: 60xx */
MV_HP_GEN_IIE = (1 << 8), /* Generation IIE: 6042/7042
*/
MV_HP_PCIE = (1 << 9), /* PCIe bus/regs: 7042 */
+ MV_HP_RESERVED_LBA8 = (1 << 10),
/* Port private flags (pp_flags) */
MV_PP_FLAG_EDMA_EN = (1 << 0), /* is EDMA engine enabled? */
@@ -1280,19 +1281,38 @@
{
struct ata_port *ap = qc->ap;
struct mv_port_priv *pp = ap->private_data;
+ struct mv_host_priv *hpriv = ap->host->private_data;
struct mv_crqb_iie *crqb;
- struct ata_taskfile *tf;
+ struct ata_taskfile *tf = &qc->tf;
unsigned in_index;
u32 flags = 0;
- if (qc->tf.protocol != ATA_PROT_DMA)
+ if (tf->protocol != ATA_PROT_DMA)
return;
/* Fill in Gen IIE command request block
*/
- if (!(qc->tf.flags & ATA_TFLAG_WRITE))
+ if (!(tf->flags & ATA_TFLAG_WRITE))
flags |= CRQB_FLAG_READ;
+ if (tf->flags & ATA_TFLAG_WRITE) {
+ if (hpriv->hp_flags & MV_HP_RESERVED_LBA8) {
+ u64 start = ata_tf_read_block(tf, qc->dev);
+ u32 nsect = tf->nsect;
+ if (tf->flags & ATA_TFLAG_LBA48)
+ nsect |= tf->hob_nsect;
+ if (!nsect)
+ nsect = 256; /* good enough for here */
+ if (start <= 8 && (start + nsect) >= 8) {
+ printk(KERN_WARNING "ata%u: sector 8 is "
+ "reserved by Highpoint BIOS\n",
+ ap->print_id);
+ qc->err_mask |= AC_ERR_INVALID;
+ return;
+ }
+ }
+ }
+
WARN_ON(MV_MAX_Q_DEPTH <= qc->tag);
flags |= qc->tag << CRQB_TAG_SHIFT;
flags |= qc->tag << CRQB_IOID_SHIFT; /* "I/O Id" is -really-
@@ -1306,7 +1326,6 @@
crqb->addr_hi = cpu_to_le32((pp->sg_tbl_dma >> 16) >> 16);
crqb->flags = cpu_to_le32(flags);
- tf = &qc->tf;
crqb->ata_cmd[0] = cpu_to_le32(
(tf->command << 16) |
(tf->feature << 24)
@@ -1353,6 +1372,8 @@
struct mv_host_priv *hpriv = ap->host->private_data;
u32 in_index;
+ if (qc->err_mask & AC_ERR_INVALID) /* from qc_prep */
+ return AC_ERR_INVALID;
if (qc->tf.protocol != ATA_PROT_DMA) {
/* We're about to send a non-EDMA capable command to the
* port. Turn off EDMA so there won't be problems access
Re: [PATCH] sata_mv: Fix broken Marvell 7042 support.
Hein-Pieter van Braam wrote: I'll try and make a bootable USB stick with my patched 2.6.23.9 and see what the results are then. .. How are you booting without the USB stick? Are you booting from the Highpoint card drives? What bootloader ? Thanks - Right now I just boot using GRUB really, perhaps the BIOS hides the 9th sector if it's in some form of RAID mode? I haven't had any trouble using GRUB... I haven't done anything special apart from putting the drives in JBOD mode, each disk is set to JBOD, it's set per disk, so not one large JBOD over 8 disks, but 8 separate JBOD volumes. .. Man, what a quirky BIOS! Okay, so if I connect a drive and don't do anything in the Highpoint BIOS setup, it then corrupts the drive by overwriting the 9th sector on every reboot. But.. if I connect a drive and go into the Highpoint BIOS setup, and "initialize" the drive there, and then set it all as a "JBOD volume", it then leaves the drive content untouched on subsequent reboots. Screwy to the max. So, I might be able to boot from it by cloning the disk *after* setting it to "JBOD" in the BIOS. That will take a (longish) while to do. - 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
[Fwd: Reminder: Last day for submissions to the Storage and Filesystem Workshop.]
Original Message Subject: Reminder: Last day for submissions to the Storage and Filesystem Workshop. Date: Mon, 3 Dec 2007 09:00:17 -0500 From: Chris Mason <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Hello everyone, The deadline for position statements to the Linux Storage and Filesystem Workshop is here. Submitting a position statement is an easy way for you to tell the organizers that you would like to attend, and which topics you are most interesting in. You can find all the details about the workshop here: http://www.usenix.org/events/lsf08/ The Linux Storage and Filesystem Workshop is a small, tightly focused, by-invitation workshop. It is intended to bring together developers and researchers interested in implementing improvements in the Linux filesystem and storage subsystems that can find their way into the mainline kernel and into Linux distributions in the 1â??2 year timeframe. The workshop will be two days and will be separated into storage and filesystem tracks, with some combined plenary sessions. The workshop will be held Feb 25 and 26 in San Jose. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] ide: remove dead code from __ide_dma_test_irq()
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ide-dma.c |6 --
1 file changed, 6 deletions(-)
Index: b/drivers/ide/ide-dma.c
===
--- a/drivers/ide/ide-dma.c
+++ b/drivers/ide/ide-dma.c
@@ -589,12 +589,6 @@ static int __ide_dma_test_irq(ide_drive_
ide_hwif_t *hwif= HWIF(drive);
u8 dma_stat = hwif->INB(hwif->dma_status);
-#if 0 /* do not set unless you know what you are doing */
- if (dma_stat & 4) {
- u8 stat = hwif->INB(IDE_STATUS_REG);
- hwif->OUTB(hwif->dma_status, dma_stat & 0xE4);
- }
-#endif
/* return 1 if INTR asserted */
if ((dma_stat & 4) == 4)
return 1;
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] ide: remove stale changelog from ide-disk.c
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> --- drivers/ide/ide-disk.c | 26 -- 1 file changed, 26 deletions(-) Index: b/drivers/ide/ide-disk.c === --- a/drivers/ide/ide-disk.c +++ b/drivers/ide/ide-disk.c @@ -13,32 +13,6 @@ *and Andre Hedrick <[EMAIL PROTECTED]> * * This is the IDE/ATA disk driver, as evolved from hd.c and ide.c. - * - * Version 1.00move disk only code from ide.c to ide-disk.c - * support optional byte-swapping of all data - * Version 1.01fix previous byte-swapping code - * Version 1.02remove ", LBA" from drive identification msgs - * Version 1.03fix display of id->buf_size for big-endian - * Version 1.04add /proc configurable settings and S.M.A.R.T support - * Version 1.05add capacity support for ATA3 >= 8GB - * Version 1.06get boot-up messages to show full cyl count - * Version 1.07disable door-locking if it fails - * Version 1.08fixed CHS/LBA translations for ATA4 > 8GB, - * process of adding new ATA4 compliance. - * fixed problems in allowing fdisk to see - * the entire disk. - * Version 1.09added increment of rq->sector in ide_multwrite - * added UDMA 3/4 reporting - * Version 1.10request queue changes, Ultra DMA 100 - * Version 1.11added 48-bit lba - * Version 1.12adding taskfile io access method - * Version 1.13added standby and flush-cache for notifier - * Version 1.14added acoustic-wcache - * Version 1.15convert all calls to ide_raw_taskfile - * since args will return register content. - * Version 1.16added suspend-resume-checkpower - * Version 1.17do flush on standby, do flush on ATA < ATA6 - * fix wcache setup. */ #define IDEDISK_VERSION"1.18" - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] ide: remove stale changelog from ide-probe.c
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> --- drivers/ide/ide-probe.c | 18 ++ 1 file changed, 2 insertions(+), 16 deletions(-) Index: b/drivers/ide/ide-probe.c === --- a/drivers/ide/ide-probe.c +++ b/drivers/ide/ide-probe.c @@ -13,22 +13,8 @@ * * This is the IDE probe module, as evolved from hd.c and ide.c. * - * Version 1.00move drive probing code from ide.c to ide-probe.c - * Version 1.01fix compilation problem for m68k - * Version 1.02increase WAIT_PIDENTIFY to avoid CD-ROM locking at boot - * by Andrea Arcangeli - * Version 1.03fix for (hwif->chipset == ide_4drives) - * Version 1.04fixed buggy treatments of known flash memory cards - * - * Version 1.05fix for (hwif->chipset == ide_pdc4030) - * added ide6/7/8/9 - * allowed for secondary flash card to be detectable - * with new flag : drive->ata_flash : 1; - * Version 1.06stream line request queue and prep for cascade project. - * Version 1.07max_sect <= 255; slower disks would get behind and - * then fall over when they get to 256.Paul G. - * Version 1.10Update set for new IDE. drive->id is now always - * valid after probe time even with noprobe + * -- increase WAIT_PIDENTIFY to avoid CD-ROM locking at boot + * by Andrea Arcangeli */ #include - 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 4/6] ide: add ide_busy_sleep() helper
Add ide_busy_sleep() helper and use it in do_probe(),
enable_nest() and probe_hwif().
As a nice side-effect this fixes a minor bug in enable_nest()
(the code was reading status register without any delay).
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ide-probe.c | 43 +--
1 file changed, 21 insertions(+), 22 deletions(-)
Index: b/drivers/ide/ide-probe.c
===
--- a/drivers/ide/ide-probe.c
+++ b/drivers/ide/ide-probe.c
@@ -382,6 +382,20 @@ static int try_to_identify (ide_drive_t
return retval;
}
+static int ide_busy_sleep(ide_hwif_t *hwif)
+{
+ unsigned long timeout = jiffies + WAIT_WORSTCASE;
+ u8 stat;
+
+ do {
+ msleep(50);
+ stat = hwif->INB(hwif->io_ports[IDE_STATUS_OFFSET]);
+ if ((stat & BUSY_STAT) == 0)
+ return 0;
+ } while (time_before(jiffies, timeout));
+
+ return 1;
+}
/**
* do_probe- probe an IDE device
@@ -450,7 +464,6 @@ static int do_probe (ide_drive_t *drive,
if ((rc == 1 && cmd == WIN_PIDENTIFY) &&
((drive->autotune == IDE_TUNE_DEFAULT) ||
(drive->autotune == IDE_TUNE_AUTO))) {
- unsigned long timeout;
printk("%s: no response (status = 0x%02x), "
"resetting drive\n", drive->name,
hwif->INB(IDE_STATUS_REG));
@@ -458,10 +471,7 @@ static int do_probe (ide_drive_t *drive,
hwif->OUTB(drive->select.all, IDE_SELECT_REG);
msleep(50);
hwif->OUTB(WIN_SRST, IDE_COMMAND_REG);
- timeout = jiffies;
- while (((hwif->INB(IDE_STATUS_REG)) & BUSY_STAT) &&
- time_before(jiffies, timeout + WAIT_WORSTCASE))
- msleep(50);
+ (void)ide_busy_sleep(hwif);
rc = try_to_identify(drive, cmd);
}
if (rc == 1)
@@ -489,20 +499,16 @@ static int do_probe (ide_drive_t *drive,
static void enable_nest (ide_drive_t *drive)
{
ide_hwif_t *hwif = HWIF(drive);
- unsigned long timeout;
printk("%s: enabling %s -- ", hwif->name, drive->id->model);
SELECT_DRIVE(drive);
msleep(50);
hwif->OUTB(EXABYTE_ENABLE_NEST, IDE_COMMAND_REG);
- timeout = jiffies + WAIT_WORSTCASE;
- do {
- if (time_after(jiffies, timeout)) {
- printk("failed (timeout)\n");
- return;
- }
- msleep(50);
- } while ((hwif->INB(IDE_STATUS_REG)) & BUSY_STAT);
+
+ if (ide_busy_sleep(hwif)) {
+ printk(KERN_CONT "failed (timeout)\n");
+ return;
+ }
msleep(50);
@@ -783,18 +789,11 @@ static void probe_hwif(ide_hwif_t *hwif)
}
}
if (hwif->io_ports[IDE_CONTROL_OFFSET] && hwif->reset) {
- unsigned long timeout = jiffies + WAIT_WORSTCASE;
- u8 stat;
-
printk(KERN_WARNING "%s: reset\n", hwif->name);
hwif->OUTB(12, hwif->io_ports[IDE_CONTROL_OFFSET]);
udelay(10);
hwif->OUTB(8, hwif->io_ports[IDE_CONTROL_OFFSET]);
- do {
- msleep(50);
- stat = hwif->INB(hwif->io_ports[IDE_STATUS_OFFSET]);
- } while ((stat & BUSY_STAT) && time_after(timeout, jiffies));
-
+ (void)ide_busy_sleep(hwif);
}
local_irq_restore(flags);
/*
-
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 5/6] ide: remove broken disk byte-swapping support
Remove broken disk byte-swapping support:
- it can cause a data corruption on SMP (or if using PREEMPT on UP)
- all data coming from disk are byte-swapped by taskfile_*_data() which
results in incorrect identify data being reported by /proc/ide/ and IOCTLs
- "hdx=bswap/byteswap" kernel parameter has been broken on m68k host drivers
(including Atari Q40 one) since 2.5.x days (because of 'hwif' zero-ing)
- byte-swapping is limited to PIO transfers (for working with TiVo disks on
x86 machines using user-space solutions or dm-byteswap should result in
much better performance because DMA can be used)
For previous discussions please see:
http://www.ussg.iu.edu/hypermail/linux/kernel/0201.0/0768.html
http://lkml.org/lkml/2004/2/28/111
[ I have dm-byteswap device mapper target if somebody is interested
(patch is for 2.6.4 though but I'll dust it off if needed). ]
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
Documentation/ide.txt |4
drivers/ide/ide-disk.c |1 -
drivers/ide/ide-taskfile.c | 32 ++--
drivers/ide/ide.c |6 +-
include/linux/ide.h|1 -
5 files changed, 3 insertions(+), 41 deletions(-)
Index: b/Documentation/ide.txt
===
--- a/Documentation/ide.txt
+++ b/Documentation/ide.txt
@@ -244,10 +244,6 @@ Summary of ide driver parameters for ker
"hdx=nodma" : disallow DMA
- "hdx=swapdata": when the drive is a disk, byte swap all data
-
- "hdx=bswap" : same as above..
-
"hdx=scsi": the return of the ide-scsi flag, this is useful for
allowing ide-floppy, ide-tape, and ide-cdrom|writers
to use ide-scsi emulation on a device specific option.
Index: b/drivers/ide/ide-disk.c
===
--- a/drivers/ide/ide-disk.c
+++ b/drivers/ide/ide-disk.c
@@ -761,7 +761,6 @@ static void idedisk_add_settings(ide_dri
ide_add_setting(drive, "bios_head",SETTING_RW, TYPE_BYTE,
0, 255,
1, 1, &drive->bios_head, NULL);
ide_add_setting(drive, "bios_sect",SETTING_RW, TYPE_BYTE,
0, 63,
1, 1, &drive->bios_sect, NULL);
ide_add_setting(drive, "address", SETTING_RW, TYPE_BYTE,
0, 2,
1, 1, &drive->addressing, set_lba_addressing);
- ide_add_setting(drive, "bswap",SETTING_READ, TYPE_BYTE,
0, 1,
1, 1, &drive->bswap, NULL);
ide_add_setting(drive, "multcount",SETTING_RW, TYPE_BYTE,
0, id->max_multsect,
1, 1, &drive->mult_count, set_multcount);
ide_add_setting(drive, "nowerr", SETTING_RW, TYPE_BYTE,
0, 1,
1, 1, &drive->nowerr, set_nowerr);
ide_add_setting(drive, "lun", SETTING_RW, TYPE_INT,
0, 7,
1, 1, &drive->lun,NULL);
Index: b/drivers/ide/ide-taskfile.c
===
--- a/drivers/ide/ide-taskfile.c
+++ b/drivers/ide/ide-taskfile.c
@@ -35,34 +35,6 @@
#include
#include
-static void ata_bswap_data (void *buffer, int wcount)
-{
- u16 *p = buffer;
-
- while (wcount--) {
- *p = *p << 8 | *p >> 8; p++;
- *p = *p << 8 | *p >> 8; p++;
- }
-}
-
-static void taskfile_input_data(ide_drive_t *drive, void *buffer, u32 wcount)
-{
- HWIF(drive)->ata_input_data(drive, buffer, wcount);
- if (drive->bswap)
- ata_bswap_data(buffer, wcount);
-}
-
-static void taskfile_output_data(ide_drive_t *drive, void *buffer, u32 wcount)
-{
- if (drive->bswap) {
- ata_bswap_data(buffer, wcount);
- HWIF(drive)->ata_output_data(drive, buffer, wcount);
- ata_bswap_data(buffer, wcount);
- } else {
- HWIF(drive)->ata_output_data(drive, buffer, wcount);
- }
-}
-
void ide_tf_load(ide_drive_t *drive, ide_task_t *task)
{
ide_hwif_t *hwif = drive->hwif;
@@ -352,9 +324,9 @@ static void ide_pio_sector(ide_drive_t *
/* do the actual data transfer */
if (write)
- taskfile_output_data(drive, buf, SECTOR_WORDS);
+ hwif->ata_output_data(drive, buf, SECTOR_WORDS);
else
- taskfile_input_data(drive, buf, SECTOR_WORDS);
+ hwif->ata_input_data(drive, buf, SECTOR_WORDS);
kunmap_atomic(buf, KM_BIO_SRC_IRQ);
#ifdef CONFIG_HIGHMEM
Index: b/drivers/ide/ide.c
===
--- a/drivers/ide/ide.c
+++ b/drivers/ide/ide.c
@@ -1297,7 +1297,7 @@ static int __in
[PATCH 6/6] cmd64x: remove /proc/ide/cmd64x
This belongs to user-space (and only if really needed).
textdata bss dec hex filename
3874 180 284082 ff2 drivers/ide/pci/cmd64x.o.before
2231 180 02411 96b drivers/ide/pci/cmd64x.o.after
Additionaly to being bloat the code contained two bugs:
- incorrect UDMA modes were reported for reserved values of UDIDETCR0/1 regs
- MRDMODE_BLK_CH0/1 bits are not defined on CMD643 and early CMD646 revisions
Also while at it remove unused CNTRL_DIS_RA0/1 defines.
Cc: Sergei Shtylyov <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/pci/cmd64x.c | 114 ---
1 file changed, 1 insertion(+), 113 deletions(-)
Index: b/drivers/ide/pci/cmd64x.c
===
--- a/drivers/ide/pci/cmd64x.c
+++ b/drivers/ide/pci/cmd64x.c
@@ -1,5 +1,5 @@
/*
- * linux/drivers/ide/pci/cmd64x.c Version 1.51Nov 8, 2007
+ * linux/drivers/ide/pci/cmd64x.c Version 1.52Dec 2, 2007
*
* cmd64x.c: Enable interrupts at initialization time on Ultra/PCI machines.
* Due to massive hardware bugs, UltraDMA is only supported
@@ -22,8 +22,6 @@
#include
-#define DISPLAY_CMD64X_TIMINGS
-
#define CMD_DEBUG 0
#if CMD_DEBUG
@@ -37,11 +35,6 @@
*/
#define CFR0x50
#define CFR_INTR_CH0 0x04
-#define CNTRL 0x51
-#define CNTRL_ENA_1ST0x04
-#define CNTRL_ENA_2ND0x08
-#define CNTRL_DIS_RA00x40
-#define CNTRL_DIS_RA10x80
#defineCMDTIM 0x52
#defineARTTIM0 0x53
@@ -60,108 +53,13 @@
#define MRDMODE0x71
#define MRDMODE_INTR_CH0 0x04
#define MRDMODE_INTR_CH1 0x08
-#define MRDMODE_BLK_CH0 0x10
-#define MRDMODE_BLK_CH1 0x20
-#define BMIDESR0 0x72
#define UDIDETCR0 0x73
#define DTPR0 0x74
#define BMIDECR1 0x78
#define BMIDECSR 0x79
-#define BMIDESR1 0x7A
#define UDIDETCR1 0x7B
#define DTPR1 0x7C
-#if defined(DISPLAY_CMD64X_TIMINGS) && defined(CONFIG_IDE_PROC_FS)
-#include
-#include
-
-static u8 cmd64x_proc = 0;
-
-#define CMD_MAX_DEVS 5
-
-static struct pci_dev *cmd_devs[CMD_MAX_DEVS];
-static int n_cmd_devs;
-
-static char * print_cmd64x_get_info (char *buf, struct pci_dev *dev, int index)
-{
- char *p = buf;
- u8 reg72 = 0, reg73 = 0;/* primary */
- u8 reg7a = 0, reg7b = 0;/* secondary */
- u8 reg50 = 1, reg51 = 1, reg57 = 0, reg71 = 0; /* extra */
-
- p += sprintf(p, "\nController: %d\n", index);
- p += sprintf(p, "PCI-%x Chipset.\n", dev->device);
-
- (void) pci_read_config_byte(dev, CFR, ®50);
- (void) pci_read_config_byte(dev, CNTRL, ®51);
- (void) pci_read_config_byte(dev, ARTTIM23, ®57);
- (void) pci_read_config_byte(dev, MRDMODE, ®71);
- (void) pci_read_config_byte(dev, BMIDESR0, ®72);
- (void) pci_read_config_byte(dev, UDIDETCR0, ®73);
- (void) pci_read_config_byte(dev, BMIDESR1, ®7a);
- (void) pci_read_config_byte(dev, UDIDETCR1, ®7b);
-
- /* PCI0643/6 originally didn't have the primary channel enable bit */
- if ((dev->device == PCI_DEVICE_ID_CMD_643) ||
- (dev->device == PCI_DEVICE_ID_CMD_646 && dev->revision < 3))
- reg51 |= CNTRL_ENA_1ST;
-
- p += sprintf(p, " Primary Channel "
- " Secondary Channel \n");
- p += sprintf(p, " %s %s\n",
-(reg51 & CNTRL_ENA_1ST) ? "enabled " : "disabled",
-(reg51 & CNTRL_ENA_2ND) ? "enabled " : "disabled");
- p += sprintf(p, " drive0 - drive1 "
- " drive0 - drive1 --\n");
- p += sprintf(p, "DMA enabled: %s %s"
- " %s %s\n",
- (reg72 & 0x20) ? "yes" : "no ", (reg72 & 0x40) ? "yes" : "no ",
- (reg7a & 0x20) ? "yes" : "no ", (reg7a & 0x40) ? "yes" : "no ");
- p += sprintf(p, "UltraDMA mode: %s (%c) %s (%c)",
- ( reg73 & 0x01) ? " on" : "off",
- ((reg73 & 0x30) == 0x30) ? ((reg73 & 0x04) ? '3' : '0') :
- ((reg73 & 0x30) == 0x20) ? ((reg73 & 0x04) ? '3' : '1') :
- ((reg73 & 0x30) == 0x10) ? ((reg73 & 0x04) ? '4' : '2') :
- ((reg73 & 0x30) == 0x00) ? ((reg73 & 0x04) ? '5' : '2') : '?',
- ( reg73 & 0x02) ? " on" : "off",
- ((reg73 & 0xC0) == 0xC0) ? ((reg73 & 0x08) ? '3' : '0') :
- ((reg73 & 0xC0) == 0x80) ? ((reg73 & 0x08) ? '3' : '1') :
- ((reg73 & 0xC0) == 0x40) ? ((reg73 & 0x08) ? '4' : '2') :
- ((reg73
Re: [PATCH] sata_mv: Fix broken Marvell 7042 support.
> Man, what a quirky BIOS! > > Okay, so if I connect a drive and don't do anything in the Highpoint BIOS > setup, > it then corrupts the drive by overwriting the 9th sector on every reboot. > > But.. if I connect a drive and go into the Highpoint BIOS setup, > and "initialize" the drive there, and then set it all as a "JBOD volume", > it then leaves the drive content untouched on subsequent reboots. > > Screwy to the max. > > So, I might be able to boot from it by cloning the disk *after* setting > it to "JBOD" in the BIOS. That will take a (longish) while to do. I've just managed to boot with PXE and 2.6.23.9 and I have come to the following: * softraid still works * sata_mv is a bit slower than the proprietary highpoint drivers (I get 300MB/s from my array rather than 400MB/s) * they array works * the content of the array seems to have shifted 'down' a bit, that's probably why it won't boot. it's a tad weird, but I can see the data just fine when I dump the content of the drives, but it seems to be in the wrong place. I'll recreate my volumes with sata_mv now, see if it will work like this. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - 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 26/28] blk_end_request: changing ide-cd (take 3)
Hi Bartlomiej,
On Sat, 1 Dec 2007 23:42:51 +0100, Bartlomiej Zolnierkiewicz <[EMAIL
PROTECTED]> wrote:
> On Saturday 01 December 2007, Kiyoshi Ueda wrote:
> > This patch converts ide-cd (cdrom_newpc_intr()) to use blk_end_request().
> >
> > ide-cd (cdrom_newpc_intr()) has some tricky behaviors below which
> > need to use blk_end_request_callback().
> > Needs to:
> > 1. call post_transform_command() to modify request contents
>
> Seems like post_transform_command() call can be removed (patch below).
>
> > 2. wait completing request until DRQ_STAT is cleared
>
> Would be great if somebody convert cdrom_newpc_intr() to use scatterlists
> also for PIO transfers (ide_pio_sector() in ide-taskfile.c should serve
> as a good starting base to see how to do PIO transfers using scatterlists)
> so we could get rid of partial request completions in cdrom_newpc_intr()
> and just fully complete request when the transfer is done. Shouldn't be
> difficult but I guess that we can live with blk_end_request_callback() for
> the time being...
>
> > after end_that_request_first() and before end_that_request_last().
> >
> > As for the second one, ide-cd will wait for the interrupt from device.
> > So blk_end_request_callback() has to return without completing request
> > even if no leftover in the request.
> > ide-cd uses a dummy callback function, which just returns value '1',
> > to tell blk_end_request_callback() about that.
> >
> > Signed-off-by: Kiyoshi Ueda <[EMAIL PROTECTED]>
> > Signed-off-by: Jun'ichi Nomura <[EMAIL PROTECTED]>
>
> [PATCH] ide-cd: remove dead post_transform_command()
>
> post_transform_command() call in cdrom_newpc_intr() has no effect because
> it is done after the request has already been fully completed (rq->bio and
> rq->data are always NULL). It was verified to be true regardless whether
> INQUIRY command is using DMA or PIO to transfer data (by using modified
> Tejun Heo's test-shortsg.c utility and adding a few printk()-s to ide-cd).
>
> This was uncovered thanks to the "blk_end_request: full I/O completion
> handler (take 3)" patch series from Kiyoshi Ueda.
>
> Cc: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Cc: Kiyoshi Ueda <[EMAIL PROTECTED]
> Cc: Jun'ichi Nomura <[EMAIL PROTECTED]>
> Cc: Tejun Heo <[EMAIL PROTECTED]>
> Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
> ---
> Kiyoshi: please rebase your patch on top of this one (I'll send
> it to Linus in the next IDE update), should make your patch a bit
> simpler.
>
> Tejun: you had really good timing with posting test-shortsg.c
> (it saved me some time coding user-space SG_IO tester), thanks!
>
> drivers/ide/ide-cd.c | 28
> 1 file changed, 28 deletions(-)
>
> Index: b/drivers/ide/ide-cd.c
> ===
> --- a/drivers/ide/ide-cd.c
> +++ b/drivers/ide/ide-cd.c
> @@ -1650,31 +1650,6 @@ static int cdrom_write_check_ireason(ide
> return 1;
> }
>
> -static void post_transform_command(struct request *req)
> -{
> - u8 *c = req->cmd;
> - char *ibuf;
> -
> - if (!blk_pc_request(req))
> - return;
> -
> - if (req->bio)
> - ibuf = bio_data(req->bio);
> - else
> - ibuf = req->data;
> -
> - if (!ibuf)
> - return;
> -
> - /*
> - * set ansi-revision and response data as atapi
> - */
> - if (c[0] == GPCMD_INQUIRY) {
> - ibuf[2] |= 2;
> - ibuf[3] = (ibuf[3] & 0xf0) | 2;
> - }
> -}
> -
> typedef void (xfer_func_t)(ide_drive_t *, void *, u32);
>
> /*
> @@ -1810,9 +1785,6 @@ static ide_startstop_t cdrom_newpc_intr(
> return ide_started;
>
> end_request:
> - if (!rq->data_len)
> - post_transform_command(rq);
> -
> spin_lock_irqsave(&ide_lock, flags);
> blkdev_dequeue_request(rq);
> end_that_request_last(rq, 1);
Thank you for the comments.
I rebased my patch on top of 2.6.24-rc3-mm2 + the patch to remove
post_transform_command().
As a result, one callback function for DMA mode has been removed.
What do you think about the patch below?
Subject: [PATCH 26/28] blk_end_request: changing ide-cd (take 3)
This patch converts ide-cd (cdrom_newpc_intr()) to use blk_end_request
interfaces.
In PIO mode, ide-cd (cdrom_newpc_intr()) needs to defer
end_that_request_last() until the device clears DRQ_STAT and raises
an interrupt after end_that_request_first().
So blk_end_request() has to return without completing request
even if no leftover in the request.
ide-cd uses blk_end_request_callback() and a dummy callback function,
which just returns value '1', to tell blk_end_request_callback()
about that.
Signed-off-by: Kiyoshi Ueda <[EMAIL PROTECTED]>
Signed-off-by: Jun'ichi Nomura <[EMAIL PROTECTED]>
---
drivers/ide/ide-cd.c | 49 +++--
1 files changed, 35 insertions(+), 14 deletions(-)
Index: 2.6.24-rc3-mm2/drivers/ide/ide-cd.c
===
reset IOCTLs
Can somebody tell me what is the difference between these reset commands (I'm developing an open source application and I would like to know this): one is in the cdrom.h (CDROMRESET - 0x5312), and the second with the third are in the hdreg.h (HDIO_DRIVE_RESET - 0x031c, WIN_DEVICE_RESET - 0x08) Thanks Kantor Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs - 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.
> Man, what a quirky BIOS! Hum... I can pvcreate on the md device just fine, but after that, pvscan won't find it... I have a suspicion that there's a BIOS doing some sector hiding or replacement of sorts... *facepalm* -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - 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 09/28] blk_end_request: changing ps3disk (take 3)
Hi Geert,
On Sun, 2 Dec 2007 10:34:56 +0100 (CET), Geert Uytterhoeven <[EMAIL PROTECTED]>
wrote:
> On Fri, 30 Nov 2007, Kiyoshi Ueda wrote:
> > This patch converts ps3disk to use blk_end_request().
> ^^^
> Patch subject and description are inconsistent with actual change.
>
> > Signed-off-by: Kiyoshi Ueda <[EMAIL PROTECTED]>
> > Signed-off-by: Jun'ichi Nomura <[EMAIL PROTECTED]>
> > ---
> > drivers/block/ps3disk.c |6 +-
> > 1 files changed, 1 insertion(+), 5 deletions(-)
> >
> > Index: 2.6.24-rc3-mm2/drivers/block/ps3disk.c
> > ===
> > --- 2.6.24-rc3-mm2.orig/drivers/block/ps3disk.c
> > +++ 2.6.24-rc3-mm2/drivers/block/ps3disk.c
> > @@ -280,11 +280,7 @@ static irqreturn_t ps3disk_interrupt(int
> > }
> >
> > spin_lock(&priv->lock);
> > - if (!end_that_request_first(req, uptodate, num_sectors)) {
> > - add_disk_randomness(req->rq_disk);
> > - blkdev_dequeue_request(req);
> > - end_that_request_last(req, uptodate);
> > - }
> > + __blk_end_request(req, uptodate, num_sectors << 9);
> ^
Thank you for the comment.
The description meant the blk_end_request family, not actual function,
blk_end_request(). But as you pointed out, it is misleading.
I'll change the description of all related patches.
Thanks,
Kiyoshi Ueda
-
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.
On Mon, 03 Dec 2007 23:48:44 +0100 Hein-Pieter van Braam <[EMAIL PROTECTED]> wrote: > > Man, what a quirky BIOS! > > Hum... I can pvcreate on the md device just fine, but after that, pvscan > won't find it... > > I have a suspicion that there's a BIOS doing some sector hiding or > replacement of sorts... > > *facepalm* That would make sense. However we have weapons to make it surrender. See the "dmraid" tool - you should be able to use that as an example of how to set up device mapper mapped linear mappings to "unshift" partitions. Alan - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sata_mv: Fix broken Marvell 7042 support.
Mark Lord wrote: Mark Lord wrote: Alan Cox wrote: Confirmed. It writes "lgcy" + stuff into the 9th sector of the drive (for my "Legacy" drive). Thats quite nasty. Given that users putting volumes unpartitioned on drives may see actual data corruption and loss perhaps we should blacklist that controller variant with a large warning ? .. Yeah, that's quite obnoxious of Highpoint to just arbitrarily overwrite data. Some warnings would probably be quite useful here. We could log a WARNING the first few times (after boot) whenever we see software writing to that sector. Do this with a hack in mv_qc_prep or mv_qc_issue ? Or even just fail any write to that sector, so that the error gets propagated all the way back to usermode where it might be visible? Plus some big nasty "awareness" messages at boot regardless. ... Something like this, perhaps. Comments, suggestions ? .. I'm not convinced that the big sledgehammer (previous patch which snooped for access to the sector that sometimes is overwritten by BIOS) is useful or does any good here. The problem is, just by powering-on with a drive connected to the RocketRAID, one may have already toasted that sector, long before Linux/sata_mv ever get to see it or warn about it. So, at a minimum, we do need to print some kind of disclaimer message to show that we're at least aware of it. But beyond that, I don't think there's anything *really* useful to do. Comments? I'll cook up a patch for 2.6.24 that detects and warns when a PCIe RocketRAID is found. But do *all* HighPoint "RAID" cards do the same thing? Anyone out there got hardware other than a 2300/2310 ? 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] sata_mv: Fix broken Marvell 7042 support.
On Mon, 2007-12-03 at 23:10 +, Alan Cox wrote: > On Mon, 03 Dec 2007 23:48:44 +0100 > Hein-Pieter van Braam <[EMAIL PROTECTED]> wrote: > > > > Man, what a quirky BIOS! > > > > Hum... I can pvcreate on the md device just fine, but after that, pvscan > > won't find it... > > > > I have a suspicion that there's a BIOS doing some sector hiding or > > replacement of sorts... > > > > *facepalm* > > That would make sense. However we have weapons to make it surrender. See > the "dmraid" tool - you should be able to use that as an example of how > to set up device mapper mapped linear mappings to "unshift" partitions. > > Alan I did some testing: First I zero'd the first 80 meg of the md device, then read it back and compared, still all zero's. Then I rebooted and compared again, still all zero's Then I got 8MB of stuff from /dev/urandom, wrote it to a file then wrote it to md device, read it back into a separate file, they still matched. I rebooted and read it back for a third time, and they still matched. I'm not sure if this means anything or not, but I was wondering if my assertion of BIOS muckery still made sense HP -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - 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 did some testing: First I zero'd the first 80 meg of the md device, then read it back and compared, still all zero's. Then I rebooted and compared again, still all zero's Then I got 8MB of stuff from /dev/urandom, wrote it to a file then wrote it to md device, read it back into a separate file, they still matched. I rebooted and read it back for a third time, and they still matched. I'm not sure if this means anything or not, but I was wondering if my assertion of BIOS muckery still made sense .. I haven't seen any evidence of it here, either, so long as BIOS "JBOD volumes" are used. So I don't have any explanation for your data "moving around" when you switched drivers, unless *their* driver remaps things at run-time. Or were you switching drivers across those reboots (likely, I suppose)? - 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.
Alan Cox wrote: On Mon, 03 Dec 2007 23:48:44 +0100 Hein-Pieter van Braam <[EMAIL PROTECTED]> wrote: Man, what a quirky BIOS! Hum... I can pvcreate on the md device just fine, but after that, pvscan won't find it... I have a suspicion that there's a BIOS doing some sector hiding or replacement of sorts... *facepalm* That would make sense. However we have weapons to make it surrender. See the "dmraid" tool - you should be able to use that as an example of how to set up device mapper mapped linear mappings to "unshift" partitions. ... Ahh.. So dmraid is a way to work with using the HighPoint BIOS to define RAIDs. But not so advisable for maintaining adaptor-neutral pure Linux s/w RAID. Right? - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sata_mv: Fix broken Marvell 7042 support.
Alan Cox wrote: On Mon, 03 Dec 2007 23:48:44 +0100 Hein-Pieter van Braam <[EMAIL PROTECTED]> wrote: Man, what a quirky BIOS! Hum... I can pvcreate on the md device just fine, but after that, pvscan won't find it... I have a suspicion that there's a BIOS doing some sector hiding or replacement of sorts... .. Alan, what do we currently do (or not) with regards to HPAs in libata? - 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.
On Mon, 03 Dec 2007 18:33:10 -0500 Mark Lord <[EMAIL PROTECTED]> wrote: > Alan Cox wrote: > > On Mon, 03 Dec 2007 23:48:44 +0100 > > Hein-Pieter van Braam <[EMAIL PROTECTED]> wrote: > > > >>> Man, what a quirky BIOS! > >> Hum... I can pvcreate on the md device just fine, but after that, pvscan > >> won't find it... > >> > >> I have a suspicion that there's a BIOS doing some sector hiding or > >> replacement of sorts... > >> > >> *facepalm* > > > > That would make sense. However we have weapons to make it surrender. See > > the "dmraid" tool - you should be able to use that as an example of how > > to set up device mapper mapped linear mappings to "unshift" partitions. > ... > > Ahh.. So dmraid is a way to work with using the HighPoint BIOS to define > RAIDs. > But not so advisable for maintaining adaptor-neutral pure Linux s/w RAID. dmraid is a tool which knows large numbers of vendor "secret so the customer can't swap vendor easily" type disk formats. It then translates them into logical mappings using the dm layer, just as LVM2 does. http://people.redhat.com/~heinzm/sw/dmraid/readme - 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: Man, what a quirky BIOS! Okay, so if I connect a drive and don't do anything in the Highpoint BIOS setup, it then corrupts the drive by overwriting the 9th sector on every reboot. But.. if I connect a drive and go into the Highpoint BIOS setup, and "initialize" the drive there, and then set it all as a "JBOD volume", it then leaves the drive content untouched on subsequent reboots. Screwy to the max. So, I might be able to boot from it by cloning the disk *after* setting it to "JBOD" in the BIOS. That will take a (longish) while to do. I've just managed to boot with PXE and 2.6.23.9 and I have come to the following: * softraid still works * sata_mv is a bit slower than the proprietary highpoint drivers (I get 300MB/s from my array rather than 400MB/s) .. No worries. That performance number will eventually come up as we develop sata_mv more. NCQ and IRQ-coalescing together oughta do it. They're "on the list". * they array works * the content of the array seems to have shifted 'down' a bit, that's probably why it won't boot. .. Shifted "down" which way, I wonder... ? Maybe they're using a Host Protected Area, which would explain why I don't see them modifying the 9th sector after "initializing" (WTF?) my drive as a JBOD using their BIOS. What does "hdparm -g /dev/sd*" show with their driver and with our driver? - 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 24/28] blk_end_request: changing ide normal caller (take 3)
Hi Bartlomiej,
On Sat, 1 Dec 2007 23:53:05 +0100, Bartlomiej Zolnierkiewicz <[EMAIL
PROTECTED]> wrote:
> On Saturday 01 December 2007, Kiyoshi Ueda wrote:
> > This patch converts "normal" parts of ide to use blk_end_request().
> >
> > Signed-off-by: Kiyoshi Ueda <[EMAIL PROTECTED]>
> > Signed-off-by: Jun'ichi Nomura <[EMAIL PROTECTED]>
> > ---
> > drivers/ide/ide-cd.c |6 +++---
> > drivers/ide/ide-io.c | 17 ++---
> > 2 files changed, 9 insertions(+), 14 deletions(-)
>
> [...]
>
> > Index: 2.6.24-rc3-mm2/drivers/ide/ide-io.c
> > ===
> > --- 2.6.24-rc3-mm2.orig/drivers/ide/ide-io.c
> > +++ 2.6.24-rc3-mm2/drivers/ide/ide-io.c
> > @@ -78,14 +78,9 @@ static int __ide_end_request(ide_drive_t
> > ide_dma_on(drive);
> > }
> >
> > - if (!end_that_request_chunk(rq, uptodate, nr_bytes)) {
> > - add_disk_randomness(rq->rq_disk);
> > - if (dequeue) {
> > - if (!list_empty(&rq->queuelist))
> > - blkdev_dequeue_request(rq);
> > + if (!__blk_end_request(rq, uptodate, nr_bytes)) {
> > + if (dequeue)
> > HWGROUP(drive)->rq = NULL;
> > - }
> > - end_that_request_last(rq, uptodate);
> > ret = 0;
> > }
>
> Hmmm, this seems to change the old behavior (the request should
> be dequeued from the queue only if 'dequeue' variable is set)
> and AFAIR some error handling code (in ide-cd?) depends on the
> old behavior so please revisit this patch.
blk_end_request() takes care of the dequeue like below,
so I think no problem. (Please see PATCH 01)
> + /* rq->queuelist of dequeued request should be list_empty() */
> + if (!list_empty(&rq->queuelist))
> + blkdev_dequeue_request(rq);
In the case of ide-cd,
o 'dequeue' variable is 1 only when the request is still linked
to the queue (i.e. rq->queuelist is not empty)
o 'dequeue' variable is 0 only when the request has already been
removed from the queue (i.e. rq->queuelist is empty)
So blk_end_request() can handle it correctly.
If there are any drivers which don't want dequeue the queued request,
the code above would not work.
But, as far as I investigated, I have never seen such a requirement
in device drivers.
Do you think that ide may still gets a problem for the 'dequeue'?
Thanks,
Kiyoshi Ueda
-
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.
On Mon, 03 Dec 2007 18:47:08 -0500 Mark Lord <[EMAIL PROTECTED]> wrote: > Alan Cox wrote: > > On Mon, 03 Dec 2007 23:48:44 +0100 > > Hein-Pieter van Braam <[EMAIL PROTECTED]> wrote: > > > >>> Man, what a quirky BIOS! > >> Hum... I can pvcreate on the md device just fine, but after that, pvscan > >> won't find it... > >> > >> I have a suspicion that there's a BIOS doing some sector hiding or > >> replacement of sorts... > .. > > Alan, what do we currently do (or not) with regards to HPAs in libata? Older kernels ignore them by default, later ones report them, current one I believe reports them and disables them. However the HPA is the other end of the disk ... - 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: .. also: on a side note, let me state again, that I'm extremely displeased with highpoint at this point... their whole 'open source linux drivers' thing is beginning to piss me off more and more. There must be something that can be done about this? OSI perhaps? .. Their stuff has always seemed more than a little screwy to me. The solution for us here, is sata_mv, which will replace their drivers for this series of boards. But.. Wow! a BIOS that just arbitrarily decides to overwrite a disk sector when one connects some other drive to it, without ever even entering their BIOS setup screen.. And apparently doesn't even need to, since it does NOT seem to do the same thing to drives that are configured as JBOD within their BIOS. Ugh. 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: Hein-Pieter van Braam wrote: .. also: on a side note, let me state again, that I'm extremely displeased with highpoint at this point... their whole 'open source linux drivers' thing is beginning to piss me off more and more. There must be something that can be done about this? OSI perhaps? .. Their stuff has always seemed more than a little screwy to me. The solution for us here, is sata_mv, which will replace their drivers for this series of boards. But.. Wow! a BIOS that just arbitrarily decides to overwrite a disk sector when one connects some other drive to it, without ever even entering their BIOS setup screen.. And apparently doesn't even need to, since it does NOT seem to do the same thing to drives that are configured as JBOD within their BIOS. Ugh. .. Say.. the 2300 board I have here has BIOS 1.0 on it. Their website shows BIOS 2.2 available for download, along with a Linux utility to burn it. Mmmm.. What version BIOS is on your copies of the 2300 ?? - 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.
> Their stuff has always seemed more than a little screwy to me. > > The solution for us here, is sata_mv, which will replace their drivers > for this series of boards. > It just seriously pisses me off that because of their advertising 'Open Source drivers' they now sold ELEVEN of their boards more than they would have otherwise... I'm just bitching I guess... > But.. Wow! a BIOS that just arbitrarily decides to overwrite a disk sector > when one connects some other drive to it, without ever even entering their > BIOS setup screen.. And apparently doesn't even need to, since it does NOT > seem to do the same thing to drives that are configured as JBOD within > their BIOS. > Indeed, had I known any of this, I most certainly would have gone for 3-ware... > Ugh. > > Cheers -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - 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] sata_mv: Warn about Highpoint RocketRAID BIOS treatment of "Legacy" drives
The Highpoint RocketRAID boards using Marvell 7042 chips
overwrite the 9th sector of attached drives at boot time,
when those drives are configured as "Legacy" (the default)
in the HighPoint BIOS.
This kills GRUB, and probably other stuff.
But it all happens *before* Linux is even loaded.
So, for now we'll log a WARNING when such boards are detected,
and advise users to configure BIOS "JBOD" volumes instead,
which don't appear to suffer from this problem.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
Patch is for 2.6.24.
--- old/drivers/ata/sata_mv.c 2007-12-03 15:29:43.0 -0500
+++ linux/drivers/ata/sata_mv.c 2007-12-03 19:15:23.0 -0500
@@ -2503,6 +2503,15 @@
case chip_7042:
hp_flags |= MV_HP_PCIE;
+ if (pdev->vendor == PCI_VENDOR_ID_TTI
+&& (pdev->device == 0x2300 || pdev->device == 0x2310))
+ {
+ printk(KERN_WARNING "sata_mv: Highpoint RocketRAID BIOS"
+ " will corrupt attached drives when"
+ " configured as \"Legacy\". BEWARE!\n");
+ printk(KERN_WARNING "sata_mv: Use BIOS \"JBOD\" volumes"
+ " instead for safety.\n");
+ }
case chip_6042:
hpriv->ops = &mv6xxx_ops;
hp_flags |= MV_HP_GEN_IIE;
-
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.
> I haven't seen any evidence of it here, either, > so long as BIOS "JBOD volumes" are used. > > So I don't have any explanation for your data "moving around" > when you switched drivers, unless *their* driver remaps things > at run-time. > > Or were you switching drivers across those reboots (likely, I suppose)? > - No, I wasn't, I still have to try that, but I nuked my filesystem, so I have to rebuild my kernel... over NFS this time since I don't have any filesystem modules anymore, so things are slow... it's been building for an hour now. I'll come up with the hdparm -g output and the results of this test with the two different drivers tomorrow. also: on a side note, let me state again, that I'm extremely displeased with highpoint at this point... their whole 'open source linux drivers' thing is beginning to piss me off more and more. There must be something that can be done about this? OSI perhaps? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - 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: Issuing a vendor specific ATA cmd on SATA Disk via ATA Pass Thru
sam song wrote: > [USI]: ata pass through(16) cdb: 85 0b 06 00 41 00 00 00 00 00 00 00 00 e0 > fd 00 > [: 85 0b 06 00 41 00 00 00 00 00 00 00 00 e0 fd 00 ] > scsi_status=0x2, host_status=0x0, driver_status=0x8 > info=0x1 duration=8184280 milliseconds [--snip--] > ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen > ata2.00: cmd fd/41:00:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 33280 out > res 40/00:01:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) > ata2: port is slow to respond, please be patient (Status 0xd0) > ata2: device not ready (errno=-16), forcing hardreset > ata2: soft resetting port > ata2.00: configured for UDMA/133 > ata2: EH complete > sd 2:0:0:0: [sdb] 1953525168 512-byte hardware sectors (1000205 MB) > sd 2:0:0:0: [sdb] Write Protect is off > sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00 > sd 2:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support > DPO or FUA Hmmm... It's timeout. How long does the command take? It's a bit weird because 36000s but the reported command duration is 136s. How long did the command take actually? -- 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: Issuing a vendor specific ATA cmd on SATA Disk via ATA Pass Thru
> sam song wrote: > > [USI]: ata pass through(16) cdb: 85 0b 06 00 41 00 00 00 00 00 00 00 00 e0 > > fd 00 > > [: 85 0b 06 00 41 00 00 00 00 00 00 00 00 e0 fd 00 ] > > scsi_status=0x2, host_status=0x0, driver_status=0x8 > > info=0x1 duration=8184280 milliseconds > [--snip--] > > ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen > > ata2.00: cmd fd/41:00:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 33280 out > > res 40/00:01:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) > > ata2: port is slow to respond, please be patient (Status 0xd0) > > ata2: device not ready (errno=-16), forcing hardreset > > ata2: soft resetting port > > ata2.00: configured for UDMA/133 > > ata2: EH complete > > sd 2:0:0:0: [sdb] 1953525168 512-byte hardware sectors (1000205 MB) > > sd 2:0:0:0: [sdb] Write Protect is off > > sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00 > > sd 2:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA > > Hmmm... It's timeout. How long does the command take? It's a bit weird > because 36000s but the reported command duration is 136s. How long did > the command take actually? The command did actually take 136minutes25seconds. I set the timeout in app as 36000seconds(10-hour). Thanks so much, Sam Song - 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: Possibly SATA related freeze killed networking and RAID
Phillip Susi wrote: > Tejun Heo wrote: >> Surprise, surprise. There's no way to tell whether the controller >> raised interrupt or not if command is not in progress. As I said >> before, there's no IRQ pending bit. While processing commands, you can >> tell by looking at other status registers but when there's nothing in >> flight and the controller determines it's a good time to raise a >> spurious interrupt, there's no way you can tell. That dang SFF >> interface is like 15+ years old. >> >> But we can still make things pretty robust. We're working on it. > > It sounds like you mean that you know the controller did NOT raise the > interrupt ( intentionally/correctly ) if there was no command in > progress, as opposed to not being able to tell. Unless there is some > condition under which it is valid for the controller to raise an > interrupt when it had no commands in progress? And if that's the case > and there's know way to know WHY, that's a broken design. If everything works correctly, all interrupts can be accounted for. It's just that there's no margin for erratic behaviors and most ATA controllers are built really cheap. So, yeah, it's a 15+ years old half-broken design. -- 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] sata_mv: Fix broken Marvell 7042 support.
Mark Lord wrote: So to boot from a 7042 the only theoretical choice is the Highpoint board, and for that we need to somehow coax it into not overwriting GRUB every time the onboard BIOS reinitializes. .. With the drive set-up as a "JBOD volume" in the HighPoint BIOS, I've now got a system that boots/runs from a single drive attached to the HighPoint 2300 PCIe board (Marvell 7042 - sata_mv). So that much works, which is good! I also then upgraded the card's BIOS from v1.0 to v2.2, and didn't notice anything different. 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: Enabling MSI in sata_nv
Jeff Garzik wrote: > > MSI is pretty flaky, but we default it to 'on' for AHCI, which is the > "enhanced mode" side of the sata_nv chip. If it's new enough. MCP55 has no ahci mode. > So it is likely that it works on newer boards -- but even though Mark > Lord's response was mistaken (he thought sata_mv was being discussed), > he was right too... sata_nv has stability problems and I would prefer > not to enable MSI just yet, until we cure the other problems. Fair enough. Well, just chalk me down as a data point where it seems to be working. --phil - 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: Issuing a vendor specific ATA cmd on SATA Disk via ATA Pass Thru
sam song wrote: =>> Hmmm... It's timeout. How long does the command take? It's a bit weird >> because 36000s but the reported command duration is 136s. How long did >> the command take actually? > > The command did actually take 136minutes25seconds. I set the timeout in app > as 36000seconds(10-hour). Right, 136m. I wonder whether it's hitting some hard timeout limit in the kernel. H... Does the attached patch fix your problem? Thanks. -- tejun diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c index 91c7322..9675b34 100644 --- a/block/scsi_ioctl.c +++ b/block/scsi_ioctl.c @@ -230,7 +230,7 @@ static int blk_fill_sghdr_rq(struct request_queue *q, struct request *rq, rq->cmd_len = hdr->cmd_len; rq->cmd_type = REQ_TYPE_BLOCK_PC; - rq->timeout = (hdr->timeout * HZ) / 1000; + rq->timeout = msecs_to_jiffies(hdr->timeout); if (!rq->timeout) rq->timeout = q->sg_timeout; if (!rq->timeout) @@ -366,7 +366,7 @@ static int sg_io(struct file *file, struct request_queue *q, */ blk_execute_rq(q, bd_disk, rq, 0); - hdr->duration = ((jiffies - start_time) * 1000) / HZ; + hdr->duration = jiffies_to_msecs(jiffies - start_time); return blk_complete_sghdr_rq(rq, hdr, bio); out:
Re: sata_sil issue on 2.6.22
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.
--
tejun
---
drivers/ata/libata-core.c |1 +
drivers/ata/libata-eh.c |2 ++
drivers/ata/sata_sil.c|6 +-
3 files changed, 8 insertions(+), 1 deletion(-)
Index: tree0/drivers/ata/sata_sil.c
===
--- tree0.orig/drivers/ata/sata_sil.c
+++ tree0/drivers/ata/sata_sil.c
@@ -398,11 +398,15 @@ static void sil_host_intr(struct ata_por
ap->eh_info.serror |= serror;
}
+ ata_port_printk(ap, KERN_INFO, "XXX SATA_IRQ, serror=0x%x\n",
+serror);
goto freeze;
}
- if (unlikely(!qc))
+ if (unlikely(!qc)) {
+ ata_port_printk(ap, KERN_INFO, "XXX DMA completion w/o qc\n");
goto freeze;
+ }
if (unlikely(qc->tf.flags & ATA_TFLAG_POLLING)) {
/* this sometimes happens, just clear IRQ */
Index: tree0/drivers/ata/libata-core.c
===
--- tree0.orig/drivers/ata/libata-core.c
+++ tree0/drivers/ata/libata-core.c
@@ -1361,6 +1361,7 @@ unsigned ata_exec_internal_sg(struct ata
/* no internal command while frozen */
if (ap->pflags & ATA_PFLAG_FROZEN) {
spin_unlock_irqrestore(ap->lock, flags);
+ ata_dev_printk(dev, KERN_INFO, "XXX internal cmd on frozen port\n");
return AC_ERR_SYSTEM;
}
Index: tree0/drivers/ata/libata-eh.c
===
--- tree0.orig/drivers/ata/libata-eh.c
+++ tree0/drivers/ata/libata-eh.c
@@ -782,6 +782,8 @@ static void __ata_port_freeze(struct ata
ap->pflags |= ATA_PFLAG_FROZEN;
+ ata_port_printk(ap, KERN_INFO, "XXX freezing port\n");
+ dump_stack();
DPRINTK("ata%u port frozen\n", ap->print_id);
}
a question about interrupt of IDE controller( bug 5637)
Hi, All I have a question about the interrupt of IDE controller. There is a regression between 2.6.13 and 2.6.12. More details can be found in the following link: http://bugzilla.kernel.org/show_bug.cgi?id=5637 When the IDE controller works in legacy mode, the default IRQ for Ide0 interface is 14 and IRQ for Ide1 interface is 15. The default interrupt mode for IRQ14/15 is edge/high. If the interrupt of some PCI devices is routed to IRQ14 or 15 and the interrupt mode is switched to Low/Level, an exception will appear.(If the I/O APIC is used as the Interrupt controller, IRQ14/15 nobody cared for. If the I8259 is used as the interrupt controller, maybe some IDE interrupts will be lost). In the Bug 5637: When the system works in acpi mode, there is no PCI interrupt router for IDE pci device in ACPI tables and OS will guess an interrupt for IDE PCI device, which is obtained from IDE PCI configuration space(The IRQ number is 15). OS will register the IRQ 15 using acpi_register_gsi and switch the interrupt mode of IRQ 15 to Low/level. Because the interrupt mode for IRQ 15 is uncorrect, there will be interrupt flood and the system reports: IRQ 15 nobody cared. How to fix this issue? Is IRQ 14/15 always reserved for the IDE device? 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: Is BIO_RW_FAILFAST really usable?
Neil Brown wrote: I've been looking at use BIO_RW_FAILFAST in md/raid to improve handling of some error cases. This is particularly significant for the DASD driver (s390 specific). I believe it uses optic fibre to connect to the drives. When one of these paths is unplugged, IO requests will block until an operator runs a command to reset the card (or until it is plugged back in). The only way to avoid this blockage is to use BIO_RW_FAILFAST. So we really need BIO_RW_FAILFAST for a reliable RAID1 configuration on DASD drives. However, I just tested BIO_RW_FAILFAST on my SATA drives: controller 02:06.0 RAID bus controller: Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller (rev 02) (not using the cards minimal RAID functionality) and requests fail immediately and always with e.g. sd 2:0:0:0: [sdc] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK end_request: I/O error, dev sdc, sector 2048 So fail fast obviously isn't generally usable. What is the answer here? Is the Silicon Image driver doing the wrong thing, or is DASD doing the wrong thing, or is BIO_RW_FAILFAST under-specified and we really need multiple flags or what? It's a hard thing to implement, in general, for scalability reasons. To make it work, you need to examine each driver's error handling to figure out what "fail fast" really means. Most storage drivers are written to try as hard as possible to complete a request, where "try as hard as possible" can often mean internal retries while trying various multi-path configurations and hardware mode changes. You might be catching SATA in the middle of error handling, for example. So each driver really has a /slight different/ version of "try to complete this request", which has the obvious effects on BIO_RW_FAILFAST. No clue about DASD, but in SATA's case I bet that a media or transfer error could be returned to the system more rapidly, while we continue to try to recover in the background. libata doesn't have any direct knowledge of fail-fast at this point, IIRC. But overall it's a job where you must examine each driver, or set of drivers :/ 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] sata_promise: make pdc_atapi_pkt() use values from qc->tf
Make pdc_atapi_pkt() use values from qc->tf instead of creating its
own. This is to ease future ATAPI handling changes.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: Mikael Pettersson <[EMAIL PROTECTED]>
---
Okay, Mikael says it's good for trying out. Please add this one to
libata-dev#upstream. Thanks.
drivers/ata/sata_promise.c | 34 +-
1 file changed, 13 insertions(+), 21 deletions(-)
Index: work/drivers/ata/sata_promise.c
===
--- work.orig/drivers/ata/sata_promise.c
+++ work/drivers/ata/sata_promise.c
@@ -450,7 +450,7 @@ static void pdc_atapi_pkt(struct ata_que
struct pdc_port_priv *pp = ap->private_data;
u8 *buf = pp->pkt;
u32 *buf32 = (u32 *) buf;
- unsigned int dev_sel, feature, nbytes;
+ unsigned int dev_sel, feature;
/* set control bits (byte 0), zero delay seq id (byte 3),
* and seq id (byte 2)
@@ -473,45 +473,37 @@ static void pdc_atapi_pkt(struct ata_que
buf32[2] = 0; /* no next-packet */
/* select drive */
- if (sata_scr_valid(&ap->link)) {
+ if (sata_scr_valid(&ap->link))
dev_sel = PDC_DEVICE_SATA;
- } else {
- dev_sel = ATA_DEVICE_OBS;
- if (qc->dev->devno != 0)
- dev_sel |= ATA_DEV1;
- }
+ else
+ dev_sel = qc->tf.device;
+
buf[12] = (1 << 5) | ATA_REG_DEVICE;
buf[13] = dev_sel;
buf[14] = (1 << 5) | ATA_REG_DEVICE | PDC_PKT_CLEAR_BSY;
buf[15] = dev_sel; /* once more, waiting for BSY to clear */
buf[16] = (1 << 5) | ATA_REG_NSECT;
- buf[17] = 0x00;
+ buf[17] = qc->tf.nsect;
buf[18] = (1 << 5) | ATA_REG_LBAL;
- buf[19] = 0x00;
+ buf[19] = qc->tf.lbal;
/* set feature and byte counter registers */
- if (qc->tf.protocol != ATA_PROT_ATAPI_DMA) {
+ if (qc->tf.protocol != ATA_PROT_ATAPI_DMA)
feature = PDC_FEATURE_ATAPI_PIO;
- /* set byte counter register to real transfer byte count */
- nbytes = qc->nbytes;
- if (nbytes > 0x)
- nbytes = 0x;
- } else {
+ else
feature = PDC_FEATURE_ATAPI_DMA;
- /* set byte counter register to 0 */
- nbytes = 0;
- }
+
buf[20] = (1 << 5) | ATA_REG_FEATURE;
buf[21] = feature;
buf[22] = (1 << 5) | ATA_REG_BYTEL;
- buf[23] = nbytes & 0xFF;
+ buf[23] = qc->tf.lbam;
buf[24] = (1 << 5) | ATA_REG_BYTEH;
- buf[25] = (nbytes >> 8) & 0xFF;
+ buf[25] = qc->tf.lbah;
/* send ATAPI packet command 0xA0 */
buf[26] = (1 << 5) | ATA_REG_CMD;
- buf[27] = ATA_CMD_PACKET;
+ buf[27] = qc->tf.command;
/* select drive and check DRQ */
buf[28] = (1 << 5) | ATA_REG_DEVICE | PDC_PKT_WAIT_DRDY;
-
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: Is BIO_RW_FAILFAST really usable?
Jeff Garzik wrote: > Neil Brown wrote: >> I've been looking at use BIO_RW_FAILFAST in md/raid to improve >> handling of some error cases. >> >> This is particularly significant for the DASD driver (s390 specific). >> I believe it uses optic fibre to connect to the drives. When one of >> these paths is unplugged, IO requests will block until an operator >> runs a command to reset the card (or until it is plugged back in). Are there any options? This reminds me of Emulex lpfc driver that by default would retry forever but could be configured to fail request after timeout. >> The only way to avoid this blockage is to use BIO_RW_FAILFAST. So >> we really need BIO_RW_FAILFAST for a reliable RAID1 configuration on >> DASD drives. >> >> However, I just tested BIO_RW_FAILFAST on my SATA drives: controller >> >> 02:06.0 RAID bus controller: Silicon Image, Inc. SiI 3114 >> [SATALink/SATARaid] Serial ATA Controller (rev 02) >> >> (not using the cards minimal RAID functionality) and requests fail >> immediately and always with e.g. >> >> sd 2:0:0:0: [sdc] Result: hostbyte=DID_NO_CONNECT >> driverbyte=DRIVER_OK,SUGGEST_OK end_request: I/O error, dev sdc, sector >> 2048 >> >> So fail fast obviously isn't generally usable. >> >> What is the answer here? Is the Silicon Image driver doing the wrong >> thing, or is DASD doing the wrong thing, or is BIO_RW_FAILFAST >> under-specified and we really need multiple flags or what? > > It's a hard thing to implement, in general, for scalability reasons. > > To make it work, you need to examine each driver's error handling to > figure out what "fail fast" really means. > > Most storage drivers are written to try as hard as possible to complete > a request, where "try as hard as possible" can often mean internal > retries while trying various multi-path configurations and hardware mode > changes. You might be catching SATA in the middle of error handling, > for example. > > So each driver really has a /slight different/ version of "try to > complete this request", which has the obvious effects on BIO_RW_FAILFAST. > > No clue about DASD, but in SATA's case I bet that a media or transfer > error could be returned to the system more rapidly, while we continue to > try to recover in the background. Well, FAILFAST is really needed only for redundant configuration (either multipath or RAID). But in this case what is the point of retrying request at all? It just complicates implementation. Just fail request as soon as possible and let upper layer to recover. -andrey > libata doesn't have any direct > knowledge of fail-fast at this point, IIRC. > > But overall it's a job where you must examine each driver, or set of > drivers :/ > > 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 - 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
