2.6.29 and SDP3430

2.6.29 and SDP3430

[Nishanth Menon]

Hi Folks,

just messing around with tony's master branch on SDP3430, just did a
defconfig and a build with  2007q3-51 codesourcery compiler, I see it
hang around:

## Booting image at 80000000 ...
   Image Name:   Linux-2.6.30-rc1-omap1-05613-g30
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1909108 Bytes =  1.8 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux.........................................................................................................................
done, booting th
e kernel.
<5>Linux version 2.6.30-rc1-omap1-05613-g30128fb (asda) (gcc version
4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-51)) #1 Thu Apr 9
01:30:30 CDT 2
009
CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c5387f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: OMAP3430 3430SDP board
Memory policy: ECC disabled, Data cache writeback
<7>On node 0 totalpages: 32768
<7>free_area_init_node: node 0, pgdat c03b4f64, node_mem_map c03d0000
<7>  Normal zone: 256 pages used for memmap
<7>  Normal zone: 0 pages reserved
<7>  Normal zone: 32512 pages, LIFO batch:7
<6>OMAP3430 ES3.0
<6>SRAM: Mapped pa 0x40200000 to va 0xd7000000 size: 0x100000
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
<5>Kernel command line: console=ttyS0,115200n8 noinitrd ip=dhcp
root=/dev/nfs rw nfsroot=IP:PATH,nolock,wsize=1024,rsize=1024
<6>NR_IRQS:402
<6>Clocking rate (Crystal/DPLL/ARM core): 26.0/332/500 MHz
<6>GPMC revision 5.0
<6>IRQ: Found an INTC at 0xd8200000 (revision 4.0) with 96 interrupts
<6>Total of 96 interrupts on 1 active controller
<6>OMAP34xx GPIO hardware version 2.5
PID hash table entries: 512 (order: 9, 2048 bytes)
Console: colour dummy device 80x30
<6>Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
<6>Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
<6>Memory: 128MB = 128MB total
<5>Memory: 125880KB available (3304K code, 307K data, 140K init, 0K highmem)
<6>Calibrating delay loop...

Has anyone tried this recently?
Regards,
Nishanth Menon

Re: 2.6.29 and SDP3430

[Jarkko Nikula]

On Thu, 9 Apr 2009 08:45:00 +0200
ext Nishanth Menon <menon.nishanth@gmail.com> wrote:

> Hi Folks,
> 
> just messing around with tony's master branch on SDP3430, just did a
> defconfig and a build with  2007q3-51 codesourcery compiler, I see it
> hang around:
> 
Kernels built with this compiler stuck into delay loop calibration.
No idea why, but 2008q3-66 was working for me.


Jarkko

RE: 2.6.29 and SDP3430

[Nayak, Rajendra]

Check this up.. 
http://marc.info/?t=123698463000001&r=1&w=2 

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org 
> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Nishanth Menon
> Sent: Thursday, April 09, 2009 12:15 PM
> To: linux-omap
> Subject: 2.6.29 and SDP3430
> 
> Hi Folks,
> 
> just messing around with tony's master branch on SDP3430, just did a
> defconfig and a build with  2007q3-51 codesourcery compiler, I see it
> hang around:
> 
> ## Booting image at 80000000 ...
>    Image Name:   Linux-2.6.30-rc1-omap1-05613-g30
>    Image Type:   ARM Linux Kernel Image (uncompressed)
>    Data Size:    1909108 Bytes =  1.8 MB
>    Load Address: 80008000
>    Entry Point:  80008000
>    Verifying Checksum ... OK
> OK
> 
> Starting kernel ...
> 
> Uncompressing 
> Linux.........................................................
> ................................................................
> done, booting th
> e kernel.
> <5>Linux version 2.6.30-rc1-omap1-05613-g30128fb (asda) (gcc version
> 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-51)) #1 Thu Apr 9
> 01:30:30 CDT 2
> 009
> CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c5387f
> CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
> Machine: OMAP3430 3430SDP board
> Memory policy: ECC disabled, Data cache writeback
> <7>On node 0 totalpages: 32768
> <7>free_area_init_node: node 0, pgdat c03b4f64, node_mem_map c03d0000
> <7>  Normal zone: 256 pages used for memmap
> <7>  Normal zone: 0 pages reserved
> <7>  Normal zone: 32512 pages, LIFO batch:7
> <6>OMAP3430 ES3.0
> <6>SRAM: Mapped pa 0x40200000 to va 0xd7000000 size: 0x100000
> Built 1 zonelists in Zone order, mobility grouping on.  Total 
> pages: 32512
> <5>Kernel command line: console=ttyS0,115200n8 noinitrd ip=dhcp
> root=/dev/nfs rw nfsroot=IP:PATH,nolock,wsize=1024,rsize=1024
> <6>NR_IRQS:402
> <6>Clocking rate (Crystal/DPLL/ARM core): 26.0/332/500 MHz
> <6>GPMC revision 5.0
> <6>IRQ: Found an INTC at 0xd8200000 (revision 4.0) with 96 interrupts
> <6>Total of 96 interrupts on 1 active controller
> <6>OMAP34xx GPIO hardware version 2.5
> PID hash table entries: 512 (order: 9, 2048 bytes)
> Console: colour dummy device 80x30
> <6>Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
> <6>Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
> <6>Memory: 128MB = 128MB total
> <5>Memory: 125880KB available (3304K code, 307K data, 140K 
> init, 0K highmem)
> <6>Calibrating delay loop...
> 
> Has anyone tried this recently?
> Regards,
> Nishanth Menon
> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: 2.6.29 and SDP3430 [needs CSL2008q3]

[Nishanth Menon]

Jarkko Nikula said the following on 04/09/2009 02:03 AM:
> On Thu, 9 Apr 2009 08:45:00 +0200
> ext Nishanth Menon <menon.nishanth@gmail.com> wrote:
>
>   
>> just messing around with tony's master branch on SDP3430, just did a
>> defconfig and a build with  2007q3-51 codesourcery compiler, I see it
>> hang around:
>>
>>     
> Kernels built with this compiler stuck into delay loop calibration.
> No idea why, but 2008q3-66 was working for me.
>   

Thanks guys..(though I wonder why exactly wont 2007q3 no longer work..
some sort of compiler bug which got fixed later??)..
Regards,
Nishanth Menon

RE: 2.6.29 and SDP3430

[Woodruff, Richard]

> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Jarkko Nikula
> Sent: Thursday, April 09, 2009 2:04 AM

> > just messing around with tony's master branch on SDP3430, just did a
> > defconfig and a build with  2007q3-51 codesourcery compiler, I see it
> > hang around:
> >
> Kernels built with this compiler stuck into delay loop calibration.
> No idea why, but 2008q3-66 was working for me.

I wonder if the timer stopped ticking.  If you connect with emulator take a look at GPT1 registers and see if time base is moving.

Another quick test is to shut off tickles, nohz=off.

Calibration code is just is spinning and counting interrupts.

Regards,
Richard W.

RE: 2.6.29 and SDP3430

[Menon, Nishanth]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Woodruff, Richard
> Sent: Thursday, April 09, 2009 8:00 AM
> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > owner@vger.kernel.org] On Behalf Of Jarkko Nikula
> > Sent: Thursday, April 09, 2009 2:04 AM
> 
> > > just messing around with tony's master branch on SDP3430, just did a
> > > defconfig and a build with  2007q3-51 codesourcery compiler, I see it
> > > hang around:
> > >
> > Kernels built with this compiler stuck into delay loop calibration.
> > No idea why, but 2008q3-66 was working for me.
Using the following:
arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2008q3-72) 4.3.2

I am past the lockup on calibration, but it now gets stuck as follows:
NET: Registered protocol family 15
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
Disabling unused clock "gpt2_ick"
Disabling unused clock "gpt2_fck"
Disabling unused clock "wdt2_ick"
Disabling unused clock "wdt2_fck"
Disabling unused clock "dpll4_m6x2_ck"
Disabling unused clock "dpll4_m5x2_ck"
Disabling unused clock "dpll3_m3x2_ck"
Disabling unused clock "sys_clkout1"
variant c rev 1
implementor 41 architecture 3 part 30 variant c rev 1
regulator_init_complete: incomplete constraints, leaving VAUX3 on


> 
> I wonder if the timer stopped ticking.  If you connect with emulator take
> a look at GPT1 registers and see if time base is moving.
> 
> Another quick test is to shut off tickles, nohz=off.
nohz=off did not work with either 2007q3 or 2008q3.. have'nt looked at the GPT regs though..

Regards,
Nishanth Menon

RE: 2.6.29 and SDP3430

[Woodruff, Richard]

> > I wonder if the timer stopped ticking.  If you connect with emulator take
> > a look at GPT1 registers and see if time base is moving.
> >
> > Another quick test is to shut off tickles, nohz=off.
> nohz=off did not work with either 2007q3 or 2008q3.. have'nt looked at the GPT
> regs though..

Hmm, something is broke.

Can put bad SDP kernel and vmlinux on a share and send me link?  I'm feeling lazy, but could take a quick peek as it's curious :)

Thanks,
Richard W.

Re: 2.6.29 and SDP3430

[Mark Brown]

On Thu, Apr 09, 2009 at 01:32:27PM -0500, Menon, Nishanth wrote:

> implementor 41 architecture 3 part 30 variant c rev 1
> regulator_init_complete: incomplete constraints, leaving VAUX3 on

That last message shouldn't be a problem - it means that if the machine
init code had requested it the regulator core would've powered off the
VAUX3 regulator since it has no users.

RE: 2.6.29 and SDP3430

[Pandita, Vikram]

>-----Original Message-----
>From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Menon,
>Nishanth
>Using the following:
>arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2008q3-72) 4.3.2
>
>I am past the lockup on calibration, but it now gets stuck as follows:
>NET: Registered protocol family 15
>RPC: Registered udp transport module.
>RPC: Registered tcp transport module.
>Disabling unused clock "gpt2_ick"
>Disabling unused clock "gpt2_fck"
>Disabling unused clock "wdt2_ick"
>Disabling unused clock "wdt2_fck"
>Disabling unused clock "dpll4_m6x2_ck"
>Disabling unused clock "dpll4_m5x2_ck"
>Disabling unused clock "dpll3_m3x2_ck"
>Disabling unused clock "sys_clkout1"
>variant c rev 1
>implementor 41 architecture 3 part 30 variant c rev 1
>regulator_init_complete: incomplete constraints, leaving VAUX3 on
>

On master of Linux-Omap: 2.6.30-rc1
Board: LDP(3430)
Toolchain version: arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2008q3-72) 4.3.2

I am also seeing a hang at following bootup time:

console [ttyS2] enabled
<6>brd: module loaded
brd: module loaded
<6>loop: module loaded
loop: module loaded
<6>i2c /dev entries driver
i2c /dev entries driver
...

And after a long time I see constant Crash dumps as follows

Mem-info:
Mem-info:
Normal per-cpu:
Normal per-cpu:
CPU    0: hi:   42, btch:   7 usd:   6
CPU    0: hi:   42, btch:   7 usd:   6
Active_anon:0 active_file:0 inactive_anon:0
 inactive_file:0 unevictable:0 dirty:0 writeback:0 unstable:0
 free:133 slab:31174 mapped:0 pagetables:0 bounce:0
Active_anon:0 active_file:0 inactive_anon:0
 inactive_file:0 unevictable:0 dirty:0 writeback:0 unstable:0
 free:133 slab:31174 mapped:0 pagetables:0 bounce:0
Normal free:532kB min:1440kB low:1800kB high:2160kB active_anon:0kB inactive_ano
n:0kB active_file:0kB inactive_file:0kB unevictable:0kB present:130048kB pages_s
canned:0 all_unreclaimable? no
Normal free:532kB min:1440kB low:1800kB high:2160kB active_anon:0kB inactive_ano
n:0kB active_file:0kB inactive_file:0kB unevictable:0kB present:130048kB pages_s
canned:0 all_unreclaimable? no
lowmem_reserve[]:lowmem_reserve[]: 0 0 0 0

Normal: Normal: 1*4kB 1*4kB 0*8kB 0*8kB 1*16kB 1*16kB 0*32kB 0*32kB 0*64kB 0*64k
B 0*128kB 0*128kB 0*256kB 0*256kB 1*512kB 1*512kB 0*1024kB 0*1024kB 0*2048kB 0*2
048kB 0*4096kB 0*4096kB = 532kB
= 532kB
0 total pagecache pages
0 total pagecache pages
0 pages in swap cache
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Swap cache stats: add 0, delete 0, find 0/0
Free swap  = 0kB
Free swap  = 0kB
Total swap = 0kB
Total swap = 0kB
32768 pages of RAM
32768 pages of RAM
164 free pages
164 free pages
1371 reserved pages
1371 reserved pages
31174 slab pages
31174 slab pages
0 pages shared
0 pages shared
0 pages swap cached
0 pages swap cached
<4>swapper: page allocation failure. order:0, mode:0x20
swapper: page allocation failure. order:0, mode:0x20
[<c00322d8>] [<c00322d8>] (unwind_backtrace+0x0/0xdc) (unwind_backtrace+0x0/0xdc
) from [<c007b344>] from [<c007b344>] (__alloc_pages_internal+0x384/0x3a4)
(__alloc_pages_internal+0x384/0x3a4)
[<c007b344>] [<c007b344>] (__alloc_pages_internal+0x384/0x3a4) (__alloc_pages_in
ternal+0x384/0x3a4) from [<c0095550>] from [<c0095550>] (cache_alloc_refill+0x24
0/0x4bc)
(cache_alloc_refill+0x240/0x4bc)
[<c0095550>] [<c0095550>] (cache_alloc_refill+0x240/0x4bc) (cache_alloc_refill+0
x240/0x4bc) from [<c00958cc>] from [<c00958cc>] (kmem_cache_alloc+0x44/0x7c)
(kmem_cache_alloc+0x44/0x7c)
[<c00958cc>] [<c00958cc>] (kmem_cache_alloc+0x44/0x7c) (kmem_cache_alloc+0x44/0x
7c) from [<c005cef0>] from [<c005cef0>] (call_usermodehelper_setup+0x20/0x70)
(call_usermodehelper_setup+0x20/0x70)
[<c005cef0>] [<c005cef0>] (call_usermodehelper_setup+0x20/0x70) (call_usermodehe
lper_setup+0x20/0x70) from [<c0157e54>] from [<c0157e54>] (kobject_uevent_env+0x
30c/0x388)
(kobject_uevent_env+0x30c/0x388)
[<c0157e54>] [<c0157e54>] (kobject_uevent_env+0x30c/0x388) (kobject_uevent_env+0
x30c/0x388) from [<c0196860>] from [<c0196860>] (device_add+0x4f4/0x540)
(device_add+0x4f4/0x540)
[<c0196860>] [<c0196860>] (device_add+0x4f4/0x540) (device_add+0x4f4/0x540) from
 [<c0196938>] from [<c0196938>] (device_create_vargs+0x74/0xa4)
(device_create_vargs+0x74/0xa4)
[<c0196938>] [<c0196938>] (device_create_vargs+0x74/0xa4) (device_create_vargs+0
x74/0xa4) from [<c0196984>] from [<c0196984>] (device_create+0x1c/0x24)
(device_create+0x1c/0x24)
[<c0196984>] [<c0196984>] (device_create+0x1c/0x24) (device_create+0x1c/0x24) fr
om [<c01a0c84>] from [<c01a0c84>] (i2cdev_attach_adapter+0x94/0xe8)
(i2cdev_attach_adapter+0x94/0xe8)
[<c01a0c84>] [<c01a0c84>] (i2cdev_attach_adapter+0x94/0xe8) (i2cdev_attach_adapt
er+0x94/0xe8) from [<c01a076c>] from [<c01a076c>] (__attach_adapter+0x28/0x30)
(__attach_adapter+0x28/0x30)
[<c01a076c>] [<c01a076c>] (__attach_adapter+0x28/0x30) (__attach_adapter+0x28/0x
30) from [<c0198dc8>] from [<c0198dc8>] (class_for_each_device+0x6c/0xac)
(class_for_each_device+0x6c/0xac)
[<c0198dc8>] [<c0198dc8>] (class_for_each_device+0x6c/0xac) (class_for_each_devi
ce+0x6c/0xac) from [<c01a0018>] from [<c01a0018>] (i2c_register_driver+0xd0/0xf0
)
(i2c_register_driver+0xd0/0xf0)
[<c01a0018>] [<c01a0018>] (i2c_register_driver+0xd0/0xf0) (i2c_register_driver+0
xd0/0xf0) from [<c0018058>] from [<c0018058>] (i2c_dev_init+0x50/0xa0)
(i2c_dev_init+0x50/0xa0)
[<c0018058>] [<c0018058>] (i2c_dev_init+0x50/0xa0) (i2c_dev_init+0x50/0xa0) from
 [<c002c27c>] from [<c002c27c>] (do_one_initcall+0x54/0x194)
(do_one_initcall+0x54/0x194)
[<c002c27c>] [<c002c27c>] (do_one_initcall+0x54/0x194) (do_one_initcall+0x54/0x1
94) from [<c000852c>] from [<c000852c>] (kernel_init+0x70/0xe4)
(kernel_init+0x70/0xe4)
[<c000852c>] [<c000852c>] (kernel_init+0x70/0xe4) (kernel_init+0x70/0xe4) from [
<c0051c20>] from [<c0051c20>] (do_exit+0x0/0x574)
(do_exit+0x0/0x574)
[<c0051c20>] [<c0051c20>] (do_exit+0x0/0x574) (do_exit+0x0/0x574) from [<0000000
1>] from [<00000001>] (0x1)
(0x1)

>
>>
>> I wonder if the timer stopped ticking.  If you connect with emulator take
>> a look at GPT1 registers and see if time base is moving.
>>
>> Another quick test is to shut off tickles, nohz=off.
>nohz=off did not work with either 2007q3 or 2008q3.. have'nt looked at the GPT regs though..
>
>Regards,
>Nishanth Menon
>--
>To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: 2.6.29 and SDP3430

[Woodruff, Richard]

> -----Original Message-----
> From: Pandita, Vikram
> Sent: Tuesday, April 14, 2009 3:08 PM
> To: Menon, Nishanth; Woodruff, Richard; Jarkko Nikula
> Cc: linux-omap
> Subject: RE: 2.6.29 and SDP3430
> I am also seeing a hang at following bootup time:
>
> console [ttyS2] enabled
> <6>brd: module loaded
> brd: module loaded
> <6>loop: module loaded
> loop: module loaded
> <6>i2c /dev entries driver
> i2c /dev entries driver
> ...


I looked really briefly on image with emulator.

It was in a big loop which fairly often was going into I2C.  Normal timer interrupts were firing.  Just the boot was not progressing.  It seems fixing is just time and debug.

Regards,
Richard W.

RE: 2.6.29 and SDP3430

[Woodruff, Richard]

>
> > > I wonder if the timer stopped ticking.  If you connect with emulator take
> > > a look at GPT1 registers and see if time base is moving.
> > >
> > > Another quick test is to shut off tickles, nohz=off.
> > nohz=off did not work with either 2007q3 or 2008q3.. have'nt looked at the
> GPT
> > regs though..
>
> Hmm, something is broke.

One clue.

I see that the TLDR/TCRR are not being written too before the calibration loop starts.  The write watch point is never hit.  So no interrupts have ever fired.

The TIER is enabled but no one gets around to writing to actually set an interrupt wake.  If you setup the timer to generate an interrupt it will take off and run till some USB clock related failure.

For some reason system_timer init is not being fully done before jiffy loop.

Regards,
Richard W.

RE: 2.6.29 and SDP3430

[Aguirre Rodriguez, Sergio Alberto]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Mark Brown
> Sent: Thursday, April 09, 2009 4:34 PM
> To: Menon, Nishanth
> Cc: Woodruff, Richard; Jarkko Nikula; linux-omap
> Subject: Re: 2.6.29 and SDP3430
> 
> On Thu, Apr 09, 2009 at 01:32:27PM -0500, Menon, Nishanth wrote:
> 
> > implementor 41 architecture 3 part 30 variant c rev 1
> > regulator_init_complete: incomplete constraints, leaving VAUX3 on
> 
> That last message shouldn't be a problem - it means that if the machine
> init code had requested it the regulator core would've powered off the
> VAUX3 regulator since it has no users.

Well, I just disabled TWL4030 regulator support (CONFIG_REGULATOR_TWL4030) and now it boots without problem...

I'm using a SDP3430 VG9.0.0 with an ES3.1 chip.

> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: 2.6.29 and SDP3430 <now 2.6.30-rc2, q3-2007 compiler error>

[Woodruff, Richard]

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

So using defconfig and float I debugged around a bit and for q3-2007 I see what looks to be compiler error.

The parameter in R1 which sets PERIODIC mode for call to clockevnet_set_mode()is destroyed.  See PNG.  I did make sure at start_kernel the correct opcode was in place (no overwrite later, no cache flush issue).

If I apply hacks to reduce optimization scope the code does go past hang.  See attached hack.

It seems kind of odd this would bite now after a lot of new use.  Perhaps the new mix of functions and layout triggered it.

Regards,
Richard W.


[-- Attachment #2: tick-q3-2007-bug.PNG --]
[-- Type: image/png, Size: 43887 bytes --]

[-- Attachment #3: bug-q3-2007.diff --]
[-- Type: application/octet-stream, Size: 687 bytes --]

diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index 21a5ca8..44da2f7 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -108,10 +108,14 @@ void tick_setup_periodic(struct clock_event_device *dev, int broadcast)
 	/* Broadcast setup ? */
 	if (!tick_device_is_functional(dev))
 		return;
+	barrier();  // hack
 
 	if ((dev->features & CLOCK_EVT_FEAT_PERIODIC) &&
 	    !tick_broadcast_oneshot_active()) {
-		clockevents_set_mode(dev, CLOCK_EVT_MODE_PERIODIC);
+		volatile int hack = CLOCK_EVT_MODE_PERIODIC; // hack
+		clockevents_set_mode(dev, hack);
+		barrier(); // hack
+		return;  // hack
 	} else {
 		unsigned long seq;
 		ktime_t next;

RE: 2.6.29 and SDP3430 <now 2.6.30-rc2, q3-2007 compiler error>

[Shilimkar, Santosh]

Thanks Richard for root casing the issue.

Yes I also did observed this. Second time when framework calls "omap2_gp_timer_set_mode" set the periodic mode, R0 contains 0 (CLOCK_EVT_MODE_UNUSED) instead of 2(CLOCK_EVT_MODE_PERIODIC).

The assembly generated looks shocking because it prepares the second function arguments in register R1 as expected and then 'pop' destroys it. A "push" before a function call is reasonable but this not quite understandable.

Can this be taken up with Codesorcery team to check what is triggering compiler to generate such an assembly ?


 
> -----Original Message-----
> From: Woodruff, Richard 
> Sent: Tuesday, April 21, 2009 6:34 AM
> To: Aguirre Rodriguez, Sergio Alberto; Mark Brown; Menon, 
> Nishanth; Tony Lindgren
> Cc: Jarkko Nikula; linux-omap; Shilimkar, Santosh; Pandita, Vikram
> Subject: RE: 2.6.29 and SDP3430 <now 2.6.30-rc2, q3-2007 
> compiler error>
> 
> So using defconfig and float I debugged around a bit and for 
> q3-2007 I see what looks to be compiler error.
> 
> The parameter in R1 which sets PERIODIC mode for call to 
> clockevnet_set_mode()is destroyed.  See PNG.  I did make sure 
> at start_kernel the correct opcode was in place (no overwrite 
> later, no cache flush issue).
> 
> If I apply hacks to reduce optimization scope the code does 
> go past hang.  See attached hack.
> 
> It seems kind of odd this would bite now after a lot of new 
> use.  Perhaps the new mix of functions and layout triggered it.
> 
> Regards,
> Richard W.
> 
> 

RE: 2.6.29 and SDP3430 <now 2.6.30-rc2, q3-2007 compiler error>

[Woodruff, Richard]

> From: Shilimkar, Santosh
> Sent: Monday, April 20, 2009 11:39 PM

> Thanks Richard for root casing the issue.
>
> Yes I also did observed this. Second time when framework calls
> "omap2_gp_timer_set_mode" set the periodic mode, R0 contains 0
> (CLOCK_EVT_MODE_UNUSED) instead of 2(CLOCK_EVT_MODE_PERIODIC).
>
> The assembly generated looks shocking because it prepares the second function
> arguments in register R1 as expected and then 'pop' destroys it. A "push"
> before a function call is reasonable but this not quite understandable.
>
> Can this be taken up with Codesorcery team to check what is triggering
> compiler to generate such an assembly ?

The compiler version is old enough I wouldn't anticipate they would do a fix unless someone was using this for production.  Typically they release some for pay fix ups around a base.  This may or may not be fixed in one of those.

If anyone is using it they should speak up.

The compiler probably noticed it could optimize away the function return point (can ret back to caller from called function instead of present one after call.  It then messed up).

Regards,
Richard W.