partial success but does not boot: 3.2~rc7
 

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


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: Pine.BSM.4.64L.1201012337470.20109@herc.mirbsd.org ">http://lists.debian.org/Pine.BSM.4.64L.1201012337470.20109@herc.mirbsd.org

partial success but does not boot: 3.2~rc7
 

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.

partial success but does not boot: 3.2~rc7
 

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


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120108175727.GD29499@suse.de">http://lists.debian.org/20120108175727.GD29499@suse.de