[m68k] partial success but does not boot: 3.2~rc7

[m68k] partial success but does not boot: 3.2~rc7

[Thorsten Glaser]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4589 bytes --]

Hi,

I have good and bad news: I got 3.2~rc7 compiled with some
patches, but it’s panicking.

I’ve attached a .tgz with the following content:

a) patches against (a git copy of) the linux-2.6 trunk SVN:

• patches/0001-distinguish-level-of-xz-compression-to-use-for-packa.patch

This is for waldi:

Use varying levels of xz compression for the packages, not always
dpkg-deb’s default of -6, and add a comment for what levels to use
once we can depend on dpkg-deb 1.16.2 after Guillem told me that
it will support -e (extreme). See #652636 for discussion. This was
primarily added here so I had a bit of speedup for building… change
to suit taste, then please commit.

• patches/0002-switch-m68k-to-gcc-4.6.patch

This is for debian-68k:

This is a tendency, our userspace was switched already. It builds,
but I have no idea whether this is a/the cause of it panicking.

Might be useful to commit, though, unless it _is_ the culprit.

• patches/0003-fix-the-aufs-pr_fmt-FTBFS-issue.patch

This is for bwh:

This is the same patch as I sent out in the mail to the AUFS thread
with mid <Pine.BSM.4.64L.1201010113350.14351@herc.mirbsd.org> (the
second version, with #undef pr_fmt – the kernel was built with the
first version though, which only differs by generating cpp redefine
warnings, which don’t change the code).

The AUFS module builds, links, but I cannot test whether it loads,
since the kernel doesn’t come up.

Since Geert does not want my other patch, I suppose we’ll need it.

• patches/0004-fix-passing-CFLAGS_KERNEL-to-kbuild.patch

This is for debian-kernel (waldi, probably):

Fix the way a debian/*/defines 'cflags' is passed to kbuild.
Please do commit.

• patches/0005-use-cflags-ffreestanding-at-least-on-m68k-maybe-Clos.patch

This is for waldi and linux-m68k:

Your suggestion to use -ffreestanding indeed Closes: #648996
Please do commit. Depends on 0004.

• 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: \x04ebian/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: \x04ebian/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.

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?

No idea whether this should be committed.

• patches/0007-defines-and-changelog-for-my-personal-testing-image.patch

This is for me, just included for the sake of completeness: when I
test-build (not for uploading), I run source and arch:all builds on
an amd64 domU sponsored by zigo, and only arch:any stuff on m68k,
for speed. I disable the amd64 debugging package and other stuff,
and m68k flavours except the one I need (atari) for my tests. It
also shows the changelog entry. It doesn’t show the regeneration
of generated files by d/rules clean.


• 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 ;-)


I can also provide the files on request:

-rw-r--r-- 1 pbuilder 1234 7951926 Jan  1 18:42 linux-image-3.2.0-rc7-atari_3.2~rc7-1~experimental.1tg1_m68k.deb
and linux-headers* and linux-libc-dev* which are less useful.

bye,
//mirabilos
-- 
<ch> you introduced a merge commit        │<mika> % g rebase -i HEAD^^
<mika> sorry, no idea and rebasing just fscked │<mika> Segmentation
<ch> should have cloned into a clean repo      │  fault (core dumped)
<ch> if I rebase that now, it's really ugh     │<mika:#grml> wuahhhhhh

[-- Attachment #2: Type: APPLICATION/OCTET-STREAM, Size: 9479 bytes --]

Re: [m68k] partial success but does not boot: 3.2~rc7

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 3010 bytes --]

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: \x04ebian/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: \x04ebian/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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [m68k] partial success but does not boot: 3.2~rc7

[Thorsten Glaser]

Ben Hutchings dixit:

>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.

I don’t think that is it, as the last upload had this in .changes:

[…]
 4b1a4046ca58561cc6c94d020a9f10f4 1997696 debian-installer extra kernel-image-3.0.0-2-amiga-di_3.0.0-6_m68k.udeb
 af52e25d6186c6fd5c9b20888221f97a 35168 debian-installer standard nic-shared-modules-3.0.0-2-amiga-di_3.0.0-6_m6
 808da40f5886053613dceae960cc64f8 38508 debian-installer optional ppp-modules-3.0.0-2-amiga-di_3.0.0-6_m68k.udeb
 e664ddcea14d6a5f341a8cdfefefac2e 10918 debian-installer standard cdrom-core-modules-3.0.0-2-amiga-di_3.0.0-6_m6
 8f1fa83300a63dc0017eafc97da549cd 15636 debian-installer standard scsi-modules-3.0.0-2-amiga-di_3.0.0-6_m68k.ude
 1ceac41404a52273068c08d02d993557 305086 debian-installer extra btrfs-modules-3.0.0-2-amiga-di_3.0.0-6_m68k.udeb
 f37e385c35fbae32f93d78312054009f 18960 debian-installer standard isofs-modules-3.0.0-2-amiga-di_3.0.0-6_m68k.ud
[…]

>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.

 d4ef87ebeac4a5177f560a7627d9ea52 13250 debian-installer standard nic-shared-modules-3.0.0-2-atari-di_3.0.0-6_m6

It built last time and seems to have some content.

>> 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.

Ah, that might be it. On the other hand, I seem to recall it erroring out
on the atari part. Not too sure.

>> 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.)

OK. I hope “we” (and maybe, when^Wif they wake up, the m68k porters)
can fix it, instead. Wouter’s built a d-i during DebĆevapčićiConf,
after all.

>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.

@linux-m68k, are you listening in? ;-)

Goodnight, and happy new year,
//mirabilos
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
	-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc

Re: [m68k] partial success but does not boot: 3.2~rc7

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]

On Sun, 2012-01-01 at 23:27 +0000, Ben Hutchings wrote:
> On Sun, 2012-01-01 at 21:16 +0000, Thorsten Glaser wrote:
[...]
> > • 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.

None of these architectures appears to call register_cpu():

    c6x frv h8300 m68k microblaze openrisc score um xtensa

and therefore they will all panic at boot following this change (commit
ccbc60d3e19a1b6ae66ca0d89b3da02dde62088b).  So either I can try to fix
them or else it must be reverted for now.

Ben.

-- 
Ben Hutchings
Humour is the best antidote to reality.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [m68k] partial success but does not boot: 3.2~rc7

[Greg KH]

On Sun, Jan 01, 2012 at 11:53:45PM +0000, Ben Hutchings wrote:
> On Sun, 2012-01-01 at 23:27 +0000, Ben Hutchings wrote:
> > On Sun, 2012-01-01 at 21:16 +0000, Thorsten Glaser wrote:
> [...]
> > > • 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.
> 
> None of these architectures appears to call register_cpu():
> 
>     c6x frv h8300 m68k microblaze openrisc score um xtensa
> 
> and therefore they will all panic at boot following this change (commit
> ccbc60d3e19a1b6ae66ca0d89b3da02dde62088b).  So either I can try to fix
> them or else it must be reverted for now.

As this is now in Linus's tree, and he has asked for a fix, could you
make one up?

thanks,

greg k-h