On Wed, 29 Jan 2025, 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. > > I'm thinking of an allocated array using the max needed size (replace a > former buffer with a larger one if needed). You are referring to discontig_frames and MAX_CONTIG_ORDER in arch/x86/xen/mmu_pv.c, right? I am not super familiar with that code but it looks like a good way to go.
