Bug 175998
Summary: | Firewire iPod no longer mounts to desktop after upgrade to 2.6.14-1.1653_FC4 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | David Goldberg <david.goldberg6> |
Component: | hal | Assignee: | Dave Jones <davej> |
Status: | CLOSED DUPLICATE | QA Contact: | Brian Brock <bbrock> |
Severity: | low | Docs Contact: | |
Priority: | medium | ||
Version: | 4 | CC: | cweyl, davidz, dedourek, pfrields, ronny-rhbugzilla, stefan-r-rhbz, vlada, wtogami |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-02-19 04:56:31 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
David Goldberg
2005-12-17 03:05:37 UTC
This is what happens here. - On plug-in, nothing happens. - Doing su, modprobe sbp2: Dec 19 17:41:56 lembas su(pam_unix)[23609]: session opened for user root by (uid=531) Dec 19 17:42:05 lembas kernel: SCSI subsystem initialized Dec 19 17:42:05 lembas kernel: sbp2: $Rev: 1306 $ Ben Collins <bcollins> Dec 19 17:42:05 lembas kernel: ieee1394: sbp2: Driver forced to serialize I/O (serialize_io=1) Dec 19 17:42:05 lembas kernel: ieee1394: sbp2: Try serialize_io=0 for better performance Dec 19 17:42:05 lembas kernel: scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices Dec 19 17:42:07 lembas kernel: ieee1394: sbp2: Logged into SBP-2 device Dec 19 17:42:07 lembas kernel: Vendor: Apple Model: iPod Rev: 1.51 Dec 19 17:42:07 lembas kernel: Type: Direct-Access-RBC ANSI SCSI revision: 02 Dec 19 17:42:09 lembas su(pam_unix)[23609]: session closed for user root Dec 19 17:42:11 lembas kernel: sda: Spinning up disk.....ready Dec 19 17:42:11 lembas kernel: SCSI device sda: 19531260 512-byte hdwr sectors (10000 MB) Dec 19 17:42:11 lembas kernel: sda: test WP failed, assume Write Enabled Dec 19 17:42:11 lembas kernel: sda: asking for cache data failed Dec 19 17:42:11 lembas kernel: sda: assuming drive cache: write through Dec 19 17:42:11 lembas kernel: SCSI device sda: 19531260 512-byte hdwr sectors (10000 MB) Dec 19 17:42:11 lembas kernel: sda: test WP failed, assume Write Enabled Dec 19 17:42:11 lembas kernel: sda: asking for cache data failed Dec 19 17:42:11 lembas kernel: sda: assuming drive cache: write through Dec 19 17:42:11 lembas kernel: sda: sda1 sda2 Dec 19 17:42:11 lembas kernel: sd 0:0:0:0: Attached scsi removable disk sda Observe that udev worked (and block special files were created), but HAL didn't. However, I have no idea how a kernel update could have broken HAL. Maybe David knows (adding to cc:) Agree that udev works. I can manually mount the ipod. I'm not familiar with HAL, but I do see that I have it installed and enabled/running. But HAL version is the same (as is everything else) whichever kernel I use. All I'm doing to get back to 2.6.13 is selecting it from the grub menu. Right. It's not that HAL is broken, it's my inability to figure how exactly the kernel broke it. Maybe a symlink in /sys went from block to block:sda or something of such nature. this patch works for me Same problems here: I own iPod mini which I connect via firewire cable (original Apple firewire Dock cable). After it is connected, it shows up in dmesg and device nodes are created via udev and I can mount it successfully. Even ejecting the device (so the iPod does not display the 'Do not disconnect' message) works fine. However, HAL does nothing about it. I would expect it to add entry to /etc/fstab via fstab-sync(8) but nothing happens. I have installed following versions of relevant software: kernel-2.6.14-1.1656_FC4 hal-0.5.2-2 hal-cups-utils-0.5.3-3 udev-058-1.0.FC4.1 This issue might be related to the one discussed at: http://lists.freedesktop.org/archives/hal/2005-December/004065.html On my system the device is identified by: [root@erazim katka]# cat /sys/block/sdb/device/type 14 relevant dmesg entries: ieee1394: sbp2: Logged into SBP-2 device ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048] Vendor: Apple Model: iPod Rev: 1.62 Type: Direct-Access-RBC ANSI SCSI revision: 00 sdb: Spinning up disk......ready SCSI device sdb: 7999488 512-byte hdwr sectors (4096 MB) sdb: Write Protect is off sdb: Mode Sense: 00 04 00 00 sdb: asking for cache data failed sdb: assuming drive cache: write through SCSI device sdb: 7999488 512-byte hdwr sectors (4096 MB) sdb: Write Protect is off sdb: Mode Sense: 00 04 00 00 sdb: asking for cache data failed sdb: assuming drive cache: write through sdb: sdb1 sdb2 Attached scsi removable disk sdb at scsi3, channel 0, id 0, lun 0 Attached scsi generic sg1 at scsi3, channel 0, id 0, lun 0, type 14 I have no problems with sbp2 kernel module not being loaded. One more thing: this might be related to the following hal changelog (http://cvs.freedesktop.org/hal/ hal/ChangeLog?view=markup) entry: 2005-03-20 David Zeuthen <davidz> Teach hal about Firewire devices; tested with both my iPod and my Powerbook in Target Disk Mode * tools/device-manager/Const.py.in: Collapse ieee1394_host and ieee1394_node into ieee1394 * hald/linux2/physdev.c (ieee1394_add): New function (ieee1394_compute_udi): New function It is evident that ipod+firewire worked at some point for David Zeuthen. (adding to CC) This is a mass-update to all currently open kernel bugs. A new kernel update has been released (Version: 2.6.15-1.1830_FC4) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. Thank you. Still no joy in the 2.6.15-1.1830_FC4 kernel. Same symptoms. Kernel and udev do their thing, setting up the device files, but HAL does not set up fstab for it much less mount it. Manual mounting works, but is annoying. And it does still work if I back out to kernel-2.6.13-1.1532_FC4. As a data point my Firewire storage devices (CF card reader, Harddisk enclosure, no iPod after I upgraded to the nano :-) works fine on my Powerbook G4 12" 867Mhz using the built-in firewire port. They don't work on my IBM T41 using a PCCard Firewire adapter. This is actually a bug in hal, see link in comment 4. Can someone please change the component to hal, so we get a chance that this bug will be fixed? I have tried to update kernel 2.6.14-1.1653_FC4 to kernel-2.6.15-1.1830_FC4 and it just corrupted my GDM login screen two seconds after it appeared on the screen. I opened this with the component set to kernel because it was a kernel upgrade that triggered the situation (no other changes, as noted in the original post). However, I've seen enough in the comments to suggest this is really an issue with Hal, so I'm setting the component to that now. I apologize in advance if that violates any proper procedure. David's initial assessment that this was a kernel issue is correct in its own right: The SCSI kernel subsystem maintainers moved RBC handling into a proper place (from sbp2 which mapped RBC disks to normal disks to sd_mod, the actual command-set specific driver). Along the way they changed a sysfs attribute of such devices, thereby broke the kernel's interface to userspace. This will not be reverted. Instead, userspace tools like hotplug scripts or hal which evaluate the sysfs attribute "type" of SCSI devices need to be adapted. Hence it was correct to move this bug to the component "hal". This is actually a duplicate of bug 174723. *** This bug has been marked as a duplicate of 174723 *** |