1 |
On Tuesday, August 25, 2015 6:40:01 PM Peter Weilbacher wrote: |
2 |
> Hi Alexander, |
3 |
> |
4 |
> On Sun, 23 Aug 2015, Alexander Kapshuk wrote: |
5 |
> |
6 |
> > On Sun, Aug 23, 2015 at 4:08 PM, Peter Weilbacher |
7 |
<newsspam@××××××××××.org> wrote: |
8 |
> > > |
9 |
> > > after successfully using kernel 4.0.5 (vanilla-sources) for a while, I |
10 |
> > > upgraded to 4.1.5 last week and 4.1.6 today. I cannot boot either of |
11 |
> > > them. On the screen I see |
12 |
> > > |
13 |
> > > Decompressing Linux... Parsing ELF... done. |
14 |
> > > Booting the kernel. |
15 |
> > > |
16 |
> > > as the last thing, then it just sits there. |
17 |
> > |
18 |
> > I am running vanilla-sources 4.1.6, and so far I have not had any |
19 |
> > trouble booting it. |
20 |
> > |
21 |
> > Are you able to boot some of your previous kernels? If so, what does |
22 |
> > your '/boot/grub/grub.cfg' look like? |
23 |
> > What is the output of 'cat /etc/fstab' and 'ls -1 /boot'? |
24 |
> |
25 |
> I can still boot 4.0.5 fine, with the same setup. I use lilo, and I |
26 |
> checked that I changed the two/four digits correctly in /etc/lilo.conf. |
27 |
> |
28 |
> By chance I left the boot sit there for more than the typical minute, |
29 |
> and got multiple messages like |
30 |
> |
31 |
> INFO: rcu_sched self-detected stall on CPU { 3} (t=60000 jiffies g=-256 |
32 |
c=-257 q=193) |
33 |
> rcu_sched kthread starved for 50027 jiffies! |
34 |
> |
35 |
> right after the above "Booting the kernel." line. |
36 |
> |
37 |
> Do I need to activate a different kind of clocking or a CPU feature in |
38 |
> 4.1.x? |
39 |
> |
40 |
> Peter. |
41 |
> |
42 |
|
43 |
Here's how I would go about it: |
44 |
|
45 |
1. Add loglevel=7 to your kernel parameters and see what it prints before it |
46 |
hangs. |
47 |
|
48 |
2. Change your scheduler settings (ie. if you're using the preemptive |
49 |
scheduler or voluntary premption scheduler switch to the regular one) and try |
50 |
again. |
51 |
|
52 |
3. From your kernel parameters I assume you're using the radeon free driver |
53 |
right? If that's the case disable it (don't compile it in or just delete the |
54 |
module) and try to boot wiith a framebuffer. If you're using the proprietary |
55 |
driver it has problem with preemptive kernels, with the 3.18.x series it |
56 |
started logging a lot of errors which I assume where warnings of some change |
57 |
yet to come. |
58 |
|
59 |
4. If all else fails clone the kernel repo (be prepared to download a 2GB |
60 |
repo) and do a git bisect (google it) between the last kernel that worked and |
61 |
the first that didn't. That will eventually give you the exact commit that |
62 |
broke it. From there you can post on the mailing list for the relevant |
63 |
subsystem or you could try emailing the dev that commited it. |
64 |
|
65 |
-- |
66 |
Fernando Rodriguez |