Re: Problem with Kindle 2 - unusual_devs.h entry needed?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ok, I disabled libusual in the kernel config, and it's matching in
unusual_devs now
usb-storage: USB Mass Storage device detected
usb-storage: -- associate_dev
usb-storage: Vendor: 0x1949, Product: 0x0002, Revision: 0x0100
usb-storage: Interface Subclass: 0x06, Protocol: 0x50
theindex:239
usb-storage: Transport: Bulk
usb-storage: Protocol: Transparent SCSI
scsi32 : SCSI emulation for USB Mass Storage devices
usb-storage: *** thread sleeping.
usb-storage: device found at 29
usb-storage: waiting for device to settle before scanning



Should libusual be affecting this?
I don't need it for anything in particular, so it can stay off, but is
this normal?


On Fri, Aug 14, 2009 at 8:23 PM, Dylan Taft<d13f00l@xxxxxxxxx> wrote:
> Ok,  I added a printk to find_unusual() in usb.c
> const int id_index = id - storage_usb_ids;
> shows as theindex:266
> which would be USUAL_DEV(US_SC_8070, US_PR_BULK, USB_US_TYPE_STOR),
> So that explains why the protocol is changing...
>
> I have another device in unusual_devs.h, and the index is correct, and it works.
>
> Kindle shows up in /proc/bus/usb/devices as
>
> T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 26 Spd=480 MxCh= 0
> D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
> P:  Vendor=1949 ProdID=0002 Rev= 1.00
> S:  Manufacturer=Amazon
> S:  Product=Amazon Kindle
> S:  SerialNumber=B002A1A091561825
> C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=500mA
> I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
> E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=125us
>
>
> What on earth could cause this?  I'd like to submit a patch to force
> max sectors to 64 in unusual_devs(theres a number of devices that do
> this), so it "just works" for other people, but it's not finding it in
> the table...
>
> Thanks
> Dylan
>
> On Fri, Aug 14, 2009 at 6:49 PM, Dylan Taft<d13f00l@xxxxxxxxx> wrote:
>> Hi,
>> Setting max_sectors to 64 works, no more errors!
>>
>> However, when I try to do it with a unusual_devs.h entry
>> UNUSUAL_DEV( 0x1949, 0x0002, 0x0001, 0x9999,
>>                "Amazon",
>>                "Amazon Kindle",
>>                US_SC_DEVICE, US_PR_DEVICE, NULL,
>>                US_FL_MAX_SECTORS_64 ),
>>
>> The protocol is changing to 8070i.
>> in storage/usb.c
>> I added
>>
>> printk("SOMEBS!!!%i\n",unusual_dev->useProtocol);
>>
>> right in get_device_info
>>
>> dmesg shows up as
>> SOMEBS!!!5
>> with the unusual_devs entry and errors out with the bad target numbers
>>
>> Without the unusual_dev sentry, it shows as 6
>> per usb_usual, US_SC_SCSI is 6, US_SC_8070 is 5...
>>
>> ...something really odd is going on...
>>
>>
>>
>>
>>
>> On Fri, Aug 14, 2009 at 11:11 AM, Alan Stern<stern@xxxxxxxxxxxxxxxxxxx> wrote:
>>> On Thu, 13 Aug 2009, Dylan Taft wrote:
>>>
>>>> Hi all,
>>>>
>>>> Any ideas on this would be gratefully appreciated!
>>>>
>>>> Kernel 2.6.29.4, been having trouble with the kindle 2 as a usb mass
>>>> storage device,
>>>> if I copy a file larger than a few megs
>>>> dmesg gets littered with
>>>>
>>>> usb-storage: device scan complete
>>>> usb 2-1: reset high speed USB device using ehci_hcd and address 3
>>>> usb 2-1: device descriptor read/all, error -71
>>>> usb 2-1: reset high speed USB device using ehci_hcd and address 3
>>>> usb 2-1: reset high speed USB device using ehci_hcd and address 3
>>>> and sometimes i/o errors
>>>>
>>>> recompiled usb storage with verbose debugging on
>>>> concerned about Status code -104; transferred 1024/122880
>>>>
>>>> Wanted to try adding an unusual_devs.h entry for it, but then it gets
>>>> detected w/ a protocol of 8070i, which is wrong. supposed to be scsi
>>>> storage?
>>>
>>> Perhaps instead of an unusual_devs entry, you need to decrease the
>>> max_sector value to 128.  See
>>>
>>>        http://www.linux-usb.org/FAQ.html#i5
>>>
>>>> UNUSUAL_DEV( 0x1949, 0x0002, 0x0001, 0x9999,
>>>>               "Amazon",
>>>>               "Amazon Kindle",
>>>>               US_SC_DEVICE, US_PR_DEVICE, NULL,
>>>>               US_FL_FIX_CAPACITY ),
>>>
>>> This should not change the protocol to 8070i.  I can't imagine why that
>>> happens.
>>>
>>>> Also tried with forcing US_SC_SCSI
>>>
>>>> without unusual_devs.h entry:
>>> ...
>>>> usb-storage: Command WRITE_10 (10 bytes)
>>>> usb-storage:  2a 00 00 0d 58 46 00 00 f0 00
>>>> usb-storage: Bulk Command S 0x43425355 T 0xe3 L 122880 F 0 Trg 0 LUN 0 CL 10
>>>> usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
>>>> usb-storage: Status code 0; transferred 31/31
>>>> usb-storage: -- transfer complete
>>>> usb-storage: Bulk command transfer result=0
>>>> usb-storage: usb_stor_bulk_transfer_sglist: xfer 122880 bytes, 30 entries
>>>> usb-storage: command_abort called
>>>> usb-storage: usb_stor_stop_transport called
>>>> usb-storage: -- cancelling sg request
>>>> usb-storage: Status code -104; transferred 1024/122880
>>>> usb-storage: -- transfer cancelled
>>>> usb-storage: Bulk data transfer result 0x4
>>>> usb-storage: -- command was aborted
>>>> usb-storage: storage_pre_reset
>>>> usb 2-1: reset high speed USB device using ehci_hcd and address 41
>>>
>>> This is not the typical sort of error one sees when FIX_CAPACITY is
>>> needed.
>>>
>>> By the way, if you're using 2.6.29 or later, you can specify quirks
>>> like FIX_CAPACITY as module parameters to usb-storage.  You don't have
>>> to change unusual_devs.h and rebuild the driver.  See the description
>>> of usb_storage.quirks= in Documentation/kernel-parameters.txt.
>>>
>>> Alan Stern
>>>
>>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux