CURRENT 220ee18f1964 memstick kernel panic, MacBookPro8,3

Originally posted to Photograph:

Kernel Panic sys/netinet/tcp_subr.c 2386

Hi, I just got a kernel panic on my 15.0-CURRENT machine, with an Assertion in sys/netinet/tcp_subr.c 2386 full log: https://people.freebsd.org/~wosch/tmp/kernel-panic-tcp_subr-line-2386.png OS: 15.0-CURRENT main-3e9515846f (10-Feb-2024, github.com/freebsd/freebsd-src) Should I worry

Re: FreeBSD-15 kernel panic when the amdtemp device is in the kernel

On Sun, 03 Sep 2023 15:17:36 +0200 "Herbert J. Skuhra" wrote: [SNIP] > Probably best to file a PR: https://bugs.freebsd.org/bugzilla/ > Bugzilla 273543 -- Gary Jennejohn

Re: FreeBSD-15 kernel panic when the amdtemp device is in the kernel

On Sat, 02 Sep 2023 18:02:03 +0200, Gary Jennejohn wrote: > > On Sat, 02 Sep 2023 15:36:36 +0200 > "Herbert J. Skuhra" wrote: > > > On Fri, 01 Sep 2023 18:05:34 +0200, Gary Jennejohn wrote: > > > > > > On Fri, 1 Sep 2023 14:43:21 + > > > Gary Jennejohn wrote: > > > > > > > A git-bisect is

Re: FreeBSD-15 kernel panic when the amdtemp device is in the kernel

On Sat, 02 Sep 2023 15:36:36 +0200 "Herbert J. Skuhra" wrote: > On Fri, 01 Sep 2023 18:05:34 +0200, Gary Jennejohn wrote: > > > > On Fri, 1 Sep 2023 14:43:21 + > > Gary Jennejohn wrote: > > > > > A git-bisect is probably required. > > > > > > > I did a bisect and the result was commit > >

Re: FreeBSD-15 kernel panic when the amdtemp device is in the kernel

On Fri, 01 Sep 2023 18:05:34 +0200, Gary Jennejohn wrote: > > On Fri, 1 Sep 2023 14:43:21 + > Gary Jennejohn wrote: > > > A git-bisect is probably required. > > > > I did a bisect and the result was commit > 9a7add6d01f3c5f7eba811e794cf860d2bce131d. > > However, that can't be correct

Re: FreeBSD-15 kernel panic when the amdtemp device is in the kernel

On Fri, 1 Sep 2023 16:00:03 -0600 Warner Losh wrote: > I think that the problem is that admsmn has probed, but not attached (or > failed to attach for some reason), so we find the device, but it's not > initialized yet, so when we call amdsmn_read, it tries to lock a mutex > that's not yet

Re: FreeBSD-15 kernel panic when the amdtemp device is in the kernel

D Ryzen 5 and a tower with a AMD Ryzen 7 > 3700X. > > > > > > > > > > These are respectively Zen 1 and Zen 2 CPUs. > > > > > > > > > > I built a kernel on both computers using the FreeBSD-15 source > tree. > > > > > > &g

Re: FreeBSD-15 kernel panic when the amdtemp device is in the kernel

nel on both computers using the FreeBSD-15 source tree. > > > > > > > > If I include the amdtemp device in my kernel file BOTH computers end up > > > > with a kernel panic while trying to attach the amdtemp device. > > > > > > > > If I rem

Re: FreeBSD-15 kernel panic when the amdtemp device is in the kernel

On Fri, 1 Sep 2023 14:43:21 + Gary Jennejohn wrote: > A git-bisect is probably required. > I did a bisect and the result was commit 9a7add6d01f3c5f7eba811e794cf860d2bce131d. However, that can't be correct because this commit was made on Mon Jul 17 19:29:20 2023 and my FBSD-14 kernel from

Re: FreeBSD-15 kernel panic when the amdtemp device is in the kernel

D Ryzen 5 and a tower with a AMD Ryzen 7 3700X. > > > > > > These are respectively Zen 1 and Zen 2 CPUs. > > > > > > I built a kernel on both computers using the FreeBSD-15 source tree. > > > > > > If I include the amdtemp device in my kernel file BOTH computers

Re: FreeBSD-15 kernel panic when the amdtemp device is in the kernel

On Fri, 1 Sep 2023 14:23:36 + Gary Jennejohn wrote: > Now that I look at the date of my FreeBSD-14 kernel I see that it's from > August 13, so this commit is perhaps not the cause of my FreeBSD-15 > kernel panicking at boot time, since FBSD-14 boots OK. > > Nonetheless, amdtemp or maybe

Re: FreeBSD-15 kernel panic when the amdtemp device is in the kernel

amdtemp device in my kernel file BOTH computers end up > with a kernel panic while trying to attach the amdtemp device. > > If I remove amdtemp both computers boot without any issues. > > I suspect that this commit is the cause: > > commit 323a94afb6236bcec3a07721566aec6f2ea2b20

Re: FreeBSD-15 kernel panic when the amdtemp device is in the kernel

PUs. > > > > I built a kernel on both computers using the FreeBSD-15 source tree. > > > > If I include the amdtemp device in my kernel file BOTH computers end up > > with a kernel panic while trying to attach the amdtemp device. > > > > If I remove amdtemp both com

Re: FreeBSD-15 kernel panic when the amdtemp device is in the kernel

amdtemp device in my kernel file BOTH computers end up > with a kernel panic while trying to attach the amdtemp device. > Traceback? Warner If I remove amdtemp both computers boot without any issues. > > I suspect that this commit is the cause: > > commit 323a94afb6236bcec3a0772

Re: FreeBSD-15 kernel panic when the amdtemp device is in the kernel

clude the amdtemp device in my kernel file BOTH computers end up > with a kernel panic while trying to attach the amdtemp device. > > If I remove amdtemp both computers boot without any issues. > > I suspect that this commit is the cause: > > commit 323a94afb6236bcec3a077215

FreeBSD-15 kernel panic when the amdtemp device is in the kernel

I have a laptop wioth a AMD Ryzen 5 and a tower with a AMD Ryzen 7 3700X. These are respectively Zen 1 and Zen 2 CPUs. I built a kernel on both computers using the FreeBSD-15 source tree. If I include the amdtemp device in my kernel file BOTH computers end up with a kernel panic while trying

Re: Kernel panic after updating 14-CURRENT amd64 to main-n264268-ff4633d9f89

On Sat, Jul 22, 2023 at 1:21 AM Yasuhiro Kimura wrote: > > From: Kevin Bowling > Subject: Re: Kernel panic after updating 14-CURRENT amd64 to > main-n264268-ff4633d9f89 > Date: Fri, 21 Jul 2023 21:44:13 -0700 > > > Thanks, I have reverted for now. Can you tell me whic

Re: Kernel panic after updating 14-CURRENT amd64 to main-n264268-ff4633d9f89

From: Kevin Bowling Subject: Re: Kernel panic after updating 14-CURRENT amd64 to main-n264268-ff4633d9f89 Date: Fri, 21 Jul 2023 21:44:13 -0700 > Thanks, I have reverted for now. Can you tell me which NIC is > implemented there? Output of `pciconf -lv` says as following. em0@pci0

Re: Kernel panic after updating 14-CURRENT amd64 to main-n264268-ff4633d9f89

Thanks, I have reverted for now. Can you tell me which NIC is implemented there? On Fri, Jul 21, 2023 at 12:45 PM Yasuhiro Kimura wrote: > > From: Yasuhiro Kimura > Subject: Kernel panic after updating 14-CURRENT amd64 to > main-n264268-ff4633d9f89 > Date: Sat, 22 Jul 2023 02:5

Re: Kernel panic after updating 14-CURRENT amd64 to main-n264268-ff4633d9f89

From: Yasuhiro Kimura Subject: Kernel panic after updating 14-CURRENT amd64 to main-n264268-ff4633d9f89 Date: Sat, 22 Jul 2023 02:50:23 +0900 (JST) > After updating my 14.0-CURRENT amd64 system from > main-n264162-f58378393fb to main-n264268-ff4633d9f89, kernel crashes > with panic as

Kernel panic after updating 14-CURRENT amd64 to main-n264268-ff4633d9f89

After updating my 14.0-CURRENT amd64 system from main-n264162-f58378393fb to main-n264268-ff4633d9f89, kernel crashes with panic as following. https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-main-n264268-ff4633d9f89.20230721.panic.png --- Yasuhiro Kimura

Re: Kernel panic on jail start

On Tue, Apr 04, 2023 at 02:31:20AM +0200, Goran Mekić wrote: > > > > > exec.start = "echo ifconfig_${vnet.interface}_name=\\"eth0\\" > > > > > >/etc/rc.conf.d/network"; > > > > > > > > ah, I see where the problem is, > > > > until its fixed you can try to set

Re: Kernel panic on jail start

> > > > exec.start = "echo ifconfig_${vnet.interface}_name=\\"eth0\\" > > > > >/etc/rc.conf.d/network"; > > > > > > ah, I see where the problem is, > > > until its fixed you can try to set compat.linux.use_real_ifnames to 1, or > > > s/eth0/to some oyhe if

Re: Kernel panic on jail start

On Mon, Apr 03, 2023 at 02:08:09PM +0200, Goran Mekić wrote: > On Fri, Mar 31, 2023 at 12:20:47PM +0300, Dmitry Chagin wrote: > > On Thu, Mar 30, 2023 at 07:08:28PM +0200, Goran Mekić wrote: > > > exec.start = "echo ifconfig_${vnet.interface}_name=\\"eth0\\" > > > >/etc/rc.conf.d/network"; > >

Re: Kernel panic on jail start

On Fri, Mar 31, 2023 at 12:20:47PM +0300, Dmitry Chagin wrote: > On Thu, Mar 30, 2023 at 07:08:28PM +0200, Goran Mekić wrote: > > exec.start = "echo ifconfig_${vnet.interface}_name=\\"eth0\\" > > >/etc/rc.conf.d/network"; > > ah, I see where the problem is,

Re: Kernel panic on jail start

On Thu, Mar 30, 2023 at 07:08:28PM +0200, Goran Mekić wrote: > Hello, > > I get the kernel panic when starting jail. With git bisect I found out > the offending commit is 0b56641cfcda30d06243223f37781ccc18455bef. After > reverting it, everything is back to normal. For completen

Re: Kernel panic on jail start

On Thu, Mar 30, 2023 at 07:08:28PM +0200, Goran Mekić wrote: > Hello, > > I get the kernel panic when starting jail. With git bisect I found out > the offending commit is 0b56641cfcda30d06243223f37781ccc18455bef. After > reverting it, everything is back to normal. For completen

Kernel panic on jail start

Hello, I get the kernel panic when starting jail. With git bisect I found out the offending commit is 0b56641cfcda30d06243223f37781ccc18455bef. After reverting it, everything is back to normal. For completeness, this is my jail.conf: network { $id = 1; $base = /var/jails; persist; vnet

Re: kernel panic during zfs pool import

Still the same with current.(from today). Opening a PR for it.. Santi On 8/22/22 10:43, Santiago Martinez wrote: Thanks Toommas, I compiling current right now and will give it a try, hopefully, will be able to mount and recover the machine. Will also open a PR as even if the is any

Re: kernel panic during zfs pool import

Thanks Toommas, I compiling current right now and will give it a try, hopefully, will be able to mount and recover the machine. Will also open a PR as even if the is any corruption/pool damage it should not panic the machine. Santi On 8/18/22 21:45, Toomas Soome wrote: On 18. Aug 2022,

Re: kernel panic during zfs pool import

> On 18. Aug 2022, at 18:46, Santiago Martinez wrote: > > Hi everyone, > > I have a server running 13.1-stable that was powered off (gracefully) and now > is been powered on again and we have the following problem. > > The server boots almost properly, kernel load and when zfs import other

kernel panic during zfs pool import

Hi everyone, I have a server running 13.1-stable that was powered off (gracefully) and now is been powered on again and we have the following problem. The server boots almost properly, kernel load and when zfs import other pools it panic with the following message. "panic : Solaris (panic)

Re: Kernel panic on armv7 when PF is enabled

W dniu 2.05.2022 o 11:02, Kristof Provost pisze: On 1 May 2022, at 5:13, qroxana wrote: After git bisecting the panic started since this commit. commit 78bc3d5e1712bc1649aa5574d2b8d153f9665113 Author: Kristof Provost < k...@freebsd.org Date: Mon Feb 14 20:09:54 2022 +0100

Re: Kernel panic on armv7 when PF is enabled

- 1; > cookie.cookie = (ack & 0xff) ^ (ack >> 24); > > + if (V_pf_status.syncookies_mode == PF_SYNCOOKIES_NEVER) > + return (0); > + > /* we don't know oddeven before setting the cookie (union) */ > if > (atomic_load_64(_pf_status.syncookies_inflight[cookie.flags.oddeven]) > == 0) > > > That shouldn’t be required though. > > Br, > Kristof Thank you sir. You were right. I tested patch with the latest kernel. It can boot successfully with the patch, and still got kernel panic without the patch.

Re: Kernel panic on armv7 when PF is enabled

On 1 May 2022, at 5:13, qroxana wrote: After git bisecting the panic started since this commit. commit 78bc3d5e1712bc1649aa5574d2b8d153f9665113 Author: Kristof Provost < k...@freebsd.org Date: Mon Feb 14 20:09:54 2022 +0100 vlan: allow net.link.vlan.mtag_pcp to be set per vnet The

Re: Kernel panic on armv7 when PF is enabled

boots from a NFS root, > > it can boot without any problem if PF is disabled. It appears this only occurs when the rootfs is NFS, I also tried to boot it from a micro SD card, no kernel panic. Another workaround to avoid the panic is to delay starting /etc/rc.d/pf to SERVERS --- pf.orig 202

Kernel panic on armv7 when PF is enabled

After git bisecting the panic started since this commit. commit 78bc3d5e1712bc1649aa5574d2b8d153f9665113 Author: Kristof Provost < k...@freebsd.org > Date: Mon Feb 14 20:09:54 2022 +0100 vlan: allow net.link.vlan.mtag_pcp to be set per vnet The primary reason for this change is to

Re: Kernel panic for if_epair

On 16 Feb 2022, at 11:31, qroxana wrote: > It's running 14.0-CURRENT armv7 main-n252983-d21e71efce39 > > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex epairidx (epairidx) r = 0 (0xe2fe9160) locked @ > /usr/src/sys/net/if_epair.c:165 > stack backtrace: > #0

Kernel panic for if_epair

It's running 14.0-CURRENT armv7 main-n252983-d21e71efce39 Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex epairidx (epairidx) r = 0 (0xe2fe9160) locked @ /usr/src/sys/net/if_epair.c:165 stack backtrace: #0 0xc03558f8 at witness_debugger+0x7c #1 0xc0356b3c at

Re: Kernel Panic main-n252492-ad15eeeaba3 - Solved

On 1/17/22 16:33, Thomas Laus wrote: I just updated today to main-n252492-ad15eeeaba3 from: main-n252313-ae13829ddce on 3 PC's. I tried bisecting the 87 changes involved between main-n252508-aac52f94ea5 to main-n252492-ad15eeeaba3 and started at the halfway point and worked forward. After

Kernel Panic main-n252492-ad15eeeaba3

I just updated today to main-n252492-ad15eeeaba3 from: main-n252313-ae13829ddce on 3 PC's. Two of them had the update go well but my Dell Inspiron 1545 had a panic after booting. This laptop doesn't have a scroll buffer and the entire panic message scrolls off the screen, so can't take a

Re: Kernel panic in networking code

ome networking code, > > > specifically with ipv4 jails. I can reproduce by running Poudriere on > > > 14-CURRENT. > > > > > > I am using HardenedBSD 14-CURRENT, but we don't have any changes to > > > any point in the code paths that would trigger/caus

Re: Kernel panic in networking code

running Poudriere on > > 14-CURRENT. > > > > I am using HardenedBSD 14-CURRENT, but we don't have any changes to > > any point in the code paths that would trigger/cause this kind of > > kernel panic. > > > > I've uploaded the crash.txt file here: > >

Re: Kernel panic in networking code

but we don't have any changes to > any point in the code paths that would trigger/cause this kind of > kernel panic. > > I've uploaded the crash.txt file here: > https://hardenedbsd.org/~shawn/2021-12-09_crash-01.txt There is some WIP to address this in https://reviews.freebsd.org/D9 and its followup revision.

Kernel panic in networking code

of kernel panic. I've uploaded the crash.txt file here: https://hardenedbsd.org/~shawn/2021-12-09_crash-01.txt `uname -a`: FreeBSD ci-08 14.0-CURRENT-HBSD FreeBSD 14.0-CURRENT-HBSD #0 hardened/current/master-n191216-7474f245a83: Wed Dec 8 22:44:04 EST 2021 shawn@ci-08:/usr/obj/usr/src/amd64

Re: Kernel panic by executing `poudriere bulk`

From: Mateusz Guzik Subject: Re: Kernel panic by executing `poudriere bulk` Date: Fri, 26 Nov 2021 20:33:22 +0100 > On 11/26/21, Yasuhiro Kimura wrote: >> yasu@rolling-vm-freebsd1[1015]% uname -a >> ~ >> FreeBSD rolling-vm-freebsd1.

Re: Kernel panic by executing `poudriere bulk`

ing-vm-freebsd1.home.utahime.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC > amd64 > yasu@rolling-vm-freebsd1[1016]% > > After regular weekly update of my 14-current amd64 system, kernel > panic happens when I execute `poudriere bulk`. > > Snapshot of console: > https://www.utahi

Kernel panic by executing `poudriere bulk`

.home.utahime.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 yasu@rolling-vm-freebsd1[1016]% After regular weekly update of my 14-current amd64 system, kernel panic happens when I execute `poudriere bulk`. Snapshot of console: https://www.utahime.org/FreeBSD/FreeBSD-14-CURRENT-amd64-main-n251115

Kernel panic on Lenovo Thinkpad T450

On this laptop I've been using FreeBSD 14 for a few months now and sometimes it panics, but after upgrading to: uname -a FreeBSD NomadBSD 14.0-CURRENT FreeBSD 14.0-CURRENT #0 e2157cd00: Sat Nov 6 03:21:26 CET 2021 root@NomadBSD:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 It always

VMMR0InitVM … kernel panic: fatal trap 9: general protection fault while in kernel mode

Is it worth opening a bug for what's below? GENERIC-NODEBUG, main-n249988-2c614481fd5 Gut feeling: it might be very difficult to reproduce. From :

Re: panic: Unaligned free (was: kernel panic while copying files)

INVARIANTS. > > > > > > > > > > > > > I decided to do a real test. So I built a kernel w/o INVARIANTS and > > > > installed it to /boot/test. > > > > > > > > Then I stuck a 160GB disk I had around into an exter

Re: panic: Unaligned free (was: kernel panic while copying files)

t; > Then I stuck a 160GB disk I had around into an external USB3 enclosure > > > and put a filesystem on it. > > > > > > The I booted the new kernel from /boot/test and set the sysctls so: > > > kern.cam.da.enable_uma_ccbs: 1 > > > kern.cam.ada.enable_u

Re: panic: Unaligned free (was: kernel panic while copying files)

test. So I built a kernel w/o INVARIANTS and > > installed it to /boot/test. > > > > Then I stuck a 160GB disk I had around into an external USB3 enclosure > > and put a filesystem on it. > > > > The I booted the new kernel from /boot/test and set the sysctls

Re: panic: Unaligned free (was: kernel panic while copying files)

> The I booted the new kernel from /boot/test and set the sysctls so: > kern.cam.da.enable_uma_ccbs: 1 > kern.cam.ada.enable_uma_ccbs: 1 > > After that I plugged in the external USB3 enclosure and copied about > 114GiB of data from an internal SSD to it - without a kernel panic: >

Re: panic: Unaligned free (was: kernel panic while copying files)

the CCBs and it's marked > > incorrectly, triggering either this panic or the prior one we saw. > > > > These actions were fine when there was one allocator, but now that there > > are two more care must be taken, and that more care hasn't been taken yet, > > so

Re: panic: Unaligned free (was: kernel panic while copying files)

On Wed, 30 Jun 2021 10:35:14 -0600 Warner Losh wrote: > On Wed, Jun 30, 2021 at 6:58 AM Gary Jennejohn wrote: > > > On Wed, 30 Jun 2021 06:02:59 +0100 > > Graham Perrin wrote: > > > > > On 29/06/2021 10:42, Gary Jennejohn wrote: > > > > ___ panic is now the result of an unaligned free. >

Re: panic: Unaligned free (was: kernel panic while copying files)

On Wed, Jun 30, 2021 at 6:58 AM Gary Jennejohn wrote: > On Wed, 30 Jun 2021 06:02:59 +0100 > Graham Perrin wrote: > > > On 29/06/2021 10:42, Gary Jennejohn wrote: > > > ___ panic is now the result of an unaligned free. > > > > > > panic: Unaligned free of 0xf800259e2800 from zone > > >

Re: panic: Unaligned free (was: kernel panic while copying files)

On Wed, 30 Jun 2021 06:02:59 +0100 Graham Perrin wrote: > On 29/06/2021 10:42, Gary Jennejohn wrote: > > ___ panic is now the result of an unaligned free. > > > > panic: Unaligned free of 0xf800259e2800 from zone > > 0xfe00dc9d2000(da_ccb) slab 0xf800259e2fd8(3) > > > > I have

panic: Unaligned free (was: kernel panic while copying files)

On 29/06/2021 10:42, Gary Jennejohn wrote: … panic is now the result of an unaligned free. panic: Unaligned free of 0xf800259e2800 from zone 0xfe00dc9d2000(da_ccb) slab 0xf800259e2fd8(3) I have the crash dump and a debug kernel in case anyone wants more info. Can you post the

Re: kernel panic while copying files

I was sort of hoping that all the recent changes made by imp@ in cam and umass may have fixed the cause of the kernel crash. Unfortunately not. But there is a change - instead of a duplicate free the panic is now the result of an unaligned free. panic: Unaligned free of 0xf800259e2800 from

Re: kernel panic while copying files

On Sat, 12 Jun 2021 14:10:36 +0100 Edward Tomasz Napiera__a wrote: > On 0610T1150, Gary Jennejohn wrote: > > On Tue, 8 Jun 2021 17:54:05 +0200 > > Gary Jennejohn wrote: > > > > [big snip] > > [..] > > > So, I did ``git reset --hard 8dc96b74edb844bb621afeba38fe4af104b13120'', > > which was

Re: kernel panic while copying files

On 0610T1150, Gary Jennejohn wrote: > On Tue, 8 Jun 2021 17:54:05 +0200 > Gary Jennejohn wrote: > > [big snip] [..] > So, I did ``git reset --hard 8dc96b74edb844bb621afeba38fe4af104b13120'', > which was the penultimate commit made by trasz to clear CCBs on the stack > after he committed

Re: kernel panic while copying files

On Tue, 8 Jun 2021 17:54:05 +0200 Gary Jennejohn wrote: [big snip] > Here's the kgdb backtrace with the -O0 kernel: > > (kgdb) bt > #0 0x8081d706 in doadump (textdump=0) > at /usr/src/sys/kern/kern_shutdown.c:398 > #1 0x804ef15a in db_dump (dummy=-2138500043, dummy2=false,

Re: kernel panic while copying files

On Tue, 8 Jun 2021 06:27:04 -0600 Warner Losh wrote: > On Tue, Jun 8, 2021 at 2:47 AM Gary Jennejohn wrote: > [snip old stuff] > > Here the kgdb backtrace: > > > > Unread portion of the kernel message buffer: > > panic: Duplicate free of 0xf800356b9000 from zone > >

Re: kernel panic while copying files

On Tue, Jun 8, 2021 at 8:42 AM Gary Jennejohn wrote: > On Tue, 8 Jun 2021 06:48:19 -0600 > Warner Losh wrote: > > > Sorry to reply to myself... had a thought as my brain rested while making > > tea... > > > > I think we may need to consider reverting (or at least not yet enabling) > > the uma

Re: kernel panic while copying files

On Tue, 8 Jun 2021 06:48:19 -0600 Warner Losh wrote: > Sorry to reply to myself... had a thought as my brain rested while making > tea... > > I think we may need to consider reverting (or at least not yet enabling) > the uma stuff. > I tested and enabled the UMA CCB stuff immediately after

Re: kernel panic while copying files

Sorry to reply to myself... had a thought as my brain rested while making tea... I think we may need to consider reverting (or at least not yet enabling) the uma stuff. On Tue, Jun 8, 2021 at 6:27 AM Warner Losh wrote: > > > On Tue, Jun 8, 2021 at 2:47 AM Gary Jennejohn > wrote: > >> On Mon,

Re: kernel panic while copying files

On Tue, Jun 8, 2021 at 2:47 AM Gary Jennejohn wrote: > On Mon, 7 Jun 2021 16:54:11 -0400 > Mark Johnston wrote: > > > On Mon, Jun 07, 2021 at 11:01:09AM +0200, Gary Jennejohn wrote: > > > I've seen this panic three times in the last two days: > > > > > > [first panic] > > > Unread portion of

Re: kernel panic while copying files

On Tue, 8 Jun 2021 11:04:33 +0200 Mateusz Guzik wrote: > Given how easy it is to reproduce perhaps you can spend a little bit > of time narrowing it down to a specific commit. You can do it with > git-bisect. > Ok, I'll give it a try. -- Gary Jennejohn

Re: kernel panic while copying files

On 6/8/21 1:34 PM, Gary Jennejohn wrote: Fields in the ccb like periph_name, unit_number and dev_name are filled with zeroes. Smells like a double free, like the panic message indicates, but would be nice to know exactly which driver is doing this, if it is "ATA" or "UMASS", so to speak.

Re: kernel panic while copying files

On Tue, 8 Jun 2021 11:20:37 +0200 Hans Petter Selasky wrote: > On 6/8/21 11:04 AM, Mateusz Guzik wrote: > > Apparently caused by recent changes to CAM. > > > > Let me know if you want more information. > > Maybe you can print the *ccb being freed and figure out which device > it belongs to.

Re: kernel panic while copying files

On 6/8/21 11:04 AM, Mateusz Guzik wrote: Apparently caused by recent changes to CAM. Let me know if you want more information. Maybe you can print the *ccb being freed and figure out which device it belongs to. --HPS

Re: kernel panic while copying files

Given how easy it is to reproduce perhaps you can spend a little bit of time narrowing it down to a specific commit. You can do it with git-bisect. On 6/8/21, Gary Jennejohn wrote: > On Mon, 7 Jun 2021 16:54:11 -0400 > Mark Johnston wrote: > >> On Mon, Jun 07, 2021 at 11:01:09AM +0200, Gary

Re: kernel panic while copying files

On Mon, 7 Jun 2021 16:54:11 -0400 Mark Johnston wrote: > On Mon, Jun 07, 2021 at 11:01:09AM +0200, Gary Jennejohn wrote: > > I've seen this panic three times in the last two days: > > > > [first panic] > > Unread portion of the kernel message buffer: > > > > > > Fatal trap 12: page fault

Re: kernel panic while copying files

On Mon, Jun 07, 2021 at 11:01:09AM +0200, Gary Jennejohn wrote: > I've seen this panic three times in the last two days: > > [first panic] > Unread portion of the kernel message buffer: > > > Fatal trap 12: page fault while in kernel mode > cpuid = 3; apic id = 03 > fault virtual address =

kernel panic while copying files

I've seen this panic three times in the last two days: [first panic] Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0x801118000 fault code = supervisor write data, page not present

Re: kernel panic and fun debugging

On Sat, Oct 17, 2020 at 1:17 PM Steve Kargl < s...@troutmask.apl.washington.edu> wrote: > On Sat, Oct 17, 2020 at 12:58:48PM -0600, Warner Losh wrote: > > On Sat, Oct 17, 2020, 12:00 PM Andrey V. Elsukov > wrote: > > > > > On 15.10.2020 09:56, Steve Kargl wrote

Re: kernel panic and fun debugging

On Sat, Oct 17, 2020 at 12:58:48PM -0600, Warner Losh wrote: > On Sat, Oct 17, 2020, 12:00 PM Andrey V. Elsukov wrote: > > > On 15.10.2020 09:56, Steve Kargl wrote: > > > Just had a kernel panic. Best info I give you is > > > > > > % uname -a > &g

Re: kernel panic and fun debugging

On Sat, Oct 17, 2020 at 08:57:31PM +0300, Andrey V. Elsukov wrote: > On 15.10.2020 09:56, Steve Kargl wrote: > > Just had a kernel panic. Best info I give you is > > > > % uname -a > > FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #1 r366176M: Sat Sep 26 >

Re: kernel panic and fun debugging

On Sat, Oct 17, 2020, 12:00 PM Andrey V. Elsukov wrote: > On 15.10.2020 09:56, Steve Kargl wrote: > > Just had a kernel panic. Best info I give you is > > > > % uname -a > > FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #1 r366176M: Sat Sep 26 > 10:35:23 PDT

Re: kernel panic and fun debugging

On 15.10.2020 09:56, Steve Kargl wrote: > Just had a kernel panic. Best info I give you is > > % uname -a > FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #1 r366176M: Sat Sep 26 > 10:35:23 PDT 2020 kargl@mobile:/usr/obj/usr/src/i386.i386/sys/MOBILE i386 > > % kg

kernel panic and fun debugging

Just had a kernel panic. Best info I give you is % uname -a FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #1 r366176M: Sat Sep 26 10:35:23 PDT 2020 kargl@mobile:/usr/obj/usr/src/i386.i386/sys/MOBILE i386 % kgdb gdb /usr/lib/debug/boot/kernel/kernel.debug vmcore.1 ... Reading symbols

Re: iflib/bridge kernel panic

On Tue, Sep 29, 2020 at 05:36:15PM -0400, Shawn Webb wrote: > On Tue, Sep 29, 2020 at 11:20:44PM +0200, Kristof Provost wrote: > > > > > > On 28 Sep 2020, at 16:44, Alexander Leidinger wrote: > > > > > Quoting Kristof Provost (from Mon, 28 Sep 2020 13:53:16 > > > +0200): > > > > > > > On 28

Re: iflib/bridge kernel panic

On Sat, Oct 3, 2020 at 2:54 PM Felix Kronlage-Dammers wrote: > > Alexander Leidinger wrote on 03.10.20 17:37: > > > Quoting Kristof Provost (from Sat, 03 Oct 2020 16:06:43 > > +0200): > > >> Okay, let’s abandon that patch. It’s ugly and it doesn’t work. > >> > >> Here’s a different approach

Re: iflib/bridge kernel panic

Alexander Leidinger wrote on 03.10.20 17:37: > Quoting Kristof Provost (from Sat, 03 Oct 2020 16:06:43 > +0200): >> Okay, let’s abandon that patch. It’s ugly and it doesn’t work. >> >> Here’s a different approach that I’m much happier with. >>

Re: iflib/bridge kernel panic

Quoting Kristof Provost (from Sat, 03 Oct 2020 16:06:43 +0200): Okay, let’s abandon that patch. It’s ugly and it doesn’t work. Here’s a different approach that I’m much happier with. https://people.freebsd.org/~kp/0001-bridge-Call-member-interface-ioctl-without-NET_EPOCH.patch It passes

Re: iflib/bridge kernel panic

On 30 Sep 2020, at 13:52, Alexander Leidinger wrote: Quoting Kristof Provost (from Tue, 29 Sep 2020 23:20:44 +0200): On 28 Sep 2020, at 16:44, Alexander Leidinger wrote: Quoting Kristof Provost (from Mon, 28 Sep 2020 13:53:16 +0200): On 28 Sep 2020, at 12:45, Alexander Leidinger wrote:

Re: iflib/bridge kernel panic

On Tue, Sep 29, 2020 at 4:21 PM Kristof Provost wrote: > > On 28 Sep 2020, at 16:44, Alexander Leidinger wrote: > > > Quoting Kristof Provost (from Mon, 28 Sep 2020 > > 13:53:16 +0200): > > > >> On 28 Sep 2020, at 12:45, Alexander Leidinger wrote: > >>> Quoting Kristof Provost (from Sun, 27 Sep

Re: iflib/bridge kernel panic

Quoting Kristof Provost (from Tue, 29 Sep 2020 23:20:44 +0200): On 28 Sep 2020, at 16:44, Alexander Leidinger wrote: Quoting Kristof Provost (from Mon, 28 Sep 2020 13:53:16 +0200): On 28 Sep 2020, at 12:45, Alexander Leidinger wrote: Quoting Kristof Provost (from Sun, 27 Sep 2020

Re: iflib/bridge kernel panic

On Tue, Sep 29, 2020 at 11:20:44PM +0200, Kristof Provost wrote: > > > On 28 Sep 2020, at 16:44, Alexander Leidinger wrote: > > > Quoting Kristof Provost (from Mon, 28 Sep 2020 13:53:16 > > +0200): > > > > > On 28 Sep 2020, at 12:45, Alexander Leidinger wrote: > > > > Quoting Kristof Provost

Re: iflib/bridge kernel panic

On 28 Sep 2020, at 16:44, Alexander Leidinger wrote: Quoting Kristof Provost (from Mon, 28 Sep 2020 13:53:16 +0200): On 28 Sep 2020, at 12:45, Alexander Leidinger wrote: Quoting Kristof Provost (from Sun, 27 Sep 2020 17:51:32 +0200): Here’s an early version of a task queue based

Re: iflib/bridge kernel panic

Quoting Kristof Provost (from Mon, 28 Sep 2020 13:53:16 +0200): On 28 Sep 2020, at 12:45, Alexander Leidinger wrote: Quoting Kristof Provost (from Sun, 27 Sep 2020 17:51:32 +0200): Here’s an early version of a task queue based approach:

Re: iflib/bridge kernel panic

://gist.github.com/lattera/a0803f31f58bcf8ead51ac1ebbc447e2 The last working boot environment was 14 Aug 2020. If I get some time to bisect commits, I'll try to figure out the culprit. Try https://reviews.freebsd.org/D26418 That seems to fix the kernel panic. dmesg gets spammed with a freak ton of these LOR

Re: iflib/bridge kernel panic

On 28 Sep 2020, at 12:45, Alexander Leidinger wrote: Quoting Kristof Provost (from Sun, 27 Sep 2020 17:51:32 +0200): Here’s an early version of a task queue based approach: http://people.freebsd.org/~kp/0001-bridge-Cope-with-if_ioctl-s-that-sleep.patch That still needs to be cleaned up, but

Re: iflib/bridge kernel panic

environment was 14 Aug 2020. If I get some time to bisect commits, I'll try to figure out the culprit. Try https://reviews.freebsd.org/D26418 That seems to fix the kernel panic. dmesg gets spammed with a freak ton of these LOR messages now: Here’s an early version of a task queue based approach

Re: iflib/bridge kernel panic

he console screen goes out and the server (router) stops responding to the keyboard. Can anyone do this test on their machine? Sergei. From: xt Sent: Friday, September 25, 2020 8:46 PM To: Sergey V. Dyatko ; Kristof Provost Cc: FreeBSD Current Subject: Re: iflib/bridge kernel panic Sergey V. Dy

Re: iflib/bridge kernel panic

Sergey V. Dyatko wrote: On Mon, 21 Sep 2020 09:57:40 +0200 "Kristof Provost" wrote: On 21 Sep 2020, at 2:52, Shawn Webb wrote: From latest HEAD on a Dell Precision 7550 laptop: https://gist.github.com/lattera/a0803f31f58bcf8ead51ac1ebbc447e2 The last working boot environment was 14 Aug

Re: iflib/bridge kernel panic

On Mon, 21 Sep 2020 09:57:40 +0200 "Kristof Provost" wrote: > On 21 Sep 2020, at 2:52, Shawn Webb wrote: > >> From latest HEAD on a Dell Precision 7550 laptop: > > > > https://gist.github.com/lattera/a0803f31f58bcf8ead51ac1ebbc447e2 > > > > The last working boot environment was 14 Aug 2020.

Re: iflib/bridge kernel panic

On 23 Sep 2020, at 19:37, xto...@hotmail.com wrote: > Kristof Provost wrote: >> On 21 Sep 2020, at 2:52, Shawn Webb wrote: From latest HEAD on a Dell Precision 7550 laptop: >>> >>> https://gist.github.com/lattera/a0803f31f58bcf8ead51ac1ebbc447e2 >>> >>> The last working boot environment was

  1   2   3   4   5   6   7   8   9   >