Re: kernel panic 7.0-current
On Sat, Feb 05, 2022 at 01:35:58PM +1100, Jonathan Gray wrote: > On Sat, Feb 05, 2022 at 12:46:06AM +0100, Joel Carnat wrote: > > Hi, > > > > I have just reinstalled my ThinkPad T460s from scratch using 2022/02/04 > > snapshot. xenodm is configured to start automatically. But since I move my > > USB mouse, the laptop freezes. > > > > If I force a reboot, wait for xenodm to popup and switch to a console using > > Ctrl-Alt-F1, I can log in. > > > > But even on the console, if I move the USB mouse, the kernel panics. Since > > then, neither the USB keyboard nor the mouse work. But the Thinkpad > > keyboard does work. > > > > Find attach pictures of the data printed on ddb. > > > > USB keyboard & mouse are Logitech with Unifying dongle. Note that > > everything worked perfectly on 7.0-stable. > > > > Tell me if you need more inputs. > > > > Regards, > > Joel C. > > > > trace from image0.jpeg > > panic: kernel diagnostic assertion "sc->sc_senstsk == NULL" failed: file > "/usr/src/sys/dev/usb/uhidpp.c", line 648 > > panic+0xbf > __assert+0x25 > uhidpp_device_connect+0x322 > uhidpp_task+0x9e > usb_task_thread+0xe5 Thanks for the report. I just committed fix.
Re: kernel panic 7.0-current
On Sat, Feb 05, 2022 at 12:46:06AM +0100, Joel Carnat wrote: > Hi, > > I have just reinstalled my ThinkPad T460s from scratch using 2022/02/04 > snapshot. xenodm is configured to start automatically. But since I move my > USB mouse, the laptop freezes. > > If I force a reboot, wait for xenodm to popup and switch to a console using > Ctrl-Alt-F1, I can log in. > > But even on the console, if I move the USB mouse, the kernel panics. Since > then, neither the USB keyboard nor the mouse work. But the Thinkpad keyboard > does work. > > Find attach pictures of the data printed on ddb. > > USB keyboard & mouse are Logitech with Unifying dongle. Note that everything > worked perfectly on 7.0-stable. > > Tell me if you need more inputs. > > Regards, > Joel C. > trace from image0.jpeg panic: kernel diagnostic assertion "sc->sc_senstsk == NULL" failed: file "/usr/src/sys/dev/usb/uhidpp.c", line 648 panic+0xbf __assert+0x25 uhidpp_device_connect+0x322 uhidpp_task+0x9e usb_task_thread+0xe5
Re: pcidump -v panic in OpenBSD 7.0 on Samsung NC215S
Yes, audio playback works fine, but I'm not sure about the microphone.
пт, 4 февр. 2022 г. в 22:33, Miod Vallat :
>
> > After printing information via "doas pcidump -v" on device PCI
> > 0:0:27:0 "Intel 82801GB HD Audio", kernel panics. Sorry, I used OCR
> > software to recognize the text from the photo of the screen, maybe
> > there are some errors in hex numbers. Photo is attached.
>
> The following diff, while not fixing the cause of the problem, ought to
> prevent the kernel from panicing.
>
> Does audio (azalia0) work correctly on your system?
>
> Miod
>
> Index: amd64/pci/pci_machdep.c
> ===
> RCS file: /OpenBSD/src/sys/arch/amd64/pci/pci_machdep.c,v
> retrieving revision 1.77
> diff -u -p -r1.77 pci_machdep.c
> --- amd64/pci/pci_machdep.c 11 Mar 2021 11:16:55 - 1.77
> +++ amd64/pci/pci_machdep.c 4 Feb 2022 19:31:36 -
> @@ -213,15 +213,14 @@ pci_conf_size(pci_chipset_tag_t pc, pcit
> return PCI_CONFIG_SPACE_SIZE;
> }
>
> -void
> +int
> pci_mcfg_map_bus(int bus)
> {
> if (pci_mcfgh[bus])
> - return;
> + return 0;
>
> - if (bus_space_map(pci_mcfgt, pci_mcfg_addr + (bus << 20), 1 << 20,
> - 0, _mcfgh[bus]))
> - panic("pci_conf_read: cannot map mcfg space");
> + return bus_space_map(pci_mcfgt, pci_mcfg_addr + (bus << 20), 1 << 20,
> + 0, _mcfgh[bus]);
> }
>
> pcireg_t
> @@ -235,7 +234,8 @@ pci_conf_read(pci_chipset_tag_t pc, pcit
> if (pci_mcfg_addr && reg >= PCI_CONFIG_SPACE_SIZE) {
> pci_decompose_tag(pc, tag, , NULL, NULL);
> if (bus >= pci_mcfg_min_bus && bus <= pci_mcfg_max_bus) {
> - pci_mcfg_map_bus(bus);
> + if (pci_mcfg_map_bus(bus) != 0)
> + return 0x;
> data = bus_space_read_4(pci_mcfgt, pci_mcfgh[bus],
> (tag & 0x000ff00) << 4 | reg);
> return data;
> @@ -261,7 +261,8 @@ pci_conf_write(pci_chipset_tag_t pc, pci
> if (pci_mcfg_addr && reg >= PCI_CONFIG_SPACE_SIZE) {
> pci_decompose_tag(pc, tag, , NULL, NULL);
> if (bus >= pci_mcfg_min_bus && bus <= pci_mcfg_max_bus) {
> - pci_mcfg_map_bus(bus);
> + if (pci_mcfg_map_bus(bus) != 0)
> + return;
> bus_space_write_4(pci_mcfgt, pci_mcfgh[bus],
> (tag & 0x000ff00) << 4 | reg, data);
> return;
> Index: i386/pci/pci_machdep.c
> ===
> RCS file: /OpenBSD/src/sys/arch/i386/pci/pci_machdep.c,v
> retrieving revision 1.87
> diff -u -p -r1.87 pci_machdep.c
> --- i386/pci/pci_machdep.c 11 Mar 2021 11:16:57 - 1.87
> +++ i386/pci/pci_machdep.c 4 Feb 2022 19:31:36 -
> @@ -127,7 +127,7 @@ bus_addr_t pci_mcfg_addr;
> int pci_mcfg_min_bus, pci_mcfg_max_bus;
> bus_space_tag_t pci_mcfgt = I386_BUS_SPACE_MEM;
> bus_space_handle_t pci_mcfgh[256];
> -void pci_mcfg_map_bus(int);
> +int pci_mcfg_map_bus(int);
>
> struct mutex pci_conf_lock = MUTEX_INITIALIZER(IPL_HIGH);
>
> @@ -420,15 +420,14 @@ pci_conf_size(pci_chipset_tag_t pc, pcit
> return PCI_CONFIG_SPACE_SIZE;
> }
>
> -void
> +int
> pci_mcfg_map_bus(int bus)
> {
> if (pci_mcfgh[bus])
> - return;
> + return 0;
>
> - if (bus_space_map(pci_mcfgt, pci_mcfg_addr + (bus << 20), 1 << 20,
> - 0, _mcfgh[bus]))
> - panic("pci_conf_read: cannot map mcfg space");
> + return bus_space_map(pci_mcfgt, pci_mcfg_addr + (bus << 20), 1 << 20,
> + 0, _mcfgh[bus]);
> }
>
> pcireg_t
> @@ -442,7 +441,8 @@ pci_conf_read(pci_chipset_tag_t pc, pcit
> if (pci_mcfg_addr && reg >= PCI_CONFIG_SPACE_SIZE) {
> pci_decompose_tag(pc, tag, , NULL, NULL);
> if (bus >= pci_mcfg_min_bus && bus <= pci_mcfg_max_bus) {
> - pci_mcfg_map_bus(bus);
> + if (pci_mcfg_map_bus(bus) != 0)
> + return 0x;
> data = bus_space_read_4(pci_mcfgt, pci_mcfgh[bus],
> (tag.mode1 & 0x000ff00) << 4 | reg);
> return data;
> @@ -480,7 +480,8 @@ pci_conf_write(pci_chipset_tag_t pc, pci
> if (pci_mcfg_addr && reg >= PCI_CONFIG_SPACE_SIZE) {
> pci_decompose_tag(pc, tag, , NULL, NULL);
> if (bus >= pci_mcfg_min_bus && bus <= pci_mcfg_max_bus) {
> - pci_mcfg_map_bus(bus);
> + if (pci_mcfg_map_bus(bus) != 0)
> + return;
> bus_space_write_4(pci_mcfgt, pci_mcfgh[bus],
> (tag.mode1 &
Re: pcidump -v panic in OpenBSD 7.0 on Samsung NC215S
> Date: Fri, 4 Feb 2022 19:33:08 +
> From: Miod Vallat
>
> > After printing information via "doas pcidump -v" on device PCI
> > 0:0:27:0 "Intel 82801GB HD Audio", kernel panics. Sorry, I used OCR
> > software to recognize the text from the photo of the screen, maybe
> > there are some errors in hex numbers. Photo is attached.
>
> The following diff, while not fixing the cause of the problem, ought to
> prevent the kernel from panicing.
I don't think making that call silently fail is a good idea though.
> Does audio (azalia0) work correctly on your system?
>
> Miod
>
> Index: amd64/pci/pci_machdep.c
> ===
> RCS file: /OpenBSD/src/sys/arch/amd64/pci/pci_machdep.c,v
> retrieving revision 1.77
> diff -u -p -r1.77 pci_machdep.c
> --- amd64/pci/pci_machdep.c 11 Mar 2021 11:16:55 - 1.77
> +++ amd64/pci/pci_machdep.c 4 Feb 2022 19:31:36 -
> @@ -213,15 +213,14 @@ pci_conf_size(pci_chipset_tag_t pc, pcit
> return PCI_CONFIG_SPACE_SIZE;
> }
>
> -void
> +int
> pci_mcfg_map_bus(int bus)
> {
> if (pci_mcfgh[bus])
> - return;
> + return 0;
>
> - if (bus_space_map(pci_mcfgt, pci_mcfg_addr + (bus << 20), 1 << 20,
> - 0, _mcfgh[bus]))
> - panic("pci_conf_read: cannot map mcfg space");
> + return bus_space_map(pci_mcfgt, pci_mcfg_addr + (bus << 20), 1 << 20,
> + 0, _mcfgh[bus]);
> }
>
> pcireg_t
> @@ -235,7 +234,8 @@ pci_conf_read(pci_chipset_tag_t pc, pcit
> if (pci_mcfg_addr && reg >= PCI_CONFIG_SPACE_SIZE) {
> pci_decompose_tag(pc, tag, , NULL, NULL);
> if (bus >= pci_mcfg_min_bus && bus <= pci_mcfg_max_bus) {
> - pci_mcfg_map_bus(bus);
> + if (pci_mcfg_map_bus(bus) != 0)
> + return 0x;
> data = bus_space_read_4(pci_mcfgt, pci_mcfgh[bus],
> (tag & 0x000ff00) << 4 | reg);
> return data;
> @@ -261,7 +261,8 @@ pci_conf_write(pci_chipset_tag_t pc, pci
> if (pci_mcfg_addr && reg >= PCI_CONFIG_SPACE_SIZE) {
> pci_decompose_tag(pc, tag, , NULL, NULL);
> if (bus >= pci_mcfg_min_bus && bus <= pci_mcfg_max_bus) {
> - pci_mcfg_map_bus(bus);
> + if (pci_mcfg_map_bus(bus) != 0)
> + return;
> bus_space_write_4(pci_mcfgt, pci_mcfgh[bus],
> (tag & 0x000ff00) << 4 | reg, data);
> return;
> Index: i386/pci/pci_machdep.c
> ===
> RCS file: /OpenBSD/src/sys/arch/i386/pci/pci_machdep.c,v
> retrieving revision 1.87
> diff -u -p -r1.87 pci_machdep.c
> --- i386/pci/pci_machdep.c11 Mar 2021 11:16:57 - 1.87
> +++ i386/pci/pci_machdep.c4 Feb 2022 19:31:36 -
> @@ -127,7 +127,7 @@ bus_addr_t pci_mcfg_addr;
> int pci_mcfg_min_bus, pci_mcfg_max_bus;
> bus_space_tag_t pci_mcfgt = I386_BUS_SPACE_MEM;
> bus_space_handle_t pci_mcfgh[256];
> -void pci_mcfg_map_bus(int);
> +int pci_mcfg_map_bus(int);
>
> struct mutex pci_conf_lock = MUTEX_INITIALIZER(IPL_HIGH);
>
> @@ -420,15 +420,14 @@ pci_conf_size(pci_chipset_tag_t pc, pcit
> return PCI_CONFIG_SPACE_SIZE;
> }
>
> -void
> +int
> pci_mcfg_map_bus(int bus)
> {
> if (pci_mcfgh[bus])
> - return;
> + return 0;
>
> - if (bus_space_map(pci_mcfgt, pci_mcfg_addr + (bus << 20), 1 << 20,
> - 0, _mcfgh[bus]))
> - panic("pci_conf_read: cannot map mcfg space");
> + return bus_space_map(pci_mcfgt, pci_mcfg_addr + (bus << 20), 1 << 20,
> + 0, _mcfgh[bus]);
> }
>
> pcireg_t
> @@ -442,7 +441,8 @@ pci_conf_read(pci_chipset_tag_t pc, pcit
> if (pci_mcfg_addr && reg >= PCI_CONFIG_SPACE_SIZE) {
> pci_decompose_tag(pc, tag, , NULL, NULL);
> if (bus >= pci_mcfg_min_bus && bus <= pci_mcfg_max_bus) {
> - pci_mcfg_map_bus(bus);
> + if (pci_mcfg_map_bus(bus) != 0)
> + return 0x;
> data = bus_space_read_4(pci_mcfgt, pci_mcfgh[bus],
> (tag.mode1 & 0x000ff00) << 4 | reg);
> return data;
> @@ -480,7 +480,8 @@ pci_conf_write(pci_chipset_tag_t pc, pci
> if (pci_mcfg_addr && reg >= PCI_CONFIG_SPACE_SIZE) {
> pci_decompose_tag(pc, tag, , NULL, NULL);
> if (bus >= pci_mcfg_min_bus && bus <= pci_mcfg_max_bus) {
> - pci_mcfg_map_bus(bus);
> + if (pci_mcfg_map_bus(bus) != 0)
> + return;
> bus_space_write_4(pci_mcfgt, pci_mcfgh[bus],
> (tag.mode1 & 0x000ff00) << 4 | reg, data);
> return;
>
>
Re: pcidump -v panic in OpenBSD 7.0 on Samsung NC215S
> After printing information via "doas pcidump -v" on device PCI
> 0:0:27:0 "Intel 82801GB HD Audio", kernel panics. Sorry, I used OCR
> software to recognize the text from the photo of the screen, maybe
> there are some errors in hex numbers. Photo is attached.
The following diff, while not fixing the cause of the problem, ought to
prevent the kernel from panicing.
Does audio (azalia0) work correctly on your system?
Miod
Index: amd64/pci/pci_machdep.c
===
RCS file: /OpenBSD/src/sys/arch/amd64/pci/pci_machdep.c,v
retrieving revision 1.77
diff -u -p -r1.77 pci_machdep.c
--- amd64/pci/pci_machdep.c 11 Mar 2021 11:16:55 - 1.77
+++ amd64/pci/pci_machdep.c 4 Feb 2022 19:31:36 -
@@ -213,15 +213,14 @@ pci_conf_size(pci_chipset_tag_t pc, pcit
return PCI_CONFIG_SPACE_SIZE;
}
-void
+int
pci_mcfg_map_bus(int bus)
{
if (pci_mcfgh[bus])
- return;
+ return 0;
- if (bus_space_map(pci_mcfgt, pci_mcfg_addr + (bus << 20), 1 << 20,
- 0, _mcfgh[bus]))
- panic("pci_conf_read: cannot map mcfg space");
+ return bus_space_map(pci_mcfgt, pci_mcfg_addr + (bus << 20), 1 << 20,
+ 0, _mcfgh[bus]);
}
pcireg_t
@@ -235,7 +234,8 @@ pci_conf_read(pci_chipset_tag_t pc, pcit
if (pci_mcfg_addr && reg >= PCI_CONFIG_SPACE_SIZE) {
pci_decompose_tag(pc, tag, , NULL, NULL);
if (bus >= pci_mcfg_min_bus && bus <= pci_mcfg_max_bus) {
- pci_mcfg_map_bus(bus);
+ if (pci_mcfg_map_bus(bus) != 0)
+ return 0x;
data = bus_space_read_4(pci_mcfgt, pci_mcfgh[bus],
(tag & 0x000ff00) << 4 | reg);
return data;
@@ -261,7 +261,8 @@ pci_conf_write(pci_chipset_tag_t pc, pci
if (pci_mcfg_addr && reg >= PCI_CONFIG_SPACE_SIZE) {
pci_decompose_tag(pc, tag, , NULL, NULL);
if (bus >= pci_mcfg_min_bus && bus <= pci_mcfg_max_bus) {
- pci_mcfg_map_bus(bus);
+ if (pci_mcfg_map_bus(bus) != 0)
+ return;
bus_space_write_4(pci_mcfgt, pci_mcfgh[bus],
(tag & 0x000ff00) << 4 | reg, data);
return;
Index: i386/pci/pci_machdep.c
===
RCS file: /OpenBSD/src/sys/arch/i386/pci/pci_machdep.c,v
retrieving revision 1.87
diff -u -p -r1.87 pci_machdep.c
--- i386/pci/pci_machdep.c 11 Mar 2021 11:16:57 - 1.87
+++ i386/pci/pci_machdep.c 4 Feb 2022 19:31:36 -
@@ -127,7 +127,7 @@ bus_addr_t pci_mcfg_addr;
int pci_mcfg_min_bus, pci_mcfg_max_bus;
bus_space_tag_t pci_mcfgt = I386_BUS_SPACE_MEM;
bus_space_handle_t pci_mcfgh[256];
-void pci_mcfg_map_bus(int);
+int pci_mcfg_map_bus(int);
struct mutex pci_conf_lock = MUTEX_INITIALIZER(IPL_HIGH);
@@ -420,15 +420,14 @@ pci_conf_size(pci_chipset_tag_t pc, pcit
return PCI_CONFIG_SPACE_SIZE;
}
-void
+int
pci_mcfg_map_bus(int bus)
{
if (pci_mcfgh[bus])
- return;
+ return 0;
- if (bus_space_map(pci_mcfgt, pci_mcfg_addr + (bus << 20), 1 << 20,
- 0, _mcfgh[bus]))
- panic("pci_conf_read: cannot map mcfg space");
+ return bus_space_map(pci_mcfgt, pci_mcfg_addr + (bus << 20), 1 << 20,
+ 0, _mcfgh[bus]);
}
pcireg_t
@@ -442,7 +441,8 @@ pci_conf_read(pci_chipset_tag_t pc, pcit
if (pci_mcfg_addr && reg >= PCI_CONFIG_SPACE_SIZE) {
pci_decompose_tag(pc, tag, , NULL, NULL);
if (bus >= pci_mcfg_min_bus && bus <= pci_mcfg_max_bus) {
- pci_mcfg_map_bus(bus);
+ if (pci_mcfg_map_bus(bus) != 0)
+ return 0x;
data = bus_space_read_4(pci_mcfgt, pci_mcfgh[bus],
(tag.mode1 & 0x000ff00) << 4 | reg);
return data;
@@ -480,7 +480,8 @@ pci_conf_write(pci_chipset_tag_t pc, pci
if (pci_mcfg_addr && reg >= PCI_CONFIG_SPACE_SIZE) {
pci_decompose_tag(pc, tag, , NULL, NULL);
if (bus >= pci_mcfg_min_bus && bus <= pci_mcfg_max_bus) {
- pci_mcfg_map_bus(bus);
+ if (pci_mcfg_map_bus(bus) != 0)
+ return;
bus_space_write_4(pci_mcfgt, pci_mcfgh[bus],
(tag.mode1 & 0x000ff00) << 4 | reg, data);
return;
Re: Kernel panic on boot as of obsd 7.0-current from 2022-02-02
On 2022/02/04 01:26, Claudio Miranda wrote:
> Hello,
>
> As of the OpenBSD 7.0-current snapshot from 2022-02-02, I've been getting a
> kernel panic on boot when it tries to load inteldrm0. The system is a Dell
> Latitude E6410 laptop with a Core i5-520M and Intel HD Graphics. Below is the
> dmesg.boot output which inludes the panic and trace from ddb.
This is likely fixed by a commit from shortly after that snapshot was
built. Wait for a new snapshot, or build your own from a source checkout.
> OpenBSD 7.0-current (GENERIC.MP) #307: Thu Feb 3 15:15:42 MST 2022
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
..
> inteldrm0: msi, IRONLAKE, gen 5
> uvm_fault(0x822fb4c0, 0x40, 0, 1) -> e
> kernel: page fault trap, code=0
> Stopped atgen3_stolen_size+0x1b: movq0x40(%rax),%rdi
> TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
>
> * 0 0 0 0x1 0x2000K swapper
>
> gen3_stolen_size(80111000,80111000,4de144a071cb0374,de05,10,826f8940)
> at gen3_stolen_size+0x1b
> intel_init_stolen_res(80111000,80111000,212038c56f97838a,80111024,80111000,80111930)
> at intel_init_stolen_res+0xf9
> inteldrm_attach(800e9c00,80111000,826f8a90,800e9c00,800e9c00,826f8a90)
> at inteldrm_attach+0x37e
> config_attach(800e9c00,82294ec0,826f8a90,8166e640,26a9b2207f566041,80001000)
> at config_attach+0x1f4
> pci_probe_device(800e9c00,80001000,0,0,d03cbfc83c46c518,0) at
> pci_probe_device+0x4e0
> pci_enumerate_bus(800e9c00,0,0,800e9c00,3cc3ddf0a79f6dda,8002c180)
> at pci_enumerate_bus+0x139
> config_attach(8002c180,82292b18,826f8c98,8168c020,26a9b2207f5833cd,800e9900)
> at config_attach+0x1f4
> acpipci_attach_bus(8002c180,800e9900,7fed778b7f825bf1,0,8002c180,8227dbd0)
> at acpipci_attach_bus+0x1ac
> acpipci_attach_busses(8002c180,8002c180,aeed7bb616cd44cb,826f8db8,8002c180,0)
> at acpipci_attach_busses+0x5d
> mainbus_attach(0,8002c180,0,0,aecdc77f778cabb1,0) at
> mainbus_attach+0x1c3
> config_attach(0,82292648,0,0,26a9b2207f483722,0) at
> config_attach+0x1f4
> cpu_configure(db938d4bcb1fe700,0,0,8002d000,8178bb13,826f8f00)
> at cpu_configure+0x33
> main(0,0,0,0,1,1) at main+0x3a3
> end trace frame: 0x0, count: 2
> https://www.openbsd.org/ddb.html describes the minimum info required in bug
> reports. Insufficient info makes it difficult to find and fix bugs.
> ddb{0}> *cpu0: uvm_fault(0x822fb4c0, 0x40, 0, 1) -> e
> ddb{0}>
> gen3_stolen_size(80111000,80111000,4de144a071cb0374,de05,10,826f8940)
> at gen3_stolen_size+0x1b
> intel_init_stolen_res(80111000,80111000,212038c56f97838a,80111024,80111000,80111930)
> at intel_init_stolen_res+0xf9
> inteldrm_attach(800e9c00,80111000,826f8a90,800e9c00,800e9c00,826f8a90)
> at inteldrm_attach+0x37e
> config_attach(800e9c00,82294ec0,826f8a90,8166e640,26a9b2207f566041,80001000)
> at config_attach+0x1f4
> pci_probe_device(800e9c00,80001000,0,0,d03cbfc83c46c518,0) at
> pci_probe_device+0x4e0
> pci_enumerate_bus(800e9c00,0,0,800e9c00,3cc3ddf0a79f6dda,8002c180)
> at pci_enumerate_bus+0x139
> config_attach(8002c180,82292b18,826f8c98,8168c020,26a9b2207f5833cd,800e9900)
> at config_attach+0x1f4
> acpipci_attach_bus(8002c180,800e9900,7fed778b7f825bf1,0,8002c180,8227dbd0)
> at acpipci_attach_bus+0x1ac
> acpipci_attach_busses(8002c180,8002c180,aeed7bb616cd44cb,826f8db8,8002c180,0)
> at acpipci_attach_busses+0x5d
> mainbus_attach(0,8002c180,0,0,aecdc77f778cabb1,0) at
> mainbus_attach+0x1c3
> config_attach(0,82292648,0,0,26a9b2207f483722,0) at
> config_attach+0x1f4
> cpu_configure(db938d4bcb1fe700,0,0,8002d000,8178bb13,826f8f00)
> at cpu_configure+0x33
> main(0,0,0,0,1,1) at main+0x3a3
> end trace frame: 0x0, count: -13
