[Adding qemu-stable@ to Cc]

On 10/15/25 13:33, Guenter Roeck wrote:
Hi all,

I lost track what exactly I reported, so here is a summary of reverts and
patches I needed to get qemu 10.1.1 and 10.0.5 working for me.

Reported to where?


---
v10.1.1:

commit b1adefa3cf40df5b1e72c77eab80284831344aba
Author:     Guenter Roeck <[email protected]>
AuthorDate: Tue Oct 14 15:41:04 2025 -0700
Commit:     Guenter Roeck <[email protected]>
CommitDate: Tue Oct 14 15:44:23 2025 -0700

     Revert "scsi-disk: Advertise FUA support by default"
This reverts commit 5562e214e82ae4bcb0b642cc52b304bdc78a58c3.

     Triggers
[ 30.688576] sd 0:2:0:0: [sda] tag#413 UNKNOWN(0x2003) Result: hostbyte=0x04 driverbyte=DRIVER_OK cmd_age=0s
     [   30.689126] sd 0:2:0:0: [sda] tag#413 CDB: opcode=0x2a 2a 08 00 00 00 
02 00 00 02 00
     [   30.689431] I/O error, dev sda, sector 2 op 0x1:(WRITE) flags 0x20800 
phys_seg 1 prio class 2
     [   30.689667] Buffer I/O error on dev sda, logical block 1, lost sync 
page write
     [   30.690052] EXT4-fs (sda): I/O error while writing superblock
     mount: mounting /dev/root on / failed: I/O error
when trying to boot from megasas/megasas2 on riscv systems, and subsequently
     hangs in scsi code when trying to shut down.

Do you have a reproducer of this?  At least, I see
ext4 fs is involved, so it's a linux guest, it looks like.
Something else?


commit 7a7e0ff6552fd5ca60d31d302fde492c7194208b
Author:     Guenter Roeck <[email protected]>
AuthorDate: Sun Oct 12 20:26:29 2025 -0700
Commit:     Guenter Roeck <[email protected]>
CommitDate: Sun Oct 12 20:37:24 2025 -0700

     Revert "hw/usb/network: Remove hardcoded 0x40 prefix in STRING_ETHADDR 
response"
This reverts commit 4474802b0cd59fa14b603b953fa0bc8cc92783c0. The patch seems innocent but causes net-cdc connection failures.

What's the reproducer of this?

And is master branch have the same issue?

Note: this commit id is in 10.0.x stable branch, not in 10.1.x branch
as you reported above.  The commit ID of this change in 10.1.x is
88006572b4, and on master branch it is aaf042299ac.


commit 193a0b3f3cdbba3605e6c0be6bf81e5ebf54e5ba
Author:     Guenter Roeck <[email protected]>
AuthorDate: Sun Oct 12 11:31:40 2025 -0700
Commit:     Guenter Roeck <[email protected]>
CommitDate: Sun Oct 12 11:31:40 2025 -0700

     Revert "target/sh4: Use MO_ALIGN for system UNALIGN()"
This reverts commit eb978e50e42f3439e7a7a104e76aafc81bc4a028.

A problem with this is?  The reproducer is?
commit a0698826d4a652257d315efc758c6f8f68d52ef1
Author:     Richard Henderson <[email protected]>
AuthorDate: Sat Oct 4 12:24:14 2025 -0700
Commit:     Guenter Roeck <[email protected]>
CommitDate: Sun Oct 12 11:23:02 2025 -0700

     accel/tcg: Hoist first page lookup above pointer_wrap
For strict alignment targets we registered cpu_pointer_wrap_notreached,
     but generic code used it before recognizing the alignment exception.
     Hoist the first page lookup, so that the alignment exception happens first.
Cc: [email protected]
     Buglink: https://bugs.debian.org/1112285
     Fixes: a4027ed7d4be ("target: Use cpu_pointer_wrap_notreached for strict align 
targets")
     Signed-off-by: Richard Henderson <[email protected]>
     Signed-off-by: Guenter Roeck <[email protected]>

And what's with this one?   It is queued up for next stable-10.1.

commit 84762d228175b9c24ec4a7a48420722ec3dfb978
Author:     Guenter Roeck <[email protected]>
AuthorDate: Sat Oct 4 12:41:40 2025 -0700
Commit:     Guenter Roeck <[email protected]>
CommitDate: Wed Oct 8 14:58:53 2025 -0700

     Revert "hw/riscv: Make FDT optional for MPFS"
This reverts commit 0c2ca9e4d139acc762325d994614a42dba31be6a. Prevents kernel command line from being accepted.

A reproducer please?

commit 82421bc6a895d679a6c4a7c0c4570e2f4c644261
Author:     Guenter Roeck <[email protected]>
AuthorDate: Sat Oct 4 12:41:05 2025 -0700
Commit:     Guenter Roeck <[email protected]>
CommitDate: Wed Oct 8 14:58:53 2025 -0700

     Revert "hw/riscv: Allow direct start of kernel for MPFS"
This reverts commit 6dd6f11710c713bd21ac67ab93f6db33169c6b4d. Prevents kernel command line from being accepted.

Is it the same as above?  A reproducer please?

There's not enough information provided.  Please give us some
more food to harvest the issues.

/mjt


Reply via email to