Bug 734191

Summary: udisks mis-identifying CF card as a system drive and non-removeable
Product: [Fedora] Fedora Reporter: Solomon Peachy <pizza>
Component: udisksAssignee: David Zeuthen <davidz>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 15CC: davidz, jim.cromie, mclasen
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
udisks --dump for working card.
none
udisks --dump for non-working card
none
kernel patch to force 'removable' flag if device identifies as compactflash
none
ata_id patch
none
Tweak to the first patch to make it work.
none
Updated patch none

Description Solomon Peachy 2011-08-29 16:55:01 UTC
Created attachment 520432 [details]
udisks --dump for working card.

Description of problem:

I'm using an ExpressCard(PCIe)->CF adapter that uses a JMicron JM386 controller.  With one card it correctly identifies as a removable, non-system drive.  With another card, udisk identifies the card as a non-removable, system-internal drive and prompts the user for a password when attempting to mount it.

I can change the default permissions to allow this without a password, but that would allow true system drives to be unmounted by unprivileged users.

Version-Release number of selected component (if applicable):

udisks-1.0.2-4.fc15.x86_64
kernel-2.6.40.3-0.fc15.x86_64

How reproducible:   100% 

Steps to Reproduce:
1.  Insert CF<->ExpressCard adapter
2.  Drive should automount.
  
Actual results:

Does not automount with one CF card, but does with another.

Expected results:

Should automount with both cards.

Additional info:

The "working" card in this case is an old 256MB CF card that doesn't support UDMA.  The "non-working" card is a modern 16GB UDMA-enabled card that also supports SMART.  When I use either card in a USB CF reader both function as expected.

I don't know if this is a kernel or udisks problem.  I plan on digging into udisks to figure out where it makes the "System-internal" and "removeable" distinction, but clearly something's wrong here.

Comment 1 Solomon Peachy 2011-08-29 16:56:02 UTC
Created attachment 520433 [details]
udisks --dump for non-working card

Added the dump from the non-working card.

Comment 2 David Zeuthen 2011-08-29 19:09:51 UTC
I don't think there's any way to detect this is a CF card - from what I can tell, you can't really tell it apart from a hard disk using the ATA command-set. Please attach the output of 'hdparm -I /dev/sdb' and 'udevadm info -q all -n /dev/sdb'. Thanks.

Comment 3 David Zeuthen 2011-08-29 19:45:42 UTC
Actually please also attach

 udevadm info -q all -n /dev/sdb --attribute-walk

Maybe we can whitelist the controller in question.

Comment 4 Solomon Peachy 2011-08-30 00:39:20 UTC
[pizza@marinara ~]$ sudo hdparm -I /dev/sdd

/dev/sdd:

CompactFlash ATA device
        Model Number:       TS16GCF400                              
        Serial Number:      20101115    0140004A
        Firmware Revision:  20101008
Standards:
        Likely used: 6
Configuration:
        Logical         max     current
        cylinders       31045   31045
        heads           16      16
        sectors/track   63      63
        --
        CHS current addressable sectors:   31293360
        LBA    user addressable sectors:   31293360
        Logical/Physical Sector size:           512 bytes
        device size with M = 1024*1024:       15279 MBytes
        device size with M = 1000*1000:       16022 MBytes (16 GB)
        cache/buffer size  = 1 KBytes (type=DualPort)
Capabilities:
        LBA, IORDY(can be disabled)
        bytes avail on r/w long: 4
        Standby timer values: spec'd by Vendor
        R/W multiple sector transfer: Max = 1   Current = 0
        Advanced power management level: disabled
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 udma6 
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4 
             Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
        Enabled Supported:
           *    SMART feature set
                Security Mode feature set
                Power Management feature set
                Write cache
                WRITE_BUFFER command
                READ_BUFFER command
                NOP cmd
                CFA feature set
                Advanced Power Management feature set
                Mandatory FLUSH_CACHE
           *    CFA advanced modes: pio5 *pio6 mdma3 mdma4 
           *    CFA Power Level 1  (max 500mA)
Security: 
        Master password revision code = 65534
                supported
        not     enabled
        not     locked
        not     frozen
        not     expired: security count
        not     supported: enhanced erase
        6min for SECURITY ERASE UNIT. 
HW reset results:
        CBLID- above Vih
        Device num = 0
Integrity word not set (found 0x0000, expected 0xada5)

Comment 5 Solomon Peachy 2011-08-30 00:41:56 UTC
[pizza@marinara ~]$ sudo udevadm info -q all -n /dev/sdd
P: /devices/pci0000:00/0000:00:1c.2/0000:04:00.0/host23/target23:0:0/23:0:0:0/block/sdd
N: sdd
S: disk/by-id/ata-TS16GCF400_20101115_0140004A
S: disk/by-id/scsi-SATA_TS16GCF400_20101115_0140004A
S: disk/by-path/pci-0000:04:00.0-scsi-0:0:0:0
E: UDEV_LOG=3
E: DEVPATH=/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/host23/target23:0:0/23:0:0:0/block/sdd
E: MAJOR=8
E: MINOR=48
E: DEVNAME=/dev/sdd
E: DEVTYPE=disk
E: SUBSYSTEM=block
E: ID_ATA=1
E: ID_TYPE=disk
E: ID_BUS=ata
E: ID_MODEL=TS16GCF400
E: ID_MODEL_ENC=TS16GCF400\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
E: ID_REVISION=20101080
E: ID_SERIAL=TS16GCF400_20101115_0140004A
E: ID_SERIAL_SHORT=20101115_0140004A
E: ID_ATA_WRITE_CACHE=1
E: ID_ATA_WRITE_CACHE_ENABLED=0
E: ID_ATA_FEATURE_SET_PM=1
E: ID_ATA_FEATURE_SET_PM_ENABLED=0
E: ID_ATA_FEATURE_SET_SECURITY=1
E: ID_ATA_FEATURE_SET_SECURITY_ENABLED=0
E: ID_ATA_FEATURE_SET_SECURITY_ERASE_UNIT_MIN=6
E: ID_ATA_FEATURE_SET_SMART=1
E: ID_ATA_FEATURE_SET_SMART_ENABLED=0
E: ID_ATA_FEATURE_SET_APM=1
E: ID_ATA_FEATURE_SET_APM_ENABLED=0
E: ID_SCSI_COMPAT=SATA_TS16GCF400_20101115_0140004A
E: ID_PATH=pci-0000:04:00.0-scsi-0:0:0:0
E: ID_PART_TABLE_TYPE=dos
E: UDISKS_PRESENTATION_NOPOLICY=0
E: UDISKS_PARTITION_TABLE=1
E: UDISKS_PARTITION_TABLE_SCHEME=mbr
E: UDISKS_PARTITION_TABLE_COUNT=1
E: UDISKS_ATA_SMART_IS_AVAILABLE=1
E: DEVLINKS=/dev/disk/by-id/ata-TS16GCF400_20101115_0140004A /dev/disk/by-id/scsi-SATA_TS16GCF400_20101115_0140004A /dev/disk/by-path/pci-0000:04:00.0-scsi-0:0:0:0
E: TAGS=:systemd:

Comment 6 Solomon Peachy 2011-08-30 00:43:52 UTC
[pizza@marinara ~]$ udevadm info -q all -n /dev/sdd --attribute-walk

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/host23/target23:0:0/23:0:0:0/block/sdd':
    KERNEL=="sdd"
    SUBSYSTEM=="block"
    DRIVER==""
    ATTR{range}=="16"
    ATTR{ext_range}=="256"
    ATTR{removable}=="0"
    ATTR{ro}=="0"
    ATTR{size}=="31293360"
    ATTR{alignment_offset}=="0"
    ATTR{discard_alignment}=="0"
    ATTR{capability}=="50"
    ATTR{stat}=="     169      631     1409       56        0        0        0        0        0       56       56"
    ATTR{inflight}=="       0        0"
    ATTR{events}==""
    ATTR{events_async}==""
    ATTR{events_poll_msecs}=="-1"

  looking at parent device '/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/host23/target23:0:0/23:0:0:0':
    KERNELS=="23:0:0:0"
    SUBSYSTEMS=="scsi"
    DRIVERS=="sd"
    ATTRS{device_blocked}=="0"
    ATTRS{type}=="0"
    ATTRS{scsi_level}=="6"
    ATTRS{vendor}=="ATA     "
    ATTRS{model}=="TS16GCF400      "
    ATTRS{rev}=="2010"
    ATTRS{state}=="running"
    ATTRS{timeout}=="30"
    ATTRS{iocounterbits}=="32"
    ATTRS{iorequest_cnt}=="0xd5"
    ATTRS{iodone_cnt}=="0xd5"
    ATTRS{ioerr_cnt}=="0xa"
    ATTRS{evt_media_change}=="0"
    ATTRS{dh_state}=="detached"
    ATTRS{queue_depth}=="1"
    ATTRS{queue_type}=="none"

  looking at parent device '/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/host23/target23:0:0':
    KERNELS=="target23:0:0"
    SUBSYSTEMS=="scsi"
    DRIVERS==""

  looking at parent device '/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/host23':
    KERNELS=="host23"
    SUBSYSTEMS=="scsi"
    DRIVERS==""

  looking at parent device '/devices/pci0000:00/0000:00:1c.2/0000:04:00.0':
    KERNELS=="0000:04:00.0"
    SUBSYSTEMS=="pci"
    DRIVERS=="pata_jmicron"
    ATTRS{vendor}=="0x197b"
    ATTRS{device}=="0x2368"
    ATTRS{subsystem_vendor}=="0x197b"
    ATTRS{subsystem_device}=="0x2368"
    ATTRS{class}=="0x010185"
    ATTRS{irq}=="18"
    ATTRS{local_cpus}=="00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000003"
    ATTRS{local_cpulist}=="0-1"
    ATTRS{numa_node}=="-1"
    ATTRS{dma_mask_bits}=="32"
    ATTRS{consistent_dma_mask_bits}=="32"
    ATTRS{broken_parity_status}=="0"
    ATTRS{msi_bus}==""

  looking at parent device '/devices/pci0000:00/0000:00:1c.2':
    KERNELS=="0000:00:1c.2"
    SUBSYSTEMS=="pci"
    DRIVERS=="pcieport"
    ATTRS{vendor}=="0x8086"
    ATTRS{device}=="0x2944"
    ATTRS{subsystem_vendor}=="0x1043"
    ATTRS{subsystem_device}=="0x19a7"
    ATTRS{class}=="0x060400"
    ATTRS{irq}=="43"
    ATTRS{local_cpus}=="00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000003"
    ATTRS{local_cpulist}=="0-1"
    ATTRS{numa_node}=="-1"
    ATTRS{dma_mask_bits}=="32"
    ATTRS{consistent_dma_mask_bits}=="32"
    ATTRS{broken_parity_status}=="0"
    ATTRS{msi_bus}=="1"

  looking at parent device '/devices/pci0000:00':
    KERNELS=="pci0000:00"
    SUBSYSTEMS==""
    DRIVERS==""

Comment 7 Solomon Peachy 2011-08-30 00:55:12 UTC
What confuses me is that one CF card is detected as non-system_internal, but not the others that I have.  That tells me that the heuristic that makes that determination is somehow broken.

I've previously filed bugs against the kernel relating to this ExpressCard adapter ("SIIG ExpressCard54 CF R/W") but the pata_jmicron driver has no way of detecting that this particular model is different from any others, given that they all share the same PCI [sub]vendor/model ID, so I also have to play games with the pata layer to force "short40c" cables so that I can even use UDMA speeds.

So I don't think we're going to be able to whitelist that adapter somehow.

Comment 8 Solomon Peachy 2011-08-30 01:26:13 UTC
## And here's the dump from the "working" card:

[pizza@marinara ~]$ sudo hdparm -I /dev/sdc
[sudo] password for pizza: 

/dev/sdc:

CompactFlash ATA device
        Model Number:       Hitachi XXM2.3.0                        
        Serial Number:      X0213 20030606021821
        Firmware Revision:  Rev 3.00
Standards:
        Likely used: 4
Configuration:
        Logical         max     current
        cylinders       695     695
        heads           15      15
        sectors/track   48      48
        --
        bytes/track: 0  bytes/sector: 512
        CHS current addressable sectors:     500400
        LBA    user addressable sectors:     500400
        Logical/Physical Sector size:           512 bytes
        device size with M = 1024*1024:         244 MBytes
        device size with M = 1000*1000:         256 MBytes 
        cache/buffer size  = 1 KBytes (type=DualPort)
Capabilities:
        LBA, IORDY(may be)(cannot be disabled)
        Buffer size: 1.0kB      bytes avail on r/w long: 4
        Standby timer values: spec'd by Vendor
        R/W multiple sector transfer: Max = 1   Current = 0
        DMA: not supported
        PIO: pio0 pio1 

[pizza@marinara ~]$ sudo udevadm info -q all -n /dev/sdc
P: /devices/pci0000:00/0000:00:1c.2/0000:04:00.0/host30/target30:0:0/30:0:0:0/block/sdc
N: sdc
S: disk/by-id/ata-Hitachi_XXM2.3.0_X0213_20030606021821
S: disk/by-id/scsi-SATA_Hitachi_XXM2.3.X0213_20030606021821
S: disk/by-path/pci-0000:04:00.0-scsi-0:0:0:0
E: UDEV_LOG=3
E: DEVPATH=/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/host30/target30:0:0/30:0:0:0/block/sdc
E: MAJOR=8
E: MINOR=32
E: DEVNAME=/dev/sdc
E: DEVTYPE=disk
E: SUBSYSTEM=block
E: ID_ATA=1
E: ID_TYPE=generic
E: ID_BUS=ata
E: ID_MODEL=Hitachi_XXM2.3.0
E: ID_MODEL_ENC=Hitachi\x20XXM2.3.0\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
E: ID_REVISION=Rev_3.00
E: ID_SERIAL=Hitachi_XXM2.3.0_X0213_20030606021821
E: ID_SERIAL_SHORT=X0213_20030606021821
E: ID_SCSI_COMPAT=SATA_Hitachi_XXM2.3.X0213_20030606021821
E: ID_PATH=pci-0000:04:00.0-scsi-0:0:0:0
E: ID_PART_TABLE_TYPE=dos
E: UDISKS_PRESENTATION_NOPOLICY=0
E: UDISKS_PARTITION_TABLE=1
E: UDISKS_PARTITION_TABLE_SCHEME=mbr
E: UDISKS_PARTITION_TABLE_COUNT=1
E: DEVLINKS=/dev/disk/by-id/ata-Hitachi_XXM2.3.0_X0213_20030606021821 /dev/disk/by-id/scsi-SATA_Hitachi_XXM2.3.X0213_20030606021821 /dev/disk/by-path/pci-0000:04:00.0-scsi-0:0:0:0
E: TAGS=:systemd:

[pizza@marinara ~]$ sudo udevadm info -q all -n /dev/sdc --attribute-walk

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/host30/target30:0:0/30:0:0:0/block/sdc':
    KERNEL=="sdc"
    SUBSYSTEM=="block"
    DRIVER==""
    ATTR{range}=="16"
    ATTR{ext_range}=="256"
    ATTR{removable}=="1"
    ATTR{ro}=="0"
    ATTR{size}=="500400"
    ATTR{alignment_offset}=="0"
    ATTR{discard_alignment}=="0"
    ATTR{capability}=="51"
    ATTR{stat}=="     165        4     1352      771        0        0        0        0        0      771      771"
    ATTR{inflight}=="       0        0"
    ATTR{events}=="media_change"
    ATTR{events_async}==""
    ATTR{events_poll_msecs}=="-1"

  looking at parent device '/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/host30/target30:0:0/30:0:0:0':
    KERNELS=="30:0:0:0"
    SUBSYSTEMS=="scsi"
    DRIVERS=="sd"
    ATTRS{device_blocked}=="0"
    ATTRS{type}=="0"
    ATTRS{scsi_level}=="6"
    ATTRS{vendor}=="ATA     "
    ATTRS{model}=="Hitachi XXM2.3.0"
    ATTRS{rev}=="Rev "
    ATTRS{state}=="running"
    ATTRS{timeout}=="30"
    ATTRS{iocounterbits}=="32"
    ATTRS{iorequest_cnt}=="0x13d"
    ATTRS{iodone_cnt}=="0x13d"
    ATTRS{ioerr_cnt}=="0x2"
    ATTRS{evt_media_change}=="0"
    ATTRS{dh_state}=="detached"
    ATTRS{queue_depth}=="1"
    ATTRS{queue_type}=="none"

  looking at parent device '/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/host30/target30:0:0':
    KERNELS=="target30:0:0"
    SUBSYSTEMS=="scsi"
    DRIVERS==""

  looking at parent device '/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/host30':
    KERNELS=="host30"
    SUBSYSTEMS=="scsi"
    DRIVERS==""

  looking at parent device '/devices/pci0000:00/0000:00:1c.2/0000:04:00.0':
    KERNELS=="0000:04:00.0"
    SUBSYSTEMS=="pci"
    DRIVERS=="pata_jmicron"
    ATTRS{vendor}=="0x197b"
    ATTRS{device}=="0x2368"
    ATTRS{subsystem_vendor}=="0x197b"
    ATTRS{subsystem_device}=="0x2368"
    ATTRS{class}=="0x010185"
    ATTRS{irq}=="18"
    ATTRS{local_cpus}=="00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000003"
    ATTRS{local_cpulist}=="0-1"
    ATTRS{numa_node}=="-1"
    ATTRS{dma_mask_bits}=="32"
    ATTRS{consistent_dma_mask_bits}=="32"
    ATTRS{enable}=="1"
    ATTRS{broken_parity_status}=="0"
    ATTRS{msi_bus}==""
    ATTRS{resource1}=="P"
    ATTRS{resource3}==""

  looking at parent device '/devices/pci0000:00/0000:00:1c.2':
    KERNELS=="0000:00:1c.2"
    SUBSYSTEMS=="pci"
    DRIVERS=="pcieport"
    ATTRS{vendor}=="0x8086"
    ATTRS{device}=="0x2944"
    ATTRS{subsystem_vendor}=="0x1043"
    ATTRS{subsystem_device}=="0x19a7"
    ATTRS{class}=="0x060400"
    ATTRS{irq}=="43"
    ATTRS{local_cpus}=="00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000003"
    ATTRS{local_cpulist}=="0-1"
    ATTRS{numa_node}=="-1"
    ATTRS{dma_mask_bits}=="32"
    ATTRS{consistent_dma_mask_bits}=="32"
    ATTRS{enable}=="2"
    ATTRS{broken_parity_status}=="0"
    ATTRS{msi_bus}=="1"

  looking at parent device '/devices/pci0000:00':
    KERNELS=="pci0000:00"
    SUBSYSTEMS==""
    DRIVERS==""

Comment 9 David Zeuthen 2011-08-30 10:08:59 UTC
(In reply to comment #7)
> What confuses me is that one CF card is detected as non-system_internal, but
> not the others that I have.  That tells me that the heuristic that makes that
> determination is somehow broken.

It's not broken - the reason is that one card is reporting the sysfs removable attribute as 1, the other as 0. That's why you are seeing this. Why is the kernel driver doing this? I don't know - it's most probably just reporting what the hardware is telling it so the driver is probably fine.

The way to resolve this is to look at the ATA IDENTIFY data and make udev's ata_id export a property, say, ID_COMPACT_FLASH and then make udisks set system-internal to FALSE if this is set (this is possible because the IDENTIFY data has a bit for this - that's why I asked for hdparm -I output). I'll start working on the ata_id patch...

Comment 10 Solomon Peachy 2011-08-30 13:32:45 UTC
I'd noticed that 'removable' flag in the dumps, but hadn't had time to hunt down where it was being set.  Since you say that's sysfs attribute, fingers point to a kernel bug.  So I started digging into the kernel source.

The removable flag is set based on bit7 in the second byte of the SCSI identify response, which in turn is generated based on bit7 of the first byte of the ATA Identify response.

Hdparm blindly ignores that bit if the compact_flash bit is set -- so I patched that test out, and lo and behold, the "working" CF card has the "removable" flag set, but the "non-working" cards don't.  Interesting.  I wonder if the ATA/CF spec implies removable if the CFA bits are set?

Comment 11 Solomon Peachy 2011-08-30 13:34:04 UTC
Created attachment 520611 [details]
kernel patch to force 'removable' flag if device identifies as compactflash

I'm not sure how well this kernel patch will go over; would it be better to workaround this problem in userspace (eg udev?)

Comment 12 Solomon Peachy 2011-08-30 14:21:40 UTC
The plot thickens; apaprently the "Removable Media" feature set has been obsoleted in newer versions of the ATA specification, which explains why my newer CF cards don't have it set.

(That implies that setting the 'removable' attribute in the kernel is probably the wrong thing to do)

It looks like udev/udisks is where this fix should be implemented after all...

Comment 13 David Zeuthen 2011-08-30 15:11:00 UTC
(In reply to comment #12)
> The plot thickens; apaprently the "Removable Media" feature set has been
> obsoleted in newer versions of the ATA specification, which explains why my
> newer CF cards don't have it set.
> 
> (That implies that setting the 'removable' attribute in the kernel is probably
> the wrong thing to do)
> 
> It looks like udev/udisks is where this fix should be implemented after all...

Yes, that's what I meant with 7 - if the ATA IDENTIFY data indicates the ATA device is a compact flash device, then don't tag it as system_internal.

Since I don't have the hardware in question, any chance you can attach the IDENTIFY data as captured with hdparm's --Istdout option? Thanks!

Comment 14 Solomon Peachy 2011-08-30 18:31:49 UTC
### here ya go..

[pizza@marinara udisks (master)]$ sudo hdparm --Istdout /dev/sdb

/dev/sdb:
044a 7945 0000 0010 0000 0240 003f 01dd
7fb0 0000 3230 3130 3131 3135 2020 2020
3031 3430 3030 3441 0002 0002 0004 3230
3130 3130 3038 5453 3136 4743 4634 3030
2020 2020 2020 2020 2020 2020 2020 2020
2020 2020 2020 2020 2020 2020 2020 8001
0000 0f00 0000 0200 0000 0007 7945 0010
003f 7fb0 01dd 0100 7fb0 01dd 0000 0007
0003 0078 0078 0078 0078 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 702b 500c 4002 0001 0000 0003
207f 0003 0000 0000 fffe 604f 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0001 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
81f4 0000 0000 0092 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000

Comment 15 David Zeuthen 2011-08-31 14:06:28 UTC
Created attachment 520824 [details]
ata_id patch

Please try this patch. Semi-instructions (if needed)

 $ sudo yum-builddep udev
 $ git clone git://git.kernel.org/pub/scm/linux/hotplug/udev.git
 $ cd udev
 $ git am /path/to/0001-ata_id-Check-for-Compact-Flash-card.patch
 $ ./autogen.sh
 $ make
 $ sudo extras/ata_id/ata_id --export /dev/sdb

then attach the output. It should should ID_ATA_CF=1. Thanks!

Comment 16 Solomon Peachy 2011-09-01 01:30:34 UTC
There's a bug in the patch, but a tweak (patch to follow) and I get this with the newer DMA-enabled cards:

[pizza@marinara udev (master)]$ sudo extras/ata_id/ata_id --export /dev/sdb
ID_ATA=1
ID_TYPE=disk
ID_BUS=ata
ID_MODEL=TS16GCF400
ID_MODEL_ENC=TS16GCF400\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
ID_REVISION=20101080
ID_SERIAL=TS16GCF400_20101115_0140004A
ID_SERIAL_SHORT=20101115_0140004A
ID_ATA_WRITE_CACHE=1
ID_ATA_WRITE_CACHE_ENABLED=0
ID_ATA_FEATURE_SET_PM=1
ID_ATA_FEATURE_SET_PM_ENABLED=0
ID_ATA_FEATURE_SET_SECURITY=1
ID_ATA_FEATURE_SET_SECURITY_ENABLED=0
ID_ATA_FEATURE_SET_SECURITY_ERASE_UNIT_MIN=6
ID_ATA_FEATURE_SET_SMART=1
ID_ATA_FEATURE_SET_SMART_ENABLED=1
ID_ATA_FEATURE_SET_APM=1
ID_ATA_FEATURE_SET_APM_ENABLED=0
ID_ATA_CFA=1

I haven't tested this with my older card (left it at the office).

Comment 17 Solomon Peachy 2011-09-01 01:32:36 UTC
Created attachment 520932 [details]
Tweak to the first patch to make it work.

I don't immediately see why this patch is even necessary, but it may have something to do with this build warning:

  CC     extras/ata_id/ata_id.o
extras/ata_id/ata_id.c: In function ‘main’:
extras/ata_id/ata_id.c:705:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]

Comment 18 David Zeuthen 2011-09-01 16:06:10 UTC
Created attachment 521049 [details]
Updated patch

OK, here's an updated patch - I'm 99% it's right but would be great to test it nonetheless. Thanks!

Comment 19 Solomon Peachy 2011-09-01 17:50:37 UTC
Looks good; the build warning's gone and all of my CF cards are identified properly with ID_ATA_CFA=1.

Comment 20 David Zeuthen 2011-09-01 19:18:09 UTC
Excellent, thanks for testing - as master.kernel.org is currently down (cf. the recent security breach) I can't push it. But I sent it to the udev maintainer and it's now in his tree and will be part of udev 174.

Comment 21 Solomon Peachy 2011-09-01 20:46:23 UTC
Yay, one bug down.  That said, udisks still needs to be modified, correct?

Comment 22 David Zeuthen 2011-09-01 21:03:48 UTC
Indeed. Any chance you can try the following udev rule?

ENV{ID_ATA_CFA}=="?*", ENV{ID_DRIVE_FLASH_CF}="1", ENV{ID_DRIVE_MEDIA_FLASH_CF}="1", ENV{UDISKS_SYSTEM_INTERNAL}="0"

Thanks!

(See also http://hal.freedesktop.org/docs/udisks/udisks.7.html for other udev properties affecting how udisks work)

Comment 23 David Zeuthen 2011-09-01 21:04:22 UTC
Actually, I guess, use

 ENV{ID_ATA_CFA}=="1"

instead of

 ENV{ID_ATA_CFA}=="?*"

Comment 24 David Zeuthen 2011-09-19 14:57:55 UTC
Solomon: any chance you can try the rules in comment 22 and comment 23? Thanks!

Comment 25 Solomon Peachy 2011-10-05 00:43:15 UTC
I put off testing this due to kernel.org being down, preventing me from pulling the udev sources again.   (I'd managed to nuke my udev tree)

So I'm going to rebuild the udev-167-6 srpm that F15 is using (with that patch) add that rule, and get back to you.

Comment 26 Solomon Peachy 2011-10-05 01:06:18 UTC
Okay, with the rule in comment 23, my new-sk00l CF cards act the same way as the old ones -- They're no longer being treated as system_internal and I can mount them without being prompted for the root password.

None of cards aren't being auto-mounted still though, but I suppose that's specified elsewhere.

Comment 27 Solomon Peachy 2011-10-05 01:30:25 UTC
I added ENV{UDISKS_AUTOMOUNT_HINT}="always" to the rule in comment 23, but the system is ignoring the hint.  (without that explicit rule, there's no hint at all according to udisks --show-info)

Any pointers on where to go to enable automounting?

Comment 28 Jim Cromie 2012-02-13 20:58:44 UTC
Is upgrade of udev to 174 scheduled for F-16 ?
Its currently at 173, so we're close.
If not, will it be in F-17 ?

Im having trouble getting a working image of voyage onto my CF,
and am hoping this fix will resolve my issues.

FWIW, when I try to "safely unmount drive" in Nautilus,
it appears to flush all the writes to the CF
(a dialog box briefly appears, but closes before I can
read the entire message), but the boot fails early in
the grub-boot, without error messages, and does a bios reboot.

Im getting further afield here (sorry), but running sync
before "safely unmounting" doesnt help.

thanks

Comment 29 Solomon Peachy 2012-06-03 02:55:14 UTC
I'm happy to report that F17 JustWorks(tm), and I can finally use my ExpressCard CF reader without jumping through any extra hoops.

Comment 30 Jim Cromie 2012-06-13 05:24:54 UTC
for me it "mostly works".  It is automounting CF when I plug it in,
unmounting when I click eject (and popups a "writing to CF" notification),
and successfully remounting when I yank and reinsert the CF (that remount
is the critical improvement).

But my trouble is with writing a Voyage image to the CF:
I use the usr/local/sbin/voyage.update script thats in the distro,
but it complains when the disk is already mounted, so I unmount
it manually:  
1st I tried this using eject button, but that caused /dev/sdc1 to
disappear, which the script needs in order to do its own mount.
2nd try, I did sudo umount /mnt/cf before running script, and
everything seemed to go smoothly, but I cannot cleanly eject the CF,
it doesnt show up under Places, MyComputer, and manual umount 
fails as follows:

[jimc@groucho voyage-current]$ sudo umount /mnt/cf
umount: /mnt/cf: target is busy.
        (In some cases useful info about processes that use
         the device is found by lsof(8) or fuser(1))

[jimc@groucho voyage-current]$ sudo fuser -auvim /mnt/cf
                     USER        PID ACCESS COMMAND
/mnt/cf:             root     kernel mount (root)/mnt/cf

[jimc@groucho voyage-current]$ sudo lsof | grep /mnt/cf
lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /run/user/jimc/gvfs
      Output information may be incomplete.

[jimc@groucho voyage-current]$ mount | grep sdc
/dev/sdc1 on /mnt/cf type ext2 (rw,relatime,seclabel)


Can I get some advice ?

Comment 31 David Zeuthen 2012-06-13 12:53:13 UTC
(In reply to comment #30)
> for me it "mostly works".  It is automounting CF when I plug it in,
> unmounting when I click eject (and popups a "writing to CF" notification),
> and successfully remounting when I yank and reinsert the CF (that remount
> is the critical improvement).
> 
> But my trouble is with writing a Voyage image to the CF:
> I use the usr/local/sbin/voyage.update script thats in the distro,
> but it complains when the disk is already mounted, so I unmount
> it manually:  
> 1st I tried this using eject button, but that caused /dev/sdc1 to
> disappear, 

The eject button in GNOME causes "eject /dev/sdc" to be run (as root) which causes the partition to disappear. This is expected (it's what ejecting means).

Just run 'umount /dev/sdc1' yourself from a terminal if you only want to unmount the device.

> which the script needs in order to do its own mount.
> 2nd try, I did sudo umount /mnt/cf before running script, and
> everything seemed to go smoothly, but I cannot cleanly eject the CF,
> it doesnt show up under Places, MyComputer, and manual umount 
> fails as follows:

This is also expected, GNOME will only show mounts in /media, /run/media/$USER or $HOME (and /mnt/cf is not one of those).

For more details on what is shown in the desktop user interface in F17  and onward, see

 http://git.gnome.org/browse/gvfs/tree/monitor/udisks2/what-is-shown.txt

Comment 32 Fedora End Of Life 2012-08-06 20:00:08 UTC
This message is a notice that Fedora 15 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 15. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

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

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 15 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

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

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 33 Fedora End Of Life 2012-08-06 20:00:51 UTC
This message is a notice that Fedora 15 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 15. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

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

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 15 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

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

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping