Re: possible progress on XO-1 camera issues
I can (somewhat) use Record 64 on my XO-1 running Debian squeeze (*) and the latest OLPC git kernel. It doesn't work out-of-the-box (needed to recompile binary blobs) and seems to hang (**) when I try to take a photo, but the video overlay is shown. In what way does Record fail for you, exactly? (*) installed using DebXO, but now an up-to-date squeeze system with no packages on hold (**) Video overlay stops updating, busy cursor appears, no reaction to touchpad clicks. I can stop it using the Frame, though. No errors in log. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: possible progress on XO-1 camera issues
On Wed, Dec 23, 2009 at 11:01:50PM -0300, Raul Gutierrez Segales wrote: 8.2 (old geode driver): (II) EXA(0): Offscreen pixmap area of 11208320 bytes F11 (new geode driver): (II) EXA(0): Offscreen pixmap area of 5829856 bytes Debian (Record is working, xserver-xorg-video-geode 2.11.6-1): (II) EXA(0): Offscreen pixmap area of 5499904 bytes Color depth is 16bit: (==) GEODE(0): Depth 16, (==) framebuffer bpp 16 (==) GEODE(0): RGB weight 565 (==) GEODE(0): Default visual is TrueColor (==) GEODE(0): Using gamma correction (1.0, 1.0, 1.0) (==) GEODE(0): DCON detected. There's no xorg.conf, everything is autodetected. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: possible progress on XO-1 camera issues
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/ -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/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
On Wed, 2009-12-23 at 14:28 -0300, César D. Rodas wrote: 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 Can you add an explanation? It doesn't look correct to me. Here's my understanding: The task of this function is to create a new offscreen memory allocation of a certain size. The function goes through the list of existing allocations, looking at each entry. It calculates how much free space there is inbetween one entry in the list, and the next one. If there is enough free space, the new allocation can be inserted at this point. Otherwise, we have to carry on iterating through the list. In that specific section of code, gap is computed, in 2 stages, to be the amount of bytes inbetween the list entry currently being examined and the next one. if (ptr-next == NULL) gap = pGeode-offscreenSize + pGeode-offscreenStart; else gap = ptr-next-offset; This is the first step. It is setting the gap variable to the absolute address where the next allocation starts. In the first branch, we have reached the end of the list, therefore our upper bound is the top of the offscreen memory. In the 2nd branch, there is a following member in the list, so our upper bound is the address of where that memory allocation starts. And the offset variable is always absolute, so this is the correct calculation for the upper bound. As the 2nd stage of the calclation, the lower bound is considered (the end of the allocation currently being examined) to produce a final value of gap that represents the number of bytes inbetween the 2 consecutive list entries: gap = gap - (ptr-offset + ptr-size); To me, everything looks correct before your patch. What am I missing? Thanks, Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: possible progress on XO-1 camera issues
On Wed, 2009-12-23 at 18:09 +, Daniel Drake wrote: On Wed, 2009-12-23 at 14:28 -0300, César D. Rodas wrote: 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 Can you add an explanation? It doesn't look correct to me. You are right. It's not correct. The allocation algorithm is OK as it is. We got a wrong understanding of it and since our change made totem and cheese work (because memory was returned - even though we might probably be stepping on someone's else memory) we decided to share the results. The linked list which keeps the count of used regions seems to be manipulated correctly so no problem there. We are actually running out of offscreen memory. After much looking at the code I went back to X's log and I saw an interesting difference between 8.2 and F11. 8.2 (old geode driver): (II) EXA(0): Offscreen pixmap area of 11208320 bytes F11 (new geode driver): (II) EXA(0): Offscreen pixmap area of 5829856 bytes I wonder why there is a 3MB difference. Ideas? Raúl ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: possible progress on XO-1 camera issues
Hey guys,
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:
(in the Screen Section)
DefaultDepth 24
(in the Display SubSection)
Depth 24
Cheese doesn't show live video from the camera but I am able to take
pictures. And totem reproduces video (no sound, but hey! that it is
another thread/ticket).
Anything wrong with using X with 24bpp?
I can feel F11 on the XO-1 near :)
On Mon, 2009-12-21 at 23:21 +, Tomeu Vizoso wrote:
Hmm, it's a bit hard to read with so many details, can you run it
again without -v --leak-check=full --show-reachable=yes ? Those are
useful when looking for memory leaks.
I would expect that valgrind would complain when the uninitialized
values get read.
Thanks,
Tomeu
On Mon, Dec 21, 2009 at 20:13, crodas cro...@paraguayeduca.org wrote:
Hi there,
On Sat, 19 Dec 2009 12:06:41 +, Tomeu Vizoso to...@sugarlabs.org
wrote:
On Sat, Dec 19, 2009 at 07:00, John Gilmore g...@toad.com wrote:
#10 0xb67fae59 in gst_xvimagesink_xvimage_put (xvimagesink=0x8364160)
at xvimagesink.c:864
src = {x = 134867456, y = 140758336, w = -1259457208, h = 1}
dst = {x = 137730309, y = 3, w = 0, h = 137691184}
result = {x = 0, y = 0, w = 322, h = 241}
draw_border = 322
__PRETTY_FUNCTION__ = gst_xvimagesink_xvimage_put
The src.w value is in the same range as the Xlib function addresses;
-1259457208 is 0x4B11CAB8 and as can be seen from the call frame #9
the XSync function is at 0x4b0eccf7. The other values seem
irrational. This may be evidence that the stack has been corrupted
somewhere else, or the values not initialised.
Just to rule out going too far down a blind alley...
Try adding a printf of these values to the code there, rather than or
in addition to using GDB. GDB may not be 100% reliable when accessing
variables from optimized code. (I used to maintain GDB, and I worked
very hard to make it never lie to you, but that precept hasn't always
been followed in the intervening decade, and optimizations have also
gotten a lot more complicated.)
Or try compiling that code without -O and see if that changes either
its behavior, or what the debugger reports.
At this point is when I would run totem in valgrind, I can help
interpreting the output if it's not clear.
# yum install valgrind
$ valgrind totem
I hope it helps,
http://oficina.paraguayeduca.org/~crodas/valgrind-debug.txt
cheers,
Regards,
Tomeu
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: possible progress on XO-1 camera issues
Btw, Record in Sugar works with the same symptoms as Cheese in Gnome
(that is, you can take pictures but you don't get a live feed).
Hth,
Raúl
On Tue, 2009-12-22 at 21:42 -0300, Raul Gutierrez Segales wrote:
Hey guys,
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:
(in the Screen Section)
DefaultDepth 24
(in the Display SubSection)
Depth 24
Cheese doesn't show live video from the camera but I am able to take
pictures. And totem reproduces video (no sound, but hey! that it is
another thread/ticket).
Anything wrong with using X with 24bpp?
I can feel F11 on the XO-1 near :)
On Mon, 2009-12-21 at 23:21 +, Tomeu Vizoso wrote:
Hmm, it's a bit hard to read with so many details, can you run it
again without -v --leak-check=full --show-reachable=yes ? Those are
useful when looking for memory leaks.
I would expect that valgrind would complain when the uninitialized
values get read.
Thanks,
Tomeu
On Mon, Dec 21, 2009 at 20:13, crodas cro...@paraguayeduca.org wrote:
Hi there,
On Sat, 19 Dec 2009 12:06:41 +, Tomeu Vizoso to...@sugarlabs.org
wrote:
On Sat, Dec 19, 2009 at 07:00, John Gilmore g...@toad.com wrote:
#10 0xb67fae59 in gst_xvimagesink_xvimage_put (xvimagesink=0x8364160)
at xvimagesink.c:864
src = {x = 134867456, y = 140758336, w = -1259457208, h = 1}
dst = {x = 137730309, y = 3, w = 0, h = 137691184}
result = {x = 0, y = 0, w = 322, h = 241}
draw_border = 322
__PRETTY_FUNCTION__ = gst_xvimagesink_xvimage_put
The src.w value is in the same range as the Xlib function addresses;
-1259457208 is 0x4B11CAB8 and as can be seen from the call frame #9
the XSync function is at 0x4b0eccf7. The other values seem
irrational. This may be evidence that the stack has been corrupted
somewhere else, or the values not initialised.
Just to rule out going too far down a blind alley...
Try adding a printf of these values to the code there, rather than or
in addition to using GDB. GDB may not be 100% reliable when accessing
variables from optimized code. (I used to maintain GDB, and I worked
very hard to make it never lie to you, but that precept hasn't always
been followed in the intervening decade, and optimizations have also
gotten a lot more complicated.)
Or try compiling that code without -O and see if that changes either
its behavior, or what the debugger reports.
At this point is when I would run totem in valgrind, I can help
interpreting the output if it's not clear.
# yum install valgrind
$ valgrind totem
I hope it helps,
http://oficina.paraguayeduca.org/~crodas/valgrind-debug.txt
cheers,
Regards,
Tomeu
___
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: possible progress on XO-1 camera issues
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). -- 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
Hi there,
On Sat, 19 Dec 2009 12:06:41 +, Tomeu Vizoso to...@sugarlabs.org
wrote:
On Sat, Dec 19, 2009 at 07:00, John Gilmore g...@toad.com wrote:
#10 0xb67fae59 in gst_xvimagesink_xvimage_put (xvimagesink=0x8364160)
at xvimagesink.c:864
src = {x = 134867456, y = 140758336, w = -1259457208, h = 1}
dst = {x = 137730309, y = 3, w = 0, h = 137691184}
result = {x = 0, y = 0, w = 322, h = 241}
draw_border = 322
__PRETTY_FUNCTION__ = gst_xvimagesink_xvimage_put
The src.w value is in the same range as the Xlib function addresses;
-1259457208 is 0x4B11CAB8 and as can be seen from the call frame #9
the XSync function is at 0x4b0eccf7. The other values seem
irrational. This may be evidence that the stack has been corrupted
somewhere else, or the values not initialised.
Just to rule out going too far down a blind alley...
Try adding a printf of these values to the code there, rather than or
in addition to using GDB. GDB may not be 100% reliable when accessing
variables from optimized code. (I used to maintain GDB, and I worked
very hard to make it never lie to you, but that precept hasn't always
been followed in the intervening decade, and optimizations have also
gotten a lot more complicated.)
Or try compiling that code without -O and see if that changes either
its behavior, or what the debugger reports.
At this point is when I would run totem in valgrind, I can help
interpreting the output if it's not clear.
# yum install valgrind
$ valgrind totem
I hope it helps,
http://oficina.paraguayeduca.org/~crodas/valgrind-debug.txt
cheers,
Regards,
Tomeu
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: possible progress on XO-1 camera issues
Hmm, it's a bit hard to read with so many details, can you run it
again without -v --leak-check=full --show-reachable=yes ? Those are
useful when looking for memory leaks.
I would expect that valgrind would complain when the uninitialized
values get read.
Thanks,
Tomeu
On Mon, Dec 21, 2009 at 20:13, crodas cro...@paraguayeduca.org wrote:
Hi there,
On Sat, 19 Dec 2009 12:06:41 +, Tomeu Vizoso to...@sugarlabs.org
wrote:
On Sat, Dec 19, 2009 at 07:00, John Gilmore g...@toad.com wrote:
#10 0xb67fae59 in gst_xvimagesink_xvimage_put (xvimagesink=0x8364160)
at xvimagesink.c:864
src = {x = 134867456, y = 140758336, w = -1259457208, h = 1}
dst = {x = 137730309, y = 3, w = 0, h = 137691184}
result = {x = 0, y = 0, w = 322, h = 241}
draw_border = 322
__PRETTY_FUNCTION__ = gst_xvimagesink_xvimage_put
The src.w value is in the same range as the Xlib function addresses;
-1259457208 is 0x4B11CAB8 and as can be seen from the call frame #9
the XSync function is at 0x4b0eccf7. The other values seem
irrational. This may be evidence that the stack has been corrupted
somewhere else, or the values not initialised.
Just to rule out going too far down a blind alley...
Try adding a printf of these values to the code there, rather than or
in addition to using GDB. GDB may not be 100% reliable when accessing
variables from optimized code. (I used to maintain GDB, and I worked
very hard to make it never lie to you, but that precept hasn't always
been followed in the intervening decade, and optimizations have also
gotten a lot more complicated.)
Or try compiling that code without -O and see if that changes either
its behavior, or what the debugger reports.
At this point is when I would run totem in valgrind, I can help
interpreting the output if it's not clear.
# yum install valgrind
$ valgrind totem
I hope it helps,
http://oficina.paraguayeduca.org/~crodas/valgrind-debug.txt
cheers,
Regards,
Tomeu
--
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: possible progress on XO-1 camera issues
On Thu, Dec 17, 2009 at 18:08, César D. Rodas cro...@paraguayeduca.org wrote: 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. Hi, if you do 'bt full' instead of just bt, it will print some more stuff and we may be able to see which values are inside the xvimagesink arg. Regards, Tomeu 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 -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: possible progress on XO-1 camera issues
Hello Tomeu, I regenerated the debug files using what you suggested me, it seems to be more information. I've attached to this e-mail. Regards, PS: If attaches to the mailing list is not allowed, please let me know. On Fri, 18 Dec 2009 08:55:05 -0200, Tomeu Vizoso to...@sugarlabs.org wrote: On Thu, Dec 17, 2009 at 18:08, César D. Rodas cro...@paraguayeduca.org wrote: 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. Hi, if you do 'bt full' instead of just bt, it will print some more stuff and we may be able to see which values are inside the xvimagesink arg. Regards, Tomeu 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: possible progress on XO-1 camera issues
Hello, On Fri, 18 Dec 2009 14:19:58 -0300, crodas cro...@paraguayeduca.org wrote: Hello Tomeu, I regenerated the debug files using what you suggested me, it seems to be more information. I've attached to this e-mail. Regards, PS: If attaches to the mailing list is not allowed, please let me know. It doesn't accept :-) Here is the debug file: http://oficina.paraguayeduca.org/~crodas/X-totem-debug-2.log On Fri, 18 Dec 2009 08:55:05 -0200, Tomeu Vizoso to...@sugarlabs.org wrote: On Thu, Dec 17, 2009 at 18:08, César D. Rodas cro...@paraguayeduca.org wrote: 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. Hi, if you do 'bt full' instead of just bt, it will print some more stuff and we may be able to see which values are inside the xvimagesink arg. Regards, Tomeu 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 ___ 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: possible progress on XO-1 camera issues
On Fri, Dec 18, 2009 at 17:19, crodas cro...@paraguayeduca.org wrote: Hello Tomeu, I regenerated the debug files using what you suggested me, it seems to be more information. I've attached to this e-mail. Regards, PS: If attaches to the mailing list is not allowed, please let me know. Don't see any attachment, mailman ate it? Regards, Tomeu On Fri, 18 Dec 2009 08:55:05 -0200, Tomeu Vizoso to...@sugarlabs.org wrote: On Thu, Dec 17, 2009 at 18:08, César D. Rodas cro...@paraguayeduca.org wrote: 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. Hi, if you do 'bt full' instead of just bt, it will print some more stuff and we may be able to see which values are inside the xvimagesink arg. Regards, Tomeu 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 -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: possible progress on XO-1 camera issues
On Fri, Dec 18, 2009 at 17:19, crodas cro...@paraguayeduca.org wrote:
Hello Tomeu,
I regenerated the debug files using what you suggested me, it seems to be
more information.
I've attached to this e-mail.
From looking at this:
http://www.google.com/codesearch/p?hl=en#Gb8U2_Gmi18/os/FreeBSD/distfiles/gst-plugins-base-0.10.12.tar.bz2|ypq63zk-0bg/gst-plugins-base-0.10.12/sys/xvimage/xvimagesink.cq=gst_xvimagesink_xvimage_put%200.10.12l=744
Looks like the absurd values in src and dst are causing X to raise an
error because cannot allocate buffers as big?
src = {x = 134867456, y = 140758336, w = -1259457208, h = 1}
dst = {x = 137730309, y = 3, w = 0, h = 137691184}
Maybe you can set a breakpoint at gst_xvimagesink_xvimage_put and see
from where come those invalid values? At a first guess something
(probably xvimagesink) hasn't been initialized properly.
http://www.unknownroad.com/rtfm/gdbtut/gdbtoc.html
Good luck,
Tomeu
Regards,
PS: If attaches to the mailing list is not allowed, please let me know.
On Fri, 18 Dec 2009 08:55:05 -0200, Tomeu Vizoso to...@sugarlabs.org
wrote:
On Thu, Dec 17, 2009 at 18:08, César D. Rodas cro...@paraguayeduca.org
wrote:
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.
Hi, if you do 'bt full' instead of just bt, it will print some more
stuff and we may be able to see which values are inside the
xvimagesink arg.
Regards,
Tomeu
That should fill out the rest of the debuginfo to make the back trace
more useful.
Re: possible progress on XO-1 camera issues
As Tomeu also found, this backtrace frame is the most interesting:
#10 0xb67fae59 in gst_xvimagesink_xvimage_put (xvimagesink=0x8364160)
at xvimagesink.c:864
src = {x = 134867456, y = 140758336, w = -1259457208, h = 1}
dst = {x = 137730309, y = 3, w = 0, h = 137691184}
result = {x = 0, y = 0, w = 322, h = 241}
draw_border = 322
__PRETTY_FUNCTION__ = gst_xvimagesink_xvimage_put
The src.w value is in the same range as the Xlib function addresses;
-1259457208 is 0x4B11CAB8 and as can be seen from the call frame #9
the XSync function is at 0x4b0eccf7. The other values seem
irrational. This may be evidence that the stack has been corrupted
somewhere else, or the values not initialised.
Looking higher in the code, src.w, src.h, dst.w and dst.h are copied
from xvimagesink struct members. That excludes initialisation of the
variables as a cause. This may be evidence that these structures have
been corrupted somewhere else.
draw_border is set by the code to either TRUE or FALSE, so a value of
322 is unexpected. It is also the same value for width. Compiler
optimisation may cause a register to be used.
If the xvimagesink buffer is so corrupt as to generate those strange
values for src and dst, then when it is sent to XvPutImage the X error
is expected.
I've reviewed the upstream source, git repository
git://anongit.freedesktop.org/gstreamer/gst-plugins-base
but there have been no significant changes in that section of code.
On Fri, Dec 18, 2009 at 05:59:56PM +, Tomeu Vizoso wrote:
Maybe you can set a breakpoint at gst_xvimagesink_xvimage_put and see
from where come those invalid values?
I agree.
--
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
#10 0xb67fae59 in gst_xvimagesink_xvimage_put (xvimagesink=0x8364160)
at xvimagesink.c:864
src = {x = 134867456, y = 140758336, w = -1259457208, h = 1}
dst = {x = 137730309, y = 3, w = 0, h = 137691184}
result = {x = 0, y = 0, w = 322, h = 241}
draw_border = 322
__PRETTY_FUNCTION__ = gst_xvimagesink_xvimage_put
The src.w value is in the same range as the Xlib function addresses;
-1259457208 is 0x4B11CAB8 and as can be seen from the call frame #9
the XSync function is at 0x4b0eccf7. The other values seem
irrational. This may be evidence that the stack has been corrupted
somewhere else, or the values not initialised.
Just to rule out going too far down a blind alley...
Try adding a printf of these values to the code there, rather than or
in addition to using GDB. GDB may not be 100% reliable when accessing
variables from optimized code. (I used to maintain GDB, and I worked
very hard to make it never lie to you, but that precept hasn't always
been followed in the intervening decade, and optimizations have also
gotten a lot more complicated.)
Or try compiling that code without -O and see if that changes either
its behavior, or what the debugger reports.
John
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: possible progress on XO-1 camera issues
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 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
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 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. 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
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 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
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
On Thu, 2009-12-17 at 15:11 +, Peter Robinson wrote: And we'll see where we need to go from there. If the problem appears to be in the geode driver, one thing you might consider doing is going back to the version that was shipped in 8.2. After 8.2, a new release was made with various improvements and new functionality but this isn't the first time that I've suspected regressions caused from that work. Going back to the old version of the driver is not trivial -- it will likely require adapting the old code to the new X.org internal graphics drivers APIs -- but probably an easy job for any experienced programmer. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: possible progress on XO-1 camera issues
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' That should fill out the rest of the debuginfo to make the back trace more useful. Regards, Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: possible progress on XO-1 camera issues
On Thu, Dec 17, 2009 at 3:40 PM, Daniel Drake d...@laptop.org wrote: On Thu, 2009-12-17 at 15:11 +, Peter Robinson wrote: And we'll see where we need to go from there. If the problem appears to be in the geode driver, one thing you might consider doing is going back to the version that was shipped in 8.2. After 8.2, a new release was made with various improvements and new functionality but this isn't the first time that I've suspected regressions caused from that work. Going back to the old version of the driver is not trivial -- it will likely require adapting the old code to the new X.org internal graphics drivers APIs -- but probably an easy job for any experienced programmer. Yes I was aware of the changes. I would hope it might be easier for someone to fix the bug :-) 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
On Thu, 2009-12-17 at 11:47 -0300, César D. Rodas wrote: This probably reflects a bug in the program. The error was 'BadAlloc (insufficient resources for operation)'. I'm doing some work that uses xv on the XO. I found that this occurred for me when running X in 24bit, but 16bit was ok. I'm assuming that it's not actually running out of ram because free reports that I have 223M totoal memory, I certainly hope that means that 32 meg has been given to the display driver. If not I'd like some of it back please :-) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: possible progress on XO-1 camera issues
On Fri, Dec 18, 2009 at 6:32 AM, Neil Graham l...@screamingduck.com wrote: On Thu, 2009-12-17 at 11:47 -0300, César D. Rodas wrote: This probably reflects a bug in the program. The error was 'BadAlloc (insufficient resources for operation)'. I'm doing some work that uses xv on the XO. I found that this occurred for me when running X in 24bit, but 16bit was ok. I'm assuming that it's not actually running out of ram because free reports that I have 223M totoal memory, I certainly hope that means that 32 meg has been given to the display driver. If not I'd like some of it back please :-) See RHBZ https://bugzilla.redhat.com/show_bug.cgi?id=487601 on that particular issue. Peter ___ 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: possible progress on XO-1 camera issues
On Wed, Dec 16, 2009 at 17:36, 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. Great idea! Would be very useful to get a backtrace with symbols of the crash. For that: - install gdb - run gdb cheese from the terminal activity - install needed symbols with the yum command printed by gdb - type 'run' - make it crash - type 'bt full' - copy the output and attach it to a trac ticket You may need to add some swap on a sd card. If I can be of help, will be in #sugar for a while now. Cheers, Tomeu 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 -- «Sugar
Re: possible progress on XO-1 camera issues
Posting some results to http://dev.laptop.org/ticket/9138 -- the symptoms I see with Record-64 in XO-1 with os10 and kernel 2.6.31_xo1-20091211.1834.1.olpc.813348c.i586.rpm are IDENTICAL to when I wrote the original ticket #9138 one year ago. Would be very useful to get a backtrace with symbols of the crash. For that: - install gdb - run gdb cheese from the terminal activity - install needed symbols with the yum command printed by gdb - type 'run' - make it crash - type 'bt full' - copy the output and attach it to a trac ticket Tried to follow the above instructions, running from Terminal in Sugar. But 'bt full' showed nothing. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: possible progress on XO-1 camera issues
On Sat, Dec 12, 2009 at 8:16 PM, Daniel Drake d...@laptop.org 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. I got it working just fine on SoaS beta 4 build for the XO using a gstreamer pipeline. I was taking .png still images with out issue. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
