Project

General

Profile

Bug #14330

AFP- Accessing a time machine sparse bundle via AFP causes a kernel panic

Added by Andre McGlown over 4 years ago. Updated about 3 years ago.

Status:
Closed: Cannot reproduce
Priority:
No priority
Assignee:
Alexander Motin
Category:
OS
Target version:
Seen in:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Description

I have a reproducible kernel panic issue that occurs when I attempt to access a Time Machine sparse bundle over afp. The error exist in both the 9.10-Stable as well. I have included the crash dump and am not sure what additional debugging I should perform.

History

#1 Updated by Jordan Hubbard over 4 years ago

  • Assignee changed from Suraj Ravichandran to Chris Torek
  • Target version set to Unspecified

#2 Updated by Chris Torek over 4 years ago

  • Category changed from 78 to 200
  • Assignee changed from Chris Torek to Alexander Motin

The crash is in zfs, in (inlined) ddt_sync_entry (line 1054 reads:

                VERIFY(ddt_object_update(ddt, ntype, nclass, dde, tx) == 0);

) There is only one kind of ddt object, a ZAP entry, so clearly ddt_zap_update has returned an error.

The only way for it to return an error is for zap_update_uint64 to return an error but there are a bunch of paths here that can fail: zap_lockdir, zap_name_alloc_uint64, and fzap_update can all return errors. (In this case we can eliminate zap_name_alloc_uint64 since it uses KM_SLEEP, though.)

mav is way more familiar with this code than I am, so I'll hand this off to him at this point :-)

#3 Updated by Alexander Motin over 4 years ago

  • Status changed from Unscreened to Screened

No quick clues, unfortunately. Dedup is not my favorite area.

#4 Updated by Andre McGlown over 4 years ago

So the answer is disabling Deduplication and restoring data back to the pool? I am still getting random crashes.

#5 Updated by Jordan Hubbard over 4 years ago

This assert going off looks rather like a corrupted pool (does this system have ECC memory?). Suggest full backup of data and recreation of pool. Also check SMART status of drives, while you're at it (unlikely to be the issue here but might as well be comprehensive).

#6 Avatar?id=14398&size=24x24 Updated by Kris Moore about 4 years ago

  • Status changed from Screened to Closed: Cannot reproduce

Timing out

#7 Avatar?id=14398&size=24x24 Updated by Kris Moore about 3 years ago

  • Target version changed from Unspecified to N/A

#8 Updated by Dru Lavigne over 2 years ago

  • File deleted (config.txt)

#9 Updated by Dru Lavigne over 2 years ago

  • File deleted (ddb.txt)

#10 Updated by Dru Lavigne over 2 years ago

  • File deleted (panic.txt)

#11 Updated by Dru Lavigne over 2 years ago

  • File deleted (version.txt)

#12 Updated by Dru Lavigne over 2 years ago

  • File deleted (msgbuf.txt)

Also available in: Atom PDF