> On 2022/Apr/25, at 01:14, Frank Scheiner <[email protected]> wrote: > > Hi guys, > > On 25.04.22 10:09, John Paul Adrian Glaubitz wrote: >>> From what I can understand by the information in the bugcheck, this is >>> somewhat related to a violation >>> in parameter copy from user to kernel during some boot-time, crypto, >>> self-test. Does that sound right? >>> If that is the case, how would this be related to FW? >> >> I'm not claiming that it must be related to the firmware, I'm just saying >> that I don't see this problem >> on my RX2660 at all and I have even reinstalled it recently with one of the >> latest firmware images >> without having to pass any parameter to the command line. > > A difference between Adrian's rx2660 and Pedro's rx2660 is Montecito > left and Montvale right. > > But could still be multiple other reasons we haven't looked at yet in > detail: > > * amount of memory installed > * SMT enabled or not > * number of processor modules installed > > It might be possible for me to check on my rx2660s (one with Montvale > and one with Montecito(s)) tomorrow. I will then also look at my other > Itanium gear and gather relevant information. >
Yes, this sounds mode likely to me too. The crypto self-tests seem to be an innocent bystander here. I tried booting the most recent kernel with the option “cryptomgr.notests” and it went much farther. Alas it still failed with another buffer copy validation for a different caller altogether: [ 3.836466] [<a000000101353690>] usercopy_abort+0x120/0x130 [ 3.836466] sp=e0000001000cfdf0 bsp=e0000001000c9388 [ 3.836466] [<a0000001004c5660>] __check_object_size+0x3c0/0x420 [ 3.836466] sp=e0000001000cfe00 bsp=e0000001000c9350 [ 3.836466] [<a000000100570030>] sys_getcwd+0x250/0x420 [ 3.836466] sp=e0000001000cfe00 bsp=e0000001000c92c8 [ 3.836466] [<a00000010000c860>] ia64_ret_from_syscall+0x0/0x20 [ 3.836466] sp=e0000001000cfe30 bsp=e0000001000c92c8 [ 3.836466] [<a000000000040720>] ia64_ivt+0xffffffff00040720/0x400 [ 3.836466] sp=e0000001000d0000 bsp=e0000001000c92c8 This suggests the bug might be in the logic validating these buffers against the allocations (heap, span, etc). I don’t know why hardened_usercopy=off is not being observed by the kernel. As a work-around I am copying myself a new kernel with CONFIG_HARDENED_USERCOPY disabled at the source. > Cheers, > Frank
