[gentoo-user] Cohorent pool size too small...

[gentoo-user] Cohorent pool size too small...

[meino.cramer]

Hi,

while trying to get a mt7601sta (UWN200 WiFi dongle) driver running
and working I came accross this in the dmesg output:

[    9.931938] usb 2-1: device v148f p7601 is not supported
[    9.931976] usb 2-1: New USB device found, idVendor=148f, idProduct=7601
[    9.931994] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   10.077532] rtusb init rt2870 --->
[   10.079338] 

=== pAd = e0c58000, size = 860808 ===

[   10.079939] ERROR: 256 KiB atomic DMA coherent pool is too small!
Please increase it with coherent_pool= kernel parameter!
[   10.079968] <-- ERROR in Alloc Bulk buffer for HTTxContext!
[   10.079983] ---> RTMPFreeTxRxRingMemory
[   10.080026] <--- RTMPFreeTxRxRingMemory
[   10.080040] ERROR!!! Failed to allocate memory - TxRxRing


But 

cat /proc/cmdline 

shows:

console=tty1 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fixrtc capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G,coherent_pool=2M

(this is an embedded device, thats why there are the other parameters
around...)

I do not find any way to set this parameter while compiling the
kernel. And setting the kernel parameter seems not to work either...

Lost?

...or am I only blind... ? ;)

How can I increase the cohorent pool size successfully?

Best regards,
mcc

PS: The driver sources are not included in the kernel and have to be
compiled externally/extra...

[gentoo-user] Re: Cohorent pool size too small...

[walt]

On 10/05/2014 06:52 AM, meino.cramer@gmx.de wrote:
> Hi,
> 
> while trying to get a mt7601sta (UWN200 WiFi dongle) driver running
> and working I came accross this in the dmesg output:
> 
> [    9.931938] usb 2-1: device v148f p7601 is not supported

This looks to me like it's the real error, not the one below.

> [    9.931976] usb 2-1: New USB device found, idVendor=148f, idProduct=7601
> [    9.931994] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> [   10.077532] rtusb init rt2870 --->
> [   10.079338] 
> 
> === pAd = e0c58000, size = 860808 ===
> 
> [   10.079939] ERROR: 256 KiB atomic DMA coherent pool is too small!
> Please increase it with coherent_pool= kernel parameter!
> [   10.079968] <-- ERROR in Alloc Bulk buffer for HTTxContext!
> [   10.079983] ---> RTMPFreeTxRxRingMemory
> [   10.080026] <--- RTMPFreeTxRxRingMemory
> [   10.080040] ERROR!!! Failed to allocate memory - TxRxRing
> 
> 
> But 
> 
> cat /proc/cmdline 
> 
> shows:
> 
> console=tty1 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fixrtc capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G,coherent_pool=2M
> 
> (this is an embedded device, thats why there are the other parameters
> around...)
> 
> I do not find any way to set this parameter while compiling the
> kernel. And setting the kernel parameter seems not to work either...
> 
> Lost?
> 
> ...or am I only blind... ? ;)
> 
> How can I increase the cohorent pool size successfully?
> 
> Best regards,
> mcc
> 
> PS: The driver sources are not included in the kernel and have to be
> compiled externally/extra...
> 
> 
> 

Re: [gentoo-user] Re: Cohorent pool size too small...

[meino.cramer]

walt <w41ter@gmail.com> [14-10-05 16:16]:
> On 10/05/2014 06:52 AM, meino.cramer@gmx.de wrote:
> > Hi,
> > 
> > while trying to get a mt7601sta (UWN200 WiFi dongle) driver running
> > and working I came accross this in the dmesg output:
> > 
> > [    9.931938] usb 2-1: device v148f p7601 is not supported
> 
> This looks to me like it's the real error, not the one below.

What I dont understand is: If I provide the kernel driver...why does
the kernel "decides" not to support the hardware the driver itsself
supports...?

By the way: I hacked the kernel to provide more coherent pool size
with the effect that NO module was loaded anymore...without any trace
in the dmesg out (beside the greater pool size itsself...)...

best regards,
mcc



> 
> > [    9.931976] usb 2-1: New USB device found, idVendor=148f, idProduct=7601
> > [    9.931994] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> > [   10.077532] rtusb init rt2870 --->
> > [   10.079338] 
> > 
> > === pAd = e0c58000, size = 860808 ===
> > 
> > [   10.079939] ERROR: 256 KiB atomic DMA coherent pool is too small!
> > Please increase it with coherent_pool= kernel parameter!
> > [   10.079968] <-- ERROR in Alloc Bulk buffer for HTTxContext!
> > [   10.079983] ---> RTMPFreeTxRxRingMemory
> > [   10.080026] <--- RTMPFreeTxRxRingMemory
> > [   10.080040] ERROR!!! Failed to allocate memory - TxRxRing
> > 
> > 
> > But 
> > 
> > cat /proc/cmdline 
> > 
> > shows:
> > 
> > console=tty1 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fixrtc capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G,coherent_pool=2M
> > 
> > (this is an embedded device, thats why there are the other parameters
> > around...)
> > 
> > I do not find any way to set this parameter while compiling the
> > kernel. And setting the kernel parameter seems not to work either...
> > 
> > Lost?
> > 
> > ...or am I only blind... ? ;)
> > 
> > How can I increase the cohorent pool size successfully?
> > 
> > Best regards,
> > mcc
> > 
> > PS: The driver sources are not included in the kernel and have to be
> > compiled externally/extra...
> > 
> > 
> > 
> 
> 
> 

[gentoo-user] Re: Cohorent pool size too small...

[walt]

On 10/05/2014 07:54 AM, meino.cramer@gmx.de wrote:
> walt <w41ter@gmail.com> [14-10-05 16:16]:
>> > On 10/05/2014 06:52 AM, meino.cramer@gmx.de wrote:
>>> > > Hi,
>>> > > 
>>> > > while trying to get a mt7601sta (UWN200 WiFi dongle) driver running
>>> > > and working I came accross this in the dmesg output:
>>> > > 
>>> > > [    9.931938] usb 2-1: device v148f p7601 is not supported
>> > 
>> > This looks to me like it's the real error, not the one below.
> What I dont understand is: If I provide the kernel driver...why does
> the kernel "decides" not to support the hardware the driver itsself
> supports...?

Where did you get the driver?  Are you sure it's really the right one?

Re: [gentoo-user] Re: Cohorent pool size too small...

[meino.cramer]

walt <w41ter@gmail.com> [14-10-05 19:36]:
> On 10/05/2014 07:54 AM, meino.cramer@gmx.de wrote:
> > walt <w41ter@gmail.com> [14-10-05 16:16]:
> >> > On 10/05/2014 06:52 AM, meino.cramer@gmx.de wrote:
> >>> > > Hi,
> >>> > > 
> >>> > > while trying to get a mt7601sta (UWN200 WiFi dongle) driver running
> >>> > > and working I came accross this in the dmesg output:
> >>> > > 
> >>> > > [    9.931938] usb 2-1: device v148f p7601 is not supported
> >> > 
> >> > This looks to me like it's the real error, not the one below.
> > What I dont understand is: If I provide the kernel driver...why does
> > the kernel "decides" not to support the hardware the driver itsself
> > supports...?
> 
> Where did you get the driver?  Are you sure it's really the right one?
> 
> 
> 

One of the main maintainer for the Beaglebone black kernel sources
(Robert C. Nelson) point me to his git repository of this driver.

I am now back to kernel 3.8.13, where this stuff runs...
(The kernel I tried it before was 3.14.19)
But this kernel version get no much updates thess days and is 
somehow old...

Best regards,
mcc

Re: [gentoo-user] Re: Cohorent pool size too small...

[Hinnerk van Bruinehsen]

[-- Attachment #1: Type: text/plain, Size: 1814 bytes --]

On Sun, Oct 05, 2014 at 07:44:03PM +0200, meino.cramer@gmx.de wrote:
> walt <w41ter@gmail.com> [14-10-05 19:36]:
> > On 10/05/2014 07:54 AM, meino.cramer@gmx.de wrote:
> > > walt <w41ter@gmail.com> [14-10-05 16:16]:
> > >> > On 10/05/2014 06:52 AM, meino.cramer@gmx.de wrote:
> > >>> > > Hi,
> > >>> > > 
> > >>> > > while trying to get a mt7601sta (UWN200 WiFi dongle) driver running
> > >>> > > and working I came accross this in the dmesg output:
> > >>> > > 
> > >>> > > [    9.931938] usb 2-1: device v148f p7601 is not supported
> > >> > 
> > >> > This looks to me like it's the real error, not the one below.
> > > What I dont understand is: If I provide the kernel driver...why does
> > > the kernel "decides" not to support the hardware the driver itsself
> > > supports...?
> > 
> > Where did you get the driver?  Are you sure it's really the right one?
> > 
> > 
> > 
> 
> One of the main maintainer for the Beaglebone black kernel sources
> (Robert C. Nelson) point me to his git repository of this driver.
> 
> I am now back to kernel 3.8.13, where this stuff runs...
> (The kernel I tried it before was 3.14.19)
> But this kernel version get no much updates thess days and is 
> somehow old...
> 
So you tried to run a driver for 3.8.x on a 3.14.x kernel?
Such things often result in breakage as, while the kernels interface to
userspace is very stable, the internal interfaces aren't stable at all. Likely
there would be some other stuff necessary to get the driver to work properly.
Some googling around led me to [1] though, which seems to imply that there is
support on newer kernels (3.15.10 and newer), if you use the right patch...

So maybe you are sucessful with that...

WKR
Hinnerk

[1] http://www.spinics.net/lists/linux-wireless/msg126291.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] Re: Cohorent pool size too small...

[meino.cramer]

Hinnerk van Bruinehsen <h.v.bruinehsen@fu-berlin.de> [14-10-06 17:56]:
> On Sun, Oct 05, 2014 at 07:44:03PM +0200, meino.cramer@gmx.de wrote:
> > walt <w41ter@gmail.com> [14-10-05 19:36]:
> > > On 10/05/2014 07:54 AM, meino.cramer@gmx.de wrote:
> > > > walt <w41ter@gmail.com> [14-10-05 16:16]:
> > > >> > On 10/05/2014 06:52 AM, meino.cramer@gmx.de wrote:
> > > >>> > > Hi,
> > > >>> > > 
> > > >>> > > while trying to get a mt7601sta (UWN200 WiFi dongle) driver running
> > > >>> > > and working I came accross this in the dmesg output:
> > > >>> > > 
> > > >>> > > [    9.931938] usb 2-1: device v148f p7601 is not supported
> > > >> > 
> > > >> > This looks to me like it's the real error, not the one below.
> > > > What I dont understand is: If I provide the kernel driver...why does
> > > > the kernel "decides" not to support the hardware the driver itsself
> > > > supports...?
> > > 
> > > Where did you get the driver?  Are you sure it's really the right one?
> > > 
> > > 
> > > 
> > 
> > One of the main maintainer for the Beaglebone black kernel sources
> > (Robert C. Nelson) point me to his git repository of this driver.
> > 
> > I am now back to kernel 3.8.13, where this stuff runs...
> > (The kernel I tried it before was 3.14.19)
> > But this kernel version get no much updates thess days and is 
> > somehow old...
> > 
> So you tried to run a driver for 3.8.x on a 3.14.x kernel?
> Such things often result in breakage as, while the kernels interface to
> userspace is very stable, the internal interfaces aren't stable at all. Likely
> there would be some other stuff necessary to get the driver to work properly.
> Some googling around led me to [1] though, which seems to imply that there is
> support on newer kernels (3.15.10 and newer), if you use the right patch...
> 
> So maybe you are sucessful with that...
> 
> WKR
> Hinnerk
> 
> [1] http://www.spinics.net/lists/linux-wireless/msg126291.html


Moin Hinnerk, 
(hopefully have guessed this greet correctly...I am from that
part of Germany ;)

I have the source of the driver exclusivly compiled for 3.8.13
as for 3.14.something (cant remember). 
3.14.x has some other problems (on that embedded platform) like
not powering off when shutdown, random reboots and such.
So decided to go back to 3.8.13.
Yesterday I started updateing (eix-sync and emerge) that Gentoo
and it ends up in an endless loop (bash update) of configureing
(damn slow on that mini iron) and compiling - as it looks -
of a single file.
After more than 10 hours I CTRL-C that, reupated and now I am
...updateing the bash again.
Sigh.
Currently "fun" is something else...

Is the 3.15.10++ branch free of things like random reboot and
not powering off?

Best regards,
mcc

Re: [gentoo-user] Re: Cohorent pool size too small...

[thegeezer]

On 06/10/14 17:34, meino.cramer@gmx.de wrote:
> Hinnerk van Bruinehsen <h.v.bruinehsen@fu-berlin.de> [14-10-06 17:56]:
>> On Sun, Oct 05, 2014 at 07:44:03PM +0200, meino.cramer@gmx.de wrote:
>>> walt <w41ter@gmail.com> [14-10-05 19:36]:
>>>> On 10/05/2014 07:54 AM, meino.cramer@gmx.de wrote:
>>>>> walt <w41ter@gmail.com> [14-10-05 16:16]:
>>>>>>> On 10/05/2014 06:52 AM, meino.cramer@gmx.de wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> while trying to get a mt7601sta (UWN200 WiFi dongle) driver running
>>>>>>>>> and working I came accross this in the dmesg output:
>>>>>>>>>
>>>>>>>>> [    9.931938] usb 2-1: device v148f p7601 is not supported
>>>>>>> This looks to me like it's the real error, not the one below.
>>>>> What I dont understand is: If I provide the kernel driver...why does
>>>>> the kernel "decides" not to support the hardware the driver itsself
>>>>> supports...?
>>>> Where did you get the driver?  Are you sure it's really the right one?
>>>>
>>>>
>>>>
>>> One of the main maintainer for the Beaglebone black kernel sources
>>> (Robert C. Nelson) point me to his git repository of this driver.
>>>
>>> I am now back to kernel 3.8.13, where this stuff runs...
>>> (The kernel I tried it before was 3.14.19)
>>> But this kernel version get no much updates thess days and is 
>>> somehow old...
>>>
>> So you tried to run a driver for 3.8.x on a 3.14.x kernel?
>> Such things often result in breakage as, while the kernels interface to
>> userspace is very stable, the internal interfaces aren't stable at all. Likely
>> there would be some other stuff necessary to get the driver to work properly.
>> Some googling around led me to [1] though, which seems to imply that there is
>> support on newer kernels (3.15.10 and newer), if you use the right patch...
>>
>> So maybe you are sucessful with that...
>>
>> WKR
>> Hinnerk
>>
>> [1] http://www.spinics.net/lists/linux-wireless/msg126291.html
>
> Moin Hinnerk, 
> (hopefully have guessed this greet correctly...I am from that
> part of Germany ;)
>
> I have the source of the driver exclusivly compiled for 3.8.13
> as for 3.14.something (cant remember). 
> 3.14.x has some other problems (on that embedded platform) like
> not powering off when shutdown, random reboots and such.
> So decided to go back to 3.8.13.
> Yesterday I started updateing (eix-sync and emerge) that Gentoo
> and it ends up in an endless loop (bash update) of configureing
> (damn slow on that mini iron) and compiling - 

just a small aside - you might like to read up on cross compiling and
save yourself a world of pain
http://dev.gentoo.org/~armin76/arm/beaglebone/install.xml

> as it looks -
> of a single file.
> After more than 10 hours I CTRL-C that, reupated and now I am
> ...updateing the bash again.
> Sigh.
> Currently "fun" is something else...
>
> Is the 3.15.10++ branch free of things like random reboot and
> not powering off?
>
> Best regards,
> mcc
>
>
>

Re: [gentoo-user] Re: Cohorent pool size too small...

[meino.cramer]

thegeezer <thegeezer@thegeezer.net> [14-10-06 20:48]:
> On 06/10/14 17:34, meino.cramer@gmx.de wrote:
> > Hinnerk van Bruinehsen <h.v.bruinehsen@fu-berlin.de> [14-10-06 17:56]:
> >> On Sun, Oct 05, 2014 at 07:44:03PM +0200, meino.cramer@gmx.de wrote:
> >>> walt <w41ter@gmail.com> [14-10-05 19:36]:
> >>>> On 10/05/2014 07:54 AM, meino.cramer@gmx.de wrote:
> >>>>> walt <w41ter@gmail.com> [14-10-05 16:16]:
> >>>>>>> On 10/05/2014 06:52 AM, meino.cramer@gmx.de wrote:
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> while trying to get a mt7601sta (UWN200 WiFi dongle) driver running
> >>>>>>>>> and working I came accross this in the dmesg output:
> >>>>>>>>>
> >>>>>>>>> [    9.931938] usb 2-1: device v148f p7601 is not supported
> >>>>>>> This looks to me like it's the real error, not the one below.
> >>>>> What I dont understand is: If I provide the kernel driver...why does
> >>>>> the kernel "decides" not to support the hardware the driver itsself
> >>>>> supports...?
> >>>> Where did you get the driver?  Are you sure it's really the right one?
> >>>>
> >>>>
> >>>>
> >>> One of the main maintainer for the Beaglebone black kernel sources
> >>> (Robert C. Nelson) point me to his git repository of this driver.
> >>>
> >>> I am now back to kernel 3.8.13, where this stuff runs...
> >>> (The kernel I tried it before was 3.14.19)
> >>> But this kernel version get no much updates thess days and is 
> >>> somehow old...
> >>>
> >> So you tried to run a driver for 3.8.x on a 3.14.x kernel?
> >> Such things often result in breakage as, while the kernels interface to
> >> userspace is very stable, the internal interfaces aren't stable at all. Likely
> >> there would be some other stuff necessary to get the driver to work properly.
> >> Some googling around led me to [1] though, which seems to imply that there is
> >> support on newer kernels (3.15.10 and newer), if you use the right patch...
> >>
> >> So maybe you are sucessful with that...
> >>
> >> WKR
> >> Hinnerk
> >>
> >> [1] http://www.spinics.net/lists/linux-wireless/msg126291.html
> >
> > Moin Hinnerk, 
> > (hopefully have guessed this greet correctly...I am from that
> > part of Germany ;)
> >
> > I have the source of the driver exclusivly compiled for 3.8.13
> > as for 3.14.something (cant remember). 
> > 3.14.x has some other problems (on that embedded platform) like
> > not powering off when shutdown, random reboots and such.
> > So decided to go back to 3.8.13.
> > Yesterday I started updateing (eix-sync and emerge) that Gentoo
> > and it ends up in an endless loop (bash update) of configureing
> > (damn slow on that mini iron) and compiling - 
> 
> just a small aside - you might like to read up on cross compiling and
> save yourself a world of pain
> http://dev.gentoo.org/~armin76/arm/beaglebone/install.xml

Thank you for the hint!
I heard that before... ;)

yeah...I walk through all this pain (cross compiling, distcc,...) 
allready. ;)

Beside the kernel, which I compile on my PC and which 
got an excellent own cross compilling setup made by Robert Nelson,
I compile all stuff natively on the embedded system itsself.
Reason:
The kernel does not depend on other things (especially header files,
libs) except the cross compiler itsself and therefore is safe to be
cross compiled.
For everything else: I repeatedly struggled over software, which
includes suddenly header files and libs from my PCs environment
instead of the cross compiling sandbox for various reasons.
Mostly hardcoded paths and such are the reason.
Sometimes it works even with the PCs headers, sometimes it fails when
executed, often it suddenly stops compiling. My PC is 64 bit, my
embedded system is 32 bit.



> > as it looks -
> > of a single file.
> > After more than 10 hours I CTRL-C that, reupated and now I am
> > ...updateing the bash again.
> > Sigh.
> > Currently "fun" is something else...
> >
> > Is the 3.15.10++ branch free of things like random reboot and
> > not powering off?
> >
> > Best regards,
> > mcc
> >
> >
> >
> 
> 

Re: [gentoo-user] Re: Cohorent pool size too small...

[Hinnerk van Bruinehsen]

[-- Attachment #1: Type: text/plain, Size: 2128 bytes --]

On Mon, Oct 06, 2014 at 06:34:06PM +0200, meino.cramer@gmx.de wrote:
<SNIP>
> 
> Moin Hinnerk, 
> (hopefully have guessed this greet correctly...I am from that
> part of Germany ;)
> 
> I have the source of the driver exclusivly compiled for 3.8.13
> as for 3.14.something (cant remember). 
> 3.14.x has some other problems (on that embedded platform) like
> not powering off when shutdown, random reboots and such.
> So decided to go back to 3.8.13.
> Yesterday I started updateing (eix-sync and emerge) that Gentoo
> and it ends up in an endless loop (bash update) of configureing
> (damn slow on that mini iron) and compiling - as it looks -
> of a single file.
> After more than 10 hours I CTRL-C that, reupated and now I am
> ...updateing the bash again.
> Sigh.
> Currently "fun" is something else...
> 
> Is the 3.15.10++ branch free of things like random reboot and
> not powering off?

Moin Meino,

(you've hit dead on spot: is there another "valid" greeting except that one?
;-) )

Right now I don't have a beaglebone black so sadly I can't provide any first
hand experience.
A 10 hour configure loop definitely sounds fishy to me. I'm running
a (hardened) Gentoo on a Raspberry Pi right now and I do compiling natively
most of the time (as it's not a that critical machine). As it's an even more
mini iron I know that it can be time consuming (maybe interesting: bash: 25
minutes, 57 seconds for 29 merges).
My rpi runs on a 3.16.3 kernel and my experience is that newer kernels help
immensely if available (that is if the hardware is either supported upstream or
there is a vendor branch testing new kernels). Especially for arm there is much
better support lately.
I find for less used platforms (read: "not-x86/amd64) the newer kernels are
often more stable than "stable" ones because the latter often doesn't
experience much testing.

So in the end there aren't many more options than just try it out (kernel
builds are quick luckily because - as you stated in your other reply - kernel
builds are very easily cross-compilable).

Good luck/Viel Erfolg,

Hinnerk

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] Re: Cohorent pool size too small...

[meino.cramer]

Hinnerk van Bruinehsen <h.v.bruinehsen@fu-berlin.de> [14-10-07 17:23]:
> On Mon, Oct 06, 2014 at 06:34:06PM +0200, meino.cramer@gmx.de wrote:
> <SNIP>
> > 
> > Moin Hinnerk, 
> > (hopefully have guessed this greet correctly...I am from that
> > part of Germany ;)
> > 
> > I have the source of the driver exclusivly compiled for 3.8.13
> > as for 3.14.something (cant remember). 
> > 3.14.x has some other problems (on that embedded platform) like
> > not powering off when shutdown, random reboots and such.
> > So decided to go back to 3.8.13.
> > Yesterday I started updateing (eix-sync and emerge) that Gentoo
> > and it ends up in an endless loop (bash update) of configureing
> > (damn slow on that mini iron) and compiling - as it looks -
> > of a single file.
> > After more than 10 hours I CTRL-C that, reupated and now I am
> > ...updateing the bash again.
> > Sigh.
> > Currently "fun" is something else...
> > 
> > Is the 3.15.10++ branch free of things like random reboot and
> > not powering off?
> 
> Moin Meino,
> 
> (you've hit dead on spot: is there another "valid" greeting except that one?
> ;-) )
> 
> Right now I don't have a beaglebone black so sadly I can't provide any first
> hand experience.
> A 10 hour configure loop definitely sounds fishy to me. I'm running
> a (hardened) Gentoo on a Raspberry Pi right now and I do compiling natively
> most of the time (as it's not a that critical machine). As it's an even more
> mini iron I know that it can be time consuming (maybe interesting: bash: 25
> minutes, 57 seconds for 29 merges).
> My rpi runs on a 3.16.3 kernel and my experience is that newer kernels help
> immensely if available (that is if the hardware is either supported upstream or
> there is a vendor branch testing new kernels). Especially for arm there is much
> better support lately.
> I find for less used platforms (read: "not-x86/amd64) the newer kernels are
> often more stable than "stable" ones because the latter often doesn't
> experience much testing.
> 
> So in the end there aren't many more options than just try it out (kernel
> builds are quick luckily because - as you stated in your other reply - kernel
> builds are very easily cross-compilable).
> 
> Good luck/Viel Erfolg,
> 
> Hinnerk

Moin Hinnerk,

(yes, exactly what you have said: "Moin" is the way to go!!! :)) 8)))))

The problem with the kernel sources here on the beagle bone side of
the street arises not from the kernel sources themselve -- so to speak
the Torvaldic parts of Kernaltica -- but more from the parts which
were implemented and designed to speak to the hardware itsself.
3.8.x has good "cape" support  ("cape": additonal pluggable PCBs)but
less good USB and ethernet.
3.14.x has better ethernet and USB but does not switch off the board
if shutdown (aka "battery eater") and does random reboots. The GPIOs
for the "capes" have to be configured more or less manually with
3.14.x.
Now I am experimenting with 3.15.x...we will see.
The whole process from "I want" to "I have" is time consuming,
because each time a lot of sources are downloaded and my DSL is 
"old school" ;)

Thanks a lot for your help!
Viele Dank für Deine Hilfe! :)

Meino