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
