ENE internal SD Card reader [PCI 1524:0751] doesn't work with Hardy (but work with Gutsy)

Bug #213439 reported by Viktor Hollmann
18
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Fedora)
Fix Released
Medium
linux (Ubuntu)
Won't Fix
Medium
Unassigned

Bug Description

Hardware: MSI PR200 aka MS-1221 aka System76 Daru2
Kernel: Ubuntu hardy (development branch) kernel 2.6.24-15-generic, 32-bit
Description: SD Reader doesn't recognize SD card inside. I have no other supported card (xD, Memory Stick)
Note: The Gutsy kernel (2.6.22-14-generic 32-bit) works with SD Card normally

lspci:
01:04.0 FLASH memory: ENE Technology Inc ENE PCI Memory Stick Card Reader Controller
        Subsystem: Micro-Star International Co., Ltd. Unknown device 2fb3
        Flags: bus master, medium devsel, latency 64, IRQ 5
        Memory at fddff000 (32-bit, non-prefetchable) [size=128]
        Capabilities: <access denied>

01:04.1 SD Host controller: ENE Technology Inc ENE PCI SmartMedia / xD Card Reader Controller (prog-if 01)
        Subsystem: Micro-Star International Co., Ltd. Unknown device 2fb3
        Flags: bus master, medium devsel, latency 64, IRQ 16
        Memory at fddff400 (32-bit, non-prefetchable) [size=256]
        Capabilities: <access denied>

01:04.2 FLASH memory: ENE Technology Inc Unknown device 0720
        Subsystem: Micro-Star International Co., Ltd. Unknown device 2fb3
        Flags: bus master, medium devsel, latency 64, IRQ 5
        Memory at fddff800 (32-bit, non-prefetchable) [size=128]
        Capabilities: <access denied>

01:04.3 FLASH memory: ENE Technology Inc ENE PCI Secure Digital / MMC Card Reader Controller
        Subsystem: Micro-Star International Co., Ltd. Unknown device 2fb3
        Flags: bus master, medium devsel, latency 64, IRQ 16
        Memory at fddffc00 (32-bit, non-prefetchable) [size=256]
        Capabilities: <access denied>

Revision history for this message
In , Jason (jason-redhat-bugs) wrote :

Description of problem:
I am running the Aug 28 rawhide. I boot fedora with a kanguru 2GB flash memory
drive in a usb port and try to mount it after login. The system says there is
no such mount point (/dev/sdc1). I check /dev and sure enough no sdc*. I pull
the drive, wait 10 seconds, plug it in and there it is. /dev/sdc becomes
available. So why can't I mount my thumb drive when the system boots?

Version-Release number of selected component (if applicable):
2.6.17-1.2586.fc6

How reproducible:
don't know. This is the only kernel available.

Steps to Reproduce:
1. plug in a usb flash memory drive
2. boot the system
3. login and try to mount it

Actual results:

Expected results:

Additional info:

Revision history for this message
In , Jason (jason-redhat-bugs) wrote :

Created attachment 135082
dmesg of boot with thumb drive plugged in

Revision history for this message
In , Jason (jason-redhat-bugs) wrote :

still happens on 2.6.17-1.2597.fc6

Revision history for this message
In , Jason (jason-redhat-bugs) wrote :

still no usb thumb drive in 2.6.17-1.2600.fc6

Revision history for this message
In , David (david-redhat-bugs) wrote :

Reassigning to correct owner, kernel-maint.

Revision history for this message
In , Jason (jason-redhat-bugs) wrote :

still no usb thumb drive in 2.6.18-1.2699.fc6

Revision history for this message
In , Dave (dave-redhat-bugs) wrote :

Pete, this looks fishy..

libusual: modprobe for usb-storage succeeded, but module is not present

any ideas ?

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

It is impossible to run modprobe normally in initrd, because the modprobe
is shortcut by nash. This probably happens because of SCSI root, which
makes mkinitrd to load libusual by mistake.

As a workaround, I suggest to unplug all USB storage, rmmod usb-storage,
rmmod libusual, then re-run this:
  mkinitrd /boot/initrd-2.6.17-1.2586.fc6.img 2.6.17-1.2586.fc6
This ought to create an initrd image without USB modules.

I have a system which boots off SATA, so I'll try to tinker with this,
see if I can reproduce it.

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

Also, please attach /etc/modprobe.conf. It can confuse mkinitrd.

Revision history for this message
In , Jason (jason-redhat-bugs) wrote :

Created attachment 137394
/etc/modprobe.conf

Revision history for this message
In , Jason (jason-redhat-bugs) wrote :

still no usb thumbdrive with kernel-2.6.18-1.2747.fc6.

Revision history for this message
In , Matthias (matthias-redhat-bugs) wrote :

I can confirm I see this to with the latest Rawhide on an x86_64 : If I boot
with my external 200GB USB hard drive powered on, it doesn't appear, nor does
the computer's internal USB card reader. If I power it off then back on, both
the external drive and the multiple card reader slots appear in nautilus'
"Computer" window.

Revision history for this message
In , I. (i.-redhat-bugs) wrote :

I use x86_64 on AMD64 and no usbpendrive on my gnome desktop, when sticked it in
usb port, but in nautilus i can see over ca. 0.5 sec icon of my beloved pendrive
.... and it dissapeard.

Revision history for this message
In , I. (i.-redhat-bugs) wrote :

Created attachment 138188
pendrive appera in nautilus less than 1 secs.

i use kernel: 2.6.18-1.2741 but prepare for 2.6.18-1.2747

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

I reproduced the problem locally and the following is happening:

- At kernel init time, static libusual is probed and it registers a driver
- When USB HCDs are loaded, khubd probes USB buses; this does kevent_add(ADD)
  and loops matching drivers, then calling driver's probe routines
- The libusual is probed and correctly refuses the probe, so the result is
  indistinguishable from not having a driver in the initrd
- When udev starts, it does not force any kind of re-probing of any buses.
  Instead, it fetches events which kevent_add posted, then runs
   modprobe usb:vXXXXpYYYY.....
  The alias resolves to libusual
- The modprobe fails to load anything, because libusual is static

So, I did not think this through well enough. I expected the replay to
load correct drivers, which it attempts to do, but fails.

I was wrong in the comment #7, the workaround is to include usb-storage
with the following
 cd /boot
 mv initrd-2.6.18-1.2693.fc6.img initrd-2.6.18-1.2693.fc6.img.save
 mkinitrd --with=usb-storage initrd-2.6.18-1.2693.fc6.img 2.6.18-1.2693.fc6
(with the appropriate kernel version used accordingly)

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

Created attachment 138493
Workaround for 50-udev.rules

This workaround does not require to rebuild initrd, so newly installed
kernels would work automatically too.

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

Created attachment 138555
Candidate patch #3 - Kernel-side fix with class

This patch uses the fact that udevtrigger in udev-095 scans classes and
posts add events. We create a dummy class, which uses the uevent as an
indication that normal userland is in force. When called, we retry
request_module.

Any and all problems can be fixed in kernel, the question is only if
it makes sense.

Revision history for this message
In , Matthias (matthias-redhat-bugs) wrote :

Adding usb-storage to the initrd seems like the wrong thing to do, since we are
not trying to boot off usb, right? As for the udev rule vs. the kernel patch...
well... you'll know best I hope :-)

Revision history for this message
In , Patrick (patrick-redhat-bugs) wrote :

That all makes sense, but it works fine for me on current FC5 with kernel
2.6.18-1.2200.fc5 (I have not had time to try FC6 anywhere).

I am not booting off a scsi disk, and root is on ext3 partition (no lvm/dm is used).

I like the udev rule.

Can't you always base whether or not ub or usb-storage is loaded on a user space
rule and/or config file (not sure what you do without udev in initrd for root fs
on USB), and get rid of the request_module and bias code in libusual? Or does
libusual then go away?

Revision history for this message
In , Patrick (patrick-redhat-bugs) wrote :

Created attachment 139553
output for boot with fc5 and usb storage being auto-loaded

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

Created attachment 139793
Candidate patch #4 - Same as above, slightly fixed

- Bit mask was incorrect for FL_FAILED
- Removed P3 printks

Revision history for this message
In , Harald (harald-redhat-bugs) wrote :

Does the fix from comment #15 work for all USB storage devices handled by libusual?

Revision history for this message
In , Vladimir (vladimir-redhat-bugs) wrote :

According to Comment #11 this bug looks really similar to bug 213156, can
someone take a look at it and confirm my suspicion ?

Revision history for this message
In , Vladimir (vladimir-redhat-bugs) wrote :

After recent package upgrade this problem seems to be fixed.

Revision history for this message
In , Piergiorgio (piergiorgio-redhat-bugs) wrote :

(In reply to comment #17)
> Adding usb-storage to the initrd seems like the wrong thing to do, since we are
> not trying to boot off usb, right? As for the udev rule vs. the kernel patch...
> well... you'll know best I hope :-)

I went into the same issue with a SCSI based PC, which has an cold plugged USB
storage device.
My solution was to add to /etc/modprobe.conf the line:

alias scsi_controller1 usb-storage

and the rebuild the initrd, without any special parameters.
Note that the first SCSI controller in /etc/modprobe.conf is the one
automatically defined during install time (I guess aha... something).

This solution was needed since the USB storage partitions must be available at
normal mount time, i.e. they are mounted from /etc/fstab and not from gnome-mount.

The question is: does the udev or kenel solution guarantee that usb-storage.ko
is loaded (and settles) in time for the the /etc/fstab mount?

Because an other (working) system, with different hardware, but same external
storage (and not /etc/modprobe.conf modifications), does not seem to have well
defined timings. It seems to me udev loads usb-storage.ko and this,
asynchronously, probes the USB subsystem and attaches the proper drives, i.e. it
will not necessarily finish before /etc/fstab is used to mount all the partitions.
I did not look deep into this (no time, sorry), so maybe my assumption (about
timinings) is wrong. If not, please consider this case before any patches,
updates or whatever are released.

Thanks.

Revision history for this message
In , Piergiorgio (piergiorgio-redhat-bugs) wrote :

Well, of course I meant:

alias scsi_hostadapter1 usb-storage

(and I also forgot to add myself to the CC list...)

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

[Adding Jon to cc: so he knows what's coming.]

Patrick is quite right in comment #18, a user-mode solution would be preferred.
But it's much more involved than anyone could imagine (well, anyone outside of
Jon Masters, Rusty, DaveJ, and other people who touched module-init-tools).

The key problem is, modprobe does not allow alias recursion. But when kernel
calls udev with usb:vXXXXpYYYY..., this goes through the alias path and uses
up the alias count. Therefore, if I write "alias libusual usb-storage" in
/etc/modprobe.conf, it does not work because one match has happened already.

I talked to Rusty about it two years ago, he was not completely averse to
adding recursive or iterative aliasing to modprobe. But adding it seemed
harder to me than throwing together libusual.

Since Greg K-H rejected my patch to add a class to libusual, I am going to
look at modprobe (and removing request_module from libusual completely).

Revision history for this message
In , Harald (harald-redhat-bugs) wrote :

+ACTION=="add", SUBSYSTEM=="usb",
ENV{MODALIAS}=="usb:v*p*d*dc*dsc*dp*ic08isc*ip*", RUN+="/sbin/modprobe usb-storage"

is as good as adding a modalias to usb-storage. So? Udev or module? In fact,
this would be the only module, where the modalias is hardcoded in udev instead
of the kernel module.

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

Harald, I only proposed this as a quick workaround for affected users,
for a couple of reasons.

#1 - It locks usb-storage, so you can't change it to ub. If we do that,
might as well disable ub altogether.

#2 - It is conceptually wrong, because it encodes the knowledge of
the alias resolution (e.g. now the 50.udev magically "knows" that
ic08 == usb-storage). This is something modules.alias has to specify,
and not any other files.

So, please don't add it to udev.

Revision history for this message
In , Jon (jon-redhat-bugs) wrote :

Thanks for the heads up. Let's get recursive alias support into
module-init-tools then. Yes, it'll be a pain in the <something> but you're not
likely to be the only person with this kind of problem :-)

So, Pete, you looking at the patch or do you want me to have a look over the
holidays once I'm done with my veggie turkey alternatives? :-)

Jon.

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

Jon, I created this situation in the first place, so I am going to write
the fix. And I'm sure you have things to do.

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

I was mistaken about modprobe and alias resolution. Changing that would not
fix the main problem, which is, in short, the entries in module.alias being
absent for USB storage devices.

I came to think that the only solution is to disable ub and libusual.

Revision history for this message
In , Harald (harald-redhat-bugs) wrote :

huh? disable?

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

That's right, no more ub. Harald, is it a problem for you?

Revision history for this message
In , Harald (harald-redhat-bugs) wrote :

No, as long as the appropriate modules get loaded by any mechanism, I have no
problem with that.

Revision history for this message
In , Michel (michel-redhat-bugs) wrote :

Has this fix been applied? I'm still experiencing the problem on the most recent
Rawhide kernels (everything since test1)

Revision history for this message
In , Michel (michel-redhat-bugs) wrote :

Relevant lines from dmesg; it seems that libusual is indeed trying to load
usb-storage, but could not find it (not in initrd?) -- right now I'm resorting
to manually loading usb-storage

usb 3-3.4: new high speed USB device using ehci_hcd and address 6
usb 3-3.4: configuration #1 chosen from 1 choice
libusual: modprobe for usb-storage succeeded, but module is not present
input: Western Digital External HDD as /class/input/input5
input: USB HID v1.11 Device [Western Digital External HDD] on usb-0000:00:13.2-3
.4

Revision history for this message
In , Harald (harald-redhat-bugs) wrote :

yes.. not in initrd

Revision history for this message
In , Stewart (stewart-redhat-bugs) wrote :

I can confirm this with the latest rawhide kernel to date.

Revision history for this message
In , David (david-redhat-bugs) wrote :

This bug needs to get fixed for Fedora 7. Who got the ball?

Revision history for this message
In , David (david-redhat-bugs) wrote :

*** Bug 238092 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Leslie (leslie-redhat-bugs) wrote :

Please read 239204

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

David, regarding the ball:

I understand that Dave Jones & Chuck Ebbert were reluctant to remove ub,
because in some cases it works (e.g. lots of dirty writeout and VM lockup).
In the same time, they did not want to carry the patch from comment #20
without an upstream committment. So they left this open in hopes that
I would cook up some compromise, but it's not happening.

I would be happy with either solution immediately, but going forward it's
probably better to drop ub and fix usb-storage problems as they come.

Revision history for this message
In , Dave (dave-redhat-bugs) wrote :

ok, I'll drop ub for f7.

Revision history for this message
In , Rahul (rahul-redhat-bugs) wrote :

Is this fixed in F7?

Revision history for this message
In , Jon (jon-redhat-bugs) wrote :

*** Bug 212886 has been marked as a duplicate of this bug. ***

Revision history for this message
Viktor Hollmann (vh-klikni) wrote :

lsipci was taken under 2.6.22-14-generic kernel.

Revision history for this message
Brian Murray (brian-murray) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage . I have classified this bug as a bug in linux the kernel for Hardy Heron.

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Hi Viktor,

Per the kernel team's bug policy, can you please attach the following information. Please be sure to attach each file as a separate attachment.

* cat /proc/version_signature > version.log
* dmesg > dmesg.log
* sudo lspci -vvnn > lspci-vvnn.log

For more information regarding the kernel team bug policy, please refer to https://wiki.ubuntu.com/KernelTeamBugPolicies . Thanks again and we appreciate your help and feedback.

Changed in linux:
status: New → Incomplete
Revision history for this message
Viktor Hollmann (vh-klikni) wrote :
Revision history for this message
Viktor Hollmann (vh-klikni) wrote :
Revision history for this message
Viktor Hollmann (vh-klikni) wrote :
Changed in linux:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → Medium
status: Incomplete → Triaged
Revision history for this message
In , Pete (pete-redhat-bugs) wrote :

Created attachment 314872
Patch #5

Set USU_MOD_FL_FAILED regardless of success of request_module.

Revision history for this message
Alan Jenkins (aj504) wrote :

This is a generic problem. The cardreader is on an internal USB bus, so it is present on boot. Ubuntu Hardy does not detect USB storage devices if they are present on boot.

Please fix it by building the kernel with CONFIG_LIBUSUAL=n. This is the solution adopted in Fedora Core 7.

Viktor, if you're not scared by building a new kernel then you can try this on your own.

Changed in linux:
status: Unknown → Fix Released
Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

Revision history for this message
Alan Jenkins (aj504) wrote :

I'm not happy downloading and installing a whole 'nother distribution. I am comfortable installing packages, kernels, and cleaning up if it goes wrong. But I have no idea where to download "linux-image-2.6.27-*". If you can clue me in then I will test the new kernel. Thanks!

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Hi Alan,

Thanks for the response. You'll have to enable the Intrepid archive/repository to get the 2.6.27 kernel. If you're not familiar with how to do that I'd almost recommend waiting for Alpha5 iso's to come out for you to burn and test via a LiveCD. Thanks.

Revision history for this message
Alan Jenkins (aj504) wrote :

That's what I'll do then. I can't justify it for this alone, but I've been looking forward to NetworkManager 0.7 so I guess I can test that and more. I have to wait for next month anyway (isp bandwidth cap).

Revision history for this message
jap1968 (jap1968) wrote :

I have an Asus Pundit (first generation, motherboard Asus P4S8L) loaded with Ubuntu 8.10 (2.6.27-7)

The machine has an ENE card reader. The card reader is only for SD cards. Everithing else works like a charm.

$ lspci | grep ENE
00:10.0 CardBus bridge: ENE Technology Inc CB-710/2/4 Cardbus Controller (rev 01)
00:10.1 FLASH memory: ENE Technology Inc CB710 Memory Card Reader Controller

I have tested with a couple of SD cards and nothing happens in Ubuntu. The card reader (and the SD cards) works properly under other OS.

Revision history for this message
Launchpad Janitor (janitor) wrote : Kernel team bugs

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

Revision history for this message
bart95130 (marc-lecrosnier) wrote :

Hi all,

I have the same problem running ubuntu jaunty, kernel 5 2.6.28-13-generic #44-Ubuntu SMP

lspci | grep ENE
02:04.0 CardBus bridge: ENE Technology Inc CB-710/2/4 Cardbus Controller
02:04.1 FLASH memory: ENE Technology Inc ENE PCI Memory Stick Card Reader Controller
02:04.2 SD Host controller: ENE Technology Inc ENE PCI Secure Digital Card Reader Controller
02:04.3 FLASH memory: ENE Technology Inc FLASH memory: ENE Technology Inc:

Nothing happen when I insert an SD Card.

Marc

Revision history for this message
Jeremy Foshee (jeremyfoshee) wrote :

This bug report was marked as Triaged a while ago but has not had any updated comments for quite some time. Please let us know if this issue remains in the current Ubuntu release, http://www.ubuntu.com/getubuntu/download . If the issue remains, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

tags: added: kj-triage
Changed in linux (Ubuntu):
status: Triaged → Incomplete
Revision history for this message
komputes (komputes) wrote :

This bug was incorrectly marked as a duplicate of Bug #633852. Although both card readers are from the same manufacturer (ENE), they have different ID and are on a different bus. Unlinking duplicate.

PCI 1524:0751 - Bug #213439
USB 0cf2:6250 - Bug #633852, Bug #542022, Bug #530277 (Master)

Changed in linux (Fedora):
importance: Unknown → Medium
Revision history for this message
Po-Hsu Lin (cypressyew) wrote :

Closing this bug with Won't fix as Hardy is no longer supported.
Please feel free to open a new bug report if you're still experiencing this on a newer release (Bionic 18.04.3 / Disco 19.04)
Thanks!

Changed in linux (Ubuntu):
status: Incomplete → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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