<div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial"><div>Dear <span style="font-family: arial; white-space: pre-wrap;">Mantas and</span> <span style="font-family: arial; white-space: pre-wrap;">Ulrich,</span></div><div><span style="font-family: arial; white-space: pre-wrap;"><br></span></div><div><font face="arial"><span style="white-space: pre-wrap;">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.</span></font></div><br><div>thanks,</div><div>Byron</div><div style="position:relative;zoom:1"></div><div id="divNeteaseMailCard"></div><br><pre><br>At 2019-10-16 14:12:35, "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> wrote:
>>>> Mantas Mikulenas <grawity@gmail.com> schrieb am 15.10.2019 um 20:32 in
>Nachricht
><CAPWNY8Whzf+G6AWBkHTLFAXUo=fRm_VtqO+i1tYt-yaobOCU8g@mail.gmail.com>:
>> On Tue, Oct 15, 2019 at 3:02 PM www <ouyangxuan10@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
>
>
</pre></div><br><br><span title="neteasefooter"><p> </p></span>