Re: [gentoo-user] Problems booting vanilla kernel 4.1.x

[Fernando Rodriguez <frodriguez.developer@outlook.com>]

On Tuesday, August 25, 2015 6:40:01 PM Peter Weilbacher wrote:
> Hi Alexander,
> 
> On Sun, 23 Aug 2015, Alexander Kapshuk wrote:
> 
> > On Sun, Aug 23, 2015 at 4:08 PM, Peter Weilbacher 
<newsspam@weilbacher.org> wrote:
> > >
> > > after successfully using kernel 4.0.5 (vanilla-sources) for a while, I
> > > upgraded to 4.1.5 last week and 4.1.6 today. I cannot boot either of
> > > them. On the screen I see
> > >
> > >    Decompressing Linux... Parsing ELF... done.
> > >    Booting the kernel.
> > >
> > > as the last thing, then it just sits there.
> >
> > I am running vanilla-sources 4.1.6, and so far I have not had any
> > trouble booting it.
> >
> > Are you able to boot some of your previous kernels? If so, what does
> > your '/boot/grub/grub.cfg' look like?
> > What is the output of 'cat /etc/fstab' and 'ls -1 /boot'?
> 
> I can still boot 4.0.5 fine, with the same setup. I use lilo, and I
> checked that I changed the two/four digits correctly in /etc/lilo.conf.
> 
> By chance I left the boot sit there for more than the typical minute,
> and got multiple messages like
> 
>   INFO: rcu_sched self-detected stall on CPU { 3}  (t=60000 jiffies g=-256 
c=-257 q=193)
>   rcu_sched kthread starved for 50027 jiffies!
> 
> right after the above "Booting the kernel." line.
> 
> Do I need to activate a different kind of clocking or a CPU feature in
> 4.1.x?
> 
>    Peter.
> 

Here's how I would go about it:

1. Add loglevel=7 to your kernel parameters and see what it prints before it 
hangs. 

2. Change your scheduler settings (ie. if you're using the preemptive 
scheduler or voluntary premption scheduler switch to the regular one) and try 
again.

3. From your kernel parameters I assume you're using the radeon free driver 
right? If that's the case disable it (don't compile it in or just delete the 
module) and try to boot wiith a framebuffer. If you're using the proprietary 
driver it has problem with preemptive kernels, with the 3.18.x series it 
started logging a lot of errors which I assume where warnings of some change 
yet to come.

4. If all else fails clone the kernel repo (be prepared to download a 2GB 
repo) and do a git bisect (google it) between the last kernel that worked and 
the first that didn't. That will eventually give you the exact commit that 
broke it. From there you can post on the mailing list for the relevant 
subsystem or you could try emailing the dev that commited it.

-- 
Fernando Rodriguez