From: Michael Schmitz <schmitzmic@gmail.com> To: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Finn Thain <fthain@linux-m68k.org>, Andreas Schwab <schwab@linux-m68k.org>, debian-68k@lists.debian.org, linux-m68k@lists.linux-m68k.org Subject: Re: instrumentation, was Re: core dump analysis Date: Tue, 11 Apr 2023 20:24:24 +1200 [thread overview] Message-ID: <13a69c91-ca2b-42d8-dbd5-0b81e76044c6@gmail.com> (raw) In-Reply-To: <CAMuHMdXEKvKDPZWdzrEs0z=qS=hiK8AEwkSMgwoQcfjc_a4wEA@mail.gmail.com> Hi Geert, Am 11.04.2023 um 19:19 schrieb Geert Uytterhoeven: > Hi Michael, > > On Tue, Apr 11, 2023 at 6:56 AM Michael Schmitz <schmitzmic@gmail.com> wrote: >> Am 11.04.2023 um 12:20 schrieb Finn Thain: >>> On Sun, 9 Apr 2023, Michael Schmitz wrote: >>>> Am 08.04.2023 um 00:06 schrieb Geert Uytterhoeven: >>>>> On Fri, Apr 7, 2023 at 3:58 AM Michael Schmitz <wrote: >>>>>> The easiest way to do that is to log all wait and signal syscalls, as >>>>>> well as process exit. That might alter timing if these log messages >>>>>> go to the serial console though. Is that what you have in mind? >>>>> >>>>> Store to RAM, retrieve through a new /proc file? >>>> >>>> Yes, that could be done, though I'd rather avoid duplicating a lot of >>>> the generic message formatting code (printk and friends). >>>> >>>> I'll have a look around ... >>>> >>> >>> A better solution might be be to port the existing instrumentation like >>> ftrace, kprobes, uprobes etc. Might be a lot of work though. I wonder >>> how portable that stuff is. Looking at a few arch implementations, I'm utterly confused. Wouldn't know where to start. >>> >>> If you use printk, you could probably avoid most of the delays by enabling >>> the dummy console. Then the kernel messages would be collected with dmesg, >>> given a sufficiently large CONFIG_LOG_BUF_SHIFT. But it would be >>> inconvenient to have no serial console available for the usual purposes. >> >> Can we disable the serial console after boot, by registering the dummy >> console? Or will that just log messages to both? > > You can increase loglevel. Yes, we could do that. I thought /proc has to be mounted for the loglevel to be changed, but I might be wrong. OTOH, if we log wait and signal actions at level debug, and set loglevel to info or notice through the command line, we won't miss much of the usual boot messages on the serial console ... Cheers, Michael > > Gr{oetje,eeting}s, > > Geert > > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds >
next prev parent reply other threads:[~2023-04-11 8:26 UTC|newest]
Thread overview: 134+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4a9c1d0d-07aa-792e-921f-237d5a30fc44.ref@yahoo.com>
[not found] ` <4a9c1d0d-07aa-792e-921f-237d5a30fc44@yahoo.com>
2023-01-30 10:12 ` stack smashing detected Geert Uytterhoeven
2023-01-31 3:05 ` Michael Schmitz
[not found] ` <af524ac9-f5af-e9fb-e33f-0884a0ebfcb6@yahoo.com>
2023-02-01 18:51 ` Michael Schmitz
2023-02-02 7:52 ` Geert Uytterhoeven
[not found] ` <8fb2aa62-dcec-9bd0-b8da-00d9bb4ddaba@yahoo.com>
2023-02-03 0:15 ` Michael Schmitz
2023-02-05 22:19 ` Michael Schmitz
[not found] ` <33d7ea3e-9bd2-16e4-4d9a-f7aa5657a0f7@yahoo.com>
2023-02-07 22:58 ` Michael Schmitz
2023-02-09 3:41 ` Michael Schmitz
[not found] ` <c01e2f1c-425f-478d-918e-cd1fd37e0008@yahoo.com>
[not found] ` <aee359a6-b5e0-fbe2-3988-779f8601f106@gmail.com>
[not found] ` <8042d988-6dd9-8170-60e9-cdf19118440f@yahoo.com>
[not found] ` <a8f06e4b-db28-c8f9-5e21-3ea0f3eebacd@linux-m68k.org>
[not found] ` <bb27b393-3d02-f42c-5c7f-c27d4936ece9@linux-m68k.org>
[not found] ` <37da2ca2-dd99-8417-7cae-a88e2e7fc1b6@yahoo.com>
[not found] ` <30a1be59-a1fd-f882-1072-c7db8734b1f1@gmail.com>
[not found] ` <39f79c2d-e803-d7b1-078f-8757ca9b1238@yahoo.com>
[not found] ` <c47abfdc-31c8-e7ed-1c14-90f68710f25d@gmail.com>
[not found] ` <040ad66a-71dd-001b-0446-36cbd6547b37@yahoo.com>
[not found] ` <5b9d64bb-2adc-20a2-f596-f99bf255b5cc@linux-m68k.org>
[not found] ` <56bd9a33-c58a-58e0-3956-e63c61abe5fe@yahoo.com>
[not found] ` <1725f7c1-2084-a404-653d-9e9f8bbe961c@linux-m68k.org>
2023-03-28 3:37 ` core dump analysis, was " Finn Thain
2023-03-31 3:33 ` Finn Thain
2023-04-01 9:27 ` Finn Thain
2023-04-01 10:11 ` Andreas Schwab
2023-04-02 10:46 ` Finn Thain
2023-04-02 22:01 ` Michael Schmitz
2023-04-04 0:13 ` Finn Thain
2023-04-04 23:22 ` Michael Schmitz
2023-04-05 2:00 ` Finn Thain
2023-04-07 1:57 ` Michael Schmitz
2023-04-07 4:03 ` dash behaviour, was Re: core dump analysis Finn Thain
2023-04-07 12:10 ` Geert Uytterhoeven
2023-04-08 5:29 ` Finn Thain
2023-04-09 8:30 ` Geert Uytterhoeven
2023-04-09 3:48 ` Michael Schmitz
2023-04-09 4:42 ` Finn Thain
2023-04-09 4:55 ` Michael Schmitz
2023-04-09 7:32 ` Finn Thain
2023-04-10 8:12 ` Michael Schmitz
2023-04-10 9:39 ` kernel behaviour, was Re: dash behaviour Finn Thain
2023-04-11 4:29 ` Michael Schmitz
2023-04-11 4:50 ` Finn Thain
2023-04-11 7:21 ` Geert Uytterhoeven
2023-04-07 12:06 ` core dump analysis, was Re: stack smashing detected Geert Uytterhoeven
2023-04-09 1:56 ` Michael Schmitz
2023-04-11 0:20 ` instrumentation, was Re: core dump analysis Finn Thain
2023-04-11 4:56 ` Michael Schmitz
2023-04-11 5:54 ` Finn Thain
2023-04-11 7:19 ` Geert Uytterhoeven
2023-04-11 8:24 ` Michael Schmitz [this message]
2023-04-12 23:22 ` Eero Tamminen
2023-04-15 15:50 ` Eero Tamminen
2023-04-15 21:56 ` Brad Boyer
2023-04-14 9:30 ` core dump analysis, was Re: stack smashing detected Finn Thain
2023-04-16 1:50 ` Michael Schmitz
2023-04-16 6:44 ` Finn Thain
2023-04-17 23:32 ` Michael Schmitz
2023-04-18 2:04 ` Finn Thain
2023-04-18 5:29 ` Michael Schmitz
2023-04-19 1:50 ` Finn Thain
2023-04-19 8:15 ` Michael Schmitz
2023-04-23 7:46 ` Finn Thain
2023-04-23 21:26 ` Michael Schmitz
2023-04-19 10:50 ` reliable reproducer, was Re: core dump analysis Finn Thain
2023-04-19 11:55 ` Geert Uytterhoeven
2023-04-20 1:02 ` Finn Thain
2023-04-20 0:55 ` Michael Schmitz
2023-04-20 2:57 ` Finn Thain
2023-04-20 4:08 ` Michael Schmitz
2023-04-20 5:17 ` Finn Thain
2023-04-20 5:48 ` Finn Thain
2023-04-20 7:34 ` Michael Schmitz
2023-04-20 7:47 ` Finn Thain
2023-04-20 8:23 ` Michael Schmitz
2023-04-20 8:55 ` Finn Thain
2023-04-20 21:58 ` Michael Schmitz
2023-04-21 1:45 ` Michael Schmitz
2023-04-21 5:52 ` Michael Schmitz
2023-04-21 8:30 ` Finn Thain
2023-04-21 9:18 ` Michael Schmitz
2023-04-22 7:54 ` Michael Schmitz
2023-04-22 8:07 ` Andreas Schwab
2023-04-22 8:16 ` Michael Schmitz
2023-04-22 10:12 ` Andreas Schwab
2023-04-22 18:24 ` Michael Schmitz
2023-04-22 18:38 ` Andreas Schwab
2023-04-22 20:06 ` Michael Schmitz
2023-04-22 20:46 ` Andreas Schwab
2023-04-23 1:41 ` Michael Schmitz
2023-04-23 7:37 ` Andreas Schwab
2023-04-23 8:18 ` Michael Schmitz
2023-04-23 8:23 ` Andreas Schwab
2023-04-23 20:19 ` Michael Schmitz
2023-04-23 21:48 ` Andreas Schwab
2023-04-24 3:51 ` Michael Schmitz
2023-04-24 5:46 ` Michael Schmitz
2023-04-23 9:23 ` Finn Thain
2023-04-23 20:43 ` Michael Schmitz
2023-04-24 23:44 ` Finn Thain
[not found] ` <1d9955d2-6016-a238-142a-887f95465dd8@linux-m68k.org>
[not found] ` <4763c8e2-6fb3-eda6-10d0-94ed1d01cd60@gmail.com>
[not found] ` <a5d70bac-bd00-7131-9ca0-18976f539adf@linux-m68k.org>
[not found] ` <b150c146-cade-bcd3-9c34-d99284dcd153@gmail.com>
[not found] ` <c3d2d874-e366-1d3b-71b0-7a089d40308a@linux-m68k.org>
2023-04-25 1:55 ` signal delivery, was Re: reliable reproducer Finn Thain
2023-04-25 2:32 ` Michael Schmitz
2023-04-25 5:59 ` Michael Schmitz
2023-04-26 19:45 ` Michael Schmitz
[not found] ` <1c4fc19f-ad9b-7b8f-6638-8b026fe1280b@linux-m68k.org>
[not found] ` <5ac55169-4916-d671-489f-7eb8fb85d336@gmail.com>
[not found] ` <9544ef26-a444-e186-fb1e-0e914acd36af@gmail.com>
[not found] ` <20de24b3-098d-4603-2768-b0468a4fe772@gmail.com>
[not found] ` <69565abb-1cd6-716e-046e-5a6d69a4e617@linux-m68k.org>
[not found] ` <89cb2211-5f6e-07a2-3149-1ad1ad887265@linux-m68k.org>
[not found] ` <d3d27369-8532-ba69-2463-66b8decbee67@gmail.com>
[not found] ` <4b4eacf2-6934-5563-fb47-04843a77a35c@gmail.com>
2023-04-29 0:28 ` Finn Thain
2023-04-29 0:53 ` Finn Thain
2023-04-29 2:53 ` Michael Schmitz
2023-04-29 5:03 ` Finn Thain
2023-04-29 6:01 ` Michael Schmitz
2023-04-29 6:13 ` Finn Thain
2023-04-29 6:43 ` Michael Schmitz
2023-04-29 6:05 ` Finn Thain
2023-04-29 7:11 ` Andreas Schwab
2023-04-29 7:37 ` Michael Schmitz
2023-04-25 9:26 ` Eero Tamminen
2023-04-25 11:25 ` Andreas Schwab
2023-04-25 19:46 ` Michael Schmitz
2023-04-26 1:54 ` Michael Schmitz
2023-04-26 3:27 ` Finn Thain
2023-04-26 3:56 ` Michael Schmitz
2023-04-26 4:53 ` Finn Thain
2023-04-26 2:02 ` Finn Thain
2023-04-26 4:00 ` Michael Schmitz
2023-04-26 4:42 ` Finn Thain
2023-04-26 9:10 ` Michael Schmitz
2023-04-26 21:48 ` Brad Boyer
2023-04-26 8:31 ` Andreas Schwab
2023-04-25 11:53 ` Andreas Schwab
2023-04-26 1:59 ` Finn Thain
2023-04-25 5:18 ` reliable reproducer, was Re: core dump analysis Michael Schmitz
2023-04-22 9:00 ` Michael Schmitz
2023-04-21 1:15 ` Finn Thain
2023-04-21 1:57 ` Michael Schmitz
2023-04-21 1:39 ` Finn Thain
2023-04-20 6:04 ` Finn Thain
2023-04-20 7:40 ` Michael Schmitz
2023-04-20 7:58 ` Finn Thain
2023-04-02 4:09 ` core dump analysis, was Re: stack smashing detected Michael Schmitz
2023-04-02 9:31 ` Finn Thain
2023-04-03 8:26 ` Michael Schmitz
2023-04-04 4:05 ` Finn Thain
2023-04-04 11:05 ` Finn Thain
2023-04-09 4:02 ` Finn Thain
2023-02-03 23:39 ` Finn Thain
[not found] ` <86badf6e-2cc8-1937-1a2f-45334bb338f4@yahoo.com>
2023-02-05 22:29 ` Debian initramfs/initrd, was " Finn Thain
2023-02-05 23:18 ` John Paul Adrian Glaubitz
[not found] ` <8107e04f-fd60-c6e3-2bad-cc0d99877967@yahoo.com>
2023-02-06 7:52 ` Geert Uytterhoeven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=13a69c91-ca2b-42d8-dbd5-0b81e76044c6@gmail.com \
--to=schmitzmic@gmail.com \
--cc=debian-68k@lists.debian.org \
--cc=fthain@linux-m68k.org \
--cc=geert@linux-m68k.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=schwab@linux-m68k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox