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,Ok, can you submit this revert with the information about why it should
On 29/01/25 2:18 PM, Greg KH wrote:
On Wed, Jan 29, 2025 at 02:13:34PM +0530, Harshvardhan Jha wrote:My apologies,
Hi there,What culprit commit? I see no information here :(
On 29/01/25 2:05 PM, Greg KH wrote:
On Wed, Jan 29, 2025 at 02:03:51PM +0530, Harshvardhan Jha wrote:Since, this is reproducible on 5.4.y I have added stable. The
Hi All,Confused, what are you wanting us to do here in the stable tree?
+stable
There seems to be some formatting issues in my log output. I have
attached it as a file.
thanks,
greg k-h
culprit
commit which upon getting reverted fixes this issue is also
present in
5.4.y stable.
Remember, top-posting is evil...
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.
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
Attachment:
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature