(at least) USB id 14cd:6116 SATA Bridge M6116 chip causes HDD corruption

[Tal Nevo]

Description:

I bought an external USB enclosure for a SATA 2.5" hard drive. When using this USB drive with Microsoft Windows, it works perfectly - I have no problems reading and writing from/to the drive.
However when using this USB drive in Ubuntu (10.04 as well as 12.04) I can read the data on the drive without a problem, however after I wrote to the drive I started getting corruption errors.

To simplify the detection of the problem I used a new empty hard drive with this USB enclosure.
I wrote zeroes on about 1GB of the start of the drive (using a different USB to SATA interface).
When I read from the drive using the commands

dd if=/dev/sdb of=/tmp/xxx bs=1M count=100
hexdump -C xxx

The output of hexdump indicates that all that was read were zeroes:

00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
06400000

However, after I run the following command (writes to drive):

dd if=/dev/zero of=/dev/sdb bs=1M count=100

and then these commands:

dd if=/dev/sdb of=/tmp/xxx bs=1M count=100
hexdump -C xxx | less

I get the following output:
00000000 55 53 42 43 96 5f 00 00 00 e0 01 00 00 00 0a 2a |USBC._.........*|
00000010 00 00 00 00 00 00 00 f0 00 00 00 00 00 00 00 18 |................|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
0001e000 55 53 42 43 97 5f 00 00 00 e0 01 00 00 00 0a 2a |USBC._.........*|
0001e010 00 00 00 00 f0 00 00 f0 00 00 00 00 00 00 00 e5 |................|
0001e020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
0003c000 55 53 42 43 98 5f 00 00 00 e0 01 00 00 00 0a 2a |USBC._.........*|
0003c010 00 00 00 01 e0 00 00 f0 00 00 00 00 00 00 00 4c |...............L|
0003c020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
0005a000 55 53 42 43 99 5f 00 00 00 e0 01 00 00 00 0a 2a |USBC._.........*|
0005a010 00 00 00 02 d0 00 00 f0 00 00 00 00 00 00 00 49 |...............I|
0005a020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00078000 55 53 42 43 9a 5f 00 00 00 e0 01 00 00 00 0a 2a |USBC._.........*|
00078010 00 00 00 03 c0 00 00 f0 00 00 00 00 00 00 00 e1 |................|
00078020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00096000 55 53 42 43 9b 5f 00 00 00 e0 01 00 00 00 0a 2a |USBC._.........*|
00096010 00 00 00 04 b0 00 00 f0 00 00 00 00 00 00 00 40 |...............@|
00096020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000b4000 55 53 42 43 9c 5f 00 00 00 e0 01 00 00 00 0a 2a |USBC._.........*|
000b4010 00 00 00 05 a0 00 00 f0 00 00 00 00 00 00 00 16 |................|
000b4020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000d2000 55 53 42 43 9d 5f 00 00 00 e0 01 00 00 00 0a 2a |USBC._.........*|
000d2010 00 00 00 06 90 00 00 f0 00 00 00 00 00 00 00 13 |................|
000d2020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000f0000 55 53 42 43 9e 5f 00 00 00 e0 01 00 00 00 0a 2a |USBC._.........*|
000f0010 00 00 00 07 80 00 00 f0 00 00 00 00 00 00 00 bb |................|
000f0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
0010e000 55 53 42 43 9f 5f 00 00 00 e0 01 00 00 00 0a 2a |USBC._.........*|
0010e010 00 00 00 08 70 00 00 f0 00 00 00 00 00 00 00 52 |....p..........R|
0010e020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

This indicates that although I tried to write zeroes to the drive, what was actually written was mostly zeroes, but also these strange blocks starting with "USBC". According to the dump these show up at the beginning of every block (block size was 1M bytes) that the 'dd' program wrote.

The output of lsusb on this system is:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 002: ID 044e:3001 Alps Electric Co., Ltd UGTZ4 Bluetooth
Bus 002 Device 002: ID 14cd:6116 Super Top M6116 SATA Bridge

The last entry being the USB to SATA controller that I think Ubuntu has a problem with.

Thanks,
Tal Nevo

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: linux-image-3.2.0-33-generic 3.2.0-33.52
ProcVersionSignature: Ubuntu 3.2.0-33.52-generic 3.2.31
Uname: Linux 3.2.0-33-generic x86_64
NonfreeKernelModules: vtsspp sep3_8 pax apwr3_0
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
ApportVersion: 2.0.1-0ubuntu15
Architecture: amd64
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog]
   Subdevices: 2/2
   Subdevice #0: subdevice #0
   Subdevice #1: subdevice #1
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: tal 2136 F.... pulseaudio
Card0.Amixer.info:
 Card hw:0 'Intel'/'HDA Intel at 0xf6a20000 irq 47'
   Mixer name : 'Intel Cantiga HDMI'
   Components : 'HDA:11d41883,10f70000,00100400 HDA:14f12c06,10f70000,00100000 HDA:80862802,80860101,00100000'
   Controls : 40
   Simple ctrls : 21
Date: Fri Nov 23 02:26:55 2012
HibernationDevice: RESUME=UUID=7d81d0b8-58ad-4582-9006-43f1e0ed2898
InstallationMedia: Ubuntu 12.04.1 LTS "Precise Pangolin" - Release amd64 (20120817.1)
MachineType: Panasonic Corporation CF-F8GXWAJP
MarkForUpload: True
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   no card
ProcEnviron:
 TERM=xterm
 SHELL=/bin/bash
 PATH=(custom, no user)
 LANG=en_US.UTF-8
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-33-generic root=UUID=172a77d7-5669-4e0a-bfe2-256eb4864c4d ro quiet splash vt.handoff=7
PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions:
 linux-restricted-modules-3.2.0-33-generic N/A
 linux-backports-modules-3.2.0-33-generic N/A
 linux-firmware 1.79.1
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 06/05/2009
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: V3.00L14
dmi.board.name: CFF8-3
dmi.board.vendor: Panasonic Corporation
dmi.board.version: 1
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: Panasonic Corporation
dmi.chassis.version: 001
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrV3.00L14:bd06/05/2009:svnPanasonicCorporation:pnCF-F8GXWAJP:pvr003:rvnPanasonicCorporation:rnCFF8-3:rvr1:cvnPanasonicCorporation:ct10:cvr001:
dmi.product.name: CF-F8GXWAJP
dmi.product.version: 003
dmi.sys.vendor: Panasonic Corporation

[Brad Figg (brad-figg)]

This change was made by a bot.

[Joseph Salisbury (jsalisbury)]

Have you tried partitioning the driver and using dd to write to the partition? For example:

dd if=/dev/zero of=/dev/sdb1 bs=1M count=100

[Tal Nevo (talnevo-i)]

As far as my tests went, it does not matter where in the drive I write to with dd - it gets corrupted.
The example I gave was in order to simplify the description of what I was seeing.
Originally, The drive had a formatted partition and when I moved it to this USB/SATA enclosure I began experiencing those corruption errors. In one of my tests I wrote zeroes to a file on that drive and when I looked into that file there were these USBC blocks inside it too.
Of course after that the partition became so corrupt, I could not mount it any more...

My suspicion is that these USBC blocks are actually part of the driver commands to the USB controller to write the data and for some reason they are actually getting written to the drive.

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.7 kernel[0] (Not a kernel in the daily directory) and install both the linux-image and linux-image-extra .deb packages.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.7-rc7-raring/

[Tal Nevo (talnevo-i)]

The laptop on which I reported the bug is not one I can modify. Therefore I used a different one that is running Ubuntu 10.04 32-bit.
First I verified that the problem I reported above can be recreated on this other system. I quickly managed to confirm that it can.
I then installed the kernel you requested: [3.7.0-030700ec7-generic] and rebooted with it.
The same problem was easy to recreate on this latest kernel as well.

Just so you know, this type of USB/SATA enclosure is very common as it is a low cost one sold, for example, on eBay:

http://www.ebay.com/itm/271107977244

[Joseph Salisbury (jsalisbury)]

If possible, can you take a look at the following wiki page:
https://wiki.ubuntu.com/Kernel/Debugging/USB

It would be helpful if you could gather some USB tracing data.

[Tal Nevo (talnevo-i)]

The following tar file (usb-debug.tgz) contains debugging obtained using the instructions in the link provided above.

I used two USB enclosures with the SATA hard drive, one that "works" and the one that exhibits the bug.
Testing was done with the last kernel installed (3.7.0-030700rc7).

I zeroed a large chunk at the beginning of the drive with the "good" USB interface and collected the data from /sys/kernel/debug/usb/usbmon/1u for two runs:

dd if=/dev/zero of=/dev/sdb bs=1M count=100
dd if=/dev/zero of=/dev/sdb sb=64K count=1000

I verified after each run that the drive was indeed zero by running hexdump.

I then repeated the same two dd tests with the "bad" USB (I zeroed the drive using the "good" interface in between). and also collected a hexdump of the drive (that shows the USBC headers that should not be there).

The bus traces are named bus1data*.txt and are marked "good" and "bad" depending on which USB interface was used.

I hope this will help.

[Olcay Korkmaz (olci)]

maybe helpful

quota from https://bbs.archlinux.org/viewtopic.php?pid=1204327

Hello,
If you are still interested, I may have found the cause of the HDD enclosure corrupting your drive.
http://code.metager.de/source/history/linux/stable/drivers/usb/storage/unusual_cypress.h
the patch submitted on 2010-10-19 causes problems with my enclosure, having the same id as yours. After removing that patch, my drive works as expected.I've already contacted the person who submitted the patch, and his bcdDevice number is 1.60, could you please check yours, so we can retarget the patch only to those actually affected.
Mine is the following:
$ lsusb -vd 14cd:6116
(...)
  idVendor 0x14cd Super Top
  idProduct 0x6116 M6116 SATA Bridge
  bcdDevice 2.20

Thanks for your help,

[Tal Nevo (talnevo-i)]

Hi,

I got the same numbers as mentioned above:

  idVendor 0x14cd Super Top
  idProduct 0x6116 M6116 SATA Bridge
  bcdDevice 2.20

Must be the same problem...

[Olcay Korkmaz (olci)]

Same problem here

my device is same as yours

  idVendor 0x14cd Super Top
  idProduct 0x6116 M6116 SATA Bridge
  bcdDevice 2.20

[Joseph Salisbury (jsalisbury)]

Do you happen to know if there was a prior Ubuntu release that did not exhibit this bug?

Also, the v3.8-rc2 mainline kernel is now available. Can you test that kernel as well? It can be downloaded from:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.8-rc2-raring/

Thanks in advance!

[Nicolas (krementnico)]

Same here, same numbers, almost same output for the dd test. (Just slightly different, not writing 0's only anyway).

I'm not sure this would be of any help but the problem appears on raspbian as well.

I'm keen to test that new kernel but I don't have any free machines. I could probably try to install the kernel on a live cd and test from here ?

[Janne Peltonen (janne-peltonen)]

Hi,

I'm suffering from the same problem.
Is there a "dummys quide" somewhere, that would describe compiling a driver module? I "managed" to compile the usb-storage.ko file again, but it ended about 10% different in size compared to the original, and not surprising, it does not work. I would appreciate any help you can offer.
Looking into the latest stable kernel there is (3.7.**) the bug still persists.

[Joseph Salisbury (jsalisbury)]

@Janne

The v3.8-rc3 kernel is not available. Can you test that kernel to see if it also exhibits this bug?

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.8-rc3-raring/

[Janne Peltonen (janne-peltonen)]

Ok I installed the 3.8-rc3 kernel, and after installing also the extras-package I got the usb devices to work.
But the same problem persists, trying to partition the hdd just fails.

[Joseph Salisbury (jsalisbury)]

This issue appears to be an upstream bug, since you tested the latest upstream kernel. Would it be possible for you to open an upstream bug report[0]? That will allow the upstream Developers to examine the issue, and may provide a quicker resolution to the bug.

Please follow the instructions on the wiki page[0]. The first step is to email the appropriate mailing list. If no response is received, then a bug may be opened on bugzilla.kernel.org.

[0] https://wiki.ubuntu.com/Bugs/Upstream/kernel

[Geo Magadan (nepotu)]

@Tal Nevo have you opened an upstream bug? I am curios what is the status of this bug as I am affected as well. I don't know if I should wait for a bug fix or I should look for another HDD enclosure. I can buy another usb drive, that's not an issue, but I don't know what vendor to choose (the model I own now is Spire SP155SUO-BK).

I have also tried it with the latest mainline kernel (v3.8-rc5-raring) and the issue persist. In my case it's even worse as I haven't tried to write to the disk (just mounted and umounted) and the partition was messed up.

Regards,
Geo

[madbiologist (me-again)]

This is fixed upstream in kernel 3.8.1 by the following patch:

commit c8f96b36a83763b2cdedaec489eb39d3394a2366
Author: Josh Boyer
Date: Thu Feb 14 09:39:09 2013 -0500

    USB: usb-storage: unusual_devs update for Super TOP SATA bridge

    commit 18e03310b5caa6d11c1a8c61b982c37047693fba upstream.

    The current entry in unusual_cypress.h for the Super TOP SATA bridge devices
    seems to be causing corruption on newer revisions of this device. This has
    been reported in Arch Linux and Fedora. The original patch was tested on
    devices with bcdDevice of 1.60, whereas the newer devices report bcdDevice
    as 2.20. Limit the UNUSUAL_DEV entry to devices less than 2.20.

    This fixes https://bugzilla.redhat.com/show_bug.cgi?id=909591

    The Arch Forum post on this is here:
     https://bbs.archlinux.org/viewtopic.php?id=152011

    Reported-by: Carsten S.
    Tested-by: Carsten S.
    Signed-off-by: Josh Boyer
    Signed-off-by: Greg Kroah-Hartman

This patch is also available in the upstream 3.0.67 kernel as commit cfb2ddcace95399e4dcefebb62e16cd93c9d4ae7 which should soon make it's way into Oneiric. It will hopefully also end up in the upstream 3.2.x kernel series soon so that it will make it's way into Precise.

The 3.5.x upstream kernel series is EOL (end of life), maybe Canonical can backport it to Quantal?

[madbiologist (me-again)]

The abovementioned fix is now available in the upstream 3.2.40 kernel. A PPA of this kernel is available at http://kernel.ubuntu.com/~kernel-ppa/mainline/ and instructions on how to install and uninstall it are available at https://wiki.ubuntu.com/Kernel/MainlineBuilds#Installing_Mainline_Kernels

This should eventually make it's way into Ubuntu 12.04 "Precise Pangolin".

[Julian Wiedmann (jwiedmann)]

Tal Nevo,
could you please test the latest kernel from -updates (3.2.0-40.64) and see if it fixes this bug?. Thank you.

[Tal Nevo (talnevo-i)]

Sorry,

I no longer have that specific HDD enclosure.

Tal

--- On Sat, 4/13/13, Julian Wiedmann <email address hidden> wrote:

> From: Julian Wiedmann <email address hidden>
> Subject: [Bug 1082215] Re: Writing on a certain USB HDD causes corruption
> To: <email address hidden>
> Date: Saturday, April 13, 2013, 3:47 AM
> Tal Nevo,
> could you please test the latest kernel from -updates
> (3.2.0-40.64) and see if it fixes this bug?. Thank you.
>
> ** Changed in: linux (Ubuntu)
>        Status: Fix Committed =>
> Incomplete
>
> --
> You received this bug notification because you are
> subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1082215
>
> Title:
>   Writing on a certain USB HDD causes corruption
>
> Status in “linux” package in Ubuntu:
>   Incomplete
>
> Bug description:
>   I bought an external USB enclosure for a SATA 2.5"
> hard drive. When using this USB drive with Microsoft
> Windows, it works perfectly - I have no problems reading and
> writing from/to the drive.
>   However when using this USB drive in Ubuntu (10.04 as
> well as 12.04) I can read the data on the drive without a
> problem, however after I wrote to the drive I started
> getting corruption errors.
>
>   To simplify the detection of the problem I used a new
> empty hard drive with this USB enclosure.
>   I wrote zeroes on about 1GB of the start of the drive
> (using a different USB to SATA interface).
>   When I read from the drive using the commands
>
>   dd if=/dev/sdb of=/tmp/xxx bs=1M count=100
>   hexdump -C xxx
>
>   The output of hexdump indicates that all that was
> read were zeroes:
>
>   00000000  00 00 00 00 00 00 00 00  00 00 00
> 00 00 00 00 00  |................|
>   *
>   06400000
>
>   However, after I run the following command (writes to
> drive):
>
>   dd if=/dev/zero of=/dev/sdb bs=1M count=100
>
>   and then these commands:
>
>   dd if=/dev/sdb of=/tmp/xxx bs=1M count=100
>   hexdump -C xxx  | less
>
>   I get the following output:
>   00000000  55 53 42 43 96 5f 00 00  00 e0 01
> 00 00 00 0a 2a  |USBC._.........*|
>   00000010  00 00 00 00 00 00 00 f0  00 00 00
> 00 00 00 00 18  |................|
>   00000020  00 00 00 00 00 00 00 00  00 00 00
> 00 00 00 00 00  |................|
>   *
>   0001e000  55 53 42 43 97 5f 00 00  00 e0 01
> 00 00 00 0a 2a  |USBC._.........*|
>   0001e010  00 00 00 00 f0 00 00 f0  00 00 00
> 00 00 00 00 e5  |................|
>   0001e020  00 00 00 00 00 00 00 00  00 00 00
> 00 00 00 00 00  |................|
>   *
>   0003c000  55 53 42 43 98 5f 00 00  00 e0 01
> 00 00 00 0a 2a  |USBC._.........*|
>   0003c010  00 00 00 01 e0 00 00 f0  00 00 00
> 00 00 00 00 4c  |...............L|
>   0003c020  00 00 00 00 00 00 00 00  00 00 00
> 00 00 00 00 00  |................|
>   *
>   0005a000  55 53 42 43 99 5f 00 00  00 e0 01
> 00 00 00 0a 2a  |USBC._.........*|
>   0005a010  00 00 00 02 d0 00 00 f0  00 00 00
> 00 00 00 00 49  |...............I|
>   0005a020  00 00 00 00 00 00 00 00  00 00 00
> 00 00 00 00 00  |................|
>   *
>   00078000  55 53 42 43 9a 5f 00 00  00 e0 01
> 00 00 00 0a 2a  |USBC._.........*|
>   00078010  00 00 00 03 c0 00 00 f0  00 00 00
> 00 00 00 00 e1  |.......

[madbiologist (me-again)]

Can anyone else test?

[Andrey (abelt)]

Sorry, mistyped again. Fixed version:
Device 14cd:6116 with bcdDeice 1.60 doesn't work in Raring. https://bugs.launchpad.net/ubuntu/+source/libatasmart/+bug/1161985
Working fine in 12.04 (Preceise) with stock kernel.

I can test it on both systems, but I don't want to corrupt the data! I have no spare disk at the moment.

[Janne Peltonen (janne-peltonen)]

Hi,

After the latest official kernel patch(3.2.0.40) for my xubuntu 12.04 , my external HDD now works. Lsusb -v reports, that the bcdDevice = 2.20 for my HDD.

[Olcay Korkmaz (olci)]

Hi

Working fine on raring with 3.8.0-19 kernel

  idVendor 0x14cd Super Top
  idProduct 0x6116 M6116 SATA Bridge
  bcdDevice 2.20

[CassieMoondust (cassie-lx)]

Like in comment #31 I have the same issues with Raring Ringtail Final release Kernel 3.9.0-19-generic.

The same device works fine in Ubuntu 12.04.2 with Kernel 3.5.0-28-generic.

[CassieMoondust (cassie-lx)]

Correction to comment #34:

The correct Raring-Kernel is 3.8.0-19-generic

[André Pirard (a.pirard)]

I am one of the victims of the bug described above.
In fact, my neigbour is the victim: Ubuntu destroyed her Windows partition.
I was trying to help her.
That is more than a reason to turn people away from Linux.
But what is written here above is another reason.
It is perfectly incomprehensible.

For the sake of Ubuntu, may I once again recommend:

- to add keywords of the bug description to indicate the affected versions (starting kernel X, fixed in Y)
- to mark as important such things as data destruction, to tick "affects you" (and allow anyone to tick?)
- in addition to "Bug description", to create a "Bug correction" in which any Ubuntu user can find in words he understands how to correct or circumvent his problem *in the system version he is using*.
No "fixed", "patch released" or "upgrade" please.
- in case the problem occurs with a particular hardware, to insistingly ask the manufacturers to indicate in their specifications "Supported OS: Linux kernel ≥ X or Ubuntu ≥ Y".

It would have saved me days used to run tests, to find out the reason and the correction.
And most of all, it would have saved my neighbour's disk !!!

[André Pirard (a.pirard)]

It sounds as this bug was fixed in Kernel 3.8.1.
Use System>Administration>Synaptic and install
linux-image-3.8.1-??-generic
linux-headers-3.8.1-??-generic
reboot and make sure this kernel is running

[madbiologist (me-again)]

The kernel mentioned in comment #37 is no longer officially supported on any supported version of Ubuntu, and in fact would be a downgrade on Ubuntu 14.04 "Trusty Tahr" and later versions. Users should simply install all updates offered by update manager.

[madbiologist (me-again)]

Re comment #36: What is written in the previous comments is a troubleshooting (diagnostic) process, not a user support forum. Troubleshooting is often necessary for bug reports. The suggestions in comment #36 would be problematic to implement, however there is probably an opportunity to make more use of Launchpad's Ubuntu version targeting feature.

[madbiologist (me-again)]

Also, we can only make polite requests to hardware manufacturers. The real problem is that hardware manufacturers focus their testing on Windows and sometimes Mac Os X, with little or no testing on Linux or BSD.