Hello,
I applied the patch. Unfortunately, results are the same. The output of dmesg is
attached.
BTW what does CSW mean? Can the speed of the USB controller be reduced? I know that
this question sounds quite strange, but if the external case has problems with the
speed of the host controller
[EMAIL PROTECTED] wrote:
The ATA convention is to return the capacity.
The SCSI convention is to return the highest block number,
one less than the capacity.
So, the driver misses a -1.
Phew, I would have never found this. Congrats!
Another problem causing hangs was that the SCSI code does
TEST_UN
Hi,
apart from locking bugs, there are other races. This fixes one with
signal delivery. The signal should be delivered _before_ the reciever
is woken.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]
On Thu, Dec 04, 2003 at 12:32:00PM -0800, David Brownell wrote:
>
> Please merge to the next kernel that gets USB patches.
Applied, thanks.
greg k-h
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just
On Mon, Oct 27, 2003 at 05:06:20PM -0800, Matthew Dharm wrote:
> Greg, this is a patch for 2.5/6 -- please apply. The description follows
> in the forwarded message.
>
> Matt
>
> - Forwarded message from Alan Stern <[EMAIL PROTECTED]> -
>
> Date: Fri, 24 Oct 2003 15:14:21 -0400 (EDT)
>
On Mon, Oct 20, 2003 at 04:42:56PM -0700, Stephen Hemminger wrote:
> This fixes the memory stick SCSI access for Sony Clie SJ33 with SanDisk
> memory stick. It worked in 2.4 because the usb-storage seemed to be less
> picky about inquiry responses. Rather than changing the inquiry response
> proc
On Mon, Oct 27, 2003 at 05:50:13PM -0800, Matthew Dharm wrote:
> Greg, this is a 2.5/6 patch -- please apply. The description is below.
>
> The residue update shouldn't make much of a difference, as almost nobody
> checks that value. But, it is reported via sg, so it should be accurate.
>
> Mat
On Mon, Oct 27, 2003 at 11:28:35PM -0800, Matthew Dharm wrote:
> Greg, this is another 2.5/6 patch -- please apply.
>
> As with the last two, the description is below.
>
> Matt
>
> - Forwarded message from Alan Stern <[EMAIL PROTECTED]> -
>
> Date: Fri, 24 Oct 2003 15:38:25 -0400 (EDT)
On Fri, Dec 05, 2003 at 11:08:44AM +0100, [EMAIL PROTECTED] wrote:
> From [EMAIL PROTECTED] Fri Dec 5 07:16:54 2003
>
> > Below a patch fixing both problems. Now my two-lun device works
> > for CF and it works for SM but not both - depending on the order
> > of the entrie
If I try (after rmmoding the hid module):
insmod usbserial vendor=0x04b4 product=0x5500
I get in the logs:
usbserial.c: Generic device with no bulk out, not allowed.
Is bulk out really needed or could usbserial be made to work without
it?
I tried google for "Vendor=04b4 ProdID=5500" and zi
On Fri, 5 Dec 2003, Jamie Lokier wrote:
> Alan Stern wrote:
> > Sorry, my question wasn't clear. What I'm trying to understand is,
> > after you had done
> >
> > echo 0 >.../bConfigurationValue
> >
> > why was any code calling usb_reset_device? And exactly which code was
> > calling usb_r
Alan Stern wrote:
> Sorry, my question wasn't clear. What I'm trying to understand is,
> after you had done
>
> echo 0 >.../bConfigurationValue
>
> why was any code calling usb_reset_device? And exactly which code was
> calling usb_reset_device?
USBDEVFS_RESET.
-- Jamie
-
> Does this fix the LUN-selection problem Eduard pointed out?
Eduard, does it?
(That is, if you remove your lun assignment patch, so that the driver
does this silly broken lun detection again, but add my "beenhere" hack
to avoid infinite recursion upon scsi error recovery, does the "detect"
then c
On Fri, 5 Dec 2003, Jamie Lokier wrote:
> Alan Stern wrote:
> > Can you say under what circumstances usb_physical_reset_device was called
> > with dev->actconfig equal to NULL? Or post a stack trace from the
> > resulting oops?
>
> After calling SETCONFIGURATION with argument 0, or
> echo 0 > ..
Alan Stern wrote:
> Can you say under what circumstances usb_physical_reset_device was called
> with dev->actconfig equal to NULL? Or post a stack trace from the
> resulting oops?
After calling SETCONFIGURATION with argument 0, or
echo 0 > /bConfigurationValue.
-- Jamie
---
On Fri, 5 Dec 2003, Jamie Lokier wrote:
> In 2.6.0-test10, usb_physical_reset_device, this call can oops with a
> NULL pointer dereference:
>
> ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
> USB_REQ_SET_CONFIGURATION, 0,
> dev->actconfig->d
On Fri, 5 Dec 2003 [EMAIL PROTECTED] wrote:
> Hmm. Now that I look - it is just that the driver is broken.
> Nothing wrong with the device.
>
> The ATA convention is to return the capacity.
> The SCSI convention is to return the highest block number,
> one less than the capacity.
> So, the driver
In 2.6.0-test10, usb_physical_reset_device, this call can oops with a
NULL pointer dereference:
ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
USB_REQ_SET_CONFIGURATION, 0,
dev->actconfig->desc.bConfigurationValue, 0,
From [EMAIL PROTECTED] Fri Dec 5 07:16:54 2003
> Below a patch fixing both problems. Now my two-lun device works
> for CF and it works for SM but not both - depending on the order
> of the entries in unusual_devices.
Why not? Can't we just use "srb->devic
19 matches
Mail list logo
