Bug 1021745

Created attachment 814832 [details]
dmesg

Full dmesg attached. Relevant section:

[   33.807282] firewire_core 0000:0d:03.0: giving up on node ffc0: reading config rom failed: no ack
[   96.072733] systemd-journald[221]: Received request to flush runtime journal from PID 1
[   96.478365] type=1305 audit(1382402723.325:4): audit_pid=356 old=0 auid=4294967295 ses=4294967295
 subj=system_u:system_r:auditd_t:s0 res=1
[  118.371281] firewire_core 0000:0d:03.0: rediscovered device fw0
[  118.372169] firewire_core 0000:0d:03.0: phy config: new root=ffc1, gap_count=5
[  120.754321] firewire_core 0000:0d:03.0: phy config: new root=ffc1, gap_count=5
[  121.381853] firewire_core 0000:0d:03.0: created device fw1: GUID 001010054099f9c6, S400
[  121.394901] scsi6 : SBP-2 IEEE-1394
[  121.395374] firewire_sbp2 fw1.0: workarounds 0x2 (firmware_revision 0x000265, model_id 0x000201)
[  121.595818] firewire_sbp2 fw1.0: logged in to LUN 0000 (0 retries)
[  121.598224] scsi 6:0:0:0: Direct-Access     PI-145   1394/USB20 Drive 2.65 PQ: 0 ANSI: 0
[  121.599644] sd 6:0:0:0: Attached scsi generic sg3 type 0
[  121.600525] sd 6:0:0:0: [sdc] 1465149168 512-byte logical blocks: (750 GB/698 GiB)
[  121.601828] sd 6:0:0:0: [sdc] Write Protect is off
[  121.602659] sd 6:0:0:0: [sdc] Mode Sense: 10 00 00 00
[  121.603850] sd 6:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[  121.725513]  sdc: sdc1 sdc2 sdc3 sdc4
[  121.740001] sd 6:0:0:0: [sdc] Attached SCSI disk
[  122.598826] SELinux: initialized (dev sdc4, type hfsplus), uses genfs_contexts
[  571.708723] systemd-journald[221]: Received request to flush runtime journal from PID 1

Created attachment 814833 [details]
journalctl -b

Current boot journal.

Created attachment 814834 [details]
journalctl prior boot segment

Portion of most recent boot's poweroff sequence.

Hi Chris,

did the above use to work with older kernels or has this always been like this?
If we could pinpoint the kernel where this worked we could try and find
the change that broke things.

Thanks,
Michele

Hi Chris,

ping on comment # 4?

thanks,
Michele

Hi. I don't know if any older kernels behaved differently.

I have placed a FireWire 800 drive on this same computer, via FW800 cable, and it spins up between firmware initialization and the GRUB menu appearing. Interestingly, if I connect this drive with a FW400 cable (enclosure and computer have FW400 and FW800 ports) to see which behavior I get, the drive isn't assigned a /dev/ node at all.

[ 1164.943606] firewire_core 0000:0d:03.0: phy config: new root=ffc1, gap_count=5
[ 1165.459980] scsi6 : SBP-2 IEEE-1394
[ 1165.460264] firewire_core 0000:0d:03.0: created device fw1: GUID 0001d202006700a7, S400
[ 1165.673244] firewire_sbp2 fw1.0: logged in to LUN 0000 (0 retries)
[ 1186.783156] firewire_sbp2 fw1.0: sbp2_scsi_abort
[ 1186.784038] firewire_sbp2 fw1.0: sbp2_scsi_abort
[ 1186.918695] scsi 6:0:0:0: Device offlined - not ready after error recovery

With FW800 cable I get:

[ 1858.561306] scsi7 : SBP-2 IEEE-1394
[ 1858.562532] firewire_core 0000:0d:03.0: created device fw1: GUID 0001d202006700a7, S800
[ 1858.562605] firewire_core 0000:0d:03.0: phy config: new root=ffc0, gap_count=5
[ 1858.775039] firewire_sbp2 fw1.0: logged in to LUN 0000 (0 retries)
[ 1858.777477] scsi 7:0:0:0: Direct-Access-RBC ST332062 0A               3.AA PQ: 0 ANSI: 4
[ 1858.780293] sd 7:0:0:0: Attached scsi generic sg2 type 14
[ 1858.790098] sd 7:0:0:0: [sdb] 625142448 512-byte logical blocks: (320 GB/298 GiB)
[ 1858.790682] sd 7:0:0:0: [sdb] Write Protect is off
[ 1858.790731] sd 7:0:0:0: [sdb] Mode Sense: 11 00 00 00
[ 1858.791936] sd 7:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 1858.799939]  sdb: unknown partition table
[ 1858.812761] sd 7:0:0:0: [sdb] Attached SCSI disk


Considering FW800 drive spin-up happens before GRUB even appears, perhaps my expectation the kernel do this is wrong? I'm not sure what the expected behavior is, and whether this is instead a computer or enclosure firmware responsibility.

(In reply to Chris Murphy from comment #6)
This is with kernel-3.13.0-0.rc4.git0.1.fc21.x86_64

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.

Fedora 20 has now been rebased to 3.13.4-200.fc20.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

*********** MASS BUG UPDATE **************

This bug has been in a needinfo state for several weeks and is being closed with insufficient data due to inactivity. If this is still an issue with Fedora 20, please feel free to reopen the bug and provide the additional information requested.