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

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

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

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

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

Quote:

Originally Posted by seanmcken (Post 1288590)

sir atleast we can try? i mean we can tweak kernel to go over 600? cuz without experiencing we cannot proceed and i think DSP must be extended and freemangordon and pali r the guys who can do these kernel stuff im sorry i dunno other developers's names but these guys are like shining stars so plz guys atleast try plzzzz

No.

(now stop asking)

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

Did you actually _try_ to read what FMG wrote? Your answer is all there! OMG, some people becoming more & more of a nuisance each week...

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

Originally Posted by seanmcken View Post
sir atleast we can try? i mean we can tweak kernel to go over 600? cuz without experiencing we cannot proceed and i think DSP must be extended and freemangordon and pali r the guys who can do these kernel stuff im sorry i dunno other developers's names but these guys are like shining stars so plz guys atleast try plzzzz
No.

pleaseee:):D
i understand what that involves, and i"m assumming the risks
i have a n900 with a silicon piece which can handle vith vdd2 on 1,15 Ghz .
800 mhz dsp wow ,that will make playable higher video bitrates no?

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

Quote:

Originally Posted by Alecsandru (Post 1288735)

Originally Posted by seanmcken View Post
sir atleast we can try? i mean we can tweak kernel to go over 600? cuz without experiencing we cannot proceed and i think DSP must be extended and freemangordon and pali r the guys who can do these kernel stuff im sorry i dunno other developers's names but these guys are like shining stars so plz guys atleast try plzzzz
No.

pleaseee:):D
i understant what involves that and i am asumming the risks
i have a n900 with a chip which handle 1,15 Ghz .
800 mhz dsp wow ,that will make playable higher video bitrates no?

mother of god.

It can be revolver time now please?

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

Quote:

Originally Posted by vi_ (Post 1288748)

mother of god.

It can be revolver time now please?

[totally not serious]
Instead of revolver, we could compile this kernel and give it to them, their n900s would burn them to death from dsp overheating / simply explode like a grenade / or something similar
[/totally not serious]

edit:
[totally not serious 2]
I heard that in the early 2009 some brave souls also tried to experiment with dsp overclocking.
[/totally not serious 2]

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

exploded from battery :p
if we have the file we can experiment until we have reached the sweepspot for the device , and about heat , i'm sure that overclock will not produce enought heat to compare it with heat produced by the nitdroid port+wi-fi , please upload it? :D :D
blesn is working
at least it can take photos with kp52

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

I think it's high time to re-post vi's instructions on overclocking DSP, CPU, MPU, GPU, and everything (tm). You know, the early version, that works once per 6 tries, just made ash compliant and deadly effective. rm -fr loaded...

/Estel

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

Pali, could you include upstream snd_usb_audio (latest stable or testing release) module in next version of KP?

It seems, that old Maemo's snd_usb_audio may be reason, why we can't redirect pulseaudio output to different USB card (conneted via USB).

Thanks a lot!

/Estel

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

@pali----bro,when the kernel power 52 will be in devel????

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

Quote:

Originally Posted by nisheet (Post 1289297)

@pali----bro,when the kernel power 52 will be in devel????

When it is ready?

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

Waiting for dfries patches...

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

I find it odd that ever since having this kernel installed on my phone, that my phone has been sending premium rate text messages to egypt and romania...:mad:

11/04/12 04:24 PM SMOINT EGYPT
(S)
0000000000l
11/04/12 04:23 PM SMOINT ROMANIA
(S)
0000000000l

There are no records of these text messages being logged in my el-v1.db file stored in the .rtcom-eventlogger folder.

Has this package been compromised?

Would some one like to share with me their sha1 hashes of the deb files?

If it is not the kernel which is tainted, then does anyone have any suggestions for finding which package that I have installed that may be rogue?

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

please search for (not-)my-nokia and cherry
/j

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

N900 101: Before activating gsm for the first time - apt-get remove cherry

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

Forgive me for my ignorance but it was this cherry application that is sending premium rate text messages to egypt and romania?

Thank you for the responses btw! :)

(I did read this: http://wiki.maemo.org/PR1.2_compulso...nical_analysis)

That would make sense of it was the program because the number that is being texted appears to be a number that is associated with interfacing between sms and e-mail.

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

Quote:

Originally Posted by pali (Post 1279757)

Packages are updated and here is changelog:

kernel-power (1:2.6.28-10power52) fremantle; urgency=low

* Backport upstream patch: udf-use-hw-sector-size.diff (This fix UDF FS support on SD cards and USB disks)
* Update bq2415x_charger patch: (use kstrtol, use dev_dbg, call sysfs_notify, rename N900 charger to bq24150a, fix reporting bad values, disable charging when charger disconnected)
* Added patch kstrtol.diff which define macro kstrtol as strict_strtol
* Update into about kernel-power-bootimg package
* Package kernel-power-bootimg does not provide any features
* Enable more netfilter and ipv6 modules
* Added driver rx51_battery which export battery temperature, design capacity and voltage to sysfs, provides: kernel-feature-rx51-battery
* Added patch tif_restore_sigmask-syscalls-arm.patch which fix pselect bug, added provides: kernel-feature-sigmask
* Enable bridge module, provides kernel-feature-bridge

-- Pali Rohár <hidden> Fri, 12 Oct 2012 14:59:09 +0200

Few questions which I'm gonna ask here, in order not to spam http://talk.maemo.org/showthread.php...07#post1291607 .

1. You said that the time reported by bq27200 is in seconds, while I see in http://www.ti.com/lit/ds/symlink/bq27200.pdf , page 12, "Minutes". Any explanation?
2. I've seen https://garage.maemo.org/plugins/ggi...587175;hb=HEAD , lines 43-70. And other patches in https://garage.maemo.org/plugins/ggi...d34322;hb=HEAD . Question:

Code:

#define BQ27x00_REG_TTECP              0x26

...

cache.time_to_empty_avg = bq27x00_battery_read_time(di, BQ27x00_REG_TTECP);

while the pdf on the same page 12 states for 0x26

Quote:

Time-to-Empty At Constant Power High - Low Byte

- does the "avg" suffix mean that and I'm just mistakingly taking it for something like "time to empty based on average from last few charges"?

Thank you for taking your time to respond.

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

@misiak,

1) Each power_supply kernel driver must report time in seconds, so bq27x00_battery too (it convert it).

@joerg_rw, you know bq27200 chip better. Time code was not written by me and now I see from datasheet that chip can report more "time to empty" values (TTECP, MLTTE, STTE, TTE, ARTTE). Which should be reported as "average value" and which as "now value"?

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

Quote:

Originally Posted by pali (Post 1291750)

1) Each power_supply kernel driver must report time in seconds, so bq27x00_battery too (it convert it).

Is it possible that there's an error somewhere in this conversion? After all, the values in my N900 are always a multiply of 3600 (60*60)... Unless the value reported by chip is a rough estimation in hours converted to minutes...

I found out your conversion in bq27x00_battery_read_time(struct bq27x00_device_info *di, u8 reg), and following the code, in bq27x00_update(struct bq27x00_device_info *di) I found out you use:

0x16 (TTE, Time-to-Empty) for setting time_to_empty (which is used as POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW - the "now value")
0x26 (TTECP, Time-to-Empty At Constant Power) for setting time_to_empty_avg (which is used as POWER_SUPPLY_PROP_TIME_TO_EMPTY_AVG - the "average value")

How I understand the registry names (but that's only my understanding, I rarely read datasheets):

0x16 (TTE, Time-to-Empty) - the average value (calculated by i-have-no-idea-what-maybe-some-balanced-weighted-formula-or-something)
0x20 (MLTTE, Max Load Time-to-Empty) - the value for "busy" state, "active" state or however we call it - the time to empty under max load, as name says (so maybe this is the "busy" value reported by bme signal)
0x1C (STTE, Standby Time-to-Empty High - Low Byte) - as the name states, time to empty at standby (maybe the "idle" value reported by bme signal)
0x26 (TTECP, Time-to-Empty At Constant Power) - the value of time IF the current (="at the moment") power usage would not change (and that would explain why this value can change so dramaically often and jump from 3600 to 18000 or drop from 18000 to 3600 in just a second)
0x04 (ARTTE, At-Rate Time-to-Empty) - ??? I don't know this one... Maybe the time to empty at power usage from 0x02 - AR, At-Rate?
0x18 (TTF, Time-to-Full) - while charging, time to charge battery to full capacity

TL;DR: The names of most are pretty explanatory, I would suspect 0x1C to be time to empty battery on idle and 0x20 to be time to empty on heavy load... so instead of reporting 0x16 for both values I would report these two, what do you think about that? I would check that by myself, but I'm very busy lately, only time I can write here on TMO is from my N900 while I'm on the train or a bus...

Any comments on that from you, joerg_rw, if you (as pali wrote) know this chip?

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

Ok, i solved the puzzle by reading other pages - Pali, please take a look at pages 12-18 of http://www.ti.com/lit/ds/symlink/bq27200.pdf (sorry for very long quote, I'm quoting here only battery-relevant parts, there are information about more registers and values, maybe you will find that useful):

Quote:

At-Rate Registers (ARL/ARH) — Address 0x02/0x03
The host can write the current in units of 3.57 μV per bit to this register for predictive calculation time-to-empty.
The part uses this value to predict the time-to-empty at any desired current; it does not affect the time-to-empty
calculation based on the actual current. The value in AR is always assumed to be a discharge current.
This register is also used during pack manufacturing to input a nominal available charge value to set NAC to the
approximate initial pack capacity value.
At Rate Time-to-Empty Registers (ARTTEL/ARTTEH) — Address 0x04/0x05
This is predicted time-to-empty in minutes at user-entered discharge rate. The discharge current used in the
calculation is entered by the host system in the AR registers. The at-rate capacity (ARCAP) value used can be
larger or smaller than CACT. It is computed using the same formulas as CACT, except the discharge
compensation is computed using AR, instead of AI, for the discharge rate. The equation used to compute at-rate
time-to-empty is:
ARTTE = 60 * ARCAP / AR
The host system has read-only access to this register pair.
Time-to-Empty Registers (TTEL/TTEH) — Address 0x16/0x17
This register pair reports calculated time-to-empty at the measured discharge rate. This value is based on the
temperature and discharge rate compensated available charge and the average current. The equation to
calculate TTE is:
TTE = 60 * CACT/AI
TTE is reported in minutes. The host system has read-only access to this register pair.
Time-to-Full Registers (TTFL/TTFH) — Address 0x18/0x19
This register pair reports calculated time-to-full at the measured charge rate. The time computed at the average
current charge rate is extended by 50% to estimate the effect of the current taper. TTF is reported in minutes.
The equation for TTF is:
TTF = 60 * 1.50 * (LMD-NAC)/AI
The host system has read-only access to this register pair.
Standby Time-to-Empty Registers (STTEL/STTEH) — Address 0x1C/0x1D
This register pair reports calculated time-to-empty at the measured standby current value. This value is based on
the nominal available charge and the standby current. STTE is reported in minutes. STTE is calculated by:
STTE = 60 * NAC/SI
The host system has read-only access to this register pair.
Max Load Time to Empty Registers (MLTTEL/MLTTEH) — Address 0x20/0x21
This register pair reports calculated time-to-empty in minutes at the maximum measured discharge rate. The Max
Load Capacity (MLCAP) value is based on the temperature and discharge rate compensated available capacity
computed using MLI, instead of AI, for the discharge rate. MLTTE is calculated by:
MLTTE = 60 * MLCAP/MLI
The host system has read-only access to this register pair.
Time-to-Empty at Constant Power Registers (TTECPL/TTECPH) — Address 0x26/0x27
TTECP is the time-to-empty in minutes with a constant power load. Because SAE is already scaled for the
average discharge voltage, the result is simply the ratio of SAE to AP:
TTECP = 60 * SAE/AP
The host system has read-only access to this register pair.

So, basically, in addition to some pre-calculated battery time values, we also have an interactive hardware calculator here which we can "feed" with voltage value to 0x02 and read remaining time value from 0x04 :D

edit: Now I officially propose to edit battery driver module and add at least:

Code:

#define BQ27x00_REG_STTE                        0x1c

#define BQ27x00_REG_MLTTE                        0x20

and change from:

Code:

cache.time_to_empty = bq27x00_battery_read_time(di, BQ27x00_REG_TTE);

cache.time_to_empty_avg = bq27x00_battery_read_time(di, BQ27x00_REG_TTECP);

to (note there's a swap in already present values and addition of two lines):

Code:

cache.time_to_empty = bq27x00_battery_read_time(di, BQ27x00_REG_TTECP);

cache.time_to_empty_avg = bq27x00_battery_read_time(di, BQ27x00_REG_TTE);

cache.time_to_empty_standby = bq27x00_battery_read_time(di, BQ27x00_REG_STTE);

cache.time_to_empty_maxload = bq27x00_battery_read_time(di, BQ27x00_REG_MTTE);

which would also require to change bq27x00_reg_cache struct and few other places in code of course, that's only the concept...

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

please refer to
http://maemo.cloud-7.de/maemo5/usr/l.../bq27k-detail2
and
http://maemo.cloud-7.de/maemo5/usr/l...bin/bq27200.sh

It's pretty clear i'd think.

( max load is exactly that: the maximum current the chip "ever" seen. Likewise S* are the "Standby" values last seen, where standby is defined as a situation with any current less than a certain self-adjusting threshold [see "ISLC Initial Standby Load Current"] of around some tens of mA - this value is useful to determine the device's power consumption while it's *not* been busy lately to read out the chip )
/j

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

Updated pre release version of kp52. DEB packages are on same URLs.

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

Quote:

Originally Posted by pali (Post 1292690)

Updated pre release version of kp52. DEB packages are on same URLs.

changelog pretty please? :)

edit: found one of the changes: http://talk.maemo.org/showthread.php...82#post1292682 and next post

bq27x00_battery kernel driver - fixed error which caused it to not report capacity in % or last full capacity if CI flag is set (when battery is not calibrated) while reporting current mAh also when CI flag is set (which messed up e.g. new battery status menu plugin)

@down: thank you, I will bookmark that link ;)

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

Pali does the kp 52 will support NTFS read and write access
currently it only supports read access

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

@Sourav.dubey, as I know there is no stable kernel driver for ntfs write (correct me if yes). At least in 2.6.28 there isnt. If you really want to enable experimental write support mount with "-o rw".

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

:mad: So I have removed cherry and I have installed notmynoia, however it appears that my n900 is still sending premium rate sms messages to egypt and romania:

11/10/12 10:45 PM SMOINT ROMANIA
(S)
0000000000l
11/10/12 10:45 PM SMOINT EGYPT
(S)
0000000000l
11/10/12 09:56 PM SMOINT EGYPT
(S)
0000000000l
11/10/12 09:56 PM SMOINT EGYPT
(S)
0000000000l
11/10/12 07:27 PM SMOINT EGYPT
(S)
0000000000l
11/10/12 07:27 PM SMOINT EGYPT
(S)
0000000000l

I know this is a separate discussion but I sense that there are members who peer over this thread that would be of great help for trying to find which package/application is doing this. Does anyone have a good method for hunting down the application that is doing this?

What tools would one suggest? lsof? Is there a stealthy way I can monitor my outgoing sms messages? Because it appears that none of these text messages are being logged..

Any words of wisdom I would greatly appreciate. :)

Also here is my current process list:

ps -A
PID USER VSZ STAT COMMAND
1 root 2076 S /sbin/init
2 root 0 SW [kthreadd]
3 root 0 SW [ksoftirqd/0]
4 root 0 SW [events/0]
5 root 0 SW [khelper]
6 root 0 SW [kblockd/0]
7 root 0 SW [cqueue]
8 root 0 SW [twl4030-irqchip]
9 root 0 SW [twl4030-irq]
10 root 0 SW [omap2_mcspi]
11 root 0 SW [ksuspend_usbd]
12 root 0 SW [khubd]
13 root 0 SW [pdflush]
14 root 0 SW [pdflush]
15 root 0 SW [kswapd0]
16 root 0 SW [aio/0]
26 root 0 SW [ubi_bgt0d]
27 root 0 SW [kondemand/0]
28 root 0 SW [ubifs_bgt0_0]
107 root 1664 S /sbin/udevd --daemon
281 root 0 SW [vibra]
460 root 0 SW [bluetooth]
502 root 0 SW [nokia-av]
503 root 0 SW [kmmcd]
533 root 0 SW [mboxd/0]
562 root 0 DW [wl12xx]
588 root 0 SW [mmcqd]
609 root 0 SW [mmcqd]
695 root 1776 S < /sbin/dsme -p /usr/lib/dsme/libstartup.so
703 root 3848 S /usr/sbin/sshd -D
709 root 8216 S /sbin/dsme-server -p /usr/lib/dsme/libstartup.so
721 root 0 SW [file-storage-ga]
730 root 3376 S /usr/sbin/bme_RX-51
743 messageb 3436 S < /usr/bin/dbus-daemon --system --nofork
751 root 3376 S /usr/libexec/n900-fmrx-enabler --nodaemon
753 root 2428 S /usr/sbin/sscd -f
757 root 4716 S /usr/sbin/alsaped -p 4 -f /usr/share/policy/etc/current/alsaped.conf
773 root 15220 S /usr/sbin/omap3camd -d /dev/video0 -f /tmp/omap3camd0-installed
780 pulse 82968 S < /usr/bin/pulseaudio --system --high-priority
785 haldaemo 4564 S /usr/sbin/hald --verbose=no --daemon=no --use-syslog
787 root 8108 S /usr/sbin/ohmd --no-daemon
790 root 3396 S /usr/sbin/csd -m -p call -p gprs -p info -p net -p sim -p simpb -p sms -p ss
794 root 3424 S /usr/sbin/sms-manager
800 root 3476 S /usr/sbin/sysinfod --system
805 root 5572 S < /sbin/mce --force-syslog
809 root 3328 S hald-runner
810 root 3636 S /usr/sbin/wappushd -b
812 root 3988 S /usr/lib/gconf2/gconfd-2
828 root 0 SW [sgx_perf]
832 root 1528 S /usr/sbin/dsp-manager
840 haldaemo 3496 S {hald-addon-omap} hald-addon-gpio: listening on /sys/devices/platform/gpio-switch/slide/state /sys/devices/platform/gpio-switch/sleep_ind/state /sy
843 root 14976 S /usr/sbin/omap3camd -d /dev/video1
849 haldaemo 3088 S {hald-addon-usb-} hald-addon-usb-cable: listening on /sys/devices/platform/musb_hdrc/usb1/../mode
854 root 0 SW [kjournald]
862 root 3420 S /usr/lib/hal/hald-addon-generic-backlight
863 root 0 SW [SGXOSTimer/0]
864 root 0 SW [sgx_misr]
875 root 22480 S < /usr/bin/Xorg -logfile /tmp/Xorg.0.log -logverbose 1 -nolisten tcp -noreset -s 0 -core
878 root 3424 S {hald-addon-inpu} hald-addon-input: Listening on /dev/input/event3 /dev/input/event1 /dev/input/event0 /dev/input/event2
895 haldaemo 3088 S {hald-addon-mmc} hald-addon-mmc: listening on /sys/class/mmc_host/mmc0/cover_switch
899 root 3628 S /usr/bin/clockd
908 root 3416 S /usr/lib/hal/hald-addon-als
909 root 3480 S /usr/lib/hal/hald-addon-bme
911 root 3436 S /usr/lib/hal/hald-addon-cpufreq
923 root 25200 S /usr/bin/signond
942 root 3412 S /usr/sbin/bluetoothd -n
965 user 2832 S dbus-launch --exit-with-session
969 user 3012 S < /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
983 user 42932 S /usr/bin/maemo-xinput-sounds
990 user 3344 S /usr/bin/profiled
993 user 3324 S /usr/bin/ohm-session-agent
999 root 0 SW< [krfcommd]
1025 user 23080 S /usr/bin/maemo-launcher --send-app-died --booster gtk,cpp --quiet --daemon
1026 user 3848 S /usr/sbin/alarmd
1030 user 12672 S /usr/lib/sapwood/sapwood-server
1032 user 27512 S /usr/bin/systemui
1057 root 1972 S /usr/bin/iphbd
1059 user 6016 S /usr/lib/gvfs/gvfsd
1073 user 6512 S /usr/lib/gvfs/gvfs-hal-volume-monitor
1090 user 5540 S /usr/bin/mission-control
1096 user 23452 S < /usr/bin/hildon-sv-notification-daemon
1101 user 4692 S /usr/lib/telepathy/telepathy-ring
1140 user 3936 S /usr/bin/hildon-status-menu
1142 user 98.6m S /usr/bin/hildon-status-menu
1143 user 3936 S /usr/bin/camera-ui
1144 user 55180 S /usr/bin/camera-ui
1146 user 3936 S /usr/bin/hildon-home
1148 user 3936 S /usr/bin/hildon-desktop
1150 user 30656 S /usr/bin/hildon-home
1151 user 71044 S /usr/bin/hildon-desktop
1154 user 8368 S /usr/libexec/gnome-vfs-daemon
1166 user 23224 S /usr/lib/evolution-data-server/e-addressbook-factory
1180 root 4136 S /usr/sbin/wlancond
1182 root 7932 S /usr/bin/location-proxy --no-detach
1183 root 20812 S < /usr/bin/tonegend -s ansi -b 100 -r 20 -D module-stream-restore.id=x-maemo-key-pressed -I media.role=phone,module-stream-restore.id=sink-input-by-m
1186 root 2624 S /usr/bin/app-detect -p 1
1190 nobody 2160 S /usr/sbin/dnsmasq -k -i lo -a 127.0.0.1 -z
1211 root 13200 S python /opt/smscon/smscon_daemon
1246 user 4616 S /usr/bin/clipboard-manager
1247 root 4544 S /usr/sbin/icd2 -l2
1248 user 31784 S N /usr/lib/tracker/trackerd
1255 root 5616 S /usr/sbin/hulda
1257 user 3936 S /usr/bin/osso-connectivity-ui-conndlgs
1264 user 28392 S /usr/bin/osso-connectivity-ui-conndlgs
1265 root 5616 S /usr/sbin/hulda
1266 user 17584 S /usr/bin/hildon-input-method
1272 user 3212 S /usr/lib/obex/obexd --nodaemon --opp --ftp --pcsuite --symlinks --tty /dev/ttyGS0 --root .obex-root --root-setup /usr/bin/obex-root-setup --capabil
1273 user 42672 S /usr/sbin/browserd -d
1288 user 39240 S < /usr/bin/mafw-dbus-wrapper mafw-gst-renderer
1292 user 7920 S /usr/bin/mafw-dbus-wrapper mafw-iradio-source
1303 user 16916 S /usr/bin/mafw-dbus-wrapper mafw-tracker-source
1308 user 9260 S /usr/bin/mafw-dbus-wrapper mafw-upnp-source
1310 user 1524 S /usr/sbin/temp-reaper
1328 user 4852 S /usr/sbin/maesync_controller
1339 root 8236 S /usr/sbin/ke-recv
1340 user 18232 S /usr/bin/syncd
1348 user 24512 S /usr/bin/osso-abook-home-applet
1390 user 14116 S /usr/libexec/hildon-thumbnailerd
1472 user 3936 S /usr/bin/osso-addressbook
1473 user 27472 S /usr/bin/osso-addressbook
1476 user 3936 S /usr/bin/rtcom-call-ui
1482 user 29944 S /usr/bin/rtcom-call-ui
1484 user 3936 S /usr/bin/rtcom-messaging-ui
1485 user 28236 S /usr/bin/rtcom-messaging-ui
1486 user 70260 S /usr/sbin/browserd -s 1486 -n RTComMessagingServer
1489 user 3936 S /usr/bin/browser
1490 user 29292 S /usr/bin/browser
1492 user 3936 S /usr/bin/image-viewer
1493 user 35144 S /usr/bin/image-viewer
1496 user 3936 S /usr/bin/Calendar
1497 user 28260 S /usr/bin/Calendar
1508 user 3936 S /usr/bin/modest
1509 user 45912 S /usr/bin/modest
1641 user 64308 S /usr/sbin/browserd -s 1641 -n browserui
1738 user 3936 S /usr/bin/osso-xterm
1739 user 30200 S /usr/bin/osso-xterm
1740 user 2792 S gnome-pty-helper
1741 user 2912 S -sh
1743 root 2836 S {gainroot} /bin/sh /usr/sbin/gainroot
1744 root 4772 S /bin/bash
1748 user 9864 S N /usr/lib/tracker/tracker-indexer
1755 root 15964 S /usr/bin/eapd
1759 root 1628 S /sbin/udhcpc -i wlan0 -s /etc/udhcpc/libicd_network_ipv4.script -H Nokia-N900 -f -R 15
1826 root 6456 S {sshd} sshd: root@pts/1
1828 root 2912 S -sh

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

@zitstif,

This is really not the appropriate thread to discuss your problems. Please open a new one so as not to "pollute" the kernel-power thread (I can assure you that kernel-power has nothing, absolutely nothing, to do with your SMSs).

Just to make it a bit quicker, I can also tell you that your ps output shows nothing suspicious. It is probably a program being executed on a schedule or in response to some dbus commands.

I suggest that, in the new thread you will open, you post the output of "dpkg -l", which will list the packages you have installed. The list will be long, but makes for a nice reading.

The obvious additional question is: have you installed anything from non-standard repositories? since when is this happening? how to you know your N900 is sending those premium SMS? (this "11/10/12 09:56 PM SMOINT EGYPT" you keep posting, where do you see that?). Are you located in Egypt and/or Romania? is your SIM card from one of those countries? have you bought anything using some sort of "charge it on my phone bill" option?

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

In your ps output I see unknown process:

Code:

1211 root 13200 S python /opt/smscon/smscon_daemon

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

Quote:

Originally Posted by pali (Post 1293313)

In your ps output I see unknown process:

Code:

1211 root 13200 S python /opt/smscon/smscon_daemon

well spotted! :)

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

What do you mean unknown? That's just smscon: http://talk.maemo.org/showthread.php...ghlight=smscon

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

Quote:

Originally Posted by ade (Post 1293319)

What do you mean unknown? That's just smscon: http://talk.maemo.org/showthread.php...ghlight=smscon

Its unknown for me :-) not present in default maemo5. But please move this discussion into other thread...

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

Moved:

http://talk.maemo.org/showthread.php...34#post1293434

Thanks for your help so far. :)

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

what about dsp freq unlock?also bleeding edge drivers won't work:(

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

hello
i need help with kernel 51
i have installed power 51 and it worked fine.
but after installing multiboot and nitdroid kernel the kp51 is not loading and cleven is not working.
suggest me any way to remove multiboot, multiboot kernel and nitdroid kernel.
i have searched TMO but want a simple way.
pls.
thankyou

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

root
apt-get purge multiboot
Y

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

I want to remove Kernel power using the N900 menu entry but it doesn't work. The wifi is on but it gives me the error "Error during uninstallion. Cannot Install Nokia Kernel" and then it exits. I used the command apt-get install --reinstall -y kernel kernel-flasher but even that won't work. I get the error, " There are problems and -y was used without --force-yes" I am stuck here. Pali says in his first post that it can't removed without the menu entry. The menu entry isn't working. Is there any work around? Thanks.

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

Quote:

Originally Posted by ApexBeat (Post 1297952)

http://wiki.maemo.org/Kernel_Power#U...g_kernel-power

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

When is kp52 coming to the repos? Im using kp52 since weeks without problems.

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

How can i install kp52? Any link for download?
Thanks :)