Gentoo Archives: gentoo-user

From: meino.cramer@×××.de
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Re: Cohorent pool size too small...
Date: Tue, 07 Oct 2014 15:52:25
Message-Id: 20141007155132.GA3826@solfire
In Reply to: Re: [gentoo-user] Re: Cohorent pool size too small... by Hinnerk van Bruinehsen
1 Hinnerk van Bruinehsen <h.v.bruinehsen@×××××××××.de> [14-10-07 17:23]:
2 > On Mon, Oct 06, 2014 at 06:34:06PM +0200, meino.cramer@×××.de wrote:
3 > <SNIP>
4 > >
5 > > Moin Hinnerk,
6 > > (hopefully have guessed this greet correctly...I am from that
7 > > part of Germany ;)
8 > >
9 > > I have the source of the driver exclusivly compiled for 3.8.13
10 > > as for 3.14.something (cant remember).
11 > > 3.14.x has some other problems (on that embedded platform) like
12 > > not powering off when shutdown, random reboots and such.
13 > > So decided to go back to 3.8.13.
14 > > Yesterday I started updateing (eix-sync and emerge) that Gentoo
15 > > and it ends up in an endless loop (bash update) of configureing
16 > > (damn slow on that mini iron) and compiling - as it looks -
17 > > of a single file.
18 > > After more than 10 hours I CTRL-C that, reupated and now I am
19 > > ...updateing the bash again.
20 > > Sigh.
21 > > Currently "fun" is something else...
22 > >
23 > > Is the 3.15.10++ branch free of things like random reboot and
24 > > not powering off?
25 >
26 > Moin Meino,
27 >
28 > (you've hit dead on spot: is there another "valid" greeting except that one?
29 > ;-) )
30 >
31 > Right now I don't have a beaglebone black so sadly I can't provide any first
32 > hand experience.
33 > A 10 hour configure loop definitely sounds fishy to me. I'm running
34 > a (hardened) Gentoo on a Raspberry Pi right now and I do compiling natively
35 > most of the time (as it's not a that critical machine). As it's an even more
36 > mini iron I know that it can be time consuming (maybe interesting: bash: 25
37 > minutes, 57 seconds for 29 merges).
38 > My rpi runs on a 3.16.3 kernel and my experience is that newer kernels help
39 > immensely if available (that is if the hardware is either supported upstream or
40 > there is a vendor branch testing new kernels). Especially for arm there is much
41 > better support lately.
42 > I find for less used platforms (read: "not-x86/amd64) the newer kernels are
43 > often more stable than "stable" ones because the latter often doesn't
44 > experience much testing.
45 >
46 > So in the end there aren't many more options than just try it out (kernel
47 > builds are quick luckily because - as you stated in your other reply - kernel
48 > builds are very easily cross-compilable).
49 >
50 > Good luck/Viel Erfolg,
51 >
52 > Hinnerk
53
54 Moin Hinnerk,
55
56 (yes, exactly what you have said: "Moin" is the way to go!!! :)) 8)))))
57
58 The problem with the kernel sources here on the beagle bone side of
59 the street arises not from the kernel sources themselve -- so to speak
60 the Torvaldic parts of Kernaltica -- but more from the parts which
61 were implemented and designed to speak to the hardware itsself.
62 3.8.x has good "cape" support ("cape": additonal pluggable PCBs)but
63 less good USB and ethernet.
64 3.14.x has better ethernet and USB but does not switch off the board
65 if shutdown (aka "battery eater") and does random reboots. The GPIOs
66 for the "capes" have to be configured more or less manually with
67 3.14.x.
68 Now I am experimenting with 3.15.x...we will see.
69 The whole process from "I want" to "I have" is time consuming,
70 because each time a lot of sources are downloaded and my DSL is
71 "old school" ;)
72
73 Thanks a lot for your help!
74 Viele Dank für Deine Hilfe! :)
75
76 Meino