15:35:15 <Guest61> Hi, I ran into the problem here I believe: https://www.illumos.org/issues/16065 - How can I apply the attached patch? My system still keeps crashing, also with the line in /etc/system. Thanks!
15:35:17 <fenix> → BUG 16065: Panic in zfs_retzcbuf with smb2_read_zcopy enabled (In Progress) | https://code.illumos.org/c/illumos-gate/+/3164
15:38:18 <jbk> are you sure it's crashing with the same issue?
15:39:18 <Guest61> got this: panicstack = unix:die+c0 () | unix:trap+999 () | unix:cmntrap+e9 () | zfs:dmu_xuio_cnt+10 () | zfs:zfs_retzcbuf+16 () | genunix:fop_retzcbuf+71 () | smbsrv:smb_vop_retzcbuf+20 () | smbsrv:smb_fsop_retzcbuf+20 () | smbsrv:smb_xuio_free+70 () | smbsrv:smb2_read+55c () | smbsrv:smb2sr_work+38f () | smbsrv:smb2_tq_work+7a () |
15:39:18 <Guest61> genunix:taskq_d_thread+1fc () | unix:thread_start+b () |
15:40:22 <Guest61> and: panicstr = BAD TRAP: type=e (#pf Page fault) rp=fffffe00f72c06a0 addr=4 occurred in module "zfs" due to a NULL pointer dereference
15:40:42 <jbk> what distro are you running?
15:41:33 <Guest61> It was OI Hipster updated to newest version from time to time: "The illumos Project     illumos-2a6a1d830d      December 2023"
15:43:02 <jbk> after updating /etc/system, have you tried running `bootadm update-archive` and rebooting? AFAIK making the change via /etc/system (should be persistent) or mdb (non-persistent), should completely disable that code path
15:44:59 <jbk> running `mdb -ke 'smb2_read_zcopy/D'`  should show you the current value
15:45:47 <tobias61> not yet, did not know i had to do so. The mdb from thread gives me: mdb: failed to open smb2_read_zcopy/W0: No such file or directory
15:46:24 <tobias61>  mdb -ke 'smb2_read_zcopy/D'
15:46:25 <tobias61> smb2_read_zcopy:
15:46:25 <tobias61> smb2_read_zcopy:1
15:46:36 <jbk> yeah, it's not applying the fix
15:47:02 <danmcd> `mdb -kwe 'smb2_read_zcopy/W0'`
15:47:22 <danmcd> (Unless '-e' doesn't work with '-w' ?)
15:47:28 <jbk> it should
15:47:41 <jbk> the mystery is that /etc/system should be doing that on boot, but appears to not be
15:47:46 <tobias61> danmcd that does something
15:47:52 <jbk> (why i was wondering if maybe the boot archive needs to be updated)
15:47:53 <tobias61> mdb -kwe 'smb2_read_zcopy/W0'
15:47:54 <tobias61> smb2_read_zcopy:0x1             =       0x0
15:48:02 <jbk> yeah, that'll disable it, but is non persistent
15:52:44 <jbk> whenever you're able to reboot, I would try the bootadm command (it can be run anytime -- it just updates the boot archive used during boot) and then rerun the mdb -ke 'smb2_read_zcopy/D' command to see what the value is
15:54:22 <tobias61> Ok, I tried the bootadm command and rebooted, but it is 1 again after that
15:55:22 <jbk> oh.. that's strange...
15:58:02 <jbk> i don't have an OI hipster system handy to test unfortunately..
15:58:22 <jbk> i don't know why setting it in /etc/system isn't working
16:00:01 <jbk> (it should basically do the same thing as `mdb -kwe 'smb2_read_zcopy/W0'` for you, but obviously is not)
16:00:44 <jbk> but that explains why you're still getting the panic
16:01:23 <jbk> a fix should be coming pretty soon
16:02:36 <tsoome> set smbsrv: smb2_read_zcopy = 0 in /etc/systrem ?
16:02:48 <tobias61> tried to remove the spaces in /etc/system line for that, ran bootadm and tried again but it is 1 again after reboot, so this temporary fix will hopefully help me until that. I would also test the patch, if I know how to apply it :)
16:02:56 <tsoome> err, without space after colon
16:03:58 <jbk> tsoome: is the fix in your queue yet?
16:04:13 <tobias61> ok I'll try that tsoome
16:04:13 <tsoome> if this does not work, you can try: boot -B disable-smbsrv=true
16:05:18 <tobias61> but will this disable the whole smb server?
16:05:22 <tsoome> it is waiting for 16031 and 15985 to land first
16:05:40 <jbk> i've been a bit out of pocket the past several days (covid :(), so haven't caught up yet
16:05:48 <tsoome> tobias61 yes, but that allows you to have usable system, so I can mail you the patched binary;)
16:08:09 <tobias61> set smbsrv:smb2_read_zcopy=0 works
16:08:38 <jbk> ahh ok..
16:08:47 <tsoome> yes, because module variables need modulename: prefix (see system(4)
16:09:07 <jbk> i've got the ticket up, i can add that
16:09:52 <tobias61> perhaps a hint in the issue could have helped me out with that :)
16:10:33 <tsoome> I'm currently waiting for 16031 and 15985 to get approved, but obviously the zfs hole did eat much of the attention...
16:10:44 <tobias61> big thanks for your help! will come back the next days and check if the fix works for me, if it is rolled out
16:11:19 <jbk> yeah, i saw the emails from the tracker fly by inbetween (several) naps over the past several days
16:46:13 <tsoome> sigh. inaccessible imported data pool is making system unusable:(