usbstorage: Sony-Ericsson W760i "No sense [current]"

Attaching dmesg output when using the test kernel from http://people.canonical.com/~smb/bug287701/

Ok, to repeat some information from the other bug:

With the patched kernel, both storage devices report a size which is reduced by one (to an even number). While this looks ok so far, only one of them works as expected. The other still fails with the "no sense" problem.

I started a debug howto at https://wiki.ubuntu.com/KernelTeam/Debugging/USB (if you find mistakes, please let me know) which should help to gather more data.

Could you provide the output of /proc/bus/usb/devices and (if you use the same port it should be bus 4) the trace of the usb bus as described there (from inserting the phone to after removing it)? Thanks.

Should I do that on the current kernel, or on the testing one?

Anyway, attaching the output of /sys/kernel/debug/usbmon/2u on the "normal" kernel.

Working through the debug data it looks quite odd: while the bigger device acts normal (as far as there is a normal with the bug) up to the point of trying to read the very last sector, the other is returning the no sense errors much sooner.

The capacity returned is 120093 sectors with 512 bytes (so 120092 would be the number of the last sector). As this devices returns the wrong thing, the last sector would actually be 120091). From the trace I can see, that there is one operation repeated over and over again. And this is to read 8 sectors, starting from 120072. That would be 120072 to 120079, which is way before the returned end of the device.

In theory, editing /lib/udev/rules.d/60-persistent-storage.rules as root (while the phone is unplugged) from

KERNEL!="sr*", IMPORT{program}="vol_id --export $tempnode"
to
KERNEL!="sr*", IMPORT{program}="vol_id --export --skip-raid $tempnode"

should temporarily prevent reading the last sectors (don't forget to remove the --skip-raid after the test!). Then you could plug in the phone and obtain the partition table ("sudo fdisk -l"). It would be interesting how much of the smaller device (I guess that is the internal one) is used by the partition. But the underlying problem is that the device seems to fail much sooner than a off-by one sector.

After editing the udev rule as you described, I could connect the phone, and Nautilus even automounted it, but immediately after running " fdisk -l " as root, dmesg started filling with "No sense" errors again, and fdisk froze until I unplugged the phone.

The output of "fdisk -l" didn't display the phone at all (only the hard disk and my USB pendrive, which are probably irrelevant).

(Out of curiosity I rebooted into Windows XP, and tried to access the end of the internal memory from there (using HxD, a hex editor). It did fail to read the last sector (120093 as reported by HxD), but successfully read 120070 to 120080 - they were full of null bytes, though.)

Nope, I was wrong about Windows - it fails reading that part too. Sorry :/

This gets stranger and stranger. I wonder whether this is a special case for
one device (yours) or generic. It would be good to have someone with the same
phone either confirming or declining the effect.
The failing blocks when unplugging the phone somehow seem to include the last
sector, though I do not know what fdisk would do there. Would "fdisk /dev/sdc"
and then use 'p' to print the table work?
At this point this sounds a bit like something that might be interesting to
report upstream (though I struggle a bit to see how this could be fixed). But
for that it should be tested against a very recent kernel. Could you probably
pull a daily kernel from

http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/

You can install the kernel in parallel to your current and select which to boot
from grub.

fdisk /dev/sdc did exactly the same - "No sense" flood.

I'll try with the kernel from PPA, once it finishes downloading.

grawity wrote:
> fdisk /dev/sdc did exactly the same - "No sense" flood.

Doh. Hm, maybe cat /proc/partitions yields a bit of that information without
cause the bug (doesn't matter which kernel is running).

> I'll try with the kernel from PPA, once it finishes downloading.

Ok, thanks.

Here's what /proc/partitions says, on the current kernel (the PPA one is installing):

major minor #blocks name

   8 0 19535040 sda
   8 1 15205491 sda1
   8 2 1 sda2
   8 5 4080478 sda5
   8 6 248976 sda6
   8 16 1957888 sdb
   8 17 1951866 sdb1
   8 32 60046 sdc
   8 33 59996 sdc1
   8 48 1997824 sdd
   8 49 1997636 sdd1

(sda is hard drive, sdb is USB pendrive, sdc is phone's internal memory - the one that causes problems, sdb is phone's MemoryStick)

root@theory ~/Desktop/Bug reports# uname -a
Linux theory 2.6.31-999-generic #1248166812 SMP Tue Jul 21 09:43:52 UTC 2009 i686 GNU/Linux

Exactly the same problem.

grawity wrote:
> major minor #blocks name
> 8 32 60046 sdc
* 2 = 120092 (as expected)
> 8 33 59996 sdc1
We do not see the start offset but usually 1 or 2 which would give a end sector
of 119995 which is safely away from the region failing.

> Linux theory 2.6.31-999-generic #1248166812 SMP Tue Jul 21 09:43:52 UTC 2009 i686 GNU/Linux
> Exactly the same problem.

Nearly to be expected. It looks a bit like the device uses that area for
something different but won't tell and fails ominously when getting poked the
normal way. A bit like host protected areas on IDE, but I thought this would
not exist on SCSI (which your phone uses as interface).
I guess I need to think about that and forward this to some upstream
developers. Thanks for testing so far

I've got the same phone with the same problem.

[111149.607901] sd 12:0:0:1: [sdd] Sense Key : No Sense [current]
[111149.607914] sd 12:0:0:1: [sdd] Add. Sense: No additional sense information
[111149.633593] sd 12:0:0:0: [sdc] Sense Key : No Sense [current]
[111149.633606] sd 12:0:0:0: [sdc] Add. Sense: No additional sense information
[111149.643149] sd 12:0:0:1: [sdd] Sense Key : No Sense [current]
[111149.643162] sd 12:0:0:1: [sdd] Add. Sense: No additional sense information
[111149.668047] sd 12:0:0:0: [sdc] Sense Key : No Sense [current]
...

Nick B. wrote:
> I've got the same phone with the same problem.

Thanks for helping out. Can you try the v2 kernel from
http://people.canonical.com/~smb//bug287701/ which should make the external
storage available but not the internal one, if both phones act the same.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Stefan Bader wrote:
> Nick B. wrote:
>> I've got the same phone with the same problem.
>
> Thanks for helping out. Can you try the v2 kernel from
> http://people.canonical.com/~smb//bug287701/ which should make the
> external storage available but not the internal one, if both phones
> act the same.
>

The v2 kernel acts as expected. I can access the memory stick but not
the phone's memory. The system log is still getting spammed with tons
of the "No sense [current]" messages though.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEcBAEBCAAGBQJKZpjxAAoJEIltSrFpUGteXi0H/i48kJjTAg/o5F0QrUJhAC9C
xzmNUuZWAPTywyPCLBhbMhMNsLdIWUmL0b1VU1niF0oR4VQLjuYqEqZsMTugiYES
PvGwywfdbGYSS+xx29X35sfj/S2RF1SicM3KEMb8CdJ2y6Nhjvtuk5fGNzYZAtbE
oru0uSf15QPU3RzUbbgyrbDHa9x/LIs1D2NltZUy1HMIYReuwtq8pMUlq2wssjN4
7mYyZHAX6ecci7+RPNRy4A0bvn1yJeieX0Sj5N7+WzYe8a4ADETnA9tbQT0XEuyf
inMp3cDXY5zxSdwVud37CUAD8PCw+u6mGyo4v942dq3RoKCCXfd8gJIL6js+Qfk=
=VlmH
-----END PGP SIGNATURE-----

Nick B. wrote:
  > The v2 kernel acts as expected. I can access the memory stick but not
> the phone's memory. The system log is still getting spammed with tons
> of the "No sense [current]" messages though.

Ok, that at least proves that the phone is consistently behaving the same and
it is not only a one-off. Thanks for verifying.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I'm not sure if this is a real fix or perhaps just a workaround, but I
stumbled across this
http://arch.uhl.nu/60-persistent-storage.rules
Dropping that in /etc/udev/rules.d/ makes the phone's internal storage
and memory stick accessible and eliminates the "No Sense" log flooding.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBCAAGBQJK59DrAAoJEIltSrFpUGteJRsH/1r42HqkziKEmdEC6sWoSIvT
B6ZAQ+RPhoPUrOBzl84KYSxBMwch6MH2zZQjuaCnLS1U8kYmKT2PZiTwh7TLO6HR
ZzVJhkSuGUq9GSN7u4u/bgVDE0W794C8C+d5yqvi+MacKs2LnQM+nBVJ96K62oVy
cLBmsePBtng78kIVdwZ0ywDd/RfQWfP8RGVcOSX3AluhbXGEZIcRb2eexb5N37MX
6VPq+E5dfYcx4/wvVcx891H/Ehosy4r+FzfgJ8+sBuUzI4mQByqkOiNZmxs9RTtt
sNUs9uFYIc+/m8UAcHeeAPh1I5Hs12OfMbLGWBlIRgdi9d/xyZgs/1fehJHQUdo=
=/GlS
-----END PGP SIGNATURE-----

On Wed, Oct 28, 2009 at 05:04:47AM -0000, Nick B. wrote:
> I'm not sure if this is a real fix or perhaps just a workaround, but I
> stumbled across this
> http://arch.uhl.nu/60-persistent-storage.rules
> Dropping that in /etc/udev/rules.d/ makes the phone's internal storage
> and memory stick accessible and eliminates the "No Sense" log flooding.

I'm not exactly sure what it does, but I guess it's similar to Stefan
Bader's --skip-raid suggestion (comment #7)...

A real fix would be kernel patch to make it not loop endlessly - this has
already been fixed in the latest release from kernel.org, and should
appear in the Ubuntu kernel too.

(Meh. todo += "Figure out Launchpad email replies.")

Actually really quite recently (after 2.6.31 release). The fix should come up with one of the next Karmic updates (not the immediate next but after that). For the moment, I did a rebuild for Jaunty with that to http://people.canonical.com/~smb/bug400652/, maybe it would be possible to verify against that.

I've also built test kernels for Karmic with the patch Stefan mentioned should help with this issue. Please test and let us know your results. Thanks!

http://people.canonical.com/~ogasawara/lp400652/

commit f1a0743bc0e7a30c032b1eb78f6a2b0f805b4597
    Author: Alan Stern <email address hidden>
    Date: Tue Oct 6 14:07:57 2009 -0400
       USB: storage: When a device returns no sense data, call it a Hardware Error

Hello,
I have/had the same problem with my SE w595.
Changing the line in 60-persistent-storage.rules didn't help.
But the kernel from Ogasawara fixed the problem.
Thanks.

The following upstream commit is supposed to fix those issues (included in upstream stable update):

commit 334d08164fa83b0274e2bc5431a59ab1cc6e32a2
Author: Alan Stern <email address hidden>
Date: Tue Oct 6 14:07:57 2009 -0400

    USB: storage: When a device returns no sense data, call it a Hardware Error

Sorry, was a bit ahead of me. The stable updates will be next.

Accepted linux into karmic-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

This bug was fixed in the package linux - 2.6.31-17.54

---------------
linux (2.6.31-17.54) karmic-proposed; urgency=low

  [ John Johansen ]

  * SAUCE: AppArmor: Fix oops after profile removal
    - LP: #475619
  * SAUCE: AppArmor: Fix Oops when in apparmor_bprm_set_creds
    - LP: #437258
  * SAUCE: AppArmor: Fix cap audit_caching preemption disabling
    - LP: #479102
  * SAUCE: AppArmor: Fix refcounting bug causing leak of creds
    - LP: #479115
  * SAUCE: AppArmor: Fix oops there is no tracer and doing unsafe
    transition.
    - LP: #480112

  [ Leann Ogasawara ]

  * Revert "[Upstream] (drop after 2.6.31) usb-storage: Workaround devices
    with bogus sense size"
    - LP: #461556
  * Revert "[Upstream] (drop after 2.6.31) Input: synaptics - add another
    Protege M300 to rate blacklist"
    - LP: #480144

  [ Tim Gardner ]

  * [Config] udeb: Add squashfs to fs-core-modules
    - LP: #352615

  [ Upstream Kernel Changes ]

  * Revert "e1000e: swap max hw supported frame size between 82574 and
    82583"
    - LP: #461556
  * Revert "drm/i915: Fix FDI M/N setting according with correct color
    depth"
    - LP: #480144
  * Revert "agp/intel: Add B43 chipset support"
    - LP: #480144
  * Revert "drm/i915: add B43 chipset support"
    - LP: #480144
  * Revert "ACPI: Attach the ACPI device to the ACPI handle as early as
    possible"
    - LP: #327499, #480144
  * SCSI: Retry ADD_TO_MLQUEUE return value for EH commands
    - LP: #461556
  * SCSI: Fix protection scsi_data_buffer leak
    - LP: #461556
  * SCSI: sg: Free data buffers after calling blk_rq_unmap_user
    - LP: #461556
  * ARM: pxa: workaround errata #37 by not using half turbo switching
    - LP: #461556
  * tracing/filters: Fix memory leak when setting a filter
    - LP: #461556
  * x86/paravirt: Use normal calling sequences for irq enable/disable
    - LP: #461556
  * USB: ftdi_sio: remove tty->low_latency
    - LP: #461556
  * USB: ftdi_sio: remove unused rx_byte counter
    - LP: #461556
  * USB: ftdi_sio: clean up read completion handler
    - LP: #461556
  * USB: ftdi_sio: re-implement read processing
    - LP: #461556
  * USB: pl2303: fix error characters not being reported to ldisc
    - LP: #461556
  * USB: digi_acceleport: Fix broken unthrottle.
    - LP: #461556
  * USB: serial: don't call release without attach
    - LP: #461556
  * USB: option: Toshiba G450 device id
    - LP: #461556
  * USB: ipaq: fix oops when device is plugged in
    - LP: #461556
  * USB: cp210x: Add support for the DW700 UART
    - LP: #461556
  * USB: Fix throttling in generic usbserial driver
    - LP: #461556
  * USB: storage: When a device returns no sense data, call it a Hardware
    Error
    - LP: #400652, #461556
  * arm, cris, mips, sparc, powerpc, um, xtensa: fix build with bash 4.0
    - LP: #461556
  * intel-iommu: Cope with broken HP DC7900 BIOS
    - LP: #461556
  * futex: Detect mismatched requeue targets
    - LP: #461556
  * futex: Fix wakeup race by setting TASK_INTERRUPTIBLE before queue_me()
    - LP: #461556
  * tpm-fixup-pcrs-sysfs-file-update
    - LP: #461556
  * TPM: fix pcrread
    - LP: #461556
  * Bluetooth: Disconnect HIDRAW devices on disconnect
    - LP...

setting top level task to Fix Released as it was overlooked.

-JFo