Hi there,
On 31/01/25 5:35 PM, Harshvardhan Jha wrote:
On 30/01/25 6:05 PM, Jürgen Groß wrote:
On 29.01.25 19:46, Harshvardhan Jha wrote:
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.
Can you try the attached patch, please? I don't have a system at hand showing the problem.
I tried this and got this error in an infinite loop again: [ 25.827922] megaraid_sas 0000:65:00.0: megasas_build_io_fusion 3273 sge_count (-12) is out of range. Range is: 0-256 [ 25.828447] megaraid_sas 0000:65:00.0: Error building command
Would this require a change in the megasas driver also as simply changing xen code isn't fixing the issue?
Harshvardhan
Juergen