|
From: Daniel S. <dan...@ma...> - 2007-02-22 15:42:49
|
Hi, =20 I was cross compiling valgrind 3.2.3 for my MPC5200B target board and compiling also natively on it. Both times same result: complete lockup of the system without any output. I am using the DENX ELDK 3.1.1 (gcc 3.3.3) with glibc 2.3 for compilation and a Linux 2.4.25 based Denx Linux Kernel which is Xenomai enabled. Syslog did not show up anything useful. I used the following command: valgrind -v ls =20 valgrind --help prints out the help as expected. Any ideas ? =20 Best regards, =20 Daniel Schnell. |
|
From: Bart V. A. <bar...@gm...> - 2007-02-22 15:49:56
|
Hello Daniel, Which kernel distribution and version are you using ? Bart. On 2/22/07, Daniel Schnell <dan...@ma...> wrote: > Hi, > > I was cross compiling valgrind 3.2.3 for my MPC5200B target board and > compiling also natively on it. Both times same result: complete lockup > of the system without any output. I am using the DENX ELDK 3.1.1 (gcc > 3.3.3) with glibc 2.3 for compilation and a Linux 2.4.25 based Denx > Linux Kernel which is Xenomai enabled. > Syslog did not show up anything useful. > > I used the following command: > > valgrind -v ls > > > valgrind --help prints out the help as expected. > > > Any ideas ? > > Best regards, > > Daniel Schnell. |
|
From: Daniel S. <dan...@ma...> - 2007-02-22 15:58:15
|
Bart Van Assche wrote: > Hello Daniel, >=20 > Which kernel distribution and version are you using ? >=20 > Bart. >=20 This is a 2.4.25 Kernel which is maintained by the company Denx. Denx makes the free ELDK toolchain which is widely used for embedded systems. The Kernel I am using is a very recent version of this: http://www.denx.de/cgi-bin/gitweb.cgi?p=3Dlinuxppc_2_4_devel.git;a=3Dsumm= ary . As I wrote, I am using the ELDK 3.1.1 toolchain, because the MPC5200B has not yet a good Linux Kernel 2.6. support. Best regards, Daniel Schnell. |
|
From: Bart V. A. <bar...@gm...> - 2007-02-22 16:10:44
|
On 2/22/07, Daniel Schnell <dan...@ma...> wrote: > > Bart Van Assche wrote: > > Which kernel distribution and version are you using ? > > This is a 2.4.25 Kernel which is maintained by the company Denx. Denx > makes the free ELDK toolchain which is widely used for embedded systems. > The Kernel I am using is a very recent version of this: > http://www.denx.de/cgi-bin/gitweb.cgi?p=linuxppc_2_4_devel.git;a=summary > . > > As I wrote, I am using the ELDK 3.1.1 toolchain, because the MPC5200B > has not yet a good Linux Kernel 2.6. support. Hello Daniel, Maybe you should complain to Denx. Valgrind runs entirely in user-space. In my opinion if a user-space program can cause the system to hang, it's a kernel bug. If the MPC5200B has a serial console, and if an oops message is printed, you can analyze this message with the ksymoops program. Bart. |
|
From: Daniel S. <dan...@ma...> - 2007-02-22 16:17:16
|
Bart Van Assche wrote: > Hello Daniel, >=20 > Maybe you should complain to Denx. Valgrind runs entirely in > user-space. In my opinion if a user-space program can cause the > system to hang, it's a kernel bug. If the MPC5200B has a serial > console, and if an oops message is printed, you can analyze this > message with the ksymoops program. =20 >=20 > Bart. Sounds reasonable. Just wanted to make sure there is no known issue with ppc and valgrind. Is valgrind maybe using any POSIX thread related calls or e.g. clock_gettime() for its functionality ? If yes there might be some conflict with the Xenomai realtime extension. I try to compile the Kernel without the Xenomai extensions built in and try again. Best regards, Daniel Schnell. |
|
From: Julian S. <js...@ac...> - 2007-02-22 18:13:20
|
> Sounds reasonable. Just wanted to make sure there is no known issue with
> ppc and valgrind.
No ppc specific issues as far as I know; it works fine on the various
ppc test machines I use.
There have been occasional system-hang problems in the past due to memcheck's
leak checker prodding hardware mapped into user space, but those were
resolved early in the 3.2.X line I believe. Also they were not ppc specific.
It would be useful to know a bit more about where it hangs. What are the
last few lines of output you get when running
valgrind --tool=none -d -d -v -v --trace-flags=10000000 \
--trace-syscalls=yes --trace-signals=yes ls
?
J
|
|
From: Daniel S. <dan...@ma...> - 2007-02-23 13:16:26
|
Julian Seward wrote: >=20 > It would be useful to know a bit more about where it hangs. What are > the last few lines of output you get when running=20 >=20 > valgrind --tool=3Dnone -d -d -v -v --trace-flags=3D10000000 \ > --trace-syscalls=3Dyes --trace-signals=3Dyes ls >=20 Last lines are: --379:1:debuglog DebugLog system started by Stage 1, level 2 logging requested --379:1:launcher tool 'none' requested --379:1:launcher selected platform 'ppc32-linux' --379:1:launcher launching /usr/local/lib/valgrind/ppc32-linux/none --379:1:debuglog DebugLog system started by Stage 2 (main), level 2 logging requested --379:1:main Welcome to Valgrind version 3.2.3 d Probably not really helpful .... Ciao, Daniel Schnell. |
|
From: Julian S. <js...@ac...> - 2007-02-23 13:47:49
|
> --379:1:debuglog DebugLog system started by Stage 1, level 2 logging > requested > --379:1:launcher tool 'none' requested > --379:1:launcher selected platform 'ppc32-linux' > --379:1:launcher launching /usr/local/lib/valgrind/ppc32-linux/none > --379:1:debuglog DebugLog system started by Stage 2 (main), level 2 > logging requested > --379:1:main Welcome to Valgrind version 3.2.3 d > > Probably not really helpful .... Indeed. It shows that the hang happens very early during the startup process, but I don't think I can deduce anything from that. J |
|
From: Daniel S. <dan...@ma...> - 2007-02-26 11:12:17
|
Julian Seward wrote: >=20 > Indeed. It shows that the hang happens very early during the startup > process, but I don't think I can deduce anything from that.=20 >=20 > J Hi, Our Kernel got a new update from Denx and valgrind now works on our target as expected. The fix had something to do with the PCI mappings, which were overlapping with CONFIG_TASKSIZE. Something really basic down under. Many thanks for the provided help. Best regards, Daniel Schnell. |
|
From: Daniel S. <dan...@ma...> - 2007-02-23 15:03:57
|
Julian Seward wrote:
>> Probably not really helpful ....
>=20
> Indeed. It shows that the hang happens very early during the startup
> process, but I don't think I can deduce anything from that.=20
>=20
Ha, I got something when experimenting with different kind of command
options. I was using CTRL-C to try to stop the hanging program and after
some while this happened:
bash-2.05b# valgrind -d -d -v -v ls
--371:1:debuglog DebugLog system started by Stage 1, level 2 logging
requested
--371:1:launcher no tool requested, defaulting to 'memcheck'
--371:1:launcher selected platform 'ppc32-linux'
--371:1:launcher launching /usr/local/lib/valgrind/ppc32-linux/memcheck
--371:1:debuglog DebugLog system started by Stage 2 (main), level 2
logging requested
--371:1:main Welcome to Valgrind version 3.2.3 debug logging
--371:1:main Checking current stack is plausible
--371:1:main Checking initial stack was noted
--371:1:main Starting the address space manager
--371:2:aspacem sp_at_startup =3D 0x007FFFF8B0 (supplied)
--371:2:aspacem minAddr =3D 0x0004000000 (computed)
--371:2:aspacem maxAddr =3D 0x007FFFEFFF (computed)
--371:2:aspacem cStart =3D 0x0004000000 (computed)
--371:2:aspacem vStart =3D 0x0042000000 (computed)
--371:2:aspacem suggested_clstack_top =3D 0x007EFFFFFF (computed)
--371:2:aspacem <<< SHOW_SEGMENTS: Initial layout (5 segments, 0
segnames)
--371:2:aspacem 0: RSVN 0000000000-0003FFFFFF 64m ----- SmFixed
--371:2:aspacem 1: 0004000000-0041FFFFFF 992m
--371:2:aspacem 2: RSVN 0042000000-0042000FFF 4096 ----- SmFixed
--371:2:aspacem 3: 0042001000-007FFFEFFF 991m
--371:2:aspacem 4: RSVN 007FFFF000-00FFFFFFFF 2048m ----- SmFixed
--371:2:aspacem >>>
--371:2:aspacem Reading /proc/
Machine check in kernel mode.
Caused by (from SRR1=3D49030): Transfer error ack signal
Oops: machine check, sig: 7
NIP: C000F9A0 XER: 00000000 LR: C0028708 SP: CDD95E60 REGS: cdd95db0
TRAP: 0200 Not tainted
MSR: 00049030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK =3D cdd94000[371] 'memcheck' Last syscall: 3
last math cdd94000 last altivec 00000000
GPR00: 00000004 CDD95E60 CDD94000 42001070 CEC4B000 00000024 42001070
00000000
GPR08: 00000000 7F454C46 C0557D04 C01B5068 00015E5C 00000000 00000000
00000000
GPR16: 38B60C50 C01E0000 C002868C 00000001 CE9D3E00 00000001 CDD95EE0
00001000
GPR24: CF15CA20 00000000 CE9D3DE0 00000000 00000000 00000034 CDD95EE0
00000034
Call backtrace:
00000000 C0028080 C00287FC C00389A8 C0005A7C 42001070 3801C1C8
38035C30 38036100 38036ADC 38036E40 38020818 3802384C 38024A98
380249B0
self/maps
--371:2:aspacem <<< SHOW_SEGMENTS: With contents of /proc/self/maps
(11 segments, 1 segnames)
--371:2:aspacem ( 0) /usr/local/lib/valgrind/ppc32-linux/memcheck
--371:2:aspacem 0: RSVN 0000000000-0003FFFFFF 64m ----- SmFixed
--371:2:aspacem 1Bus error
Ksymoops afterwards tells me:
ksymoops 2.4.9 on ppc 2.4.25. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.25/ (default)
-m mach4/linuxppc_2_4_devel-git-configured/System.map (specified)
No modules in ksyms, skipping objects
Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid
lsmod file?
Warning (compare_maps): mismatch on symbol xchg_u32 , ksyms_base says
c000cea4, System.map says c0007f24. Ignoring ksyms_base entry
Machine check in kernel mode.
Oops: machine check, sig: 7
NIP: C000F9A0 XER: 00000000 LR: C0028708 SP: CDD95E60 REGS: cdd95db0
TRAP: 0200 Not tainted
Using defaults from ksymoops -t elf32-powerpc -a powerpc:common
MSR: 00049030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK =3D cdd94000[371] 'memcheck' Last syscall: 3
last math cdd94000 last altivec 00000000
GPR00: 00000004 CDD95E60 CDD94000 42001070 CEC4B000 00000024 42001070
00000000
GPR08: 00000000 7F454C46 C0557D04 C01B5068 00015E5C 00000000 00000000
00000000
GPR16: 38B60C50 C01E0000 C002868C 00000001 CE9D3E00 00000001 CDD95EE0
00001000
GPR24: CF15CA20 00000000 CE9D3DE0 00000000 00000000 00000034 CDD95EE0
00000034
Call backtrace:
00000000 C0028080 C00287FC C00389A8 C0005A7C 42001070 3801C1C8
38035C30 38036100 38036ADC 38036E40 38020818 3802384C 38024A98
380249B0
Warning (Oops_read): Code line not seen, dumping what data is available
>>NIP; c000f9a0 <__copy_tofrom_user+54/210> <=3D=3D=3D=3D=3D
>>GPR11; c01b5068 <contig_page_data+0/3ac>
>>GPR17; c01e0000 <log_buf+8c/4000>
>>GPR18; c002868c <file_read_actor+0/c8>
Trace; 00000000 Before first symbol
Trace; c0028080 <do_generic_file_read+1dc/524>
Trace; c00287fc <generic_file_read+a8/1f4>
Trace; c00389a8 <sys_read+b4/148>
Trace; c0005a7c <ret_from_syscall_1+0/b4>
Trace; 42001070 Before first symbol
Trace; 3801c1c8 Before first symbol
Trace; 38035c30 Before first symbol
Trace; 38036100 Before first symbol
Trace; 38036adc Before first symbol
Trace; 38036e40 Before first symbol
Trace; 38020818 Before first symbol
Trace; 3802384c Before first symbol
Trace; 38024a98 Before first symbol
Trace; 380249b0 Before first symbol
3 warnings issued. Results may not be reliable.
Any ideas ?
Ciao,
Daniel.
|
|
From: Igmar P. <mai...@jd...> - 2007-02-23 15:36:50
|
> Machine check in kernel mode. This means your kernel paniced. Valgrind triggers it, but isn't the cause. > 3 warnings issued. Results may not be reliable. > > > Any ideas ? Any reason you're using this version ? I suggest a more recent kernel version. Igmar |
|
From: Daniel S. <dan...@ma...> - 2007-02-23 15:44:12
|
Igmar Palsenberg wrote: >> Machine check in kernel mode. >=20 > This means your kernel paniced. Valgrind triggers it, but isn't the > cause.=20 >=20 >> 3 warnings issued. Results may not be reliable. >>=20 >>=20 >> Any ideas ? >=20 > Any reason you're using this version ? I suggest a more recent kernel > version.=20 >=20 Ah yes ! Our platform is not supported by 2.6.XX so far. I really would like to get to 2.6.XX but this will need still quite a time, I guess. Strangely I still guess that valgrind does something unusual that it triggers the Kernel bug. I meam all of the normal applications do work normally. The oops happens if it accesses is something inside /proc ... What is valgrind actually doing here ? Ciao, Daniel. |
|
From: Julian S. <js...@ac...> - 2007-02-23 16:04:17
|
> The oops happens if it accesses is something inside /proc ... What is > valgrind actually doing here ? The message you saw is incomplete. It says "reading /proc/self/maps" and so the process is simply reading its own /proc/self/map file to find out the its initial memory layout. Nothing complex. J |
|
From: Bart V. A. <bar...@gm...> - 2007-02-23 16:03:32
|
On 2/23/07, Daniel Schnell <dan...@ma...> wrote:
>
> Ah yes ! Our platform is not supported by 2.6.XX so far. I really would
> like to get to 2.6.XX but this will need still quite a time, I guess.
>
> Strangely I still guess that valgrind does something unusual that it
> triggers the Kernel bug. I meam all of the normal applications do work
> normally.
>
> The oops happens if it accesses is something inside /proc ... What is
> valgrind actually doing here ?
Hello Daniel,
I hope you will be able to find a workaround such that you can use
Valgrind on the MPC5200B board. But in my opinion Denx, who supplied
you the kernel, should have a look at this. They should at least be
able to explain why the kernel crash happens. And in my opinion they
also should fix their kernel such that Valgrind works on it.
By the way, I have been running Valgrind myself on 32-bit PowerPC
boards, both with 2.4.20 and 2.6.10 kernels modified for real-time
scheduling latency (these kernels were supplied by MontaVista).
Regarding the MPC5200B board and the 2.6 kernel: are you sure the 2.6
kernel is not supported on the MPC5200B board ? Can you please have a
look on the following URL:
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=CWB-MPC5200-LITEB&parentCode=MPC5200B&nodeId=0162468rH3DgbNGrmC0898
Bart.
|
|
From: Daniel S. <dan...@ma...> - 2007-02-23 17:37:00
|
Bart Van Assche wrote: > On 2/23/07, Daniel Schnell <dan...@ma...> wrote: >=20 > I hope you will be able to find a workaround such that you can > use Valgrind on the MPC5200B board. But in my opinion Denx, who > supplied you the kernel, should have a look at this. They should at > least be able to explain why the kernel crash happens. And in my > opinion they also should fix their kernel such that Valgrind works on > it. =20 >=20 > By the way, I have been running Valgrind myself on 32-bit PowerPC > boards, both with 2.4.20 and 2.6.10 kernels modified for real-time > scheduling latency (these kernels were supplied by MontaVista). =20 >=20 > Regarding the MPC5200B board and the 2.6 kernel: are you sure the 2.6 > kernel is not supported on the MPC5200B board ? Can you please have a > look on the following URL: =20 > http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=3DCWB-MPC5= 2 00-LITEB&parentCode=3DMPC5200B&nodeId=3D0162468rH3DgbNGrmC0898 >=20 Thanks for your advice and the link. I will do ask Denx about the issue. They should be able to reproduce the error. I know there are patches for the 2.6 Kernel for MPC5200B. But it is supposed to not be ready for production yet. This will probably not change until the merge ppc --> powerpc is completed. Ciao, Daniel. |