Hi,
I wanted to follow up on my previous email regarding the visitor list. Please let me know your thoughts—I’d be happy to provide more details. Plus, we’re currently offering an exclusive discount, making this the perfect time to secure the list at the best price!
Looking forward to your response.
Best regards,
Grace
Subject: Integrated Systems Europe 2025-with Discount!
Hi,
Would you like to get the latest list of exhibitors and attendees for Integrated Systems Europe 2025? This comprehensive list includes last-minute registrants as well.
Event Details:
Location: Fira Barcelona Gran Via, Barcelona, Spain
Exhibitors: 1,460
Attendees: 73,891
Available Data Fields: Individual Email Address, Phone Number, Contact Name, Job Title, Company Name, Website, Physical Address, and more.
Let me know if you're interested in the attendees list, exhibitors list, or both! I’d be happy to share pricing and additional details.
Looking forward to your response!
Best regards,
Grace Green
Sr. Demand Generation
P.S. If you’d prefer not to receive updates, simply reply with “NO.”
GCC 15 changed the default C standard dialect from gnu17 to gnu23,
which should not have impacted the kernel because it explicitly requests
the gnu11 standard in the main Makefile. However, mips/vdso code uses
its own CFLAGS without a '-std=' value, which break with this dialect
change because of the kernel's own definitions of bool, false, and true
conflicting with the C23 reserved keywords.
include/linux/stddef.h:11:9: error: cannot use keyword 'false' as enumeration constant
11 | false = 0,
| ^~~~~
include/linux/stddef.h:11:9: note: 'false' is a keyword with '-std=c23' onwards
include/linux/types.h:35:33: error: 'bool' cannot be defined via 'typedef'
35 | typedef _Bool bool;
| ^~~~
include/linux/types.h:35:33: note: 'bool' is a keyword with '-std=c23' onwards
Add '-std=gnu11' to the decompressor and purgatory CFLAGS to eliminate
these errors and make the C standard version of these areas match the
rest of the kernel.
Signed-off-by: Khem Raj <raj.khem(a)gmail.com>
Cc: stable(a)vger.kernel.org
---
arch/mips/vdso/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/vdso/Makefile b/arch/mips/vdso/Makefile
index b289b2c1b294..15521004c563 100644
--- a/arch/mips/vdso/Makefile
+++ b/arch/mips/vdso/Makefile
@@ -30,7 +30,7 @@ cflags-vdso := $(ccflags-vdso) \
-O3 -g -fPIC -fno-strict-aliasing -fno-common -fno-builtin -G 0 \
-mrelax-pic-calls $(call cc-option, -mexplicit-relocs) \
-fno-stack-protector -fno-jump-tables -DDISABLE_BRANCH_PROFILING \
- $(call cc-option, -fno-asynchronous-unwind-tables)
+ $(call cc-option, -fno-asynchronous-unwind-tables) -std=gnu11
aflags-vdso := $(ccflags-vdso) \
-D__ASSEMBLY__ -Wa,-gdwarf-2
On Mon, Mar 03, 2025 at 03:58:30PM +0100, Eric wrote:
> Hi Niklas
>
> Le 03/03/2025 à 07:25, Niklas Cassel a écrit :
> > So far, this just sounds like a bug where UEFI cannot detect your SSD.
> Bit it is detected during cold boot, though.
> > UEFI problems should be reported to your BIOS vendor.
> I'll try to see what can be done, however I am not sure how responsive they
> will be for this board...
> >
> > It would be interesting to see if _Linux_ can detect your SSD, after a
> > reboot, without UEFI involvement.
> >
> > If you kexec into the same kernel as you are currently running:
> > https://manpages.debian.org/testing/kexec-tools/kexec.8.en.html
> >
> > Do you see your SSD in the kexec'd kernel?
>
> Sorry, I've tried that using several methods (systemctl kexec / kexec --load
> + kexec -e / kexec --load + shutdown --reboot now) and it failed each time.
> I *don't* think it is related to this bug, however, because each time the
> process got stuck just after displaying "kexec_core: Starting new kernel".
I just tired (as root):
# kexec -l /boot/vmlinuz-6.13.5-200.fc41.x86_64 --initrd=/boot/initramfs-6.13.5-200.fc41.x86_64.img --reuse-cmd
# kexec -e
and FWIW, kexec worked fine.
Did you specify an initrd ? did you specify --reuse-cmd ?
If not, please try it.
It would be interesting to see if Linux can detect your SATA drive after
a kexec. If it can't, then we need to report the issue to your drive
vendor (Samsung).
Kind regards,
Niklas
In ThinPro, we use the convention <upstream_ver>+hp<patchlevel> for
the kernel package. This does not have a dash in the name or version.
This is built by editing ".version" before a build, and setting
EXTRAVERSION="+hp" and KDEB_PKGVERSION make variables:
echo 68 > .version
make -j<n> EXTRAVERSION="+hp" bindeb-pkg KDEB_PKGVERSION=6.12.2+hp69
.deb name: linux-image-6.12.2+hp_6.12.2+hp69_amd64.deb
Since commit 7d4f07d5cb71 ("kbuild: deb-pkg: squash
scripts/package/deb-build-option to debian/rules"), this no longer
works. The deb build logic changed, even though, the commit message
implies that the logic should be unmodified.
Before, KBUILD_BUILD_VERSION was not set if the KDEB_PKGVERSION did
not contain a dash. After the change KBUILD_BUILD_VERSION is always
set to KDEB_PKGVERSION. Since this determines UTS_VERSION,the uname
output to look off:
(now) uname -a: version 6.12.2+hp ... #6.12.2+hp69
(expected) uname -a: version 6.12.2+hp ... #69
Update the debian/rules logic to restore the original behavior.
Cc: <stable(a)vger.kernel.org>
Fixes: 7d4f07d5cb71 ("kbuild: deb-pkg: squash scripts/package/deb-build-option to debian/rules")
Signed-off-by: Alexandru Gagniuc <alexandru.gagniuc(a)hp.com>
Reviewed-by: Nicolas Schier <nicolas(a)fjasle.eu>
---
Changes since v1:
* Rework logic so that dpkg-parsechangelog is invoked just once
* Adjust commit message to reflect review feedback
scripts/package/debian/rules | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/scripts/package/debian/rules b/scripts/package/debian/rules
index ca07243bd5cd..d1f400685682 100755
--- a/scripts/package/debian/rules
+++ b/scripts/package/debian/rules
@@ -21,9 +21,11 @@ ifeq ($(origin KBUILD_VERBOSE),undefined)
endif
endif
-revision = $(lastword $(subst -, ,$(shell dpkg-parsechangelog -S Version)))
+revision = $(shell dpkg-parsechangelog -S Version | sed -n 's/.*-//p')
CROSS_COMPILE ?= $(filter-out $(DEB_BUILD_GNU_TYPE)-, $(DEB_HOST_GNU_TYPE)-)
-make-opts = ARCH=$(ARCH) KERNELRELEASE=$(KERNELRELEASE) KBUILD_BUILD_VERSION=$(revision) $(addprefix CROSS_COMPILE=,$(CROSS_COMPILE))
+make-opts = ARCH=$(ARCH) KERNELRELEASE=$(KERNELRELEASE) $(addprefix \
+ KBUILD_BUILD_VERSION=,$(revision)) $(addprefix \
+ CROSS_COMPILE=,$(CROSS_COMPILE))
binary-targets := $(addprefix binary-, image image-dbg headers libc-dev)
--
2.48.1
Incomplete backport of series "xfs: log intent item recovery should
reconstruct defer work state" [1] leads to a kernel crash during the
xfs/235 test execution on top of 6.6.y stable.
Tested (briefly) with my local xfstests setup. Additional testing would
be much appreciated.
[1]: https://lore.kernel.org/linux-xfs/170191741007.1195961.10092536809136830257…
XFS (loop1): Corruption of in-memory data (0x8) detected at xfs_trans_cancel+0x4d9/0x610 (fs/xfs/xfs_trans.c:1097). Shutting down filesystem.
XFS (loop1): Please unmount the filesystem and rectify the problem(s)
general protection fault, probably for non-canonical address 0xdffffc000000000c: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000060-0x0000000000000067]
CPU: 1 PID: 2011 Comm: mount Not tainted 6.6.84-rc2+ #12
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
RIP: 0010:xlog_recover_cancel_intents+0xad/0x1b0
Call Trace:
<TASK>
xlog_recover_finish+0x7f6/0x9a0
xfs_log_mount_finish+0x386/0x650
xfs_mountfs+0x1405/0x1fb0
xfs_fs_fill_super+0x11d6/0x1ca0
get_tree_bdev+0x3b4/0x650
vfs_get_tree+0x92/0x370
path_mount+0x13b9/0x1f10
__x64_sys_mount+0x286/0x310
do_syscall_64+0x39/0x90
entry_SYSCALL_64_after_hwframe+0x78/0xe2
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:xlog_recover_cancel_intents+0xad/0x1b0
Link to the original bug report [2].
[2]: https://lore.kernel.org/stable/6pxyzwujo52p4bp2otliyssjcvsfydd6ju32eusdlyhz…
Found by Linux Verification Center (linuxtesting.org).
Darrick J. Wong (4):
xfs: recreate work items when recovering intent items
xfs: dump the recovered xattri log item if corruption happens
xfs: use xfs_defer_finish_one to finish recovered work items
xfs: move ->iop_recover to xfs_defer_op_type
fs/xfs/libxfs/xfs_defer.c | 22 ++++-
fs/xfs/libxfs/xfs_defer.h | 14 +++
fs/xfs/libxfs/xfs_log_recover.h | 4 +-
fs/xfs/xfs_attr_item.c | 115 ++++++++++++------------
fs/xfs/xfs_bmap_item.c | 92 ++++++++++---------
fs/xfs/xfs_extfree_item.c | 117 +++++++++++--------------
fs/xfs/xfs_log_recover.c | 37 ++++----
fs/xfs/xfs_refcount_item.c | 127 +++++++++------------------
fs/xfs/xfs_rmap_item.c | 151 ++++++++++++++++----------------
fs/xfs/xfs_trans.h | 4 -
10 files changed, 326 insertions(+), 357 deletions(-)
--
2.49.0