Re: v5.4.289 failed to boot with error megasas_build_io_fusion 3219 sge_count (-12) is out of range

[Harshvardhan Jha <harshvardhan.j.jha@oracle.com>]

On 29/01/25 4:52 PM, Juergen Gross wrote:
> On 29.01.25 10:15, Harshvardhan Jha wrote:
>>
>> On 29/01/25 2:34 PM, Greg KH wrote:
>>> On Wed, Jan 29, 2025 at 02:29:48PM +0530, Harshvardhan Jha wrote:
>>>> Hi Greg,
>>>>
>>>> On 29/01/25 2:18 PM, Greg KH wrote:
>>>>> On Wed, Jan 29, 2025 at 02:13:34PM +0530, Harshvardhan Jha wrote:
>>>>>> Hi there,
>>>>>>
>>>>>> On 29/01/25 2:05 PM, Greg KH wrote:
>>>>>>> On Wed, Jan 29, 2025 at 02:03:51PM +0530, Harshvardhan Jha wrote:
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> +stable
>>>>>>>>
>>>>>>>> There seems to be some formatting issues in my log output. I have
>>>>>>>> attached it as a file.
>>>>>>> Confused, what are you wanting us to do here in the stable tree?
>>>>>>>
>>>>>>> thanks,
>>>>>>>
>>>>>>> greg k-h
>>>>>> Since, this is reproducible on 5.4.y I have added stable. The
>>>>>> culprit
>>>>>> commit which upon getting reverted fixes this issue is also
>>>>>> present in
>>>>>> 5.4.y stable.
>>>>> What culprit commit?  I see no information here :(
>>>>>
>>>>> Remember, top-posting is evil...
>>>> My apologies,
>>>>
>>>> The stable tag v5.4.289 seems to fail to boot with the following
>>>> prompt in an infinite loop:
>>>> [   24.427217] megaraid_sas 0000:65:00.0: megasas_build_io_fusion
>>>> 3273 sge_count (-12) is out of range. Range is:  0-256
>>>>
>>>> Reverting the following patch seems to fix the issue:
>>>>
>>>> stable-5.4      : v5.4.285             - 5df29a445f3a xen/swiotlb: add
>>>> alignment check for dma buffers
>>>>
>>>> I tried changing swiotlb grub command line arguments but that didn't
>>>> seem to help much unfortunately and the error was seen again.
>>>>
>>> Ok, can you submit this revert with the information about why it should
>>> not be included in the 5.4.y tree and cc: everyone involved and then we
>>> will be glad to queue it up.
>>>
>>> thanks,
>>>
>>> greg k-h
>>
>> This might be reproducible on other stable trees and mainline as well so
>> we will get it fixed there and I will submit the necessary fix to stable
>> when everything is sorted out on mainline.
>
> Right. Just reverting my patch will trade one error with another one (the
> one which triggered me to write the patch).
>
> There are two possible ways to fix the issue:
>
> - allow larger DMA buffers in xen/swiotlb (today 2MB are the max.
> supported
>   size, the megaraid_sas driver seems to effectively request 4MB)

This seems relatively simpler to implement but I'm not sure whether it's
the most optimal approach

>
> - fix the megaraid_sas driver by splitting up the allocated DMA buffer
> (it is
>   requesting 2.3MB, which will be rounded up to 4MB - it is probably
> not needed
>   to be in one chunk, so a split would result in max. 2MB chunk size)
>
> Both variants have their pros and cons, though.
>
>
> Juergen
Harshvardhan