Re: How do I find out what changed for an freebsd release update?
On Fri, Oct 15, 2021 at 11:48:01PM +, Rick Macklem wrote: > Hi, > > PR#259163 reports a problem w.r.t. the NFSv3 server that surfaced when > the server was upgraded from 12.2-p8 to 12.2-p9. > I know that nothing changed in NFS server code, but how can I find out > what did get changed by that update? > > Thanks in advance for any help, rick 1. Check UPDATING https://cgit.freebsd.org/src/tree/UPDATING?h=releng/12.2 2. git log and git diff e.g.: git diff 6e927d10c587..2430d82b40ea -- Herbert
Re: 13-STABLE/drm-fbsd13-kmod: Firefox crash: Bad system call
On Fri, 15 Oct 2021 23:25:01 +0300 Konstantin Belousov wrote: > On Fri, Oct 15, 2021 at 10:20:55PM +0200, Jan Beich wrote: > > FreeBSD User writes: > > > > > After updating 13-STABLE to 13.0-STABLE #3 stable/13-n247671-70db230dcbd: > > > Thu Oct 14 > > > 20:48:53 CEST 2021 amd64 on a Lenovo E540 notebook with Intel iGPU and > > > also > > > updating port graphics/drm-fbsd13-kmod to > > > drm-fbsd13-kmod-5.4.144.g20211013, > > > graphics/libdrm to libdrm-2.4.107_1,1, Firefox (firefox-93.0_1,2) crashes > > > now with > > > the following message: > > > > Which revision "13-STABLE" was before the update? If you didn't change > > any kernel options (and bump into a pilot error) bisecting may help. > > > > > > > > [~] firefox > > > Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close > > > with > > > reason=AbnormalShutdown (t=0.216076) Exiting due to channel error. Bad > > > system > > > callgraphics/libdrm. > > > > Run under truss(1) or ktrace(1) (enable tracing descendants) to get the > > syscall name or number. For example, Firefox requires CAPABILITIES for > > cap_rights_{limit,init} and COMPAT_FREEBSD11 [1] for pre-ino64 via Rust. > > > > [1] https://github.com/rust-lang/libc/pull/2406 > > If you set kern.lognosys=3, it should be quite loud advertized which syscall > was missed, ie. console + control terminal. > terminal) > Hello, thanks for the fast response. I changed indeed one single kernel parameter: commenting out the COMPAT_FREEBSD11. I think Jan Beich pointed towards the right thing. Thanks for the help and soryy for the noise. Kind regards, O. Hartmann
How do I find out what changed for an freebsd release update?
Hi, PR#259163 reports a problem w.r.t. the NFSv3 server that surfaced when the server was upgraded from 12.2-p8 to 12.2-p9. I know that nothing changed in NFS server code, but how can I find out what did get changed by that update? Thanks in advance for any help, rick
Re: 13-STABLE/drm-fbsd13-kmod: Firefox crash: Bad system call
On Fri, Oct 15, 2021 at 10:20:55PM +0200, Jan Beich wrote: > FreeBSD User writes: > > > After updating 13-STABLE to 13.0-STABLE #3 stable/13-n247671-70db230dcbd: > > Thu Oct 14 > > 20:48:53 CEST 2021 amd64 on a Lenovo E540 notebook with Intel iGPU and also > > updating port > > graphics/drm-fbsd13-kmod to drm-fbsd13-kmod-5.4.144.g20211013, > > graphics/libdrm to > > libdrm-2.4.107_1,1, Firefox (firefox-93.0_1,2) crashes now with the > > following message: > > Which revision "13-STABLE" was before the update? If you didn't change > any kernel options (and bump into a pilot error) bisecting may help. > > > > > [~] firefox > > Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close with > > reason=AbnormalShutdown (t=0.216076) Exiting due to channel error. Bad > > system > > callgraphics/libdrm. > > Run under truss(1) or ktrace(1) (enable tracing descendants) to get the > syscall name or number. For example, Firefox requires CAPABILITIES for > cap_rights_{limit,init} and COMPAT_FREEBSD11 [1] for pre-ino64 via Rust. > > [1] https://github.com/rust-lang/libc/pull/2406 If you set kern.lognosys=3, it should be quite loud advertized which syscall was missed, ie. console + control terminal. terminal)
Re: 13-STABLE/drm-fbsd13-kmod: Firefox crash: Bad system call
FreeBSD User writes: > After updating 13-STABLE to 13.0-STABLE #3 stable/13-n247671-70db230dcbd: Thu > Oct 14 > 20:48:53 CEST 2021 amd64 on a Lenovo E540 notebook with Intel iGPU and also > updating port > graphics/drm-fbsd13-kmod to drm-fbsd13-kmod-5.4.144.g20211013, > graphics/libdrm to > libdrm-2.4.107_1,1, Firefox (firefox-93.0_1,2) crashes now with the following > message: Which revision "13-STABLE" was before the update? If you didn't change any kernel options (and bump into a pilot error) bisecting may help. > > [~] firefox > Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close with > reason=AbnormalShutdown (t=0.216076) Exiting due to channel error. Bad system > callgraphics/libdrm. Run under truss(1) or ktrace(1) (enable tracing descendants) to get the syscall name or number. For example, Firefox requires CAPABILITIES for cap_rights_{limit,init} and COMPAT_FREEBSD11 [1] for pre-ino64 via Rust. [1] https://github.com/rust-lang/libc/pull/2406
13-STABLE/drm-fbsd13-kmod: Firefox crash: Bad system call
After updating 13-STABLE to 13.0-STABLE #3 stable/13-n247671-70db230dcbd: Thu Oct 14 20:48:53 CEST 2021 amd64 on a Lenovo E540 notebook with Intel iGPU and also updating port graphics/drm-fbsd13-kmod to drm-fbsd13-kmod-5.4.144.g20211013, graphics/libdrm to libdrm-2.4.107_1,1, Firefox (firefox-93.0_1,2) crashes now with the following message: [~] firefox Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close with reason=AbnormalShutdown (t=0.216076) Exiting due to channel error. Bad system callgraphics/libdrm. info on packages installed: [~] pkg info -x drm drm-fbsd13-kmod-5.4.144.g20211013 drm-kmod-g20190710_1 libdrm-2.4.107_1,1 linux-c7-libdrm-2.4.97 It doesn't matter whether to update the ports (including firefox) from a regular FreeBSD ports repo or, in my case, compiling special kernel related kmod port like drm-fbsd13-kmod manually on each kernel build. The ports package of graphics/drm-fbsd13-kmod seems to be behind the version of drm-fbsd13-kmod-5.4.144.g20211013 when updating from regular package host, but it doesn't matter, the result then is the same: Bad system call on Firefox. So FreeBSD 13-STABLE seems to be the culprit. What happened? I saw the Linux KPI changed again, so might this trigger this? Kind regards, O. Hartmann