Bug 251401
|
Description
David Ponce
2007-08-08 18:49:26 UTC
I can confirm this bug... Is there a workaround? [neugens@nirvana neugens]$ uname -r 2.6.22.1-41.fc7 [neugens@nirvana neugens]$ rpm -q udev udev-113-9.fc7 Reverting to udev-113-8 does not solve. While I don't think it maybe of any help, my camera is also a Nikon DSLR. It worked fine just a couple of days ago (before the udev update). Just an additional note, switching back to udev-106-4.1.fc7 seems to solve, like David suggested, but of course it causes some other troubles (for example, I'm unable to connect to the net with NetworkManager unless I set "allow users to enable this device bla bla" in network config). please attach the output of $ ls -lR /dev/ for both udev versions Sure, with and without camera. If you need more tests please tell me. Created attachment 160970 [details]
output of ls -lR /dev/ udev-106
Without camera attached
Created attachment 160971 [details]
output of ls -lR /dev/ udev-106
With camera
Created attachment 160972 [details]
output of ls -lR /dev/ udev-113
Without camera attached
Created attachment 160973 [details]
output of ls -lR /dev/ udev-113
With camera attached
try this with the new udev: # mv /etc/udev/rules.d/60-persistent-storage.rules \ /etc/udev/rules.d/60-persistent-storage.rules.bak and replug the cam Yeah, now it works fine.
[root@nirvana neugens]# rpm -q udev
udev-113-9.fc7
tail -f /var/log/messages
Aug 9 18:50:04 nirvana kernel: usb 5-1: new high speed USB device using
ehci_hcd and address 8
Aug 9 18:50:04 nirvana kernel: usb 5-1: configuration #1 chosen from 1 choice
Aug 9 18:50:04 nirvana kernel: scsi10 : SCSI emulation for USB Mass Storage devices
Aug 9 18:50:09 nirvana kernel: scsi 10:0:0:0: Direct-Access NIKON D40
1.10 PQ: 0 ANSI: 2
Aug 9 18:50:09 nirvana kernel: sd 10:0:0:0: [sdc] 4022273 512-byte hardware
sectors (2059 MB)
Aug 9 18:50:09 nirvana kernel: sd 10:0:0:0: [sdc] Write Protect is off
Aug 9 18:50:09 nirvana kernel: sd 10:0:0:0: [sdc] Assuming drive cache: write
through
Aug 9 18:50:09 nirvana kernel: sd 10:0:0:0: [sdc] 4022273 512-byte hardware
sectors (2059 MB)
Aug 9 18:50:09 nirvana kernel: sd 10:0:0:0: [sdc] Write Protect is off
Aug 9 18:50:09 nirvana kernel: sd 10:0:0:0: [sdc] Assuming drive cache: write
through
Aug 9 18:50:09 nirvana kernel: sdc: sdc1
Aug 9 18:50:09 nirvana kernel: sd 10:0:0:0: [sdc] Attached SCSI removable disk
Aug 9 18:50:09 nirvana kernel: sd 10:0:0:0: Attached scsi generic sg3 type 0
Aug 9 18:50:10 nirvana hald: mounted /dev/sdc1 on behalf of uid 500
(In reply to comment #10) > try this with the new udev: > > # mv /etc/udev/rules.d/60-persistent-storage.rules \ > /etc/udev/rules.d/60-persistent-storage.rules.bak > > and replug the cam That works now! ? rpm -q udev udev-113-9.fc7 /var/log/messages : Aug 9 19:31:43 maunakea kernel: usb 5-6: new high speed USB device using ehci_hcd and address 5 Aug 9 19:31:43 maunakea kernel: usb 5-6: configuration #1 chosen from 1 choice Aug 9 19:31:43 maunakea kernel: scsi3 : SCSI emulation for USB Mass Storage devices Aug 9 19:31:48 maunakea kernel: scsi 3:0:0:0: Direct-Access NIKON D200 1.00 PQ: 0 ANSI: 2 Aug 9 19:31:48 maunakea kernel: sd 3:0:0:0: [sdb] 8005537 512-byte hardware sectors (4099 MB) Aug 9 19:31:48 maunakea kernel: sd 3:0:0:0: [sdb] Write Protect is off Aug 9 19:31:48 maunakea kernel: sd 3:0:0:0: [sdb] Assuming drive cache: write through Aug 9 19:31:48 maunakea kernel: sd 3:0:0:0: [sdb] 8005537 512-byte hardware sectors (4099 MB) Aug 9 19:31:48 maunakea kernel: sd 3:0:0:0: [sdb] Write Protect is off Aug 9 19:31:48 maunakea kernel: sd 3:0:0:0: [sdb] Assuming drive cache: write through Aug 9 19:31:48 maunakea kernel: sdb: sdb1 Aug 9 19:31:48 maunakea kernel: sd 3:0:0:0: [sdb] Attached SCSI removable disk Aug 9 19:31:48 maunakea kernel: sd 3:0:0:0: Attached scsi generic sg2 type 0 Aug 9 19:31:56 maunakea hald: mounted /dev/sdb1 on behalf of uid 500 It's likely a bug in the camera firmware which advertises a size of the blockdev which can't be accessed. It needs to worked around in the usb-storage module. HAL should cause the same problem with that device. Does the same error log appear if you run: /lib/udev/vol_id /dev/sdb or /lib/udev/vol_id /dev/sdb1 ? And if it does, please attach the vid-strace.log file of: strace -t -s 256 -o vid-strace.log /lib/udev/vol_id /dev/sdb Thanks! I'm not sure I understood, do you want "/lib/udev/vol_id /dev/sdb1" (sdc1 in my case) with the /etc/udev/rules.d/60-persistent-storage.rules files restored? In this case I get "/dev/sdc1: unknown volume type" But this is normal as the volume is not mounted. In the second case (60-persistent-storage.rules removed), this is the output of the command: ID_FS_USAGE=filesystem ID_FS_TYPE=vfat ID_FS_VERSION=FAT16 ID_FS_UUID=0860-3C1A ID_FS_UUID_ENC=0860-3C1A ID_FS_LABEL=NIKON D40 ID_FS_LABEL_ENC=NIKON\x20D40 ID_FS_LABEL_SAFE=NIKON_D40 I attach the log of the strace in both cases. Created attachment 161114 [details]
strace -t -s 256 -o vid-strace-failure.log /lib/udev/vol_id /dev/sdc1
This strace of the attempt to mount the Nikon D40 with udev 113 and the
/etc/udev/rules.d/60-persistent-storage.rules
Created attachment 161115 [details]
strace -t -s 256 -o vid-strace-mounted.log /lib/udev/vol_id /dev/sdc1
Same as 161114, but the /etc/udev/rules.d/60-persistent-storage.rules as been
removed, so the camera was mounted correctly.
Oh, vol_id does not try to mount, it just probes the strage device /dev/sdX for a filesystem, and the storage device always exists as long as the camera is connected, regardless if it is mounted or not. The result of vol_id is used to decide if the device will get automounted or not. Seems that your camera needs a fix not to get confused by reading the end of the device, after it has reported a broken size. See here: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/usb/storage/unusual_devs.h;hb=HEAD#l323 There is already a long list of Nikon's with that problem, and this device probably needs to be added to the list of devices with broken behavior. Alan, can you please have a look at: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=161114 and tell us if this USB storage device needs: US_FL_FIX_CAPACITY like all the other Nikon cameras? Thanks! This is interesting. Given the long list of Nikon camera there, I guess it's useless to bug Nikon to try to fix that in the firmware, right? Anyway, if I understand correctly, this will require a kernel update to work, in this case, can it be referenced in this bug, so that we know when the udev rules can be restored? Thanks a lot! They probably don't care, yes. The problem is that some RAID devices on Linux
use the last sector to mark a device as a RAID member, and we need to read that
sector to know if we need to ignore the device, otherwise we would mount devices
which belong to a RAID set and possibly destroy the data on the device. Maybe no
other operating system needs to read the last sectors ...
A possible fix would be added to the kernel, yes.
We can possibly limit the probing to partitions, and skip main block devices for
now. In:
/etc/udev/rules.d/60-persistent-storage.rules
we can change:
IMPORT{program}="vol_id --export $tempnode"
to:
ENV{DEVTYPE}=="partition", IMPORT{program}="vol_id --export $tempnode"
and it may work fine without disabling all the persistent naming. Could you
please try that? Thanks!
Yes, this works!! I attach the trivial patch for your reference. What are the effect of this patch on the system (other than making my camera work)? I ask because I suspect that this could impact somehow other usb storage devices, is it correct? It just skips the creation of links for unpartitioned devices. It should be fine. I'll put that in the default udev rules now, until we sorted that out. Regardless of that, usb-storage should proably get an entry for your device, but let's wait for Alan, he should know. Created attachment 161117 [details]
patch to /etc/udev/rules.d/60-persistent-storage.rules
Patch as suggested by Kay Sievers, allows Nikon usb cameras to be mounted.
ok, thanks a lot! The error messages in the opening report indicate that the problem began when the system tried to read the last sector of the camera, so the camera probably is reporting an incorrect size. Nikon might or might not care about fixing this. Most likely they buy their firmware from someone else (like Symbian, which has been supplying mass-storage firmwares with this bug for a long time although I believe they have fixed it now). In any case, they certainly can't correct it in devices which have already been made. Adding an unusual_devs entry for the D200 will be easy enough, but first I need to see more information. The camera's entry either in /proc/bus/usb/devices or in the output from "lsusb -v" would be enough. Hi!
Here is the data for the D40:
--- /proc/bus/usb/devices ---
T: Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 12 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=04b0 ProdID=0413 Rev= 1.10
S: Manufacturer=NIKON
S: Product=NIKON DSC D40
S: SerialNumber=6005246
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 2mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
--- lsusb -v ---
Bus 005 Device 012: ID 04b0:0413 Nikon Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x04b0 Nikon Corp.
idProduct 0x0413
bcdDevice 1.10
iManufacturer 1 NIKON
iProduct 2 NIKON DSC D40
iSerial 3 6005246
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 2mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
------------
I imagine that other Nikon cameras that share similar hardware (i.e. D40, D40x,
D200, D80) will have the same problem, but I have no way to tell that.
(In reply to comment #24) > The error messages in the opening report indicate that the problem began when > the system tried to read the last sector of the camera, so the camera probably > is reporting an incorrect size. > > Nikon might or might not care about fixing this. Most likely they buy their > firmware from someone else (like Symbian, which has been supplying mass-storage > firmwares with this bug for a long time although I believe they have fixed it > now). In any case, they certainly can't correct it in devices which have > already been made. > > Adding an unusual_devs entry for the D200 will be easy enough, but first I need > to see more information. The camera's entry either in /proc/bus/usb/devices or > in the output from "lsusb -v" would be enough. Hi! Here is the data for the D200: --- /proc/bus/usb/devices --- T: Bus=05 Lev=01 Prnt=01 Port=05 Cnt=01 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=04b0 ProdID=040f Rev= 1.00 S: Manufacturer=NIKON S: Product=NIKON DSC D200 S: SerialNumber=0000000 C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 2mA 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 --- lsusb -v --- Bus 005 Device 004: ID 04b0:040f Nikon Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x04b0 Nikon Corp. idProduct 0x040f bcdDevice 1.00 iManufacturer 1 NIKON iProduct 2 NIKON DSC D200 iSerial 3 0000000 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk (Zip) iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1 ------------ Thanks all for your support. Created attachment 161173 [details]
unusual_devs entries for NIKON D200 and D40
This patch contains entries for both types of camera.
udev-113-10.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report. udev-113-11.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report. udev-113-11.fc7 Works with my camera. I've just installed so I don't know if there are other problems with this version, but for now it seems to work fine. (In reply to comment #29) > udev-113-11.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report. It seems to work fine. Thanks! udev-113-11.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report. |