Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Crash and reboot on Mavericks with 74.3.2 #129

Closed
GoogleCodeExporter opened this issue Oct 10, 2015 · 23 comments
Closed

Crash and reboot on Mavericks with 74.3.2 #129

GoogleCodeExporter opened this issue Oct 10, 2015 · 23 comments
Labels
auto-migrated Hackintosh Priority-Medium Type-Defect

Comments

@GoogleCodeExporter
Copy link 

What steps will reproduce the problem?
1 Installed latest version of Mavericks (+ 10.9.1) on Mac Pro.
2 I have a mirror of pair 2TB WD Green since 10.7 and 74.1.0 MacZFS release.
3 I updated to latest version of MacZFS v.74.3.2
4 after update every start right in login window i have a short hang and then 
machine rebooted immediately


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

Expected output is normal mounting and operating of pool in OS.

What version of the product are you using? On what operating system?

OS X 10.9.1 (13B40) with MacZFS 74.3.2

Please provide any additional information below.

The pool is normally working on previous version 74.3.0

If need something else, let me know.

Original issue reported on code.google.com by armdnl...@gmail.com on 9 Dec 2013 at 6:33

Attachments:
@GoogleCodeExporter
Copy link
Author 

Thanks for the report.  I looked at your three logs, but the information is not 
conclusive.  At least the "zfs_crash_log.rtf" hints at a version conflict: Is 
it possible that you have a mixture of different MacZFS / ZEVO / ZFS-OSX 
installations?  Note that MAcZFS-74.3.2 is incompatible to MacZFS-74.3.1 and 
earlier.  This unfortunate change was necessary due to a serious bug in the 
IOCTL interface.  Running for example the zfs tool from 74.3.2 against a 74.3.1 
kext will produce a Panic and the opposite combination will crash the zfs 
binary.

Questions:

Can you provide the output (if any) produced by "grep -e zfs 
/var/log/system.log" (run in terminal)?

Can you see if there are panic reports generated under 
"/Library/Logs/DiagnosticReports"?  If yes, then I like to see one related to 
one of the unexpected reboots.

Original comment by googlelogin@bjoern-kahl.de on 10 Dec 2013 at 9:14

@GoogleCodeExporter
Copy link
Author 

I have the exact same issue, I did install Zevo before I realized it wasn't 
compatible but uninstalled it with their uninstaller immediately.  I'll try and 
gather the requested logs and post them.

Original comment by dw...@erbco.com on 14 Dec 2013 at 5:14

@GoogleCodeExporter
Copy link
Author 

Sorry, I little more info, I am running v74.3.2b.  Also it works fine and can 
import the pool when I first install it, it's only once I reboot that it hangs.

Original comment by dw...@erbco.com on 14 Dec 2013 at 5:20

@GoogleCodeExporter
Copy link
Author 

Okay, so there are no panics under Library/Logs/DiagnosticReports.  Attached is 
the gripped system.log but there doesn't seem to be anything around 12:20 which 
is when the freeze occurred.  Any other logs or info I can provide?

Thanks.

Original comment by dw...@erbco.com on 14 Dec 2013 at 5:34

Attachments:

@GoogleCodeExporter
Copy link
Author 

Here is what is reported in the logs for the freeze.  Note, if I remove 
zfs.kext then it will boot just fine.

Original comment by dw...@erbco.com on 14 Dec 2013 at 5:37

Attachments:

@GoogleCodeExporter
Copy link
Author 

Sorry about delay. I just upgraded from 74.3.0 to 74.3.2 and had this troubles. 
Logs is seems already wiped by the system... But no ZEVO or ZFS-OSX were 
installed earlier. Only MacZFS.

Original comment by armdnl...@gmail.com on 18 Dec 2013 at 7:01

@GoogleCodeExporter
Copy link
Author 

Yeah, I've been pulling my hair our trying to figure out a solution.  I even 
tried loading the zfs.kext after boot by using launchd but that froze as well, 
although if I log in and load the kext manually it works fine.  So it seems 
like zfs.kext will panic the system if no one is logged in, at least that's my 
working theory.  I also tried pulling my SiI3124 to make sure that wasn't 
causing the issue but it still froze.  Any other information I can offer to the 
gurus behind maczfs?  I think my next step is to try 74.3.2 on my old snow 
leopard install to see if it's an issue specifically with Mavericks.

Original comment by dw...@erbco.com on 18 Dec 2013 at 7:14

@GoogleCodeExporter
Copy link
Author 

Thanks for the updated report.
Unfortunately this is still a big mystery for me.

@armdnlife:
Your original report mentioned 74.3.2, but your new comment #6 says you just 
upgraded from 74.3.0 to 74.3.2.  Had you downgraded in between?

Also, did the problem only exists with 74.3.2 or also with 74.3.0?


@dwebb:
You say it "froze".  As far as I know, Mac OSX isn't supposed to freeze, 
instead it should sooner than later do an automatic reboot (thought I might 
confuse server and desktop here).  Can you be more specific how the state 
"frozen" shows itself?  Does the display / mouse pointer stops responding?  
Does it still react on special keys like volume control (if the Mac Pro has 
such)?

Related question: Do you have a second machine to try and "ping" the frozen 
box?  If you have, does it still respond to ping packets?  If it does, could 
you try to SSH into the box?  (For SSH to work, you have to enable it under 
"Sharing", it is called "remote login" or "remote access" or something similar 
(I have a German MacbookPro, no idea how Apple called that option in the 
English Mac OSX version)).  If you can SSH into the box, is "ps -fax" or 
"kextstat" showing anything related to MacZFS while the machine is in the 
"frozen" state?

Original comment by googlelogin@bjoern-kahl.de on 18 Dec 2013 at 8:14

@GoogleCodeExporter
Copy link
Author 

Sorry, should have been more specific, I'm on a hackintosh so I think I have it 
set not to reboot by default.  Mouse is frozen and caps lock doesn't respond.  
I will try pinging it but I'm fairly certain it is frozen solid.  Sometimes it 
will actually write the panic info to the screen, I have a screenshot of that 
attached.

Original comment by dw...@erbco.com on 18 Dec 2013 at 9:34

Attachments:

@GoogleCodeExporter
Copy link
Author 

@dwebb: Thanks for the screenshot.

It shows the same backtrace as in issue #126.  Since issue #126 is also on a 
Hackintosh, I am inclined to (1) mark this as duplicate of 126 and (2) tag both 
as hackintosh related.

Original comment by googlelogin@bjoern-kahl.de on 18 Dec 2013 at 9:54

  • Added labels: Hackintosh

@GoogleCodeExporter
Copy link
Author 

@armdnlife:
Your original report mentioned 74.3.2, but your new comment #6 says you just 
upgraded from 74.3.0 to 74.3.2.  Had you downgraded in between?

Also, did the problem only exists with 74.3.2 or also with 74.3.0?

I'm not on a Hackintosh, i have a Mac Pro 2008...
Also 74.3.0 is out of troubles. Only 74.3.2 has this problem. I downgraded back 
and all works good now.

Original comment by armdnl...@gmail.com on 21 Dec 2013 at 7:15

@GoogleCodeExporter
Copy link
Author 

Interesting, so 74.3.0 works with Mavericks?  Is it only the installer that is 
broken?  If it's safe to downgrade then I will give that a try.

Original comment by dw...@erbco.com on 21 Dec 2013 at 5:19

@GoogleCodeExporter
Copy link
Author 

The MacZFS-74.3.0. installer is not "broken", it has a deliberate protection 
against installing on 10.9 and above, since at the time it was made we could 
not know if 10.9 would break any important kernel interfaces.

The functionality (and code implementing it) is identical within 74.3.x line.

The only and important code difference between 74.3.0 and 74.3.2 is an added 
protection against using user land tools (zfs and zpool) of one release or 
implementation against the kernel part (zfs.kext) of a different release or 
implementation.

At least some (but not all) of the problems reported against 74.3.2 were caused 
by mixing old user land tools with a new kext and vice versa.

Original comment by googlelogin@bjoern-kahl.de on 21 Dec 2013 at 5:30

@GoogleCodeExporter
Copy link
Author 

Okay, thanks for the info.  I decided to give the old version (74.3.0) a try, I 
installed it with pacifist and it worked!  So there has to be something in 
those changes causing issues on my system.  Thanks for the tip armdnlife.  
Bjoern, if you need me for testing then let me know.

Thanks.

Original comment by dw...@erbco.com on 22 Dec 2013 at 10:49

@GoogleCodeExporter
Copy link
Author 

Okay, I have more information.  I still have an issue using 74.3.0.  If I copy 
files to the zpool using the finder I get a kernel panic.  Copying files from 
the zpool works fine and copying using the terminal works fine.  I then 
upgraded again to 74.3.2, moved zfs.kext out of /S/L/E and manually loaded it 
after login with kextload and had the exact same problems.  I then upgraded my 
Snow Leopard install from 74.1.0 to 74.3.2 and had no issues.  So it seems like 
I am having Finder based issues specifically on Mavericks, at least with 74.3.* 
 I do have some files in /Library/Logs/DiagnosticRoports now, may be because I 
have enabled nvram like Stuart mentioned in #126.

Let me get my logs and screenshots in order and I will upload those shortly.

Original comment by dw...@erbco.com on 5 Jan 2014 at 5:50

@GoogleCodeExporter
Copy link
Author 

This may be only happening when copying from an external USB drive.  I'm doing 
more testing on that.  It works fine in Snow Leopard though.

Logs...

There were multiple copies of this quad.crash logs grouped at 11:30, 11:31 and 
11:48.  I checked the installed version of libzfs.dylib and the 74.3.2 packaged 
version and the creation date matched.  I also have a libzpool.dylib which I 
can't find in the 74.3.2 package, should I remove this?

Looks like the freeze occurred around 11:45.  The screenshot is from a previous 
freeze.

Original comment by dw...@erbco.com on 6 Jan 2014 at 5:15

Attachments:

@GoogleCodeExporter
Copy link
Author 

So all of my problems seem to only happen with 1 external USB drive.  Problem 
was it was the drive I was using to test Mavericks.  Other USB drives don't 
seem to be affected, although I've only tested this theory with a couple of 
thumbdrives.  Now that I have moved mavericks from the USB drive to my internal 
Apple Raid it boots just fine using 74.3.2  That drive does work fine though in 
Snow Leopard with 74.3.2.  Thanks for the help and the great project.  If you 
want more info or troubleshooting then let me know.

Original comment by dw...@erbco.com on 9 Jan 2014 at 2:59

@GoogleCodeExporter
Copy link
Author 

I'm pretty much crashing on demand.  It's always 'git' that causes my crash, 
very easily when trying to clone.

e.g., this command reboots my computer:

    git clone git://github.com/dustin/yellow.git


Anonymous UUID:       716F8321-0FDF-C634-0CB0-5C5C3A6F43CD

Sat Jan 11 14:51:32 2014
panic(cpu 1 caller 0xffffff800d4dc19e): Kernel trap at 0xffffff800d5fb054, type 
14=page fault, registers:
CR0: 0x0000000080010033, CR2: 0x00000000000000d0, CR3: 0x00000000a435a000, CR4: 
0x0000000000000660
RAX: 0x0000000000000000, RBX: 0x0000000000000000, RCX: 0xffffff800dae2b20, RDX: 
0xffffff80271ef0f0
RSP: 0xffffff80fcb23c20, RBP: 0xffffff80fcb23c20, RSI: 0x0000000000000002, RDI: 
0x0000000000000000
R8:  0xffffff80ff190888, R9:  0xffffff80fcb23cb6, R10: 0x0000000000000000, R11: 
0x0000000000000206
R12: 0xffffff80271921e0, R13: 0xffffff8023f312a0, R14: 0xffffff80fcb23d98, R15: 
0xffffff8023285ef8
RFL: 0x0000000000010246, RIP: 0xffffff800d5fb054, CS:  0x0000000000000008, SS:  
0x0000000000000010
Fault CR2: 0x00000000000000d0, Error code: 0x0000000000000000, Fault CPU: 0x1

Backtrace (CPU 1), Frame : Return Address
0xffffff80fcb238b0 : 0xffffff800d422f69 
0xffffff80fcb23930 : 0xffffff800d4dc19e 
0xffffff80fcb23b00 : 0xffffff800d4f3606 
0xffffff80fcb23b20 : 0xffffff800d5fb054 
0xffffff80fcb23c20 : 0xffffff800d5e77f4 
0xffffff80fcb23f50 : 0xffffff800d83de23 
0xffffff80fcb23fb0 : 0xffffff800d4f3e06 

BSD process name corresponding to current thread: git

Mac OS version:
13B42

Kernel version:
Darwin Kernel Version 13.0.0: Thu Sep 19 22:22:27 PDT 2013; 
root:xnu-2422.1.72~6/RELEASE_X86_64
Kernel UUID: 1D9369E3-D0A5-31B6-8D16-BFFBBB390393
Kernel slide:     0x000000000d200000
Kernel text base: 0xffffff800d400000
System model name: Macmini4,1 (Mac-F2208EC8)

System uptime in nanoseconds: 354831821657
last loaded kext at 280145831661: org.maczfs.zfs.fs     74.3.2 (addr 
0xffffff7f8f7f9000, size 835584)
last unloaded kext at 138389069887: com.apple.driver.AppleMCP89RootPortPM       
1.11 (addr 0xffffff7f8f3a5000, size 24576)
loaded kexts:
org.maczfs.zfs.fs       74.3.2

Original comment by dsalli...@gmail.com on 11 Jan 2014 at 11:07

@GoogleCodeExporter
Copy link
Author 

I'm back again.  I was wrong about being wrong, it's not just the external USB 
drive.  It's continued to happen when copying files using finder (path finder 
seems to work fine though)  and iPhoto.  So it seems to be related to apple 
products only.  Next I want to try iMovie, although iTunes hasn't had any 
issues and its library is on my ZFS drive.  Also I think the reason it doesn't 
freeze on boot anymore is because my zpool isn't mounting anymore, I have to 
force the mount after login.

Original comment by dw...@erbco.com on 26 Jan 2014 at 3:22

@GoogleCodeExporter
Copy link
Author 

Here's info from collect-maczfs-state.  I see some zero packages but I don't 
think any of those are running.  Am I reading this right?

Original comment by dw...@erbco.com on 26 Jan 2014 at 5:10

Attachments:

@GoogleCodeExporter
Copy link
Author 

zevo packages

Original comment by dw...@erbco.com on 26 Jan 2014 at 5:11

@GoogleCodeExporter
Copy link
Author 

Same here with copy files from HFS+ to ZFS volume. But system will crash if 
copy apps from volume to volume using Finder. Here's report.

Original comment by armdnl...@gmail.com on 14 Feb 2014 at 4:27

Attachments:

@GoogleCodeExporter
Copy link
Author 

This issue report seems to cover two independent (fixed) problems:

1) At least the comments #18 (dsallings), #16 (dwebb) are the same as issue 120 
(fixed)
2) Comment #9 (dwebb) is same backtrace as issue 126 (fixed)

Therefore I close this as duplicate, picking 120 as reference since the latest 
comments #17, #19 and #22 all seem to relate to issue 120.

Original comment by googlelogin@bjoern-kahl.de on 15 Feb 2014 at 12:56

  • Changed state: Duplicate

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
auto-migrated Hackintosh Priority-Medium Type-Defect
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@GoogleCodeExporter