On Mon, 19 Jan 2015, Alan Stern wrote:
...
If anyone (still?) cares about this bug, commit 3a9794d3 ("sd: Fix max
transfer length for 4k disks") fixes it, with no patches required.
-Kenny
--
Kenneth R. Crudup Sr. SW Engineer, Scott County Consulting, Silicon Valley
--
To unsubscribe f
On Mon, 19 Jan 2015, Alan Stern wrote:
> Are you certain the patch had been applied to the kernel you were testing?
Yeah, I definitely remember the result of "git status" having the patch
ready for commit at the time of build. I'll test it again later tonight.
> Maybe you can add a printk statem
On Mon, 19 Jan 2015, Kenneth R. Crudup wrote:
> Sorry for taking so long to get back to you guys about this (the 3.19-rc
> series has been
> problematic for me in a couple of areas, so I'd let it go for a while):
>
> On Mon, 5 Jan 2015, Alan Stern wrote:
>
> > The patch I posted sets a general
Sorry for taking so long to get back to you guys about this (the 3.19-rc series
has been
problematic for me in a couple of areas, so I'd let it go for a while):
On Mon, 5 Jan 2015, Alan Stern wrote:
> The patch I posted sets a general limit of 32 MB for USB drives that
> don't have a quirk flag
I will later tonight. For now, I'm using 3.18.x (for another reason), which
doesn't have this commit.
My Linus-latest tree has a "fix" that imposed a hard limit of 32767, which
worked for me then.
On January 5, 2015 12:07:56 PM PST, Alan Stern
wrote:
>On Mon, 5 Jan 2015, Christoph Hellwig wro
On Mon, 5 Jan 2015, Christoph Hellwig wrote:
> On Tue, Dec 30, 2014 at 08:36:34AM -0800, Kenneth R. Crudup wrote:
> > OP here. FWIW, this is what I get when running that command on the SCSI
> > generic device that corresponds to the USB-3 (non-UAS) disk[1] that had the
> > issue:
>
> So it looks
On Tue, Dec 30, 2014 at 08:36:34AM -0800, Kenneth R. Crudup wrote:
> OP here. FWIW, this is what I get when running that command on the SCSI
> generic device that corresponds to the USB-3 (non-UAS) disk[1] that had the
> issue:
So it looks like this one actually provides sane values, but we don't
On Tue, Dec 30, 2014 at 11:19:07AM -0500, Douglas Gilbert wrote:
> In SCSI, the VPD page 0xb0 (Block limits) has a "Maximum transfer
> length" field (32 bits long). Its units are logical blocks. Useful
> if >0 as 0 means "unreported".
>
> USB to SATA bridges should comply with SAT. However SAT and
On Tue, 30 Dec 2014, Douglas Gilbert wrote:
> IMO about the best SATL is in the MPT SAS-2 and SAS-3 HBAs and
> here is that page for a SAS expander attached SATA disk:
> # sg_vpd -p bl /dev/sg3
OP here. FWIW, this is what I get when running that command on the SCSI
generic device that correspond
On Tue, 2014-12-30 at 11:45 -0500, Alan Stern wrote:
> PS: What's the current situation of my "SCSI: fix regression in
> scsi_send_eh_cmnd()" patch:
>
> http://marc.info/?l=linux-scsi&m=141658469207765&w=2
>
> submitted on November 21? Since it was a bug-fix, I rather expected it
> to g
On Tue, 30 Dec 2014, James Bottomley wrote:
> > All right. How does this patch look?
>
> OK, I suppose. The transfer limits are a little on the low side, but
> for usb-storage (i.e. non-UAS) performance devices, they should be OK.
If you're referring to the 32-KB and 64-KB limits, we know from
On Tue, 2014-12-30 at 11:12 -0500, Alan Stern wrote:
> On Tue, 30 Dec 2014, James Bottomley wrote:
>
> > > _Is_ there any way to communicate the maximum transfer size? I'm not
> > > aware of any SCSI command for it. It isn't part of the USB
> > > mass-storage spec.
> >
> > For the device, it's
On 14-12-30 10:34 AM, Alan Stern wrote:
On Tue, 30 Dec 2014, Christoph Hellwig wrote:
The only limits usb-storage imposes on max_sectors are those needed to
work around bugs in the devices' USB bridges. (Okay, there's also
something for tape drive devices, but it probably doesn't belong in
usb
On Tue, 30 Dec 2014, James Bottomley wrote:
> > _Is_ there any way to communicate the maximum transfer size? I'm not
> > aware of any SCSI command for it. It isn't part of the USB
> > mass-storage spec.
>
> For the device, it's in the Block limits VPD page. However, what the
> device supports
On Tue, 2014-12-30 at 10:34 -0500, Alan Stern wrote:
> On Tue, 30 Dec 2014, Christoph Hellwig wrote:
>
> > > The only limits usb-storage imposes on max_sectors are those needed to
> > > work around bugs in the devices' USB bridges. (Okay, there's also
> > > something for tape drive devices, but i
On Tue, 30 Dec 2014, Christoph Hellwig wrote:
> > The only limits usb-storage imposes on max_sectors are those needed to
> > work around bugs in the devices' USB bridges. (Okay, there's also
> > something for tape drive devices, but it probably doesn't belong in
> > usb-storage -- it should be ha
On Sun, Dec 28, 2014 at 10:10:01PM -0500, Alan Stern wrote:
> (Is this a USB device? Presumably you wouldn't have CC'ed the
> linux-usb and usb-storage mailing lists if it wasn't...)
It's a usb attached device. From the inquity information and the
product name it looks like a SATA device attache
On Sat, 27 Dec 2014, Christoph Hellwig wrote:
> On Tue, Dec 23, 2014 at 11:48:40PM -0800, Kenneth R. Crudup wrote:
> > > Looks like we need to quirk it. Can you try to echo different limits
> > > to the /sys/block/sdc/queue/max_hw_sectors_kb file for the device to
> > > find the limit for it?
>
On Tue, Dec 23, 2014 at 11:48:40PM -0800, Kenneth R. Crudup wrote:
> > Looks like we need to quirk it. Can you try to echo different limits
> > to the /sys/block/sdc/queue/max_hw_sectors_kb file for the device to
> > find the limit for it?
>
> Looks like it's 32767; making it an even 32K sectors
19 matches
Mail list logo
