[Gta04-owner] Linux 3.2-rc3 on GTA04

NeilBrown neilb at suse.de
Wed Nov 30 01:48:09 CET 2011


On Wed, 30 Nov 2011 00:17:04 +0000 Neil Jerram <neil at ossau.homelinux.net>
wrote:

> On 28.11.2011 23:58, Neil Jerram wrote:
> > On 26.11.2011 11:43, NeilBrown wrote:
> >> Hi again,
> >>
> >>  I have just updated
> >>     git://neil.brown.name/gta04#merge
> >>
> >>  to 3.2-rc3.
> >
> >> All input very welcome,
> >
> > For me it boots successfully into X.
> 
> A few other things to report...
> 
> 1. I don't think the phone is shutting down fully when I say "shutdown 
> -h now" and then remove the USB cable, whereas the hw-validation kernel 
> did.  Is it a known problem?  If not, is there something I can do to pin 
> it down more precisely?

Yes, I noticed that too.

The only strategy I know of to get more info is to read the code, try to
follow what is meant to happen, and put in "printk" statements to find out
what actually happens.

(... uses "git grep" a bit a looks around ....)

The key information is the "pm_power_off" variable.
Something needs to set this to make power_off happen.
In the hw-validation kernel, drivers/mfd/twl4030-power.c
sets it.  In the mainline kernel nothing does.

It seems that twl4030-power.c in mainline contains twl4030_remove_script
which is never used.  Maybe that is meant to do something.
Or maybe we just need to copy twl4030_poweroff from the hw kernel and use
that.  Need to read the twl4030 data sheets and figure out what the two
routines are doing.


> 
> 2. There are 5 lots of "Slab corruption" in my dmesg.  I've no idea 
> what that is, but it doesn't sound good!  Here's the first:
> 
> [    0.176330] Slab corruption: size-32 start=ced512c0, len=32
> [    0.176330] 010: c8 df 01 c0 fc de 01 c0 6b 6b 6b 6b 6b 6b 6b a5  
> ........kkkkkkk.
> [    0.176361] Prev obj: start=ced51280, len=32
> [    0.176391] 000: 80 7d d4 ce c8 22 c0 ce 00 00 00 00 00 50 d5 ce  
> .}...".......P..
> [    0.176422] 010: 01 00 00 00 ff ff ff ff 00 00 5a 5a fd ff ff ff  
> ..........ZZ....
> [    0.176452] Next obj: start=ced51300, len=32
> [    0.176452] 000: 70 6f 77 65 72 00 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  
> power.ZZZZZZZZZZ
> [    0.176483] 010: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a a5  
> ZZZZZZZZZZZZZZZ.
> [    0.176788]  omap-mcbsp.2: alias fck already exists
> [    0.176818] Registering platform device 'omap-mcbsp.2'. Parent at 
> omap
> [    0.176849] device: 'omap-mcbsp.2': device_add
> [    0.176910] bus: 'platform': add device omap-mcbsp.2
> [    0.177093] PM: Adding info for platform:omap-mcbsp.2

I noticed that a couple of times.  Tracking that down will be tricky.
I'm hoping it'll just disappear in a future -rc :-)


> 
> 3. Also dmesg has "INFO: suspicious RCU usage".  I think someone might 
> have already reported this, but in case not, here it is:
> 
> [   12.227813] ===============================
> [   12.232208] [ INFO: suspicious RCU usage. ]
> [   12.236572] -------------------------------
> [   12.240936] drivers/base/power/opp.c:153 suspicious 
> rcu_dereference_check() usage!
> [   12.248809]
> [   12.248809] other info that might help us debug this:
> [   12.248809]
> [   12.257171]
> [   12.257171] rcu_scheduler_active = 1, debug_locks = 0
> [   12.264007] no locks held by swapper/1.
> [   12.268005]
> [   12.268005] stack backtrace:
> [   12.272674] [<c001361c>] (unwind_backtrace+0x0/0x128) from 
> [<c0252c20>] (opp_get_voltage+0x60/0xb4)
> [   12.282165] [<c0252c20>] (opp_get_voltage+0x60/0xb4) from 
> [<c057ab18>] (omap2_set_init_voltage+0xd4/0x13c)
> [   12.292266] [<c057ab18>] (omap2_set_init_voltage+0xd4/0x13c) from 
> [<c057abb4>] (omap2_common_pm_late_init+0x34/0x58)
> [   12.303253] [<c057abb4>] (omap2_common_pm_late_init+0x34/0x58) from 
> [<c0008678>] (do_one_initcall+0x94/0x160)
> [   12.313659] [<c0008678>] (do_one_initcall+0x94/0x160) from 
> [<c0572220>] (kernel_init+0x7c/0x124)
> [   12.322906] [<c0572220>] (kernel_init+0x7c/0x124) from [<c000f0cc>] 
> (kernel_thread_exit+0x0/0x8)

opp_get_voltage is meant to be called with an rcu lock, but
omap2_get_init_voltage doesn't take the lock.

Below is probably the correct fix, but it needs to be reviewed by omap people.

Thanks,
NeilBrown

diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 1e79bdf..bbc69fd1 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -173,14 +173,17 @@ static int __init omap2_set_init_voltage(char *vdd_name, char *clk_name,
 	freq = clk->rate;
 	clk_put(clk);
 
+	rcu_readlock();
 	opp = opp_find_freq_ceil(dev, &freq);
 	if (IS_ERR(opp)) {
+		rcu_read_unlock();
 		pr_err("%s: unable to find boot up OPP for vdd_%s\n",
 			__func__, vdd_name);
 		goto exit;
 	}
 
 	bootup_volt = opp_get_voltage(opp);
+	rcu_read_unlock();
 	if (!bootup_volt) {
 		pr_err("%s: unable to find voltage corresponding "
 			"to the bootup OPP for vdd_%s\n", __func__, vdd_name);


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20111130/453cb149/attachment.bin>


More information about the Gta04-owner mailing list