Bug 249147 - [ZFS][Panic]Fatal trap 18 on boot after OpenZFS import
Summary: [ZFS][Panic]Fatal trap 18 on boot after OpenZFS import
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-fs (Nobody)
URL:
Keywords: crash, regression
Depends on:
Blocks:
 
Reported: 2020-09-06 08:55 UTC by Tomoaki AOKI
Modified: 2022-10-12 00:49 UTC (History)
2 users (show)

See Also:

Attachments
Trap screen sample (1.60 KB, text/plain)
2020-09-06 08:55 UTC, Tomoaki AOKI 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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!