Re: [PATCH] ide: hdio.txt update
Greetings Bartlomiej,
I've updated the following
* in_flags modification when out_flags != 0 && in_flags == 0
* more than one -> one or more than one
* tf_{in|out}_flags -> {in|out}_flags as tf_* are in-kernel names
I'll update the taskfile patch series after receiving your comments
about the patches. Also, if you have a big picture for the IDE
driver, do you care to spill? What I have in mind now are
1. Completion-based taskfile (no direct ending/error handling of
requests), so that we can use it for specials/rw_disk/eh/etc...
2. Make specials (set_geometry, set_multmode...) more regular.
3. Do error-handling/resetting in a exception handler thread.
Maybe this and #2 should happen together.
So, please let me know what you think. Updated patch for hdio.txt
follows.
This patch updates Documentation/ioctl/hdio.txt to include more
detailed descriptions about HDIO_DRIVE_{CMD|TASK|TASKFILE} ioctls.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Index: linux-taskfile-ng/Documentation/ioctl/hdio.txt
===
--- linux-taskfile-ng.orig/Documentation/ioctl/hdio.txt 2005-03-11
15:10:59.068016786 +0900
+++ linux-taskfile-ng/Documentation/ioctl/hdio.txt 2005-03-11
15:27:32.718915939 +0900
@@ -573,26 +573,43 @@ HDIO_DRIVE_TASKFILE execute raw taskfil
EFAULTreq_cmd == TASKFILE_IN_OUT (not implemented as of 2.6.8)
EPERM req_cmd == TASKFILE_MULTI_OUT and drive
multi-count not yet set.
-
+ EIO Drive failed the command.
notes:
- [1] Currently (2.6.8), both the input and output buffers are
- copied from the user and written back to the user, even when
- not used. This may be a bug.
-
- [2] The out_flags and in_flags are returned to the user after
- the ioctl completes. Currently (2.6.8) these are the same
- as the input values, unchanged. In the future, they may have
- more significance.
-
- Extreme caution should be used with using this ioctl. A
- mistake can easily corrupt data or hang the system.
-
- The argument to the ioctl is a pointer to a region of memory
- containing a ide_task_request_t structure, followed by an
- optional buffer of data to be transmitted to the drive,
- followed by an optional buffer to receive data from the drive.
+ [1] READ THE FOLLOWING NOTES *CAREFULLY*. THIS IOCTL IS
+ FULL OF GOTCHAS. Extreme caution should be used with using
+ this ioctl. A mistake can easily corrupt data or hang the
+ system.
+
+ [2] Both the input and output buffers are copied from the
+ user and written back to the user, even when not used.
+
+ [3] If one or more bits are set in out_flags and in_flags is
+ zero, the following values are used for in_flags.all and
+ written back into in_flags on completion.
+
+ * IDE_TASKFILE_STD_IN_FLAGS | (IDE_HOB_STD_IN_FLAGS << 8)
+if LBA48 addressing is enabled for the drive
+ * IDE_TASKFILE_STD_IN_FLAGS
+if CHS/LBA28
+
+ The association between in_flags.all and each enable
+ bitfield flips depending on endianess; fortunately, TASKFILE
+ only uses inflags.b.data bit and ignores all other bits.
+ The end result is that, on any endian machines, it has no
+ effect other than modifying in_flags on completion.
+
+ [4] The default value of SELECT is (0xa0|DEV_bit|LBA_bit)
+ except for four drives per port chipsets. For four drives
+ per port chipsets, it's (0xa0|DEV_bit|LBA_bit) for the first
+ pair and (0x80|DEV_bit|LBA_bit) for the second pair.
+
+ [5] The argument to the ioctl is a pointer to a region of
+ memory containing a ide_task_request_t structure, followed
+ by an optional buffer of data to be transmitted to the
+ drive, followed by an optional buffer to receive data from
+ the drive.
Command is passed to the disk drive via the ide_task_request_t
structure, which contains these fields:
@@ -611,11 +628,66 @@ HDIO_DRIVE_TASKFILE execute raw taskfil
out_sizeoutput (user->drive) buffer size, bytes
in_size input (drive->user) buffer size, bytes
- This ioctl does not necessarily respect all flags in the
- out_flags and in_flags values -- some taskfile registers
- may be written or read even if not requested in the flags.
- Unused fields of io_ports[] and hob_ports[] should be set
- to zero.
+ When out_flags is zero, the following registers are loaded.
+
+ HOB_FEATURE If the drive supports LBA48
+ HOB_NSECTOR If the drive supports LBA48
+ HOB_SECTOR If the drive supports LB
Problems with SATA Plextor PX-716SA
Hi, I've just installed a Plextor PX-716SA in my server, and I'm having trouble with it. I can do eject/load with the eject utility, and I can mount DVDs and list the contents, but burning doesn't work at all. Instead of burning start, the drive locks, and I get: Mar 10 17:15:37 [kernel] SCSI error : <1 0 0 0> return code = 0x2 Mar 10 17:17:02 [kernel] ata2: command 0xa0 timeout, stat 0xd0 host_stat 0x20 To make the drive available again, I have to reboot. This behavior is consistent. I've confirmed it both with vanilla 2.6.11 (libata.h edited to enable ATAPI support) and the latest patch set against 2.6.11 available from http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/ The motherboard is an Intel D865GBF with ICH5. I've got a Seagate ST3200822AS attached to the first SATA channel, and the Plextor (fw 1.04) attached to the second. I have two Seagate ST3200822As attached to the primary and secondary PATA channels, one each. If there's any other useful information I can provide, please let me know. TIA - 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
[SATA] libata-2.4 backport queue updated
Updated libata 2.4.x branch to 2.4.30-pre3. Patch URL, BK URL, and list of changes attached. Jeff BK users: bk pull bk://gkernel.bkbits.net/libata-2.4 Patch: http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/2.4.30-pre3-libata1.patch.bz2 This will update the following files: Documentation/DocBook/Makefile|2 Documentation/DocBook/libata.tmpl |5 ++ drivers/pci/quirks.c | 85 ++ drivers/scsi/ahci.c | 15 +- drivers/scsi/ata_piix.c |3 - drivers/scsi/libata-core.c| 24 -- include/linux/ioport.h|1 kernel/ksyms.c|1 kernel/resource.c | 10 9 files changed, 138 insertions(+), 8 deletions(-) through these ChangeSets: Arjan van de Ven: o [libata ata_piix] Use standard headers from include/scsi, not drivers/scsi Brett Russ: o AHCI: fix fatal error int handling Jason Gaston: o [PCI] update SATA PCI quirk for Intel ICH7 Jeff Garzik: o [libata ahci] support ->tf_read hook o [PCI, libata] Fix "combined mode" PCI quirk for ICH6 o [libata ata_piix] re-enable combined mode support o [libata ata_piix] ->qc_prep hook o [libata ata_piix] fix DocBook docs o [libata ata_piix] add ->bmdma_setup hook o [libata] re-merge the rest of the 2.4 junk
Re: [PATCH] Re: AHCI: support for tf_read (RFC)
Brett Russ wrote: Jeff Garzik wrote: I checked the attached patch into a local repository, but haven't yet merged it into libata-dev-2.6, or tested it. Jeff, The below works for me in testing. Can you push into libata-2.6? pulled - 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
More SIL 3112 intrigue
As you might remember, the 3112 was giving us grief by sending a flood of interrupts when doing the IDENTIFY ATAPI DEVICE (0xA1) command. This was on a rev 1,1 chip. When we tried a rev 1.21 chip, the problem was corrected. Now it appears that even the rev 1.21 chip will flood us with interrupts when doing the IDENTIFY ATA DEVICE (0xEC) command. Im getting to not like Silicon Image. - 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
[BK PATCHES] ide-2.6 update
Hi Linus,
Please do a
bk pull bk://bart.bkbits.net/ide-2.6
This will update the following files:
drivers/ide/Kconfig|1
drivers/ide/ide-cd.c | 58
drivers/ide/ide-default.c | 17 ++-
drivers/ide/ide-disk.c | 213 +++--
drivers/ide/ide-floppy.c | 15 ++-
drivers/ide/ide-io.c | 169 ++-
drivers/ide/ide-iops.c | 20
drivers/ide/ide-probe.c| 62 -
drivers/ide/ide-proc.c |8 -
drivers/ide/ide-tape.c | 21 +---
drivers/ide/ide-taskfile.c |6 -
drivers/ide/ide.c | 80
drivers/scsi/ide-scsi.c| 11 ++
include/linux/ide.h|6 -
14 files changed, 329 insertions(+), 358 deletions(-)
through these ChangeSets:
<[EMAIL PROTECTED](none)> (05/03/10 1.2016)
[ide] kill setup_driver_defaults()
* move default_do_request() to ide-default.c
* fix drivers to set ide_driver_t->{do_request,end_request,error,abort}
* kill setup_driver_defaults()
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
<[EMAIL PROTECTED](none)> (05/03/10 1.2015)
[ide] kill ide_driver_t->capacity
* add private /proc/ide/hd?/capacity handlers to ide-{cd,disk,floppy}.c
* use generic proc_ide_read_capacity() for ide-{scsi,tape}.c
* kill ->capacity, default_capacity() and generic_subdriver_entries[]
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
<[EMAIL PROTECTED](none)> (05/03/10 1.2014)
[ide] kill ide_driver_t->pre_reset
Add ide_drive_t->post_reset flag and use it to signal post reset
condition to the ide-tape driver (the only user of ->pre_reset).
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
<[EMAIL PROTECTED](none)> (05/03/10 1.2013)
[ide] fix some rare ide-default vs ide-disk races
Some rare races between ide-default and ide-disk are possible, i.e.:
* ide-default is used, I/O request is triggered (ie. /proc/ide/hd?/identify),
drive->special is cleared silently (so CHS is not initialized properly),
ide-disk is loaded and fails if drive uses CHS
* ide-disk is used, drive is resetted, ide-disk is unloaded, ide-default
takes control over drive and on the first I/O request silently clears
drive->special without restoring settings
Fix them by moving idedisk_{special,pre_reset}() and company to IDE core.
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
<[EMAIL PROTECTED](none)> (05/03/10 1.2012)
[ide] generic Power Management for IDE devices
Move PM code from ide-cd.c and ide-disk.c to IDE core so:
* PM is supported for other ATAPI devices (floppy, tape)
* PM is supported even if specific driver is not loaded
Also s/HWIF(drive)/drive->hwif/ while at it.
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
<[EMAIL PROTECTED](none)> (05/03/10 1.2011)
[ide] fix drive->ready_stat for ATAPI
ATAPI devices ignore DRDY bit so drive->ready_stat must be set to zero.
It is currently done by device drivers (including ide-default fake driver)
but for PMAC driver it is too late as wait_for_ready() may be called during
probe: probe_hwif()->pmac_ide_dma_check()->pmac_ide_{mdma,udma}_enable()->
->pmac_ide_do_setfeature()->wait_for_ready().
Fixup drive->ready_stat just after detecting ATAPI device.
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> (05/03/10 1.2010)
[ide] fix DMA support for LBA48 disks on ALi15x3 (revs < 0xC5)
From: Bram Verweij <[EMAIL PROTECTED]>
The problem seems to be that ide-disk.c tries to use PIO mode for
blocks > 137 GB (which is good), and LBA48 + DMA for blocks <= 137GB
(which is known to be a problem, i.e., this is why the no_lba48_dma
field was introduced in the first place). Attached is a small patch
that makes ide-disk.c use PIO mode for blocks > 137 GB, and LBA28 DMA
(instead of LBA48 DMA) for blocks <= 137 GB.
bart: argh, I forgot about 'lba48' flag; patch slightly modified by me
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Re: AHCI: support for tf_read (RFC)
Jeff Garzik wrote:
I checked the attached patch into a local repository, but haven't yet
merged it into libata-dev-2.6, or tested it.
Jeff,
The below works for me in testing. Can you push into libata-2.6?
Thanks,
BR
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/02/25 18:18:09-05:00 [EMAIL PROTECTED]
# [libata ahci] support ->tf_read hook
#
# drivers/scsi/ahci.c
# 2005/02/25 18:18:03-05:00 [EMAIL PROTECTED] +11 -0
# [libata ahci] support ->tf_read hook
#
diff -Nru a/drivers/scsi/ahci.c b/drivers/scsi/ahci.c
--- a/drivers/scsi/ahci.c 2005-02-25 18:18:23 -05:00
+++ b/drivers/scsi/ahci.c 2005-02-25 18:18:23 -05:00
@@ -177,6 +177,7 @@
static int ahci_port_start(struct ata_port *ap);
static void ahci_port_stop(struct ata_port *ap);
static void ahci_host_stop(struct ata_host_set *host_set);
+static void ahci_tf_read(struct ata_port *ap, struct ata_taskfile *tf);
static void ahci_qc_prep(struct ata_queued_cmd *qc);
static u8 ahci_check_status(struct ata_port *ap);
static u8 ahci_check_err(struct ata_port *ap);
@@ -209,6 +210,8 @@
.check_err = ahci_check_err,
.dev_select = ata_noop_dev_select,
+ .tf_read = ahci_tf_read,
+
.phy_reset = ahci_phy_reset,
.qc_prep = ahci_qc_prep,
@@ -460,6 +463,14 @@
void *mmio = (void *) ap->ioaddr.cmd_addr;
return (readl(mmio + PORT_TFDATA) >> 8) & 0xFF;
+}
+
+static void ahci_tf_read(struct ata_port *ap, struct ata_taskfile *tf)
+{
+ struct ahci_port_priv *pp = ap->private_data;
+ u8 *d2h_fis = pp->rx_fis + RX_FIS_D2H_REG;
+
+ ata_tf_from_fis(d2h_fis, tf);
}
static void ahci_fill_sg(struct ata_queued_cmd *qc)
-
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 UPDATE] drivers/ide/cs5520.c : Use the DMA_{64,32}BIT_MASK constants
On Thu, Mar 10, 2005 at 05:30:12PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Tue, 8 Mar 2005 14:33:58 +0100, Tobias Klauser <[EMAIL PROTECTED]> wrote:
> > Description: Use the DMA_{64,32}BIT_MASK constants from dma-mapping.h
> > when calling pci_set_dma_mask() or pci_set_consistent_dma_mask()
> > See http://marc.theaimsgroup.com/?t=10800199301&r=1&w=2 for details
>
> only DMA_32BIT_MASK constant is used in the patch
I just took the same description for all patches of this series. Some of
them do not include DMA_64BIT_MASK.
> > Signed-off-by: Tobias Klauser <[EMAIL PROTECTED]>
> >
> > --- linux-2.6.11.orig/drivers/ide/pci/cs5520.c 2005-03-02
> > 12:50:39.0 +0100
> > +++ linux-2.6.11/drivers/ide/pci/cs5520.c 2005-03-03
> > 11:46:46.0 +0100
> > @@ -227,7 +227,7 @@ static int __devinit cs5520_init_one(str
> > return 1;
> > }
> > pci_set_master(dev);
> > - if (pci_set_dma_mask(dev, 0x)) {
> > + if (pci_set_dma_mask(dev, DMA_32BIT_MASK)) {
> > printk(KERN_WARNING "cs5520: No suitable DMA available.\n");
> > return -ENODEV;
> > }
>
> You need to include explicitly
> or build will fail for some architectures, i.e. please see:
> http://linus.bkbits.net:8080/linux-2.5/[EMAIL
> PROTECTED]|src/|src/drivers|src/drivers/ide|related/drivers/ide/setup-pci.c
I only compile-tested this patch on x86 and there it worked. So here's an
updated patch:
Signed-off-by: Tobias Klauser <[EMAIL PROTECTED]>
--- linux-2.6.11.orig/drivers/ide/pci/cs5520.c 2005-03-02 12:50:39.0
+0100
+++ linux-2.6.11/drivers/ide/pci/cs5520.c 2005-03-10 17:55:23.894909672
+0100
@@ -51,6 +51,8 @@
#include
#include
+#include
+
struct pio_clocks
{
int address;
@@ -227,7 +229,7 @@ static int __devinit cs5520_init_one(str
return 1;
}
pci_set_master(dev);
- if (pci_set_dma_mask(dev, 0x)) {
+ if (pci_set_dma_mask(dev, DMA_32BIT_MASK)) {
printk(KERN_WARNING "cs5520: No suitable DMA available.\n");
return -ENODEV;
}
-
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: ALI15x3, 200GB HD, dma broken, no_lba48_dma
good catch, I overlooked lba48 flag when introducing no_lba48_dma
I slightly modified your patch:
diff -Nru a/drivers/ide/ide-disk.c b/drivers/ide/ide-disk.c
--- a/drivers/ide/ide-disk.c2005-03-10 16:07:50 +01:00
+++ b/drivers/ide/ide-disk.c2005-03-10 16:07:50 +01:00
@@ -168,6 +168,8 @@
if (hwif->no_lba48_dma && lba48 && dma) {
if (block + rq->nr_sectors > 1ULL << 28)
dma = 0;
+ else
+ lba48 = 0;
}
if (!dma) {
@@ -181,7 +183,7 @@
/* FIXME: SELECT_MASK(drive, 0) ? */
if (drive->select.b.lba) {
- if (drive->addressing == 1) {
+ if (lba48) {
task_ioreg_t tasklets[10];
pr_debug("%s: LBA=0x%012llx\n", drive->name, block);
and applied it, thanks
Bartlomiej
-
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] drivers/ide/cs5520.c : Use the DMA_{64,32}BIT_MASK constants
On Tue, 8 Mar 2005 14:33:58 +0100, Tobias Klauser <[EMAIL PROTECTED]> wrote:
> Hello,
Hi,
> Description: Use the DMA_{64,32}BIT_MASK constants from dma-mapping.h
> when calling pci_set_dma_mask() or pci_set_consistent_dma_mask()
> See http://marc.theaimsgroup.com/?t=10800199301&r=1&w=2 for details
only DMA_32BIT_MASK constant is used in the patch
> Signed-off-by: Tobias Klauser <[EMAIL PROTECTED]>
>
> --- linux-2.6.11.orig/drivers/ide/pci/cs5520.c 2005-03-02 12:50:39.0
> +0100
> +++ linux-2.6.11/drivers/ide/pci/cs5520.c 2005-03-03 11:46:46.0
> +0100
> @@ -227,7 +227,7 @@ static int __devinit cs5520_init_one(str
> return 1;
> }
> pci_set_master(dev);
> - if (pci_set_dma_mask(dev, 0x)) {
> + if (pci_set_dma_mask(dev, DMA_32BIT_MASK)) {
> printk(KERN_WARNING "cs5520: No suitable DMA available.\n");
> return -ENODEV;
> }
You need to include explicitly
or build will fail for some architectures, i.e. please see:
http://linus.bkbits.net:8080/linux-2.5/[EMAIL
PROTECTED]|src/|src/drivers|src/drivers/ide|related/drivers/ide/setup-pci.c
Bartlomiej
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ide: hdio.txt update
Hi,
On Thu, 3 Mar 2005 11:16:38 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote:
> + [2] Both the input and output buffers are copied from the
> + user and written back to the user, even when not used. The
> + out_flags and in_flags are written back to the user after
> + the ioctl completes. These are the same as the input
> + values, unchanged.
This is incorrect, please refer to flagged_taskfile() and ide_taskfile_ioctl().
Unfortunately you've based your latest patch series on this assumption.
> + Taskfile registers are read back from the drive into
> + {io|hob}_ports[] after the command completes iff one of the
> + following conditions is met; otherwise, the original values
> + will be written back, unchanged.
> +
> + 1. The drive fails the command (EIO).
> + 2. More than one bit is set in tf_out_flags.
Isn't one bit enough?
The rest is of the update is fine, thanks for doing this.
Bartlomiej
-
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
sata_via + VT8237 RAID 0 array of 2 s-ata drives
Hi Jeff, a quick question about libata + sata_via V1.10 as included in the most recent kernel 2.6.11.2: I have a MSI KT6V (MS-7021) mainboard with VIA VT-8237 Southbridge and want to connect two S-ATA hard disk drives. Both drives should run in a RAID 0 array, which is to be configured through the S-ATA RAID BIOS on the main board. Is it possible that the sata_via driver recognizes the existence of the array and treats it as one drive under LINUX? As far as I've learned, the VT-8237 is not a real hardware RAID solution and needs some software support from the OS, too. Again, is it possible to do this, or does the driver only support seperate s-ata channels, no matter what is configured in the S-ATA RAID BIOS? If the BIOS configured RAID volumes are not supported at all (any plans for the near future?) what would you recommend to do instead to provide fast and efficient RAID 0 striping for both s-ata drives (to double the r/w data rate). Are there any other limitations with the current sata_via driver concerning VT8237 with two S-ATA drives? Thank you very much for your support and the continued effort to maintain this driver. Best regards, Chris -- DSL Komplett von GMX +++ Supergünstig und stressfrei einsteigen! AKTION "Kein Einrichtungspreis" nutzen: http://www.gmx.net/de/go/dsl - 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
