Re: [Server-devel] [ejabberd] mnesia corruption with concurrent ejabberdctl usage
On Tue, 2009-12-29 at 19:39 +0100, Martin Langhoff wrote: On Tue, Dec 29, 2009 at 6:27 PM, Martin Langhoff martin.langh...@gmail.com wrote: I am cooking an RPM but you can see, critique and/or use the patches I apply to ejabberdctl.template and the resulting script. RPM spec file patch at http://dev.laptop.org/git/users/martin/ejabberd-xs.git/commit/?id=5f257b944d71c318bcf25a6da92ca60f4bc42c83 My style of handling the RPM is a bit of a hack on top of the Fedora/RH spec files, but should be easy to review cherry pick into the Fedora spec. cheers, m Hello Martin, I'm wondering, are this fixes already included in any XS OS release?. The folk here want to upgrade the XS to the newest version, and we want to start using Moodle. If the answer is no, I assume I just need to update using yum (I recall you wrote about it in a previous e-mail. Cheers, ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: possible progress on XO-1 camera issues
Hello Everybody, After hard debugging with Raul, we've realized that the problem was in the Geode driver. I've changed a line within the memory buffer, and it seems to work now. Looking forward to get feedback (please don't be evil, it's my first patch :-) http://oficina.paraguayeduca.org/~crodas/0045-Fixed-Out-of-memory-error-on-XO-1.patch Cheers On Wed, 2009-12-23 at 13:29 +0100, Tomeu Vizoso wrote: On Wed, Dec 23, 2009 at 02:42, James Cameron qu...@laptop.org wrote: On Tue, Dec 22, 2009 at 09:42:54PM -0300, Raul Gutierrez Segales wrote: Is it cheating to change the screen depth? I change it to 24 bpp and now cheese and totem work. Changes to /etc/X11/xorg.conf: That's odd. We changed the screen depth quite a bit with XO-1.5 development, I wonder if those changes accidentally reached XO-1 development builds? (For XO-1.5 we needed the firmware, the kernel, and X to all agree on depth so that suspend and resume would work nicely). My best guess right now is that something that was able to return a 16bpp surface is failing to do so in F11, but is manifesting itself as absurd dimensions because the caller code is not checking for that specific failure. Regards, Tomeu -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: possible progress on XO-1 camera issues
Hello Peter, On Thu, 2009-12-17 at 08:45 +, Peter Robinson wrote: On Wed, Dec 16, 2009 at 7:36 PM, César D. Rodas cro...@paraguayeduca.org wrote: Hi, The problem with the camera seems to be the xf86-video-geode package. The cafe_ccic module is loaded automatically. Cheese and recordactivity crashed right before show any picture. Then I tested remotely with ssh -X and it worked for olpc and root user and it works. This test was done with: * XO-1 kernel: 2.6.31_xo1-20091214.1334.1.olpc.49c30d0 * os10 Even if it works remotely, there are a lots of warning messages on the /var/log/messages: The gstreamer pipeline i used on the command line to take a photo is: gst-launch-0.10 v4l2src ! ffmpegcolorspace ! pngenc ! filesink location=foo.png It works perfectly fine, thanks for your help. It seems to be that X is having a hard time displaying the video feed for some reason I can't discover (yet). I took a look at the /var/log/Xorg.0.log file (while attempting to run cheese) and it said: Could not allocate memory for the video That's why it worked remotely before (apparently). I also tried loading extra modules in xorg.conf (the ones that are loaded in the XO-1.5 config) but no go. I'm looking forward to read clues about how to fix it. Regards, It basically takes png file. Regards, Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: possible progress on XO-1 camera issues
Hi Peter, On Thu, 2009-12-17 at 14:18 +, Peter Robinson wrote: Hi César, The problem with the camera seems to be the xf86-video-geode package. The cafe_ccic module is loaded automatically. Cheese and recordactivity crashed right before show any picture. Then I tested remotely with ssh -X and it worked for olpc and root user and it works. This test was done with: * XO-1 kernel: 2.6.31_xo1-20091214.1334.1.olpc.49c30d0 * os10 Even if it works remotely, there are a lots of warning messages on the /var/log/messages: The gstreamer pipeline i used on the command line to take a photo is: gst-launch-0.10 v4l2src ! ffmpegcolorspace ! pngenc ! filesink location=foo.png It works perfectly fine, thanks for your help. It seems to be that X is having a hard time displaying the video feed for some reason I can't discover (yet). I took a look at the /var/log/Xorg.0.log file (while attempting to run cheese) and it said: Could not allocate memory for the video That's why it worked remotely before (apparently). I also tried loading extra modules in xorg.conf (the ones that are loaded in the XO-1.5 config) but no go. I'm looking forward to read clues about how to fix it. It sounds suspiciously like a Xv issue. That could be anything from a missing kernel module to a X driver bug. Out of interest can you play video using totem? Possibly record a video using a XO-1 with the working 802 build and see if it will play on one with the F11 build. That would rule out that issue, or possibly we could craft up a gstreamer pipeline that takes the output of the camera and displays it on the screen. Let me know how you go with the totem test and then we'll see where we can take it from there, if that works I can work out what the pipeline would need to be to test that raw. Well, I've tried what you've suggested me, and it has the same problem. $ totem /media/34F7-79FD/11-Music-Painter\ \(medium\).ogg Gdk-ERROR **: The program 'totem' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAlloc (insufficient resources for operation)'. (Details: serial 101 error_code 11 request_code 131 minor_code 19) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) aborting... aborted Is this output helping somehow? Is there a way I can help out to fix it? Regards, Regards, Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: possible progress on XO-1 camera issues
Hello, On Thu, 2009-12-17 at 15:11 +, Peter Robinson wrote: On Thu, Dec 17, 2009 at 2:47 PM, César D. Rodas cro...@paraguayeduca.org wrote: Hi Peter, On Thu, 2009-12-17 at 14:18 +, Peter Robinson wrote: Hi César, The problem with the camera seems to be the xf86-video-geode package. The cafe_ccic module is loaded automatically. Cheese and recordactivity crashed right before show any picture. Then I tested remotely with ssh -X and it worked for olpc and root user and it works. This test was done with: * XO-1 kernel: 2.6.31_xo1-20091214.1334.1.olpc.49c30d0 * os10 Even if it works remotely, there are a lots of warning messages on the /var/log/messages: The gstreamer pipeline i used on the command line to take a photo is: gst-launch-0.10 v4l2src ! ffmpegcolorspace ! pngenc ! filesink location=foo.png It works perfectly fine, thanks for your help. It seems to be that X is having a hard time displaying the video feed for some reason I can't discover (yet). I took a look at the /var/log/Xorg.0.log file (while attempting to run cheese) and it said: Could not allocate memory for the video That's why it worked remotely before (apparently). I also tried loading extra modules in xorg.conf (the ones that are loaded in the XO-1.5 config) but no go. I'm looking forward to read clues about how to fix it. It sounds suspiciously like a Xv issue. That could be anything from a missing kernel module to a X driver bug. Out of interest can you play video using totem? Possibly record a video using a XO-1 with the working 802 build and see if it will play on one with the F11 build. That would rule out that issue, or possibly we could craft up a gstreamer pipeline that takes the output of the camera and displays it on the screen. Let me know how you go with the totem test and then we'll see where we can take it from there, if that works I can work out what the pipeline would need to be to test that raw. Well, I've tried what you've suggested me, and it has the same problem. $ totem /media/34F7-79FD/11-Music-Painter\ \(medium\).ogg Gdk-ERROR **: The program 'totem' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAlloc (insufficient resources for operation)'. (Details: serial 101 error_code 11 request_code 131 minor_code 19) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) aborting... aborted Is this output helping somehow? Is there a way I can help out to fix it? Yes, it looks like an X bug. I had a similar issue previously with another X driver. To get a proper backtrace using GDB can you do the following, this will then allow us to file a bug. Run gdb and then from the gdb prompt run the following commands. If gdb isn't installed you'll need to do a 'yum install -y gdb'. You'll probably need to install quite a few debuginfo packages to ensure we get a useful backtrace but if you post the backtrace first we can work out what we need. (gdb) exec-file totem --sync (gdb) break gdk_x_error() (gdb) r You'll then get totem come up. Try and play the video as before and you'll have it crash. The run the following with gdb (gdb) thread apply all bt and paste the complete output into a file and put it somewhere I can see it (it might be somewhat large). You can see a sample one from an issue I had with the nouveau driver previously here https://bugzilla.redhat.com/attachment.cgi?id=369702 GDB complained saying it was missing some packages such as debuginfo-install totem-2.26.5-1.fc11.i586, but I think it will have not side effect since I don't want to debug Totem, I want to debug X through it. The output file is here http://oficina.paraguayeduca.org/~crodas/X-totem-debug.log Is it useful? What else can we do in order to hunt this bug? Regards, And we'll see where we need to go from there. Cheers, Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: possible progress on XO-1 camera issues
Hi Peter, On Thu, 2009-12-17 at 16:33 +, Peter Robinson wrote: I'm looking forward to read clues about how to fix it. It sounds suspiciously like a Xv issue. That could be anything from a missing kernel module to a X driver bug. Out of interest can you play video using totem? Possibly record a video using a XO-1 with the working 802 build and see if it will play on one with the F11 build. That would rule out that issue, or possibly we could craft up a gstreamer pipeline that takes the output of the camera and displays it on the screen. Let me know how you go with the totem test and then we'll see where we can take it from there, if that works I can work out what the pipeline would need to be to test that raw. Well, I've tried what you've suggested me, and it has the same problem. $ totem /media/34F7-79FD/11-Music-Painter\ \(medium\).ogg Gdk-ERROR **: The program 'totem' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAlloc (insufficient resources for operation)'. (Details: serial 101 error_code 11 request_code 131 minor_code 19) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) aborting... aborted Is this output helping somehow? Is there a way I can help out to fix it? Yes, it looks like an X bug. I had a similar issue previously with another X driver. To get a proper backtrace using GDB can you do the following, this will then allow us to file a bug. Run gdb and then from the gdb prompt run the following commands. If gdb isn't installed you'll need to do a 'yum install -y gdb'. You'll probably need to install quite a few debuginfo packages to ensure we get a useful backtrace but if you post the backtrace first we can work out what we need. (gdb) exec-file totem --sync (gdb) break gdk_x_error() (gdb) r You'll then get totem come up. Try and play the video as before and you'll have it crash. The run the following with gdb (gdb) thread apply all bt and paste the complete output into a file and put it somewhere I can see it (it might be somewhat large). You can see a sample one from an issue I had with the nouveau driver previously here https://bugzilla.redhat.com/attachment.cgi?id=369702 GDB complained saying it was missing some packages such as debuginfo-install totem-2.26.5-1.fc11.i586, but I think it will have not side effect since I don't want to debug Totem, I want to debug X through it. The output file is here http://oficina.paraguayeduca.org/~crodas/X-totem-debug.log Is it useful? What else can we do in order to hunt this bug? Its a start. We need (at least) also the following debuginfo packages. So a 'yum install -y gstreamer-debuginfo gstreamer-plugins-base-debuginfo gstreamer-debuginfo glib2-debuginfo totem-pl-parser-debuginfo glibc-debuginfo gtk2-debuginfo libX11-debuginfo xorg-x11-server-debuginfo' Thanks for the clue, I've installed those missing packages and I re-run the debugger, http://oficina.paraguayeduca.org/~crodas/X-totem-debug-1.log Please let me know if I need to do something else to debug better. That should fill out the rest of the debuginfo to make the back trace more useful. Regards, Peter Regards, ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: possible progress on XO-1 camera issues
Hi, The problem with the camera seems to be the xf86-video-geode package. The cafe_ccic module is loaded automatically. Cheese and recordactivity crashed right before show any picture. Then I tested remotely with ssh -X and it worked for olpc and root user and it works. This test was done with: * XO-1 kernel: 2.6.31_xo1-20091214.1334.1.olpc.49c30d0 * os10 Even if it works remotely, there are a lots of warning messages on the /var/log/messages: Dec 16 19:09:35 xo-37-a0-b9 kernel: [ 1218.250879] cafe1000-ccic :00:0c.2: Frame overrun on 1, frames lost Dec 16 19:09:36 xo-37-a0-b9 kernel: [ 1218.284198] cafe1000-ccic :00:0c.2: Frame overrun on 2, frames lost Dec 16 19:09:36 xo-37-a0-b9 kernel: [ 1218.317524] cafe1000-ccic :00:0c.2: Frame overrun on 0, frames lost Dec 16 19:09:36 xo-37-a0-b9 kernel: [ 1218.350843] cafe1000-ccic :00:0c.2: Frame overrun on 1, frames lost Dec 16 19:09:36 xo-37-a0-b9 kernel: [ 1218.384170] cafe1000-ccic :00:0c.2: Frame overrun on 2, frames lost Dec 16 19:09:36 xo-37-a0-b9 kernel: [ 1218.417498] cafe1000-ccic :00:0c.2: Frame overrun on 0, frames lost Dec 16 19:09:36 xo-37-a0-b9 kernel: [ 1218.450817] cafe1000-ccic :00:0c.2: Frame overrun on 1, frames lost Dec 16 19:09:36 xo-37-a0-b9 kernel: [ 1218.484134] cafe1000-ccic :00:0c.2: Frame overrun on 2, frames lost Dec 16 19:09:36 xo-37-a0-b9 kernel: [ 1218.517459] cafe1000-ccic :00:0c.2: Frame overrun on 0, frames lost Dec 16 19:09:41 xo-37-a0-b9 kernel: [ 1223.282572] __ratelimit: 142 callbacks suppressed Dec 16 19:09:41 xo-37-a0-b9 kernel: [ 1223.282599] cafe1000-ccic :00:0c.2: Frame overrun on 2, frames lost Dec 16 19:09:41 xo-37-a0-b9 kernel: [ 1223.315900] cafe1000-ccic :00:0c.2: Frame overrun on 0, frames lost Dec 16 19:09:41 xo-37-a0-b9 kernel: [ 1223.349218] cafe1000-ccic :00:0c.2: Frame overrun on 1, frames lost Dec 16 19:09:41 xo-37-a0-b9 kernel: [ 1223.382540] cafe1000-ccic :00:0c.2: Frame overrun on 2, frames lost Dec 16 19:09:41 xo-37-a0-b9 kernel: [ 1223.415857] cafe1000-ccic :00:0c.2: Frame overrun on 0, frames lost Dec 16 19:09:41 xo-37-a0-b9 kernel: [ 1223.449178] cafe1000-ccic :00:0c.2: Frame overrun on 1, frames lost Dec 16 19:09:41 xo-37-a0-b9 kernel: [ 1223.480217] cafe1000-ccic :00:0c.2: Frame overrun on 2, frames lost Dec 16 19:09:41 xo-37-a0-b9 kernel: [ 1223.510492] cafe1000-ccic :00:0c.2: Frame overrun on 0, frames lost Dec 16 19:09:41 xo-37-a0-b9 kernel: [ 1223.549157] cafe1000-ccic :00:0c.2: Frame overrun on 1, frames lost Dec 16 19:09:41 xo-37-a0-b9 kernel: [ 1223.582476] cafe1000-ccic :00:0c.2: Frame overrun on 2, frames lost Regards, On Sat, 2009-12-12 at 20:16 +, Daniel Drake wrote: Hi, Jon Corbet's been working on the XO-1.5 camera driver for us, and while doing so he found a V4L2 bug which is probably one of the reasons that we're having problems with XO-1 camera on all post-8.2 builds. The workaround is to build the sensor driver into the kernel, and the camera driver as a module. I've made the equivalent change for the kernel that has been built here: http://xs-dev.laptop.org/~dsd/repos/f11-xo1/kernel-2.6.31_xo1-20091211.1834.1.olpc.813348c.i586.rpm Untested, just wanted to get the word out. Note that you may have to load the camera driver (cafe_ccic) manually, if it doesn't automatically get loaded. Word is going round that on a SoaS build for XO (which uses something close to OLPC's 2.6.30 kernel, I think), someone recently managed to capture a photo from the command line. If someone is up for a small task, it would be good to start changing these words going round to some actual solid information. Anyone want to head up these efforts and to start http://wiki.laptop.org/go/Reviving_XO1_camera ? At the very least it would be nice to have some solid documentation on where the problem is (and isn't). Is it in ov7670, cafe_ccic, v4l2, gstreamer, xf86-video-geode, or..? How can you tell? Does the above kernel help? What's the exact command you can use on F12 SoasXO to take a photo? What's the corresponding error if you do that on F11? etc. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: a trac milestone for F11-for-XO1 work
Hello, I'm Cesar Rodas from Paraguay, as you might notice I'm new here, please be nice if I say something wrong :-) On Mon, 2009-12-14 at 22:33 +, Daniel Drake wrote: Hi, Just wanted to point out that there is a new 1.0-software-future milestone in trac. I encourage those of you who are working on F11-for-XO1 to use that to coordinate on the outstanding issues. I was talking to Raul and he told me we could help adding tickets for the XO1 (from the mailing list, and if we find some bugs). Also, we can help trying (as hard as we can) to hunt down those bugs. We're interested to help because we have ~4000 XO1 running OS-8.2 and we want to upgrade to Fedora11+Sugar0.84 ASAP (in less than month). The disclaimer is that if someone puts a ticket there which additionally applies to XO-1.5, we might move it to an XO-1.5 milestone. But if we do that, it's probably because we're going to fix it soon, so hopefully you won't complain :) Also, once we get the XO-1.5 initial software release finished, I plan to rework our build system, and I'll make it so that both XO-1 and XO-1.5 builds can be made from the same codebase. Thanks! Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel Best regards, crodas ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Some testing notes for OS10 for the XO-1
Hello Paul, On Mon, 2009-12-14 at 02:43 -0500, Paul Fox wrote: smparrish will correct me if i'm wrong, but i believe the release you're testing runs powerd, not ohmd. the presence of the control panel, and its inability to control powerd's behavior, is a bug, or an unimplemented feature -- take your pick. (you can disable powerd if you wish, with initctl stop powerd, and move /etc/events.d/powerd elsewhere. then start ohmd as you did below.) I did it in a XO-1 and it's still having issues with the resume. I've looked at the /var/log/messages and dmesg and there is nothing weird there. Can you please give a clue about what should I do about it? Regards, i'm curious about the keyboard/mouse not waking things up properly, but i have zero time to look at it currently. to prevent powerd from suspending the laptop, edit /etc/powerd/powerd.conf, and adjust the timeout s to something big, like 9. paul philipp wrote: Switching off pm doesn't work (with control panel GUI or command): [o...@xo-11-08-d6 logs]$ sugar-control-panel -s automatic_pm off /usr/lib/python2.6/site-packages/sugar/util.py:25: DeprecationWarning: the sha module is deprecated; use the hashlib module instead import sha sugar-control-panel: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.ohm was not provided by any .service files After starting ohmd with sudo service ohmd start (per default service ohmd is off for all runlevels) it is possible to switch off automatic_pm (at least no error anymore), but it still suspends after some time and with resume is the same problem as before. Is ohmd supposed to be on or off? On 12/12/2009 01:55 AM, Steven M. Parrish wrote: If you are going to try out OS10 for the XO-1 here are a few things that need testing. Does it boot consistently into Sugar? Gnome? Any strange lockups? If so what were you doing? Can you upgrade packages using yum update from the command line? Does sound work? Can you suspend? Does it wake up? Please report any issues you have. Steven ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
