User avatar
Richard-TX
Posts: 1549
Joined: Tue May 28, 2013 3:24 pm
Location: North Texas

Re: New device tree kernel is in testing

Fri Dec 12, 2014 3:00 pm

DougieLawson wrote:I've got

[email protected] /dev # uname -a
Linux aplus 3.18.0+ #726 PREEMPT Mon Dec 8 16:01:09 GMT 2014 armv6l GNU/Linux
[email protected] /dev # ls -la i2* spi*
crw-rw---T 1 root i2c 89, 0 Dec 12 14:45 i2c-0
crw-rw---T 1 root i2c 89, 1 Dec 12 14:45 i2c-1
crw-rw---T 1 root spi 153, 0 Jan 1 1970 spidev0.0
crw-rw---T 1 root spi 153, 1 Jan 1 1970 spidev0.1
[email protected] /dev #

And a camera that doesn't work.
That sounds perfect to me.
Richard
Doing Unix since 1985.
The 9-25-2013 image of Wheezy can be found at:
http://downloads.raspberrypi.org/raspbian/images/raspbian-2013-09-27/2013-09-25-wheezy-raspbian.zip

User avatar
DougieLawson
Posts: 36578
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website Twitter

Re: New device tree kernel is in testing

Fri Dec 12, 2014 3:06 pm

PhilE wrote:@dougielawson: you're right - edited.
Thank you. The camera works now.

Next step is getting my SPI attached ethernet running.
Note: Having anything humorous in your signature is completely banned on this forum. Wear a tin-foil hat and you'll get a ban.

Any DMs sent on Twitter will be answered next month.

This is a doctor free zone.

User avatar
Richard-TX
Posts: 1549
Joined: Tue May 28, 2013 3:24 pm
Location: North Texas

Re: New device tree kernel is in testing

Fri Dec 12, 2014 3:18 pm

DougieLawson wrote:
PhilE wrote:@dougielawson: you're right - edited.
Thank you. The camera works now.

Next step is getting my SPI attached ethernet running.
Agreed!
Richard
Doing Unix since 1985.
The 9-25-2013 image of Wheezy can be found at:
http://downloads.raspberrypi.org/raspbian/images/raspbian-2013-09-27/2013-09-25-wheezy-raspbian.zip

User avatar
davidcoton
Posts: 4263
Joined: Mon Sep 01, 2014 2:37 pm
Location: Cambridge, UK

Re: New device tree kernel is in testing

Fri Dec 12, 2014 5:24 pm

milhouse wrote: (... it locked up this morning 13 Dec 09:55).
Does your time machine run on the Pi? Where can I get one? 24 hours notice of a lock-up is plenty to enable a pre-emptive reboot :D :shock: :o
Signature retired

milhouse
Posts: 641
Joined: Mon Jan 16, 2012 12:59 pm

Re: New device tree kernel is in testing

Fri Dec 12, 2014 5:27 pm

davidcoton wrote:
milhouse wrote: (... it locked up this morning 13 Dec 09:55).
Does your time machine run on the Pi? Where can I get one? 24 hours notice of a lock-up is plenty to enable a pre-emptive reboot :D :shock: :o
Doh... not sure what I was thinking of there... 12 Dec 09:55! Will correct original post :)

milhouse
Posts: 641
Joined: Mon Jan 16, 2012 12:59 pm

Re: New device tree kernel is in testing

Sat Dec 13, 2014 9:34 pm

Unfortunately I've just arrived home to find the Pi with "device_tree=" had locked up again - booted at 12 Dec 15:05. locked up at 13 Dec 17:58.

Code: Select all

[email protected] ~ $ uname -a
Linux raspberrypi 3.18.0+ #726 PREEMPT Mon Dec 8 16:01:09 GMT 2014 armv6l GNU/Linux
[email protected] ~ $ vcgencmd version
Dec  8 2014 16:03:47
Copyright (c) 2012 Broadcom
version a9edf64011873a20bd0e860ec5ee150fd56ffa20 (clean) (release)
I normally leave the Pi running bcmstat.sh - the last 3 entries prior to lockup show the Pi idle with plenty of free memory:

Code: Select all

Time          ARM     Core     H264  Core Temp (Max)   IRQ/s      RX B/s      TX B/s   %user   %nice %system   %idle %iowait    %irq  %s/irq  %total  Memory Free/Used(SwUse)
========  =======  =======  =======  ===============  ======  ==========  ==========  ======  ======  ======  ======  ======  ======  ======  ======  =======================
17:57:45  1000Mhz   500Mhz   250Mhz  54.07C (57.30C)     780         734       1,619    0.10    0.79    0.59   96.48    0.00    0.00    0.00    3.52  409,428 kB/31.4%( 0.0%)
17:57:55  1000Mhz   500Mhz   250Mhz  54.07C (57.30C)     779         247       1,568    0.00    0.89    0.89   96.77    0.00    0.00    0.00    3.23  409,428 kB/31.4%( 0.0%)
17:58:05   999Mhz   500Mhz   250Mhz  54.07C (57.30C)     778         582       1,492    0.20    0.99    0.89   96.06    0.00    0.00    0.00    3.94  409,428 kB/31.4%( 0.0%)
I'll stop running bcmstat on the freshly booted Pi in case the repeated calls to vcgencmd are somehow responsible for the lockup.

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5372
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: New device tree kernel is in testing

Sat Dec 13, 2014 9:38 pm

milhouse wrote: I'll stop running bcmstat on the freshly booted Pi in case the repeated calls to vcgencmd are somehow responsible for the lockup.
Just to be sure can you disable overclock and confirm it still fails.

milhouse
Posts: 641
Joined: Mon Jan 16, 2012 12:59 pm

Re: New device tree kernel is in testing

Sat Dec 13, 2014 10:30 pm

dom wrote: Just to be sure can you disable overclock and confirm it still fails.
OK, overclock is now disabled - config.txt is:

Code: Select all

gpu_mem=16

#arm_freq=1000
#core_freq=500
#sdram_freq=600
#over_voltage=3
#over_voltage_sdram=1

#current_limit_override=0x5A000020
#force_turbo=1

config_hdmi_boost=7
disable_overscan=1

decode_MPG2=0xe99b2a93,0x182c16a,0xddea19ea
decode_WVC1=0xfc7dcee8,0xdcb45030,0xc467f2a1

device_tree=
Will resume bcmstat, so the only change now is the removal of any overclock.

One strange thing I've noticed, probably specific to this 3.18 kernel (it was the same while overclocking) is that bcmstat doesn't detect any codecs when gpu_mem is below 32MB:

Code: Select all

[email protected] ~ $ /boot/bin/bcmstat.sh
  Config: v0.1.8, args "Cxcd10", priority lowest (+19)
Governor: ondemand
  Memory: 512MB (split 496MB ARM, 16MB GPU) plus 100MB Swap
HW Block: |   ARM   |  Core  |  H264  |   SDRAM   |
Min Freq: |  700Mhz | 250Mhz |   0Mhz |   400Mhz  |
Max Freq: |  700Mhz | 250Mhz | 250Mhz |   400Mhz  |
Voltages: |          0, 1.20V         |  0, 1.20V |
   Other: temp_limit=85
Firmware: Dec 8 2014 16:03:47, version a9edf64011873a20bd0e860ec5ee150fd56ffa20 (clean) (release)
  Codecs: none
  Booted: Sat Dec 13 22:31:13 2014
When gpu_mem is 31 or less, bcmstat will show "Codecs: none" when it should be "Codecs: H264 WVC1 MPG2 MJPG".

Codec status is determined from a call to vcgencmd, ie. "vcgencmd codec_enabled H264", which is returning "disabled" with 3.18/<32MB but "enabled" with 3.18/32MB+. Is this expected behaviour? Obviously it's no great loss being headless, but is a difference from earlier kernels.

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5372
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: New device tree kernel is in testing

Sat Dec 13, 2014 10:44 pm

milhouse wrote: When gpu_mem is 31 or less, bcmstat will show "Codecs: none" when it should be "Codecs: H264 WVC1 MPG2 MJPG".
That's deliberate. When gpu_mem < 32 we load start_cd.elf which has no codecs / 3d linked in, so decode is not available.

milhouse
Posts: 641
Joined: Mon Jan 16, 2012 12:59 pm

Re: New device tree kernel is in testing

Sat Dec 13, 2014 10:45 pm

dom wrote: That's deliberate. When gpu_mem < 32 we load start_cd.elf which has no codecs / 3d linked in, so decode is not available.
OK cheers.

acidjazz
Posts: 2
Joined: Wed Dec 17, 2014 12:42 am

Re: New device tree kernel is in testing

Wed Dec 17, 2014 12:47 am

A little irc bird told me that this new tree has better network drivers that allow monitor mode?? Potentially for 8192cu and/or rtl8192 ??

Can anyone confirm this?? :)

Image

User avatar
DougieLawson
Posts: 36578
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website Twitter

Re: New device tree kernel is in testing

Thu Dec 18, 2014 1:02 pm

DougieLawson wrote:Thank you. The camera works now.

Next step is getting my SPI attached ethernet running.
Having struggled to find any coherent docs on FDT/DTB/DTS I found just about enough to understand it. The docs for this stuff are very patchy.

I've now written my own DTS/DTB and got SPI, I2C and my SPI ENC28J60 working. :D :D :D

I'm not using an overlay (because I can't find any docs for how that piece works and how you relate it to the DTB it's overlaying) so I've decompiled the bcm2708-rpi-b*.dtb to dts and enabled everything in there (I've also disabled I2S). Getting the SPI ethernet on my A+ is working made me very happy yesterday afternoon (using my home built 3.18 kernel with lots of the modules I'll never need stripped out).

This morning I got my kernel and DTB running on one of my Bs.

Is there any code that will read /proc/device-tree on a running system and (re-)generate a DTB (or DTS) from it?
Found it: dtc -I fs -O dts /proc/device-tree -o dts generates dts from the running system.
Last edited by DougieLawson on Thu Dec 18, 2014 1:23 pm, edited 1 time in total.
Note: Having anything humorous in your signature is completely banned on this forum. Wear a tin-foil hat and you'll get a ban.

Any DMs sent on Twitter will be answered next month.

This is a doctor free zone.

milhouse
Posts: 641
Joined: Mon Jan 16, 2012 12:59 pm

Re: New device tree kernel is in testing

Thu Dec 18, 2014 1:14 pm

dom wrote: Just to be sure can you disable overclock and confirm it still fails.
With overclock disabled, it's now been up 4.5 days without any problem.

I'd be surprised if power is a problem, as this Pi has been 100% reliable with previous kernels, runs headless, and it's not doing much when it crashes which only started with Device Tree + 3.17.x/3.18.

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5372
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: New device tree kernel is in testing

Thu Dec 18, 2014 1:31 pm

milhouse wrote: With overclock disabled, it's now been up 4.5 days without any problem.

I'd be surprised if power is a problem, as this Pi has been 100% reliable with previous kernels, runs headless, and it's not doing much when it crashes which only started with Device Tree + 3.17.x/3.18.
Try 90% of the overclock. It does sound like your overclock may have been borderline and the newer kernel just tickles the core in the wrong way (e.g. has a code path that rapidly goes from very low power consumption to high power consumption).

I'm working on an overclocking utilty (that will find the maximum overclock automatically), which includes a pretty hard stress test, when that's ready it would be interesting to see if that passes with your overclock settings (with older and newer kernels).

milhouse
Posts: 641
Joined: Mon Jan 16, 2012 12:59 pm

Re: New device tree kernel is in testing

Thu Dec 18, 2014 2:25 pm

dom wrote: Try 90% of the overclock. It does sound like your overclock may have been borderline and the newer kernel just tickles the core in the wrong way (e.g. has a code path that rapidly goes from very low power consumption to high power consumption).
OK, will see how long it stays up when the arm_freq is 900 (reduced from 1000), and core_freq 450 (reduced from 500). I've left sdram_freq set to 600.

I'm using fairly low voltages (currently +3/+1), so could bump either or both those if it's simply marginal on voltage.
dom wrote: I'm working on an overclocking utilty (that will find the maximum overclock automatically), which includes a pretty hard stress test, when that's ready it would be interesting to see if that passes with your overclock settings (with older and newer kernels).
Sounds interesting, happy to give it a go!

vvn2023
Posts: 33
Joined: Fri Dec 19, 2014 6:42 am

Re: New device tree kernel is in testing

Fri Dec 19, 2014 10:07 am

I am not able to boot with the latest kernel source ie 3.18.0 with the device tree enabled.
I am getting blank screen.

I used the latest tools and firmware to boot.
downloaded the code from https://github.com/raspberrypi/linux/tree/rpi-3.18.y and compiled it.
downloaded the firmware from https://github.com/raspberrypi/firmware/tree/next
downloaded the tools from https://github.com/raspberrypi/tools

I followed the following steps to compile it.

Code: Select all

ARCH=arm make bcmrpi_defconfig
CCPREFIX=rpi-tools/arm-bcm2708/arm-bcm2708-linux-gnueabi/bin/arm-bcm2708-linux-gnueabi-
ARCH=arm CROSS_COMPILE=$CCPREFIX make -j4
ARCH=arm CROSS_COMPILE=$CCPREFIX INSTALL_MOD_PATH=modules make -j2 modules_install
/boot/config.txt content:

Code: Select all

device_tree=bcm2708-rpi-b-plus.dtb
device_tree_address=0x100
kernel_address=0x8000
disable_commandline_tags=2
Plese let me know if anything i am missing.
Please Suggest me something.

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5372
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: New device tree kernel is in testing

Fri Dec 19, 2014 11:13 am

vvn2023 wrote:I am not able to boot with the latest kernel source ie 3.18.0 with the device tree enabled.
I am getting blank screen.
Does the DT kernel installed with rpi-update work for you?
You want to run this on the kernel and should remove the config.txt entries (they will be added when DT is detected).

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2490
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: New device tree kernel is in testing

Fri Dec 19, 2014 8:50 pm

As promised, there is now a better way to enable the optional interfaces (i2c, i2s, spi) - device tree parameters. The latest BRANCH=next firmware release includes support for patching certain parts of the device tree at boot time, all controlled from config,txt. There will be a more comprehensive documentation release including how to create your own overlays (with parameters) soon - hopefully early next week - but in the meantime you advanced users will have to manage with this.

============

Introducing device tree parameters

It is now possible to modify certain parts of the base DTB and overlays using device tree parameters. The base DTBs support four parameters - i2c0, i2c1, i2s and spi - that allow you to enable those interfaces without using dedicated overlays. The syntax looks like this:

Code: Select all

device_tree_param=i2c1=on,spi=on
Supported values for these parameters are yes, y, on, true, okay, 1, no, n, off, false, disabled and 0.

You can abbreviate this to:

Code: Select all

dtparam=i2c1,spi
(the =on is assumed). Overlay loading can be shortened from:

Code: Select all

device_tree_overlay=overlays/acme-board-overlay.dtb
to:

Code: Select all

dtoverlay=acme-board
If your overlay defines some parameters, they can be specified either on the same line like this:

Code: Select all

dtoverlay=lirc-rpi,gpio_out_pin=16,gpio_in_pin=17,gpio_in_pull=down
or on a subsequent line like this:

Code: Select all

    dtoverlay=lirc-rpi
    dtparam=gpio_out_pin=16,gpio_in_pin=17,gpio_in_pull=down
or you can use a mixture of the two. Note that overlay parameters go out of scope when the next overlay is loaded, or after an explicit:

Code: Select all

dtoverlay=
In the event of a parameter with the same name being exported by both the overlay and the base (don't - it's just confusing), the overlay is searched first. To see the parameter exported by the base DTB instead, end the current overlay scope as above.

As before, you can disable the device tree support altogether using:

Code: Select all

device_tree=
Some errors (missing overlays, bad parameters) can be recovered from, but a serious error will cause the loader to revert the kernel to non-DT behaviour.

In the event of an error or other unexpected behaviour, it is worth checking the vcdbg messages for clues:

Code: Select all

sudo vcdbg log msg

User avatar
DougieLawson
Posts: 36578
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website Twitter

Re: New device tree kernel is in testing

Fri Dec 19, 2014 10:04 pm

Phil,

Are you able to generate copious numbers of messages in the kernel dmesg log so we can see what's going on and whether the DT has been interpreted OK?

Can we, possibly, have a config.txt parm to set a level of device tree debug logging (something like: 0 == none, 1 == files read and processed, 2 == devices instantiated and 3 == devices instantiated and which files supplied the definition for them).
Note: Having anything humorous in your signature is completely banned on this forum. Wear a tin-foil hat and you'll get a ban.

Any DMs sent on Twitter will be answered next month.

This is a doctor free zone.

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2490
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: New device tree kernel is in testing

Fri Dec 19, 2014 10:36 pm

Have you looked at the output from

Code: Select all

sudo vcdbg log msg
? While hardly copious, it should help to either reassure you or help to show what is going wrong.

Remember that all of the device tree processing happens before the ARM executes a single instruction, so dmesg output is not straightforward. Variable levels of vcdbg logging for device tree processing is considerably easier.

The instantiated devices are available by reading /proc/device-tree. The directories correspond to device nodes, while the files are the properties. For the non-textual properties you will need something like hexdump to make sense of them.

asavah
Posts: 365
Joined: Thu Aug 14, 2014 12:49 am

Re: New device tree kernel is in testing

Sat Dec 20, 2014 6:57 pm

Dear sirs:
Accept my eternal gratitude for your excellent work on raspberry pi.
Special thanks go to popcornmix, sorry I don't know your nick here :oops:

Been running my pi B+ with 3.17.y and 3.18.y with dt enabled for a few weeks, everything works just fine.
The only problem I've had - some stability issues due to an aggressive overclock, lowered it a bit and everything been stable so far.

My config.txt for the latest 3.18.1 kernel (built it just a hour ago) + firmware-next:

Code: Select all

start_file=start_x.elf
fixup_file=fixup_x.elf
kernel=kernel.img
framebuffer_depth=32
framebuffer_ignore_alpha=1
disable_overscan=1
disable_splash=1
gpu_mem=192
gpu_mem_512=192
force_turbo=1
arm_freq=1100
core_freq=550
sdram_freq=700
over_voltage=8
over_voltage_sdram=6
avoid_pwm_pll=1
dtoverlay=lirc-rpi
dtparam=i2c0,i2c1,spi
decode_MPG2=0x
decode_WVC1=0x
The "OS" is a custom mix of LFS, debian and my own experiments , fully crosscompiled with latest gcc-linaro-4.9-2014.12 + glibc-2.20 + crosstool-ng, NFS root.

Main use - KODI media center, I'm using popcornmix/newclock4 branch, huge thanks to popcornmix again.
It runs very smooth with the latest kernels, maybe it's a placebo effect, but IMO the UI is more responsive than with 3.12.y.

milhouse
Posts: 641
Joined: Mon Jan 16, 2012 12:59 pm

Re: New device tree kernel is in testing

Mon Dec 22, 2014 9:39 am

After no problems for a long time with 3.12.y, I'm seeing some issues with 3.18/3.18.1 while using Transmission and downloading a torrent (ie. heavy CPU/network load):

Code: Select all

Dec 22 09:02:22 raspberrypi kernel: [82922.270441] ------------[ cut here ]------------
Dec 22 09:02:22 raspberrypi kernel: [82922.270488] WARNING: CPU: 0 PID: 2183 at net/core/skbuff.c:3995 skb_try_coalesce+0x330/0x3c0()
Dec 22 09:02:22 raspberrypi kernel: [82922.270498] Modules linked in: rpcsec_gss_krb5 snd_bcm2835 snd_pcm snd_seq snd_seq_device snd_timer snd sg evdev uio_pdrv_genirq uio
Dec 22 09:02:22 raspberrypi kernel: [82922.270548] CPU: 0 PID: 2183 Comm: transmission-da Not tainted 3.18.1+ #731
Dec 22 09:02:22 raspberrypi kernel: [82922.270592] [<c001519c>] (unwind_backtrace) from [<c00126c0>] (show_stack+0x20/0x24)
Dec 22 09:02:22 raspberrypi kernel: [82922.270617] [<c00126c0>] (show_stack) from [<c0554028>] (dump_stack+0x20/0x28)
Dec 22 09:02:22 raspberrypi kernel: [82922.270645] [<c0554028>] (dump_stack) from [<c0022e08>] (warn_slowpath_common+0x7c/0x9c)
Dec 22 09:02:22 raspberrypi kernel: [82922.270666] [<c0022e08>] (warn_slowpath_common) from [<c0022ee4>] (warn_slowpath_null+0x2c/0x34)
Dec 22 09:02:22 raspberrypi kernel: [82922.270685] [<c0022ee4>] (warn_slowpath_null) from [<c04705f4>] (skb_try_coalesce+0x330/0x3c0)
Dec 22 09:02:22 raspberrypi kernel: [82922.270708] [<c04705f4>] (skb_try_coalesce) from [<c04c9348>] (tcp_try_coalesce+0x5c/0xd8)
Dec 22 09:02:22 raspberrypi kernel: [82922.270728] [<c04c9348>] (tcp_try_coalesce) from [<c04c9e64>] (tcp_data_queue+0x3a0/0xc58)
Dec 22 09:02:22 raspberrypi kernel: [82922.270749] [<c04c9e64>] (tcp_data_queue) from [<c04cc7f8>] (tcp_rcv_established+0x138/0x5f4)
Dec 22 09:02:22 raspberrypi kernel: [82922.270829] [<c04cc7f8>] (tcp_rcv_established) from [<c04d4e70>] (tcp_v4_do_rcv+0x114/0x298)
Dec 22 09:02:22 raspberrypi kernel: [82922.270852] [<c04d4e70>] (tcp_v4_do_rcv) from [<c04d7734>] (tcp_v4_rcv+0x87c/0x890)
Dec 22 09:02:22 raspberrypi kernel: [82922.270879] [<c04d7734>] (tcp_v4_rcv) from [<c04b31f0>] (ip_local_deliver_finish+0xdc/0x250)
Dec 22 09:02:22 raspberrypi kernel: [82922.270902] [<c04b31f0>] (ip_local_deliver_finish) from [<c04b3830>] (ip_local_deliver+0x48/0xa8)
Dec 22 09:02:22 raspberrypi kernel: [82922.270921] [<c04b3830>] (ip_local_deliver) from [<c04b349c>] (ip_rcv_finish+0x138/0x358)
Dec 22 09:02:22 raspberrypi kernel: [82922.270939] [<c04b349c>] (ip_rcv_finish) from [<c04b3ad8>] (ip_rcv+0x248/0x38c)
Dec 22 09:02:22 raspberrypi kernel: [82922.270968] [<c04b3ad8>] (ip_rcv) from [<c047c84c>] (__netif_receive_skb_core+0x628/0x850)
Dec 22 09:02:22 raspberrypi kernel: [82922.270989] [<c047c84c>] (__netif_receive_skb_core) from [<c047ca94>] (__netif_receive_skb+0x20/0x70)
Dec 22 09:02:22 raspberrypi kernel: [82922.271010] [<c047ca94>] (__netif_receive_skb) from [<c047d800>] (process_backlog+0x7c/0x11c)
Dec 22 09:02:22 raspberrypi kernel: [82922.271031] [<c047d800>] (process_backlog) from [<c047cf34>] (net_rx_action+0x144/0x2a4)
Dec 22 09:02:22 raspberrypi kernel: [82922.271056] [<c047cf34>] (net_rx_action) from [<c0026508>] (__do_softirq+0x118/0x36c)
Dec 22 09:02:22 raspberrypi kernel: [82922.271077] [<c0026508>] (__do_softirq) from [<c0026ac0>] (irq_exit+0xbc/0x110)
Dec 22 09:02:22 raspberrypi kernel: [82922.271102] [<c0026ac0>] (irq_exit) from [<c005eeb8>] (__handle_domain_irq+0x88/0xd4)
Dec 22 09:02:22 raspberrypi kernel: [82922.271123] [<c005eeb8>] (__handle_domain_irq) from [<c000853c>] (asm_do_IRQ+0x2c/0x30)
Dec 22 09:02:22 raspberrypi kernel: [82922.271150] [<c000853c>] (asm_do_IRQ) from [<c0559728>] (__irq_usr+0x48/0xc0)
Dec 22 09:02:22 raspberrypi kernel: [82922.271161] Exception stack(0xdd3cffb0 to 0xdd3cfff8)
Dec 22 09:02:22 raspberrypi kernel: [82922.271175] ffa0:                                     b83c7470 b84bbb1c 80000000 00000000
Dec 22 09:02:22 raspberrypi kernel: [82922.271192] ffc0: 00000000 b84bbaf0 0000000d 0000000f b83e76c8 5497de1e b6fd6da0 80800400
Dec 22 09:02:22 raspberrypi kernel: [82922.271207] ffe0: b6fe3efc b67b6c28 b6fb0970 b6fb099c 60000010 ffffffff
Dec 22 09:02:22 raspberrypi kernel: [82922.271218] ---[ end trace 17707c459182373e ]---

Code: Select all

[email protected] ~/.sickbeard/logs $ uname -a
Linux raspberrypi 3.18.1+ #731 PREEMPT Fri Dec 19 19:16:36 GMT 2014 armv6l GNU/Linux
My /etc/sysctl.conf consists of the following:

Code: Select all

kernel.printk = 3 4 1 3
vm.swappiness=1
vm.min_free_kbytes=10240
Any ideas on what might be best to tune, or if this is a kernel bug of some sort?
Last edited by milhouse on Mon Dec 22, 2014 11:34 am, edited 1 time in total.

vvn2023
Posts: 33
Joined: Fri Dec 19, 2014 6:42 am

Re: New device tree kernel is in testing

Mon Dec 22, 2014 11:31 am

How can i write my own overlay for my audio card.

Recently i am successfully completed compiling with device tree and now i want to write the overlay file for the wolfsonmy audio card

And i have one doubt how the overlay file can load the my audio card specific modules?

And how the automatic detection of the overlay file can be done without writing the device_tree_ovelay in config.txt

Is there any document now on how to write overlay file?
Last edited by vvn2023 on Wed Dec 24, 2014 6:20 am, edited 1 time in total.

asavah
Posts: 365
Joined: Thu Aug 14, 2014 12:49 am

Re: New device tree kernel is in testing

Mon Dec 22, 2014 12:37 pm

I've had similar issue as milhouse but with latest kodi

Code: Select all

Dec 21 15:44:37 rpi kernel: [55241.787962] WARNING: CPU: 0 PID: 1528 at net/core/skbuff.c:3995 skb_try_coalesce+0x33c/0x3b8()
Dec 21 15:44:37 rpi kernel: [55241.795515] Modules linked in: bcm2708_wdog ipv6 i2c_dev bcm2708_rng i2c_bcm2708 spi_bcm2708 lirc_rpi(C) lirc_dev uio_pdrv_genirq rc_core uio
Dec 21 15:44:37 rpi kernel: [55241.803303] CPU: 0 PID: 1528 Comm: kodi.bin Tainted: G         C     3.18.1+ #2
Dec 21 15:44:37 rpi kernel: [55241.810401] [<c0015418>] (unwind_backtrace) from [<c0012904>] (show_stack+0x20/0x24)
Dec 21 15:44:37 rpi kernel: [55241.816664] [<c0012904>] (show_stack) from [<c0554678>] (dump_stack+0x20/0x28)
Dec 21 15:44:37 rpi kernel: [55241.822890] [<c0554678>] (dump_stack) from [<c0022fdc>] (warn_slowpath_common+0x78/0x98)
Dec 21 15:44:37 rpi kernel: [55241.829019] [<c0022fdc>] (warn_slowpath_common) from [<c00230b8>] (warn_slowpath_null+0x2c/0x34)
Dec 21 15:44:37 rpi kernel: [55241.835259] [<c00230b8>] (warn_slowpath_null) from [<c04727f8>] (skb_try_coalesce+0x33c/0x3b8)
Dec 21 15:44:37 rpi kernel: [55241.841405] [<c04727f8>] (skb_try_coalesce) from [<c04cbefc>] (tcp_try_coalesce+0x5c/0xd4)
Dec 21 15:44:37 rpi kernel: [55241.847570] [<c04cbefc>] (tcp_try_coalesce) from [<c04cd308>] (tcp_data_queue+0x3ac/0xc70)
Dec 21 15:44:37 rpi kernel: [55241.853808] [<c04cd308>] (tcp_data_queue) from [<c04cf40c>] (tcp_rcv_established+0x138/0x5f0)
Dec 21 15:44:37 rpi kernel: [55241.860024] [<c04cf40c>] (tcp_rcv_established) from [<c04d7a68>] (tcp_v4_do_rcv+0x118/0x2a4)
Dec 21 15:44:37 rpi kernel: [55241.866187] [<c04d7a68>] (tcp_v4_do_rcv) from [<c04da360>] (tcp_v4_rcv+0x8b4/0x8c8)
Dec 21 15:44:37 rpi kernel: [55241.872525] [<c04da360>] (tcp_v4_rcv) from [<c04b5bf4>] (ip_local_deliver_finish+0xdc/0x250)
Dec 21 15:44:37 rpi kernel: [55241.878788] [<c04b5bf4>] (ip_local_deliver_finish) from [<c04b6254>] (ip_local_deliver+0x48/0xa4)
Dec 21 15:44:37 rpi kernel: [55241.885123] [<c04b6254>] (ip_local_deliver) from [<c04b5eac>] (ip_rcv_finish+0x144/0x374)
Dec 21 15:44:37 rpi kernel: [55241.891431] [<c04b5eac>] (ip_rcv_finish) from [<c04b6558>] (ip_rcv+0x2a8/0x380)
Dec 21 15:44:37 rpi kernel: [55241.897689] [<c04b6558>] (ip_rcv) from [<c047c8f0>] (__netif_receive_skb_core+0x624/0x89c)
Dec 21 15:44:37 rpi kernel: [55241.904056] [<c047c8f0>] (__netif_receive_skb_core) from [<c047eedc>] (__netif_receive_skb+0x20/0x70)
Dec 21 15:44:37 rpi kernel: [55241.910499] [<c047eedc>] (__netif_receive_skb) from [<c047fc70>] (process_backlog+0x88/0x120)
Dec 21 15:44:37 rpi kernel: [55241.916952] [<c047fc70>] (process_backlog) from [<c047f384>] (net_rx_action+0x154/0x2c8)
Dec 21 15:44:37 rpi kernel: [55241.923509] [<c047f384>] (net_rx_action) from [<c0026738>] (__do_softirq+0x130/0x364)
Dec 21 15:44:37 rpi kernel: [55241.930015] [<c0026738>] (__do_softirq) from [<c0026cc4>] (irq_exit+0xbc/0x110)
Dec 21 15:44:37 rpi kernel: [55241.936657] [<c0026cc4>] (irq_exit) from [<c005f4ac>] (__handle_domain_irq+0x88/0xd8)
Dec 21 15:44:37 rpi kernel: [55241.943345] [<c005f4ac>] (__handle_domain_irq) from [<c0008528>] (asm_do_IRQ+0x28/0x2c)
Dec 21 15:44:37 rpi kernel: [55241.950003] [<c0008528>] (asm_do_IRQ) from [<c0559ae8>] (__irq_usr+0x48/0xc0)
Dec 21 15:44:37 rpi kernel: [55241.956724] Exception stack(0xd3311fb0 to 0xd3311ff8)
Dec 21 15:44:37 rpi kernel: [55241.963393] 1fa0:                                     01c56048 befd2558 befd2558 befd258c
Dec 21 15:44:37 rpi kernel: [55241.970190] 1fc0: befd2558 befd25e0 03f6f468 01c56008 befd258c befd2668 04f9b3d0 befd2aac
Dec 21 15:44:37 rpi kernel: [55241.977084] 1fe0: 01c56048 befd2548 0045d540 0045d58c 20000010 ffffffff
Dec 21 15:44:37 rpi kernel: [55241.984042] ---[ end trace 1f00dbbbdd8f64fc ]---
EDIT: PS from what I could see on the mailing it's a driver issue, no idea how to fix for rpi tho.
Last edited by asavah on Mon Dec 22, 2014 12:47 pm, edited 1 time in total.

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2490
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: New device tree kernel is in testing

Mon Dec 22, 2014 12:46 pm

@vvn2023, I suggest you start by reading the source to the existing overlays - you will find them all in arch/arm/boot/dts, named "*-overlay.dts". Also look at the minor changes to the drivers that happened at the same time - commit cee7c800c812cab928de37e82b229644f7f16b05 on branch rpi-3.18.y is what you need.

The "compatible" strings in the DTS files identify the modules to be loaded - just make sure that your modules include .of_match_table and MODULE_DEVICE_TABLE(of, ...).

The only way to get an overlay automatically (i.e. without adding something to config.txt) loaded is to make your card a proper HAT, and to programme your overlay into the EEPROM.

We are just about to release some documentation about the whole area of device tree usage and overlays. Until then, follow the steps above, and feel free to ask any specific questions you have - device tree is new to many people and slightly bewildering at first, but after a while it starts to make sense.

Return to “Advanced users”