Firewire drive disconnects after ~ 1 hour while lid is closed

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Connect external drive via firewire.
2 (optional). Run i/o heavy task (ex. badblocks -w)
3. Close the lid.
4. Wait ~ 1 hour (maybe less).
5. Drive disconnects and won't wake-up until reconnect/reboot.

What is the expected output? What do you see instead?

Expected: closing the lid does not affect firewire drive.
Instead: firewire drive stops responding.

What version of the product are you using? On what operating system?
(if you don't know how to get a version number, enter "kextstat|grep -i
no sleep" in Terminal.app, without quotes)

MacBookPro8,2
Mac OS X 10.9.5
com.protech.NoSleep (1.3.3) <5 4 3>

Please provide any additional information below.

Hello and thank you for a nice tool for preventing my mac from sleep. 
Definitely required if mac works like iTunes music player, for example.

Recently I bought external HDD for Time Machine. And being suspicious one, I 
decided to test it, of course. So I ran:
> sh-3.2# /usr/local/Cellar/e2fsprogs/1.42.11/sbin/badblocks -vsw -o 
/Users/apollov/badblocks /dev/disk2
And after some activity closed the lid. After some time I decided to look how's 
it going. I saw something like:
> Checking for bad blocks in read-write mode
> From block 0 to 1953514582
> Testing with pattern 0xaa:   0.70% done, 1:19:53 elapsed. (0/0/0 errors)
I mentioned, that the drive was really quiet (no sounds at all) and progress 
stalled: even time stopped ticking.
I tried to restart a process:
> ^C^C^C
With no success. I tried to kill a process with
> kill -TERM $BADBLOCKS_PID
No changes. So, let's force:
> kill -KILL $BADBLOCKS_PID
No effect.
After an hour bad blocks responded:
> 0.70% done, 2:35:19 elapsed. (0/0/0 errors)
But has not exited. And the more I tried to access the drive - the more 
sluggishly my system became. I thought I've to reboot - but disconnecting the 
drive was enough to get rid of hangs etc.
After some thinking and messing around I've decided to repeat the test, but via 
USB-2.0. Everything went smooth there: full-disk write, than read - no problem. 
So, the drive is OK. I started thinking that my FireWire may be faulty.
After some more time I was dawned that maybe closing the lid is the key, so I 
ran a test with lid open. As you may guess, it was successful.
Maybe I'm in the wrong way writing a bug report here - but I guess that if it's 
NoSleep that is responsible for not-going-to-sleep-when-lid-gets-closed, maybe 
it is the thing that may be related :)
So, that's the story :)

Original issue reported on code.google.com by Apoll...@gmail.com on 6 Oct 2014 at 11:47

Attachments:

• dmesg.log

[GoogleCodeExporter]

Update:

Today I tried this:
1. Turn drive sleep off in Settings.app
2. Reboot (to be sure).
3. date && /usr/local/Cellar/e2fsprogs/1.42.11/sbin/badblocks -vsw -o 
/Users/apollov/badblocks /dev/disk3 2>&1 | tee /Users/apollov/badblocks.log
4. Close the lid.

Now it hung after 12:35:15 of work.

And in Console.app I see interesting logs about time of stop:

DiagnosticMessages/2014.10.08.asl:
Oct  8 01:08:52 apollov-macbook nbagent[37469] <Error>: INSERT-HANG-DETECTED: 
Tx time:4.282700, # of Inserts: 0, # of bytes written: 0, Did shrink: NO

system.log
Oct  8 01:08:46 apollov-macbook nbagent[37469]: XPC Activity invoked with 
state=0
Oct  8 01:08:46 apollov-macbook nbagent[37469]: XPC Activity invoked with 
state=2
Oct  8 01:08:53 apollov-macbook sandboxd[208] ([37488]): nbstated(37488) deny 
ipc-posix-shm-read-data com.apple.AppleDatabaseChanged

powermanagement/2014.10.08.asl:
Oct  8 01:09:19 apollov-macbook powerd[16] <Notice>: PID 37468(AddressBookSour) 
Released PreventUserIdleSystemSleep "Address Book Source Sync" 00:00:34  
id:0x10000263d [System: DeclUser BGTask kDisp]
Oct  8 01:09:19 apollov-macbook powerd[16] <Notice>: PID 547(UserEventAgent) 
Released BackgroundTask "com.apple.AddressBook.ScheduledSync" 00:00:34  
id:0xc0000263e [System: DeclUser kDisp]

Maybe it's unrelated, but App store started updates near that time.

Original comment by Apoll...@gmail.com on 8 Oct 2014 at 8:54

[GoogleCodeExporter]

Oh, I've forgotten to attach bad blocks.log :)

Original comment by Apoll...@gmail.com on 8 Oct 2014 at 8:56

Attachments:

• badblocks.log