On Sun, 2012-01-01 at 21:16 +0000, Thorsten Glaser wrote: [...] > • patches/0006-Bastian-Blank-do-not-error-out-when-kernel-wedge-ret.patch > > This is _from_ waldi via IRC: > > 18:10⎜<mirabilos> kernel-wedge install-files 3.2.0-rc7 > 18:10⎜<mirabilos> could not find kernel image at /usr/share/kernel-wedge/commands/install-files line 103, > ⎜ <KVERS> line 2. > 18:11⎜<mirabilos> make[2]: *** [install-udeb_m68k] Error 2 > 18:11⎜«waldi» ich dachte die fehler werden ignoriert …# > > 19:03⎜<mirabilos> find: ebian/kernel-image-3.2.0-rc7-atari-di': No such file or directory > 19:03⎜<mirabilos> kernel-image-3.2.0-rc7-atari-di will be empty > 19:03⎜<mirabilos> find: ebian/nic-shared-modules-3.2.0-rc7-atari-di': No such file or directory > 19:03⎜<mirabilos> nic-shared-modules-3.2.0-rc7-atari-di will be empty > 19:03⎜<mirabilos> hrm. > 19:03⎜<mirabilos> waldi, was ist da kaputt? > 19:03⎜<mirabilos> ich wars nicht > > I just wonder why this seems to have been needed in the first place. It is quite possible that m68k kernel udebs have not been built for some years, though the configuration has been updated along with other architectures. The module list for nic-shared-modules on m68k looks wrong in that there are several driver modules listed there; those belong in nic-modules or nic-extra-modules. If m68k doesn't have any network drivers using the library modules such as mii then the package should be disabled by removing the module list file. > 18:50⎜<mirabilos> -rw-r--r-- 1 root root 1845989 Jan 1 18:32 > ⎜ /var/cache/pbuilder/build/cow.937/tmp/buildd/linux-2.6-3.2~rc7/debian/linux-image-3.2.0-rc7-atari/boo > ⎜ t/vmlinuz-3.2.0-rc7-atari > > $sourcedir wrong? $installedname wrong? Did you also build the amiga and mac flavours? The kernel-versions file for m68k lists all three flavours. > No idea whether this should be committed. Hell no. We must either fix or remove the kernel-wedge configuration for m68k. (I already did the latter for alpha.) [...] > • work and fail > > This is for debian-68k, linux-68k and debian-kernel: > > ARAnyM “console” output of a working (3.0) and failing (3.2) boot, > for your debugging pleasure. I can run arbitrary tests against the > failing kernel, as long as they’re limited to [LILO].Args or make > it boot ;-) This is presumably triggered by enabling CPU topology information in sysfs on UP systems. This is a Debian patch for 3.2 (features/all/topology-Provide-CPU-topology-in-sysfs-in-SMP-configura.patch) but has been accepted upstream for 3.3. My guess is that on m68k get_cpu_sysdev(0) returns NULL and thus topology_add_dev() passes an invalid pointer into sysfs_create_group(). So either m68k (and maybe some other architectures with no SMP support) need to be fixed or the CPU topology code needs to allow for this. Ben. -- Ben Hutchings Humour is the best antidote to reality.
Attachment:
signature.asc
Description: This is a digitally signed message part