Bug 146855 - "Vantec 11in1 USB 2.0 UGT-CR912" not recognised
"Vantec 11in1 USB 2.0 UGT-CR912" not recognised
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-01 22:22 EST by Jamie Zawinski
Modified: 2013-03-05 22:42 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-02 01:10:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
hal debug logs (267.92 KB, text/plain)
2005-02-01 23:00 EST, Jamie Zawinski
no flags Details

  None (edit)
Description Jamie Zawinski 2005-02-01 22:22:01 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
I got a new card reader ("Vantec 11in1 USB 2.0 UGT-CR912",
http://www.vantecusa.com/) and when I put in a CF card, it doesn't get
a mount point created for it (as the card does with other readers.)  I
guess this is because hal is missing a .fdi file for this kind of
reader?  I tried to make one, but I must have been doing something wrong.

Here's what /proc/bus/usb/devices has to say about it:

T:  Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 11 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=058f ProdID=6362 Rev= 1.10
S:  Manufacturer=Generic
S:  Product=Mass Storage Device
S:  SerialNumber=058F312D81A
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=250mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms


It has slots for: CF/MD; SM; MS/MS-PRO; SD/MMC.
(I count 7, but they call it "11in1" -- beats me...)

I don't know which "lun" values correspond to each slot (if that's how
it works) because I only have CF cards to test with, not the other
types that it supports.

Let me know if you need any more info, or want me to test out a .fdi file.

Here's what I get when I plug it in (CF card already in place):

kernel: usb 1-4: new high speed USB device using ehci_hcd and address 16
kernel: scsi15 : SCSI emulation for USB Mass Storage devices
kernel:   Vendor: Generic   Model: USB SD Reader     Rev: 1.00
kernel:   Type:   Direct-Access                      ANSI SCSI
revision: 00
kernel: Attached scsi removable disk sda at scsi15, channel 0, id 0, lun 0
kernel:   Vendor: Generic   Model: USB CF Reader     Rev: 1.01
kernel:   Type:   Direct-Access                      ANSI SCSI
revision: 00
scsi.agent[18903]: disk at
/devices/pci0000:00/0000:00:13.2/usb1/1-4/1-4:1.0/host15/target15:0:0/15:0:0:0
kernel: SCSI device sdb: 4029984 512-byte hdwr sectors (2063 MB)
kernel: sdb: Write Protect is off
kernel: sdb: assuming drive cache: write through
kernel: SCSI device sdb: 4029984 512-byte hdwr sectors (2063 MB)
kernel: sdb: Write Protect is off
kernel: sdb: assuming drive cache: write through
kernel:  sdb: sdb1
kernel: Attached scsi removable disk sdb at scsi15, channel 0, id 0, lun 1
kernel:   Vendor: Generic   Model: USB SM Reader     Rev: 1.02
kernel:   Type:   Direct-Access                      ANSI SCSI
revision: 00
kernel: Attached scsi removable disk sdc at scsi15, channel 0, id 0, lun 2
kernel:   Vendor: Generic   Model: USB MS Reader     Rev: 1.03
kernel:   Type:   Direct-Access                      ANSI SCSI
revision: 00
kernel: Attached scsi removable disk sdd at scsi15, channel 0, id 0, lun 3
scsi.agent[19024]: disk at
/devices/pci0000:00/0000:00:13.2/usb1/1-4/1-4:1.0/host15/target15:0:0/15:0:0:3
scsi.agent[18949]: disk at
/devices/pci0000:00/0000:00:13.2/usb1/1-4/1-4:1.0/host15/target15:0:0/15:0:0:1
scsi.agent[18980]: disk at
/devices/pci0000:00/0000:00:13.2/usb1/1-4/1-4:1.0/host15/target15:0:0/15:0:0:2


Version-Release number of selected component (if applicable):
hal-0.4.7-1.FC3

How reproducible:
Always
Comment 1 David Zeuthen 2005-02-01 22:34:55 EST
Hi,

I have a page for things to report here

 http://freedesktop.org/wiki/Software_2fHalTraces

Initially it would be useful with the output of 'hald --daemon=no
--verbose=yes' from after you plug the device in but if any of the
other files (/etc/fstab or /var/log/messages) show useful information
do include it.

Also, does it work with manually mounting the device; e.g. 'mount -t
vfat /dev/sd[abcd]1 /media/somewhere'?

Thanks,
David
Comment 2 Jamie Zawinski 2005-02-01 23:00:23 EST
Created attachment 110541 [details]
hal debug logs

Yes, "mount /dev/sdb1 /tmp/foo" works.
Comment 3 David Zeuthen 2005-02-01 23:15:56 EST
It seems that your /etc/fstab file already contains several entries
for /dev/sdb1, right?. Thus, fstab-sync won't add any (from log "8479:
Could not add entry to fstab file: block device /dev/sdb1 already
listed").

Now, if your existing entries haven't got any of the options user,
users, pamconsole it's not possible for gnome-volume-manager to
automount the device, nor will Nautilus show any icons since an
unprivileged user cannot mount them.

Try removing your existing /etc/fstab entries for (at least) /dev/sdb1
and you should be all set; does that work?
Comment 4 Jamie Zawinski 2005-02-01 23:58:04 EST
Aha!  Yes, removing the /dev/sdb* entries in my fstab made it
auto-create the mount point.

It's not auto-mounting it, though -- does hal do that, or does
something else?  (I don't run nautilus.)
Comment 5 Jamie Zawinski 2005-02-01 23:59:16 EST
The thing that was confusing about this is that, while I was
experimenting with all the card readers I have (trying to see which
work) sometimes the mount point got created and sometimes it didn't. 
Maybe in that case, it was using something other than /dev/sdb,
because it thought it was still in use somehow?
Comment 6 David Zeuthen 2005-02-02 01:10:41 EST
> It's not auto-mounting it, though -- does hal do that, or does
> something else?  (I don't run nautilus.)

Yeah, for automounting you need to run gnome-volume-manager; it should
be started as part of gnome-session. You can even *shiver* configure
default actions through Applications -> Preferences -> Removable
Storage if you're running GNOME. On a stock GNOME FC3 install this is
set to sensible defaults - almost like the Mac most people seem to
tell you to use :-)  

(yes, it sucks UI-wise that you need to enter the paths of a program,
we'll fix that later to be dropdown menus but it requires changes to
the desktop-file fd.o spec, e.g. consensus with all the other desktop
projects. Sucks.) 

> The thing that was confusing about this is that, while I was
> experimenting with all the card readers I have (trying to see which
> work) sometimes the mount point got created and sometimes it didn't. 
> Maybe in that case, it was using something other than /dev/sdb,
> because it thought it was still in use somehow?

Yeah, it's totally arbritary what device file the kernel hands out;
when hald starts up it cleans up all the previously generated mount
points (unless something is mounted at them, but this is not the case
on reboots) because it uses the no-op mount option 'managed'.

Looking at your mount points for /dev/sdb1 they all began with /mnt so
they are not generated by fstab-sync (which hald invokes). 

And some USB card readers just doesn't work (though I think this is
improved in 2.6.10 compared to earlier 2.6 kernels) so there is little
hald can do about them since hald will only add mount points if it
finds a mountable file system. And this fs probing requires IO, e.g.
the device needs to work.

I'm going to close this bug since it appears the problem was resolved.

Cheers,
David

Note You need to log in before you can comment on or make changes to this bug.