Hi, me again…
Am 13.01.2015 um 16:51 schrieb Dr. H. Nikolaus Schaller hns@goldelico.com:
Am 13.01.2015 um 14:46 schrieb Grazvydas Ignotas notasas@gmail.com:
On Tue, Jan 13, 2015 at 11:32 AM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
Hi,
Am 12.01.2015 um 18:42 schrieb aTc atc@k-n-p.org:
The kernel compiling also fails when the patched xorg is running.
I did the following:
- boot EVM from my 8GB SD card
- with BOE panel attached and installed
- showing LXDE desktop
Here the commands (edited from bash history):
155 apt-get install git 156 git clone http://git.goldelico.com/gta04-kernel.git 159 cd gta04-kernel/ 162 git checkout 3.19-rc4 163 gcc -v Using built-in specs. ...
166 apt-get install bc 169 time make gta04_defconfig uImage LOADADDR=0x80008000 dtbs modules
...
So it works and is stable (on Wheezy 7.7). I just had to install ‘bc’.
You need to use "make -j3 ..." for make to keep running 3 jobs (1 for each ARM core and one to take a free core that's waiting for SD card when it's reading new source files). Then problems tend to show up, some time ago I've tried doing this on internal eMMC and it corrupted the filesystem (this might be unrelated eMMC driver problem and was on TI kernel I think, so probably unrelated to currently discussed issues).
Still no segfault :(
root@gta04:~/gta04-kernel# make clean CLEAN . CLEAN arch/arm/kernel CLEAN drivers/tty/vt CLEAN drivers/video/logo CLEAN firmware CLEAN kernel/time CLEAN kernel CLEAN lib CLEAN usr CLEAN arch/arm/boot/compressed CLEAN arch/arm/boot/dts CLEAN arch/arm/boot CLEAN .tmp_versions root@gta04:~/gta04-kernel# time make -j3 gta04_defconfig uImage LOADADDR=0x80008000 dtbs modules HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/bin2c HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf # # configuration written to .config # scripts/kconfig/conf --silentoldconfig Kconfig CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h HOSTCC scripts/dtc/dtc.o
…. (the order of compile steps is scrambled compared to make w/o -j3) …
LD [M] sound/soc/omap/snd-soc-omap-mcbsp.ko LD [M] sound/soc/omap/snd-soc-omap-mcpdm.ko HOSTCC firmware/ihex2fw IHEX2FW firmware/emi26/loader.fw IHEX2FW firmware/emi26/firmware.fw IHEX2FW firmware/emi26/bitstream.fw IHEX2FW firmware/emi62/loader.fw IHEX2FW firmware/emi62/bitstream.fw IHEX2FW firmware/emi62/spdif.fw IHEX2FW firmware/emi62/midi.fw
real 56m11.666s user 49m47.790s sys 6m5.240s root@gta04:~/gta04-kernel# ls -l arch/arm/boot/ total 17312 drwxr-xr-x 2 root root 4096 Jan 12 21:18 bootp drwxr-xr-x 2 root root 4096 Jan 13 14:31 compressed drwxr-xr-x 3 root root 69632 Jan 13 14:31 dts -rwxr-xr-x 1 root root 9062600 Jan 13 14:30 Image -rw-r--r-- 1 root root 1648 Jan 12 20:09 install.sh -rw-r--r-- 1 root root 3148 Jan 12 20:09 Makefile -rw-r--r-- 1 root root 4265456 Jan 13 14:31 uImage -rwxr-xr-x 1 root root 4265392 Jan 13 14:31 zImage
Only one thing was interesting. While the make was running, I tried cpufreq-info through a second ssh session:
root@gta04:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 338 us. hardware limits: 1000 MHz - 1.50 GHz available frequency steps: 1000 MHz, 1.50 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance current policy: frequency should be within 1000 MHz and 1.50 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1000 MHz (asserted by call to hardware). cpufreq stats: 1000 MHz:82.99%, 1.50 GHz:17.01% (3376) analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 338 us. hardware limits: 1000 MHz - 1.50 GHz available frequency steps: 1000 MHz, 1.50 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance current policy: frequency should be within 1000 MHz and 1.50 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1000 MHz (asserted by call to hardware). cpufreq stats: 1000 MHz:82.99%, 1.50 GHz:17.01% (3376) root@gta04:~#
This shows that running the make isn’t driving the cores to max. speed. Most times they are at 1GZh- And I measured the temperature to be 45C which isn’t really hot.
Could it be that my SD card is slower than a SATA disk and the problem only appears if the CPUs are both permantently running at 1.5 GHz?
I could try connecting my only disk with eSATA connector… But it had some spindle startup problems so I don’t know if it really works well or introduces its own problem.
Yes, it did take 5 minutes with some clicking noises and flicker on the power supply LED but then it got to speed and did mount.
Here the result:
LD [M] sound/soc/omap/snd-soc-gta04-fm.ko LD [M] sound/soc/omap/snd-soc-gta04-headset.ko LD [M] sound/soc/omap/snd-soc-gta04-jack.ko LD [M] sound/soc/omap/snd-soc-gta04-voice.ko LD [M] sound/soc/omap/snd-soc-omap-abe-twl6040.ko LD [M] sound/soc/omap/snd-soc-omap-dmic.ko LD [M] sound/soc/omap/snd-soc-omap-mcbsp.ko LD [M] sound/soc/omap/snd-soc-omap-mcpdm.ko HOSTCC firmware/ihex2fw IHEX2FW firmware/emi26/loader.fw IHEX2FW firmware/emi26/firmware.fw IHEX2FW firmware/emi26/bitstream.fw IHEX2FW firmware/emi62/loader.fw IHEX2FW firmware/emi62/bitstream.fw IHEX2FW firmware/emi62/spdif.fw IHEX2FW firmware/emi62/midi.fw
real 29m51.179s user 49m0.820s sys 5m10.640s root@gta04:/media/usb0/gta04-kernel#
As you can see it is almost using 200%.
And:
root@gta04:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 338 us. hardware limits: 1000 MHz - 1.50 GHz available frequency steps: 1000 MHz, 1.50 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance current policy: frequency should be within 1000 MHz and 1.50 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1000 MHz (asserted by call to hardware). cpufreq stats: 1000 MHz:26.41%, 1.50 GHz:73.59% (152) analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 338 us. hardware limits: 1000 MHz - 1.50 GHz available frequency steps: 1000 MHz, 1.50 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance current policy: frequency should be within 1000 MHz and 1.50 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1000 MHz (asserted by call to hardware). cpufreq stats: 1000 MHz:26.41%, 1.50 GHz:73.59% (152) root@gta04:~#
So much higher CPU utilization of both cores. And temperature did rise to ~55C (measured externally with infrared thermometer).
But still no segfault.
So I can only conclude that the gta04-kernel works stable - at least for me and my EVM setup and I have really no idea why it fails for you.
You may now understand why grumbling about gta04-kernel being very unstable didn’t find immediate positive reactions :)
What you could try is to boot with a copy of my kernel binary (pulled from the EVM using scp):
http://download.goldelico.com/gta04-kernel/unstable/pyra/Archiv.zip
What I don’t know exactly is if it boots without LCD panel.
BR, Nikolaus