python 2.5-gtk2
I noticed in the latest python2.5-gtk2 package (OS2008 chinook) hasn't included glade.so. Am I missing something out? The previous version of the package had it. -Alex ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
I recommend using the garbage collector module manually to override the defaults. Python for some reason doesn't reclaim memory fast. So if you put in your code: import gc gc.collect() (at the right spots, probably after the file chooser dialog and after some memory intensive tasks). You should notice a lot of memory being free'd up. -Alex On Sunday 30 December 2007 05:20:34 pm Jayesh Salvi wrote: > Hi, > > I am porting a pygtk application to maemo. It works alright, but I > noticed that it was consuming lot of memory, preventing me from opening > other applications. > > When I investigated, I found that my python application was forking 4 > more instances of itself, each one identical in memory footprint. Thus > they consumed nearly 60-70% of my memory. > > So I ran my application using pdb and narrowed down to a code segment > that was leading to multiple instances of the process. It turned out > that when I call run() on hildon.fileChooserDialog object, the dialog > opens and at that moment in the "top" I see 4 more instances being > forked. > > I fail to understand this behavior. I replaced the hildon widgets by > pure gtk widgets and I see similar behavior, except that 2 more > instances get forked. Also when using gtk.FileChooserDialog, these new > instances get created in the instantiation of the dialog object, rather > than call to run(). (code included below) > > So to further explore the problem, I ran same application on my desktop > with gtk widgets. But I verified that when fileChooserDialog's run is > called, there are no additional instances of python. > > I am running this code on n770, with 2007 HE and python2.5 runtime. My > application code is pure python and not using any additional libraries. > In fact following would be a simpler version of it to reproduce the > problem: > > import gtk > import hildon > > #window = gtk.Window(gtk.WINDOW_TOPLEVEL) > > #fileChooser = gtk.FileChooserDialog( > # title="Choose a photo to publish", > # buttons=(gtk.STOCK_CANCEL, gtk.RESPONSE_CANCEL, > # gtk.STOCK_OK, gtk.RESPONSE_OK)) > > fileChooser = hildon.FileChooserDialog( > window,gtk.FILE_CHOOSER_ACTION_OPEN) > > > result = fileChooser.run() > > if result == gtk.RESPONSE_OK: > print fileChooser.get_filename() > > Do you have any tips, as to what might be going wrong? > > This problem is fatal at least on n770 - it will trigger low memory > message when other applications are used on the side. > > Any help will be useful. > > Thanks, ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Kismet on N800 stops running after 1-2 minutes
That's not it, the main problem is not that the device stops receiving packets, it's the corruption of the packet content it does. As a note you can control power management by issuing: iwconfig wlan0 power off -Alex On Friday 14 December 2007 11:15:51 am Michael Wiktowy wrote: > On Dec 13, 2007 8:24 PM, Jaeyeon Jung <[EMAIL PROTECTED]> wrote: > > Any other suggestions? Basically, Kismet runs fine for a couple of > > minutes and the packet counter stops increasing (the application is > > still running and the elapsed time is updated but basically sniffing > > stops working). > > As I understand it, this is more of an issue with the power-saving > features of the tablet. In monitor mode, the OS doesn't think that the > wireless chip is being used so it puts it to sleep. I believe that > keeping it plugged into the charger while you scan works. Not an ideal > work-around but might be enough for what you want to do. > > /Mike > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N810 Resets
Hi, I think there was a bit of a confusion here, I was using the pre-bundled internal card shipped with the device with the default filesystem (jffs2). (No added MMC card) Anyway the problem has been solved. As you had originally suggested there was a peak point at which my application was trying to use 195MB of memory and that's when the reboot of the device occurred. I fixed that by manually controlling pythons garbage collector to force it to free memory. Thanks, Alex On Friday 14 December 2007 06:20:01 am you wrote: > Hi, > > ext Alex Iliadis wrote: > > Hi Eero, > > > > On Thursday 13 December 2007 10:16:09 am you wrote: > >> ext Alex Iliadis wrote: > >>> On Thursday 13 December 2007 02:25:58 am you wrote: > >>>> ext Alex Iliadis wrote: > >>> > >>> I scrolled a bit further down though and I noticed the following: > >>> > >>> Dec 13 09:36:20 Nokia-N810-42-18 kernel: [ 18.531250] mmcblk0: > >>> rw=0, want=4013848, limit=3932160 > >>> Dec 13 09:36:20 Nokia-N810-42-18 kernel: [ 18.531250] Buffer I/O > >>> error on device mmcblk0p1, logical block 501728 > >>> Dec 13 09:36:20 Nokia-N810-42-18 kernel: [ 18.531250] attempt to > >>> access beyond end of device > >> > >> Does the reboot happen if you remove the MMC? > >> > >> There was earlier some case where an application infinitely reading > >> corrupted MMC FAT file system could sometimes cause kernel panic, but > >> that should have been fixed for N810 & Chinook. > > > > I think it's an internal one bundled with the device. (I haven't > > connected any in the slot) Not sure why it's displayed as mmc, but I'm > > guessing the linux kernel identifies it as one? Maybe somehow it got > > corrupted and that's what's causing the problems? I'll try to do a > > clean flash of the system and re-run the application and let you know > > of the result. > > Reflashing doesn't do anything to the MMCs (whether it's the N810 > internal one of something that user can change). You can format it > from the file manager or from Desktop after connecting the USB cable. > > In Chinook the MMC is mounted as read-only if it's corrupted. > However if something in system is accessing it incessantly, it's > possible that this can cause some instability. > > > Btw. As everybody knows, the MicroSoft FAT file system used on > the memory cards wasn't designed to be robust. If you unplug > the USB cable without "safely remove" step, remove MMC otherwise > when it's being written, take battery out when device is on or > device HW (not SW) watchdog reboots it, the MMC FAT filesystem > will get corrupted. (These aren't a problem with the internal > JFFS2 filesystem) > > > - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Kismet on N800 stops running after 1-2 minutes
I believe it has to do with the wireless driver not working properly in monitoring mode. There are workarounds for it but they require some sort of scripting. Also the wireless driver corrupts packets in monitor mode so you may get inaccurate results sometimes. Thanks, Alex On Thursday 13 December 2007 08:24:12 pm Jaeyeon Jung wrote: > Found that others also encountered a similar problem and as someone > suggested, I increased the automatic connection search interval (to 60 > minutes) and crossed my fingers. Unfortunately, that doesn't fix the > problem. > > Any other suggestions? Basically, Kismet runs fine for a couple of > minutes and the packet counter stops increasing (the application is > still running and the elapsed time is updated but basically sniffing > stops working). > > jYj > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N810 Resets
I did a fresh install and I noticed that those messages appear anyway in every boot I do, be it recovering from a hw watchdog reboot or not. Unfortunately the problem seems to persist even after a clean install the device reboots when the application utilizes a lot of resources. I did notice however that the whole device became unresponsive, at that point my application was using 195MB of memory which was triggering a disk mapping since it had exceeded the physical memory limit. I guess it boils down into limiting the amount of memory python could use from the system since I've got no control over the memory allocation that the interpreter does. Thanks, Alex On Thursday 13 December 2007 10:16:09 am you wrote: > Hi, > > ext Alex Iliadis wrote: > > On Thursday 13 December 2007 02:25:58 am you wrote: > >> ext Alex Iliadis wrote: > > > > I scrolled a bit further down though and I noticed the following: > > > > Dec 13 09:36:20 Nokia-N810-42-18 kernel: [ 18.531250] mmcblk0: rw=0, > > want=4013848, limit=3932160 > > Dec 13 09:36:20 Nokia-N810-42-18 kernel: [ 18.531250] Buffer I/O > > error on device mmcblk0p1, logical block 501728 > > Dec 13 09:36:20 Nokia-N810-42-18 kernel: [ 18.531250] attempt to > > access beyond end of device > > Does the reboot happen if you remove the MMC? > > There was earlier some case where an application infinitely reading > corrupted MMC FAT file system could sometimes cause kernel panic, but > that should have been fixed for N810 & Chinook. > > > > - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N810 Resets
Hi Eero, On Thursday 13 December 2007 10:16:09 am you wrote: > Hi, > > ext Alex Iliadis wrote: > > On Thursday 13 December 2007 02:25:58 am you wrote: > >> ext Alex Iliadis wrote: > > > > I scrolled a bit further down though and I noticed the following: > > > > Dec 13 09:36:20 Nokia-N810-42-18 kernel: [ 18.531250] mmcblk0: rw=0, > > want=4013848, limit=3932160 > > Dec 13 09:36:20 Nokia-N810-42-18 kernel: [ 18.531250] Buffer I/O > > error on device mmcblk0p1, logical block 501728 > > Dec 13 09:36:20 Nokia-N810-42-18 kernel: [ 18.531250] attempt to > > access beyond end of device > > Does the reboot happen if you remove the MMC? > > There was earlier some case where an application infinitely reading > corrupted MMC FAT file system could sometimes cause kernel panic, but > that should have been fixed for N810 & Chinook. > > I think it's an internal one bundled with the device. (I haven't connected any in the slot) Not sure why it's displayed as mmc, but I'm guessing the linux kernel identifies it as one? Maybe somehow it got corrupted and that's what's causing the problems? I'll try to do a clean flash of the system and re-run the application and let you know of the result. -Alex > > - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N810 Resets
On Thursday 13 December 2007 02:25:58 am you wrote: > Hi, > > ext Alex Iliadis wrote: > > Yeah, it's running as root, but it's a python script. After running > > top to monitor it's memory usage it was ranging from 35-55MB. > > How much memory it was using just before the device booted? > (By consuming all memory root process can make the device so slow > that HW watchdog reboots it.) > It has to run as root since I do low level things with the interfaces. I wrote a script that monitored memory usage of the application and it seemed within bounds ranging from 28-57mb. I also extended the swap drive by the maximum and from what I've noticed in the free output the memory mapped space hasn't been utilized by it. (0mb used) > > Let me know if you need any further details. > > If running your script as normal user doesn't help > (e.g. from xterminal), You could install syslog and > give the information just before the device reboots. > > I.e. after the reboot search for the last "Bootup reason:" > message from syslog and go up from that until you see where > the kernel starts and check what happens at that time). > This is prior Bootup: Dec 13 09:36:18 Nokia-N810-42-18 kernel: [1.085937] Disabling unused clock "uart3_fck" Dec 13 09:36:18 Nokia-N810-42-18 kernel: [1.085937] Disabling unused clock "uart3_ick" Dec 13 09:36:18 Nokia-N810-42-18 kernel: [1.085937] Disabling unused clock "uart2_fck" Dec 13 09:36:18 Nokia-N810-42-18 kernel: [1.085937] Disabling unused clock "uart2_ick" Dec 13 09:36:18 Nokia-N810-42-18 kernel: [1.085937] Disabling unused clock "gpt12_fck" Dec 13 09:36:18 Nokia-N810-42-18 kernel: [1.085937] Disabling unused clock "gpt12_ick" Dec 13 09:36:18 Nokia-N810-42-18 kernel: [1.085937] Disabling unused clock "gpt11_fck" Dec 13 09:36:18 Nokia-N810-42-18 kernel: [1.093750] Disabling unused clock "gpt11_ick" Dec 13 09:36:18 Nokia-N810-42-18 kernel: [1.093750] Disabling unused clock "gpt10_fck" Dec 13 09:36:18 Nokia-N810-42-18 kernel: [1.093750] Disabling unused clock "gpt10_ick" Dec 13 09:36:18 Nokia-N810-42-18 kernel: [1.093750] Disabling unused clock "gpt9_fck" Dec 13 09:36:18 Nokia-N810-42-18 kernel: [1.093750] Disabling unused clock "gpt9_ick" Dec 13 09:36:18 Nokia-N810-42-18 kernel: [1.093750] Disabling unused clock "gpt8_fck" Dec 13 09:36:18 Nokia-N810-42-18 kernel: [1.093750] Disabling unused clock "gpt8_ick" Dec 13 09:36:18 Nokia-N810-42-18 kernel: [1.093750] Disabling unused clock "gpt7_fck" Dec 13 09:36:18 Nokia-N810-42-18 kernel: [1.093750] Disabling unused clock "gpt7_ick" Dec 13 09:36:18 Nokia-N810-42-18 kernel: [1.093750] Disabling unused clock "gpt6_fck" Dec 13 09:36:18 Nokia-N810-42-18 kernel: [1.093750] Disabling unused clock "gpt6_ick" Dec 13 09:36:18 Nokia-N810-42-18 kernel: [1.093750] Disabling unused clock "gpt5_fck" Dec 13 09:36:18 Nokia-N810-42-18 kernel: [1.093750] Disabling unused clock "gpt5_ick" Dec 13 09:36:18 Nokia-N810-42-18 kernel: [1.093750] Disabling unused clock "gpt4_fck" Dec 13 09:36:18 Nokia-N810-42-18 kernel: [1.093750] Disabling unused clock "gpt4_ick" Dec 13 09:36:18 Nokia-N810-42-18 kernel: [1.093750] Disabling unused clock "gpt3_fck" Dec 13 09:36:18 Nokia-N810-42-18 kernel: [1.093750] Disabling unused clock "gpt3_ick" Dec 13 09:36:18 Nokia-N810-42-18 kernel: [1.093750] Disabling unused clock "gpt2_fck" Dec 13 09:36:18 Nokia-N810-42-18 kernel: [1.093750] Disabling unused clock "gpt2_ick" Dec 13 09:36:18 Nokia-N810-42-18 kernel: [1.093750] Disabling unused clock "dss2_fck" Dec 13 09:36:18 Nokia-N810-42-18 kernel: [1.093750] Bootup reason: 32wd_to I scrolled a bit further down though and I noticed the following: Dec 13 09:36:20 Nokia-N810-42-18 kernel: [ 18.375000] menelaus 1-0072: Shutting off 'VIO' Dec 13 09:36:20 Nokia-N810-42-18 kernel: [ 18.390625] menelaus 1-0072: Shutting off 'VMEM' Dec 13 09:36:20 Nokia-N810-42-18 kernel: [ 18.531250] attempt to access beyond end of device Dec 13 09:36:20 Nokia-N810-42-18 kernel: [ 18.531250] mmcblk0: rw=0, want=4013848, limit=3932160 Dec 13 09:36:20 Nokia-N810-42-18 kernel: [ 18.531250] Buffer I/O error on device mmcblk0p1, logical block 501728 Dec 13 09:36:20 Nokia-N810-42-18 kernel: [ 18.531250] attempt to access beyond end of device Dec 13 09:36:20 Nokia-N810-42-18 kernel: [ 18.531250] mmcblk0: rw=0, want=4013848, limit=3932160 Dec 13 09:36:20 Nokia-N810-42-18 kernel: [ 18.531250] Buffer I/O error on device mmcblk0p1, logical block 501728 Dec 13 09:36:20
Re: N810 Resets
After running again my code and introducing a small delay factor, I noticed the following warning in ksyslogd saved logfile: WARNING: prism_softmac_frame_tx_done() returned an empty frame This was the last thing that was in the log prior the crash. I was indeed sending data at that moment so the wireless card was in use, and offcourse that's when the device rebooted on it's own. Without trying to speculate anything I believe this bug was introduced recently as my code works perfectly with the N800, latest OS2007. -Alex On Wednesday 12 December 2007 12:41:13 pm Alex Iliadis wrote: > Yeah, it's running as root, but it's a python script. After running top > to monitor it's memory usage it was ranging from 35-55MB. Let me know if > you need any further details. > > -Alex > > On Wednesday 12 December 2007 12:38:18 pm you wrote: > > Hi, > > > > ext Alex Iliadis wrote: > > > I suspected it was the watchdog which was doing software resets. > > > Here is the output of the results: > > > > > > /proc/bootreason > > > 32wd_to > > > > > > 32wd_to: > > > 5 > > > > ... > > > > > After that I decided to disable the lifeguard resets in the device > > > by using the flasher tool: > > > flasher --set-rd-flags=no-lifeguard-reset -R > > > > 32wd_to is the device HW watchdog reboot, not the SW watchdog one. > > > > > (side note: the device was in r&d mode in both runs) > > > > > > Unfortunately I ended up having the same exact result, the device > > > rebooted while running my python script. I also enabled core files > > > to see if it was an application crashing but that didn't turn out to > > > be the case since there were no core's generated. Furthermore I > > > installed sysklogd to see if there will be any time to save error > > > messages prior the reset but nothing useful was in the logs. I would > > > appreciate any pointers on debugging this issue. > > > > Are you running your script as root? And if yes, how much memory > > it's using? (root processes are protected from OOM-killing i.e. > > like on any Linux device, root can mess the system) > > > > > > > > - Eero > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N810 Resets
Yeah, it's running as root, but it's a python script. After running top to monitor it's memory usage it was ranging from 35-55MB. Let me know if you need any further details. -Alex On Wednesday 12 December 2007 12:38:18 pm you wrote: > Hi, > > ext Alex Iliadis wrote: > > I suspected it was the watchdog which was doing software resets. Here > > is the output of the results: > > > > /proc/bootreason > > 32wd_to > > > > 32wd_to: > > 5 > > ... > > > After that I decided to disable the lifeguard resets in the device by > > using the flasher tool: > > flasher --set-rd-flags=no-lifeguard-reset -R > > 32wd_to is the device HW watchdog reboot, not the SW watchdog one. > > > (side note: the device was in r&d mode in both runs) > > > > Unfortunately I ended up having the same exact result, the device > > rebooted while running my python script. I also enabled core files to > > see if it was an application crashing but that didn't turn out to be > > the case since there were no core's generated. Furthermore I installed > > sysklogd to see if there will be any time to save error messages prior > > the reset but nothing useful was in the logs. I would appreciate any > > pointers on debugging this issue. > > Are you running your script as root? And if yes, how much memory > it's using? (root processes are protected from OOM-killing i.e. > like on any Linux device, root can mess the system) > > > > - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
N810 Resets
I suspected it was the watchdog which was doing software resets. Here is the output of the results: /proc/bootreason 32wd_to 32wd_to: 5 lifeguard_restarts: /usr/sbin/dsp_dld -p --disable-restart -c /lib/dsp/dsp_dld_avs.conf : 3 /usr/sbin/multimediad : 3 /usr/bin/esd : 4 * /usr/sbin/wlancond : 1 /usr/bin/hildon-input-method : 4 /usr/sbin/ke-recv : 4 /usr/bin/hildon-desktop : 1 sw_rst: 3 After that I decided to disable the lifeguard resets in the device by using the flasher tool: flasher --set-rd-flags=no-lifeguard-reset -R (side note: the device was in r&d mode in both runs) Unfortunately I ended up having the same exact result, the device rebooted while running my python script. I also enabled core files to see if it was an application crashing but that didn't turn out to be the case since there were no core's generated. Furthermore I installed sysklogd to see if there will be any time to save error messages prior the reset but nothing useful was in the logs. I would appreciate any pointers on debugging this issue. Thanks, Alex ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
umac.ko
I was looking into the cx3110x driver source trying to enable the transmission of packets while the driver is set in Monitor mode (packet injection) but I found that the code imports modules from the umac module which apparently isn't included with the cx3110 source. More specifically I wanted to remove any send checks in the prism*tx* calls that are being used through the cx3110 callbacks. Is there a way that we can modify the source of the umac.ko module supplied with the N810 or N800? Thanks, Alex Iliadis ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
