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

Bug #925760 reported by Julian Alarcon
274
This bug affects 62 people
Affects Status Importance Assigned to Milestone
Linux
In Progress
Medium
linux (Fedora)
Won't Fix
Undecided
linux (Ubuntu)
Triaged
Low
Unassigned

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 (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

Revision history for this message
In , Joe (joe-redhat-bugs) wrote :

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.

90 comments hidden view all 131 comments
Revision history for this message
Julian Alarcon (julian-alarcon) wrote :
Revision history for this message
Julian Alarcon (julian-alarcon) wrote :

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

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

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.

tags: added: needs-upstream-testing
Brad Figg (brad-figg)
Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
Brad Figg (brad-figg) wrote : Test with newer development kernel (3.2.0-13.22)

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.

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
tags: added: kernel-request-3.2.0-13.22
Brad Figg (brad-figg)
Changed in linux (Ubuntu):
importance: Undecided → Low
Revision history for this message
Neal McBurnett (nealmcb) wrote :

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

description: updated
tags: added: kernel-bug-exists-upstream
removed: needs-upstream-testing
tags: removed: kernel-request-3.2.0-13.22
Revision history for this message
Neal McBurnett (nealmcb) wrote :

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

My dmesg is attached.

Revision history for this message
Neal McBurnett (nealmcb) wrote :

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");

Revision history for this message
Neal McBurnett (nealmcb) wrote :

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.

Revision history for this message
Neal McBurnett (nealmcb) wrote :

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.

Revision history for this message
Neal McBurnett (nealmcb) wrote :

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

Revision history for this message
Julian Alarcon (julian-alarcon) wrote :

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

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Brad Figg (brad-figg) wrote : Test with newer development kernel (3.2.0-17.26)

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.

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
tags: added: kernel-request-3.2.0-17.26
Revision history for this message
Neal McBurnett (nealmcb) wrote :

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

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
tags: removed: kernel-request-3.2.0-17.26
Revision history for this message
Brad Figg (brad-figg) wrote :

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.

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
tags: added: kernel-request-3.2.0-17.26
Revision history for this message
Neal McBurnett (nealmcb) wrote :

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

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Julian Alarcon (julian-alarcon) wrote :

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

Revision history for this message
Brad Figg (brad-figg) wrote : Test with newer development kernel (3.2.0-17.27)

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.

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
tags: added: kernel-request-3.2.0-17.27
75 comments hidden view all 131 comments
Revision history for this message
In , Mark (mark-redhat-bugs) wrote :

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...

Revision history for this message
In , Pete (pete-redhat-bugs) wrote :

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.

75 comments hidden view all 131 comments
Revision history for this message
Julian Alarcon (julian-alarcon) wrote : AcpiTables.txt

apport information

tags: added: apport-collected
description: updated
Revision history for this message
Julian Alarcon (julian-alarcon) wrote : AlsaDevices.txt

apport information

Revision history for this message
Julian Alarcon (julian-alarcon) wrote : BootDmesg.txt

apport information

Revision history for this message
Julian Alarcon (julian-alarcon) wrote : CRDA.txt

apport information

Revision history for this message
Julian Alarcon (julian-alarcon) wrote : Card0.Amixer.values.txt

apport information

Revision history for this message
Julian Alarcon (julian-alarcon) wrote : Card0.Codecs.codec.0.txt

apport information

Revision history for this message
Julian Alarcon (julian-alarcon) wrote : Card0.Codecs.codec.1.txt

apport information

Revision history for this message
Julian Alarcon (julian-alarcon) wrote : CurrentDmesg.txt

apport information

Revision history for this message
Julian Alarcon (julian-alarcon) wrote : IwConfig.txt

apport information

Revision history for this message
Julian Alarcon (julian-alarcon) wrote : Lspci.txt

apport information

Revision history for this message
Julian Alarcon (julian-alarcon) wrote : Lsusb.txt

apport information

Revision history for this message
Julian Alarcon (julian-alarcon) wrote : PciMultimedia.txt

apport information

Revision history for this message
Julian Alarcon (julian-alarcon) wrote : ProcCpuinfo.txt

apport information

Revision history for this message
Julian Alarcon (julian-alarcon) wrote : ProcInterrupts.txt

apport information

Revision history for this message
Julian Alarcon (julian-alarcon) wrote : ProcModules.txt

apport information

Revision history for this message
Julian Alarcon (julian-alarcon) wrote : PulseSinks.txt

apport information

Revision history for this message
Julian Alarcon (julian-alarcon) wrote : PulseSources.txt

apport information

Revision history for this message
Julian Alarcon (julian-alarcon) wrote : RfKill.txt

apport information

Revision history for this message
Julian Alarcon (julian-alarcon) wrote : UdevDb.txt

apport information

Revision history for this message
Julian Alarcon (julian-alarcon) wrote : UdevLog.txt

apport information

Revision history for this message
Julian Alarcon (julian-alarcon) wrote : WifiSyslog.txt

apport information

description: updated
Revision history for this message
Julian Alarcon (julian-alarcon) wrote : AcpiTables.txt

apport information

Revision history for this message
Julian Alarcon (julian-alarcon) wrote : AlsaDevices.txt

apport information

Changed in linux (Ubuntu):
status: Incomplete → Triaged
54 comments hidden view all 131 comments
Revision history for this message
In , Samuel (samuel-redhat-bugs) wrote :

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.

Revision history for this message
In , Petr (petr-redhat-bugs) wrote :

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.

Revision history for this message
In , Petr (petr-redhat-bugs) wrote :

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.

Changed in linux:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
In , Christian (christian-redhat-bugs) wrote :

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

Revision history for this message
In , Joe (joe-redhat-bugs) wrote :

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.

Changed in linux:
status: Confirmed → In Progress
Revision history for this message
In , Antonio (antonio-redhat-bugs-1) wrote :

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.

Changed in linux (Ubuntu):
assignee: nobody → Feras Abdullah (pianoforte)
Changed in linux (Ubuntu):
assignee: Feras Abdullah (pianoforte) → nobody
Revision history for this message
In , Joe (joe-redhat-bugs) wrote :

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.

akamanax (edmon-xxl)
Changed in linux (Ubuntu):
assignee: nobody → akamanax (edmon-xxl)
assignee: akamanax (edmon-xxl) → nobody
Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

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

Revision history for this message
In , Justin (justin-redhat-bugs) wrote :

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

Revision history for this message
In , Ralf (ralf-redhat-bugs) wrote :

(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

Revision history for this message
In , Ralf (ralf-redhat-bugs) wrote :

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

Revision history for this message
In , Josh (josh-redhat-bugs) wrote :

*********** 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.

Revision history for this message
In , Ralf (ralf-redhat-bugs) wrote :

(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.

Revision history for this message
In , Justin (justin-redhat-bugs) wrote :

*********** 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.

Revision history for this message
In , Joe (joe-redhat-bugs) wrote :

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.

Revision history for this message
In , Ralf (ralf-redhat-bugs) wrote :

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

Revision history for this message
In , Justin (justin-redhat-bugs) wrote :

*********** 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.

Revision history for this message
In , Ralf (ralf-redhat-bugs) wrote :

(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.

Revision history for this message
In , Justin (justin-redhat-bugs) wrote :

*********** 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.

Revision history for this message
In , Ralf (ralf-redhat-bugs) wrote :

(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.

Revision history for this message
In , Ralf (ralf-redhat-bugs) wrote :

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

Revision history for this message
In , John (john-redhat-bugs) wrote :

(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.

Revision history for this message
In , Ralf (ralf-redhat-bugs) wrote :

(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).

Revision history for this message
In , John (john-redhat-bugs) wrote :

(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.

Revision history for this message
In , Justin (justin-redhat-bugs) wrote :

*********** 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.

Revision history for this message
In , Christian (christian-redhat-bugs) wrote :

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

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

*********** 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.

Revision history for this message
In , Ralf (ralf-redhat-bugs) wrote :

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.

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

*********** 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.

Revision history for this message
In , Joe (joe-redhat-bugs) wrote :

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.

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

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.

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

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.

Revision history for this message
In , Christian (christian-redhat-bugs) wrote :

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.

Revision history for this message
In , Ralf (ralf-redhat-bugs) wrote :

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

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

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.

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

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.

Revision history for this message
In , Christian (christian-redhat-bugs) wrote :

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!

Changed in linux (Fedora):
importance: Unknown → Undecided
status: Unknown → Won't Fix
Displaying first 40 and last 40 comments. View all 131 comments or add a comment.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.