udev faulting with openbmc filesystem builds.

udev faulting with openbmc filesystem builds.

[Steven J. Hill]

Hello.

I'm working with an AST2500 development board. I have built the
Palmetto and Witherspoon platforms. I am taking the filesystem
'obmc-phosphor-image-PLATFORM-20180208xxxxxx.rootfs.squashfs-xz'
and placing the files on a USB flash drive. Coldplugging devices
with 'udev' always faults as shown below. I have a custom 4.10
kernel that works with non-OBMC root filesystems just fine. Does
anyone have some ideas? Please reply to me directly as multiple
attempts to subscribe to this list have failed. Cheers.

Steve


[  OK  ] Started Apply Kernel Variables.
         Starting Create System Users...
Unable to handle kernel paging request at virtual address 9bda7000
pgd = db1ac000
[9bda7000] *pgd=00000000
Internal error: Oops: 5 [#1] ARM
Modules linked in:
CPU: 0 PID: 146 Comm: udevadm Not tainted 4.10.0+ #3
Hardware name: ASpeed BMC SoC
task: db025ac0 task.stack: db170000
PC is at strlen+0xc/0x38
LR is at kstrdup+0x20/0x58
pc : [<c01f2bb4>]    lr : [<c00965ec>]    psr: a0000013
sp : db171d30  ip : db171d40  fp : db171d3c
r10: dbff85c0  r9 : dbd9c208  r8 : 00000fff
r7 : db171d9a  r6 : 9bda7000  r5 : c0266bc4  r4 : 014000c0
r3 : dbd95890  r2 : 0000f000  r1 : 014000c0  r0 : 9bda7000
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 00c5387d  Table: 9b1ac008  DAC: 00000055
Process udevadm (pid: 146, stack limit = 0xdb170188)
Stack: (0xdb171d30 to 0xdb172000)
1d20:                                     db171d5c db171d40 c00965ec c01f2bb4
1d40: dbd9c208 db171d9c dbd9c200 db171d9a db171d6c db171d60 c0266bc4 c00965d8
1d60: db171d8c db171d70 c026b5d8 c0266b98 dbd9c208 db058000 dbd9c200 db171da4
1d80: db171dc4 db171d90 c026b778 c026b56c db171d9c db171da0 f000432c 00000000
1da0: 00000000 00000000 dbc26d00 db058000 dbd9c208 db057000 db171dec db171dc8
1dc0: c0268f20 c026b648 dbff3f20 c059b8c8 c04324ac db057000 00000fff dbd9c208
1de0: db171e04 db171df0 c0268d40 c0268e78 dbff3f20 00001000 db171e34 db171e08
1e00: c011c7bc c0268d28 c011c72c dbff3f20 00001000 db171e60 00000000 dbd3f680
1e20: db171f78 00000001 db171e44 db171e38 c011b2c4 c011c738 db171e9c db171e48
1e40: c00e0a08 c011b2a4 db171ebc 7f6ad9a0 00001000 dbff3f50 db00f5d0 dbfe7580
1e60: 00000000 00000000 00000055 014000c0 0007f6af dbff85c0 00001000 db171f78
1e80: db171f78 00000000 00001000 00000000 db171edc db171ea0 c011bfa8 c00e0958
1ea0: 00000817 7f6af9ac 00000055 7f6ad9a0 db171efc c011be6c dbd3f680 db171f78
1ec0: db171f78 00000000 00001000 00000000 db171f44 db171ee0 c00bdb0c c011be78
1ee0: 7f6af9ac db171fb0 b6e69b94 00000001 db171fac db171f00 c0009244 c0015560
1f00: dbfe7590 00000000 7f6d0000 db055ba0 db171f7c db171f20 c00a85f8 c00a6b04
1f20: 00001000 dbd3f680 00001000 dbd3f680 7f6ad9a0 db171f78 db171f74 db171f48
1f40: c00bf12c c00bdae8 7f6d0000 7f6af000 db171f74 dbd3f680 dbd3f680 00000000
1f60: 00000000 7f6ad9a0 db171fa4 db171f78 c00bffec c00bf0ac 00000000 00000000
1f80: 7f6ad838 b6d95c84 00001000 00000003 c000f784 db170000 00000000 db171fa8
1fa0: c000f5e0 c00bffb4 7f6ad838 b6d95c84 00000005 7f6ad9a0 00001000 00000040
1fc0: 7f6ad838 b6d95c84 00001000 00000003 ffffffff ffffffff 7f6ad9a0 b6e67ba8
1fe0: 00000000 beb0251c b6d95924 b6dee64c 60000010 00000005 00000000 00000000
Backtrace:
[<c01f2ba8>] (strlen) from [<c00965ec>] (kstrdup+0x20/0x58)
[<c00965cc>] (kstrdup) from [<c0266bc4>] (misc_devnode+0x38/0x40)
 r7:db171d9a r6:dbd9c200 r5:db171d9c r4:dbd9c208
[<c0266b8c>] (misc_devnode) from [<c026b5d8>] (device_get_devnode+0x78/0xdc)
[<c026b560>] (device_get_devnode) from [<c026b778>] (dev_uevent+0x13c/0x1e0)
 r7:db171da4 r6:dbd9c200 r5:db058000 r4:dbd9c208
[<c026b63c>] (dev_uevent) from [<c0268f20>] (uevent_show+0xb4/0x118)
 r7:db057000 r6:dbd9c208 r5:db058000 r4:dbc26d00
[<c0268e6c>] (uevent_show) from [<c0268d40>] (dev_attr_show+0x24/0x50)
 r9:dbd9c208 r8:00000fff r7:db057000 r6:c04324ac r5:c059b8c8 r4:dbff3f20
[<c0268d1c>] (dev_attr_show) from [<c011c7bc>] (sysfs_kf_seq_show+0x90/0xfc)
 r5:00001000 r4:dbff3f20
[<c011c72c>] (sysfs_kf_seq_show) from [<c011b2c4>] (kernfs_seq_show+0x2c/0x30)
 r10:00000001 r9:db171f78 r8:dbd3f680 r7:00000000 r6:db171e60 r5:00001000
 r4:dbff3f20 r3:c011c72c
[<c011b298>] (kernfs_seq_show) from [<c00e0a08>] (seq_read+0xbc/0x4c0)
[<c00e094c>] (seq_read) from [<c011bfa8>] (kernfs_fop_read+0x13c/0x1b8)
 r10:00000000 r9:00001000 r8:00000000 r7:db171f78 r6:db171f78 r5:00001000
 r4:dbff85c0
[<c011be6c>] (kernfs_fop_read) from [<c00bdb0c>] (__vfs_read+0x30/0x114)
 r10:00000000 r9:00001000 r8:00000000 r7:db171f78 r6:db171f78 r5:dbd3f680
 r4:c011be6c
[<c00bdadc>] (__vfs_read) from [<c00bf12c>] (vfs_read+0x8c/0x114)
 r7:db171f78 r6:7f6ad9a0 r5:dbd3f680 r4:00001000
[<c00bf0a0>] (vfs_read) from [<c00bffec>] (SyS_read+0x44/0x98)
 r8:7f6ad9a0 r7:00000000 r6:00000000 r5:dbd3f680 r4:dbd3f680
[<c00bffa8>] (SyS_read) from [<c000f5e0>] (ret_fast_syscall+0x0/0x34)
 r9:db170000 r8:c000f784 r7:00000003 r6:00001000 r5:b6d95c84 r4:7f6ad838
Code: c0412150 e1a0c00d e92dd800 e24cb004 (e5d03000)
---[ end trace 79534d21c87b0cbe ]---
[FAILED] Failed to start udev Coldplug all Devices.
See 'systemctl status systemd-udev-trigger.service' for details.
[  OK  ] Started Create System Users.

Re: udev faulting with openbmc filesystem builds.

[Joel Stanley]

Hi Steve,

On Fri, Feb 9, 2018 at 5:38 PM, Steven J. Hill <Steven.Hill@cavium.com> wrote:
> I'm working with an AST2500 development board. I have built the
> Palmetto and Witherspoon platforms. I am taking the filesystem
> 'obmc-phosphor-image-PLATFORM-20180208xxxxxx.rootfs.squashfs-xz'
> and placing the files on a USB flash drive. Coldplugging devices
> with 'udev' always faults as shown below. I have a custom 4.10
> kernel that works with non-OBMC root filesystems just fine.

Do your other filesystems have similar userspace components, such as systemd?

Have you tried to reproduce using the OpenBMC kernel?

Cheers,

Joel


> [  OK  ] Started Apply Kernel Variables.
>          Starting Create System Users...
> Unable to handle kernel paging request at virtual address 9bda7000
> pgd = db1ac000
> [9bda7000] *pgd=00000000
> Internal error: Oops: 5 [#1] ARM
> Modules linked in:
> CPU: 0 PID: 146 Comm: udevadm Not tainted 4.10.0+ #3
> Hardware name: ASpeed BMC SoC
> task: db025ac0 task.stack: db170000
> PC is at strlen+0xc/0x38
> LR is at kstrdup+0x20/0x58
> pc : [<c01f2bb4>]    lr : [<c00965ec>]    psr: a0000013
> sp : db171d30  ip : db171d40  fp : db171d3c
> r10: dbff85c0  r9 : dbd9c208  r8 : 00000fff
> r7 : db171d9a  r6 : 9bda7000  r5 : c0266bc4  r4 : 014000c0
> r3 : dbd95890  r2 : 0000f000  r1 : 014000c0  r0 : 9bda7000
> Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
> Control: 00c5387d  Table: 9b1ac008  DAC: 00000055
> Process udevadm (pid: 146, stack limit = 0xdb170188)
> Stack: (0xdb171d30 to 0xdb172000)
> 1d20:                                     db171d5c db171d40 c00965ec c01f2bb4
> 1d40: dbd9c208 db171d9c dbd9c200 db171d9a db171d6c db171d60 c0266bc4 c00965d8
> 1d60: db171d8c db171d70 c026b5d8 c0266b98 dbd9c208 db058000 dbd9c200 db171da4
> 1d80: db171dc4 db171d90 c026b778 c026b56c db171d9c db171da0 f000432c 00000000
> 1da0: 00000000 00000000 dbc26d00 db058000 dbd9c208 db057000 db171dec db171dc8
> 1dc0: c0268f20 c026b648 dbff3f20 c059b8c8 c04324ac db057000 00000fff dbd9c208
> 1de0: db171e04 db171df0 c0268d40 c0268e78 dbff3f20 00001000 db171e34 db171e08
> 1e00: c011c7bc c0268d28 c011c72c dbff3f20 00001000 db171e60 00000000 dbd3f680
> 1e20: db171f78 00000001 db171e44 db171e38 c011b2c4 c011c738 db171e9c db171e48
> 1e40: c00e0a08 c011b2a4 db171ebc 7f6ad9a0 00001000 dbff3f50 db00f5d0 dbfe7580
> 1e60: 00000000 00000000 00000055 014000c0 0007f6af dbff85c0 00001000 db171f78
> 1e80: db171f78 00000000 00001000 00000000 db171edc db171ea0 c011bfa8 c00e0958
> 1ea0: 00000817 7f6af9ac 00000055 7f6ad9a0 db171efc c011be6c dbd3f680 db171f78
> 1ec0: db171f78 00000000 00001000 00000000 db171f44 db171ee0 c00bdb0c c011be78
> 1ee0: 7f6af9ac db171fb0 b6e69b94 00000001 db171fac db171f00 c0009244 c0015560
> 1f00: dbfe7590 00000000 7f6d0000 db055ba0 db171f7c db171f20 c00a85f8 c00a6b04
> 1f20: 00001000 dbd3f680 00001000 dbd3f680 7f6ad9a0 db171f78 db171f74 db171f48
> 1f40: c00bf12c c00bdae8 7f6d0000 7f6af000 db171f74 dbd3f680 dbd3f680 00000000
> 1f60: 00000000 7f6ad9a0 db171fa4 db171f78 c00bffec c00bf0ac 00000000 00000000
> 1f80: 7f6ad838 b6d95c84 00001000 00000003 c000f784 db170000 00000000 db171fa8
> 1fa0: c000f5e0 c00bffb4 7f6ad838 b6d95c84 00000005 7f6ad9a0 00001000 00000040
> 1fc0: 7f6ad838 b6d95c84 00001000 00000003 ffffffff ffffffff 7f6ad9a0 b6e67ba8
> 1fe0: 00000000 beb0251c b6d95924 b6dee64c 60000010 00000005 00000000 00000000
> Backtrace:
> [<c01f2ba8>] (strlen) from [<c00965ec>] (kstrdup+0x20/0x58)
> [<c00965cc>] (kstrdup) from [<c0266bc4>] (misc_devnode+0x38/0x40)
>  r7:db171d9a r6:dbd9c200 r5:db171d9c r4:dbd9c208
> [<c0266b8c>] (misc_devnode) from [<c026b5d8>] (device_get_devnode+0x78/0xdc)
> [<c026b560>] (device_get_devnode) from [<c026b778>] (dev_uevent+0x13c/0x1e0)
>  r7:db171da4 r6:dbd9c200 r5:db058000 r4:dbd9c208
> [<c026b63c>] (dev_uevent) from [<c0268f20>] (uevent_show+0xb4/0x118)
>  r7:db057000 r6:dbd9c208 r5:db058000 r4:dbc26d00
> [<c0268e6c>] (uevent_show) from [<c0268d40>] (dev_attr_show+0x24/0x50)
>  r9:dbd9c208 r8:00000fff r7:db057000 r6:c04324ac r5:c059b8c8 r4:dbff3f20
> [<c0268d1c>] (dev_attr_show) from [<c011c7bc>] (sysfs_kf_seq_show+0x90/0xfc)
>  r5:00001000 r4:dbff3f20
> [<c011c72c>] (sysfs_kf_seq_show) from [<c011b2c4>] (kernfs_seq_show+0x2c/0x30)
>  r10:00000001 r9:db171f78 r8:dbd3f680 r7:00000000 r6:db171e60 r5:00001000
>  r4:dbff3f20 r3:c011c72c
> [<c011b298>] (kernfs_seq_show) from [<c00e0a08>] (seq_read+0xbc/0x4c0)
> [<c00e094c>] (seq_read) from [<c011bfa8>] (kernfs_fop_read+0x13c/0x1b8)
>  r10:00000000 r9:00001000 r8:00000000 r7:db171f78 r6:db171f78 r5:00001000
>  r4:dbff85c0
> [<c011be6c>] (kernfs_fop_read) from [<c00bdb0c>] (__vfs_read+0x30/0x114)
>  r10:00000000 r9:00001000 r8:00000000 r7:db171f78 r6:db171f78 r5:dbd3f680
>  r4:c011be6c
> [<c00bdadc>] (__vfs_read) from [<c00bf12c>] (vfs_read+0x8c/0x114)
>  r7:db171f78 r6:7f6ad9a0 r5:dbd3f680 r4:00001000
> [<c00bf0a0>] (vfs_read) from [<c00bffec>] (SyS_read+0x44/0x98)
>  r8:7f6ad9a0 r7:00000000 r6:00000000 r5:dbd3f680 r4:dbd3f680
> [<c00bffa8>] (SyS_read) from [<c000f5e0>] (ret_fast_syscall+0x0/0x34)
>  r9:db170000 r8:c000f784 r7:00000003 r6:00001000 r5:b6d95c84 r4:7f6ad838
> Code: c0412150 e1a0c00d e92dd800 e24cb004 (e5d03000)
> ---[ end trace 79534d21c87b0cbe ]---
> [FAILED] Failed to start udev Coldplug all Devices.
> See 'systemctl status systemd-udev-trigger.service' for details.
> [  OK  ] Started Create System Users.

Re: udev faulting with openbmc filesystem builds.

[Steven J. Hill]

On 02/12/2018 12:44 AM, Joel Stanley wrote:
> 
> Do your other filesystems have similar userspace components, such as systemd?
> 
> Have you tried to reproduce using the OpenBMC kernel?
> 
Joel,

Yes, I have tried the OpenBMC kernel and get the same results. Let me outline
my platform, kernel versions tried, etc. for completeness.

Developing on Aspeed AST2500 evaluation board. The core is an AST2500-A1.
The detailed core information from the kernel is:

   CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5307d
   CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
   OF: fdt: Machine model: AST2500 EVB

Kernels that I have tested:

   Palmetto (built by the OBMC build system)
   Witherspoon (built by the OBMC build system)
   Generic OpenBMC kernel from 'dev-4.10' branch
   Aspeed SDK kernel based on 4.9 (supplied from Aspeed)
   Aspeed SDK kernel based on 4.10 (ported by me)
   Aspeed SDK kernel based on 4.11 (ported by me)
   Aspeed SDK kernel based on 4.12 (ported by me)
   Aspeed SDK kernel based on 4.13 (ported by me)
   Aspeed SDK kernel based on 4.14 (ported by me)
   Aspeed SDK kernel based on 4.15 (ported by me)

Root filesystems tested, all using systemd:

   Palmetto
   Witherspoon
   buildroot (HEAD)

All kernel/RFS combinations fault at exactly the same function inside
of 'udevadm' shown below. It is always the 'strlen' function. For all
test runs the virtual address is always aligned on a 4KB page boundary.
I have tried variations of SLUB, SLAB, enabling errata workarounds,
passing different 'mem=xxx' to the kernel, kernel hacking options,
"kernel mem{cpy,set}() for {copy_to,clear}_user()" option and others.
This is where I am currently. Any insight would be great. Cheers.

Steve



Unable to handle kernel paging request at virtual address 9bc8c000
pgd = db438000
[9bc8c000] *pgd=00000000
Internal error: Oops: 5 [#1] ARM
Modules linked in:
CPU: 0 PID: 900 Comm: udevadm Not tainted 4.10.0+ #3
Hardware name: ASpeed BMC SoC
task: dbed7880 task.stack: db4ae000
PC is at strlen+0xc/0x38
LR is at kstrdup+0x20/0x58
pc : [<c01f610c>]    lr : [<c00965ec>]    psr: a0000013
sp : db4afd30  ip : db4afd40  fp : db4afd3c
r10: db5a88c0  r9 : dbda1f08  r8 : 00000fff
r7 : db4afd9a  r6 : 9bc8c000  r5 : c0269d9c  r4 : 014000c0
r3 : dbdbf990  r2 : 0000f000  r1 : 014000c0  r0 : 9bc8c000
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 00c5387d  Table: 9b438008  DAC: 00000055
Process udevadm (pid: 900, stack limit = 0xdb4ae188)
Stack: (0xdb4afd30 to 0xdb4b0000)
...
...
...
Backtrace:
[<c01f6100>] (strlen) from [<c00965ec>] (kstrdup+0x20/0x58)
[<c00965cc>] (kstrdup) from [<c0269d9c>] (misc_devnode+0x38/0x40)
 r7:db4afd9a r6:dbda1f00 r5:db4afd9c r4:dbda1f08
[<c0269d64>] (misc_devnode) from [<c026e7b0>] (device_get_devnode+0x78/0xdc)
[<c026e738>] (device_get_devnode) from [<c026e950>] (dev_uevent+0x13c/0x1e0)

Re: udev faulting with openbmc filesystem builds.

[Brad Bishop]

> On Feb 9, 2018, at 2:08 AM, Steven J. Hill <Steven.Hill@cavium.com> wrote:
> 
> Please reply to me directly as multiple
> attempts to subscribe to this list have failed.

Can you elaborate on the trouble you had?  This isn’t the first time I’ve heard
of people having trouble subscribing to the list.  I would like to get this fixed
up.

Re: udev faulting with openbmc filesystem builds.

[Steven J. Hill]

On 02/12/2018 01:26 PM, Brad Bishop wrote:
> 
> Can you elaborate on the trouble you had?  This isn’t the first time I’ve heard
> of people having trouble subscribing to the list.  I would like to get this fixed
> up.
> 
I took Jeremy's input and opened up a ticket internally to see WTH our
mail server is doing. I will ask for details once they fix this.

Re: udev faulting with openbmc filesystem builds.

[Joel Stanley]

On Tue, Feb 13, 2018 at 4:44 AM, Steven J. Hill <Steven.Hill@cavium.com> wrote:
> On 02/12/2018 12:44 AM, Joel Stanley wrote:
>>
>> Do your other filesystems have similar userspace components, such as systemd?
>>
>> Have you tried to reproduce using the OpenBMC kernel?
>>
> Joel,
>
> Yes, I have tried the OpenBMC kernel and get the same results. Let me outline
> my platform, kernel versions tried, etc. for completeness.
>
> Developing on Aspeed AST2500 evaluation board. The core is an AST2500-A1.
> The detailed core information from the kernel is:
>
>    CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5307d
>    CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
>    OF: fdt: Machine model: AST2500 EVB
>
> Kernels that I have tested:
>
>    Palmetto (built by the OBMC build system)
>    Witherspoon (built by the OBMC build system)
>    Generic OpenBMC kernel from 'dev-4.10' branch

When you say "generic", which device tree are you using?

I don't know what has gone wrong from your backtrace. Which device
driver was being loaded when you hit this issue? Booting with
initcall_debug might help here.

I suggest you use the device tree for the ast2500-evb. Here's how I
would build a kernel for testing:

git checkout dev-4.13
make CROSS_COMPILE=arm-linux-gnueabi- ARCH=arm aspeed_g5_defconfig
make CROSS_COMPILE=arm-linux-gnueabi- ARCH=arm

cat << EOF > evb.its
/dts-v1/;

/ {
        description = "test kernel";
        #address-cells = <1>;

        images {
                kernel@1 {
                        description = "Linux kernel";
                        data = /incbin/("arch/arm/boot/zImage");
                        type = "kernel";
                        arch = "arm";
                        os = "linux";
                        compression = "none";
                        load = <0x80001000>;
                        entry = <0x80001000>;
                };
                fdt@1 {
                        description = "device tree";
                        data =
/incbin/("arch/arm/boot/dts/aspeed-ast2500-evb.dtb");
                        type = "flat_dt";
                        arch = "arm";
                        compression = "none";
                };
                ramdisk@1 {
                        description = "initramfs";
                        data = /incbin/("rootfs.cpio.xz");
                        type = "ramdisk";
                        arch = "arm";
                        os = "linux";
                };
        };

        configurations {
                default = "conf@1";
                conf@1 {
                        description = "Boot Linux kernel with FDT
blob, ramdisk";
                        kernel = "kernel@1";
                        fdt = "fdt@1";
                        ramdisk = "ramdisk@1";
                };
        };
};
EOF

mkimage -f evb.its evb
cp evb /srv/tftp/

From u-boot:

setenv serverip <tftp server ip>
dhcp evb
bootm

If that shows the bug, send me the fill dmesg log with initcall_debug
enabled and we can go from there.

Cheers,

Joel

>    Aspeed SDK kernel based on 4.9 (supplied from Aspeed)
>    Aspeed SDK kernel based on 4.10 (ported by me)
>    Aspeed SDK kernel based on 4.11 (ported by me)
>    Aspeed SDK kernel based on 4.12 (ported by me)
>    Aspeed SDK kernel based on 4.13 (ported by me)
>    Aspeed SDK kernel based on 4.14 (ported by me)
>    Aspeed SDK kernel based on 4.15 (ported by me)
>
> Root filesystems tested, all using systemd:
>
>    Palmetto
>    Witherspoon
>    buildroot (HEAD)
>
> All kernel/RFS combinations fault at exactly the same function inside
> of 'udevadm' shown below. It is always the 'strlen' function. For all
> test runs the virtual address is always aligned on a 4KB page boundary.
> I have tried variations of SLUB, SLAB, enabling errata workarounds,
> passing different 'mem=xxx' to the kernel, kernel hacking options,
> "kernel mem{cpy,set}() for {copy_to,clear}_user()" option and others.
> This is where I am currently. Any insight would be great. Cheers.
>
> Steve
>
>
>
> Unable to handle kernel paging request at virtual address 9bc8c000
> pgd = db438000
> [9bc8c000] *pgd=00000000
> Internal error: Oops: 5 [#1] ARM
> Modules linked in:
> CPU: 0 PID: 900 Comm: udevadm Not tainted 4.10.0+ #3
> Hardware name: ASpeed BMC SoC
> task: dbed7880 task.stack: db4ae000
> PC is at strlen+0xc/0x38
> LR is at kstrdup+0x20/0x58
> pc : [<c01f610c>]    lr : [<c00965ec>]    psr: a0000013
> sp : db4afd30  ip : db4afd40  fp : db4afd3c
> r10: db5a88c0  r9 : dbda1f08  r8 : 00000fff
> r7 : db4afd9a  r6 : 9bc8c000  r5 : c0269d9c  r4 : 014000c0
> r3 : dbdbf990  r2 : 0000f000  r1 : 014000c0  r0 : 9bc8c000
> Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
> Control: 00c5387d  Table: 9b438008  DAC: 00000055
> Process udevadm (pid: 900, stack limit = 0xdb4ae188)
> Stack: (0xdb4afd30 to 0xdb4b0000)
> ...
> ...
> ...
> Backtrace:
> [<c01f6100>] (strlen) from [<c00965ec>] (kstrdup+0x20/0x58)
> [<c00965cc>] (kstrdup) from [<c0269d9c>] (misc_devnode+0x38/0x40)
>  r7:db4afd9a r6:dbda1f00 r5:db4afd9c r4:dbda1f08
> [<c0269d64>] (misc_devnode) from [<c026e7b0>] (device_get_devnode+0x78/0xdc)
> [<c026e738>] (device_get_devnode) from [<c026e950>] (dev_uevent+0x13c/0x1e0)

Re: udev faulting with openbmc filesystem builds.

[Steven J. Hill]

On 02/12/2018 07:51 PM, Joel Stanley wrote:
> 
> I suggest you use the device tree for the ast2500-evb. Here's how I
> would build a kernel for testing:
> 
> git checkout dev-4.13
> make CROSS_COMPILE=arm-linux-gnueabi- ARCH=arm aspeed_g5_defconfig
> make CROSS_COMPILE=arm-linux-gnueabi- ARCH=arm
>Cool, this worked. I took the entire RFS from 'witherspoon' and made
a ramdisk and there is no fault with udevadm. It boots up completely
and I finally get a serial console. The diff between v4.13.16 and
the 'dev-4.13' tree is only 20K lines. I can easily dig through and
see what I have wrong in my kernel. Thank you so much for the help.

Steve