Re: gfx1100: first successes with pass-through
Hi Brian,
On 2024-09-14 18:30, Brian DeRocher wrote:
> On 9/13/24 18:10, Brian DeRocher wrote:
>> I'm documenting the process here.
>> https://hackmd.io/UINQqeaTTOSRNv1yhFjVqw
>>
> I got about 5 steps in. But the last 3 kernel builds are erroring out.
> I mean they boot and daemons start, but before I get to a prompt, I get
> dropped into an emergency shell. The only apparent failure is something
> related to decompression. I strongly suspect the .config has something
> weird in it.
I experienced the same in my attempt a few weeks ago and I share your
suspicion.
Looking at bookworm's 6.1 config, we have
| CONFIG_MODULE_COMPRESS_NONE=y
| # CONFIG_MODULE_COMPRESS_GZIP is not set
| # CONFIG_MODULE_COMPRESS_XZ is not set
| # CONFIG_MODULE_COMPRESS_STD is not set
whereas 6.10's config has
| # CONFIG_MODULE_COMPRESS_NONE is not set
| # CONFIG_MODULE_COMPRESS_GZIP is not set
| CONFIG_MODULE_COMPRESS_XZ=y
Looking at the kernel's d/changelog, this was enabled in 6.6.3-1~exp1:
| * Compress all modules:
| - Set MODULE_COMPRESS_XZ.
So this should actually have been supported in the good case 6.6.
This was as far as I got before I had to abort to a lack of time.
As I was building on a bookworm host, my suspicion was that perhaps some
other part of the kernel build tooling might have had an effect on this.
> Anyone know how to build a simple and sane .config for each version of
> the kernel. As I'm bisecting, I some times go forward in time and
> backward in time. So I want it to have configuration options that make
> sense for the current version.
My approach was to download the official 6.6 kernel .debs from
snapshot.debian.org, install it, and grab its /boot/config-6.6*.
Running make oldconfig should produce relatively few new options (those
that were added/changed in 6.7).
> Also, I set bad to 6.6.15 and good to 6.7.12. But oddly, after setting
> a step as "skip", git bisect brought me to a 6.5.0 kernel! Specifically
> it was v6.5.0-rc7-01777-ge1133ac81176. The commit hash is e1133ac81176.
Odd.
> Has anyone used eatmydata. I mean it would be nice to avoid syncing
> to my slow disk for every write.
For such a scratch build, which you can always re-run in the event of
some failure, eatmydata is defintitely fine.
Best,
Christian
Reply to: