Constant warnings from the kernel: Test WP failed, assume Write Enabled

[Julian Alarcon]

I have this problem with this Laptop Acer 5735-4624, when I change to a TTY (Ctrl+Alt+F1..) I got this message everytime

Feb 2 17:07:12 telintel26 kernel: [33802.064779] sd 4:0:0:0: [sdb] Test WP failed, assume Write Enabled
Feb 2 17:07:12 telintel26 kernel: [33802.067026] sd 4:0:0:0: [sdb] Asking for cache data failed
Feb 2 17:07:12 telintel26 kernel: [33802.067034] sd 4:0:0:0: [sdb] Assuming drive cache: write through

This are just warnings, because all seems to work OK but are really nasty messages because appear every time even if you are running another program (example: top)

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: linux-image-3.2.0-12-generic 3.2.0-12.21
ProcVersionSignature: Ubuntu 3.2.0-12.21-generic 3.2.2
Uname: Linux 3.2.0-12-generic x86_64
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
AplayDevices:
 **** List of PLAYBACK Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: ALC268 Analog [ALC268 Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
ApportVersion: 1.91-0ubuntu1
Architecture: amd64
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: ALC268 Analog [ALC268 Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: alarconj 1752 F.... pulseaudio
Card0.Amixer.info:
 Card hw:0 'Intel'/'HDA Intel at 0xf8900000 irq 47'
   Mixer name : 'Realtek ALC268'
   Components : 'HDA:10ec0268,10250176,00100101 HDA:11c11040,11c10001,00100200'
   Controls : 16
   Simple ctrls : 9
Date: Thu Feb 2 17:06:19 2012
HibernationDevice: RESUME=UUID=bb53f046-48a6-441f-82c7-0e0fdb12ce2f
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64 (20120102)
MachineType: Acer Aspire 5735
ProcEnviron:
 LANGUAGE=es_CO:es
 PATH=(custom, no user)
 LANG=es_CO.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-12-generic root=UUID=6da9a4fd-7e97-4217-b00e-4c5c5bd76813 ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.2.0-12-generic N/A
 linux-backports-modules-3.2.0-12-generic N/A
 linux-firmware 1.68
SourcePackage: linux
UpgradeStatus: Upgraded to precise on 2012-01-26 (7 days ago)
dmi.bios.date: 12/04/2008
dmi.bios.vendor: Phoenix Technologies LTD
dmi.bios.version: V1.10
dmi.board.name: CathedralPeak
dmi.board.vendor: Acer
dmi.board.version: Rev
dmi.chassis.type: 10
dmi.chassis.vendor: Acer
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnPhoenixTechnologiesLTD:bvrV1.10:bd12/04/2008:svnAcer:pnAspire5735:pvr0100:rvnAcer:rnCathedralPeak:rvrRev:cvnAcer:ct10:cvrN/A:
dmi.product.name: Aspire 5735
dmi.product.version: 0100
dmi.sys.vendor: Acer
---
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
AplayDevices:
 **** List of PLAYBACK Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: ALC268 Analog [ALC268 Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
ApportVersion: 1.94-0ubuntu1
Architecture: amd64
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: ALC268 Analog [ALC268 Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: alarconj 2078 F.... pulseaudio
Card0.Amixer.info:
 Card hw:0 'Intel'/'HDA Intel at 0xf8900000 irq 47'
   Mixer name : 'Realtek ALC268'
   Components : 'HDA:10ec0268,10250176,00100101 HDA:11c11040,11c10001,00100200'
   Controls : 16
   Simple ctrls : 9
DistroRelease: Ubuntu 12.04
HibernationDevice: RESUME=UUID=bb53f046-48a6-441f-82c7-0e0fdb12ce2f
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64 (20120102)
MachineType: Acer Aspire 5735
Package: linux (not installed)
ProcEnviron:
 LANGUAGE=es_CO:es
 TERM=xterm
 PATH=(custom, no user)
 LANG=es_CO.UTF-8
 SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-18-generic root=UUID=6da9a4fd-7e97-4217-b00e-4c5c5bd76813 ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.2.0-18.28-generic 3.2.9
RelatedPackageVersions:
 linux-restricted-modules-3.2.0-18-generic N/A
 linux-backports-modules-3.2.0-18-generic N/A
 linux-firmware 1.71
Tags: precise
Uname: Linux 3.2.0-18-generic x86_64
UpgradeStatus: Upgraded to precise on 2012-02-17 (16 days ago)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
dmi.bios.date: 12/04/2008
dmi.bios.vendor: Phoenix Technologies LTD
dmi.bios.version: V1.10
dmi.board.name: CathedralPeak
dmi.board.vendor: Acer
dmi.board.version: Rev
dmi.chassis.type: 10
dmi.chassis.vendor: Acer
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnPhoenixTechnologiesLTD:bvrV1.10:bd12/04/2008:svnAcer:pnAspire5735:pvr0100:rvnAcer:rnCathedralPeak:rvrRev:cvnAcer:ct10:cvrN/A:
dmi.product.name: Aspire 5735
dmi.product.version: 0100
dmi.sys.vendor: Acer
---
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
AplayDevices:
 **** List of PLAYBACK Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: ALC268 Analog [ALC268 Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
ApportVersion: 1.94-0ubuntu1
Architecture: amd64
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: ALC268 Analog [ALC268 Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: alarconj 2078 F.... pulseaudio
Card0.Amixer.info:
 Card hw:0 'Intel'/'HDA Intel at 0xf8900000 irq 47'
   Mixer name : 'Realtek ALC268'
   Components : 'HDA:10ec0268,10250176,00100101 HDA:11c11040,11c10001,00100200'
   Controls : 16
   Simple ctrls : 9
DistroRelease: Ubuntu 12.04
HibernationDevice: RESUME=UUID=bb53f046-48a6-441f-82c7-0e0fdb12ce2f
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64 (20120102)
MachineType: Acer Aspire 5735
Package: linux-image-3.2.0-18-generic 3.2.0-18.28
PackageArchitecture: amd64
ProcEnviron:
 LANGUAGE=es_CO:es
 TERM=xterm
 PATH=(custom, no user)
 LANG=es_CO.UTF-8
 SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-18-generic root=UUID=6da9a4fd-7e97-4217-b00e-4c5c5bd76813 ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.2.0-18.28-generic 3.2.9
RelatedPackageVersions:
 linux-restricted-modules-3.2.0-18-generic N/A
 linux-backports-modules-3.2.0-18-generic N/A
 linux-firmware 1.71
Tags: precise
Uname: Linux 3.2.0-18-generic x86_64
UpgradeStatus: Upgraded to precise on 2012-02-17 (16 days ago)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
dmi.bios.date: 12/04/2008
dmi.bios.vendor: Phoenix Technologies LTD
dmi.bios.version: V1.10
dmi.board.name: CathedralPeak
dmi.board.vendor: Acer
dmi.board.version: Rev
dmi.chassis.type: 10
dmi.chassis.vendor: Acer
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnPhoenixTechnologiesLTD:bvrV1.10:bd12/04/2008:svnAcer:pnAspire5735:pvr0100:rvnAcer:rnCathedralPeak:rvrRev:cvnAcer:ct10:cvrN/A:
dmi.product.name: Aspire 5735
dmi.product.version: 0100
dmi.sys.vendor: Acer

[Ralf (ralf-redhat-bugs)]

Description of problem:

Since having upgraded to F16 from F14, I am drowning in messages similar to the one below on the console (corrupting any console output)

[ 1400.353433] sd 4:0:0:0: [sdb] Asking for cache data failed
[ 1400.356601] sd 4:0:0:0: [sdb] Assuming drive cache: write through

accompanied by a message similar to the one in /var/log/messages (gradually filling it up)

[ 1400.351374] sd 4:0:0:0: [sdb] Test WP failed, assume Write Enabled
[ 1400.353433] sd 4:0:0:0: [sdb] Asking for cache data failed
[ 1400.356601] sd 4:0:0:0: [sdb] Assuming drive cache: write through

This machine (a netbook) only has one hard disk. sdb seems to refer to the builtin usb card reader.

Version-Release number of selected component (if applicable):
kernel-PAE-3.1.5-6.fc16.i686

How reproducible:
100%

Expected results:
The kernel not to raise these warnings/errors, but to work flawlessly (Older kernels did).

I am inclined to believe the kernel is not handling this sdb device properly.

[Dave (dave-redhat-bugs)]

please attach the dmesg output from a fresh boot.
need to see exactly which device we're working with here.

[Ralf (ralf-redhat-bugs)]

Created attachment 549125
dmesg of the system exposing this issue

[Dave (dave-redhat-bugs)]

reported to upstream maintainer. thanks.

[Ralf (ralf-redhat-bugs)]

(In reply to comment #3)
> reported to upstream maintainer. thanks.
Welcome.

Any upstream BZ/PR? Any patch proposals, workarounds to try?

[Joe (joe-redhat-bugs)]

I've been getting the same messages during boot on my laptop ever since "upgrading" from F14 to F16 and the boot process hangs right there. The only way I can use my laptop is to boot with the last 2.X kernel from F14, which works fine. No matter what 3.X kernel I try, this happens. My laptop only has one internal HDD, and I never have a CD or flash drive mounted during boot if that helps. If there's a way for me to get some data about a failed boot, please let me know and I'll do what's needed.

[Joe (joe-redhat-bugs)]

More info. Ever since the "upgrade," the CD/DVD on my laptop has been unusable. If I into a 3.x kernel with it empty, I get the endless [sdb] errors and putting a known-good CD in the drive first doesn't change anything.

[Julian Alarcon (julian-alarcon)]

Maybe this problem is related to the Multi Card reader , if you need more info just let me know.

Bus 001 Device 002: ID 0bda:0158 Realtek Semiconductor Corp. USB 2.0 multicard reader

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.3 kernel[1] (Not a kernel in the daily directory). Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag(Only that one tag, please leave the other tags). This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

If this bug is fixed by the mainline kernel, please add the following tag 'kernel-fixed-upstream-KERNEL-VERSION'. For example, if kernel version 3.3-rc2 fixed the issue, the tag would be: 'kernel-fixed-upstream-v3.3-rc2'.

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.

[Brad Figg (brad-figg)]

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

[Neal McBurnett (nealmcb)]

I get the same 3 messages in /var/log/syslog every 52 seconds on my Dell mini 1012.
I get it both with the recent Ubuntu kernel 3.2.0-15,
and with the latest Ubuntu-built mainline kernel: 3.3.0-030300rc4-generic-pae

[Neal McBurnett (nealmcb)]

.... and the bug is also there in the latest precise kernel: 3.2.0-17-generic #26-Ubuntu

My dmesg is attached.

[Neal McBurnett (nealmcb)]

I do not see the bug when booting in precise using the oneiric kernel 3.0.0-16-generic

I do see the same bug in 3.1: ~kernel-ppa/mainline/v3.1.10-precise - the Ubuntu build of the mainline 3.1.10 kernel: 3.1.10-030110-generic #201201181135

So it looks like a regression in the mainline kernel 3.1

And I hate it when my logs and consoles get filled up with stuff that doesn't otherwise matter :/

The code that prints the KERN_NOTICE messages is in linux/drivers/scsi/sd.c, and says it is only called when sd_revalidate_disk() is called. Why would that be called every 52 seconds? Here are some snippets from around each of the three messages:

* ... read write protect setting, if possible - called only in sd_revalidate_disk()
sd_read_write_protect_flag(struct scsi_disk *sdkp, unsigned char *buffer)
{....
  if (sdp->skip_ms_page_3f) {
  sd_printk(KERN_NOTICE, sdkp, "Assuming Write Enabled\n");
...
 if (!scsi_status_is_good(res)) {
  sd_printk(KERN_WARNING, sdkp,
     "Test WP failed, assume Write Enabled\n");

...
sd_read_cache_type - called only from sd_revalidate_disk()
....
 if (scsi_sense_valid(&sshdr) &&
     sshdr.sense_key == ILLEGAL_REQUEST &&
     sshdr.asc == 0x24 && sshdr.ascq == 0x0)
  /* Invalid field in CDB */
  sd_printk(KERN_NOTICE, sdkp, "Cache data unavailable\n");
 else
  sd_printk(KERN_ERR, sdkp, "Asking for cache data failed\n");

[Neal McBurnett (nealmcb)]

2 WORKAROUNDS:
I can at least get it to shut up by doing "sudo rmmod ums_realtek"

If I subsequently do a "sudo modprobe ums_realtek" the messages start showing up again every 52 seconds.

If I actually try use the sdb device (which is the SD card in my dell mini 1012 netbook) by inserting an SD card, the card seems to work fine - it automatically reloads the module and mounts the card.

And, in addition, inserting a card also makes the messages go away, even after the card is removed, and even though ums_realtek remains loaded.

[Neal McBurnett (nealmcb)]

Aha - it turns out the second workaround (inserting an SD card) stopped working when I re-inserted the little inert plastic insert that fills in the SD card hole when you're not using it.

So the real workaround is to pull that out and leave it out, or to remove the kernel module.

This also suggests what is going on - for some reason the driver now seems to be constantly trying to figure out what is going on with the inert plastic insert. I'm guessing that some change for the 3.1 kernel is now kicking off that behavior.

[Neal McBurnett (nealmcb)]

I did one more rmmod command, and got a kernel oops (but not a crash) which is now documented at bug 936652.

[Julian Alarcon (julian-alarcon)]

Good news: The error do't come up over and over again in the tty.
Bad news: The error is still there, using lastest Ubuntu 12.04 (Linux telintel26 3.2.0-17-generic #26-Ubuntu SMP Fri Feb 17 21:35:49 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux)

Feb 22 16:08:25 telintel26 kernel: [ 2940.441575] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
Feb 22 16:08:25 telintel26 kernel: [ 2940.441583] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
Feb 22 16:09:01 telintel26 kernel: [ 2977.061171] sd 4:0:0:0: [sdb] Test WP failed, assume Write Enabled
Feb 22 16:09:01 telintel26 kernel: [ 2977.063289] sd 4:0:0:0: [sdb] Asking for cache data failed
Feb 22 16:09:01 telintel26 kernel: [ 2977.063297] sd 4:0:0:0: [sdb] Assuming drive cache: write through
Feb 22 16:09:53 telintel26 kernel: [ 3029.060664] sd 4:0:0:0: [sdb] Test WP failed, assume Write Enabled
Feb 22 16:09:53 telintel26 kernel: [ 3029.062794] sd 4:0:0:0: [sdb] Asking for cache data failed
Feb 22 16:09:53 telintel26 kernel: [ 3029.062802] sd 4:0:0:0: [sdb] Assuming drive cache: write through

[Brad Figg (brad-figg)]

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

[Neal McBurnett (nealmcb)]

Two of us already reported that 3.2.0-17.26 fails. I removed the tag also.

[Brad Figg (brad-figg)]

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

[Neal McBurnett (nealmcb)]

Hmm - maybe I shouldn't have removed that tag.... :/

[Julian Alarcon (julian-alarcon)]

I already test the last kernel, and was trying to add the info to this bug, but apport crash.

Last kernel in Ubuntu 12.04, Linux telintel26 3.2.0-17-generic #26-Ubuntu SMP Fri Feb 17 21:35:49 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux, also has this bug.

I you are curious, this is the apport bug (private for now):
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/939589

[Brad Figg (brad-figg)]

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

[Mark (mark-redhat-bugs)]

I'm seeing this also on a laptop with builtin card reader. Every 50 seconds or so:

kernel: [ 312.932881] sd 6:0:0:0: [sdb] Test WP failed, assume Write Enabled
kernel: [ 312.935878] sd 6:0:0:0: [sdb] Asking for cache data failed
kernel: [ 312.935888] sd 6:0:0:0: [sdb] Assuming drive cache: write through

But if I remove the plastic fake SD card which fits in the slot to prevent dust, etc:

kernel: [ 317.199029] usb 2-1.6: USB disconnect, device number 4

Then the kernel messages stop. On reinsertion of the fake card:

kernel: [ 556.312591] usb 2-1.6: New USB device found, idVendor=0bda, idProduct=0138
kernel: [ 556.312601] usb 2-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
kernel: [ 556.312608] usb 2-1.6: Product: USB2.0-CRW
kernel: [ 556.312612] usb 2-1.6: Manufacturer: Generic
kernel: [ 556.312616] usb 2-1.6: SerialNumber: 20090516388200000
kernel: [ 556.494090] scsi7 : usb-storage 2-1.6:1.0
mtp-probe: checking bus 2, device 5: "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.6"
mtp-probe: bus: 2, device: 5 was not an MTP device
kernel: [ 557.517025] scsi 7:0:0:0: Direct-Access Generic- Multi-Card 1.00 PQ: 0 ANSI: 0 CCS
kernel: [ 557.519450] sd 7:0:0:0: Attached scsi generic sg2 type 0
kernel: [ 564.710556] sd 7:0:0:0: [sdb] Attached SCSI removable disk
kernel: [ 608.214558] sd 7:0:0:0: [sdb] Test WP failed, assume Write Enabled
kernel: [ 608.217681] sd 7:0:0:0: [sdb] Asking for cache data failed
kernel: [ 608.217691] sd 7:0:0:0: [sdb] Assuming drive cache: write through

and so on...

[Pete (pete-redhat-bugs)]

So, what component does poke sdb? I have the same problem on a small server
with a built-in SD reader. I killed smartd and cupsd (with colord). Only
systemd, udev, and networking servers remai.

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

apport information

[Julian Alarcon (julian-alarcon)]

I jst added the info (twice, sorry) for the kernel linux-image-3.2.0-18-generic
So, the error is still there.

[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 at bugzilla.kernel.org [1]? That will allow the upstream Developers to examine the issue, and may provide a quicker resolution to the bug.

If you are comfortable with opening a bug upstream, It would be great if you can report back the upstream bug number in this bug report. That will allow us to link this bug to the upstream report.

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

[Samuel (samuel-redhat-bugs)]

Has any found a workaround for this. I am on fedora 16 and have the latest updates and i get this message. It does not boot to the graphical interface but continues to give me this error.

[Petr (petr-redhat-bugs)]

This problem appeared on my Gentoo after I upgraded udev (to version 182) and enabled DEVTMPFS in kernel (3.2.11) because this udev has started to require it. Since this change I get these three messages in kernel log each 52 seconds. The block device is USB memory card reader (0bda:0158 Realtek Semiconductor Corp. USB 2.0 multicard reader) without a medium.

[Petr (petr-redhat-bugs)]

The kernel messages correlate with following kernel/udev events:

KERNEL[684.511147] change /devices/pci0000:00/0000:00:0e.5/usb4/4-1/4-1:1.0/host2/target2:0:0/2:0:0:0/block/sdb (block)
ACTION=change
DEVNAME=/dev/sdb
DEVPATH=/devices/pci0000:00/0000:00:0e.5/usb4/4-1/4-1:1.0/host2/target2:0:0/2:0:0:0/block/sdb
DEVTYPE=disk
DISK_MEDIA_CHANGE=1
MAJOR=8
MINOR=16
SEQNUM=725
SUBSYSTEM=block

UDEV [684.602048] change /devices/pci0000:00/0000:00:0e.5/usb4/4-1/4-1:1.0/host2/target2:0:0/2:0:0:0/block/sdb (block)
ACTION=change
DEVLINKS=/dev/disk/by-id/usb-Generic-_Multi-Card_20071114173400000-0:0 /dev/disk/by-path/pci-0000:00:0e.5-usb-0:1:1.0-scsi-0:0:0:0
DEVNAME=/dev/sdb
DEVPATH=/devices/pci0000:00/0000:00:0e.5/usb4/4-1/4-1:1.0/host2/target2:0:0/2:0:0:0/block/sdb
DEVTYPE=disk
DISK_MEDIA_CHANGE=1
ID_BUS=usb
ID_INSTANCE=0:0
ID_MODEL=Multi-Card
ID_MODEL_ENC=Multi-Card\x20\x20\x20\x20\x20\x20
ID_MODEL_ID=0158
ID_PATH=pci-0000:00:0e.5-usb-0:1:1.0-scsi-0:0:0:0
ID_PATH_TAG=pci-0000_00_0e_5-usb-0_1_1_0-scsi-0_0_0_0
ID_REVISION=1.00
ID_SERIAL=Generic-_Multi-Card_20071114173400000-0:0
ID_SERIAL_SHORT=20071114173400000
ID_TYPE=disk
ID_USB_DRIVER=ums-realtek
ID_USB_INTERFACES=:080650:
ID_USB_INTERFACE_NUM=00
ID_VENDOR=Generic-
ID_VENDOR_ENC=Generic-
ID_VENDOR_ID=0bda
MAJOR=8
MINOR=16
SEQNUM=725
SUBSYSTEM=block
USEC_INITIALIZED=10909217

KERNEL[687.073016] change /devices/pci0000:00/0000:00:0e.5/usb4/4-1/4-1:1.0/host2/target2:0:0/2:0:0:0/block/sdb (block)
ACTION=change
DEVNAME=/dev/sdb
DEVPATH=/devices/pci0000:00/0000:00:0e.5/usb4/4-1/4-1:1.0/host2/target2:0:0/2:0:0:0/block/sdb
DEVTYPE=disk
DISK_MEDIA_CHANGE=1
MAJOR=8
MINOR=16
SEQNUM=726
SUBSYSTEM=block

UDEV [687.089178] change /devices/pci0000:00/0000:00:0e.5/usb4/4-1/4-1:1.0/host2/target2:0:0/2:0:0:0/block/sdb (block)
ACTION=change
DEVLINKS=/dev/disk/by-id/usb-Generic-_Multi-Card_20071114173400000-0:0 /dev/disk/by-path/pci-0000:00:0e.5-usb-0:1:1.0-scsi-0:0:0:0
DEVNAME=/dev/sdb
DEVPATH=/devices/pci0000:00/0000:00:0e.5/usb4/4-1/4-1:1.0/host2/target2:0:0/2:0:0:0/block/sdb
DEVTYPE=disk
DISK_MEDIA_CHANGE=1
ID_BUS=usb
ID_INSTANCE=0:0
ID_MODEL=Multi-Card
ID_MODEL_ENC=Multi-Card\x20\x20\x20\x20\x20\x20
ID_MODEL_ID=0158
ID_PATH=pci-0000:00:0e.5-usb-0:1:1.0-scsi-0:0:0:0
ID_PATH_TAG=pci-0000_00_0e_5-usb-0_1_1_0-scsi-0_0_0_0
ID_REVISION=1.00
ID_SERIAL=Generic-_Multi-Card_20071114173400000-0:0
ID_SERIAL_SHORT=20071114173400000
ID_TYPE=disk
ID_USB_DRIVER=ums-realtek
ID_USB_INTERFACES=:080650:
ID_USB_INTERFACE_NUM=00
ID_VENDOR=Generic-
ID_VENDOR_ENC=Generic-
ID_VENDOR_ID=0bda
MAJOR=8
MINOR=16
SEQNUM=726
SUBSYSTEM=block
USEC_INITIALIZED=10909217

Both media-change events generated by kernel appears during one cycle.

Once I need to use the reader, I found kernel does not signal insertion of a medium, I had to manually rescan partion table with blockdev --rereadpt. These spurious periodic media events could be a work-around implemented in kernel for the special hardware.

[Christian Kujau (christiank)]

Still present with3.2.0-24-generic. Upstream bug: https://bugzilla.kernel.org/show_bug.cgi?id=43191
The workaround from comment #8 works here (Lenovo Ideapad S10), thanks nealmcb :)

[Christian (christian-redhat-bugs)]

FWIW, https://bugzilla.kernel.org/show_bug.cgi?id=43191 seems to be the upstream bug.

[Joe (joe-redhat-bugs)]

I tried to boot my laptop into a 3.X kernel with a card in the reader. It got as far as recreating volatile files and directories, sat there for about ten minutes or so and rebooted. I then tried booting it (with the card still in place) into my trusty old 2.X kernel and It Just Worked. I can't speak for anybody else, but having a card in the reader not only doesn't work around the problem, it causes more problems earlier in the boot process. And, I'll admit, the idea of having to keep a memory card in the slot just to get your computer to boot would Just Be Wrong.

[mgoreiro (mgoreiro)]

Same problem with eMachines EL1200 after udate to Ubuntu 12.04 LTS. Made a fresh installation and problem still exists.

Dmesg reports as follow:

[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 3.2.0-24-generic (buildd@yellow) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #37-Ubuntu SMP Wed Apr 25 08:43:22 UTC 2012 (Ubuntu 3.2.0-24.37-generic 3.2.14)
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-24-generic root=UUID=bee2c41d-b1e9-44ca-862d-c0d29bac17c6 ro quiet splash vt.handoff=7
[ 0.000000] KERNEL supported cpus:
[ 0.000000] Intel GenuineIntel
[ 0.000000] AMD AuthenticAMD
[ 0.000000] Centaur CentaurHauls
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
[ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 0000000037ee0000 (usable)
[ 0.000000] BIOS-e820: 0000000037ee0000 - 0000000037ee3000 (ACPI NVS)
[ 0.000000] BIOS-e820: 0000000037ee3000 - 0000000037ef0000 (ACPI data)
[ 0.000000] BIOS-e820: 0000000037ef0000 - 0000000037f00000 (reserved)
[ 0.000000] BIOS-e820: 0000000038000000 - 0000000040000000 (reserved)
[ 0.000000] BIOS-e820: 00000000f0000000 - 00000000f4000000 (reserved)
[ 0.000000] BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] DMI 2.5 present.
[ 0.000000] DMI: eMachines EL1200/WMCP61M, BIOS R01-A0L 09/17/2008
[ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
[ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
[ 0.000000] No AGP bridge found
[ 0.000000] last_pfn = 0x37ee0 max_arch_pfn = 0x400000000
[ 0.000000] MTRR default type: uncachable
[ 0.000000] MTRR fixed ranges enabled:
[ 0.000000] 00000-9FFFF write-back
[ 0.000000] A0000-BFFFF uncachable
[ 0.000000] C0000-C7FFF write-protect
[ 0.000000] C8000-FFFFF uncachable
[ 0.000000] MTRR variable ranges enabled:
[ 0.000000] 0 base 0000000000 mask FFC0000000 write-back
[ 0.000000] 1 disabled
[ 0.000000] 2 disabled
[ 0.000000] 3 disabled
[ 0.000000] 4 disabled
[ 0.000000] 5 disabled
[ 0.000000] 6 disabled
[ 0.000000] 7 disabled
[ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[ 0.000000] found SMP MP-table at [ffff8800000f3c50] f3c50
[ 0.000000] initial memory mapped : 0 - 20000000
[ 0.000000] Base memory trampoline at [ffff88000009a000] 9a000 size 20480
[ 0.000000] init_memory_mapping: 0000000000000000-0000000037ee0000
[ 0.000000] 0000000000 - 0037e00000 page 2M
[ 0.000000] 0037e00000 - 0037ee0000 page 4k
[ 0.000000] kernel direct mapping tables up to 37ee0000 @ 1fffd000-20000000
[ 0.000000] RAMDISK: 364e6000 - 3726b000
[ 0.000000] ACPI: RSDP 00000000000f8080 00014 (v00 ACRSYS)
[ 0.000000] ACPI: RSDT 0000000037ee3000 00038 (v01 ACRSYS ACRPRDCT 42302E31 NVDA 00...

[Daniel Mehrmann (daniel-mehrmann)]

Well, i have the same problem with my SD-Card reader and I can confirm that this bug is still there with Ubuntu 12.04.

I tested the latestest upstream kernel (3.4.0-030400rc6-generic #201205061835 SMP Sun May 6 22:42:47 UTC 2012 i686 i686 i386 GNU/Linux) and i have no good news for you. :-(

Sorry, I overlooked this report and marked my one #994414 as duplicated.

[Antonio (antonio-redhat-bugs-1)]

Same issue in Fedora 17; these messages, regarding USB card reader, appear with and without card. The only way to stop them is remove usb modules:

# modprobe -r ums_realtek

ums_realtek and usb-storage are interdependent.

[ilf (ilf)]

Same here, anything you need for it to progress?

[Andrei Cazimir (cazimir)]

I am running ubuntu 12.04 LTS 64 bit on a Dell Vostro 3550 and I have experienced this issue as well. However, the problem has been SOLVED by simply removing the factory installed dummy from the SD slot. Apparently, the relevant driver is designed to detect a SD module via the slot plug-in switch activation. As such, any object with the right shape that could activate this switch will be detected as a valid SD module. The ensuing syslog messages are a result of the automout trying (every ~ 45 seconds) to mount what is in fact an invalid device.

Should these messages be generated with an empty SD slot, I would suspect the slot plug-in switch to be faulty ("on" all the time).

Consequently, I do not believe this to be a kernel bug, although it may be possible to find a more reliable way to detect a valid SD module for the device driver.

Regards

[Joe (joe-redhat-bugs)]

I just tried booting my laptop with a F17 Live USB key. It worked, just fine, TYVM. Clearly, there's some interaction between the 3.X kernels and somethng else I have installed. Looks like the best way to fix this is back up anything I want to keep from my laptop (Not much, because it's not my main machine.) and do a complete nuke/pave/reinstall from scratch with F17.

[Sebastian Meyer (x-archimedes)]

For the record:
There is hardware with faulty slot plug-in switches, namely the EeeBox B202 (one of the earlier Intel-Atom-in-a-small-box-boxes).
Mine has an empty tray, but displays that message on the tty every 51 seconds.

lsusb reveals the "bad" device (snippet):
> Bus 001 Device 003: ID 0bda:0158 Realtek Semiconductor Corp. USB 2.0 multicard reader

Obviously, doing an rmmod ums_realtek solves the issue of annoying trash on the tty.

I am not fluent in rsyslog configuration, but maybe it is possible to reroute that message to /dev/null?

[Sebastien (tuzisan)]

Same problem on my Dell Mini 1010 with a solid state drive.

The workaround from comment #8 works, I've added these lines in the file /etc/rc.local to make this change "temporarily permanent":

# Avoid constant kernel warnings about missing cache on SSD
# see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/925760
rmmod ums_realtek

[ilf (ilf)]

Just blacklist the module in /etc/modprobe.d/blacklist.conf

[Nick Bunyan (nick-bunyan)]

Running 12.04 LTS on 64-bit AMD setup with a generic USB attached Multi-card reader. With all the slots in the reader empty (CF/SD/USB etc) the following appears in kern.log and syslog, repeating the whole block approximately every 55 seconds.

Oct 26 12:59:38 chi kernel: [238967.019095] sd 8:0:0:0: [sdd] Test WP failed, assume Write Enabled
Oct 26 12:59:38 chi kernel: [238967.021168] sd 8:0:0:0: [sdd] Asking for cache data failed
Oct 26 12:59:38 chi kernel: [238967.021174] sd 8:0:0:0: [sdd] Assuming drive cache: write through

Inserting a card or stick into any of the device slots generates 6 additional lines in the logs then stops the cycle. In other words this is only a problem when the device is 'empty'

FYI - the reader does NOT appear to have any specific card sensing mechanism, either switch or sensor, built in.

Rather than blacklisting the module, which I may want to use one day, I stuck an old SD card in the reader and the logs are quiet...

[Kaulbach (mystic-scientist)]

The "ss_en" option of the ums_realtek driver seems to solve this for me as I described in post #3 at http://askubuntu.com/questions/132100/errors-in-dmesg-test-wp-failed-assume-write-enabled
modinfo ums_realtek shows as options:

parm: auto_delink_en:enable auto delink (int)
parm: ss_en:enable selective suspend (int)
parm: ss_delay:seconds to delay before entering selective suspend (int)

Empirical testing shows that ss_delay value is how often the error will appear in the console.
Disabling the suspend with ss_en=0 still allows the reader to work but not suspend/wake every ss_delay amount of seconds.

This fix is still working for me as of Raring Ringtail with 64bit kernel 3.8.0-1-generic #5-Ubuntu

[Ralph Navarro (ralph-navarrocomputing)]

A better solution may be to get the Realtek developer to fix their driver.

On Tue, Jan 22, 2013 at 4:22 PM, Kaulbach <email address hidden> wrote:

> The "ss_en" option of the ums_realtek driver seems to solve this for me as
> I described in post #3 at
> http://askubuntu.com/questions/132100/errors-in-dmesg-test-wp-failed-assume-write-enabled
> modinfo ums_realtek shows as options:
>
> parm: auto_delink_en:enable auto delink (int)
> parm: ss_en:enable selective suspend (int)
> parm: ss_delay:seconds to delay before entering selective suspend (int)
>
> Empirical testing shows that ss_delay value is how often the error will
> appear in the console.
> Disabling the suspend with ss_en=0 still allows the reader to work but not
> suspend/wake every ss_delay amount of seconds.
>
> This fix is still working for me as of Raring Ringtail with 64bit kernel
> 3.8.0-1-generic #5-Ubuntu
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/925760
>
> Title:
> Constant warnings from the kernel: Test WP failed, assume Write
> Enabled
>
> Status in The Linux Kernel:
> In Progress
> Status in “linux” package in Ubuntu:
> Triaged
> Status in “linux” package in Fedora:
> Unknown
>
> Bug description:
> I have this problem with this Laptop Acer 5735-4624, when I change to
> a TTY (Ctrl+Alt+F1..) I got this message everytime
>
> Feb 2 17:07:12 telintel26 kernel: [33802.064779] sd 4:0:0:0: [sdb] Test
> WP failed, assume Write Enabled
> Feb 2 17:07:12 telintel26 kernel: [33802.067026] sd 4:0:0:0: [sdb]
> Asking for cache data failed
> Feb 2 17:07:12 telintel26 kernel: [33802.067034] sd 4:0:0:0: [sdb]
> Assuming drive cache: write through
>
> This are just warnings, because all seems to work OK but are really
> nasty messages because appear every time even if you are running
> another program (example: top)
>
> ProblemType: Bug
> DistroRelease: Ubuntu 12.04
> Package: linux-image-3.2.0-12-generic 3.2.0-12.21
> ProcVersionSignature: Ubuntu 3.2.0-12.21-generic 3.2.2
> Uname: Linux 3.2.0-12-generic x86_64
> AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
> AplayDevices:
> **** List of PLAYBACK Hardware Devices ****
> card 0: Intel [HDA Intel], device 0: ALC268 Analog [ALC268 Analog]
> Subdevices: 1/1
> Subdevice #0: subdevice #0
> ApportVersion: 1.91-0ubuntu1
> Architecture: amd64
> ArecordDevices:
> **** List of CAPTURE Hardware Devices ****
> card 0: Intel [HDA Intel], device 0: ALC268 Analog [ALC268 Analog]
> Subdevices: 1/1
> Subdevice #0: subdevice #0
> AudioDevicesInUse:
> USER PID ACCESS COMMAND
> /dev/snd/controlC0: alarconj 1752 F.... pulseaudio
> Card0.Amixer.info:
> Card hw:0 'Intel'/'HDA Intel at 0xf8900000 irq 47'
> Mixer name : 'Realtek ALC268'
> Components : 'HDA:10ec0268,10250176,00100101
> HDA:11c11040,11c10001,00100200'
> Controls : 16
> Simple ctrls : 9
> Date: Thu Feb 2 17:06:19 2012
> HibernationDevice: RESUME=UUID=bb53f046-48a6-441f-82c7-0e0fdb12ce2f
> InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64...

[Krzysztof Kosinski (tweenk)]

For a permanent workaround, create the file /etc/modprobe.d/ums-realtek.conf with the following content:

options ums_realtek ss_en=0

or execute this command:

sudo sh -c 'echo "options ums_realtek ss_en=0" > /etc/modprobe.d/ums-realtek.conf'

I think this bug could be declared fixed once the ss_en option is disabled by default. This can be done either by shipping a modprobe conffile or by changing the default value of the option in the kernel source.

The 'ss_en' switch controls 'selective suspend', e.g. suspending parts of the card reader which are not used. Typically only one card slot is in use at any time, so disabling would slightly decrease power consumption when a card is inserted. When there is no card, the reader would power down through the normal USB suspend mechanism.

[Neal McBurnett (nealmcb)]

Thank you, Krzysztof!! Your suggestion in comment #75 worked for me, at least it seems to be working after doing this to restart the module:

$ sudo rmmod ums_realtek
$ sudo modprobe ums_realtek

My current setup is a bit screwy, running 12.10 on a 12.04 kernel (3.2.0-36-generic) because of another nasty kernel bug on my dell mini 1012.

[Fedora (fedora-redhat-bugs)]

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

[Justin (justin-redhat-bugs)]

Is this still an issue with the 3.9 kernels in F19?

[Ralf (ralf-redhat-bugs)]

(In reply to comment #17)
> Is this still an issue with the 3.9 kernels in F19?

Yes, this bug is still present in both F18 (Real install on HD)
and F19 (LiveInstall on USB-stick).

With F19, there is one visible change. The "Test WP" message is gone.

The log messages now look like this:
[ 479.347586] sd 5:0:0:0: [sdb] Asking for cache data failed
[ 479.347992] sd 5:0:0:0: [sdb] Assuming drive cache: write through

[Ralf (ralf-redhat-bugs)]

Forgot to mention the kernel versions being involved:
F19: kernel-3.9.0-0.rc4.git0.1.fc19.i686
F18: kernel-PAE-3.8.5-201.fc18.i686

[Ganton (ganton)]

It's still happening in Kubuntu 13.04.

[Ganton (ganton)]

In my computer, using Kubuntu 13.04, the "ss_en" option of the ums_realtek driver didn't work for me, the messages were still filling the logs.

The solution proposed in comment #70 worked.

[Josh (josh-redhat-bugs)]

*********** MASS BUG UPDATE **************

We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.11.1-200.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

[Ralf (ralf-redhat-bugs)]

(In reply to Josh Boyer from comment #20)
> Fedora 19 has now been rebased to 3.11.1-200.fc19.
Bug as described in comment#0 is still present with 3.11.1-200.fc19.

[Justin (justin-redhat-bugs)]

*********** MASS BUG UPDATE **************

We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.12.6-200.fc19. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 20, and are still experiencing this issue, please change the version to Fedora 20.

If you experience different issues, please open a new bug report for those.

[Joe (joe-redhat-bugs)]

My laptop is running Fedora 20, and I just updated the kernel to 3.12.6-300.fc20.i686+PAE. Checking, /var/log/messages still contains a number of complaints about the cache data on [sdb] even though I only have one hard drive and there is no flash drive, CD/DVD or memory card inserted, although it doesn't prevent me from booting.

I may be simply blinder than normal, but I don't see where I can change the version from 19 to 20, so I'd appreciate it if somebody else does this for me.

[Ralf (ralf-redhat-bugs)]

(In reply to Joe Zeff from comment #23)
Bug is still present for me with both f19 and f20 (multiboot config).

[Justin (justin-redhat-bugs)]

*********** MASS BUG UPDATE **************

We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.

Fedora 20 has now been rebased to 3.13.4-200.fc20. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

[Ralf (ralf-redhat-bugs)]

(In reply to Justin M. Forbes from comment #25)
> *********** MASS BUG UPDATE **************

> Fedora 20 has now been rebased to 3.13.4-200.fc20. Please test this kernel
> update and let us know if you issue has been resolved or if it is still
> present with the newer kernel.

No improvement with kernel-PAE-3.13.3-201.fc20.i686. Same issue as in 2011.

[Juan Jose Amor Iglesias (jjamor)]

Me too #78. After using "ss_en" option, the messages changed to continuous "USB disconnected" and reconnected messages.

So, finally the only solution is to disable the module as #70 recommended and wait to a fixed driver.

[mikewhatever (mikewhatever)]

Bug confirmed in Trusty - current kernel 3.13.0-24-generic. The ss_en=0 option doesn't seem to work any more. Blacklisting the module is the only thing to do for now.

[Justin (justin-redhat-bugs)]

*********** MASS BUG UPDATE **************

We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.

Fedora 20 has now been rebased to 3.14.4-200.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

[Ralf (ralf-redhat-bugs)]

(In reply to Justin M. Forbes from comment #27)
> *********** MASS BUG UPDATE **************

> Fedora 20 has now been rebased to 3.14.4-200.fc20. Please test this kernel
> update (or newer) and let us know if you issue has been resolved or if it is
> still present with the newer kernel.

No improvement with kernel-PAE-3.14.4-200.fc20.i686. Same issue as in 2011.

[Ralf (ralf-redhat-bugs)]

Yeah! Petr, I own you a beer!

In my case, this definitely is Linux Kernel 43191.

Googling around for this bug has led me to find passing "ss_en=0" to
the ums_realtek kernel module
works-around (fixes ?) this issue.

E.g. Add a file
/etc/modprobe.d/ums-realtek.conf
with this contents:
options ums_realtek ss_en=0

[John S. Gruber (jsjgruber)]

ss_en=0 option still works for me with trusty. Kernel version is: 3.13.0-24-generic.

[WinEunuchs2Unix (ricklee518)]

Under Trusty 14.04 LTS 3.13.0-24-generic the ss_en=0 option did not work on first try. The file was created but it was empty. After using gksu gedit blah blah blah on the file and manually putting the option in it worked fine. Thank you very much at getting this annoying undocumented feature (old tongue for bug) out of the way every time I do a dmesg.

After a million lines of 1. Test failed, 2. Ask for cash (who wouldn't?) and 3. assume write (everyone assumes they are right) The ss_en=0 was manually added to the file and then the Remove / reinsert kernel module was executed. To prove it works dmesg output is below:

[ 3466.265066] sd 2:0:0:0: [sda] Test WP failed, assume Write Enabled
[ 3466.267309] sd 2:0:0:0: [sda] Asking for cache data failed
[ 3466.267317] sd 2:0:0:0: [sda] Assuming drive cache: write through
[ 3474.080808] usbcore: deregistering interface driver ums-realtek
[ 3639.916413] ums-realtek 1-4:1.0: USB Mass Storage device detected
[ 3639.917971] scsi6 : usb-storage 1-4:1.0
[ 3639.918200] usbcore: registered new interface driver ums-realtek
[ 3640.918321] scsi 6:0:0:0: Direct-Access Generic- Multi-Card 1.00 PQ: 0 ANSI: 0 CCS
[ 3640.918936] sd 6:0:0:0: Attached scsi generic sg1 type 0
[ 3640.929692] sd 6:0:0:0: [sda] Attached SCSI removable disk

Can we can close this bug if it moves upstream with ss_en=0 and the SD ram card reader still works as others state?

- WE2U (WinEunuuchs2Unix)

[WinEunuchs2Unix (ricklee518)]

Well it did work until I rebooted. The successful solution was to use "sudo gedit /etc/rc.local" and insert the following commnands before the last line which contains "exit 0":

rmmod ums_realtek
modprobe ums_realtek ss_en=0

Note "sudo" prefix isn't needed because rc.local runs with root privileges at startup.

[John (john-redhat-bugs)]

(In reply to Ralf Corsepius from comment #29)
> Yeah! Petr, I own you a beer!
>
> In my case, this definitely is Linux Kernel 43191.
>
> Googling around for this bug has led me to find passing "ss_en=0" to
> the ums_realtek kernel module
> works-around (fixes ?) this issue.
>
> E.g. Add a file
> /etc/modprobe.d/ums-realtek.conf
> with this contents:
> options ums_realtek ss_en=0

Ralph, thanks for the excellent comment. Any news on the success (or not) of using ss_en=0?

Anybody, if I see these messages and am without ss_en=0, does this just result in log noise or does it cause ill behavior besides?

I'm getting these messages, but on stateless deployments that boot from a SD card so I can't really test without a respin.

[Ralf (ralf-redhat-bugs)]

(In reply to John Florian from comment #30)

> Ralph, thanks for the excellent comment. Any news on the success (or not)
> of using ss_en=0?
AFAICT, in recent kernels (Don't know since when; I am on Fedora 20),
ss_en=0 is not required anymore.

> Anybody, if I see these messages and am without ss_en=0, does this just
> result in log noise or does it cause ill behavior besides?
The log noise isn't "that harmless". It had caused /var/log/messages rsp. journals to grow beyond reasons and caused different kinds of hick-ups on slow, small RAM systems (I am suspecting it to be co-responsible for hard machine lock ups, I once was facing with journalctl).

[John (john-redhat-bugs)]

(In reply to Ralf Corsepius from comment #31)
> (In reply to John Florian from comment #30)
>
> > Ralph, thanks for the excellent comment. Any news on the success (or not)
> > of using ss_en=0?
> AFAICT, in recent kernels (Don't know since when; I am on Fedora 20),
> ss_en=0 is not required anymore.

Good to know. I see the problem on my F18-based spins but not on the F20-based one nearing deployment. These two specific cases (18=bad/20=good) are both on Asus EeeBox B202 hardware, but there are many production variants of this "model" (grrrrr). Knowing you haven't seen on F20 is very helpful.

> > Anybody, if I see these messages and am without ss_en=0, does this just
> > result in log noise or does it cause ill behavior besides?
> The log noise isn't "that harmless". It had caused /var/log/messages rsp.
> journals to grow beyond reasons and caused different kinds of hick-ups on
> slow, small RAM systems (I am suspecting it to be co-responsible for hard
> machine lock ups, I once was facing with journalctl).

Hmmm... that worries me. My B202 deployments have been mostly good but more likely than other models to exhibit troublesome behavior. I should have systemd-journald conf'd where log growth isn't an issue, but ...

I actually might be able to aid my F18-based deployments after all, despite what logic and reason would have my presume. I was able to rmmod usb_realtek, make the config you offered and modprobe it back in. I had been seeing the noise about every 50s and it's now been quiet for 5m. How I was able to make the change, I don't understand. The config file only hit tmpfs (because of the statelessness), but the tools I needed to do so once rmmod'd would have had to come off SD ... or from caching of the Live squashfs.img.

[Justin (justin-redhat-bugs)]

*********** MASS BUG UPDATE **************

We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.

Fedora 20 has now been rebased to 3.17.2-200.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21.

If you experience different issues, please open a new bug report for those.

[Christian (christian-redhat-bugs)]

After "modprobe ums_realtek" (w/o any options) the following gets printed, but the repeating messages are gone with 3.17.2-200.fc20.i686:

 kernel: [162938.337569] ums-realtek 1-5:1.0: USB Mass Storage device detected
 kernel: [162938.347415] scsi host4: usb-storage 1-5:1.0
 kernel: [162938.352902] usbcore: registered new interface driver ums-realtek
 kernel: ums-realtek 1-5:1.0: USB Mass Storage device detected
 kernel: scsi host4: usb-storage 1-5:1.0
 kernel: usbcore: registered new interface driver ums-realtek
 kernel: [162939.357790] scsi 4:0:0:0: Direct-Access Generic- Multi-Card 1.00 PQ: 0 ANSI: 0 CCS
 kernel: scsi 4:0:0:0: Direct-Access Generic- Multi-Card 1.00 PQ: 0 ANSI: 0 CCS
 kernel: [162939.367789] sd 4:0:0:0: Attached scsi generic sg1 type 0
 kernel: [162939.377269] sd 4:0:0:0: [sdb] Attached SCSI removable disk
 kernel: sd 4:0:0:0: Attached scsi generic sg1 type 0
 kernel: sd 4:0:0:0: [sdb] Attached SCSI removable disk

[Peter Rosenberg (peter-rosenberg-dk)]

I have the same problem since I had my first Linux Mint 16 and now turned into Linux Mint 17 (Qiana - 32bit) the problem is still there (Ubuntu 14.04 i believe). Below, is my workaround which may benefit others too.

I have experimented a bit with the User Interface, more specifically the Control Center - Disks (menu in the Mate). There, is a Power Off menu choice of the Realtek Mass Storage device (ie. by pci builtin Card reader, usually empty).
And voila - the kernel messages stopped ! :-)
It would be nice if one could power down specific ones, by will.
I have found some solutions (not working for me) mostly like tweaking files in the Drivers settings (/sys/bus/usb/devices path).
These were more or less Linux version dependent, and did not work for me.

Instead, I carried on experimenting, and using the same Control Center - Disks I found a small button to edit Mount options which opened the dialog as I have attached a screenshot of.
If I in there specifically said 'Automatic Mount Options' to OFF, then I permanently seems to avoid the kernel messaged flooding the system log.
So I stay with this workaround, until further.

[Peter Rosenberg (peter-rosenberg-dk)]

My Comment #84 was a wee bit to quick - sorry. I had wrong (interpreted) timestamps in the kernel log, so I saw log records seemingly from yesterday, but they are from today !
So I had to continue experimenting, and this command (which you could run for every boot) should detach the device, hence power it off and you avoid the flooding of messages:
   udisks --detach /dev/sdb
where sdb is the device causing the messages:
    [Sat Nov 15 23:58:58 2014] sd 5:0:0:0: [sdb] Assuming drive cache: write through
    [Sat Nov 15 23:59:49 2014] sd 5:0:0:0: [sdb] Test WP failed, assume Write Enabled
    [Sat Nov 15 23:59:49 2014] sd 5:0:0:0: [sdb] Asking for cache data failed
If you are unsure of which devices you have 'available' there's several tools available, but these seems to be informative:
   udisks --enumerate-device-files
   udisks --show-info /dev/<your device, like sdb for me>
and also
   lsusb -v

[Fedora (fedora-redhat-bugs)]

*********** MASS BUG UPDATE **************

We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.

Fedora 20 has now been rebased to 3.18.7-100.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21.

If you experience different issues, please open a new bug report for those.

[Ralf (ralf-redhat-bugs)]

I think this bug is back in "new clothes":
...
Mar 22 19:42:14 gunvald1 systemd-udevd[488]: error: /dev/sdb: No medium found
Mar 22 19:42:14 gunvald1 systemd-udevd[488]: error: /dev/sdb: No medium found
Mar 22 19:42:14 gunvald1 systemd-udevd[488]: error: /dev/sdb: No medium found
Mar 22 19:41:23 gunvald1 systemd-udevd[488]: error: /dev/sdb: No medium found
Mar 22 19:41:23 gunvald1 systemd-udevd[488]: error: /dev/sdb: No medium found
Mar 22 19:41:23 gunvald1 systemd-udevd[488]: error: /dev/sdb: No medium found
...

Same HW as before, same symptoms, different error messages.

The internet is full of people complaining about it and of kernel-maintainers and systemd maintainer mutually denying responsibility.

[Fedora (fedora-redhat-bugs)]

*********** MASS BUG UPDATE **************

We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.

Fedora 20 has now been rebased to 3.19.5-100.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21.

If you experience different issues, please open a new bug report for those.

[Joe (joe-redhat-bugs)]

My laptop is no longer doing this. I do, however get several kerneloops at boot that can't be reported because the kernel is tainted. (Flags:GW) Checking, /proc/sys/kernel/tainted reports 0. I don't know what this means, except that the earlier bug is no longer active. I'm using F 20 right now, soon to upgrade to 21.

[Fedora (fedora-redhat-bugs)]

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 20 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

[Fedora (fedora-redhat-bugs)]

Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

[Christian (christian-redhat-bugs)]

As Ralf Corsepius already mentioned, this is still happening in Fedora 21, although with a new error message:

len# modprobe ums-realtek
Jul 29 11:06:01 len kernel: ums-realtek 1-5:1.0: USB Mass Storage device detected
Jul 29 11:06:01 len kernel: scsi host4: usb-storage 1-5:1.0
Jul 29 11:06:01 len kernel: usbcore: registered new interface driver ums-realtek
Jul 29 11:06:02 len kernel: scsi 4:0:0:0: Direct-Access Generic- Multi-Card 1.00 PQ: 0 ANSI: 0 CCS
Jul 29 11:06:02 len kernel: sd 4:0:0:0: [sdb] Attached SCSI removable disk
Jul 29 11:06:02 len kernel: sd 4:0:0:0: Attached scsi generic sg1 type 0
Jul 29 11:06:02 len systemd-udevd[251]: error: /dev/sdb: No medium found
Jul 29 11:06:03 len systemd-udevd[251]: error: /dev/sdb: No medium found

=== And then, every 50 seconds:

Jul 29 11:06:52 len systemd-udevd[251]: error: /dev/sdb: No medium found
Jul 29 11:06:53 len systemd-udevd[251]: error: /dev/sdb: No medium found
Jul 29 11:06:53 len systemd-udevd[251]: error: /dev/sdb: No medium found

Jul 29 11:07:44 len systemd-udevd[251]: error: /dev/sdb: No medium found
Jul 29 11:07:44 len systemd-udevd[251]: error: /dev/sdb: No medium found
Jul 29 11:07:44 len systemd-udevd[251]: error: /dev/sdb: No medium found

Unloading (and blacklisting) ums_realtek make the error go away.

[Ralf (ralf-redhat-bugs)]

Reopening.

It also happens with f22:
...
Jul 30 06:06:55 gunvald1 systemd-udevd[524]: error: /dev/sdb: No medium found
Jul 30 06:06:55 gunvald1 systemd-udevd[524]: error: /dev/sdb: No medium found
Jul 30 06:06:55 gunvald1 systemd-udevd[524]: error: /dev/sdb: No medium found
Jul 30 06:06:03 gunvald1 systemd-udevd[524]: error: /dev/sdb: No medium found
Jul 30 06:06:03 gunvald1 systemd-udevd[524]: error: /dev/sdb: No medium found
Jul 30 06:06:03 gunvald1 systemd-udevd[524]: error: /dev/sdb: No medium found
Jul 30 06:05:12 gunvald1 systemd-udevd[524]: error: /dev/sdb: No medium found
Jul 30 06:05:12 gunvald1 systemd-udevd[524]: error: /dev/sdb: No medium found

# uname -a
Linux gunvald1 4.1.2-200.fc22.i686+PAE #1 SMP Wed Jul 15 20:30:12 UTC 2015 i686 i686 i386 GNU/Linux

[Fedora (fedora-redhat-bugs)]

This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 21 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

[Fedora (fedora-redhat-bugs)]

Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

[Christian (christian-redhat-bugs)]

I can't reproduce this with F23 any more:

$ uname -r
4.2.6-300.fc23.i686+PAE

$ modprobe ums-realtek
$ dmesg
[...]
[919349.437171] ums-realtek 1-5:1.0: USB Mass Storage device detected
[919349.467214] scsi host6: usb-storage 1-5:1.0
[919349.469002] usbcore: registered new interface driver ums-realtek
[919350.470825] scsi 6:0:0:0: Direct-Access Generic- Multi-Card 1.00 PQ: 0 ANSI: 0 CCS
[919350.477418] sd 6:0:0:0: Attached scsi generic sg1 type 0
[919350.486544] sd 6:0:0:0: [sdb] Attached SCSI removable disk

=> No more (periodic) error messages, great!