Stacktraces from core dump files in 11.2.x and 11.3.x OSs

[Martin Langhoff]

We recently found that we cannot easily read core dumps generated by
our 11.x.y OS builds. With help from Jan and John Gilmore we got to
the bottom of it.

I've prepared a patched GDB rpm with the patch that can handle our
core files, and documented this quirk at
http://wiki.laptop.org/go/StackTraces

Background info at
http://lists.fedoraproject.org/pipermail/devel/2012-March/164133.html

thanks,


m
-- 
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Urgent -- help needed diagnosing possible DMA conflict

[Martin Langhoff]

We have what looks like a fix for the Record crash! Yum update your
kernel and rsync the kernel+inird into place, and help us test :-)



m

On Sat, Mar 17, 2012 at 10:15 AM, Saadia Husain Baloch
 wrote:
> Jon C.
> These are definitely a breakthrough! I have not been able to crash Record
> (and I'm good at managing crashes), and there are no green screens of death
> either. Chris Ball has pushed them to our code tree so more people can test
> them as well.
> I have noticed one thing in the short testing I did this morning: the audio
> is garbled/unintelligible on these recorded segments. Let me see if anyone
> else is experiencing this, but I didn't have it before.
> Thank you for all your help
> -Saadia
>
>
> On Fri, Mar 16, 2012 at 6:51 PM, Jonathan Corbet  wrote:
>>
>> On Fri, 16 Mar 2012 14:53:58 -0600
>> Jonathan Corbet  wrote:
>>
>> > I want to pound on it for a bit longer, then I'll have a set of patches
>> > to
>> > send in.  Stay tuned...
>>
>> And now they are ready.  There's a whole set of stuff in my repo,
>> including the other bug fixes I've sent around, a couple you haven't seen
>> yet (including one for #11644), and, at the end of the series, the
>> demotion of the "Release" printk spam to debug level.
>>
>> With these patches in, I cannot make my machine crash no matter how hard I
>> try; I think the problems are truly stomped.  My apologies for creating
>> them in the first place and causing you to lose a lot of time.
>>
>> jon
>>
>> The following changes since commit
>> 943cd42c06440bbc139b775a73fbf55786e44087
>> are available in the git repository at:
>>
>>  git://git.lwn.net/linux-2.6.git olpc-camera-fixes
>>
>> for you to fetch changes up to 3b944fd17f650c9f589924f0f26de7c36c444516:
>>
>>  marvell-cam: Demote the "release" print to debug level (2012-03-16
>> 16:29:50 -0600)
>>
>> 
>> Jonathan Corbet (7):
>>      marvell-cam: ensure that the camera stops when requested
>>      marvell-cam: Remove broken "owner" logic
>>      marvell-cam: Increase the DMA shutdown timeout
>>      marvell-cam: fix the green screen of death
>>      marvell-cam: Don't signal multiple frame completions in
>> scatter/gather mode
>>      mmp-camera: Don't power up the sensor on resume
>>      marvell-cam: Demote the "release" print to debug level
>>
>>  drivers/media/video/marvell-ccic/mcam-core.c  |   35
>> 
>>  drivers/media/video/marvell-ccic/mcam-core.h  |    1 -
>>  drivers/media/video/marvell-ccic/mmp-driver.c |   13 ++---
>>  3 files changed, 32 insertions(+), 17 deletions(-)
>
>



-- 
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Debuginfo package for Python-2.7 on F14 mismatched or (l)user error?

[Martin Langhoff]

Hi Jan,

that's enormously useful -- thanks! I'll make sure we fix our kernel
options so this isn't an issue in the future.

And I'll patch my gdb so I can read the other stacktraces.

cheers -


m

On Sat, Mar 17, 2012 at 4:56 AM, Jan Kratochvil
 wrote:
> On Fri, 16 Mar 2012 20:46:16 +0100, Martin Langhoff wrote:
>> Argh, that could be. But our kernel is a custom built rpm,
>
> You have a bug for Fedora there, in the core file by readelf -l:
> Program Headers:
>  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
> [...]
>  LOAD          0x1933000 0xa7703000 0x 0x0 0x174000 R E 0x1000
>                                                ^^^
> There is normally 0x1000 on x86* Fedora kernels due to:
> $ cat /proc/self/coredump_filter
> 0033
>
> /usr/share/doc/kernel-doc-*/Documentation/filesystems/proc.txt
>  - (bit 4) ELF header pages in file-backed private memory areas (it is
>            effective only if the bit 2 is cleared)
>
> This way build-id for the executable and shared libraries is dumped in the
> core file but it is missing in this OLPC kernel.  Fedora GDB has not yet
> upstreamed patch for build-id which did not expect such core files.
>
> Going to push a fix for F-15+ but F-14 is EOLed, you can either use FSF GDB or
> patch Fedora GDB by this patch or use F-15+ GDB etc.
>
> That backtrace of "core.522" FYI is at:
>        http://people.redhat.com/jkratoch/sandisk.bt
>
>
> Thanks,
> Jan
>
> --- gdb-7.2/gdb/solib-svr4.c.orig       2012-03-17 09:39:54.874090162 +0100
> +++ gdb-7.2/gdb/solib-svr4.c    2012-03-17 09:42:12.561810807 +0100
> @@ -1202,14 +1202,30 @@ svr4_current_sos (void)
>            }
>          else
>            {
> -             struct build_id *build_id;
> +             struct build_id *build_id = NULL;
>
>              strncpy (new->so_original_name, buffer, SO_NAME_MAX_PATH_SIZE - 
> 1);
>              new->so_original_name[SO_NAME_MAX_PATH_SIZE - 1] = '\0';
>              /* May get overwritten below.  */
>              strcpy (new->so_name, new->so_original_name);
>
> -             build_id = build_id_addr_get (LM_DYNAMIC_FROM_LINK_MAP (new));
> +             /* In the case the main executable was found according to its
> +                build-id (from a core file) prevent loading a different build
> +                of a library with accidentally the same SO_NAME.
> +
> +                It suppresses bogus backtraces (and prints "??" there 
> instead)
> +                if the on-disk files no longer match the running program
> +                version.
> +
> +                If the main executable was not loaded according to its
> +                build-id do not do any build-id checking of the libraries.
> +                There may be missing build-ids dumped in the core file and we
> +                would map all the libraries to the only existing file loaded
> +                that time - the executable.  */
> +
> +             if (symfile_objfile != NULL
> +                 && (symfile_objfile->flags & OBJF_BUILD_ID_CORE_LOADED) != 
> 0)
> +               build_id = build_id_addr_get (LM_DYNAMIC_FROM_LINK_MAP (new));
>              if (build_id != NULL)
>                {
>                  char *name, *build_id_filename;
> @@ -1224,23 +1240,7 @@ svr4_current_sos (void)
>                      xfree (name);
>                    }
>                  else
> -                   {
> -                     debug_print_missing (new->so_name, build_id_filename);
> -
> -                     /* In the case the main executable was found according 
> to
> -                        its build-id (from a core file) prevent loading
> -                        a different build of a library with accidentally the
> -                        same SO_NAME.
> -
> -                        It suppresses bogus backtraces (and prints "??" there
> -                        instead) if the on-disk files no longer match the
> -                        running program version.  */
> -
> -                     if (symfile_objfile != NULL
> -                         && (symfile_objfile->flags
> -                             & OBJF_BUILD_ID_CORE_LOADED) != 0)
> -                       new->so_name[0] = 0;
> -                   }
> +                   debug_print_missing (new->so_name, build_id_filename);
>
>                  xfree (build_id_filename);
>                  xfree (build_id);
>
> --
> devel mailing list
> de...@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel



-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Some questions about "root" and "olpc" logins.

[Ajay Garg]

Thanks Paul, Alan, Martin, James.


Well, I guess the "only-allow-wheel-group-users-to-switch-to -su" was the
thing that I had missed out; now everything seems to fall in place ::

==
b.
If I add  password for "root"; and both "root" and "olpc" are part of
"wheel" group, then :

   (i)  on os883.img, doing "su -" from "olpc" login DOES NOT ask for the
"root" password.
   (ii) on my F14 machine, doing "su -" from "olpc" login DOES ask for the
"root" password, and authentication is successful upon entering the correct
root-password.

What is the reason for this difference in behaviour?
===

Case b. (i) is explained, since "olpc" is in "wheel" group, so it is
allowed to "su"; moreover since there is the line
"authsufficient  pam_wheel.so trust use_uid"
"in /etc/pam.d/su", thus "wheel" group users need not be asked for password.




===
c.
If I add password for "root", and only "root" is part of the "wheel" group,
then :

   (i)  on os883.img, doing "su -" from "olpc" login DOES ask the
root-password, but the authentication is NEVER successful, no matter what
password is entered.
   (ii) on my F14 machine, doing "su -" from "olpc" login DOES ask for the
"root" password, and authentication is successful upon entering the correct
root-password.


Now, since "olpc" is not a part of "wheel" group, thus, it cannot "su",
come what may 




I commented out the line (as suggested by James) ::
auth   requiredpam_wheel.so use_uid
in "/etc/pam.d/su",

and now, it rightfully asks for root-password, and upon entering the
correct password, authrorizes the entry into the zone :)


Thanks everyone.

Regards,
Ajay



On Sat, Mar 17, 2012 at 3:27 AM, James Cameron  wrote:

> On Sat, Mar 17, 2012 at 12:40:11AM +0530, Ajay Garg wrote:
> > Hi all.
> >
> > I just compared the "root" and "olpc" logins functioning on os883.img,
> > and my F14 laptop; and I am curious about the following things ::
> >
> > a.
> > Why is "root" login not protected by a password on os883.img ?
>
> We have always done this with OLPC builds.  If I recall correctly, the
> basis for it was that the learner always is in control of their own
> machine, it is always with them, and the learner is allowed to damage
> the software and lose their data in order to learn.
>
> This ties in with the OLPC Core Principles of Child Ownership and Free
> and Open Source.
>
> > b.
> > If I add  password for "root"; and both "root" and "olpc" are part of
> "wheel"
> > group, then :
> >
> >(i)  on os883.img, doing "su -" from "olpc" login DOES NOT ask for the
> > "root" password.
> >(ii) on my F14 machine, doing "su -" from "olpc" login DOES ask for
> the
> > "root" password, and authentication is successful upon entering the
> correct
> > root-password.
> >
> > What is the reason for this difference in behaviour?
>
> olpc-os-builder.git:modules/base/kspost.10.core.inc
>
> # allow sudo for olpc user
> echo "%wheel ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers
>
> # Only allow su access to those in the wheel group (#5537)
> sed -i -e '1,6s/^#auth/auth/' /etc/pam.d/su
>
> > c.
> > If I add password for "root", and only "root" is part of the "wheel"
> group,
> > then :
> >
> >(i)  on os883.img, doing "su -" from "olpc" login DOES ask the
> > root-password, but the authentication is NEVER successful, no matter what
> > password is entered.
> >(ii) on my F14 machine, doing "su -" from "olpc" login DOES ask for
> the
> > "root" password, and authentication is successful upon entering the
> correct
> > root-password.
> >
> > What is the reason for this difference in behaviour?
>
> Same as above.
>
> > It might very well be a design decision; just my bad that I am unaware
> > of it :|
>
> ;-)
>
> --
> James Cameron
> http://quozl.linux.org.au/
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: 12.1.0 trac milestone organisation (Devel Digest, Vol 73, Issue 25)

[Chris Ball]

Hi,

On Sat, Mar 17 2012, Yioryos Asprobounitis wrote:
> I was wondering if there are any VM builds planed for OLPC 12.1.0 
> (particularly XO-1.75 builds) or if this is considered an unnecessary burden 
> for tracking.
> I can understand that using the actual hardware is the most important thing. 
> But apparently there are not enough XO-1.75s available. 
> So VM builds could be of some value during development.

We haven't made having VM builds a priority because:

qemu-arm is extremely slow even on fast x86 machines, so emulating ARM
builds on x86 doesn't work well.

For the x86 builds, you might as well just install the same version of
Fedora that the build is based on, and yum install sugar.

- Chris.
-- 
Chris Ball  
One Laptop Per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel