>>> Mantas Mikulenas <graw...@gmail.com> schrieb am 15.10.2019 um 20:32 in Nachricht <CAPWNY8Whzf+G6AWBkHTLFAXUo=frm_vtqo+i1tyt-yaoboc...@mail.gmail.com>: > On Tue, Oct 15, 2019 at 3:02 PM www <ouyangxua...@163.com> wrote: > >> Dear all, >> >> I add a new driver to kernel, and it probe success. When enter into >> systemd, the udevadm generate a kernel panic. >> I want to ask how to debug it and find out where the error occurred? When >> did udevadm load? What commands are used by udevadm, and what are the >> specific operations? >> > > There aren't many udevadm calls in systemd... The main one is > systemd-udev-trigger.service, which calls `udevadm trigger > --type=subsystems --action=add`, then repeats the same for type=devices. It > tries to generate coldplug uevents by writing 'add' to each found device's > /sys/.../uevent file.
That's waht I guessed: The driver being loaded created siome udev event (with probably invalid data in it), so when processing those, problems are triggered. I'm not arguing whether all thge components involved are robust enough (to avoid a kernel panic), but is there a kind of "driver validation tool" (like inserting the module, querying it's metedata, udev events, removing the module again, etc.)? Regards, Ulrich > > (The second is systemd-udev-settle.service, but it is disabled by default > on most systems and just waits for udev's job queue to empty.) > > -- > Mantas Mikulėnas _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
