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

Re: [m68k] 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


Reply to: