[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: