Crash & reboot after pkg add...

jb82 said:
Findings,
a) A bad memory seems unlikely since an overnight UEFI-based memory test on the ECC modules showed PASSED.
b) I already collected other crashdumps, screenshot above therefore is not the only clue
c) It has nothing to do with pkg, vscode or whatsoever. I won't change the title though. It seems to be a generic issue, either HW, or ZFS related.
d) At the time of screenshoting that, I did have dumpdev = "NO", that's why I took the picture. Now, I have proper crash dumps.
e) The HW is Lenovo P1 Gen 2, Intel(R) Xeon(R) E-2276M, 64 GB RAM ECC modules, NVME SAMSUNG MZVLB1T0HBLR-000L7 5M2QEXF7 1 TB.

It's hard to reproduce but I've already had ~5 such events in the last two weeks.
Click to expand...
So much for the “hardware is absolutely stable” claim.

A laptop with ZFS and an nvme drive. I’m surprised it works at all. People keep pretending FreeBSD is a desktop OS and it’s just not.
 
Barney said:
So much for the “hardware is absolutely stable” claim.

A laptop with ZFS and an nvme drive. I’m surprised it works at all. People keep pretending FreeBSD is a desktop OS and it’s just not.
Click to expand...
Come on. It is. It's absolutely fine to use FreeBSD on consumer HW and frankly, Xeon + ECC is a step forward into the solid HW realm.
 
jb82 said:
Come on. It is. It's absolutely fine to use FreeBSD on consumer HW and frankly, Xeon + ECC is a step forward into the solid HW realm.
Click to expand...
“absolutely fine” except when it crashes every couple of days and you waste hours of your time trying to figure it out
Cath O'Deray said:
good enough
Click to expand...
“Good Enough” is the point. Why deal with it when you can just run something that that doesnt struggle to just work ok?
 
Not sure why people obsess about the HW while it is quite clear that it's a ZFS problem.
Either a code bug or something unexpected on disk.
The crash is a classic NULL pointer dereference.

The best way forward is to open a FreeBSD problem report with the debug information.
A GitHub issue for openzfs/zfs repo could also help.
 
Andriy said:
Not sure why people obsess about the HW while it is quite clear that it's a ZFS problem.
Either a code bug or something unexpected on disk.
The crash is a classic NULL pointer dereference.

The best way forward is to open a FreeBSD problem report with the debug information.
A GitHub issue for openzfs/zfs repo could also help.
Click to expand...
I've been pretty certain about that from the very beginning. I just like to please more senior people in this forum. :cool: (kidding ofc, but yeah, it's obviously a bug)
 
Out of curiosity, how large is your system's swap partition/file? Did the page fault panic start only after an initial crash trying to process the vscode pkg or did this occur on your system beforehand?
 
Kubitz said:
Out of curiosity, how large is your system's swap partition/file? Did the page fault panic start only after an initial crash trying to process the vscode pkg or did this occur on your system beforehand?
Click to expand...
Machine is 64 GB RAM, right after the first crash I increased my dumpdev to 80 GB.
 
Barney said:
“Good Enough” is the point. Why deal with it when you can just run something that that doesnt struggle to just work ok?
Click to expand...

It's behind you.pngThe struggle makes me forget where I left my flipchart easel. Or does it?
 
You must log in or register to reply here.
Back
Top