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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 30/01/25 12:13 AM, Jürgen Groß wrote:
> On 29.01.25 19:35, Harshvardhan Jha wrote:
>>
>> 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
>
> Just making the static array larger used to hold the frame numbers for
> the
> buffer seems to be a waste of memory for most configurations.
Yep definitely not required in most cases.
>
> I'm thinking of an allocated array using the max needed size (replace a
> former buffer with a larger one if needed).

This seems like the right way to go.

Harshvardhan

>
>
> Juergen
>
> Juergen




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux