Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.kernel > #85682 > unrolled thread

Bug#1093371: megaraid_sas didn't work anymore with Xen

Started byBen Hutchings <ben@decadent.org.uk>
First post2025-02-19 21:30 +0100
Last post2025-02-23 21:30 +0100
Articles 3 — 2 participants

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Bug#1093371: megaraid_sas didn't work anymore with Xen Ben Hutchings <ben@decadent.org.uk> - 2025-02-19 21:30 +0100
    Bug#1093371: megaraid_sas didn't work anymore with Xen <reportbug@csds.ch> - 2025-02-21 12:00 +0100
      Bug#1093371: megaraid_sas didn't work anymore with Xen Ben Hutchings <ben@decadent.org.uk> - 2025-02-23 21:30 +0100

#85682 — Bug#1093371: megaraid_sas didn't work anymore with Xen

FromBen Hutchings <ben@decadent.org.uk>
Date2025-02-19 21:30 +0100
SubjectBug#1093371: megaraid_sas didn't work anymore with Xen
Message-ID<KhYRH-sfv-1@gated-at.bofh.it>

[Multipart message — attachments visible in raw view] — view raw

Hi Nicolas,

Sorrry for the delay in handling this bug.

We think this regression is due to the upstream change:

commit 9f40ec84a7976d95c34e7cc070939deb103652b0
Author: Juergen Gross <jgross@suse.com>
Date:   Fri Sep 13 12:05:02 2024 +0200
 
    xen/swiotlb: add alignment check for dma buffers

which was backported to the 6.1-stable series.

To confirm this, please can you test:

1. Is this fixed in the latest released kernel for bookworm (version
6.1.128-1)?  If it is, you can stop here.

2. Is this fixed in version 6.1.128-1a~test from
<https://people.debian.org/~benh/packages/linux-xen-regression/>?
(This reverts the above change.)

3. Is this fixed in version 6.1.128-1a~test2, from the same place?
(This adds an upstream fix on top of the above change.)

Note that the test packages above are not signed for use with Secure
Boot.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
                               A fail-safe circuit will destroy others.

[toc] | [next] | [standalone]


#86014

From<reportbug@csds.ch>
Date2025-02-21 12:00 +0100
Message-ID<KiyVc-OVq-5@gated-at.bofh.it>
In reply to#85682

[Multipart message — attachments visible in raw view] — view raw

Hi Ben,

I was following this discussion as I was affected from the very same issue as well. Axel Beckert was helping me, analyzing this issue further (thank you, Axel).

I installed the test kernel you mentioned in your last email and it worked for me.

In my case I encountered issues with an Areca controller (Areca Technology Corp. ARC-188x series PCIe 2.0/3.0 to SAS/SATA 6/12Gb RAID Controller (rev 02)) that was not recognized anymore.


I only saw the following errors in dmesg:
[Thu Nov 28 00:33:11 2024] Areca RAID Controller0: Model ARC-1883, F/W V1.70 2024-08-05
[Thu Nov 28 00:33:11 2024] arcmsr0: dma_alloc_coherent got error
[Thu Nov 28 00:33:11 2024] arcmsr0: arcmsr_alloc_ccb_pool got error

With your test kernel the correct output is now:
[ 4.599360] Areca RAID Controller0: Model ARC-1883, F/W V1.70 2024-08-05
[ 4.607260] scsi host0: Areca SAS/SATA RAID Controller (RAID6 capable)
arcmsr version v1.50.00.05-20210429
[ 4.608990] arcmsr0: msi-x enabled
[ 4.635797] arcmsr0: cdb_phyaddr_hi32=0x11
[ 4.991584] scsi 0:0:0:0: Direct-Access Areca ARC-1883-VOL#000 R001 PQ: 0 ANSI: 5
[ 4.994960] scsi 0:0:16:0: Processor Areca RAID controller R001 PQ: 0 ANSI: 0

Thank you very much for your work. I appreciate it a lot!


Best wishes,

David

On Wednesday, 19 February 2025 at 21:18:41 +01:00, Ben Hutchings <ben@decadent.org.uk> wrote:

> Hi Nicolas,
> 
> Sorrry for the delay in handling this bug.
> 
> We think this regression is due to the upstream change:
> 
> commit 9f40ec84a7976d95c34e7cc070939deb103652b0
> Author: Juergen Gross <<jgross@suse.com>>
> Date: Fri Sep 13 12:05:02 2024 +0200
> 
> xen/swiotlb: add alignment check for dma buffers
> 
> which was backported to the 6.1-stable series.
> 
> To confirm this, please can you test:
> 
> 1. Is this fixed in the latest released kernel for bookworm (version
> 6.1.128-1)? If it is, you can stop here.
> 
> 2. Is this fixed in version 6.1.128-1a~test from
> <<https://people.debian.org/~benh/packages/linux-xen-regression/>>?
> (This reverts the above change.)
> 
> 3. Is this fixed in version 6.1.128-1a~test2, from the same place?
> (This adds an upstream fix on top of the above change.)
> 
> Note that the test packages above are not signed for use with Secure
> Boot.
> 
> Ben.
> 
> -- 
> Ben Hutchings
> Klipstein's 4th Law of Prototyping and Production:
> A fail-safe circuit will destroy others.
> 

[toc] | [prev] | [next] | [standalone]


#86104

FromBen Hutchings <ben@decadent.org.uk>
Date2025-02-23 21:30 +0100
Message-ID<KjqLT-1s29-1@gated-at.bofh.it>
In reply to#86014

[Multipart message — attachments visible in raw view] — view raw

Hi Nicolas,

On Fri, 2025-02-21 at 11:32 +0100, reportbug@csds.ch wrote:
> Hi Ben,
> 
> I was following this discussion as I was affected from the very same issue as well. Axel Beckert was helping me, analyzing this issue further (thank you, Axel).
> 
> I installed the test kernel you mentioned in your last email and it worked for me.
[...]

Thank you for testing and confirming the fix.  This fix should be
included in the next update to bookworm.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
                               A fail-safe circuit will destroy others.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.kernel


csiph-web