Bug 249147

Summary: [ZFS][Panic]Fatal trap 18 on boot after OpenZFS import
Product: Base System Reporter: Tomoaki AOKI <junchoon>
Component: kernAssignee: freebsd-fs (Nobody) <fs>
Status: Closed FIXED    
Severity: Affects Only Me CC: emaste, freqlabs
Priority: --- Keywords: crash, regression
Version: CURRENT   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
Trap screen sample none

Description Tomoaki AOKI 2020-09-06 08:55:11 UTC
Created attachment 217787 [details]
Trap screen sample

Panic by fatal trap 18 on boot from ZFS root configuration.
Last bootable revision is r364744.

Panics on first reboot after installkernel (before installworld),
so loader.efi on the root pool is of r364744.

Panic screen is attached (typed up from photo, so possibly contain typo).

 *amd64 on ThinkPad P52, Core i7-8750H with descrete nvidia GPU.

 *2 independent root pools, one stable/12 on nvd0 and one head on ada0.

 *boot1.efi (as bootx64.efi) chain-boots loader.efi fine.

 *(Old)loader.efi seems to boot kernel fine, as bold and bright kernel output
  looks fine, and panics just the timing single user shell path input is required
  on usual single user boot.
Comment 1 Ryan Moeller freebsd_committer freebsd_triage 2020-09-07 15:50:33 UTC
Can you tell me what you have for kern.hz?
Comment 2 Tomoaki AOKI 2020-09-07 21:58:32 UTC
(In reply to Ryan Moeller from comment #1)

I have kern.hz="8192" (== 0x2000) in /boot/loader.conf, which worked fine for legacy ZoF implementation.

I can't recall whose post it was, but I've set so for quicker desktop responsiveness adviced on ML or web page.
Comment 3 Ryan Moeller freebsd_committer freebsd_triage 2020-09-07 22:25:52 UTC
Ok that's what I suspected. I have a PR to fix this pending upstream. Until that makes its way down, kern.hz=1000 will work.
Comment 4 Tomoaki AOKI 2020-09-08 10:51:14 UTC
(In reply to Ryan Moeller from comment #3)

That's it! Thanks.
Changing kern.hz to 1000 worked around the problem.

Looking forward to the real fix be committed.
Comment 5 Tomoaki AOKI 2020-09-19 06:40:07 UTC
(In reply to Ryan Moeller from comment #3)

Confirmed fixed at r365894. Thanks!