tifm: Texas Instruments Card reader not reading SD cards

Some more output:

duncan@duncan-laptop:~$ lspci
...
0000:08:06.0 CardBus bridge: Texas Instruments: Unknown device 8039
0000:08:06.1 FireWire (IEEE 1394): Texas Instruments: Unknown device 803a <--- works
0000:08:06.2 Mass storage controller: Texas Instruments: Unknown device 803b
0000:08:06.3 0805: Texas Instruments: Unknown device 803c
...

duncan@duncan-laptop:~$ cat /sys/bus/pnp/devices/*/id
PNP0c02
PNP0200
INT0800
PNP0103
PNP0c01
PNP0c04
PNP0c02
PNP0303
SYN011e
SYN0100
SYN0002
PNP0f13
PNP0b00
duncan@duncan-laptop:~$

anything useful there?

according to http://www.webcon.ca/~imorgan/tifm21/ the driver for this device (sdhci) is merged into the kernel. Still I get nothing from 6.10 (knot 1) and I can't work out how to use the startup script refered to.

There's some more about the TI issues here: http://mmc.drzeus.cx/wiki/Controllers/TexasInstruments/FlashMedia

Among the comments is:

"The Texas Instruments specific interface is accessed through the PCI subdevice called "FlashMedia controller" (PCI id 104c:8033). Currently, there is no linux support for this interface, however some early driver/software work seems to have been done on TI's behalf by a consulting company called [WWW] Everest Inc"

Some comments about trouble with the controller
interface http://list.drzeus.cx/pipermail/sdhci-devel/2005-November/000036.html and a (messy) workaround

I tried it with a 'memory stick duo' manufactured by Magic gate and a normal SD card, don't remember the make

same status with kernel 2.6.17-10

I have the same reader pci id 104c:8039 to 803d
I can read and mount SD cards but I think the integrated smartcard reader uses the same chip but nothing happens.

I have a HP nx9420 and is running edgy

02:06.0 CardBus bridge: Texas Instruments Unknown device 8039
02:06.1 FireWire (IEEE 1394): Texas Instruments Unknown device 803a
02:06.2 Mass storage controller: Texas Instruments Unknown device 803b
02:06.3 Class 0805: Texas Instruments Unknown device 803c
02:06.4 Communication controller: Texas Instruments Unknown device 803d

I was emailed a fix by Mackenzie Morgan which worked for my SD card, I haven't tried any other cards yet.

Open the terminal and type in

lspci -vvvv | grep CardBus

Mine is 8039 and this fix is also reported to work for 803b.

Now in the terminal type the following three lines to force start these kernel modules:
sudo modprobe tifm_7xx1
sudo modprobe tifm_core
sudo modprobe tifm_sd

See if the card reader works now. To make these modules always start at boot add the three module names to your /etc/modules file (edit as root)

Works for me!

I just want to add that I also run into this bug. Combined with Bug#77510 Ubuntu failed miserably at my first attempt to migrate someone to free software. ("Ubuntu works out of the box, yeah!" and then it was fighting with Linux the whole day...)

On my HP NC4200, I only need to modprobe tifm_sd to get a working SD/MMC reader. Also, adding it to the /etc/modules means that I don't need to do it every time.

Could somebody point to documentation about how to get this to be detected properly so I could perhaps submit a patch?

tarek : )

Upon looking at the duplicates, a patch is found in this bug report:

https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/69123

and can be found here:

http://librarian.launchpad.net/4940121/tifm_7xx1.modprobe

One note is that the above fix breaks suspend for me. The following has to be added to /etc/default/acpi-support to make it sleep and wake up appropriately. Unfortunately, it still doesn't safely unmount on sleep.

Make sure this line is in /etc/default/acpi-support:

MODULES="tifm_sd sdhci mmc_core"

tarek : )

This has been handled in the latest udev upload - it's not quite perfect, but it'll do for feisty

Regression: as of this morning's updates (2.6.20-13-generic kernel, udev 103-0ubuntu14), my TI SD card reader has stopped working again.

It was working fine before the updates. After rebooting, I lost my card reader. I have tifm_sd in /etc/modules

I confirm that it doesn't work with the update. But for me, it didn't work even before this update.

Confirming that it doesn't work with 2.6.20-13 but did work for me with 2.6.20-12. Reopening the bug.

dmesg for regression:
...
[ 496.932000] mmcblk0: error 1 sending read/write command
[ 496.932000] end_request: I/O error, dev mmcblk0, sector 1999871
[ 496.932000] mmcblk0: error 1 sending read/write command
[ 496.932000] end_request: I/O error, dev mmcblk0, sector 245
...

The udev part (that the module is loaded at all) has been fixed - what remains seems to be a driver/hardware issue

For the record, this bug affects my Averatec 2370 Laptop, which worked fine under Edgy and is still a problem as of Mar 31.

Why is this bug "Medium?" I hope it doesn't mean you guys would actually ship Feisty with it still in place?

I'm also getting this problem on a HP NX9420 laptop. Works fine in 2.6.20.12 but if I boot with 2.6.20-13 I get error messages similar to Pavel Rojtberg and the system becomes unusable due to the constant logging of those messages.

I too started having this problem with the Feisty beta.

I'd love to help diagnose/debug on IRC if it will help the devs out. I'm newz2000. I can confirm that this was working in Edgy (but not in Dapper).

when inserting a card, dmesg says:
[ 282.148000] tifm_7xx1: sd card detected in socket 1
[ 282.308000] mmcblk0: mmc1:6cbc S016B 14560KiB
[ 282.308000] mmcblk0: p1

You'd think that means its working.

uname -a
Linux matts-laptop 2.6.20-13-generic #2 SMP Sun Mar 25 00:21:25 UTC 2007 i686 GNU/Linux

lspci -vv
07:06.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD)
        Subsystem: Toshiba America Info Systems Unknown device ff10
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 128 (1750ns min, 1000ns max), Cache Line Size: 16 bytes
        Interrupt: pin A routed to IRQ 18
        Region 0: Memory at dc004000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME+

07:06.3 Generic system peripheral [0805]: Texas Instruments PCIxx12 SDA Standard Compliant SD Host Controller (prog-if 01)
        Subsystem: Toshiba America Info Systems Unknown device ff10
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 128 (1750ns min, 1000ns max), Cache Line Size: 16 bytes
        Interrupt: pin A routed to IRQ 18
        Region 0: Memory at dc005800 (32-bit, non-prefetchable) [size=256]
        Capabilities: [80] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

I have always this message in boot :
PCI: Failed to allocate mem resource #0:xxxxxx at xxxxxx for 0000:04:00.2

This is the number of texas chipset... A reason of detection failure for texas card controller ? I have a HP pavillon zv5000
The last version of feisty failed to detect SD card.

Just confirmed, this is still a problem in -14.

Having the same problem. This worked in edgy after applying the setpci hack, In feisty 2.6.20-13 and 14 I get the constant error logs:

[ 711.608000] mmcblk0: error 1 sending read/write command
[ 711.608000] end_request: I/O error, dev mmcblk0, sector 103
[ 711.608000] mmcblk0: error 1 sending read/write command
[ 711.608000] end_request: I/O error, dev mmcblk0, sector 104
and so on.

lspci:
02:06.0 CardBus bridge: Texas Instruments PCIxx21/x515 Cardbus Controller
02:06.2 FireWire (IEEE 1394): Texas Instruments OHCI Compliant IEEE 1394 Host Controller
02:06.3 Mass storage controller: Texas Instruments PCIxx21 Integrated FlashMedia Controller
02:06.4 Generic system peripheral [0805]: Texas Instruments PCI6411/6421/6611/6621/7411/7421/7611/7621 Secure Digital Controller
02:06.5 Communication controller: Texas Instruments PCI6411/6421/6611/6621/7411/7421/7611/7621 Smart Card Controller

lspci -n:
02:06.0 0607: 104c:8031
02:06.2 0c00: 104c:8032
02:06.3 0180: 104c:8033
02:06.4 0805: 104c:8034
02:06.5 0780: 104c:8035

I am using an HP Compaq nw8240. This is only an SD card and smart card reader, not a 5 in 1.

under feisty 7.04beta works with kernel 2.6.20-12:
dmesg:
[ 122.704000] tifm_core: MMC/SD card detected in socket 0:3
[ 123.372000] mmcblk0: mmc3:9bd7 SD256 249088KiB
[ 123.372000] mmcblk0: p1

but kernel 2.6.20-13 or -14 don't work:
dmesg:
[ 126.720000] tifm_7xx1: sd card detected in socket 3
[ 127.204000] mmcblk0: mmc3:9bd7 SD256 249088KiB
[ 127.204000] mmcblk0: p1
[ 128.212000] tifm_sd: card failed to respond for a long period of time<6>tifm_7xx1: demand removing card from socket 3
[ 128.212000] mmcblk0: error 1 sending read/write command
[ 128.212000] end_request: I/O error, dev mmcblk0, sector 498112
[ 128.212000] Buffer I/O error on device mmcblk0, logical block 62264
above line *100

I'm using Feisty 7.04 Beta on Compaq NX 6120 Note Book, the card reader wouldn't work... When I was using Ubuntu 6.10, I found a fix in the Ubuntu Forums that would make it work, but even that fix wouldn't work in Feisty 7.04 Beta...

uname -a
Linux matrix 2.6.20-14-generic #2 SMP Mon Apr 2 20:37:49 UTC 2007 i686 GNU/Linux

sorry I forgot to mention the link of the Ubuntu Form article I was referring to, it's...

http://ubuntuforums.org/showthread.php?t=315497

Given the number of duplicates, the number of hardware that seems affected and the fact that this bugs is a regression, I would suggest to rise the priority/importance. IMHO, this bug should be fixed in Feisty. (I personnaly don't care as I don't use it but other people do)

So it seems like whatever fixed the initial broken cardreaders (tifm
version 0.8) also broke some other models of TI FlashMedia?

no, some change from 2.6.20-12 to 2.6.20-12 broke everything, so now basically no tifm cardreader works.

*to 2.6.20-13

isn't this bug related to #77894 ?
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/77894/

Only if it's a udev problem (guessing because when udev has a problem, it seems like it pops up in lots of places)...they're different card readers and different kernel modules and everything, so they don't seem like they'd be related

appears to be a lot of rumours ans multiple bug reports here but this looks like the one for not auto mounting I'm not sure it is a tifm module issue as HAL responds correctly on card insertion see below

I have rebuilt the tifm modules from

http://openfacts.berlios.de/index-en...12/xx21_driver

to replace the hopelessly buggy stock 2.6.20 kernel

All is good and installing the card gives

[ 714.680000] tifm_core: MMC/SD card detected in socket 0:3
[ 714.972000] mmcblk0: mmc3:0001 SDMMC 508800KiB
[ 714.972000] mmcblk0: p1

fdisk -l

Disk /dev/sda: 60.0 GB, 60011642880 bytes
240 heads, 63 sectors/track, 7752 cylinders
Units = cylinders of 15120 * 512 = 7741440 bytes

Device Boot Start End Blocks Id System
/dev/sda1 1 250 1889968+ 82 Linux swap / Solaris
/dev/sda2 251 7752 56715120 83 Linux

Disk /dev/mmcblk0: 521 MB, 521011200 bytes
9 heads, 24 sectors/track, 4711 cylinders
Units = cylinders of 216 * 512 = 110592 bytes

Device Boot Start End Blocks Id System
/dev/mmcblk0p1 2 4712 508685+ 6 FAT16

so all is good manual mounting the card works a treat to but feisty will not automount on insertion
this is a retrograde for edgy as with the .6 drivers it worked.

I suspect this is a mmc problem as

lshal -m gives

Start monitoring devicelist:
-------------------------------------------------
pci_104c_8033_mmc_host added

on card insertion so why doesn't fiesty react to the hal event ??

The link you've posted is broken.

Sorry

"http://openfacts.berlios.de/index-en.phtml?title=TI_FlashMedia_xx12/xx21_driver"

Interesting thing here:
I've compiled above module in the working kernel: 2.6.20-12, and it just compile well.
(tifm module version 0.8)
On kernel 2.6.20-14 that doesn't works:
root@leon:/home/laurent# make clean
rm -rf *.o *.o.d *.ko.d .depend .*.cmd *.ko *.mod.c .tmp_versions
root@leon:/home/laurent# make
echo /home/laurent
/home/laurent
make -C /lib/modules/2.6.20-14-generic/build M=/home/laurent
make[1]: entrant dans le répertoire « /usr/src/linux-headers-2.6.20-14-generic »
  LD /home/laurent/built-in.o
  CC [M] /home/laurent/tifm_core.o
  CC [M] /home/laurent/tifm_7xx1.o
  CC [M] /home/laurent/tifm_sd.o
/home/laurent/tifm_sd.c:16:32: erreur: linux/mmc/protocol.h : Aucun fichier ou répertoire de ce type
/home/laurent/tifm_sd.c: In function ‘tifm_sd_probe’:
/home/laurent/tifm_sd.c:987: erreur: ‘struct mmc_host’ has no member named ‘max_sectors’
make[2]: *** [/home/laurent/tifm_sd.o] Erreur 1
make[1]: *** [_module_/home/laurent] Erreur 2
make[1]: quittant le répertoire « /usr/src/linux-headers-2.6.20-14-generic »
make: *** [all] Erreur 2

It seems that kernel-2.6.20-14 is missing linux/mmc/protocol.h ??

Could it be a related to why the module don't works well on -13 and -14??

Have you also seen that? on the module website:
Version 0.6 of the driver is included with stock 2.6.19 release of the linux kernel. Version 0.8 should compile on 2.6.20 kernels and can be used as a replacement for the shipped

_(and quite unfortunately, buggy) one. _

It's in progress of merging into the main kernel tree.

Ok for completeness I removed the tifm modules and switched over to the sdhci module with

setpci -s 02:06.3 4c.b=0x02 (only for my laptop check lspci for yours)

inserting card gives

[ 8354.956000] mmcblk0: mmc2:0001 SDMMC 508800KiB
[ 8354.956000] mmcblk0: p1

fdisk -l

Disk /dev/sda: 60.0 GB, 60011642880 bytes
240 heads, 63 sectors/track, 7752 cylinders
Units = cylinders of 15120 * 512 = 7741440 bytes

   Device Boot Start End Blocks Id System
/dev/sda1 1 250 1889968+ 82 Linux swap / Solaris
/dev/sda2 251 7752 56715120 83 Linux

Disk /dev/mmcblk0: 521 MB, 521011200 bytes
9 heads, 24 sectors/track, 4711 cylinders
Units = cylinders of 216 * 512 = 110592 bytes

        Device Boot Start End Blocks Id System
/dev/mmcblk0p1 2 4712 508685+ 6 FAT16

But Hal does not recognize card insertion at all ????

But Manual mounting works fine.

Conclusion Both the sdhci AND tifm modules work BUT

1 with tifm modules hal events function but no auto mount, manual mount works
2 with sdhci modules hal doesn't function, manual mount still works

Hopefully this will clear up the confusion with the two different drivers and these bugs can be traced prior to feisty

so I think there are 2 bugs but need someone smarter than me to say which package they are in.

To compile you will have to get protocol.h from the main kernel.org as Feisty sources seem to have files missing!!!!!!

I'm not ok with what you says andrew.
My hald is working but not my tifm module.
Let's resume here my (and I think other problems):
-Not changing hald but simply switching from one kernel to one other: let's say 2.6.20-12 to 1.6.20-13or-14 make the sdcard insertion work or not.
-I can't mount even manually my sdcard on kernel -13 or -14.
-On -12 automount just works but that's because module is working there...
My main problem is that on kernel -13 or -14, the tifm module is bugguy and i've got this message:
[ 128.212000] tifm_sd: card failed to respond for a long period of time<6>tifm_7xx1: demand removing card from socket 3
[ 128.212000] mmcblk0: error 1 sending read/write command
[ 128.212000] end_request: I/O error, dev mmcblk0, sector 498112
[ 128.212000] Buffer I/O error on device mmcblk0, logical block 62264:
-I ahven't got this message with kernel 2.6.20-12.

More:
- tifm module compile on 2.6.20-12 kernel not on 2.6.20-14:
so:
I suspect a patch jas not been applied on -14 kernel...
This is not normal that -14 feisty kernel hasn't got these files!

Any kernel ubunutu feisty kernel maintainer there to help debug this?

Andrew do you the timeout and same I/O error problem on your dmesg(on card insertion)? perhaps you've got another bug different from mine?

Thanks Andrew, "setpci -s 02:06.3 4c.b=0x02" would get the mmc detected but not auto mount it for some reason; manual mounting works.

The timeouts are a symptom of the stock module in 2.6.20

you need to recompile from the website i gave you.

todo that you need protocol.h this is missing from fiesty therefore if you download the sources from kernel.org then just copy protocol.h to linux/mmc/protocol.h then the tifm module will compile and work.

if you dont want todo this then switch over to the sdhci module using the setpci command (check the forum for description on how)

Sorry cant be more helpfull but this is a bug report not help forum.

linux/mmc/protocol.h does not appear to be the only thing that is needed. The struct mmc_host structure is missing the max_sectors member in the linux/mmc/host.h file and the version of the module that comes with feisty 2.6.20-14 is 0.7. The newest version is the one to which Andrew is referring and that is version 0.8. It appears that the linux/mmc/host.h file may need to be updated but that may affect other mmc-related modules in the kernel.

The linux/mmc/host.h file from the kernel also #includes linux/mmc/mmc.h which causes additional compilation problems. Replacing that with linux/mmc/core.h got the module to compile and then it works. Maybe the solution going forward is to update the 2.6.20 sources to use 2.6.20.6 instead of 2.6.20.4 and include version 0.8 of the tifm driver?

Thats weird heres my compilation from kernel headers 2.6.20-14 generic

/home/andy/Downloads/tifm-0.8d
make -C /lib/modules/2.6.20-14-generic/build M=/home/andy/Downloads/tifm-0.8d
make[1]: Entering directory `/usr/src/linux-headers-2.6.20-14-generic'
  LD /home/andy/Downloads/tifm-0.8d/built-in.o
  CC [M] /home/andy/Downloads/tifm-0.8d/tifm_core.o
  CC [M] /home/andy/Downloads/tifm-0.8d/tifm_7xx1.o
  CC [M] /home/andy/Downloads/tifm-0.8d/tifm_sd.o
  Building modules, stage 2.
  MODPOST 3 modules
  CC /home/andy/Downloads/tifm-0.8d/tifm_7xx1.mod.o
  LD [M] /home/andy/Downloads/tifm-0.8d/tifm_7xx1.ko
  CC /home/andy/Downloads/tifm-0.8d/tifm_core.mod.o
  LD [M] /home/andy/Downloads/tifm-0.8d/tifm_core.ko
  CC /home/andy/Downloads/tifm-0.8d/tifm_sd.mod.o
  LD [M] /home/andy/Downloads/tifm-0.8d/tifm_sd.ko
make[1]: Leaving directory `/usr/src/linux-headers-2.6.20-14-generic'
root@sidney:/home/andy/Downloads/tifm-0.8d#

All files except protocol.h are original and dated mar 20th 18:41 so don't know why mine compiles cleanly
maybe I have later source than you??
Or maybe i copied /mmc from the original source for 2.6.14.4 but dont remember doing that.

Still doesn't auto mount though ;-)

Your suggestion seems a sensible approach then feisty just needs the auto mount working for tifm which as hal is picking up the event guess is just a gnome vfs or hal config file fix.

Finally got it compiling and i also confirm that it also works for me with no automount :)

Ah found what I did to get it to compile besides the protocol.h

rem'd out the max sector function in tifm_sd.c

// mmc->max_blk_count = 2048;
// mmc->max_hw_segs = mmc->max_blk_count;
        mmc->max_hw_segs = 16;
// mmc->max_blk_size = min(2048, PAGE_SIZE);
// mmc->max_seg_size = mmc->max_blk_count * mmc->max_blk_size;
        mmc->max_seg_size = 127 * 2048;

        mmc->max_phys_segs = mmc->max_hw_segs;
// mmc->max_sectors = 127 * mmc->max_phys_segs;

// mmc->max_req_size = mmc->max_seg_size;

guess that was cheating ;-)

Other people already asked this. Please raise the priority of this bug and make it necessary to fix it before feisty. I think it will be very bad publicity to get out with such a regression in stable, lots of people (think of all those new cheap vaio around) have tifm readers.

I disagree. My cardreader did not work before -12, and worked at -13
and continues to work.

On 4/8/07, Pavel Rojtberg <email address hidden> wrote:
> no, some change from 2.6.20-12 to 2.6.20-12 broke everything, so now
> basically no tifm cardreader works.
>
> --
> tifm: Texas Instruments Card reader not working
> https://bugs.launchpad.net/bugs/53923
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Please don't confirm bugs for the kernel until you read the bug policies. Confirmed bugs should be assigned to the kernel team (else they get ignored by accident).

Ok heres where I think we are and where the bugs exist (yes there are multitude)

1 No Protocol.h and sources too old (2.6.20.6 required) in kernel headers stopping compilation of working tifm (.8) ----Ubuntu Kernel
2 existing tifm module in 2.6.20 are Buggy/nonworking (confirmed by TIFM developer) ------------- kernel.org --kernel
3 sdhci Unable to generate an HAL event so wont auto mount -------------- Udev
4 tifm (.8) Generates Hal event but no auto mount action ------------hal

I would be surprised is this get fixed prior to feisty, as I sure at present the ubuntu packagers are very busy with release stuff.
even though the information in this thread is ample to fix most/all problems.

And Ben who were you aiming your broadside at or was it just a general RANT and what does 'else they get ignored by accident' do you mean if a user reports a bug however important and doesn't do it correctly you will 'accidentally' ignore it? .

OK as it seems to be DIY around here 12 bugs reported on this 6 months no action.

It appears hal doesn't like the fact the card reader reports a non removable device so ignores.

I've created a udev rule that force mounts the MMC devices, works to will be mounted in /media/mmcblk0....

unfortunately I'm crap at permissions tried
#mmc
KERNEL=="mmcblk[0-9]*", GROUP="plugdev", MODE=0666

in 40-permissions-rules but doesn't work folder is still owned by root

So If someone more oh fay with ubuntu could sort that bit out we'd have a auto mounting system not bad for 2 days messing about especially as the first bug report on this is from October Last year.

If you want to play the mmc rule is attached just drop it in /etc/udev/rules.d permission it correctly root/root

and your TIFM card will mount on insertion , you wont be able to access it as a standard user though as its permissioned for root

Ben > what do you mean ? Which bug policy are you talking about ?

BenC was just pointing out the way kernel bug triaging works. Bugs start out as unconfirmed and unassigned, and that's what we look for when evaluating bugs for work etc. If they're confirmed and not assigned to the kernel team they won't appear in many searches, and will also be assumed to have been already triaged and evaluated by a member of the kernel team, and hence potentially overlooked.

No bugs are ignored accidentally or otherwise, bugs may appear to be ignored, but that's normally because there's not enough information to deal with them, no available fixes, or higher priority bugs. We value input and suggestions from community members.

Add to that I'm an idiot

The udev permissions are fine on the device nodes created (i think)

My brute force method uses pmount as the root user so of cause the file is created as root.

have to rethink this.

not as clever as I thought.

don't think bitching between devs and users will get this fixed so let me be the first to apologize for any abrasive literacy I've been involved in .

Phillip > thanks for the clarification. If I confirm a bug related to the Kernel, I will then assign it to the kernel team. :-)

I wasn't ranting. The incoming bug level has required us to implement and enforce some policies with kernel bugs so that it is easier for us to triage and fix them. Those policies can be found here:

https://wiki.ubuntu.com/KernelTeamBugPolicies

Since these policies are new, I make it a point to note them whenever I fix a conflict with them. That way people get educated at the same time (and I avoid make the same fixes over and over).

In general, only the person triaging the bug should mark it confirmed. We have too many bugs getting marked confirmed by people experiencing the bug, when the bug report is in no way confirmed. Confirmed for us means that the bug reports contains all the needed info in order for us to work on it sensibly.

Also, when a bug on t he kernel is marked confirmed, it should have a severity set, and assigned to ubuntu-kernel-team. This way it shows up in our list of "bugs that can be worked on" as opposed to "bugs that still need info". We need this separation in order to make sense of the hundreds of reports we have.

Thanks for the report, and the help in triaging it. Hopefully we can get it resolved.

to make it owned by you:
sudo chown username:username filename

so if the thing that force mounts it is named mmcforce, and my username is maco:
sudo chown maco:maco mmcforce

OK my quick and dirty fix just got a lot dirtier but is now working

create an executable file with the following in
-------------------------------------------------------------------------------------------------
#!/bin/sh

# Work-around for mmc card reader udev thinks none removable breaking hal

sudo -u andy pmount /dev/mmcblk0p1
-------------------------------------------------------------------------------------------------

place somewhere sensible (I used /usr/local/bin/sdmount)

Replace andy with your user name.

edit 10-mmc.rule to call this (sdmount) instead of pmount and off you go inserting card will result in disk device appearing on desktop.

WARNING I don't advise doing this unless you are confident messing with system files as 1 slip could break your OS bad.

Also bear in mind when this is fixed your alterations may cause the fix to fail.

PS you have been warned

Thanks for you script! It worked for me.

My laptop is a HP pavilion ZT3115E from 2003 with a SD-Reader integrated. In Edgy it works perfectly (adding mmcblock module): when I inserted a SD, KDE autorun menu pop-up and so on.
With Feisty (I'm with Feisty since Herd1 more or less) with some kernels it worked ok but recently I only can read from SD. Now, with more recently kernels no KDE pop-up menu, no reading is posible and, obviously, no writing is posible.
dmesg shows that module is correctly loaded when I insert a SD:
[ 685.108000] mmcblk0: mmc0:d991 SD01G 1006080KiB
[ 685.108000] mmcblk0: p1
But nothing more happens.
I don't have any 10-mmc.rule in my /etc/udev.d/rules directory so I don't know how create it (what type in) but if I execute your 'sdmount' manually I can access to SD content in /media/mmcblk0p1 so I can read SD cards. I hope this problem will be fix before Feisty release because it's an annoying bug.

Thanks

The 10-mmc.rule is attached in this bug report see left hand column

"udev rule to manualy mount mmcblk devices"

Its not in feisty its a filthy hack I knocked up for my own use , Just change the pmount part to call sdmount

@andrew> Isn't it now (with the mount problem) the same bug as Bug #91429? perhaps we should mark #91429 as duplicate?

On my Feisty system just updated from the main server this bug is still present. I will try some of the workarounds when I get a chance. Pereira, please reconsider the 'Fix Released' status of this bug.

Duncan, it broke twice in Feisty. It broke from udev at first, and that was fixed on 2.6.20-12. Then the kernel broke it, so now that one is just "confirmed".

latest kernel with mmc fix 2.6.20.14.23

fixes the mount issue though you still need to rem out max sectors (see above),copy protocol.ini and roll your own tifm modules.

Don't forget to remove my hack 10-mmc.rules

really cool to get the SD icon back on desktop

thanks devs first part of puzzle complete

The latest updates seem to have resolved it for me. As of Apr 13 '07, 1 AM Pacific Time, with all updates applied I can insert an SD card, the icon appears on the desktop, and I can read the files and unmount just as before. Many thanks to the Ubuntu team for getting this fixed BEFORE "officially" shipping Feisty.

I am fully updated also, and have only waited for updates to fix this, not do anything myself and my SD card does not get mounted.

hi, this solution may work =) (only italian sorry =( )
http://graymalkin.wordpress.com/2007/04/13/tifm-texas-instruments-card-reader-pcixx21x515-not-working/

read also this comment https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/53923/comments/48

Just like cbudden for me : with all upgraded and rebooted, nothing has changed.

/home/duncan/Desktop/lspci_-vv.txt

/var/log/messages

Bug still present :(

Linux vayralemine 2.6.20-15-generic #2 SMP Fri Apr 13 16:33:26 UTC 2007 i686 GNU/Linux

OK guys lets be clear

If you have a TIFM reader that doesn't work with .7 tifm modules( standard 2.6.20) then unless you have

A. compiled .8 following the instructions above
or
B. Switched over to the SDHCI module using the setpci command see above.

Then as you don't have a working driver for your card the fact that auto mount is now fixed is of no use to you as you have nothing to mount.

A quick check is run dmesg from a command prompt and see if your getting io errors when card inserted if you are you need to do a or b above.

What would be nice is anyone using the setpci have to report if auto mount is now working, it should be as the fix was in the mmc core stuff.

as far as I can see the only bug outstanding is that the stock tifm modules are broken and should be replaced with the tifm developer fixed version, Whether this should be done by the feisty developers I'm not sure as really its an upstream bug (fixed in 2.6.21).

Maybe they'll take pity on you and do it .

It seems rude, let's me be clear to you andrew. my sd card is working with
windows and with my camera, so what's the problem with you?

2007/4/14, Andrew Waldram <email address hidden>:
>
> OK guys lets be clear
>
> If you have a TIFM reader that doesn't work with .7 tifm modules(
> standard 2.6.20) then unless you have
>
> A. compiled .8 following the instructions above
> or
> B. Switched over to the SDHCI module using the setpci command see above.
>
> Then as you don't have a working driver for your card the fact that auto
> mount is now fixed is of no use to you as you have nothing to mount.
>
> A quick check is run dmesg from a command prompt and see if your getting
> io errors when card inserted if you are you need to do a or b above.
>
> What would be nice is anyone using the setpci have to report if auto
> mount is now working, it should be as the fix was in the mmc core stuff.
>
> as far as I can see the only bug outstanding is that the stock tifm
> modules are broken and should be replaced with the tifm developer fixed
> version, Whether this should be done by the feisty developers I'm not
> sure as really its an upstream bug (fixed in 2.6.21).
>
> Maybe they'll take pity on you and do it .
>
> --
> tifm: Texas Instruments Card reader not working
> https://bugs.launchpad.net/bugs/53923
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
Pau Marc Muñoz Torres

Laboratori de Biologia Computacional
Institut de Biotecnologia i Biomedicina Vicent
Villar
Universitat Autonoma de Barcelona
E-08193 Bellaterra (Barcelona)

telèfon: 93 5812807
Email : <email address hidden>

Come on, let's be polite, okay? Nobody gets money for this, neither the developers nor the testers. Fighting is not going to fix the bug.

Andrew, the SD cards don't work for me and I'm using Feisty's default configuration (no compiled module, no setpci). When I get home I'll try to play a little with the module and setpci and see if I can find a workaround.

I wasn't trying to get peoples backs up,

Just trying to explain that kernel 2.6.20 doesn't work at default with some TIFM hardware.

This is a kernel/TIFM issue not feisty, Any packaged distro running this kernel without patches will have this problem.

The sdhci module does work but to use this you have to switch the hardware over to SD mode.

The feisty bug in the pci MMC readers (of which TIFM is one) were not seen as host devices and hence hal would not mount has been fixed.

Pau Marc Muñoz Torres my SD card works fine in Linux, I am capable of fixing most/any issues with any Debian based distro and don't need to try and help anybody else.

As far as windows XP goes maybe you should delete your Linux partition and run the OS of you choice that your obviously so happy with, it is of no concern to me.

Carlos if you dont want to re-compile the tifm modules heres how to switch over to SD mode

from a command run

lspci

you will get a list of pci devices, look for the Mass storage controller texas instruments and note the number to the left

02:06.0 CardBus bridge: Texas Instruments PCIxx21/x515 Cardbus Controller
02:06.1 CardBus bridge: Texas Instruments PCIxx21/x515 Cardbus Controller
02:06.2 FireWire (IEEE 1394): Texas Instruments OHCI Compliant IEEE 1394 Host Controller
02:06.3 Mass storage controller: Texas Instruments PCIxx21 Integrated FlashMedia Controller

Issue the following command substituting your pci id where mine is

setpci -s 02:06.3 4c.b=0x02

now try inserting you sd card...
this needs to be done every reboot as its none persistant ... Note the is some confusing information out there about this in a nut shell

There are 2 drivers capable of driving this module
SDHCI
and
TIFM_sd.TIFM_7xx1,TIFM_core

the tifm module are bust in the 2.6.20 kernel series

to use sdhci you have to switch the hardware mode over using setpci

NOTE as far as I can tell both drivers only support SD cards 100% sure this is true for the tifm driver but cant find anything definitive about the sdhci driver ..can't test myself as only have sd cards.

Andrew,

I tried your solution (setpci + using 'sdhci' module), but it didn't work.

I entered the setpci command with the correct address, modprobed sdhci, and then inserted the SD card, but nothing happened. 'dmesg' does not show any information about the SD card, it seems like it was't inserted.

Anything else I could try besides recompiling the module?

PS: Can I reverse the setpci command? I mean, typing something to use tifm again instead of sdhci?

Thanks

A reboot will undo the setpci.

What controller do you have??

I just did

rmmod tifm_sd
rmmod tifm_7xx1
rmmod tifm_core
setpci -s 02:06.3 4c.b=0x02
Inserted card here <---- sd auto mounted and file browser opened
dmesg
[30776.012000] mmcblk0: mmc2:0001 SDMMC 508800KiB
[30776.012000] mmcblk0: p1
lsmod |grep mmc
mmc_block 13832 2
mmc_core 26756 2 mmc_block,sdhci

So for me sdhci works fine ...

Have now proved ONLY SD cards will work with either driver (just plugged a borrowed SM card in nothing diddly squat.)

So from this I'm happy tifm is the way to go as work is under way for XD and sony memory stick.

Just found out some of the Newer TIFM hardware does NOT support legacy SD mode so setpci will NOT work with these devices.

This is for the Kernel devs

this thread on kernel.org between kernell devs and tifm dev explains why suspend is bust with SD card mounted

http://lkml.org/lkml/2007/2/17/86

It also has stuff about hald failing but guess you were also on top of this as thats what youve fixed.

I got my kernel updated today; and I am using SDHCI using the setpci hack and my auto mount woks fine in gnome; that solves my problem.

uname -a
Linux matrix 2.6.20-15-generic #2 SMP Sat Apr 14 00:54:01 UTC 2007 i686 GNU/Linux

Andrew: My laptop is 2 years old, and the SD card reader worked fine with Dapper, that's why I'm surprised with this regression.
My controller:

06:01.3 Mass storage controller: Texas Instruments PCIxx21 Integrated FlashMedia Controller
        Subsystem: Acer Incorporated [ALI] Unknown device 0066
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 57 (1750ns min, 1000ns max), Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 18
        Region 0: Memory at c8214000 (32-bit, non-prefetchable) [size=8K]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Ramesh: Tried with the latest kernel, but no luck.

Ok, time to find some solutions.
First of all: My cardreader does work on Feisty 2.6.20-15 with the tifm-modules compiled from the sources (tifm 0.8d) with the protocol.h from the vanilla kernel copied "quick and dirty" to the headers file. It doesn't work with the setpci-hack and it doesn't work with the normal Feisty kernel.
Obviously the 0.8d modules will not be part of the 2.4.20.5 kernel, Feisty builds upon and the kernel guys should probably have more important things on their minds than fix cardreaders. So how about putting the compiled 0.8d tifm-modules in the modules-backports-package?

Regressions are ugly, and some people will be disappointed to see that their SD reader worked on Edgy but not on Feisty.

I think that, now that the modules are frozen, the best idea is to include 0.8d in the backports, as Bernhard says.

After 2.6.20-15 update my sd card reader now works with the setpci hack as it did in edgy.

After tonight's update to the kernel-image and -headers, my modules compiled yesterday won't load anymore - and neither will they compile with the borrowed protocol.h. Man, that's frustrating!

One more thing: As Andrew mentioned before, there seem to be at least 2 versions of TI hardware with the newer versions being "immune" to the setpci fix with the current kernel. (Mine manifests in lspci as:
06:00.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD)
06:00.3 Generic system peripheral [0805]: Texas Instruments PCIxx12 SDA Standard Compliant SD Host Controller
)

However, in the Edgy-kernel, the setpci-fix was working fine (I had a nice complicated startup script... :-) )... Since I 'm no real dev, I can only say: Strange things happen.

So what happens next? Anyone packaging modules? Does someone know what the kernel guys did to the protocols.h and mmc headers? A tifm-source package that builds with the ubuntu-kernel?

Still works for me...

ensure max_sectors remed out (I fell for this when re-downloaded tifm source)
protocol.ini copied accross

then
make clean
make
make install

If I didn't know better, I'd say it's monday - oh wait - it IS monday.

Of course after I tried everything again (unpack source, copy protocol.h, try make, forget "max_sectors" for the hundredth time, comment it out, do the make-trio, run depmod and modprobe) it works fine. However that'S exactly what I did this morning and I got some weird errors when inserting the tifm_sd module about symbol versions (even though I had removed the modules both from memory and the drive).

Doesn't matter - it works.

So what about packages?

[ 309.316000] tifm_sd: disagrees about version of symbol tifm_eject
[ 309.316000] tifm_sd: Unknown symbol tifm_eject
[ 309.316000] tifm_sd: disagrees about version of symbol tifm_register_driver
[ 309.316000] tifm_sd: Unknown symbol tifm_register_driver
[ 309.316000] tifm_sd: disagrees about version of symbol tifm_unmap_sg
[ 309.316000] tifm_sd: Unknown symbol tifm_unmap_sg
[ 309.316000] tifm_sd: disagrees about version of symbol tifm_map_sg
[ 309.316000] tifm_sd: Unknown symbol tifm_map_sg
[ 309.320000] tifm_sd: disagrees about version of symbol tifm_unregister_driver
[ 309.320000] tifm_sd: Unknown symbol tifm_unregister_driver

:|

02:09.3 Mass storage controller: Texas Instruments PCIxx21 Integrated FlashMedia Controller
        Subsystem: Fujitsu Siemens Computer GmbH Unknown device 1092
        Flags: bus master, medium devsel, latency 64, IRQ 16
        Memory at d0206000 (32-bit, non-prefetchable) [size=8K]
        Capabilities: <access denied>

ok i've solved also this =)

1. compile using this istruction https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/53923/comments/48
2. sudo cp tifm_sd.ko /lib/modules/$(uname -r)/kernel/drivers/misc
3. make install

seem to works =))))

bad english :D -.- sorry :°°°°o

Just to confirm. I have the same problem in a Toshiba U205 - S5067 noteboook.

lspci:

03:08.0 Ethernet controller: Intel Corporation PRO/100 VE Network Connection (rev 02)
03:0b.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
03:0b.1 FireWire (IEEE 1394): Texas Instruments PCIxx12 OHCI Compliant IEEE 1394 Host Controller
03:0b.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD)
03:0b.3 Generic system peripheral [0805]: Texas Instruments PCIxx12 SDA Standard Compliant SD Host Controller

In this computer, the setpci hack doen't seem to work and I could not get the tifm module to compile and install cleanly (I did as Andrew suggested and copied the protocol.h file (from the old 2.6.20-12, it was installed and it had the file) and I commented out the max sector line in tifm_sd.c. But I couldn't get the newly compiled modules to install cleanly. The system complained.)

I just installed Ubuntu 7.04, the sd card did not auto mount, and I can't seem to mount it manually. I tried to download the driver from above but the links seem broken.

The card reader worked fine in 6.10, and would auto mount.

lspci:
06:04.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
06:04.1 FireWire (IEEE 1394): Texas Instruments PCIxx12 OHCI Compliant IEEE 1394 Host Controller
06:04.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD)
06:04.3 Generic system peripheral [0805]: Texas Instruments PCIxx12 SDA Standard Compliant SD Host Controller

The sd-card reader ist still broken in feisty (Thinkpad Z61m).
--- /var/log/messages
Apr 21 16:18:41 homer kernel: [ 321.332000] tifm_7xx1: sd card detected in socket 1
Apr 21 16:18:42 homer kernel: [ 321.664000] mmcblk0: mmc1:3975 SD02G 2011136KiB
Apr 21 16:18:42 homer kernel: [ 321.664000] mmcblk0: p1
Apr 21 16:21:53 homer kernel: [ 513.012000] end_request: I/O error, dev mmcblk0, sector 4022208
Apr 21 16:21:53 homer kernel: [ 513.012000] printk: 1341 messages suppressed.
Apr 21 16:21:53 homer kernel: [ 513.012000] end_request: I/O error, dev mmcblk0, sector 4022208
Apr 21 16:21:53 homer kernel: [ 513.012000] end_request: I/O error, dev mmcblk0, sector 4022256
Apr 21 16:21:53 homer kernel: [ 513.012000] end_request: I/O error, dev mmcblk0, sector 4022256
Apr 21 16:21:53 homer kernel: [ 513.012000] end_request: I/O error, dev mmcblk0, sector 0
Apr 21 16:21:53 homer last message repeated 2 times
Apr 21 16:21:53 homer kernel: [ 513.016000] end_request: I/O error, dev mmcblk0, sector 0
Apr 21 16:21:53 homer last message repeated 25 times
...
... hundreds of messages
---

---- lspci -vvv|less -p " Standard Compliant SD Host Controller"
15:00.3 Generic system peripheral [0805]: Texas Instruments PCIxx12 SDA Standard Compliant SD Host Controller (prog-if 01)
        Subsystem: Lenovo Unknown device 207d
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 (1750ns min, 1000ns max)
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at e4302800 (32-bit, non-prefetchable) [size=256]
        Capabilities: [80] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Before upgrading to feisty it worked if i loaded the following modules manually
----
modprobe tifm_7xx1 sdhci tifm_sd mmc_core tifm_core tifm_sd sdhci
----

My SD card reader isn't working in Feisty (final release) either. In Ubuntu Edgy when I added:
modprobe tifm_sd
to one of the init scripts, it worked fine, including auto mount. Now it doesn't work.

I have a Toshiba A100-TA7

My error messages are the same as scoopex above so I won't bother posting them unless anyone needs it.

My hardware info:
lspci -vvv|less -p " Standard Compliant SD Host Controller"
07:06.3 Generic system peripheral [0805]: Texas Instruments PCIxx12 SDA Standard Compliant SD Host Controller (prog-if 01)
        Subsystem: Toshiba America Info Systems Unknown device ff10
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 128 (1750ns min, 1000ns max), Cache Line Size: 16 bytes
        Interrupt: pin A routed to IRQ 18
        Region 0: Memory at dc006800 (32-bit, non-prefetchable) [size=256]
        Capabilities: [80] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

I get the same errors as scoopex

Fresh install of Feisty Kubuntu AMD64 on a Lenovo Thinkpad Z61t

The solution is in the preceding bug report.

to recap

1 The kernel supplied in feisty has BROKEN tifm modules
2 TIFM modules or the set pci hack ONLY support SD cards NOT ms,sm or xd at this time
3 Unless Ubuntu supply corrected modules the only way to get this working is to follow the instructions in this thread (compile your own).

if you get "end_request: I/O error, dev mmcblk0,......." then you you are running the buggy modules
if you get "tifm_sd: disagrees about version of symbol tifm_register_driver" you are running a bit of both ;-) (hint ...make clean, and rmmod)

Auto mounting is fixed its just the driver faulty, Fix the driver and your set.

As a plus the .8 driver is a lot less buggy than the .6 in edgy (dont reboot the machine with the sd card in or you have the multiple sd cards on the desktop )

Could you please point to the exact reply with the instructions for compiling the modules?

in reply to :
https://bugs.launchpad.net/ubuntu/+source/udev/+bug/53923/comments/98

is this the same thing is you dont get the errors, but the card wont mount.

Also noticed that it is finding cards as xd, even if SD is in the slot.....

linux/mmc/protocol.h does not appear to be the only thing that is needed. The struct mmc_host structure is missing the max_sectors member in the linux/mmc/host.h file and the version of the module that comes with feisty 2.6.20-14 is 0.7. The newest version is the one to which Andrew is referring and that is version 0.8. It appears that the linux/mmc/host.h file may need to be updated but that may affect other mmc-related modules in the kernel.

The linux/mmc/host.h file from the kernel also #includes linux/mmc/mmc.h which causes additional compilation problems. Replacing that with linux/mmc/core.h got the module to compile and then it works. Maybe the solution going forward is to update the 2.6.20 sources to use 2.6.20.6 instead of 2.6.20.4 and include version 0.8 of the tifm driver?

^^^^^^^^^^^
To that: where do we get those files? It looks like the kernel is one big text file packaged up instead a whole bunch of .c and .h files. 2.6.20.6 & 2.6.20.7 don't have protocol.h mentioned anywhere. Also looks like the kernel part is just a patch (it's called patch-2.6.20.7) with a bunch of diffs (I'm clicking on the .bz2's with the names of the kernels in http://www.kernel.org/pub/linux/kernel/v2.6/ is that where I should be getting the sources? ). 2.6.20 has protocol.h and those structs mentioned. Should I copy the text regarding them and save them as the above-named files? I'm compiling in ~/src/tifm, so would I put those files in ~/src/tifm/linux/mmc/? The tifm 0.8 tarball I downloaded doesn't have a linux/mmc folder at all. I downloaded it from the link that was provided above.

I attached the part of the 2.6.20 that I think is relevant. Can you tell me if I have the right stuff and what to do with it to compile the modules properly?

Alright, correction. I got the full sources now. But where in the full 2.6.20 sources are those header files located? I found mmc.h mmci.h and mmc_queue.h in /linux-2.6.20/drivers/mmc/ (in the kernel tarball), but I don't see protocol.h anywhere.

Okay, nevermind. I figured out the answers to my questions, and then I made a bash script that will automate this. I'm attaching a tarball. Untar it, then either read the readme if you want to, or
sudo chmod +x install.sh
./install.sh

which is pretty much what the readme says to do, except that the readme includes the right-click way too.

Good work maco. I will be a guinea pig and try it when I get home tonight.

The find command didn't locate those files you couldn't see in the kernel source ?

Don't know if anyone else has this problem, but it looks like the attatched tarball (http://librarian.launchpad.net/7395543/tifm_install.tar.gz) in post, https://bugs.launchpad.net/ubuntu/+source/udev/+bug/53923/comments/103
is corrupt.

No actually i downloaded it and it extracted. I dpn't know if you mean if it works or not, i haven't tried it yet. I will, when i get home like DaveQB. I keep my fingers crossed till then!

I just redownloaded it and everything's there. Perhaps there was a problem mid-download?

Oh, the problem I was having was that I was downloading the patch instead of all 40-something megabytes of kernel source. Once I got the full sources, I did a grep -r protocol.h . (after reading the grep man page :p) to find out where they are (lack of direct path like /usr/src/linux-headers-2.6.20-15-generic/include/linux/mmc/protocol.h was confusing, so I had to search...I get it now though). I don't play around with the kernel much...I should.

maco do you know if this will work for me? I am new to linux. Just two months time and i just ugraded edgy to feisty. My card reader does not work. I can see in dmesg that my memory stick has been detected. I believe that an sd card ican be detected too but i don't see them on my desktop (so i believe they are not mounted correctly). I can see in your readme that thiese modules are of a newer version than the ones in feisty... Why is that there are no updates in update manager, if this is a newer version and it works? I suppose it needs testing...First of all how can i see which version is installed on my feisty?

Thanks a lot in advance.

Yes downloaded it now from work, and was able to extract...

But get an error when running make...

make
Warning: Compiling for 2.6:
make -C /lib/modules/2.6.20-15-generic/build SUBDIRS=/home/mgm/nozomi_2.21alpha_060917 modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.20-15-generic'
  CC [M] /home/mgm/nozomi_2.21alpha_060917/nozomi.o
/home/mgm/nozomi_2.21alpha_060917/nozomi.c: In function ‘interrupt_handler’:
/home/mgm/nozomi_2.21alpha_060917/nozomi.c:1403: warning: cast from pointer to integer of different size
/home/mgm/nozomi_2.21alpha_060917/nozomi.c: In function ‘nozomi_setup_interrupt’:
/home/mgm/nozomi_2.21alpha_060917/nozomi.c:1517: warning: passing argument 2 of ‘request_irq’ from incompatible pointer type
/home/mgm/nozomi_2.21alpha_060917/nozomi.c: In function ‘nozomi_card_init’:
/home/mgm/nozomi_2.21alpha_060917/nozomi.c:1689: warning: cast from pointer to integer of different size
/home/mgm/nozomi_2.21alpha_060917/nozomi.c:1736:64: error: macro "INIT_WORK" passed 3 arguments, but takes just 2
/home/mgm/nozomi_2.21alpha_060917/nozomi.c:1736: error: ‘INIT_WORK’ undeclared (first use in this function)
/home/mgm/nozomi_2.21alpha_060917/nozomi.c:1736: error: (Each undeclared identifier is reported only once
/home/mgm/nozomi_2.21alpha_060917/nozomi.c:1736: error: for each function it appears in.)
/home/mgm/nozomi_2.21alpha_060917/nozomi.c:1742: warning: overflow in implicit constant conversion
/home/mgm/nozomi_2.21alpha_060917/nozomi.c: At top level:
/home/mgm/nozomi_2.21alpha_060917/nozomi.c:2326: warning: initialization from incompatible pointer type
/home/mgm/nozomi_2.21alpha_060917/nozomi.c: In function ‘ntty_tty_init’:
/home/mgm/nozomi_2.21alpha_060917/nozomi.c:2361: warning: assignment from incompatible pointer type
/home/mgm/nozomi_2.21alpha_060917/nozomi.c:2362: warning: assignment from incompatible pointer type
make[2]: *** [/home/mgm/nozomi_2.21alpha_060917/nozomi.o] Error 1
make[1]: *** [_module_/home/mgm/nozomi_2.21alpha_060917] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-2.6.20-15-generic'
make: *** [default] Error 2

Any ideas?

uname -a
Linux mgm-laptop 2.6.20-15-generic #2 SMP Sun Apr 15 06:17:24 UTC 2007 x86_64 GNU/Linux

Do a
lspci
(in the terminal) and see if you have something like this:
04:09.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD)
If it's Texas Instruments, it should work. The reason it didn't come through updates? The devs never got around to fixing the bug and it seems they're letting it sit. There's plenty of discussion on this bug of how to fix it, so that file just does what they all said to do without you having to figure out *how* (or download 40mb through which you'd have to sort).

Mackenzie Morgan
Linux User # 432169
Hey, type this in the terminal! It's really fun!
apt-get moo
then try
aptitude moo
and
aptitude -v moo
just keep adding v's to that and watch it change

----- Original Message -----
From: Bill Prantzos <email address hidden>
Date: Tuesday, April 24, 2007 4:25 am
Subject: [Bug 53923] Re: tifm: Texas Instruments Card reader not working
To: <email address hidden>

> maco do you know if this will work for me? I am new to linux. Just two
> months time and i just ugraded edgy to feisty. My card reader does not
> work. I can see in dmesg that my memory stick has been detected. I
> believe that an sd card ican be detected too but i don't see them on my
> desktop (so i believe they are not mounted correctly). I can see in your
> readme that thiese modules are of a newer version than the ones in
> feisty... Why is that there are no updates in update manager, if this
> is
> a newer version and it works? I suppose it needs testing...First of all
> how can i see which version is installed on my feisty?
>
> Thanks a lot in advance.
>
> --
> tifm: Texas Instruments Card reader not working
>
> You received this bug notification because you are a direct subscriber
> of the bug.

yes i have a Texas instruments card reader. The output of lspci [-nnv] is not exactly the same but it is Texas Instruments... Thanks so much for your help. I hope this works. I will then have fixed nearly all my bugs and will be able to never use windows again!
What are those 40MB you mentioned? Aren't the files you posted source files? and we have to compile them and put them in the right places? (your script does that exactly. I had the chance to read the contents before i went to my office)

PS: I would be very grateful if you have any idea as to how can i use bluepin instead of bluez-pin to pair my bluetooth devices (i can't find the file on my system so as to use it in some configuration file...) Sorry for the irrelevant subject

Yes they're source files, but only the necessary ones. The entire kernel is 40-something mb and takes a while to download.

I'm uploading an updated tarball though. This one has an uninstall script as well and they are set to print out log files of what they did. So, if it was to fail (shouldn't) you can see where it happened...or just for your own curiosity :p

 i ran the script, partial success in that my logfiles dont fill with errors but it did not mount - kern.log has

tifm_sd: disagrees about version of symbol tifm_eject
tifm_sd: Unknown symbol tifm_eject

and more similar (attached); also attached the install.log...
any advice?

That makes me wonder if the log actually does anything...I think it wouldn't finish printing everything if it died mid-run, but if it finished running, it won't show anything unusual...

Do the uninstall, then
cd mmc
sudo cp protocol.h /usr/src/linux-headers-`uname -r`/include/linux/mmc/proto col.h
sudo mv /usr/src/linux-headers-`uname -r`/include/linux/mmc/host.h /usr/src/ linux-headers-`uname -r`/include/linux/mmc/host.h.old
sudo cp host.h /usr/src/linux-headers-`uname -r`/include/linux/mmc/host.h
cd ../tifm
sudo make

So that just the kernel headers are corrected and the first step of compiling. The logs from the Makefile are probably gone because of "make clean" at the end of the script, so check the logs in the "tifm" directory and see if there's anything wrong with the compiling. If nothing's wrong after "sudo make" try "sudo make install" and see if you get an error there.

Thanks a lot. It works great. I don't know if the lines you removed in the code files will have any effect. The were some "timing" variables etc etc... My sony memory stick does not work but i think there is no support for it yet. Another thing. In my /lib/modules/2.6.20-15-generic/kernel/drivers/mmc there was no tifm_sd.ko. Maybe it's in all Feisty systems, maybe only on mine... Indeed the log file when a command fails the entry is: something backed up to somethingelse which is misleading. (ex: In my case there was no file to move to file-old)

You're right...that wasn't there to begin with...uhh..oops I'll fix that...when I was making the uninstall one do its thing I added the backup-er to make it able to restore the old ones when you use the uninstall one, but since it wasn't there to begin with it cant :p
by the way, so I don't have to keep uploading it two places, it's at
http://geocities.com/dollzrgr8/tifm_install.tar.gz

There weren't any lines removed. The header-include line on the new host.h was changed as Jason said here:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/53923/comments/45
There were lines missing from the old host.h. The one in the tarball has the missing lines.

Quick Googling says Sony Memory Sticks only work if you have a USB card reader.

Okay, yeah, I'm not sure how to do a proper log thing. I figure it involves having some kind of if statements that if it works, it'll print that it did it's thing and if it doesn't it'll do something else, but I can't figure out how to make that happen in bash...and Google's not being too helpful.

Mark, my kernel and system logs show:
Inserting card, kern.log:
Apr 24 16:55:05 localhost kernel: [63994.596000] tifm_core: MMC/SD card detected in socket 0:1
Apr 24 16:55:05 localhost kernel: [63994.756000] mmcblk0: mmc0:cc8b SD064 60928KiB
Apr 24 16:55:05 localhost kernel: [63994.756000] mmcblk0: p1

Removing card, syslog & daemon.log:
Apr 24 17:51:59 localhost hald: unmounted /dev/mmcblk0p1 from '/media/disk' on behalf of uid 500

Can you look at Module.symvers in the tifm folder? Mine shows:

0x7625ea0d tifm_alloc_device drivers/misc/tifm_core EXPORT_SYMBOL
0xb1deb2e3 tifm_map_sg drivers/misc/tifm_core EXPORT_SYMBOL
0x39f86aa1 tifm_queue_work /home/maco/Desktop/tifm_install/tifm/tifm_core EXPORT_SYMBOL
0xd98bbe7e tifm_alloc_adapter drivers/misc/tifm_core EXPORT_SYMBOL
0x257b1daf tifm_add_adapter drivers/misc/tifm_core EXPORT_SYMBOL
0xee5a18c5 tifm_unregister_driver drivers/misc/tifm_core EXPORT_SYMBOL
0xdf91b1db tifm_free_adapter drivers/misc/tifm_core EXPORT_SYMBOL
0x5104a1b3 tifm_eject drivers/misc/tifm_core EXPORT_SYMBOL
0x56d708ec tifm_free_device drivers/misc/tifm_core EXPORT_SYMBOL
0x83b47cf3 tifm_unmap_sg drivers/misc/tifm_core EXPORT_SYMBOL
0x645f016b tifm_register_driver drivers/misc/tifm_core EXPORT_SYMBOL
0xe47f7293 tifm_remove_adapter drivers/misc/tifm_core EXPORT_SYMBOL

Is the 8th line there on yours?

You should remove the logging. It's enough you found the files and made an easy script by collecting the backup and copying commands into one script.
In install script there are some tabs/spaces i noticed. For example ... /usr /`uname -r` /kernel/etc etc etc I did not run the script as was, i deleted them first.
In host.h you added some things and deleted others (probably obsolete).

Well thanks a lot again...

I just did. I don't think there's much useful it can do seeing as I can't figure out how to tell it when something goes wrong. The Module.symvers is sort of a log for the building anyway.

Well THAT's weird. I noticed a tab in there a few hours ago, removed it, and reuploaded (at least on the geocities one). There's 2 back now O_o I don't know how that happens. Something hates vim? Fixed the tab again now...maybe it'll stick this time.

I tried maco install script. I found a little bug, maco. You try to rename the tifm_sd.ko file, searching for it
in /lib/modules/`uname -r`/kernel/drivers/mmc/, however in the newer kernel in Feisty, 2.6.20-15, this file
is located at /lib/modules/`uname -r`/kernel/drivers/mmc/host.

This bug explains the error messages that mark is seeing. The kernel is trying to load the old tifm_sd module
that is still there in the mmc/host directory. You have to rename or deleted the older module to make the
system load the new tifm_sd module.

After fixing that, and some whitespaces as Bill said, the script ran OK. Unfortunately my card reader is stil
dead. I have a new Toshiba U205 laptop. Maybe its Texas Instrument card reader is a new revision that
tifm 0.8 does not support? Is there any other U205 (for windows vista, mine is a S5067 model), confirm this?

I removed the renaming command for tifm_sd.ko because of it not being in drivers/mmc/ already (updated one is always on http://geocities.com/dollzrgr8/tifm_install.tar.gz ). Without touching the one in drivers/mmc/host/ at all, it compiles fine. The tifm Makefile puts it in drivers/mmc/, though now I'm looking through mmc/ to find out what all's going on in there.

On the 2.6.20-14 kernel (since I didn't compile on that one), there is:
mmc/core/mmc_core.ko
mmc/card/mmc_block.ko
mmc/host/tifm_sd.ko
mmc/host/wbsd.ko
mmc/host/sdhci.ko

After running the script, all of those are still there, but there is also mmc/tifm_sd.ko and it works for me right away. I'm testing different things now (moving files to other places, unloading modules, reloading modules, putting things back and moving other things).
mmc/tifm_sd.ko is necessary
mmc/card/mmc_block.ko is necessary
mmc/core/mmc_core.ko is necessary
Nothing in mmc/host/ has any effect on whether it works or not for me. wbsd and sdhci are in there, so that directory might pertain more to other card readers.

You do not have to remove mmc/host/tifm_sd.ko to make it work It is present on my system along with the new module and everything works fine.

Maybe you can try doing a sudo rmmod tifm_sd && modprobe tifm_sd ? I didn't have to modprobe the new modules when I tested this the first time (or through subsequent uninstall / reinstalls). It just worked immediately, but I suppose that could fix it for you.

I think I found the cause.

Philip commited TIFM 0.8 into a 2.6.20-(12 or 13?) kernel to fix this bug.

However, this git commit shows Ben Collins reverting from version 0.8 to 0.7, which caused a regression causing the TIFM breakage to show up again. I think this is was an unintentional mistake.

http://git.kernel.org/?p=linux/kernel/git/bcollins/ubuntu-feisty.git;a=commit;h=c25cfc3ad3cb8cac3474febfe66cff8ee0bfba18

Cause is confirmed:

Phillip Lougher [Thu, 8 Mar 2007 14:13:05 +0000 (14:13 +0000)]: Commits TIFM 0.8 to close bug 82680
http://git.kernel.org/?p=linux/kernel/git/bcollins/ubuntu-feisty.git;a=commitdiff;h=a3e42adedcd3c2f3364e6b620e12b14c68c7a149

Ben Collins [Tue, 20 Mar 2007 21:25:04 +0000 (17:25 -0400)]: "Updates TIFM Core" which also reverted TIFM to 0.7, causing a regression
http://git.kernel.org/?p=linux/kernel/git/bcollins/ubuntu-feisty.git;a=commitdiff;h=c25cfc3ad3cb8cac3474febfe66cff8ee0bfba18

I'm pretty certain the reverting of TIFM from 0.8 to 0.7 was an accident?

maco: i now have a happy SD card!

confirm that there were whitespaces in the install script - i even checked
it myself b4 running it, duh! - which was likely the cause of my probs.
Ran the latest, kicked out a couple errors:

ERROR: Module tifm_sd does not exist in /proc/modules
ERROR: Module mmc_core is in use by sdhci

and there was a little wierdness about permission to umount but after reboot
is all working - mount/umount, plug in/plug out.

Thanks to you, and to the other smart folks above, who have put in time and
effort to make this work.

On 24/04/07, maco <email address hidden> wrote:

> Can you look at Module.symvers in the tifm folder?
>
>

Those errors were from rmmod & modprobing the modules. It seems not all computer run the same ones to get it going though. Mine didn't have sdhci running, but tifm_sd was. Yours had sdhci and not tifm_sd by those errors. Too bad there's no "rmmod *sd*" and "modprobe *sd*" options, cuz ya know, that'd make things easy, and you can't have that :p

Thanks, maco, I used your original script (from comment 103) and my SD card reader on a Toshiba Satellite M55-S325 is now working fine again (as it was in Dapper). Great work!

Yes, the change was a mistake. We had already identified this a few days before release, but could not get the fix in time.

Phillip was going to work on getting 0.8 back in for feisty-updates. Assigning to him for clarification. This will get fixed.

I can also confirm that the script make my SD card work again.

On 4/25/07, pogets <email address hidden> wrote:
>
> Thanks, maco, I used your original script (from comment 103) and my SD
> card reader on a Toshiba Satellite M55-S325 is now working fine again
> (as it was in Dapper). Great work!
>
> --
> tifm: Texas Instruments Card reader not working
> https://bugs.launchpad.net/bugs/53923
> You received this bug notification because you are a direct subscriber
> of the bug.
>

After update from 6.10 to 7.04 the sd card reader does not work:

lspci result:

00:00.0 Host bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02)
00:00.1 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02)
00:00.3 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 83)
00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 03)
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03)
00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 03)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
02:06.0 Network controller: Intel Corporation PRO/Wireless 2200BG Network Connection (rev 05)
02:09.0 CardBus bridge: Texas Instruments PCIxx21/x515 Cardbus Controller
02:09.2 FireWire (IEEE 1394): Texas Instruments OHCI Compliant IEEE 1394 Host Controller
02:09.3 Mass storage controller: Texas Instruments PCIxx21 Integrated FlashMedia Controller
02:09.4 Generic system peripheral [0805]: Texas Instruments PCI6411/6421/6611/6621/7411/7421/7611/7621 Secure Digital Controller

/var/log/massages after I insert the sd card:

[...]
Apr 25 08:42:25 NW001C0021 kernel: [ 1383.244000] tifm_7xx1: sd card detected in socket 3
Apr 25 08:42:26 NW001C0021 kernel: [ 1383.728000] mmcblk0: mmc3:b368 SDC 2009600KiB
Apr 25 08:42:26 NW001C0021 kernel: [ 1383.728000] mmcblk0: p1
Apr 25 08:42:27 NW001C0021 kernel: [ 1384.808000] end_request: I/O error, dev mmcblk0, sector 4019136
Apr 25 08:42:27 NW001C0021 kernel: [ 1384.808000] printk: 952 messages suppressed.
Apr 25 08:42:27 NW001C0021 kernel: [ 1384.808000] end_request: I/O error, dev mmcblk0, sector 4019136
Apr 25 08:42:27 NW001C0021 kernel: [ 1384.808000] end_request: I/O error, dev mmcblk0, sector 4019184
Apr 25 08:42:27 NW001C0021 kernel: [ 1384.812000] end_request: I/O error, dev mmcblk0, sector 4019184
Apr 25 08:42:27 NW001C0021 kernel: [ 1384.816000] end_request: I/O error, dev mmcblk0, sector 0
Apr 25 08:42:27 NW001C0021 kernel: [ 1384.816000] end_request: I/O error, dev mmcblk0, sector 0
Apr 25 08:42:27 NW001C0021 kernel: [ 1384.820000] end_request: I/O err...

Everyone, there is no need to further confirm that your cardreader is not working. The kernel developers know that, and know why it's happening, and are working on a fix. More comments to the bug tracker will not speed up this process :)

I was NEVER able to use card reader with any LINUX distro...

On Wed, 2007-04-25 at 20:50 +0000, slackwarelife wrote:

> After update from 6.10 to 7.04 the sd card reader does not work:
>
> lspci result:
>
> 00:00.0 Host bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02)
> 00:00.1 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02)
> 00:00.3 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02)
> 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
> 00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
> 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 03)
> 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 03)
> 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 03)
> 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 03)
> 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 83)
> 00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 03)
> 00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 03)
> 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 03)
> 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03)
> 00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 03)
> 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
> 02:06.0 Network controller: Intel Corporation PRO/Wireless 2200BG Network Connection (rev 05)
> 02:09.0 CardBus bridge: Texas Instruments PCIxx21/x515 Cardbus Controller
> 02:09.2 FireWire (IEEE 1394): Texas Instruments OHCI Compliant IEEE 1394 Host Controller
> 02:09.3 Mass storage controller: Texas Instruments PCIxx21 Integrated FlashMedia Controller
> 02:09.4 Generic system peripheral [0805]: Texas Instruments PCI6411/6421/6611/6621/7411/7421/7611/7621 Secure Digital Controller
>
> /var/log/massages after I insert the sd card:
>
> [...]
> Apr 25 08:42:25 NW001C0021 kernel: [ 1383.244000] tifm_7xx1: sd card detected in socket 3
> Apr 25 08:42:26 NW001C0021 kernel: [ 1383.728000] mmcblk0: mmc3:b368 SDC 2009600KiB
> Apr 25 08:42:26 NW001C0021 kernel: [ 1383.728000] mmcblk0: p1
> Apr 25 08:42:27 NW001C0021 kernel: [ 1384.808000] end_request: I/O error, dev mmcblk0, sector 4019136
> Apr 25 08:42:27 NW001C0021 kernel: [ 1384.808000] printk: 952 messages suppressed.
> Apr 25 08:42:27 NW001C0021 kernel: [ 1384.808000] end_request: I/O error, dev mmcblk0, sector 4019136
> Apr 25 08:42:27 NW001C0021 kernel: [ 1384.808000] end_request: I/O error, dev mmcblk0, sector 4019184
> Apr 25 08:42:27 NW001C0021 kernel: [ 1384.812000] end_request: I/O error, dev mmcblk0, sector 4019184
> Apr 25 08:42:27 NW001C0021 kernel: [ 1384.816000] end_request: I...

I installed newer tifm drivers on my system, using the script provided at http://ubuntulinuxtipstricks.blogspot.com/2007/04/texas-instruments-sdmmc-card-reader.html, then I run the "setpci hack" at each system boot using /etc/rc.local, and use the sdhci module. This makes my card work, but at reboot, when I log in, gnome freezes until I manually remove the card, then I reinsert the card, remove the sdhci module, insert it again, and my system works.

Please feel free to ask any information you need, but please do so before releasing the fix :)

Similar to Vincenzo, I following the instructions at Ubuntu Linux Tips & Tricks. However, I did not do anything with the "setpci hack" (which I had used before compiling the new tifm drivers (v0.8): setpci -s 04.3 4c=0x22 w/ v0.7 - default Feisty). I have both a HP/Compaq Presario V3000z & R4012us running Feisty AMD64 and had to compile the new tifm packages. I'm not at my V3000z, but here's the info from the R4012us:

03:04.0 CardBus bridge: Texas Instruments PCIxx21/x515 Cardbus Controller
        Subsystem: Hewlett-Packard Company Unknown device 3085
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 168, Cache Line Size: 128 bytes
        Interrupt: pin A routed to IRQ 20
        Region 0: Memory at b0209000 (32-bit, non-prefetchable) [size=4K]
        Bus: primary=03, secondary=04, subordinate=07, sec-latency=176
        Memory window 0: 50000000-53fff000 (prefetchable)
        Memory window 1: 54000000-57fff000
        I/O window 0: 0000a400-0000a4ff
        I/O window 1: 0000a800-0000a8ff
        BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
        16-bit legacy interface ports at 0001

03:04.3 Mass storage controller: Texas Instruments PCIxx21 Integrated FlashMedia Controller
        Subsystem: Hewlett-Packard Company Unknown device 3085
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 (1750ns min, 1000ns max), Cache Line Size: 32 bytes
        Interrupt: pin B routed to IRQ 21
        Region 0: Memory at b0206000 (32-bit, non-prefetchable) [size=8K]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

03:04.4 Generic system peripheral [0805]: Texas Instruments PCI6411/6421/6611/6621/7411/7421/7611/7621 Secure Digital Controller
        Subsystem: Hewlett-Packard Company Unknown device 3085
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 (1750ns min, 1000ns max), Cache Line Size: 32 bytes
        Interrupt: pin D routed to IRQ 23
        Region 0: Memory at b020a000 (32-bit, non-prefetchable) [size=256]
        Region 1: Memory at b0208c00 (32-bit, non-prefetchable) [size=256]
        Region 2: Memory at b0208800 (32-bit, non-prefetchable) [size=256]
        Capabilities: [80] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

If you need additional information, please let me know.

So y'all know, they're referring to the same script that's been uploaded in this bug. My blog links to it.

A test kernel with the new fixed tifm driver is available from http://people.ubuntu.com/~pkl/linux-image-2.6.20-16-generic_2.6.20-16.28_i386.deb

This has the fixed 0.8d tifm driver. The previously mentioned ways to get this driver to compile (commenting out code), produces a driver with extremely low default values for queue sizes. The driver in the previously mentioned build has (hopefully) correct values which will make it perform much better. However, I need someone with TI MMC hardware to check that it works correctly.

Please test. Once I know the driver works, it can be put in the next SRU upload of the Feisty kernel.

Please let me know if anyone wants an x86-64 built kernel.

If anyone needs to know, the package can be installed by sudo dpkg --install linux-image-2.6.20-16-generic_2.6.20-16.28_i386.deb and removed by sudo dpkg --purge linux-image-2.6.20-16-generic

Thanks.

Unfortunately it doesn't work for me (and the manual/script compilation fix doesn't work either).

I have a Toshiba U205 S2067 laptop with:

03:0b.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
03:0b.1 FireWire (IEEE 1394): Texas Instruments PCIxx12 OHCI Compliant IEEE 1394 Host Controller
03:0b.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD)
03:0b.3 Generic system peripheral [0805]: Texas Instruments PCIxx12 SDA Standard Compliant SD Host Controller

After booting I have modules tifm_core tifm_7xx1 mmc_core and sdhci installed. Modules tifm_sd and
mmc_block are not installed automatically. I have tried the following variations (none works):

tifm_core, tifm_7xx1, mmc_core, sdhci
tifm_core, tifm_7xx1, mmc_core, sdhci + tifm_sd
tifm_core, tifm_7xx1, mmc_core, sdhci + mmc_block
tifm_core, tifm_7xx1, mmc_core, sdhci + tifm_sd + mmc_block
tifm_core, tifm_7xx1, mmc_core + tifm_sd
tifm_core, tifm_7xx1, mmc_core +tifm_sd + mmc_block

(I achived this by eding the files /etc/modules and /etc/modprobe.h/blacklist)

Obs: Twice, after forgeting the SD card in the reader and booting the machine, my system
recognized the SD and I could browse it with nautilus. Once I unmount it, I can not mount
it anymore (and insertion doen't auto-mount int). So maybe the modules are working, but
my system is not reacting to the insertion of the card, even if I load some modules manually.

With the kernel given above, I could use the SD card reader just fine (it didn't work with feisty's original kernel).
I have an HP Pavillion dv1000 (dv1136ea).

With the kernel given, Texas SD card reader on HP compaq nc8430 started *working*.

the given kernel makes the card reader work again. hp nx6325.

RE: https://bugs.launchpad.net/ubuntu/+source/udev/+bug/53923/comments/142

I have nx6325 as well, and the kernel did not fix the problem, but perhaps i missed some steps. Can you please put what steps need to be taken? any blacklisting, and adding modules in /etc/modules? modprobing?

I installed the kernel provided by Philip and SD cards work automagically again on my HP nc64000 with Kubuntu 7.04.

Thank you!!!

Three partitions on a 512 MB Toshiba card:

[ 316.852000] tifm_core: MMC/SD card detected in socket 0:1
[ 317.604000] mmcblk0: mmc1:7562 SD512 500224KiB
[ 317.604000] mmcblk0: p1 p2 p3

With the stock kernel 2.6.21.1 from kernel.org the card reader does not work ...

RE: https://bugs.launchpad.net/ubuntu/+source/udev/+bug/53923/comments/142
I have not touched anything. but I have not tried the fix posted here earlier either. so if you have tried it it maybe has altered your setup.
an other possibilty is that you have an different laptop revision.

Works perfectly with test kernel here.

Absolutely nothing here. If I insert tifm modules, nothing happens. If I insert sdhci, led blinks but I can't see the card in "my computer". What should the device be in /dev? Where should card insertion be logged? How can I debug the problem, find more information on what should happen and is not happening?

I have a Toshiba A120-151. Built in SD card reader worked perfectly with Edgy, but broke when upgraded to Feisty.
Installed kernel suggested by Phillip. Unfortunately SD still not recognised with new kernel. Also my wireless card was not recognised (intel 3945) so have reverted to standard kernel.
Hope a fix can be provided soon.

That's probably because there's no l-r-m for that kernel yet, and the Intel wifi drivers are in l-r-m. When it's officially released, there'll be restricted modules for it though. This'll probably also mess with a few nvidia/ati graphics people.

I'm using a Compaq NX 6120; and my card works with your new kernel.

The kernel mentioned in comment 138 https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/53923/comments/138 doesn't seem to be available any more. I'm getting a 404 'not found' error.

On 5/17/07, Duncan Lithgow <email address hidden> wrote:
> The kernel mentioned in comment 138
> https://bugs.launchpad.net/ubuntu/+source/linux-
> source-2.6.17/+bug/53923/comments/138 doesn't seem to be available any
> more. I'm getting a 404 'not found' error.
>

Oops. It's back there now. There is in addition, a kernel for x86_64.

I've added another set of kernel images which (hopefully) fix ps/2
device recognition, which also need testing. To avoid confusion, I
put the tifm kernels in the directory no_ps2, and the ps/2 fix kernels
in the directory ps2 forgetting anyone following the original link
would get failure.

Thanks for pointing out the mistake.

Phillip

I also have this problem on my Gateway MX6440. I did not have this problem in 6.10, the card reader worked fine with tifm_sd / tifm_7xx1, tifm_core (and mmc_core). In order to get it to work with the 6.10 live cd I simply have to modprobe tifm_sd and it works.

On 7.04 it used to work occasionally. My 7.04 was an upgrade from 6.10 with a working configuration for the sd card reader, to which I had added tifm_sd, tifm_7xx1, tifm_core to /etc/modules. When the bug happened, /etc/modules did not have any ti* in it. Occasionally, (maybe 10-20%) if I started the computer up with the card in it or just inserted the sd card it work work and everything would be fine. The rest of the time nothing would happen that I could tell from the GUI. I realized today that my /root (because I didn't make a separate /var when I installed on my laptop) is full and I am unable to log in to my system. My /var directory contains aprox 18GB of logs, mainly in syslog.0 kern.log.0 syslog kern.log messages.0 messages all of which are 1-4.2GB in size. These huge logs were created in past 36-48 hours as my SO had left the SD in the laptop which was kept running the whole time.

This is an excerpt from /var/log/syslog

[133611.664000] tifm_sd: card failed to respond for a long period of time<6>tifm_7xx1: demand removing card from socket 3
[133611.664000] mmcblk0: error 1 sending read/write command
[133611.664000] end_request: I/O error, dev mmcblk0, sector 990912
[133611.664000] printk: 1277 messages suppressed
[133611.664000] Buffer I/O error on device mmcblk0, logical block 123864
[133611.664000] mmcblk0: error 1 sending read/write command
[133611.664000] end_request: I/O error, dev mmcblk0, sector 990912
[133611.664000] Buffer I/O error on device mmcblk0, logical block 123864

lspci -vv says

05:09.4 Class 0805: Texas Instruments PCI6411, PCI6421, PCI6611, PCI6621, PCI7411, PCI7421, PCI7611, PCI7621 Secure Digital (SD) Controller
        Subsystem: Gateway 2000 Unknown device 0300
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 (1750ns min, 1000ns max), Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 177
        Region 0: Memory at d0309000 (32-bit, non-prefetchable) [size=256]
        Region 1: Memory at d0308c00 (32-bit, non-prefetchable) [size=256]
        Region 2: Memory at d0308800 (32-bit, non-prefetchable) [size=256]
        Capabilities: [80] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

05:09.3 Mass storage controller: Texas Instruments PCIxx21 Integrated FlashMedia Controller
        Subsystem: Gateway 2000 Unknown device 0300
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 (1750ns min, 1000ns max), Cache Line Size: 32 bytes
        Interrupt: pin A routed to IR...

It works for me again. Although I can't suspend with a card inserted.

Using Kernel sugested in https://bugs.launchpad.net/ubuntu/+source/udev/+bug/53923/comments/138 my SD reader works again.

Software:
Ubuntu 7.04 fully updated + sugested linux-image
Hardware:
Laptop Acer Ferrari 4000
$ lspci
06:09.3 Mass storage controller: Texas Instruments PCIxx21 Integrated FlashMedia Controller
$ lspci -n
06:09.3 0180: 104c:8033

When the SD card is inserted, it is recognized and can be read/written.
BUG: Suspending the laptop with the SD inserted doesn't work: The laptop never completes the suspend and I have to turn it off using the power button.
Suspending the laptop without the SD inserted works OK, inserting the SD card while in suspended state resumes OK and the card is detected but not mounted. Double clicking on the card icon (In Nautilus computer://) mounts the card as expected.

Hello, I used the kernel sugested in https://bugs.launchpad.net/ubuntu/+source/udev/+bug/53923/comments/138

but still my card reader won't work, here's the output of dmesg when I inserted the MMC card:

[ 243.300000] tifm_core: MMC/SD card detected in socket 0:3
[ 243.428000] mmcblk0: mmc3:0001 000000 1003520KiB
[ 243.428000] mmcblk0: unknown partition table

That's the same error I get with linux-image-2.6.20-15-generic btw.
Here's output of lspci -vvv :

06:06.3 Mass storage controller: Texas Instruments PCIxx21 Integrated FlashMedia Controller
        Subsystem: Hewlett-Packard Company Unknown device 3081
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 128 (1750ns min, 1000ns max), Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 17
        Region 0: Memory at b0104000 (32-bit, non-prefetchable) [size=8K]
        Capabilities: <access denied>

06:06.4 Generic system peripheral [0805]: Texas Instruments PCI6411/6421/6611/6621/7411/7421/7611/7621 Secure Digital Controller
        Subsystem: Hewlett-Packard Company Unknown device 3081
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 128 (1750ns min, 1000ns max), Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 17
        Region 0: Memory at b0109000 (32-bit, non-prefetchable) [size=256]
        Region 1: Memory at b0108c00 (32-bit, non-prefetchable) [size=256]
        Region 2: Memory at b0108800 (32-bit, non-prefetchable) [size=256]
        Capabilities: <access denied>

It now works for me with the patch provided in https://bugs.launchpad.net/ubuntu/+source/udev/+bug/53923/comments/138 . It also seems to auto mount faster then it did in Edgy. I insert the card and its instantaneous where as in Edgy it probably took about half a second. Thank you!

The patch provide in bug 53923 comments 138 doesn't work for me.
I have no output in dmesg after insering a SD card.

My hardware :
03:0b.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD)
        Subsystem: Toshiba America Info Systems Unknown device 0001
        Flags: bus master, medium devsel, latency 64, IRQ 19
        Memory at ffa05000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: <access denied>

03:0b.3 Generic system peripheral [0805]: Texas Instruments PCIxx12 SDA Standard Compliant SD Host Controller (prog-if 01)
        Subsystem: Toshiba America Info Systems Unknown device 0001
        Flags: bus master, medium devsel, latency 64, IRQ 19
        Memory at ffa06800 (32-bit, non-prefetchable) [size=256]
        Capabilities: <access denied>

The MMC card reader was working on edgy.
tifm_7xx1, tifm_core and sdhci modules are loaded.

The fix works for me on x86-64, using http://people.ubuntu.com/~pkl/linux-image-2.6.20-16-generic_2.6.20-16.28_amd64.deb on an hp (compaq) nc6400 with the TI chipset. Using that 2.6.20-16.28 kernel, I no longer see the dmesg mmcblk0 errors.

$ lspci | grep MMC
02:06.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD)

I'm looking forward to an official release, though, because my wifi uses linux-restricted-modules.

Hi,
I've just tried the posted kernel in my HP nc6120, and it still doesn't work.

dmesg:

[20063.440000] tifm_core: MMC/SD card detected in socket 0:3
[20063.780000] mmcblk0: mmc3:e5ea SD01G 1006080KiB
[20063.780000] mmcblk0:<3>mmcblk0: error 2 transferring data
[20063.780000] end_request: I/O error, dev mmcblk0, sector 0
[20063.780000] Buffer I/O error on device mmcblk0, logical block 0
[20063.780000] mmcblk0: error 2 transferring data
[20063.780000] end_request: I/O error, dev mmcblk0, sector 0
[20063.780000] Buffer I/O error on device mmcblk0, logical block 0
[20063.780000] mmcblk0: error 2 transferring data
[20063.780000] end_request: I/O error, dev mmcblk0, sector 0
[20063.780000] Buffer I/O error on device mmcblk0, logical block 0
[20063.780000] mmcblk0: error 2 transferring data

...and so on.
It worked with Ubuntu 6.06, but since then it's like this.
I hope someone cleverer then me can fix it!

This worked for me.
https://answers.launchpad.net/ubuntu/+source/gnome-panel/+question/6262

Rejecting this from 2.6.22 until someone actually says they tested it on 2.6.22, and that if it doesn't work it's the _same_ bug, not just a "doesn't work there either".

> Rejecting this from 2.6.22 until someone actually says they tested it on
> 2.6.22, and that if it doesn't work it's the _same_ bug, not just a
> "doesn't work there either".
I tested it on 2.6.22 after downloading deb paquet. Troubes were like
for 2.6.20. In fact I think it's normal since this should be same module
and same bug.
I tried on 2.6.15 (dapper) and it didn't work on it. I don't got edgy
live-cd to test it again but it was working on it.

It works for me

thank you for all

Toshiba a130, the new kernel works for me. (Broke X that took a while to fix) Copied 1 file, copied several files at once. Was able to eject and it remounted automaticly when reinserted. Read Files off the card with this and other pc. Thanks.

What's the shortest path to backport gutsy's 2.6.22 kernel to feisty? And, please, can someone provide a checklist to know where exactly my card reader is "broken"? I am still unable to find anything in system logs, but it just won't work, and it was one of those that worked out-of-the-box in edgy.

Vincenzo: Just install the kernel from gutsy onto feisty.

On Wed, May 30, 2007 at 11:04:40PM -0000, Ben Collins wrote:
> Vincenzo: Just install the kernel from gutsy onto feisty.
I just did that, and I got this :

find: /lib/firmware/2.6.22-5-generic: No such file or directory
find: /lib/firmware/2.6.22-5-generic: No such file or directory
find: /lib/firmware/2.6.22-5-generic: No such file or directory
find: /lib/firmware/2.6.22-5-generic: No such file or directory
find: /lib/firmware/2.6.22-5-generic: No such file or directory
find: /lib/firmware/2.6.22-5-generic: No such file or directory

On Sun, May 27, 2007 at 10:34:21PM -0000, stevelasvegas wrote:
> This worked for me.
> https://answers.launchpad.net/ubuntu/+source/gnome-panel/+question/6262

I tried that with 2.6.20-15 & -16 kernels, neither worked for me ! Btw,
the card reader used to work in Edgy.

> What's the shortest path to backport gutsy's 2.6.22 kernel to feisty?
>

Just download linux-image-2.6.22-5-generic_2.6.22-5.11_i386.deb from
http://archive.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.22/
Nevertheless I tested it few days ago and it doesn't work better for me.

> And, please, can someone provide a checklist to know where exactly my
> card reader is "broken"? I am still unable to find anything in system
> logs, but it just won't work, and it was one of those that worked out-
> of-the-box in edgy.
>
Same as you.
I tried to get information from /var/log/kern.log but I haven't any.

Maybe someone can help us to compile the module with a "debug flag" and
help us to use and understand informations it may provide.

There are more and more bugs opened in launchpad and I surprised how
long they are opened/confirmed. I'd like to help to fix these bugs but I
don't how to do. I only know how to report them.

That script won't do anything for 2.6.20-16. It just does what the above comments say to do, but 2.6.20-16 have the modules already. It was only needed for 2.6.20-15.

As we have no information about the progress in resolving this bug, I tried to in an other way. I visited http://developer.berlios.de/projects/tifmxx and downloaded latest version available.

Then I tried to compile it but I got an unexpected error :

$ make
echo /tmp/tifm-0.8e.tar.bz2_FILES
/tmp/tifm-0.8e.tar.bz2_FILES
make -C /lib/modules/2.6.20-16-generic/build M=/tmp/tifm-0.8e.tar.bz2_FILES
make[1]: entrant dans le répertoire « /usr/src/linux-headers-2.6.20-16-generic »
  CC [M] /tmp/tifm-0.8e.tar.bz2_FILES/tifm_sd.o
/tmp/tifm-0.8e.tar.bz2_FILES/tifm_sd.c:16:32: erreur: linux/mmc/protocol.h : Aucun fichier ou répertoire de ce type
make[2]: *** [/tmp/tifm-0.8e.tar.bz2_FILES/tifm_sd.o] Erreur 1
make[1]: *** [_module_/tmp/tifm-0.8e.tar.bz2_FILES] Erreur 2
make[1]: quittant le répertoire « /usr/src/linux-headers-2.6.20-16-generic »
make: *** [all] Erreur 2

linux-headers-2.6.20-16-generic packet is installed on my computer, so I don't know if mmc-support is enabled. It was needed with 2.6.17 according to http://gentoo-wiki.com/HARDWARE_Gentoo_Acer_Ferrari_4005WLMi_Manual.
I'd like to be able to compile the module or to understand how it was compile on this version.

================

With current version, blockdevice /dev/mmcblk0p1 isn't created after inserting a SD card.
With older version, automount of the card worked, and here are the information on the module :

$ modinfo tifm_sd
filename: /lib/modules/2.6.17-10-generic/kernel/drivers/mmc/tifm_sd.ko
author: Alex Dubov
description: TI FlashMedia SD driver
license: GPL
version: 0.5
vermagic: 2.6.17-10-generic SMP mod_unload 586 REGPARM gcc-4.1
depends: mmc_core,tifm_core
srcversion: 01E00C53E8DFA16C1BE7F45
parm: no_dma:bool

And in dmesg :
[17180510.468000] mmcblk0: mmc0:b3c7 SD064 60928KiB
[17180510.468000] mmcblk0: p1
[17180525.908000] FAT: utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!

The card reader works for me now.
azrael@laptop666:~$ uname -a
Linux laptop666 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux
azrael@laptop666:~$ lspci |grep Texas
02:04.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
02:04.1 FireWire (IEEE 1394): Texas Instruments PCIxx12 OHCI Compliant IEEE 1394 Host Controller
02:04.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD)
02:04.3 Generic system peripheral [0805]: Texas Instruments PCIxx12 SDA Standard Compliant SD Host Controller

My laptop is HP Compaq nx6325.

Thx for the great work!

I tried a fresh gutsy cd, everything works on my tablet pc (even the pen of course), but MMC cardreader. I repeat, this cardreader, with this card I am using now, worked without any manual intervention in edgy. Here in feisty and gutsy, the tifm_* modules won't do anything useful. Removing those modules, then inserting SDHCI, won't do anything either (where not doing anything means no messages in system logs in both cases). If I remove every related module, then do the setpci hack, then install only sdhci, I get this in the logs

Jun 20 13:27:36 ubuntu kernel: [ 510.404000] sdhci: Secure Digital Host Controller Interface driver
Jun 20 13:27:36 ubuntu kernel: [ 510.404000] sdhci: Copyright(c) Pierre Ossman
Jun 20 13:27:36 ubuntu kernel: [ 510.404000] sdhci: SDHCI controller found at 0000:03:0b.3 [104c:803c] (rev 0)
Jun 20 13:27:36 ubuntu kernel: [ 510.404000] ACPI: PCI Interrupt 0000:03:0b.3[D] -> GSI 23 (level, low) -> IRQ 19
Jun 20 13:27:36 ubuntu kernel: [ 510.404000] mmc0: SDHCI at 0x58006800 irq 19 DMA

but nothing will happen when inserting the card (again, no messages in the log).

Please someone tell me how to provide more information, I am afraid that my case can be different from others and I would like to file a proper report *before* gutsy, since I reported a dupe of this *before feisty* (when I was wasting my time testing the beta), then had it fixed, then it broke again *after feisty* i.e. in the stable version. I believe in contributing to the community and reporting problems, but I am getting a little fed up with this particular bug.

I tested it on 2.6.22, and it is the same bug.

> Please someone tell me how to provide more information, I am afraid that
> my case can be different from others and I would like to file a proper
> report *before* gutsy, since I reported a dupe of this *before feisty*
> (when I was wasting my time testing the beta), then had it fixed, then
> it broke again *after feisty* i.e. in the stable version. I believe in
> contributing to the community and reporting problems, but I am getting a
> little fed up with this particular bug.
>
I wrote to the developer. I put the answer bellow (that I haven't tried).
I've got same trouble as you.

> Then, it is very surprising you are not
> seeing anything in the log (not even "card detected" message). As always, compiling with -DDEBUG
> may shed some light.
>

This may help us !

Just for the heck of it, have you tried checking with an Edgy Live CD that the card reader itself isn't broken? The fact that dmesg isn't seeing anything happening there at all is a bit weird.

> I tried a fresh gutsy cd, everything works on my tablet pc (even the pen
> of course), but MMC cardreader. I repeat, this cardreader, with this
> card I am using now, worked without any manual intervention in edgy.
> Here in feisty and gutsy, the tifm_* modules won't do anything useful.
> Removing those modules, then inserting SDHCI, won't do anything either
> (where not doing anything means no messages in system logs in both
> cases). If I remove every related module, then do the setpci hack, then
> install only sdhci, I get this in the logs
>
> Jun 20 13:27:36 ubuntu kernel: [ 510.404000] sdhci: Secure Digital
> Host Controller Interface driver
> Jun 20 13:27:36 ubuntu kernel: [ 510.404000] sdhci: Copyright(c)
> Pierre Ossman
> Jun 20 13:27:36 ubuntu kernel: [ 510.404000] sdhci: SDHCI controller
> found at 0000:03:0b.3 [104c:803c] (rev 0)
> Jun 20 13:27:36 ubuntu kernel: [ 510.404000] ACPI: PCI Interrupt
> 0000:03:0b.3[D] -> GSI 23 (level, low) -> IRQ 19
> Jun 20 13:27:36 ubuntu kernel: [ 510.404000] mmc0: SDHCI at
> 0x58006800 irq 19 DMA
>
> but nothing will happen when inserting the card (again, no messages in
> the log).
>
> Please someone tell me how to provide more information, I am afraid that
> my case can be different from others and I would like to file a proper
> report *before* gutsy, since I reported a dupe of this *before feisty*
> (when I was wasting my time testing the beta), then had it fixed, then
> it broke again *after feisty* i.e. in the stable version. I believe in
> contributing to the community and reporting problems, but I am getting
> a
> little fed up with this particular bug.
>
> --
> tifm: Texas Instruments Card reader not working
>
> You received this bug notification because you are a direct subscriber
> of the bug.

My Kernel:
Linux ubuntu 2.6.22-6-generic #1 SMP Fri Jun 1 19:24:12 GMT 2007 i686 GNU/Linux

My reader described at the start reads an SD card perfectly without any intervention.

I've updated the original description to reflect my experiences with Gutsy.

I'm running Dapper Drake and noted that there apparently is no support for tifm under Dapper. However, it was mentioned that there was another way around it and so I went out and bought a cheap SD card reader/writer and tried it.

It works okay. The permissions aren't quite right -- it won't let me write to it but I suspect somebody who knows what they're doing might be able to get that to work as well.

The card reader was distributed by GE for Jasco Products which is out of Oklahoma City, OK. Their website is www.jascoproducts.com and the model number is one of these 4 (my eyesight isn't good enough to read the tiny writing on the unit): HO97929, HO97930, HO97931 and HO97948.

Was able to dump four pictures taken from my Olympic camera to my desktop running Ubuntu Dapper Drake.

Browning>>>

2.6.22 target is invalid. Original bug is fixed. Reporter claiming to still see a problem needs to open a new bug, provide all details for device, and target it for gutsy (linux-source-2.6.22). That persons bug will not get fixed in feisty.

I opened bug #82680 which has been marked as a duplicate of this one, I opened that before stable release and I would kindly ask you all to at least try to fix that in feisty, by checking if I provided enough information and eventually engaging me in a debug session, at least to understand if the problem is or not in the kernel. I am travelling, will try provide debug logs for the modules next week. The bug I reported is *the same* in feisty and gutsy. I am not sure that my bug is a duplicate of this one, however this is not enough to say that the original bug is fixed, and that I have been writing for a while without being listened to it seems.

Question: Under Dapper, I have the same general problem which I fixed by going to an cheap card reader that doesn't use the texas instrument chip set. However, when I try to use that different card reader on a micro SD (1 gig, via a regular SD adapter -- it's for a verizon phone) the card shows up but no files are seen. Anybody else run into this?

Browning>>>

Just like my comment #177 my card works perfectly in Ubuntu 7.10 Tribe 3.

According to what I read above, there still is an issu with some Toshiba laptop.
I got the Toshiba U200 laptop
Paulo J. S. Silva got the Toshiba U205 laptop which is rather the same (comment 93)
Tom Dowden got the Toshiba A120-151 (comment 148)

These 3 laptop have an unusable SD card reader with 2.6.20-16.
I tried on gutsy tribe 5 but it doesn't work too.

On feisty (up-to-date) :

lspci -n :
03:0b.0 0607: 104c:8039
03:0b.1 0c00: 104c:803a
03:0b.2 0180: 104c:803b
03:0b.3 0805: 104c:803c

03:0b.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
03:0b.1 FireWire (IEEE 1394): Texas Instruments PCIxx12 OHCI Compliant IEEE 1394 Host Controller
03:0b.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD)
03:0b.3 Generic system peripheral [0805]: Texas Instruments PCIxx12 SDA Standard Compliant SD Host Controller

lshw :
           *-pcmcia
                description: CardBus bridge
                product: PCIxx12 Cardbus Controller
                vendor: Texas Instruments
                physical id: b
                bus info: pci@03:0b.0
                version: 00
                width: 32 bits
                clock: 33MHz
                capabilities: pcmcia bus_master cap_list
                configuration: driver=yenta_cardbus latency=176 maxlatency=5 mingnt=192
                resources: iomemory:ffa04000-ffa04fff irq:18
           *-firewire
                description: FireWire (IEEE 1394)
                product: PCIxx12 OHCI Compliant IEEE 1394 Host Controller
                vendor: Texas Instruments
                physical id: b.1
                bus info: pci@03:0b.1
                version: 00
                width: 32 bits
                clock: 33MHz
                capabilities: ohci bus_master cap_list
                configuration: driver=ohci1394 latency=64 maxlatency=4 mingnt=2
                resources: iomemory:ffa06000-ffa067ff iomemory:ffa00000-ffa03fff irq:22
           *-storage
                description: Mass storage controller
                product: 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD)
                vendor: Texas Instruments
                physical id: b.2
                bus info: pci@03:0b.2
                version: 00
                width: 32 bits
                clock: 33MHz
                capabilities: storage bus_master cap_list
                configuration: driver=tifm_7xx1 latency=64 maxlatency=4 mingnt=7
                resources: iomemory:ffa05000-ffa05fff irq:19
           *-system
                description: Generic system peripheral
                product: PCIxx12 SDA Standard Compliant SD Host Controller
                vendor: Texas Instruments
                physical id: b.3
                bus info: pci@03:0b.3
                version: 00
                width: 32 bits
                clock: 33MHz
                capabilities: bus_master cap_list
                configuration: driver=sdhci latency=64 maxlatency=4 mingnt=7
                resources: iomemory:ffa06800-ffa068ff irq:19

lsmod :
tifm_7xx1 8704 0
tifm_core 11140 1 tifm_7xx1
sdhci 18700 0
mmc_core ...

Me too, it still does not work, and worked in edgy.

lspci -n
00:00.0 0600: 8086:27a0 (rev 03)
00:02.0 0300: 8086:27a2 (rev 03)
00:02.1 0380: 8086:27a6 (rev 03)
00:1b.0 0403: 8086:27d8 (rev 02)
00:1c.0 0604: 8086:27d0 (rev 02)
00:1c.2 0604: 8086:27d4 (rev 02)
00:1d.0 0c03: 8086:27c8 (rev 02)
00:1d.1 0c03: 8086:27c9 (rev 02)
00:1d.2 0c03: 8086:27ca (rev 02)
00:1d.3 0c03: 8086:27cb (rev 02)
00:1d.7 0c03: 8086:27cc (rev 02)
00:1e.0 0604: 8086:2448 (rev e2)
00:1f.0 0601: 8086:27b9 (rev 02)
00:1f.1 0101: 8086:27df (rev 02)
00:1f.2 0106: 8086:27c5 (rev 02)
01:00.0 0200: 8086:109a
02:00.0 0280: 8086:4222 (rev 02)
03:0b.0 0607: 104c:8039
03:0b.1 0c00: 104c:803a
03:0b.2 0180: 104c:803b
03:0b.3 0805: 104c:803c

Bug #82680 is a duplicate of this one, both are not fixed for me.

Fixed for me. In my case the affected hardware is a built-in card
reader for an Averatec 2300 laptop.

On Thu, 2007-09-06 at 04:27 +0000, Vincenzo Ciancia wrote:

> Bug #82680 is a duplicate of this one, both are not fixed for me.
>
> ** Changed in: linux-source-2.6.20 (Ubuntu)
> Status: Fix Released => Confirmed
>

Ok, after some discussion on IRC I opened bug #137686. I would like to ask users and developers reading this bug report to take a look and eventually subscribe to that one.

I have Texas Instruments PCIxx21 Integrated FlashMedia Controller on my ACER Aspire 1692WLMi laptop not working with a Gutsy fresh install.

The tested kernel is:
$ uname -a
Linux roadrunner 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux

The Controller is reported by lspci -vv as:
06:01.3 Mass storage controller: Texas Instruments PCIxx21 Integrated FlashMedia Controller
        Subsystem: Acer Incorporated [ALI] Unknown device 0066
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 57 (1750ns min, 1000ns max), Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 18
        Region 0: Memory at b0214000 (32-bit, non-prefetchable) [size=8K]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME+

When I insert an MMS card into the slot I get the following messages from dmesg:
Nov 1 18:52:08 roadrunner kernel: [ 1357.024000] tifm_core: MemoryStick card detected in socket 0:2
Nov 1 18:52:08 roadrunner kernel: [ 1357.032000] tifm_ms: Unknown symbol tifm_has_ms_pif

And nothing happens. The card is not even shown with sudo fdisk -l .

udevmon gives when I insert thw card:
UDEV [1193936019.015727] add /devices/pci0000:00/0000:00:1e.0/0000:06:01.3/tifm_ms0:2 (tifm)

And when I remove it I have
[ 1487.488000] tifm0 : demand removing card from socket 0:2
from dmesg, and
UDEV [1193936059.381048] remove /devices/pci0000:00/0000:00:1e.0/0000:06:01.3/tifm_ms0:2 (tifm)
from udevmon .

I think the whole issue is because tifm_ms module fails to load with the error message: tifm_ms: Unknown symbol tifm_has_ms_pif . I take this same error when I try to manually modprobe tifm_ms:
$ sudo modprobe tifm_ms
FATAL: Error inserting tifm_ms (/lib/modules/2.6.22-14-generic/ubuntu/misc/tifm/tifm_ms.ko): Unknown symbol in module, or unknown parameter (see dmesg)

Please let me know if this is should be considered as a separate bug and if you need me to provide any more info from the affected system.

Don't know if it's a separate bug -- sound like what happened to me. The problem is that the Texas Instruments chip set isn't one chip set -- seems there are a couple of different ones out there and they react differently. I got mine working under Feisty with a fresh install and using a cheap USB reader. It then started showing up on the desktop but there were still problems with mounting and unmounting it. The upshot was that I more or less have to have the card in the reader and the reader in place when I boot Ubuntu and then I can transfer the photos to my Desktop.

Browning>>>

Konstantinos Togias <email address hidden> wrote: I have Texas Instruments PCIxx21 Integrated FlashMedia Controller on my
ACER Aspire 1692WLMi laptop not working with a Gutsy fresh install.

The tested kernel is:
$ uname -a
Linux roadrunner 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux

The Controller is reported by lspci -vv as:
06:01.3 Mass storage controller: Texas Instruments PCIxx21 Integrated FlashMedia Controller
        Subsystem: Acer Incorporated [ALI] Unknown device 0066
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR-

        Latency: 57 (1750ns min, 1000ns max), Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 18
        Region 0: Memory at b0214000 (32-bit, non-prefetchable) [size=8K]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME+

When I insert an MMS card into the slot I get the following messages from dmesg:
Nov 1 18:52:08 roadrunner kernel: [ 1357.024000] tifm_core: MemoryStick card detected in socket 0:2
Nov 1 18:52:08 roadrunner kernel: [ 1357.032000] tifm_ms: Unknown symbol tifm_has_ms_pif

And nothing happens. The card is not even shown with sudo fdisk -l .

udevmon gives when I insert thw card:
UDEV [1193936019.015727] add /devices/pci0000:00/0000:00:1e.0/0000:06:01.3/tifm_ms0:2 (tifm)

And when I remove it I have
[ 1487.488000] tifm0 : demand removing card from socket 0:2
from dmesg, and
UDEV [1193936059.381048] remove /devices/pci0000:00/0000:00:1e.0/0000:06:01.3/tifm_ms0:2 (tifm)
from udevmon .

I think the whole issue is because tifm_ms module fails to load with the error message: tifm_ms: Unknown symbol tifm_has_ms_pif . I take this same error when I try to manually modprobe tifm_ms:
$ sudo modprobe tifm_ms
FATAL: Error inserting tifm_ms (/lib/modules/2.6.22-14-generic/ubuntu/misc/tifm/tifm_ms.ko): Unknown symbol in module, or unknown parameter (see dmesg)

Please let me know if this is should be considered as a separate bug and
if you need me to provide any more info from the affected system.

--
tifm: Texas Instruments Card reader not working
https://bugs.launchpad.net/bugs/53923
You received this bug notification because you are a direct subscriber
of the bug.

Konstaninos and TG Browning....

I'm guessing by MMS you mean Memmory Stick as there is no such card as MMS.

This is not the same bug, Memory sticks are not yet supported by this driver

A quick search on the tifm home page shows
Currently in development:

tifm_ms - driver for MemoryStick cards (beta). This driver is not very useful without higher level MemoryStick protocol drivers. These are found in the same svn repository. Their current status:
memstick - card identification driver (beta)
ms_block - legacy MemoryStick storage support (alpha)
mspro_block - MemoryStick Pro storage support (beta, has some problems)
Early stages of development:

So the fact that the memmory stick is detected shows the driver is working to its present limit.

If you had read through this bug report you would also have found that I have mentioned REPEATEDLY that this drive only supports SD cards at present.

If you want Memmory Stick support I'd sugest you pop across to Belios's (the developer) homepage and cross his palm with silver or donate a MS card for testing.

Andrew,

Sorry if I wasn't clear -- this was NOT a memory stick issue. in point of fact, it was a SanDisk issue that I was referring to and it's flaky as hell, to be honest.

Don't get me wrong -- the people working on it are doing a heck of a good job. The problem (as I see it) is that there are different chip sets out there with odd firmware that doesn't ID itself very well. My experience was with a Secure Digital & Mutlimedia (GE supposedly) USB SanDisk reader. It works. Not great, but it does work if you have it in when the system boots. It occasionally works if you plug it in later, but not always.

Yes, the lspci and other scanning compenents under Ubuntu do see the current diskreader but get messed up, sometimes allowing them to be mounted, sometimes not, and always being a pain in the pratt if you pull the SanDisk. There doesn't seem to be any way to unmount them once they're there.

Please, Andrew, this was NOT a crit of you or the bug reporting and bug killing efforts of the Ubuntu community. Cripes, you guys do a heck of a job considering the complete and total lack of support that most vendors (influenced by Microsoft).

Browning>>>
Andrew Waldram <email address hidden> wrote: Konstaninos and TG Browning....

I'm guessing by MMS you mean Memmory Stick as there is no such card as
MMS.

This is not the same bug, Memory sticks are not yet supported by this
driver

A quick search on the tifm home page shows
Currently in development:

tifm_ms - driver for MemoryStick cards (beta). This driver is not very useful without higher level MemoryStick protocol drivers. These are found in the same svn repository. Their current status:
memstick - card identification driver (beta)
ms_block - legacy MemoryStick storage support (alpha)
mspro_block - MemoryStick Pro storage support (beta, has some problems)
Early stages of development: