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
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, 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
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
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 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, Dec 23, 2009 at 02:42, James Cameron 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
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
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 wrote:
> > > Hi there,
> > > On Sat, 19 Dec 2009 12:06:41 +, Tomeu Vizoso
> > > wrote:
> > >> On Sat, Dec 19, 2009 at 07:00, John Gilmore 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
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 wrote:
> > Hi there,
> > On Sat, 19 Dec 2009 12:06:41 +, Tomeu Vizoso
> > wrote:
> >> On Sat, Dec 19, 2009 at 07:00, John Gilmore 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 wrote:
> Hi there,
> On Sat, 19 Dec 2009 12:06:41 +, Tomeu Vizoso
> wrote:
>> On Sat, Dec 19, 2009 at 07:00, John Gilmore 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
Hi there,
On Sat, 19 Dec 2009 12:06:41 +, Tomeu Vizoso
wrote:
> On Sat, Dec 19, 2009 at 07:00, John Gilmore 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
On Sat, Dec 19, 2009 at 07:00, John Gilmore 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
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
> #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
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
On Fri, Dec 18, 2009 at 17:19, crodas 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.c&q=gst_xvimagesink_xvimage_put%200.10.12&l=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
> wrote:
>> On Thu, Dec 17, 2009 at 18:08, César D. Rodas
>> 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-
Re: possible progress on XO-1 camera issues
On Fri, Dec 18, 2009 at 17:19, crodas 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 > wrote: >> On Thu, Dec 17, 2009 at 18:08, César D. Rodas >> 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
Re: possible progress on XO-1 camera issues
Hello, On Fri, 18 Dec 2009 14:19:58 -0300, crodas 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 > wrote: >> On Thu, Dec 17, 2009 at 18:08, César D. Rodas >> 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, >>> >>>
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 wrote: > On Thu, Dec 17, 2009 at 18:08, César D. Rodas > 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
On Thu, Dec 17, 2009 at 18:08, César D. Rodas 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 6:32 AM, Neil Graham 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
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
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, Dec 17, 2009 at 3:40 PM, Daniel Drake 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
>> >> > 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, 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
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 > 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, Dec 17, 2009 at 2:47 PM, César D. Rodas 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
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
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
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 > 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
On Wed, Dec 16, 2009 at 7:36 PM, César D. Rodas 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
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 Wed, Dec 16, 2009 at 17:36, César D. Rodas 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 >> > > > ___
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 Sat, Dec 12, 2009 at 8:16 PM, 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. 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
