[Bug 2095169] Re: [SRU] SIGILL on emulation of RISC-V Vector instructions

@raof Do you think anything else is needed before this can be pushed to noble-updates? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2095169 Title: [SRU] SIGILL on emulation of RISC-V Vector instruc

[Bug 2095169] Re: [SRU] SIGILL on emulation of RISC-V Vector instructions

On the livecd-rootfs autopkgtest: the new test run passed, so no regressions were caused by this update. In the meantime, I've also verified that the fix unblocks an issue we had on a RISC-V partner project. -- You received this bug notification because you are a member of Ubuntu Bugs, which is

[Bug 2095169] Re: [SRU] SIGILL on emulation of RISC-V Vector instructions

Hi Christian, thanks for pointing out the omission of cpu flags in the testing procedures, that was my bad. Re: regressions listed by the SRU bot - it seems we tripped on an infrastructure issue while running autopkgtests, but I've requested a re-run just to make sure. I can also confirm that the

[Bug 2095169] Re: [SRU] SIGILL on emulation of RISC-V Vector instructions

** Description changed: [ Impact ]  * Qemu 8.2.2 claims to support the riscv64 vector extension, but fails to set the emulated vstart_eq_zero flag, which then causes illegal instruction crashes in certain cases.  * Launchpad builders currently use the same Qemu package as Noble, so this

[Bug 2095169] Re: [SRU] SIGILL on emulation of RISC-V Vector instructions

** Description changed: [ Impact ] - * Qemu 8.2.2 reports support for the riscv64 vector instruction, but fails to set the emulated vstart_eq_zero flag, which then causes illegal instruction crashes in certain cases. - * Launchpad builders use the same Qemu package as noble, so fixing thi

[Bug 2095169] Re: [SRU] SIGILL on emulation of RISC-V Vector instructions

** Changed in: qemu (Ubuntu Noble) Assignee: (unassigned) => Gabriel B. Sant'Anna (baioc) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2095169 Title: [SRU] SIGILL on emulation o

[Bug 2095169] [NEW] [SRU] SIGILL on emulation of RISC-V Vector instructions

ilures to riscv emulation failing completely, but the test above covers those cases. [ Other Info ] * n/a ** Affects: qemu (Ubuntu) Importance: Undecided Status: New ** Affects: qemu (Ubuntu Noble) Importance: Undecided Assignee: Gabriel B. Sant'Anna (baioc)

[Bug 2076173] Re: cannot display sensor name when its owner is lun1

Hi Sergio, Correct, I haven't been able to reproduce it without specific hardware. Someone pointed me to , which contains an IPMI simulator, but after an afternoon of experiments I'm still not able to generate events with the right lun.

[Bug 2076173] Re: cannot display sensor name when its owner is lun1

I wasn't able to test the specific case covered by this (sensor with lun1 owner), but in case anyone's interested in trying it out, I've built patched versions for Noble and Jammy in ppa:baioc/ipmitool-sru-sel-sensor-lun1 I'll attach the debdiffs here as well. ** Patch added: "debdiff for noble"

[Bug 2076173] Re: cannot display sensor name when its owner is lun1

** Patch added: "debdiff for jammy" https://bugs.launchpad.net/ubuntu/+source/ipmitool/+bug/2076173/+attachment/5803247/+files/ipmitool_1.8.18-11ubuntu2.2~jammy1.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.

[Bug 2076173] [NEW] cannot display sensor name when its owner is lun1

Public bug reported: ipmitool sel does not correctly display the sensor's name if its owner is set to lun1. Upstream bug: https://codeberg.org/IPMITool/ipmitool/issues/8 We were asked to track this in order to enable new hardware from a partner. It was reported in v1.8.19 (used in Noble), but li