Re: [RFC] libata-scsi: introducing SANITIZE translation

On 16-07-11 02:35 AM, Tom Yan wrote: I don't suppose there would be any problem doing it in userspace / with ATA PASS-THROUGH anyway. .. On 8 July 2016 at 17:29, James Bottomley wrote: .. Not really. The point is that you've proposed something as an

Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst

-self.no_sg_constraint = 1; Sadly it didn't fix the problem. Did I get the patch right? That sounds almost as if the old version is still being loaded/run, possibly from the initramfs image? -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line

Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst

or something? -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] sd: don't bother spinning up disks on resume

On 13-11-18 10:54 AM, Phillip Susi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/17/2013 8:06 PM, Phillip Susi wrote: I don't see anything particularly inefficient about issuing the command in the eh path ( in fact, libata always uses the eh path to handle power management ).

Re: [PATCH 1/3] sd: don't bother spinning up disks on resume

On 13-11-07 01:21 PM, Douglas Gilbert wrote: On 13-11-06 08:57 PM, Phillip Susi wrote: Don't bother forcing disks to spin up on resume, as they will do so automatically when accessed, and forcing them to spin up slows down the resume. Add a second bit to the manage_start_stop flag to restore

Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern

On 13-10-11 04:41 AM, Alexander Gordeev wrote: On Thu, Oct 10, 2013 at 07:17:18PM -0400, Mark Lord wrote: Just to help us all understand the loop issue.. Here's an example of driver code which uses the existing MSI-X interfaces, for a device which can work with either 16, 8, 4, 2, or 1 MSI-X

Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern

Just to help us all understand the loop issue.. Here's an example of driver code which uses the existing MSI-X interfaces, for a device which can work with either 16, 8, 4, 2, or 1 MSI-X interrupt. This is from a new driver I'm working on right now: static int xx_alloc_msix_irqs (struct xx_dev

Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern

On 13-10-02 06:29 AM, Alexander Gordeev wrote: .. This update converts pci_enable_msix() and pci_enable_msi_block() interfaces to canonical kernel functions and makes them return a error code in case of failure or 0 in case of success. Rather than silently break dozens of drivers in mysterious

Re: [PATCH] Fix libata-eh don't retry command after reset succeeded.

From 9cc9a85f17a8525e53caf430611d762c105d324c Mon Sep 17 00:00:00 2001 From: Bian Yu ycbzzj...@gmail.com Date: Tue, 18 Dec 2012 05:58:34 -0500 Subject: [PATCH] Fix libata-eh don't retry command after reset succeeded. It's introduced by commit 8d899e70c1b3afff, When disk has a UNC error,

Re: [PATCH] Fix libata-eh don't retry command after reset succeeded.

On 13-01-14 09:01 AM, Mark Lord wrote: From 9cc9a85f17a8525e53caf430611d762c105d324c Mon Sep 17 00:00:00 2001 From: Bian Yu ycbzzj...@gmail.com Date: Tue, 18 Dec 2012 05:58:34 -0500 Subject: [PATCH] Fix libata-eh don't retry command after reset succeeded. It's introduced by commit

Re: DMA mapping on SCSI device?

Robert Hancock wrote: Luben Tuikov wrote: --- On Mon, 1/28/08, Robert Hancock [EMAIL PROTECTED] wrote: The trick is that if an ATAPI device is connected, we (as far as I'm aware) can't use ADMA mode, so we have to switch that port into legacy mode. Can you double check this with the HW

Re: DMA mapping on SCSI device?

Mark Lord wrote: .. Commands which were not ADMA compatible (eg. MODE_SENSE, TEST_UNIT_READY, ..) were simply handled with PIO (in the driver) rather than any form of DMA, which is okay because those commands are relatively infrequent. .. A slight correction there: TEST_UNIT_READY was fine

QUEUE_FLAG_CLUSTER: not working in 2.6.24 ?

Jens, I'm experimenting here with trying to generate large I/O through libata, and not having much luck. The limit seems to be the number of hardware PRD (SG) entries permitted by the driver (libata:ata_piix), which is 128 by default. The problem is, the block layer *never* sends an SG entry

QUEUE_FLAG_CLUSTER: not working in 2.6.24 ?

(resending with corrected email address for Jens) Jens, I'm experimenting here with trying to generate large I/O through libata, and not having much luck. The limit seems to be the number of hardware PRD (SG) entries permitted by the driver (libata:ata_piix), which is 128 by default. The

Re: QUEUE_FLAG_CLUSTER: not working in 2.6.24 ?

Mark Lord wrote: (resending with corrected email address for Jens) Jens, I'm experimenting here with trying to generate large I/O through libata, and not having much luck. The limit seems to be the number of hardware PRD (SG) entries permitted by the driver (libata:ata_piix), which is 128

Re: QUEUE_FLAG_CLUSTER: not working in 2.6.24 ?

Matthew Wilcox wrote: On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote: Problem confirmed. 2.6.23.8 regularly generates segments up to 64KB for libata, but 2.6.24 uses only 4KB segments and a *few* 8KB segments. Just a suspicion ... could this be slab vs slub? ie check your

Re: QUEUE_FLAG_CLUSTER: not working in 2.6.24 ?

Jens Axboe wrote: On Thu, Dec 13 2007, Mark Lord wrote: Matthew Wilcox wrote: On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote: Problem confirmed. 2.6.23.8 regularly generates segments up to 64KB for libata, but 2.6.24 uses only 4KB segments and a *few* 8KB segments. Just

Re: QUEUE_FLAG_CLUSTER: not working in 2.6.24 ?

Mark Lord wrote: Jens Axboe wrote: On Thu, Dec 13 2007, Mark Lord wrote: Matthew Wilcox wrote: On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote: Problem confirmed. 2.6.23.8 regularly generates segments up to 64KB for libata, but 2.6.24 uses only 4KB segments and a *few* 8KB

Re: QUEUE_FLAG_CLUSTER: not working in 2.6.24 ?

Jens Axboe wrote: On Thu, Dec 13 2007, Mark Lord wrote: Jens Axboe wrote: On Thu, Dec 13 2007, Mark Lord wrote: Mark Lord wrote: Jens Axboe wrote: On Thu, Dec 13 2007, Mark Lord wrote: Matthew Wilcox wrote: On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote: Problem confirmed

Re: QUEUE_FLAG_CLUSTER: not working in 2.6.24 ?

Jens Axboe wrote: On Thu, Dec 13 2007, Jens Axboe wrote: On Thu, Dec 13 2007, Mark Lord wrote: Jens Axboe wrote: On Thu, Dec 13 2007, Mark Lord wrote: Mark Lord wrote: Jens Axboe wrote: On Thu, Dec 13 2007, Mark Lord wrote: Matthew Wilcox wrote: On Thu, Dec 13, 2007 at 01:48:18PM -0500

Re: QUEUE_FLAG_CLUSTER: not working in 2.6.24 ?

Jens Axboe wrote: On Thu, Dec 13 2007, Mark Lord wrote: Jens Axboe wrote: On Thu, Dec 13 2007, Jens Axboe wrote: On Thu, Dec 13 2007, Mark Lord wrote: Jens Axboe wrote: On Thu, Dec 13 2007, Mark Lord wrote: Mark Lord wrote: Jens Axboe wrote: On Thu, Dec 13 2007, Mark Lord wrote: Matthew

Re: QUEUE_FLAG_CLUSTER: not working in 2.6.24 ?

Mark Lord wrote: Jens Axboe wrote: .. OK, it's a vm issue, I have tens of thousand backward pages after a boot - IOW, bvec-bv_page is the page before bvprv-bv_page, not reverse. So it looks like that bug got reintroduced. ... Mmm.. shouldn't one of the front- or back- merge logics work

Re: QUEUE_FLAG_CLUSTER: not working in 2.6.24 ?

Andrew Morton wrote: On Thu, 13 Dec 2007 17:15:06 -0500 James Bottomley [EMAIL PROTECTED] wrote: On Thu, 2007-12-13 at 14:02 -0800, Andrew Morton wrote: On Thu, 13 Dec 2007 21:09:59 +0100 Jens Axboe [EMAIL PROTECTED] wrote: OK, it's a vm issue, cc linux-mm and probable culprit. I have

Re: QUEUE_FLAG_CLUSTER: not working in 2.6.24 ?

Mark Lord wrote: Andrew Morton wrote: On Thu, 13 Dec 2007 17:15:06 -0500 James Bottomley [EMAIL PROTECTED] wrote: On Thu, 2007-12-13 at 14:02 -0800, Andrew Morton wrote: On Thu, 13 Dec 2007 21:09:59 +0100 Jens Axboe [EMAIL PROTECTED] wrote: OK, it's a vm issue, cc linux-mm and probable

Re: QUEUE_FLAG_CLUSTER: not working in 2.6.24 ?

Mark Lord wrote: Mark Lord wrote: Andrew Morton wrote: On Thu, 13 Dec 2007 17:15:06 -0500 James Bottomley [EMAIL PROTECTED] wrote: On Thu, 2007-12-13 at 14:02 -0800, Andrew Morton wrote: On Thu, 13 Dec 2007 21:09:59 +0100 Jens Axboe [EMAIL PROTECTED] wrote: OK, it's a vm issue, cc linux

Re: QUEUE_FLAG_CLUSTER: not working in 2.6.24 ?

Andrew Morton wrote: On Thu, 13 Dec 2007 19:30:00 -0500 Mark Lord [EMAIL PROTECTED] wrote: Here's the commit that causes the regression: ... --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -760,7 +760,8 @@ static int rmqueue_bulk(struct zone *zone, unsigned int order, struct

[PATCH] fix page_alloc for larger I/O segments

Mark Lord wrote: Mark Lord wrote: Mark Lord wrote: Mark Lord wrote: Andrew Morton wrote: On Thu, 13 Dec 2007 17:15:06 -0500 James Bottomley [EMAIL PROTECTED] wrote: On Thu, 2007-12-13 at 14:02 -0800, Andrew Morton wrote: On Thu, 13 Dec 2007 21:09:59 +0100 Jens Axboe [EMAIL PROTECTED

[PATCH] fix page_alloc for larger I/O segments (improved)

Improved version, more similar to the 2.6.23 code: Fix page allocator to give better chance of larger contiguous segments (again). Signed-off-by: Mark Lord [EMAIL PROTECTED] --- --- old/mm/page_alloc.c 2007-12-13 19:25:15.0 -0500 +++ linux-2.6/mm/page_alloc.c 2007-12-13 19:43

Re: QUEUE_FLAG_CLUSTER: not working in 2.6.24 ?

Mark Lord wrote: Andrew Morton wrote: On Thu, 13 Dec 2007 19:30:00 -0500 Mark Lord [EMAIL PROTECTED] wrote: Here's the commit that causes the regression: ... --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -760,7 +760,8 @@ static int rmqueue_bulk(struct zone *zone, unsigned int order

Re: [PATCH] fix page_alloc for larger I/O segments (improved)

Andrew Morton wrote: On Thu, 13 Dec 2007 19:57:29 -0500 James Bottomley [EMAIL PROTECTED] wrote: On Thu, 2007-12-13 at 19:46 -0500, Mark Lord wrote: Improved version, more similar to the 2.6.23 code: Fix page allocator to give better chance of larger contiguous segments (again). Signed-off

Re: Process Scheduling Issue using sg/libata

Fajun Chen wrote: .. I verified your program works in my system and my application works as well if changed accordingly. However, this change (indirect IO in sg term) may come at a performance cost for IO intensive applications since it does NOT utilize mmaped buffer managed by sg driver.

Re: Process Scheduling Issue using sg/libata

Fajun Chen wrote: As a matter of fact, I'm using /dev/sg*. Due to the size of my test application, I have not be able to compress it into a small and publishable form. However, this issue can be easily reproduced on my ARM XScale target using sg3_util code as follows: 1. Run printtime.c

Re: Process Scheduling Issue using sg/libata

Fajun Chen wrote: On 11/16/07, Mark Lord [EMAIL PROTECTED] wrote: Fajun Chen wrote: Hi All, I use sg/libata and ata pass through for read/writes. Linux 2.6.18-rc2 and libata version 2.00 are loaded on ARM XScale board. Under heavy cpu load (e.g. when blocks per transfer/sector count is set

Re: Process Scheduling Issue using sg/libata

Fajun Chen wrote: On 11/17/07, Mark Lord [EMAIL PROTECTED] wrote: Fajun Chen wrote: On 11/16/07, Mark Lord [EMAIL PROTECTED] wrote: Fajun Chen wrote: .. This problem also happens with R/W DMA ops. Below are simplified code snippets: // Open one sg device for read if ((sg_fd

Re: Process Scheduling Issue using sg/libata

Fajun Chen wrote: Hi All, I use sg/libata and ata pass through for read/writes. Linux 2.6.18-rc2 and libata version 2.00 are loaded on ARM XScale board. Under heavy cpu load (e.g. when blocks per transfer/sector count is set to 1), I've observed that the test application can suck cpu away for

Re: [linux-usb-devel] Problems with USB disk [solved]

Alan Stern wrote: On Wed, 12 Sep 2007, Mark Lord wrote: Chuck Ebbert wrote: .. Oh, nice. The usb-storage (SCSI) disk spins itself down and we can't handle that. Should we be disabling auto-spindown when we connect the device, or be able to handle this by sending the start command when

Re: [linux-usb-devel] Problems with USB disk [solved]

Alan Stern wrote: On Thu, 13 Sep 2007, Mark Lord wrote: .. What happens is, there's a nice little LED on the Cruzer stick, that is lit when the stick itself is not in a power suspend state (or whatever you USB folks call it). We call it suspended. (Wasn't there an episode of Classic Trek

Re: HDIO_DRIVE_CMD and hdparm

Alan Cox wrote: - SCSI doesn't handle HDIO_DRIVE_CMD(null), and returns EINVAL = fine for hdparm - If a block device doesn't support the ioctl, blkdev_driver_ioctl() returns ENOTTY = hdparm error message Those are both correct -ENOTTY I don't know this

Re: HDIO_DRIVE_CMD and hdparm

Geert Uytterhoeven wrote: Hi, `hdparm -t' uses HDIO_DRIVE_CMD(null) to flush the disk's buffer. More correctly, that command is supposed to act like an I/O queue barrier operation, not returning from the syscall until everything queued in front of it has been issued/completed. I

Re: libata /dev/scd0 problem: mount after burn fails without eject

Forwarding to linux-scsi and linux-ide mailing lists. Frank van Maarseveen wrote: Tested on 2.6.20.6 and 2.6.21.1 I decided to swich from the old IDE drivers to libata and now there seems to be a little but annoying problem: cannot mount an ISO image after burning it. May 1 14:32:55 kernel:

Re: [PATCH 4/4] bidi support: bidirectional request

Jens Axboe wrote: So basically just add a struct request pointer, so you can do rq = rq-next_rq or something for the next data phase. I bet this would be a LOT less invasive as well, and we can get by with a few helpers to support it. Hey, I want a way to issue those (linked requests) from

Re: [PATCH] scsi_lib.c: continue after MEDIUM_ERROR

Alan wrote: If this is the right strategy for disk recovery for a given type of device then this ought to be an automatic strategy. Most end users will not have the knowledge to frob about in sysfs, and if the bad sector hits at the wrong moment a sensible automatic recovery strategy is going

Re: [PATCH] scsi_lib.c: continue after MEDIUM_ERROR

Matt Mackall wrote: .. Also worth considering is that spending minutes trying to reread damaged sectors is likely to accelerate your death spiral. More data may be recoverable if you give up quickly in a first pass, then go back and manually retry damaged bits with smaller I/Os. All good

Re: [PATCH] scsi_lib.c: continue after MEDIUM_ERROR

James Bottomley wrote: On Tue, 2007-01-30 at 19:47 -0500, Mark Lord wrote: Kernels since about 2.6.16 or so have been broken in this regard. They complete the good sectors before the error, and then fail the entire remaining portions of the request. What was the commit that introduced

Re: [PATCH] scsi_lib.c: continue after MEDIUM_ERROR

James Bottomley wrote: On Thu, 2007-02-01 at 15:02 -0500, Mark Lord wrote: .. One thing that could be even better than the patch below, would be to have it perhaps skip the entire bio that includes the failed sector, rather than only the bad sector itself. Er ... define skip over the bio

Re: [PATCH] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices

Tejun Heo wrote: Mark Lord wrote: .. So, to achieve ATA passthru capability for libata ATAPI, we have to instead use the ATA_16 opcode: a 16-byte command. SCSI normally disallows issuing 16-byte commands to 12-byte devices, so special support has to be added for this. I might have missed

Re: [PATCH] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices

James Bottomley wrote: .. In SCSI, we're very careful only to use large commands where necessary, so even for a 2TB array, you only see 16 byte commands for sectors beyond 2TB. This essentially means that the capacity (and we do a careful READ_CAPACITY(10) and only move on to READ_CAPACITY(16)

Re: [PATCH] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices

into libata for ATAPI devices. There is a separate related patch already pending to actually implement ATA_16 for ATAPI inside libata. Signed-off-by: Mark Lord [EMAIL PROTECTED] --- --- old/drivers/ata/libata-core.c 2007-01-31 19:55:53.0 -0500 +++ linux/drivers/ata/libata-core.c

Re: [PATCH] scsi_lib.c: continue after MEDIUM_ERROR

Ric Wheeler wrote: Mark Lord wrote: Eric D. Mudama wrote: Actually, it's possibly worse, since each failure in libata will generate 3-4 retries. (note: libata does *not* generate retries for medium errors; the looping is driven by the SCSI mid-layer code). It really beats the alternative

Re: [PATCH] scsi_lib.c: continue after MEDIUM_ERROR

James Bottomley wrote: For the MD case, this is what REQ_FAILFAST is for. I cannot find where SCSI honours that flag. James? And for that matter, even when I patch SCSI so that it *does* honour it, I don't actually see the flag making it into the SCSI layer from above. And I don't see

Re: [PATCH] scsi_lib.c: continue after MEDIUM_ERROR

Mark Lord wrote: James Bottomley wrote: For the MD case, this is what REQ_FAILFAST is for. I cannot find where SCSI honours that flag. James? Scratch that thought.. SCSI honours it in scsi_end_request(). But I'm not certain that the block layer handles it correctly, at least

Re: [PATCH] scsi_lib.c: continue after MEDIUM_ERROR

Douglas Gilbert wrote: Ric, Both ATA (ATA8-ACS) and SCSI (SBC-3) have recently added command support to flag a block as uncorrectable. There is no need to send bad long data to it and suppress the disk's automatic re-allocation logic. That'll be useful in a couple of years, once drives that

Re: [PATCH] scsi_lib.c: continue after MEDIUM_ERROR

Alan wrote: When libata reports a MEDIUM_ERROR to us, we *know* it's non-recoverable, as the drive itself has already done internal retries (libata uses the with retry ATA opcodes for this). This depends on the firmware. Some of the raid firmware drives don't appear to do retries in firmware.

Re: [PATCH] scsi_lib.c: continue after MEDIUM_ERROR

James Bottomley wrote: On Wed, 2007-01-31 at 12:57 -0500, Mark Lord wrote: Alan wrote: When libata reports a MEDIUM_ERROR to us, we *know* it's non-recoverable, as the drive itself has already done internal retries (libata uses the with retry ATA opcodes for this). This depends

[PATCH] RESEND scsi_lib.c: continue after MEDIUM_ERROR

to pretend that (for example) an adjacent directly lookup also failed. This patch fixes the behaviour to be similar to what we had originally. When a bad sector is encounted, SCSI will now work around it again, failing *only* the bad sector itself. Signed-off-by:  Mark Lord [EMAIL PROTECTED

Re: [PATCH] scsi_lib.c: continue after MEDIUM_ERROR

Eric D. Mudama wrote: Actually, it's possibly worse, since each failure in libata will generate 3-4 retries. With existing ATA error recovery in the drives, that's about 3 seconds per retry on average, or 12 seconds per failure. Multiply that by the number of blocks past the error to

Re: [PATCH] scsi_lib.c: continue after MEDIUM_ERROR

James Bottomley wrote: First off, please send SCSI patches to the SCSI list: linux-scsi@vger.kernel.org Fixed already, thanks! This patch fixes the behaviour to be similar to what we had originally. When a bad sector is encounted, SCSI will now work around it again, failing *only* the bad

Re: [PATCH] SCSI, libata: add support for ATA_16 commands to libata ATAPI devices

Jens Axboe wrote: On Wed, Jan 03 2007, James Bottomley wrote: Er, well, as you know, I've never been a fan of this static list. I thought Jens was going to put us all out of our misery by making the list settable per device by root and thus shovel the problem off onto the distros? The code

Re: [PATCH] SCSI, libata: add support for ATA_16 commands to libata ATAPI devices

James Bottomley wrote: Er I've only seen one patch ... I did ask if there was another to add the ATA_16 interpretation ... did that get lost by the SCSI reflector? Ahh.. my apologies on that, James. The two patches apply and build independently, and the second patch was only for libata, so

Re: [PATCH] SCSI, libata: add support for ATA_16 commands to libata ATAPI devices

James Bottomley wrote: As I read the code Mark sent me, current libata will only accept ATA_16 for ATAPI devices (whether type 5 or not) ... pehaps this needs to be altered? It could be. Both ATA_12 and ATA_16 are just ways of getting a taskfile sent down to the LLD, and ATA_12 is merely a

Re: [PATCH 2.6.20-rc3] fix broken retval test in sr_block_ioctl

Jeff Garzik wrote: Mark Lord wrote: ... ret = cdrom_ioctl(file, cd-cdi, inode, cmd, arg); -if (ret != ENOSYS) +if (ret != -ENOSYS) I think Tejun posted the same patch earlier today. Ahh.. missed it -- could have saved me an hour or two of debugging! Cheers! - To unsubscribe

[PATCH 2.6.20-rc3] fix broken retval test in sr_block_ioctl

With recent kernels (and possibly much older ones, too), ioctl() calls for ATAPI devices never make it to the driver layers. The reason for this is a borked return code test in drivers/scsi/sr.c. This patch fixes it. Signed-off-by: Mark Lord [EMAIL PROTECTED] --- --- old/drivers/scsi/sr.c

[PATCH] SCSI, libata: add support for ATA_16 commands to libata ATAPI devices

to signal that 16-byte ATA_16 commands should be permitted even for 12-byte ATAPI devices. Signed-off-by: Mark Lord [EMAIL PROTECTED] --- old/include/scsi/scsi_host.h2007-01-02 19:06:45.0 -0500 +++ new/include/scsi/scsi_host.h2007-01-02 19:09:06.0 -0500 @@ -608,6