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 which NIC is > > implemented there? > > Output of `pciconf -lv` says as following. > > em0@pci0:0:3:0: class=0x02 rev=0x02 hdr=0x00 vendor=0x8086 device=0x100e > subvendor=0x8086 subdevice=0x001e > vendor = 'Intel Corporation' > device = '82540EM Gigabit Ethernet Controller' > class = network > subclass = ethernet > > Regards. Thanks for the report, I've identified the errors and recommitted. > --- > Yasuhiro Kimura
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:0:3:0: class=0x02 rev=0x02 hdr=0x00 vendor=0x8086 device=0x100e subvendor=0x8086 subdevice=0x001e vendor = 'Intel Corporation' device = '82540EM Gigabit Ethernet Controller' class = network subclass = ethernet Regards. --- Yasuhiro Kimura
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: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 following. > > > > https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-main-n264268-ff4633d9f89.20230721.panic.png > > According to the result of bisect, kernel panic starts with following > commit. > > -- > commit 95f7b36e8fac45092b9a4eea5e32732e979989f0 > Author: Kevin Bowling > Date: Thu Jul 20 20:30:00 2023 -0700 > > e1000: lem(4)/em(4) ifcaps, TSO and hwcsum fixes > > * em(4) obey administrative ifcaps for using hwcsum offload > * em(4) obey administrative ifcaps for hw vlan receive tagging > * em(4) add additional TSO6 ifcap, but disabled by default as is TSO4 > * lem(4) obey administrative ifcaps for using hwcsum offload > * lem(4) add support for hw vlan receive tagging > * lem(4) Add ifcaps for TSO offload experimentation, but disabled by > default due to errata and possibly missing txrx code. > * lem(4) disable HWCSUM ifcaps by default on 82547 due to errata around > full duplex links. It may still be administratively enabled. > > Reviewed by:markj (previous version) > MFC after: 2 weeks > Differential Revision: https://reviews.freebsd.org/D30072 > -- > > Cc-ing to its committer. > > --- > Yasuhiro Kimura
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 following. > > https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-main-n264268-ff4633d9f89.20230721.panic.png According to the result of bisect, kernel panic starts with following commit. -- commit 95f7b36e8fac45092b9a4eea5e32732e979989f0 Author: Kevin Bowling Date: Thu Jul 20 20:30:00 2023 -0700 e1000: lem(4)/em(4) ifcaps, TSO and hwcsum fixes * em(4) obey administrative ifcaps for using hwcsum offload * em(4) obey administrative ifcaps for hw vlan receive tagging * em(4) add additional TSO6 ifcap, but disabled by default as is TSO4 * lem(4) obey administrative ifcaps for using hwcsum offload * lem(4) add support for hw vlan receive tagging * lem(4) Add ifcaps for TSO offload experimentation, but disabled by default due to errata and possibly missing txrx code. * lem(4) disable HWCSUM ifcaps by default on 82547 due to errata around full duplex links. It may still be administratively enabled. Reviewed by:markj (previous version) MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D30072 -- Cc-ing to its committer. --- Yasuhiro Kimura
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: Panic after updating
On Wed, 2021-01-13 at 10:37 +0100, Jakob Alvermark wrote: > On 1/13/21 10:07 AM, Hans Petter Selasky wrote: > > > > > > Yes! That works! Thank you! > > > > > > > See: > > > > https://cgit.freebsd.org/src/commit/?id=bafb682656724d06045fa494efb83a4312036f1f > > > > > > > Nice! Thanks again! > > > Jakob > Indeed, thank you for taking care of this, my $job has me way too busy these days. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic after updating
On 1/13/21 10:07 AM, Hans Petter Selasky wrote: Yes! That works! Thank you! See: https://cgit.freebsd.org/src/commit/?id=bafb682656724d06045fa494efb83a4312036f1f Nice! Thanks again! Jakob ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic after updating
Yes! That works! Thank you! See: https://cgit.freebsd.org/src/commit/?id=bafb682656724d06045fa494efb83a4312036f1f --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic after updating
On 1/12/21 6:10 PM, Hans Petter Selasky wrote:
On 1/12/21 2:46 PM, Hans Petter Selasky wrote:
On 1/12/21 2:40 PM, Jakob Alvermark wrote:
On 1/12/21 2:16 PM, Hans Petter Selasky wrote:
On 1/12/21 1:43 PM, Jakob Alvermark wrote:
On 1/12/21 12:54 PM, Hans Petter Selasky wrote:
On 1/12/21 12:32 PM, Jakob Alvermark wrote:
Alright, after a new bisect run I got a different result, so I
most likely did something wrong the first time.
ff3468ac94597efdcbc56f372528dfc98b114dac is the first bad commit
commit ff3468ac94597efdcbc56f372528dfc98b114dac
Author: Ian Lepore
Date: Sat Dec 12 18:34:15 2020 +
Provide userland notification of gpio pin changes
("userland gpio interrupts").
Maybe more likely this is causing the panic?
Doesn't make sense :-(
Can you try to fetch the latest 13-current as of now and re-build
the kernel? I noticed some issues myself which got fixed.
I did that, still panics the same way.
But, the commit above is about gpio, and I do have
'bytgpio_load="YES"' in my /boot/loader.conf
If I boot the kernel without that it works.
'kldload bytgpio' panics the machine.
Could you screenshot the panic backtrace after kldload of bytegpio ?
Sure:
panic: vm_fault_lookup: fault on nofault entry, addr:
0xfe00c96c2000
cpuid = 1
time = 1610458544
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe00c7306140
vpanic() at vpanic+0x181/frame 0xfe00c7306190
panic() at panic+0x43/frame 0xfe00c73061f0
vm_fault() at vm_fault+0x142d/frame 0xfe00c73062f0
vm_fault_trap() at vm_fault_trap+0xb1/frame 0xfe00c7306340
trap_pfault() at trap_pfault+0x1f6/frame 0xfe00c73063a0
trap() at trap+0x280/frame 0xfe00c73064b0
calltrap() at calltrap+0x8/frame 0xfe00c73064b0
--- trap 0xc, rip = 0x80c27d08, rsp = 0xfe00c7306580,
rbp = 0xfe00c7306580 ---
lock_init() at lock_init+0xf8/frame 0xfe00c7306580
_mtx_init() at _mtx_init+0x70/frame 0xfe00c73065a0
gpioc_attach() at gpioc_attach+0x139/frame 0xfe00c7306620
device_attach() at device_attach+0x3dd/frame 0xfe00c7306670
bus_generic_attach() at bus_generic_attach+0x4b/frame
0xfe00c73066a0
gpiobus_attach_bus() at gpiobus_attach_bus+0x44/frame
0xfe00c73066c0
bytgpio_attach() at bytgpio_attach+0x1f7/frame 0xfe00c7306710
device_attach() at device_attach+0x3dd/frame 0xfe00c7306760
device_probe_and_attach() at device_probe_and_attach+0x41/frame
0xfe00c7306790
acpi_driver_added() at acpi_driver_added+0xaa/frame 0xfe00c73067c0
devclass_driver_added() at devclass_driver_added+0x3c/frame
0xfe00c7306800
devclass_add_driver() at devclass_add_driver+0x13d/frame
0xfe00c7306840
module_register_init() at module_register_init+0xa7/frame
0xfe00c7306870
linker_load_module() at linker_load_module+0xbca/frame
0xfe00c7306b80
kern_kldload() at kern_kldload+0xbb/frame 0xfe00c7306bd0
sys_kldload() at sys_kldload+0x5b/frame 0xfe00c7306c00
amd64_syscall() at amd64_syscall+0x111/frame 0xfe00c7306d30
fast_syscall_common() at fast_syscall_common+0xf8/frame
0xfe00c7306d30
--- syscall (304, FreeBSD ELF64, sys_kldload), rip = 0x80037715a,
rsp = 0x7fffe698, rbp = 0x7fffec10 ---
KDB: enter: panic
Adding Ian.
Looks like an off-by-one there.
Can you try to apply this patch manually:
diff --git a/sys/dev/gpio/gpioc.c b/sys/dev/gpio/gpioc.c
index 727b07a7058..29d795bb54b 100644
--- a/sys/dev/gpio/gpioc.c
+++ b/sys/dev/gpio/gpioc.c
@@ -582,7 +582,7 @@ gpioc_attach(device_t dev)
return (err);
sc->sc_pin_intr = malloc(sizeof(struct gpioc_pin_intr) *
sc->sc_npins,
M_GPIOC, M_WAITOK | M_ZERO);
- for (int i = 0; i <= sc->sc_npins; i++) {
+ for (int i = 0; i != sc->sc_npins; i++) {
sc->sc_pin_intr[i].pin = malloc(sizeof(struct
gpiobus_pin),
M_GPIOC, M_WAITOK | M_ZERO);
sc->sc_pin_intr[i].sc = sc;
@@ -616,7 +616,7 @@ gpioc_detach(device_t dev)
if (sc->sc_ctl_dev)
destroy_dev(sc->sc_ctl_dev);
- for (int i = 0; i <= sc->sc_npins; i++) {
+ for (int i = 0; i != sc->sc_npins; i++) {
mtx_destroy(>sc_pin_intr[i].mtx);
free(>sc_pin_intr[i].pin, M_GPIOC);
}
Yes! That works! Thank you!
Jakob
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic after updating
On Tue, 2021-01-12 at 19:56 +0100, Hans Petter Selasky wrote:
> On 1/12/21 7:45 PM, Ian Lepore wrote:
> > > > - for (int i = 0; i <= sc->sc_npins; i++) {
> > > > + for (int i = 0; i != sc->sc_npins; i++) {
> > > > mtx_destroy(>sc_pin_intr[i].mtx);
> > > > free(>sc_pin_intr[i].pin, M_GPIOC);
> > > > }
> > >
> > > --HPS
> > >
> >
> > If that is the problem, I'd rather see it fixed by using the
> > idiomatic
> > i < sc->sc_npins rather than the non-standard != test. (But I
> > don't
> > feel strongly enough about it to learn how to use git and commit
> > the
> > fix myself.)
>
> Hi Ian,
>
> I think it is more serious that the iteration variable is declared
> inside the for-loop :-)
>
> At least it is pretty obvious that the array written is one element
> too
> small. I've always used != instead of <= in for-loops. But if there
> is a
> certain style in there, I'm good with < too, though I've always seen
> <
> as an overhead compared to != , because to implement < you need a
> subtraction, while != is just a comparison ...
>
> --HPS
I thought we recently changed (or at least discussed changing) style(9)
to allow for that sort of loop-iter-var declaration.
On most of the chips I know assembly language for (mostly risc chips),
there is no difference between a comparison and a subtraction at the
chip-instruction level. That is, at the chip level, comparision
instructions are typically implemented as a subtraction that sets
condition code bits but doesn't store the result back to a register.
-- Ian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic after updating
On 1/12/21 7:45 PM, Ian Lepore wrote:
- for (int i = 0; i <= sc->sc_npins; i++) {
+ for (int i = 0; i != sc->sc_npins; i++) {
mtx_destroy(>sc_pin_intr[i].mtx);
free(>sc_pin_intr[i].pin, M_GPIOC);
}
--HPS
If that is the problem, I'd rather see it fixed by using the idiomatic
i < sc->sc_npins rather than the non-standard != test. (But I don't
feel strongly enough about it to learn how to use git and commit the
fix myself.)
Hi Ian,
I think it is more serious that the iteration variable is declared
inside the for-loop :-)
At least it is pretty obvious that the array written is one element too
small. I've always used != instead of <= in for-loops. But if there is a
certain style in there, I'm good with < too, though I've always seen <
as an overhead compared to != , because to implement < you need a
subtraction, while != is just a comparison ...
--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic after updating
On Tue, 2021-01-12 at 18:10 +0100, Hans Petter Selasky wrote:
> On 1/12/21 2:46 PM, Hans Petter Selasky wrote:
> > On 1/12/21 2:40 PM, Jakob Alvermark wrote:
> > >
> > > On 1/12/21 2:16 PM, Hans Petter Selasky wrote:
> > > > On 1/12/21 1:43 PM, Jakob Alvermark wrote:
> > > > >
> > > > > On 1/12/21 12:54 PM, Hans Petter Selasky wrote:
> > > > > > On 1/12/21 12:32 PM, Jakob Alvermark wrote:
> > > > > > > Alright, after a new bisect run I got a different result,
> > > > > > > so I
> > > > > > > most likely did something wrong the first time.
> > > > > > >
> > > > > > > ff3468ac94597efdcbc56f372528dfc98b114dac is the first bad
> > > > > > > commit
> > > > > > > commit ff3468ac94597efdcbc56f372528dfc98b114dac
> > > > > > > Author: Ian Lepore
> > > > > > > Date: Sat Dec 12 18:34:15 2020 +
> > > > > > >
> > > > > > > Provide userland notification of gpio pin changes
> > > > > > > ("userland
> > > > > > > gpio interrupts").
> > > > > > >
> > > > > > >
> > > > > > > Maybe more likely this is causing the panic?
> > > > > >
> > > > > > Doesn't make sense :-(
> > > > > >
> > > > > > Can you try to fetch the latest 13-current as of now and
> > > > > > re-build
> > > > > > the kernel? I noticed some issues myself which got fixed.
> > > > >
> > > > >
> > > > > I did that, still panics the same way.
> > > > >
> > > > > But, the commit above is about gpio, and I do have
> > > > > 'bytgpio_load="YES"' in my /boot/loader.conf
> > > > >
> > > > > If I boot the kernel without that it works.
> > > > >
> > > > > 'kldload bytgpio' panics the machine.
> > > > >
> > > >
> > > > Could you screenshot the panic backtrace after kldload of
> > > > bytegpio ?
> > >
> > > Sure:
> > >
> > > panic: vm_fault_lookup: fault on nofault entry, addr:
> > > 0xfe00c96c2000
> > > cpuid = 1
> > > time = 1610458544
> > > KDB: stack backtrace:
> > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> > > 0xfe00c7306140
> > > vpanic() at vpanic+0x181/frame 0xfe00c7306190
> > > panic() at panic+0x43/frame 0xfe00c73061f0
> > > vm_fault() at vm_fault+0x142d/frame 0xfe00c73062f0
> > > vm_fault_trap() at vm_fault_trap+0xb1/frame 0xfe00c7306340
> > > trap_pfault() at trap_pfault+0x1f6/frame 0xfe00c73063a0
> > > trap() at trap+0x280/frame 0xfe00c73064b0
> > > calltrap() at calltrap+0x8/frame 0xfe00c73064b0
> > > --- trap 0xc, rip = 0x80c27d08, rsp = 0xfe00c7306580,
> > > rbp
> > > = 0xfe00c7306580 ---
> > > lock_init() at lock_init+0xf8/frame 0xfe00c7306580
> > > _mtx_init() at _mtx_init+0x70/frame 0xfe00c73065a0
> > > gpioc_attach() at gpioc_attach+0x139/frame 0xfe00c7306620
> > > device_attach() at device_attach+0x3dd/frame 0xfe00c7306670
> > > bus_generic_attach() at bus_generic_attach+0x4b/frame
> > > 0xfe00c73066a0
> > > gpiobus_attach_bus() at gpiobus_attach_bus+0x44/frame
> > > 0xfe00c73066c0
> > > bytgpio_attach() at bytgpio_attach+0x1f7/frame 0xfe00c7306710
> > > device_attach() at device_attach+0x3dd/frame 0xfe00c7306760
> > > device_probe_and_attach() at device_probe_and_attach+0x41/frame
> > > 0xfe00c7306790
> > > acpi_driver_added() at acpi_driver_added+0xaa/frame
> > > 0xfe00c73067c0
> > > devclass_driver_added() at devclass_driver_added+0x3c/frame
> > > 0xfe00c7306800
> > > devclass_add_driver() at devclass_add_driver+0x13d/frame
> > > 0xfe00c7306840
> > > module_register_init() at module_register_init+0xa7/frame
> > > 0xfe00c7306870
> > > linker_load_module() at linker_load_module+0xbca/frame
> > > 0xfe00c7306b80
> > > kern_kldload() at kern_kldload+0xbb/frame 0xfe00c7306bd0
> > > sys_kldload() at sys_kldload+0x5b/frame 0xfe00c7306c00
> > > amd64_syscall() at amd64_syscall+0x111/frame 0xfe00c7306d30
> > > fast_syscall_common() at fast_syscall_common+0xf8/frame
> > > 0xfe00c7306d30
> > > --- syscall (304, FreeBSD ELF64, sys_kldload), rip = 0x80037715a,
> > > rsp
> > > = 0x7fffe698, rbp = 0x7fffec10 ---
> > > KDB: enter: panic
> > >
> >
> > Adding Ian.
> >
>
> Looks like an off-by-one there.
>
> Can you try to apply this patch manually:
>
> > diff --git a/sys/dev/gpio/gpioc.c b/sys/dev/gpio/gpioc.c
> > index 727b07a7058..29d795bb54b 100644
> > --- a/sys/dev/gpio/gpioc.c
> > +++ b/sys/dev/gpio/gpioc.c
> > @@ -582,7 +582,7 @@ gpioc_attach(device_t dev)
> > return (err);
> > sc->sc_pin_intr = malloc(sizeof(struct gpioc_pin_intr) *
> > sc->sc_npins,
> > M_GPIOC, M_WAITOK | M_ZERO);
> > - for (int i = 0; i <= sc->sc_npins; i++) {
> > + for (int i = 0; i != sc->sc_npins; i++) {
> > sc->sc_pin_intr[i].pin = malloc(sizeof(struct
> > gpiobus_pin),
> > M_GPIOC, M_WAITOK | M_ZERO);
> > sc->sc_pin_intr[i].sc = sc;
> > @@ -616,7 +616,7 @@ gpioc_detach(device_t dev)
> > if (sc->sc_ctl_dev)
> > destroy_dev(sc->sc_ctl_dev);
> >
> > - for (int i =
Re: Panic after updating
On 1/12/21 2:46 PM, Hans Petter Selasky wrote:
On 1/12/21 2:40 PM, Jakob Alvermark wrote:
On 1/12/21 2:16 PM, Hans Petter Selasky wrote:
On 1/12/21 1:43 PM, Jakob Alvermark wrote:
On 1/12/21 12:54 PM, Hans Petter Selasky wrote:
On 1/12/21 12:32 PM, Jakob Alvermark wrote:
Alright, after a new bisect run I got a different result, so I
most likely did something wrong the first time.
ff3468ac94597efdcbc56f372528dfc98b114dac is the first bad commit
commit ff3468ac94597efdcbc56f372528dfc98b114dac
Author: Ian Lepore
Date: Sat Dec 12 18:34:15 2020 +
Provide userland notification of gpio pin changes ("userland
gpio interrupts").
Maybe more likely this is causing the panic?
Doesn't make sense :-(
Can you try to fetch the latest 13-current as of now and re-build
the kernel? I noticed some issues myself which got fixed.
I did that, still panics the same way.
But, the commit above is about gpio, and I do have
'bytgpio_load="YES"' in my /boot/loader.conf
If I boot the kernel without that it works.
'kldload bytgpio' panics the machine.
Could you screenshot the panic backtrace after kldload of bytegpio ?
Sure:
panic: vm_fault_lookup: fault on nofault entry, addr: 0xfe00c96c2000
cpuid = 1
time = 1610458544
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe00c7306140
vpanic() at vpanic+0x181/frame 0xfe00c7306190
panic() at panic+0x43/frame 0xfe00c73061f0
vm_fault() at vm_fault+0x142d/frame 0xfe00c73062f0
vm_fault_trap() at vm_fault_trap+0xb1/frame 0xfe00c7306340
trap_pfault() at trap_pfault+0x1f6/frame 0xfe00c73063a0
trap() at trap+0x280/frame 0xfe00c73064b0
calltrap() at calltrap+0x8/frame 0xfe00c73064b0
--- trap 0xc, rip = 0x80c27d08, rsp = 0xfe00c7306580, rbp
= 0xfe00c7306580 ---
lock_init() at lock_init+0xf8/frame 0xfe00c7306580
_mtx_init() at _mtx_init+0x70/frame 0xfe00c73065a0
gpioc_attach() at gpioc_attach+0x139/frame 0xfe00c7306620
device_attach() at device_attach+0x3dd/frame 0xfe00c7306670
bus_generic_attach() at bus_generic_attach+0x4b/frame 0xfe00c73066a0
gpiobus_attach_bus() at gpiobus_attach_bus+0x44/frame 0xfe00c73066c0
bytgpio_attach() at bytgpio_attach+0x1f7/frame 0xfe00c7306710
device_attach() at device_attach+0x3dd/frame 0xfe00c7306760
device_probe_and_attach() at device_probe_and_attach+0x41/frame
0xfe00c7306790
acpi_driver_added() at acpi_driver_added+0xaa/frame 0xfe00c73067c0
devclass_driver_added() at devclass_driver_added+0x3c/frame
0xfe00c7306800
devclass_add_driver() at devclass_add_driver+0x13d/frame
0xfe00c7306840
module_register_init() at module_register_init+0xa7/frame
0xfe00c7306870
linker_load_module() at linker_load_module+0xbca/frame 0xfe00c7306b80
kern_kldload() at kern_kldload+0xbb/frame 0xfe00c7306bd0
sys_kldload() at sys_kldload+0x5b/frame 0xfe00c7306c00
amd64_syscall() at amd64_syscall+0x111/frame 0xfe00c7306d30
fast_syscall_common() at fast_syscall_common+0xf8/frame
0xfe00c7306d30
--- syscall (304, FreeBSD ELF64, sys_kldload), rip = 0x80037715a, rsp
= 0x7fffe698, rbp = 0x7fffec10 ---
KDB: enter: panic
Adding Ian.
Looks like an off-by-one there.
Can you try to apply this patch manually:
diff --git a/sys/dev/gpio/gpioc.c b/sys/dev/gpio/gpioc.c
index 727b07a7058..29d795bb54b 100644
--- a/sys/dev/gpio/gpioc.c
+++ b/sys/dev/gpio/gpioc.c
@@ -582,7 +582,7 @@ gpioc_attach(device_t dev)
return (err);
sc->sc_pin_intr = malloc(sizeof(struct gpioc_pin_intr) * sc->sc_npins,
M_GPIOC, M_WAITOK | M_ZERO);
- for (int i = 0; i <= sc->sc_npins; i++) {
+ for (int i = 0; i != sc->sc_npins; i++) {
sc->sc_pin_intr[i].pin = malloc(sizeof(struct gpiobus_pin),
M_GPIOC, M_WAITOK | M_ZERO);
sc->sc_pin_intr[i].sc = sc;
@@ -616,7 +616,7 @@ gpioc_detach(device_t dev)
if (sc->sc_ctl_dev)
destroy_dev(sc->sc_ctl_dev);
- for (int i = 0; i <= sc->sc_npins; i++) {
+ for (int i = 0; i != sc->sc_npins; i++) {
mtx_destroy(>sc_pin_intr[i].mtx);
free(>sc_pin_intr[i].pin, M_GPIOC);
}
--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic after updating
On 1/12/21 2:40 PM, Jakob Alvermark wrote:
On 1/12/21 2:16 PM, Hans Petter Selasky wrote:
On 1/12/21 1:43 PM, Jakob Alvermark wrote:
On 1/12/21 12:54 PM, Hans Petter Selasky wrote:
On 1/12/21 12:32 PM, Jakob Alvermark wrote:
Alright, after a new bisect run I got a different result, so I most
likely did something wrong the first time.
ff3468ac94597efdcbc56f372528dfc98b114dac is the first bad commit
commit ff3468ac94597efdcbc56f372528dfc98b114dac
Author: Ian Lepore
Date: Sat Dec 12 18:34:15 2020 +
Provide userland notification of gpio pin changes ("userland
gpio interrupts").
Maybe more likely this is causing the panic?
Doesn't make sense :-(
Can you try to fetch the latest 13-current as of now and re-build
the kernel? I noticed some issues myself which got fixed.
I did that, still panics the same way.
But, the commit above is about gpio, and I do have
'bytgpio_load="YES"' in my /boot/loader.conf
If I boot the kernel without that it works.
'kldload bytgpio' panics the machine.
Could you screenshot the panic backtrace after kldload of bytegpio ?
Sure:
panic: vm_fault_lookup: fault on nofault entry, addr: 0xfe00c96c2000
cpuid = 1
time = 1610458544
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe00c7306140
vpanic() at vpanic+0x181/frame 0xfe00c7306190
panic() at panic+0x43/frame 0xfe00c73061f0
vm_fault() at vm_fault+0x142d/frame 0xfe00c73062f0
vm_fault_trap() at vm_fault_trap+0xb1/frame 0xfe00c7306340
trap_pfault() at trap_pfault+0x1f6/frame 0xfe00c73063a0
trap() at trap+0x280/frame 0xfe00c73064b0
calltrap() at calltrap+0x8/frame 0xfe00c73064b0
--- trap 0xc, rip = 0x80c27d08, rsp = 0xfe00c7306580, rbp =
0xfe00c7306580 ---
lock_init() at lock_init+0xf8/frame 0xfe00c7306580
_mtx_init() at _mtx_init+0x70/frame 0xfe00c73065a0
gpioc_attach() at gpioc_attach+0x139/frame 0xfe00c7306620
device_attach() at device_attach+0x3dd/frame 0xfe00c7306670
bus_generic_attach() at bus_generic_attach+0x4b/frame 0xfe00c73066a0
gpiobus_attach_bus() at gpiobus_attach_bus+0x44/frame 0xfe00c73066c0
bytgpio_attach() at bytgpio_attach+0x1f7/frame 0xfe00c7306710
device_attach() at device_attach+0x3dd/frame 0xfe00c7306760
device_probe_and_attach() at device_probe_and_attach+0x41/frame
0xfe00c7306790
acpi_driver_added() at acpi_driver_added+0xaa/frame 0xfe00c73067c0
devclass_driver_added() at devclass_driver_added+0x3c/frame
0xfe00c7306800
devclass_add_driver() at devclass_add_driver+0x13d/frame 0xfe00c7306840
module_register_init() at module_register_init+0xa7/frame
0xfe00c7306870
linker_load_module() at linker_load_module+0xbca/frame 0xfe00c7306b80
kern_kldload() at kern_kldload+0xbb/frame 0xfe00c7306bd0
sys_kldload() at sys_kldload+0x5b/frame 0xfe00c7306c00
amd64_syscall() at amd64_syscall+0x111/frame 0xfe00c7306d30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe00c7306d30
--- syscall (304, FreeBSD ELF64, sys_kldload), rip = 0x80037715a, rsp =
0x7fffe698, rbp = 0x7fffec10 ---
KDB: enter: panic
Adding Ian.
--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic after updating
On 1/12/21 2:16 PM, Hans Petter Selasky wrote:
On 1/12/21 1:43 PM, Jakob Alvermark wrote:
On 1/12/21 12:54 PM, Hans Petter Selasky wrote:
On 1/12/21 12:32 PM, Jakob Alvermark wrote:
Alright, after a new bisect run I got a different result, so I most
likely did something wrong the first time.
ff3468ac94597efdcbc56f372528dfc98b114dac is the first bad commit
commit ff3468ac94597efdcbc56f372528dfc98b114dac
Author: Ian Lepore
Date: Sat Dec 12 18:34:15 2020 +
Provide userland notification of gpio pin changes ("userland
gpio interrupts").
Maybe more likely this is causing the panic?
Doesn't make sense :-(
Can you try to fetch the latest 13-current as of now and re-build
the kernel? I noticed some issues myself which got fixed.
I did that, still panics the same way.
But, the commit above is about gpio, and I do have
'bytgpio_load="YES"' in my /boot/loader.conf
If I boot the kernel without that it works.
'kldload bytgpio' panics the machine.
Could you screenshot the panic backtrace after kldload of bytegpio ?
Sure:
panic: vm_fault_lookup: fault on nofault entry, addr: 0xfe00c96c2000
cpuid = 1
time = 1610458544
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe00c7306140
vpanic() at vpanic+0x181/frame 0xfe00c7306190
panic() at panic+0x43/frame 0xfe00c73061f0
vm_fault() at vm_fault+0x142d/frame 0xfe00c73062f0
vm_fault_trap() at vm_fault_trap+0xb1/frame 0xfe00c7306340
trap_pfault() at trap_pfault+0x1f6/frame 0xfe00c73063a0
trap() at trap+0x280/frame 0xfe00c73064b0
calltrap() at calltrap+0x8/frame 0xfe00c73064b0
--- trap 0xc, rip = 0x80c27d08, rsp = 0xfe00c7306580, rbp =
0xfe00c7306580 ---
lock_init() at lock_init+0xf8/frame 0xfe00c7306580
_mtx_init() at _mtx_init+0x70/frame 0xfe00c73065a0
gpioc_attach() at gpioc_attach+0x139/frame 0xfe00c7306620
device_attach() at device_attach+0x3dd/frame 0xfe00c7306670
bus_generic_attach() at bus_generic_attach+0x4b/frame 0xfe00c73066a0
gpiobus_attach_bus() at gpiobus_attach_bus+0x44/frame 0xfe00c73066c0
bytgpio_attach() at bytgpio_attach+0x1f7/frame 0xfe00c7306710
device_attach() at device_attach+0x3dd/frame 0xfe00c7306760
device_probe_and_attach() at device_probe_and_attach+0x41/frame
0xfe00c7306790
acpi_driver_added() at acpi_driver_added+0xaa/frame 0xfe00c73067c0
devclass_driver_added() at devclass_driver_added+0x3c/frame
0xfe00c7306800
devclass_add_driver() at devclass_add_driver+0x13d/frame 0xfe00c7306840
module_register_init() at module_register_init+0xa7/frame 0xfe00c7306870
linker_load_module() at linker_load_module+0xbca/frame 0xfe00c7306b80
kern_kldload() at kern_kldload+0xbb/frame 0xfe00c7306bd0
sys_kldload() at sys_kldload+0x5b/frame 0xfe00c7306c00
amd64_syscall() at amd64_syscall+0x111/frame 0xfe00c7306d30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe00c7306d30
--- syscall (304, FreeBSD ELF64, sys_kldload), rip = 0x80037715a, rsp =
0x7fffe698, rbp = 0x7fffec10 ---
KDB: enter: panic
Jakob
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic after updating
On 1/12/21 1:43 PM, Jakob Alvermark wrote:
On 1/12/21 12:54 PM, Hans Petter Selasky wrote:
On 1/12/21 12:32 PM, Jakob Alvermark wrote:
Alright, after a new bisect run I got a different result, so I most
likely did something wrong the first time.
ff3468ac94597efdcbc56f372528dfc98b114dac is the first bad commit
commit ff3468ac94597efdcbc56f372528dfc98b114dac
Author: Ian Lepore
Date: Sat Dec 12 18:34:15 2020 +
Provide userland notification of gpio pin changes ("userland
gpio interrupts").
Maybe more likely this is causing the panic?
Doesn't make sense :-(
Can you try to fetch the latest 13-current as of now and re-build the
kernel? I noticed some issues myself which got fixed.
I did that, still panics the same way.
But, the commit above is about gpio, and I do have 'bytgpio_load="YES"'
in my /boot/loader.conf
If I boot the kernel without that it works.
'kldload bytgpio' panics the machine.
Could you screenshot the panic backtrace after kldload of bytegpio ?
--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic after updating
On 1/12/21 12:54 PM, Hans Petter Selasky wrote:
On 1/12/21 12:32 PM, Jakob Alvermark wrote:
Alright, after a new bisect run I got a different result, so I most
likely did something wrong the first time.
ff3468ac94597efdcbc56f372528dfc98b114dac is the first bad commit
commit ff3468ac94597efdcbc56f372528dfc98b114dac
Author: Ian Lepore
Date: Sat Dec 12 18:34:15 2020 +
Provide userland notification of gpio pin changes ("userland
gpio interrupts").
Maybe more likely this is causing the panic?
Doesn't make sense :-(
Can you try to fetch the latest 13-current as of now and re-build the
kernel? I noticed some issues myself which got fixed.
I did that, still panics the same way.
But, the commit above is about gpio, and I do have 'bytgpio_load="YES"'
in my /boot/loader.conf
If I boot the kernel without that it works.
'kldload bytgpio' panics the machine.
Jakob
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic after updating
On 1/12/21 12:32 PM, Jakob Alvermark wrote:
Alright, after a new bisect run I got a different result, so I most
likely did something wrong the first time.
ff3468ac94597efdcbc56f372528dfc98b114dac is the first bad commit
commit ff3468ac94597efdcbc56f372528dfc98b114dac
Author: Ian Lepore
Date: Sat Dec 12 18:34:15 2020 +
Provide userland notification of gpio pin changes ("userland gpio
interrupts").
Maybe more likely this is causing the panic?
Doesn't make sense :-(
Can you try to fetch the latest 13-current as of now and re-build the
kernel? I noticed some issues myself which got fixed.
--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic after updating
On 1/12/21 9:33 AM, Jakob Alvermark wrote:
On 1/11/21 7:08 PM, Hans Petter Selasky wrote:
On 1/11/21 5:24 PM, Jakob Alvermark wrote:
On 1/11/21 1:14 PM, Hans Petter Selasky wrote:
On 1/11/21 11:12 AM, Jakob Alvermark wrote:
Updated my Acer laptop from r367734 to main-c255666-g1790f5e654f
Rebooting with the newly build kernel i get this panic.
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 02
fault virtual address = 0x103
fault code = supervisor read data,
instruction pointer = 0x20:0x809e5265
stack pointer = 0x28:0x8281db70
frame pointer = 0x28:0x8281db70
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 12 (irq88: xhci0)
trap number = 12
panic: page fault
cpuid = 1
time = 2
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0x8281d820
vpanic() at vpanic+0x181/frame 0x8281d870
panic() at panic+0x43/frame 0x8281d8d0
trap_fatal() at trap_fatal+0x387/frame 0x8281d930
trap_pfault() at trap_pfault+0x4f/frame 0x8281d990
trap() at trap+0x280/frame 0x8281daa0
calltrap() at calltrap+0x8/frame 0x8281daa0
--- trap 0xc, rip = 0x809e5265, rsp =
0x8281db70, rbp = 0x8281db70 ---
usbd_get_page() at usbd_get_page+0x65/frame 0x8281db70
xhci_interrupt_poll() at xhci_interrupt_poll+0x29/frame
0x8281dc20
xhci_interrupt() at xhci_interrupt+0x11a/frame 0x8281dc60
ithread_loop() at ithread_loop+0x24f/frame 0x8281dcf0
fork_exit() at fork_exit+0x7e/frame 0x8281dd30
fork_trampoline() at fork_trampoline+0xe/frame 0x8281dd30
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
Any help appreciated.
Hi,
If you could bi-sect that panic, would be great.
Else install gdb from ports and run:
kgdb101
info line *(usbd_get_page+0x65)
Having just learned how to bisect (thanks Warner for the mini
primer) this is the result:
de0b2d4f47bad36025dcf52755ce76cca6e715d9 is the first bad commit
You mean this commit is causing the panic?
git show de0b2d4f47bad36025dcf52755ce76cca6e715d9
commit de0b2d4f47bad36025dcf52755ce76cca6e715d9
Author: Mateusz Guzik
Date: Sun Dec 13 21:30:42 2020 +
Patch annotation in sigdeferstop
Probability flipped since sigdefer handling was moved away
from regular VOP
calls.
Notes:
svn path=/head/; revision=368616
diff --git a/sys/sys/signalvar.h b/sys/sys/signalvar.h
index 93ef15bbbf0..df761a1e1a5 100644
--- a/sys/sys/signalvar.h
+++ b/sys/sys/signalvar.h
@@ -367,7 +367,7 @@ static inline int
sigdeferstop(int mode)
{
- if (__predict_true(mode == SIGDEFERSTOP_NOP))
+ if (__predict_false(mode == SIGDEFERSTOP_NOP))
return (SIGDEFERSTOP_VAL_NCHG);
return (sigdeferstop_impl(mode));
}
It appears so. Mind you, this is the first time I have done a bisect,
I may have made a mistake.
And:
git show de0b2d4f47bad36025dcf52755ce76cca6e715d9 | patch -p1 -R
gets you a working kernel?
No... So I probably made a mistake in bisecting. I will try again.
Alright, after a new bisect run I got a different result, so I most
likely did something wrong the first time.
ff3468ac94597efdcbc56f372528dfc98b114dac is the first bad commit
commit ff3468ac94597efdcbc56f372528dfc98b114dac
Author: Ian Lepore
Date: Sat Dec 12 18:34:15 2020 +
Provide userland notification of gpio pin changes ("userland gpio
interrupts").
Maybe more likely this is causing the panic?
Jakob
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic after updating
On 1/11/21 7:08 PM, Hans Petter Selasky wrote:
On 1/11/21 5:24 PM, Jakob Alvermark wrote:
On 1/11/21 1:14 PM, Hans Petter Selasky wrote:
On 1/11/21 11:12 AM, Jakob Alvermark wrote:
Updated my Acer laptop from r367734 to main-c255666-g1790f5e654f
Rebooting with the newly build kernel i get this panic.
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 02
fault virtual address = 0x103
fault code = supervisor read data,
instruction pointer = 0x20:0x809e5265
stack pointer = 0x28:0x8281db70
frame pointer = 0x28:0x8281db70
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 12 (irq88: xhci0)
trap number = 12
panic: page fault
cpuid = 1
time = 2
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0x8281d820
vpanic() at vpanic+0x181/frame 0x8281d870
panic() at panic+0x43/frame 0x8281d8d0
trap_fatal() at trap_fatal+0x387/frame 0x8281d930
trap_pfault() at trap_pfault+0x4f/frame 0x8281d990
trap() at trap+0x280/frame 0x8281daa0
calltrap() at calltrap+0x8/frame 0x8281daa0
--- trap 0xc, rip = 0x809e5265, rsp =
0x8281db70, rbp = 0x8281db70 ---
usbd_get_page() at usbd_get_page+0x65/frame 0x8281db70
xhci_interrupt_poll() at xhci_interrupt_poll+0x29/frame
0x8281dc20
xhci_interrupt() at xhci_interrupt+0x11a/frame 0x8281dc60
ithread_loop() at ithread_loop+0x24f/frame 0x8281dcf0
fork_exit() at fork_exit+0x7e/frame 0x8281dd30
fork_trampoline() at fork_trampoline+0xe/frame 0x8281dd30
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
Any help appreciated.
Hi,
If you could bi-sect that panic, would be great.
Else install gdb from ports and run:
kgdb101
info line *(usbd_get_page+0x65)
Having just learned how to bisect (thanks Warner for the mini primer)
this is the result:
de0b2d4f47bad36025dcf52755ce76cca6e715d9 is the first bad commit
You mean this commit is causing the panic?
git show de0b2d4f47bad36025dcf52755ce76cca6e715d9
commit de0b2d4f47bad36025dcf52755ce76cca6e715d9
Author: Mateusz Guzik
Date: Sun Dec 13 21:30:42 2020 +
Patch annotation in sigdeferstop
Probability flipped since sigdefer handling was moved away
from regular VOP
calls.
Notes:
svn path=/head/; revision=368616
diff --git a/sys/sys/signalvar.h b/sys/sys/signalvar.h
index 93ef15bbbf0..df761a1e1a5 100644
--- a/sys/sys/signalvar.h
+++ b/sys/sys/signalvar.h
@@ -367,7 +367,7 @@ static inline int
sigdeferstop(int mode)
{
- if (__predict_true(mode == SIGDEFERSTOP_NOP))
+ if (__predict_false(mode == SIGDEFERSTOP_NOP))
return (SIGDEFERSTOP_VAL_NCHG);
return (sigdeferstop_impl(mode));
}
It appears so. Mind you, this is the first time I have done a bisect, I
may have made a mistake.
And:
git show de0b2d4f47bad36025dcf52755ce76cca6e715d9 | patch -p1 -R
gets you a working kernel?
No... So I probably made a mistake in bisecting. I will try again.
Jakob
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic after updating
On 1/11/21 5:24 PM, Jakob Alvermark wrote:
On 1/11/21 1:14 PM, Hans Petter Selasky wrote:
On 1/11/21 11:12 AM, Jakob Alvermark wrote:
Updated my Acer laptop from r367734 to main-c255666-g1790f5e654f
Rebooting with the newly build kernel i get this panic.
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 02
fault virtual address = 0x103
fault code = supervisor read data,
instruction pointer = 0x20:0x809e5265
stack pointer = 0x28:0x8281db70
frame pointer = 0x28:0x8281db70
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 12 (irq88: xhci0)
trap number = 12
panic: page fault
cpuid = 1
time = 2
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0x8281d820
vpanic() at vpanic+0x181/frame 0x8281d870
panic() at panic+0x43/frame 0x8281d8d0
trap_fatal() at trap_fatal+0x387/frame 0x8281d930
trap_pfault() at trap_pfault+0x4f/frame 0x8281d990
trap() at trap+0x280/frame 0x8281daa0
calltrap() at calltrap+0x8/frame 0x8281daa0
--- trap 0xc, rip = 0x809e5265, rsp = 0x8281db70,
rbp = 0x8281db70 ---
usbd_get_page() at usbd_get_page+0x65/frame 0x8281db70
xhci_interrupt_poll() at xhci_interrupt_poll+0x29/frame
0x8281dc20
xhci_interrupt() at xhci_interrupt+0x11a/frame 0x8281dc60
ithread_loop() at ithread_loop+0x24f/frame 0x8281dcf0
fork_exit() at fork_exit+0x7e/frame 0x8281dd30
fork_trampoline() at fork_trampoline+0xe/frame 0x8281dd30
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
Any help appreciated.
Hi,
If you could bi-sect that panic, would be great.
Else install gdb from ports and run:
kgdb101
info line *(usbd_get_page+0x65)
Having just learned how to bisect (thanks Warner for the mini primer)
this is the result:
de0b2d4f47bad36025dcf52755ce76cca6e715d9 is the first bad commit
You mean this commit is causing the panic?
git show de0b2d4f47bad36025dcf52755ce76cca6e715d9
commit de0b2d4f47bad36025dcf52755ce76cca6e715d9
Author: Mateusz Guzik
Date: Sun Dec 13 21:30:42 2020 +
Patch annotation in sigdeferstop
Probability flipped since sigdefer handling was moved away from regular VOP
calls.
Notes:
svn path=/head/; revision=368616
diff --git a/sys/sys/signalvar.h b/sys/sys/signalvar.h
index 93ef15bbbf0..df761a1e1a5 100644
--- a/sys/sys/signalvar.h
+++ b/sys/sys/signalvar.h
@@ -367,7 +367,7 @@ static inline int
sigdeferstop(int mode)
{
- if (__predict_true(mode == SIGDEFERSTOP_NOP))
+ if (__predict_false(mode == SIGDEFERSTOP_NOP))
return (SIGDEFERSTOP_VAL_NCHG);
return (sigdeferstop_impl(mode));
}
And:
git show de0b2d4f47bad36025dcf52755ce76cca6e715d9 | patch -p1 -R
gets you a working kernel?
--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic after updating
On 1/11/21 6:07 PM, Matthias Apitz wrote: On Mon, 11 Jan 2021 17:24:39 +0100, Jakob Alvermark wrote: On 1/11/21 1:14 PM, Hans Petter Selasky wrote: On 1/11/21 11:12 AM, Jakob Alvermark wrote: Updated my Acer laptop from r367734 to main-c255666-g1790f5e654f Rebooting with the newly build kernel i get this panic. Fataltrap 12: page fault while in kernel mode cpuid= 1; apic id = 02 faultvirtual address = 0x103 faultcode= supervisor read data, instructionpointer = 0x20:0x809e5265 stackpointer = 0x28:0x8281db70 framepointer = 0x28:0x8281db70 codesegment = base 0x0, limit 0xf, type 0x1b =DPL 0, pres 1, long 1, def32 0, gran 1 processoreflags = interrupt enabled, resume, IOPL = 0 currentprocess = 12 (irq88: xhci0) trapnumber = 12 panic:page fault cpuid= 1 time= 2 KDB:stack backtrace: db_trace_self_wrapper()at db_trace_self_wrapper+0x2b/frame 0x8281d820 vpanic()at vpanic+0x181/frame 0x8281d870 panic()at panic+0x43/frame 0x8281d8d0 trap_fatal()at trap_fatal+0x387/frame 0x8281d930 trap_pfault()at trap_pfault+0x4f/frame 0x8281d990 trap()at trap+0x280/frame 0x8281daa0 calltrap()at calltrap+0x8/frame 0x8281daa0 ---trap 0xc, rip = 0x809e5265, rsp = 0x8281db70, rbp = 0x8281db70 --- usbd_get_page()at usbd_get_page+0x65/frame 0x8281db70 xhci_interrupt_poll()at xhci_interrupt_poll+0x29/frame 0x8281dc20 xhci_interrupt()at xhci_interrupt+0x11a/frame 0x8281dc60 ithread_loop()at ithread_loop+0x24f/frame 0x8281dcf0 fork_exit()at fork_exit+0x7e/frame 0x8281dd30 fork_trampoline()at fork_trampoline+0xe/frame 0x8281dd30 ---trap 0, rip = 0, rsp = 0, rbp = 0 --- KDB:enter: panic Any help appreciated. Hi, If you could bi-sect that panic, would be great. Else install gdb from ports and run: kgdb101 info line *(usbd_get_page+0x65) Having just learned how to bisect (thanks Warner for the mini primer) this is the result: de0b2d4f47bad36025dcf52755ce76cca6e715d9 is the first bad commit Jakob Can you please share this mini primer or a link to it. TIA Matthias Absolutely! https://github.com/bsdimp/freebsd-git-docs/blob/main/mini-primer.md Jakob ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic after updating
On Mon, 11 Jan 2021 17:24:39 +0100, Jakob Alvermark wrote: > > On 1/11/21 1:14 PM, Hans Petter Selasky wrote: >> On 1/11/21 11:12 AM, Jakob Alvermark wrote: >>> >>> Updated my Acer laptop from r367734 to main-c255666-g1790f5e654f >>> >>> >>> Rebooting with the newly build kernel i get this panic. >>> >>> >>> Fataltrap 12: page fault while in kernel mode >>> >>> cpuid= 1; apic id = 02 >>> faultvirtual address = 0x103 >>> faultcode= supervisor read data, >>> >>> instructionpointer = 0x20:0x809e5265 >>> stackpointer = 0x28:0x8281db70 >>> framepointer = 0x28:0x8281db70 >>> codesegment = base 0x0, limit 0xf, type 0x1b >>> =DPL 0, pres 1, long 1, def32 0, gran 1 >>> processoreflags = interrupt enabled, resume, IOPL = 0 >>> currentprocess = 12 (irq88: xhci0) >>> trapnumber = 12 >>> panic:page fault >>> cpuid= 1 >>> time= 2 >>> KDB:stack backtrace: >>> db_trace_self_wrapper()at db_trace_self_wrapper+0x2b/frame >>> 0x8281d820 >>> vpanic()at vpanic+0x181/frame 0x8281d870 >>> panic()at panic+0x43/frame 0x8281d8d0 >>> trap_fatal()at trap_fatal+0x387/frame 0x8281d930 >>> trap_pfault()at trap_pfault+0x4f/frame 0x8281d990 >>> trap()at trap+0x280/frame 0x8281daa0 >>> calltrap()at calltrap+0x8/frame 0x8281daa0 >>> ---trap 0xc, rip = 0x809e5265, rsp = 0x8281db70, >>> rbp = 0x8281db70 --- >>> usbd_get_page()at usbd_get_page+0x65/frame 0x8281db70 >>> xhci_interrupt_poll()at xhci_interrupt_poll+0x29/frame >>> 0x8281dc20 >>> xhci_interrupt()at xhci_interrupt+0x11a/frame 0x8281dc60 >>> ithread_loop()at ithread_loop+0x24f/frame 0x8281dcf0 >>> fork_exit()at fork_exit+0x7e/frame 0x8281dd30 >>> fork_trampoline()at fork_trampoline+0xe/frame 0x8281dd30 >>> ---trap 0, rip = 0, rsp = 0, rbp = 0 --- >>> KDB:enter: panic >>> >>> >>> Any help appreciated. >> >> Hi, >> >> If you could bi-sect that panic, would be great. >> >> Else install gdb from ports and run: >> >> kgdb101 >> >> info line *(usbd_get_page+0x65) >> >> > > Having just learned how to bisect (thanks Warner for the mini primer) > this is the result: > > de0b2d4f47bad36025dcf52755ce76cca6e715d9 is the first bad commit > > Jakob > Can you please share this mini primer or a link to it. TIA Matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Без книги нет знания, без знания нет коммунизма (Влaдимир Ильич Ленин) Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin) Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin) -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Без книги нет знания, без знания нет коммунизма (Влaдимир Ильич Ленин) Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin) Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic after updating
On 1/11/21 1:14 PM, Hans Petter Selasky wrote: On 1/11/21 11:12 AM, Jakob Alvermark wrote: Updated my Acer laptop from r367734 to main-c255666-g1790f5e654f Rebooting with the newly build kernel i get this panic. Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 02 fault virtual address = 0x103 fault code = supervisor read data, instruction pointer = 0x20:0x809e5265 stack pointer = 0x28:0x8281db70 frame pointer = 0x28:0x8281db70 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq88: xhci0) trap number = 12 panic: page fault cpuid = 1 time = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x8281d820 vpanic() at vpanic+0x181/frame 0x8281d870 panic() at panic+0x43/frame 0x8281d8d0 trap_fatal() at trap_fatal+0x387/frame 0x8281d930 trap_pfault() at trap_pfault+0x4f/frame 0x8281d990 trap() at trap+0x280/frame 0x8281daa0 calltrap() at calltrap+0x8/frame 0x8281daa0 --- trap 0xc, rip = 0x809e5265, rsp = 0x8281db70, rbp = 0x8281db70 --- usbd_get_page() at usbd_get_page+0x65/frame 0x8281db70 xhci_interrupt_poll() at xhci_interrupt_poll+0x29/frame 0x8281dc20 xhci_interrupt() at xhci_interrupt+0x11a/frame 0x8281dc60 ithread_loop() at ithread_loop+0x24f/frame 0x8281dcf0 fork_exit() at fork_exit+0x7e/frame 0x8281dd30 fork_trampoline() at fork_trampoline+0xe/frame 0x8281dd30 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- KDB: enter: panic Any help appreciated. Hi, If you could bi-sect that panic, would be great. Else install gdb from ports and run: kgdb101 info line *(usbd_get_page+0x65) Having just learned how to bisect (thanks Warner for the mini primer) this is the result: de0b2d4f47bad36025dcf52755ce76cca6e715d9 is the first bad commit Jakob ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic after updating
On 1/11/21 11:12 AM, Jakob Alvermark wrote: Updated my Acer laptop from r367734 to main-c255666-g1790f5e654f Rebooting with the newly build kernel i get this panic. Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 02 fault virtual address = 0x103 fault code = supervisor read data, instruction pointer = 0x20:0x809e5265 stack pointer = 0x28:0x8281db70 frame pointer = 0x28:0x8281db70 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq88: xhci0) trap number = 12 panic: page fault cpuid = 1 time = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x8281d820 vpanic() at vpanic+0x181/frame 0x8281d870 panic() at panic+0x43/frame 0x8281d8d0 trap_fatal() at trap_fatal+0x387/frame 0x8281d930 trap_pfault() at trap_pfault+0x4f/frame 0x8281d990 trap() at trap+0x280/frame 0x8281daa0 calltrap() at calltrap+0x8/frame 0x8281daa0 --- trap 0xc, rip = 0x809e5265, rsp = 0x8281db70, rbp = 0x8281db70 --- usbd_get_page() at usbd_get_page+0x65/frame 0x8281db70 xhci_interrupt_poll() at xhci_interrupt_poll+0x29/frame 0x8281dc20 xhci_interrupt() at xhci_interrupt+0x11a/frame 0x8281dc60 ithread_loop() at ithread_loop+0x24f/frame 0x8281dcf0 fork_exit() at fork_exit+0x7e/frame 0x8281dd30 fork_trampoline() at fork_trampoline+0xe/frame 0x8281dd30 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- KDB: enter: panic Any help appreciated. Hi, If you could bi-sect that panic, would be great. Else install gdb from ports and run: kgdb101 info line *(usbd_get_page+0x65) It looks like a recursive panic, so the backtrace you see there is just for polling the keyboard, which apparently fails. --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Panic after updating
Updated my Acer laptop from r367734 to main-c255666-g1790f5e654f Rebooting with the newly build kernel i get this panic. Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 02 fault virtual address = 0x103 fault code = supervisor read data, instruction pointer = 0x20:0x809e5265 stack pointer = 0x28:0x8281db70 frame pointer = 0x28:0x8281db70 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq88: xhci0) trap number = 12 panic: page fault cpuid = 1 time = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x8281d820 vpanic() at vpanic+0x181/frame 0x8281d870 panic() at panic+0x43/frame 0x8281d8d0 trap_fatal() at trap_fatal+0x387/frame 0x8281d930 trap_pfault() at trap_pfault+0x4f/frame 0x8281d990 trap() at trap+0x280/frame 0x8281daa0 calltrap() at calltrap+0x8/frame 0x8281daa0 --- trap 0xc, rip = 0x809e5265, rsp = 0x8281db70, rbp = 0x8281db70 --- usbd_get_page() at usbd_get_page+0x65/frame 0x8281db70 xhci_interrupt_poll() at xhci_interrupt_poll+0x29/frame 0x8281dc20 xhci_interrupt() at xhci_interrupt+0x11a/frame 0x8281dc60 ithread_loop() at ithread_loop+0x24f/frame 0x8281dcf0 fork_exit() at fork_exit+0x7e/frame 0x8281dd30 fork_trampoline() at fork_trampoline+0xe/frame 0x8281dd30 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- KDB: enter: panic Any help appreciated. Jakob ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
