Re: [systemd-devel] [systemd]: sd-sync lead to kernel panic
On Wed, Jun 30, 2021 at 02:54:24PM +0800, www wrote: > Dear all, > > > systemd version: v234 > kernel version: 5.1.5 > > > My embedded system uses systemd. Occasionally kernel panic appears in this > system. It is found that it is related to sd-sync in systemd. How to analyze > this and why? > What causes this problem? Or can you see that sd-sync has a problem > processing that file or service? > If you have any ideas or opinions, or need any specific information, please > let me know. sd-sync is just systemd calling sync(2) in a thread. So it's just your kernel crashing. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd]: sd-sync lead to kernel panic
On Wed, Jun 30, 2021 at 02:54:24PM +0800, www wrote: > Dear all, > > > systemd version: v234 > kernel version: 5.1.5 That is a very old and obsolete and insecure and known-buggy kernel version. Please work with the vendor who is forcing you to use this kernel version as you are paying them for support for this. If you are not paying for support, please move to the latest kernel release (5.13) and see if the problem is there as well. thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd]: sd-sync lead to kernel panic
On Wed, Jun 30, 2021 at 10:09 AM www wrote: > Dear all, > > systemd version: v234 > kernel version: 5.1.5 > > My embedded system uses systemd. Occasionally kernel panic appears in this > system. It is found that it is related to sd-sync in systemd. How to > analyze this and why? > What causes this problem? Or can you see that sd-sync has a problem > processing that file or service? > If you have any ideas or opinions, or need any specific information, > please let me know. > > Thank you. > > [ 1664.582102] Unable to handle kernel paging request at virtual address > 7f8bba1c > [ 1664.589350] pgd = fb46e47e > [ 1664.592062] [7f8bba1c] *pgd= > [ 1664.595666] Internal error: Oops: 8005 [#1] ARM > [ 1664.600558] CPU: 0 PID: 14730 Comm: (*sd-sync*) Not tainted > 5.1.5-yocto-s-dirty-fd96c2b #1 > When shutdown.target is invoked, systemd forks a 'sd-sync' background process which does literally one thing: it issues a global sync() to begin flushing all filesystems to disk. There is no specific file involved here, sync() handles all mounted filesystems at once. Check what happens if you run `/usr/sbin/sync` from shell, since it does exactly the same thing. In general there should be nothing special about systemd calling sync(), it's purely a kernel problem. The only difference that I can think of is that systemd begins the sync() while all services are shutting down and still actively writing to files... -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [systemd]: sd-sync lead to kernel panic
Dear all, systemd version: v234 kernel version: 5.1.5 My embedded system uses systemd. Occasionally kernel panic appears in this system. It is found that it is related to sd-sync in systemd. How to analyze this and why? What causes this problem? Or can you see that sd-sync has a problem processing that file or service? If you have any ideas or opinions, or need any specific information, please let me know. Thank you. [ 1664.582102] Unable to handle kernel paging request at virtual address 7f8bba1c [ 1664.589350] pgd = fb46e47e [ 1664.592062] [7f8bba1c] *pgd= [ 1664.595666] Internal error: Oops: 8005 [#1] ARM [ 1664.600558] CPU: 0 PID: 14730 Comm: (sd-sync) Not tainted 5.1.5-yocto-s-dirty-fd96c2b #1 [ 1664.608641] Hardware name: Generic DT based system [ 1664.613444] PC is at 0x7f8bba1c [ 1664.616617] LR is at xas_find_marked+0x94/0x230 [ 1664.621148] pc : [<7f8bba1c>]lr : [<80744690>]psr: 6013 [ 1664.627411] sp : 95eeddb0 ip : ffc0 fp : 95eede4c [ 1664.632627] r10: r9 : r8 : 9e004bcc [ 1664.637847] r7 : 95eedec8 r6 : 95eedec8 r5 : 0001 r4 : [ 1664.644363] r3 : 0002 r2 : r1 : 0004 r0 : a013 [ 1664.650883] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 1664.658006] Control: 00c5387d Table: 95f60008 DAC: 0051 [ 1664.663751] Process (sd-sync) (pid: 14730, stack limit = 0x7a5416e4) [ 1664.670097] Stack: (0x95eeddb0 to 0x95eee000) [ 1664.674452] dda0: 8073815c 80737de8 0001 0002 [ 1664.682628] ddc0: 9e004bcc 801faba8 7fff 8074 [ 1664.690801] dde0: 80b107e0 42139f9a 80b07008 80748498 95eede14 9ac1a120 95f13b00 80b107e0 [ 1664.698972] de00: 9af73540 95eede5c 95eede18 807480c4 8013b46c 9ad45044 80b07008 [ 1664.707146] de20: 95eede54 9e004bcc 95eedec8 95eedec8 801faba8 9e004a90 95eec000 [ 1664.715319] de40: 95eede7c 95eede50 801fd538 801fcf7c 95eede50 95eede50 95eede58 95eede58 [ 1664.723491] de60: 9500 80b07008 9e004bcc 9e004bcc 95eede8c 95eede80 802793c8 801fd4e4 [ 1664.731664] de80: 95eedec4 95eede90 801fd430 802793bc 9ad8d000 8026ac14 95eedf04 95eedea8 [ 1664.739836] dea0: 8026ac14 80b07008 9e004bcc 7fff 7fff 95eedf0c 95eedec8 [ 1664.748008] dec0: 801ec328 801fd3ec 7fff 7fff [ 1664.756182] dee0: 0001 8039002c 80b07008 9ad8d000 8026e4d8 80b075a8 [ 1664.764356] df00: 95eedf34 95eedf10 801ec3a0 801ec2a4 7fff 0001 8027b4fc [ 1664.772528] df20: 9e004af8 95eedf44 95eedf38 8026e4f8 801ec374 95eedf6c 95eedf48 [ 1664.780700] df40: 8027b51c 8026e4e4 00c38f68 0024 801011e4 95eec000 [ 1664.788872] df60: 95eedf94 95eedf70 8026e724 8027b4bc 8010ba08 0001 80b07008 [ 1664.797044] df80: 95eedfa4 95eedf98 8026e798 8026e6c0 95eedfa8 [ 1664.805218] dfa0: 80101000 8026e78c 0002 6ade8c00 [ 1664.813388] dfc0: 00c38f68 0024 7e8d7740 7e8d774c 0003 [ 1664.821562] dfe0: 43759194 7e8d76cc 435e77f0 4307ef9c 6010 [ 1664.829724] Backtrace: [ 1664.832205] [<801fcf70>] (write_cache_pages) from [<801fd538>] (generic_writepages+0x60/0x98) [ 1664.840729] r10: r9:95eec000 r8:9e004a90 r7:801faba8 r6:95eedec8 r5:95eedec8 [ 1664.848549] r4:9e004bcc [ 1664.851107] [<801fd4d8>] (generic_writepages) from [<802793c8>] (blkdev_writepages+0x18/0x1c) [ 1664.859620] r5:9e004bcc r4:9e004bcc [ 1664.863209] [<802793b0>] (blkdev_writepages) from [<801fd430>] (do_writepages+0x50/0xf8) [ 1664.871317] [<801fd3e0>] (do_writepages) from [<801ec328>] (__filemap_fdatawrite_range+0x90/0xd0) [ 1664.880182] r7:7fff r6: r5:7fff r4:9e004bcc [ 1664.885848] [<801ec298>] (__filemap_fdatawrite_range) from [<801ec3a0>] (filemap_fdatawrite+0x38/0x40) [ 1664.895145] r7:80b075a8 r6:8026e4d8 r4: [ 1664.899779] [<801ec368>] (filemap_fdatawrite) from [<8026e4f8>] (fdatawrite_one_bdev+0x20/0x24) [ 1664.908467] r5: r4:9e004af8 [ 1664.912062] [<8026e4d8>] (fdatawrite_one_bdev) from [<8027b51c>] (iterate_bdevs+0x6c/0xc4) [ 1664.920343] [<8027b4b0>] (iterate_bdevs) from [<8026e724>] (ksys_sync+0x70/0xcc) [ 1664.927737] r9:95eec000 r8:801011e4 r7:0024 r6:00c38f68 r5: r4: [ 1664.935482] [<8026e6b4>] (ksys_sync) from [<8026e798>] (sys_sync+0x18/0x20) [ 1664.942436] r4: [ 1664.944980] [<8026e780>] (sys_sync) from [<80101000>] (ret_fast_syscall+0x0/0x54) [ 1664.952455] Exception stack(0x95eedfa8 to 0x95eedff0) [ 1664.957504] dfa0: 0002 6ade8c00 [ 1664.965681] dfc0: 00c38f68 0024 7e8d7740 7e8d774c 0003 [ 1664.973848] dfe0: 43759194 7e8d76cc 435e77f0 4307ef9c [ 1664.978897] Code: bad PC
