lkml.org 
[lkml]   [2003]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: readprofile: 0 total nan (fwd)
    Yes I tried both. But no use. XScale can operate in both little endian and big
    endian configuration. By default it is little endian. Does any one have
    oprofile for XScale/ARM ?

    Shesha


    On Tue, 8 Apr 2003, Randy.Dunlap wrote:

    > Hi,
    >
    > We were seeing this problem occasionally at OSDL (but not on Xscale :).
    > Is Xscale little or big endian?
    >
    > I suggest that you try the proposed patch or just run readprofile
    > with the -n option.
    >
    > Did you try either of those yet?
    >
    > ~Randy
    >
    >
    > > Hello All
    > >
    > > I am not very sure that it is readprofile application problem. I downloaded
    > > readprofile source and I compiled it. It worked fine on x86 machine running
    > > 2.4.7-10 kernel. I cross compiled it for xscale processor running 2.4.18 it
    > > is not working.
    > >
    > > Any Input?
    > >
    > >
    > > On Tue, 8 Apr 2003, Andy Pfiffer wrote:
    > >
    > >> On Tue, 2003-04-08 at 15:41, Shesha@asu.edu wrote:
    > >> > I am running 2.4.18 kernel for ARM. I have one of the boot parameters
    > >> "profile=2". The size of the /proc/profile file is shown as 16MB. But
    > >> when I execute "readprofile" the output is ...
    > >> > 0 total nan
    > >> >
    > >> > If I cat the file it just give me a ".". Can anyone suggest what i am
    > >> doing wrong?
    > >>
    > >> [ I swear I was just talking about this problem with someone else... ]
    > >>
    > >> 1. /proc/profile is a binary file. cat won't show you anything
    > >> meaningful.
    > >>
    > >> 2. the 0 output by readprofile is a problem with the automatic
    > >> byte-order detection heuristic built into the code. Try invoking
    > >> readprofile with the "-n" option, and see if your problem goes away.
    > >>
    > >> FYI: For those that might also run into this, the essence of the problem
    > >> is this piece of code in readprofile.c (fragmented for clarity):
    > >>
    > >> "optNative" is 0.
    > >> "buf" is an unsigned int *.
    > >>
    > >>
    > >> if (!optNative) {
    > >> int entries = len/sizeof(*buf);
    > >> int big = 0,small = 0,i;
    > >> unsigned *p;
    > >>
    > >> for (p = buf+1; p < buf+entries; p++)
    > >> if (*p) {
    > >> if (*p >= 1 << (sizeof.7-10 kernel. I cross
    > compiled it for xscale processor running 2.4.18 it
    > > is not working.
    > >
    > > Any Input?
    > >
    > >
    > > On Tue, 8 Apr 2003, Andy Pfiffer wrote:
    > >
    > >> On Tue, 2003-04-08 at 15:41, Shesha@asu.edu wrote:
    > >> > I am running 2.4.18 kernel for ARM. I have one of the boot parameters
    > >> "profile=2". The size of the /proc/profile file is shown as 16MB. But
    > >> when I execute "readprofile" the output is ...
    > >> > 0 total nan
    > >> >
    > >> > If I cat the file it just give me a ".". Can anyone suggest what i am
    > >> doing wrong?
    > >>
    > >> [ I swear I was just talking about this problem with someone else... ]
    > >>
    > >> 1. /proc/profile is a binary file. cat won't show you anything
    > >> meaningful.
    > >>
    > >> 2. the 0 output by readprofile is a problem with the automatic
    > >> byte-order detection heuristic built into the code. Try invoking
    > >> readprofile with the "-n" option, and see if your problem goes away.
    > >>
    > >> FYI: For those that might also run into this, the essence of the problem
    > >> is this piece of code in readprofile.c (fragmented for clarity):
    > >>
    > >> "optNative" is 0.
    > >> "buf" is an unsigned int *.
    > >>
    > >>
    > >> if (!optNative) {
    > >> int entries = len/sizeof(*buf);
    > >> int big = 0,small = 0,i;
    > >> unsigned *p;
    > >>
    > >> for (p = buf+1; p < buf+entries; p++)
    > >> if (*p) {
    > >> if (*p >= 1 << (sizeof(*buf)/2)) big++;
    > >> else small++;
    > >> }
    > >> if (big > small) {
    > >> fprintf(stderr,"Assuming reversed byte order. "
    > >> "Use -n to force native byte order.\n");
    > >> <snipped>
    > >> .
    > >> .
    > >> .
    > >> }
    > >> }
    > >>
    > >> Based on my read of the code, "big" will be incremented if *p >= 4,
    > >> otherwise "small" will be incremented. I can't see how this would ever
    > >> detect the byte order...
    > >>
    > >> Werner proposed this as a solution, but it could still fail to correctly
    > >> detect the byteorder (although with much less frequency):
    >
    >
    >
    >

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:34    [W:0.038 / U:62.840 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site