Description of problem: With Arjan's test kernels > 2.6.6-1.379, firewire works for my external hard drive enclosure. I can manually mount the drive after the machine boots; all the modules are there, autodetection of the enclosure works, all I have to do is to define the drive in /etc/fstab and issue the mount command. However, I can neither boot nor shut down cleanly with the firewire drive defined in /etc/fstab -- /dev/sdb1 /backup ext3 defaults,noauto 1 2 If I try to boot with this line in /etc/fstab, boot fails and drops me into the 'repair shell' login prompt because it can't find /dev/sdb because the boot sequence is looking at fstab before it loads the firewire modules. When I try to shut down, I get a long sequences of SCSI read errors, May 26 20:56:05 grithr kernel: ieee1394: sbp2: aborting sbp2 command May 26 20:56:05 grithr kernel: Read (10) 00 09 51 22 bf 00 00 80 00 May 26 20:56:05 grithr kernel: SCSI error : <1 0 0 0> return code = 0x8000002 May 26 20:56:05 grithr kernel: Current sdb: sense key Aborted Command May 26 20:56:05 grithr kernel: end_request: I/O error, dev sdb, sector 156312255 May 26 20:56:05 grithr kernel: Buffer I/O error on device sdb1, logical block 156312192 and the reboot process hangs around where shutdown should be completed. No reboot takes place until I poke the reset button. Version-Release number of selected component (if applicable): kernel-2.6.6-1.379 kernel-2.6.6-1.391 How reproducible: Always. Steps to Reproduce: 1. use a test kernel > 2.6.6-1.379 2. define a firewire drive in /etc/fstab and mount it 3. reboot Actual results: Shutdown hangs just prior to either power-off or rebooting. Reboot drops into 'repair shell' prompt when the boot sequence examines /etc/fstab before the firewire modules are loaded. Expected results: Clean booting and rebooting with the external firewire drive being mounted automatically as part of the boot sequence. Additional info:
With kernel-2.6.6-1.403 (also kernel-2.6.6-1.391), it's not having the firewire partition defined in /etc/fstab which is doing me in, it's having the firewire enclosure *connected*. (the definition in /etc/fstab then does me in because the boot sequence can't find the device and drops me into the repair shell.) With the enclosure connected and powered on, the boot sequence gets to 'mounting the root filesystem in read/write' mode and hangs. Similarly, 'shutdown now -r" gets to 'umounting filesystems' and hangs. Power it off, and the boot sequence proceeds normally. Power it back on after the machine has finished booting, and after May 30 22:23:17 grithr ieee1394.agent[3106]: ... no drivers for IEEE1394 product 0x/0x/0x May 30 22:23:17 grithr ieee1394.agent[3092]: ... no drivers for IEEE1394 product 0x/0x/0x May 30 22:23:17 grithr kernel: scsi1 : SCSI emulation for IEEE-1394 SBP-2 Devices May 30 22:23:18 grithr kernel: ieee1394: sbp2: Logged into SBP-2 device May 30 22:23:18 grithr kernel: Vendor: WDC WD80 Model: 0JB-00ETA0 Rev: May 30 22:23:18 grithr kernel: Type: Direct-Access ANSI SCSI revision: 06 May 30 22:23:18 grithr kernel: SCSI device sdb: 268435455 512-byte hdwr sectors (137439 MB) May 30 22:23:18 grithr kernel: sdb: asking for cache data failed May 30 22:23:18 grithr kernel: sdb: assuming drive cache: write through May 30 22:23:18 grithr kernel: sdb:SCSI error : <1 0 0 0> return code = 0x8000002 May 30 22:23:18 grithr kernel: Current sdb: sense key Aborted Command May 30 22:23:18 grithr kernel: end_request: I/O error, dev sdb, sector 268435448 May 30 22:23:18 grithr kernel: Buffer I/O error on device sdb, logical block 268435448 with the I/O errors repeating for that same logical block. I get an entirely live and sensible firewire external drive; e2fsck -f /dev/sdb1 gives the drive a clean bill of health, despite the buffer I/O errors. I'm not getting any log messages from the hang events, but the box will sit there for fifteen minutes without doing anything, not even blinking lights, until manually reset or powered off.
any luck with the errata kernel ?
Whups! I didn't keep proper track, but by kernel-2.6.8-1.541 this is certainly ok. (And it's still ok in kernel-2.6.9-1.640.)