Dear Mantas and Ulrich,
Thank you very much for your help. Because systemd will automatically call this driver, which causes the system to fail to start normally, I have to load the driver in a different way (load it separately), and then debug it. Thanks again for your help. thanks, Byron At 2019-10-16 14:12:35, "Ulrich Windl" <ulrich.wi...@rz.uni-regensburg.de> wrote: >>>> 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
