Axel Beckert wrote: > ... but I actually have no idea how to cross-compile a > kernel package from amd64 to i386.
The 64 bits compiler supports native build of 32 bits binaries through the -m32 flag so you have just to install kernel build dependencies , multilibs support and point to the kernel source tree : make ARCH=i386 menuconfig and then load your kernel config from elsewhere make ARCH=i386 -j(number_of_cores) bindeb-pkg You will obtain kernel-image-<version_progressive-number>-i386.deb and kernel-headers-<version_progressive-number>-i386.deb for the 32 bit architecture. When installing the headers in the native 32 bit machine, the external modules will not be built by dkms because the headers' scripts "fixdep" and "genksym" are not cross-compiled but they're built for a x86_64 environment : those scripts can be simply replaced by copying their 32 bit version from a pre installed 32 bit headers' scripts location ( eg: /usr/src/linux-headers-5.16.0-6-common/scripts/basic/fixdep , /usr/src/linux-headers-5.16.0-6-common/scripts/genksym/genksym ) modpost gives problems to be replaced : I found a solution by installing qemu-x86_64 in the 32 bit environment , putting the 64 bits libc-2.3x.so and ld.so somewhere and finally changing in scripts/Makefile.modpost the line MODPOST = scripts/mod/modpost with MODPOST = qemu-x86_64 -L <location_of_libc-.so and_ld.so> scripts/mod/modpost You can now build your modules with : dkms autoinstall -k <kernel-version> It's an artifact that I use because I don't really want to set up a native 32 bit build host. Sooooo ....is the solution to this bug to not permit reading the driver's log when attached to an ICH4 controller ? If that's the case you will have to blacklist all the machines with that controller installed, not only "Thinkpad" branded machines. I suspect that the controller is the base for a bunch of different branded machines of a certain period ( mine is an ACER ) P.s. for readers .... for the next time , please sanitize the serial number of the drives :)
