maemo.org - Talk - [Announce] kernel-power stable v52 in Extras

maemo.org - Talk (https://talk.maemo.org/index.php)

- Maemo 5 / Fremantle (https://talk.maemo.org/forumdisplay.php?f=40)

- - [Announce] kernel-power stable v52 in Extras (https://talk.maemo.org/showthread.php?t=89823)

Re: [Announce] kernel-power stable v52 in Extras-Devel

Ahoj pali,

I believe something is screwed up.
Either on my device. Or with kp52 modules.
I would like your help on this please.

I have upgraded my device a bit the last days/weeks. And now felt the need to boot stock kernel.
I ended in a few days of reboot loop sessions. Luckily I still have multiboot (I know ;)) and of course use (almost) only u-boot, so I could easily get out of it (most of the times :().

I examined this behaviour and thought it might be my setup (u-boot/multiboot), but I could boot kp47/kp50 and kp52. No problem at all. Only stock kernel oopsed out directly after "sbin/init 2" was called.
I enabled syslog, but to no avail. I could see logs from pk but not stock. I checked modules and depmod and current symlink and everything else. So I ran out of ideas...
Then I checked some more logs I never noticed before :rolleyes: in /var/log.
maemo-optify-boottime
oopslogtail

The oops one brought me to the idea to check mtd2 with sp-oops-extract and I found some strange messages:

Code:

Log Entry 230 (at position 37)

[   43.047973] Unable to handle kernel NULL pointer dereference at virtual address 00000000

[   43.048065] pgd = cd96c000

[   43.048065] [00000000] *pgd=8e784031, *pte=00000000, *ppte=00000000

[   43.048126] Internal error: Oops: 17 [#1] PREEMPT

[   43.048156] Modules linked in: pvrsrvkm bridgedriver g_file_storage uinput board_rx51_camera et8ek8 omap_previewer_hack omap34xxcam_mod isp_mod iovmm videobuf_dma_sg videobuf_core omap3_iommu iommu2 iommu dspbridge ssi_mcsaab_imp cmt_speech phonet smc91x mii wl12xx omap_ssi mac80211 crc7 tsc2005 nokia_av hci_h4p bluetooth fmtx_si4713 ad5820 lis302dl videodev v4l1_compat compat_ioctl32 adp1653 tsl2563 smia_sensor smiaregs v4l2_int_device rtc_twl4030 rtc_core leds_twl4030_vibra joydev nls_utf8 fuse cifs ntfs leds_lp5523 led_class mmc_block omap_hsmmc mmc_core twl4030_wdt omap_wdt

[   43.048553] CPU: 0    Not tainted  (2.6.28-omap1 #1)

[   43.048645] PC is at regsupGetValue+0x28/0xa4 [bridgedriver]

[   43.048706] LR is at REG_GetValue+0x1c/0x34 [bridgedriver]

[   43.048767] pc : [<bf26cd1c>]    lr : [<bf26c9a0>]    psr: 60000013

[   43.048767] sp : ce54dda8  ip : ce54dde0  fp : ce54dddc

[   43.048797] r10: bf289233  r9 : ce54de1c  r8 : 00000000

[   43.048828] r7 : ce77db88  r6 : 00000000  r5 : 00000000  r4 : ce54de1c

[   43.048858] r3 : bf2903b8  r2 : ce54ddfc  r1 : ce54de1c  r0 : bf289233

[   43.048919] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user

[   43.048950] Control: 10c5387d  Table: 8d96c018  DAC: 00000015

[   43.048980] Process dsp-manager (pid: 970, stack limit = 0xce54c2e0)

[   43.049011] Stack: (0xce54dda8 to 0xce54e000)

[   43.049041] dda0:                   c0153d70 ce54ddfc bf28fdc0 ce54de1c cd82f900 cd80e400

[   43.049102] ddc0: ce77db88 00000000 ce54c000 cd82f900 ce54ddec ce54dde0 bf26c9a0 bf26cd00

[   43.049163] dde0: ce54de14 ce54ddf0 bf26c6a4 bf26c990 ce54ddfc c007d024 c00d0980 00000004

[   43.049224] de00: 000000f8 00000000 ce54de34 ce54de18 bf285140 bf26c658 00000000 cfd78100

[   43.049316] de20: ce54c000 00000000 ce54de64 ce54de38 c00bcc8c bf285124 c00c4750 00000000

[   43.049377] de40: cd82f900 ce77db88 00000000 c00bcaa4 cfd78100 ced94980 ce54de8c ce54de68

[   43.049438] de60: c00b7648 c00bcab0 cd82f900 ce54ded8 ffffff9c 00000003 00000003 40024000

[   43.049499] de80: ce54deac ce54de90 c00b7798 c00b74b4 00000000 ce54ded8 ffffff9c 00000000

[   43.049591] dea0: ce54df64 ce54deb0 c00c59c4 c00b776c 00000003 ce54dec0 c0071594 0000000c

[   43.049652] dec0: 00000002 ce54ded0 00000026 c0071590 00000000 00001000 cfd78100 ced94980

[   43.049713] dee0: 00000017 ce54dfb0 40156064 00000101 00000001 00000000 ce54dfac ce54df08

[   43.049774] df00: c002c24c c028806c ce4c8180 cfe8a420 00000394 cd96d000 cd843540 00000003

[   43.049865] df20: 00000000 cd82f900 00000000 ce54c000 ce54df64 ce54df40 c00cec38 00000002

[   43.049926] df40: 0000000c ffffff9c 00000003 ce509000 ce54c000 40024000 ce54df94 ce54df68

[   43.049987] df60: c00b73c0 c00c565c 00000000 40024000 ce54df9c 00000000 4001cbf0 00012008

[   43.050048] df80: 00000005 c002caa4 ce54dfa4 ce54df98 c00b7488 c00b7370 00000000 ce54dfa8

[   43.050140] dfa0: c002c920 c00b7470 00000000 4001cbf0 000094fc 00000002 0000000c 00000000

[   43.050201] dfc0: 00000000 4001cbf0 00012008 00000005 00011674 00000000 40024000 bebd7cdc

[   43.050262] dfe0: 00012018 bebd7cd8 0000922c 400e504c 60000010 000094fc e89da8f0 e5953000

[   43.050323] Backtrace:

[   43.050354] [<bf26ccf4>] (regsupGetValue+0x0/0xa4 [bridgedriver]) from [<bf26c9a0>] (REG_GetValue+0x1c/0x34 [bridgedriver])

[   43.050476] [<bf26c984>] (REG_GetValue+0x0/0x34 [bridgedriver]) from [<bf26c6a4>] (CFG_GetObject+0x58/0x84 [bridgedriver])

[   43.050598] [<bf26c64c>] (CFG_GetObject+0x0/0x84 [bridgedriver]) from [<bf285140>] (bridge_open+0x28/0x134 [bridgedriver])

[   43.050750]  r4:00000000

[   43.050750] [<bf285118>] (bridge_open+0x0/0x134 [bridgedriver]) from [<c00bcc8c>] (chrdev_open+0x1e8/0x208)

[   43.050872]  r5:00000000 r4:ce54c000

[   43.050903] [<c00bcaa4>] (chrdev_open+0x0/0x208) from [<c00b7648>] (__dentry_open+0x1a0/0x2b8)

Log Entry 231 (at position 38)

[   43.051666] mtdoops: Ready 38, 231 (no erase)

[   43.051696] [<c00b74a8>] (__dentry_open+0x0/0x2b8) from [<c00b7798>] (nameidata_to_filp+0x38/0x50)

[   43.051757] [<c00b7760>] (nameidata_to_filp+0x0/0x50) from [<c00c59c4>] (do_filp_open+0x374/0x730)

[   43.051818]  r4:00000000

[   43.051849] [<c00c5650>] (do_filp_open+0x0/0x730) from [<c00b73c0>] (do_sys_open+0x5c/0xec)

[   43.051910] [<c00b7364>] (do_sys_open+0x0/0xec) from [<c00b7488>] (sys_open+0x24/0x28)

[   43.051971]  r8:c002caa4 r7:00000005 r6:00012008 r5:4001cbf0 r4:00000000

[   43.052032] [<c00b7464>] (sys_open+0x0/0x28) from [<c002c920>] (ret_fast_syscall+0x0/0x2c)

[   43.052093] Code: e1a0a000 e5936000 e1a09001 e3a05000 (e5968000)



Log Entry 232 (at position 39)

[   43.052642] mtdoops: Ready 39, 232 (no erase)

[   43.052673] Kernel panic - not syncing: Fatal exception

Exactly that module I had in suspicion a few hours ago, as it was strange that after installing kp52-modules, I did not have that "#fixed by power-kernel" line in /etc/modprobe.d/bridgedriver.
So I reinstalled modules and then it looked exactly like expected.
Before (and after first module install:

Code:

options bridgedriver shm_size=0x500000 base_img=/lib/dsp/baseimage.dof

After second module reinstall:

Code:

options bridgedriver phys_mempool_base=0 base_img=/lib/dsp/baseimage.dof

After manual echoing the version (in postrm):

Code:

options bridgedriver shm_size=0x400000 phys_mempool_base=0 base_img=/lib/dsp/baseimage.dof

Only with the last entry, the stock kernel boots up.

It was no difference if booted with u-boot or kernel from NAND directly.

Can someone confirm that stock kernel does not boot with latest u-boot and kp52 modules?
Or is it something strange on my device?

One more possible reason: I needed to use backupmenu (for the very first time) a few days ago (dumb me upgrading) and had some problems to restore, claiming something about corrupt fs. But single restore, first root - then opt, worked and kp52 works flawlessly.
But I have those strange boot-maemo-optify logs and messages like

Code:

2009-01-01 10:34:33 :: not enough free space in /home (need at least 200 MB free), quitting.

initctl: MOUNTS_OK event failed

1+0 records in

1+0 records out

512 bytes (512B) copied, 1.521210 seconds, 336B/s

But /home has enough free space and is working okay. I am afraid to use e2fsck on /home, as it ruined my debian image a few times already.

So enough now, what do you think?
Might it be some bug? Or why bridgedriver did not get updated on first install? And why stock kernel only wants to boot with original entry?

Thank you in advance for your help and/or experienced tips.
peterleinchen

P.S.: oh and btw if this tends to be something strange only on my device I will create new thread ...

Re: [Announce] kernel-power stable v52 in Extras-Devel

Quote:

Originally Posted by salahkhani (Post 1365906)

thanks alot my friend and hope will get better but for me I have returned it to stock kernel cause it 's himreging the battery so batter as I have just charged it full and after 3 hours it starts showing low battery even thaugh am not using it just checking the battery condition

minimum speed was 125 and max was 600 and till now didn't understand why it was draining the battery soooooooooooo quickely

check voltages , read overclocking/underclocking tutorial

Re: [Announce] kernel-power stable v52 in Extras-Devel

@freemangordon: can you look at @peterleinchen problem?

If I remember correctly kp52 has updated dsp bridge kernel module which needs new options in /etc/modprobe.d/bridgedriver. So maybe it can break stock kernel, but I did not have this problem. I can boot both kernel-power and stock kernel (with updated modprobe.d). But this could be device dependent...

Re: [Announce] kernel-power stable v52 in Extras-Devel

Quote:

Originally Posted by pali (Post 1366751)

It is like that for as long as we have harmattan bridgedriver backported in KP - KP48 iirc.

This is what I have on my device(kernel-cssu):

Code:

Nokia-N900:~# cat /etc/modprobe.d/bridgedriver

options bridgedriver phys_mempool_base=0 base_img=/lib/dsp/baseimage.dof

#fixed by kernel-cssu

Nokia-N900:~#

not specifying shm_size is needed so both kernels to coexist and to use their defaults (0x500000 for KP and 0x400000 for omap1)

No idea who changed that and why, but I don't think it is KP:

https://garage.maemo.org/plugins/ggi...62;hb=HEAD#l14

Re: [Announce] kernel-power stable v52 in Extras-Devel

@pali and fmg
Thanks, sounds reasonable. As I have some other strange behaviours (USB does not get recognized, but I need to unload g_file_storage once manually) and now this and those strange optfs too low messages, I decoded to start all over with a backup from July and upgrade one more time.
One beg: does anybody have the mkfs command for optfs? I am gonna clean optfs on rescue shell and then restore backup. Or is it just a plain mkfs? Thinking about some root reserved clusters, naming and so on ...

Re: [Announce] kernel-power stable v52 in Extras-Devel

AFAIK no reserved things - just make sure you ID partition correctly, as plain fdisk does something funny with it (like setting same ID for every type of partition).

Not so long ago, I had a headache trying to understand why N900 fails to properly use perfectly fine partition table, in particular, deny to use OptFS. It turned out, that some startup scripts (rcS-late?) "cleverly" identify partition meant to be Opt by... checking ID. That is, f****n ID - almost as stupid, as using labels for that purpose. As every partition has same ID, it wanted to use MyDocs (as first found partition with matching ID) for OptFS purposes, resulting in disaster. Setting correct Ids via sfdisk (without re-formatting, just changing IDs itself) fixed it immediately.

Other than that, no special requirements for OptFS, you may give it whatever labels, root reserved percentage, journals, etc. you feel fancy.

/Estel

Re: [Announce] kernel-power stable v52 in Extras-Devel

Quote:

Originally Posted by Estel (Post 1367440)

It turned out, that some startup scripts (rcS-late?) "cleverly" identify partition meant to be Opt by... checking ID. That is, f****n ID - almost as stupid, as using labels for that purpose.

Annoying, isn't it? I don't understand this world's obsession with IDs. What's wrong with good old /dev/[hs]da[1234]? However hard I try, I can't think of a use case when an ID would be preferable. Quite the opposite in fact, I've lost count of how many times it got in the way of doing things (resizing partitions, for example).

I see it as an annoying penetration of the Windows way of thinking into the open-source ecosystem and a contamination of the latter with the former.

Sorry about the rant, couldn't help it.

Re: [Announce] kernel-power stable v52 in Extras-Devel

Quote:

Originally Posted by pichlo (Post 1367544)

I can't think of a use case when an ID would be preferable. Quite the opposite in fact, I've lost count of how many times it got in the way of doing things (resizing partitions, for example).

<OT>
Well, I can give you a few reasons:
- I know lots of people who are unable to insert RAID disks in the correct order
- the use of multiple external disks for backups, where certain locations need backup to certain disks

But none n900 or embedded-related.

Re: [Announce] kernel-power stable v52 in Extras-Devel

Quote:

Originally Posted by peterleinchen (Post 1366812)

Just a short feedback: of course I stumbled again into some troubles (see 720p thread and other posts of mine from today :)).
But after formatting optfs (yes, it was somehow corrupted) and upgrading once more and solving the trouble, it looks like everything is fine.
Thanks again for fast feedback.

Re: [Announce] kernel-power stable v52 in Extras-Devel