On 11/06/2014 12:30 PM, James Bottomley wrote:
On Wed, 2014-11-05 at 11:30 -0800, Christoph Hellwig wrote:
On Wed, Nov 05, 2014 at 11:34:11AM -0500, Alan Stern wrote:
Sorry, meant to. In principle I'm OK with this as the lever for the
hack (largely because it means we don't need to do
On 11/06/2014 05:54 PM, James Bottomley wrote:
We don't have a failure. This is the problem. Determining that a
problem exists
OK Sorry. I assumed the bridge is smart enough to do nothing,
ie READ_CAPACITY_10 is passed as is via sata to the device that
actually supports
On 11/06/2014 05:53 PM, Alan Stern wrote:
But just the simple case of read-capacity failure should we then?
That's a separate question. As far as I know, the case you are
describing has not come up.
BTW: what we should do is when the partition parser at the block layer
see that the
On 11/05/2014 06:34 PM, Alan Stern wrote:
It's simpler than that: The drive is attached directly to the computer
(i.e., via SATA rather than USB) when the partition table is created.
With no USB-SATA bridge chip to mess things up, there's no problem
determining the correct capacity.
On Tue, Feb 05 2008 at 17:42 +0200, Alan Stern [EMAIL PROTECTED] wrote:
On Tue, 5 Feb 2008, Boaz Harrosh wrote:
However the interface to usb_stor_access_xfer_buf() will have to change
slightly. Right now if it sees that *sgptr is NULL, it assumes this
means it should start at the beginning
On Thu, Jan 31 2008 at 22:56 +0200, Alan Stern [EMAIL PROTECTED] wrote:
On Thu, 31 Jan 2008, Boaz Harrosh wrote:
The code in usb_stor_access_xfer_buf() will
now correctly attempt to transfer according to buflen and what ever is
available
at the passed sg's. Now this can be less or it can
On Thu, Jan 31 2008 at 1:08 +0200, Alan Stern [EMAIL PROTECTED] wrote:
Boaz:
This looks like it might have something to do with your changes.
Alan Stern
On Wed, 30 Jan 2008, Mark Glines wrote:
:
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
On Thu, Jan 31 2008 at 17:08 +0200, Mark Glines [EMAIL PROTECTED] wrote:
On Thu, 31 Jan 2008 11:27:39 +0200
Boaz Harrosh [EMAIL PROTECTED] wrote:
Please check the below patch.
one thing that I can see is that the isd200 does an INQUARY transfer
of sizeof(struct inquiry_data) which is 96
.
Then usb_stor_set_xfer_buf() should report this condition as a negative
resid. Should we also set cmnd-status in the underflow condition?
Then also isd200.c is fixed to only return the type of INQUIRY SENSE
the upper layer asked for.
Signed-off-by: Boaz Harrosh [EMAIL PROTECTED]
---
drivers/usb/storage/isd200.c
On Thu, Jan 31 2008 at 18:45 +0200, Alan Stern [EMAIL PROTECTED] wrote:
On Thu, 31 Jan 2008, Boaz Harrosh wrote:
Please check the below patch.
one thing that I can see is that the isd200 does an INQUARY transfer
of sizeof(struct inquiry_data) which is 96 bytes, when scsi_scan.c
sends
On Thu, Jan 31 2008 at 20:00 +0200, Greg KH [EMAIL PROTECTED] wrote:
On Thu, Jan 31, 2008 at 07:19:57PM +0200, Boaz Harrosh wrote:
scsi_scan is issuing a 36-byte INQUIRY request to llds. isd200 would
volunteer 96 bytes of INQUIRY. This caused an underflow condition in
protocol.c
On Thu, Jan 31 2008 at 21:34 +0200, Alan Stern [EMAIL PROTECTED] wrote:
On Thu, 31 Jan 2008, Boaz Harrosh wrote:
On Thu, Jan 31 2008 at 19:49 +0200, Alan Stern [EMAIL PROTECTED] wrote:
On Thu, 31 Jan 2008, Boaz Harrosh wrote:
@@ -228,9 +228,14 @@ void usb_stor_set_xfer_buf(unsigned char
On Thu, Jan 31 2008 at 21:49 +0200, Matthew Dharm [EMAIL PROTECTED] wrote:
No. No no no.
The ISD200 code was written by the ISD200 developers. I really don't want
to go mucking about changing what commands actually get send to the ISD200
parts. We have no idea if the will reliably accept
On Tue, Jan 29 2008 at 17:36 +0200, Alan Stern [EMAIL PROTECTED] wrote:
On Tue, 29 Jan 2008, Boaz Harrosh wrote:
--- a/drivers/usb/storage/transport.c
+++ b/drivers/usb/storage/transport.c
@@ -462,18 +462,24 @@ static int usb_stor_bulk_transfer_sglist(struct
us_data *us, unsigned int pipe
On Tue, Jan 29 2008 at 16:31 +0200, Oliver Neukum [EMAIL PROTECTED] wrote:
Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe:
On Tue, Jan 29 2008, Boaz Harrosh wrote:
On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe [EMAIL PROTECTED] wrote:
On Tue, Jan 29 2008, Boaz Harrosh wrote:
Greg
On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe [EMAIL PROTECTED] wrote:
On Tue, Jan 29 2008, Boaz Harrosh wrote:
Greg KH wrote:
On Mon, Jan 28, 2008 at 09:49:35PM +0100, Jens Axboe wrote:
Hi,
Running latest -git (head 91525300baf162e83e923b09ca286f9205e21522) and
connecting my cf usb
On Tue, Jan 29 2008 at 16:06 +0200, Boaz Harrosh [EMAIL PROTECTED] wrote:
On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe [EMAIL PROTECTED] wrote:
On Tue, Jan 29 2008, Boaz Harrosh wrote:
Greg KH wrote:
On Mon, Jan 28, 2008 at 09:49:35PM +0100, Jens Axboe wrote:
Hi,
Running latest -git (head
On Tue, Jan 29 2008 at 20:48 +0200, James Bottomley [EMAIL PROTECTED] wrote:
On Tue, 2008-01-29 at 20:27 +0200, Boaz Harrosh wrote:
On Tue, Jan 29 2008 at 18:34 +0200, James Bottomley [EMAIL PROTECTED]
wrote:
On Tue, 2008-01-29 at 10:36 -0500, Alan Stern wrote:
On Tue, 29 Jan 2008, Boaz
On Tue, Jan 29 2008 at 22:24 +0200, James Bottomley [EMAIL PROTECTED] wrote:
On Tue, 2008-01-29 at 21:06 +0100, Jens Axboe wrote:
I will ... but it will cause an explosion in the bidirectional tree
again. I think the bidi updates also fix this. However, give me time
to rebase and verify.
OK
On Tue, Jan 29 2008 at 22:13 +0200, Jens Axboe [EMAIL PROTECTED] wrote:
On Tue, Jan 29 2008, Boaz Harrosh wrote:
Ok this is not in Linus tree is it? Hence I did not have that failure.
Boaz
actually James bidi tree has a fix for this in the scsi_data_buffer patch.
what you sent
On Tue, Jan 29 2008 at 21:17 +0200, James Bottomley [EMAIL PROTECTED] wrote:
On Tue, 2008-01-29 at 20:58 +0200, Boaz Harrosh wrote:
Your new code does
int partial; - stack uninitialised
sb_stor_bulk_transfer_sglist(..., partial, ...);
scsi_set_resid(srb, scsi_bufflen(srb) - partial
On Fri, Jan 25 2008 at 20:02 +0200, Greg KH [EMAIL PROTECTED] wrote:
FYI, this is a patch that will be sent out in the next round to Linus
for inclusion in 2.6.25.
If anyone has any objections about it, please let me know.
thanks,
greg k-h
What about ndiswrapper and its windows
- Original Message -
*From:* Hans de Goede [EMAIL PROTECTED]
*To:* USB Storage list [EMAIL PROTECTED]
*CC:* [EMAIL PROTECTED], USB development list
[EMAIL PROTECTED], David Brown
[EMAIL PROTECTED], Guillaume Bedot [EMAIL PROTECTED],
[EMAIL PROTECTED], linux-usb@vger.kernel.org
*Sent:* Wed,
23 matches
Mail list logo
