[gentoo-sparc] PCI-SUN4V: strange virtual-dma size

[gentoo-sparc] PCI-SUN4V: strange virtual-dma size

[Alexander Piavka]

   Hi,
I can't boot 2007.0 sparc64 livecd, the error i get is:
  PCI-SUN4V: strange virtual-dma size
booting both 2.6.17 and 2.6.20 kernels
With 2006.1 livecd 2.6.17 kernel i get the same error
and 2.6.16 - ERROR: Last Trap: Illegal Instruction

I saw there was a patch for this problem http://lkml.org/lkml/2007/6/8/69
Is there a newer sparc64 livecd that overcomes this problem?

  I have:
Sun-Fire-T2000 System Firmware 6.4.4  2007/04/20 10:13
Host flash versions:
    Hypervisor 1.4.1 2007/04/02 16:37
    OBP 4.26.1 2007/04/02 16:26
    POST 4.26.0 2007/03/26 16:45

Allocated 8 Megs of memory at 0x40000000 for kernel
Loaded kernel version 2.6.17
Loading initial ramdisk (645031 bytes at 0x7FFCF4000 phys, 0x40C00000 
virt)...
/
Remapping the kernel... done.
bootmem_init: Scan pavail, choose_bootmap_pfn: kern[8800000:8cd6000] 
avoid[7ffcf4000:7ffd92000]
choose_bootmap_pfn: Using 4200 [8400000]
init_bootmem(min[4200], bootmap[4200], max[3ffefd])
free_bootmem(pavail:0): base[8400000] size[7f78ec000]
free_bootmem(pavail:1): base[7ffcf4000] size[f4000]
free_bootmem(pavail:2): base[7ffdf6000] size[4000]
reserve_bootmem(initrd): base[7ffcf4000] size[7ffd917a7]
reserve_bootmem(kernel): base[8800000] size[4d5ee8]
reserve_bootmem(bootmap): base[8400000] size[7f7a0]
memory_present(0, 4200, 3ffe76)
memory_present(0, 3ffe7a, 3ffef4)
memory_present(0, 3ffefb, 3ffefd)
Booting Linux...
mem_init: Calling free_all_bootmem().
PCI-SUN4V: strange virtual-dma size.
Program terminated

  Thanks
  Alex
-- 
gentoo-sparc@gentoo.org mailing list

[gentoo-sparc] Correctable ECC Error question...

[Leif Sawyer]

Is there a way to map the information given by the ECC error
into a specific RAM module on my UltraSparc 2?

Jan  8 20:21:46 wormhole kernel: CPU[1]: Correctable ECC Error
AFSR[100000] AFAR[0000000046592940] UDBL[0] UDBH[0] TL>1[0]

Jan  8 21:57:17 wormhole kernel: CPU[1]: Correctable ECC Error
AFSR[100000] AFAR[0000000046592940] UDBL[0] UDBH[0] TL>1[0]

(message repeats, exactly, except for timestamps, 11 more times)

--
gentoo-sparc@lists.gentoo.org mailing list

[gentoo-sparc] Another quiet question

[Leif Sawyer]

My ECC Ram question went by without so much as a burp on the list, who
knows if this will make any waves, either...

$ gcc --version
gcc (GCC) 3.4.6 (Gentoo 3.4.6-r2, HTB-3.4.4-1.00, ssp-3.4.6-1.0,
pie-8.7.9)

$ sudo emerge sys-devel/gcc-3.4.6-r2
[snip]
stage1/xgcc -Bstage1/ -B/usr/sparc-unknown-linux-gnu/bin/    -m32
-mcpu=ultrasparc -O2 -pipe -DIN_GCC   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-Wold-style-definition     -DHAVE_CONFIG_H  -o tree1 \
        treelang/tree1.o treelang/treetree.o treelang/tree-convert.o \
        treelang/lex.o treelang/parse.o \
        main.o libbackend.a ../libiberty/libiberty.a
../libiberty/libiberty.a   ../libiberty/libiberty.a   attribs.o
libbackend.a(function.o): In function `expand_function_end':
function.c:(.text+0xa568): undefined reference to
`bounds_delete_redundant_calls'
libbackend.a(calls.o): In function `expand_call':
calls.c:(.text+0x56cc): undefined reference to
`bounds_note_call_for_deletion'
calls.c:(.text+0x5ccc): undefined reference to
`bounds_is_deletable_fn_p'
collect2: ld returned 1 exit status
make[2]: *** [tree1] Error 1
make[2]: Leaving directory
`/var/tmp/portage/sys-devel/gcc-3.4.6-r2/work/build/gcc'
make[1]: *** [stage2_build] Error 2
make[1]: Leaving directory
`/var/tmp/portage/sys-devel/gcc-3.4.6-r2/work/build/gcc'
make: *** [bootstrap-lean] Error 2
 *
 * ERROR: sys-devel/gcc-3.4.6-r2 failed.
 * Call stack:
 *               ebuild.sh, line   49:  Called src_compile
 *             environment, line 4519:  Called toolchain_src_compile
 *             environment, line 5009:  Called gcc_src_compile
 *             environment, line 2886:  Called gcc_do_make
 *             environment, line 2716:  Called die
 * The specific snippet of code:
 *       emake LDFLAGS="${LDFLAGS}" STAGE1_CFLAGS="${STAGE1_CFLAGS}"
LIBPATH="${LIBPATH}" BOOT_CFLAGS="${BOOT_CFLAGS}" ${GCC_MAKE_TARGET} ||
die "emake failed with ${GCC_MAKE_TARGET}";
 *  The die message:
 *   emake failed with bootstrap-lean
 *
 * If you need support, post the topmost build error, and the call stack
if relevant.
 * A complete build log is located at
'/var/tmp/portage/sys-devel/gcc-3.4.6-r2/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/sys-devel/gcc-3.4.6-r2/temp/environment'.
 *

 * Messages for package sys-devel/gcc-3.4.6-r2:

 *
 * ERROR: sys-devel/gcc-3.4.6-r2 failed.
 * Call stack:
 *               ebuild.sh, line   49:  Called src_compile
 *             environment, line 4519:  Called toolchain_src_compile
 *             environment, line 5009:  Called gcc_src_compile
 *             environment, line 2886:  Called gcc_do_make
 *             environment, line 2716:  Called die
 * The specific snippet of code:
 *       emake LDFLAGS="${LDFLAGS}" STAGE1_CFLAGS="${STAGE1_CFLAGS}"
LIBPATH="${LIBPATH}" BOOT_CFLAGS="${BOOT_CFLAGS}" ${GCC_MAKE_TARGET} ||
die "emake failed with ${GCC_MAKE_TARGET}";
 *  The die message:
 *   emake failed with bootstrap-lean
 *
 * If you need support, post the topmost build error, and the call stack
if relevant.
 * A complete build log is located at
'/var/tmp/portage/sys-devel/gcc-3.4.6-r2/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/sys-devel/gcc-3.4.6-r2/temp/environment'.
 *

--
gentoo-sparc@lists.gentoo.org mailing list

Re: [gentoo-sparc] Another quiet question

[Hamish Greig]

Leif Sawyer wrote:
> My ECC Ram question went by without so much as a burp on the list, who
> knows if this will make any waves, either...
> 
> $ gcc --version
> gcc (GCC) 3.4.6 (Gentoo 3.4.6-r2, HTB-3.4.4-1.00, ssp-3.4.6-1.0,
> pie-8.7.9)
> 
> $ sudo emerge sys-devel/gcc-3.4.6-r2
> [snip]

I think the reason no-one responds to your posts are because they are 
not structured in any methodical way. No sequence showing how you've 
already tried to investigate the problem, just a post asking for an 
answer, which doesn't get a lot of respect from people who've taken time 
and effort to learn things already.
What more than this dump can you tell us about this error? What have you 
already done to investigate it? what level of skill do you have in this 
area? are we expected to fix it for you step by step or to guide you to 
a resolution?


-- 
gentoo-sparc@lists.gentoo.org mailing list

RE: [gentoo-sparc] Another quiet question

[Leif Sawyer]

Hamish Greig [mailto:hgreig@bigpond.net.au] 
> I think the reason no-one responds to your posts are because 
> they are not structured in any methodical way. No sequence 
> showing how you've already tried to investigate the problem, 
> just a post asking for an answer, which doesn't get a lot of 
> respect from people who've taken time and effort to learn 
> things already.

I'm sorry that my terseness offends your sensibilities.  All
the information that I had available was in the post, i.e.,
gcc failed to build.

> What more than this dump can you tell us about this error? 

it's reproducable.  it's not caused by OOM, but obviously by
a build-level error, because certain objects that the source
code thinks should be available, aren't.  Perhaps looking at
the detail I provided a bit closer might reveal that fact, in
an obvious sort of manner (i.e., an ld error)

> What have you already done to investigate it? what level of 
> skill do you have in this area? are we expected to fix it for 
> you step by step or to guide you to a resolution?

Since I'm neither a maintainer, nor a GCC developer, but simply
a gentoo-sparc user, my job is to report the bugs that I see.

If you are a developer or maintainer, one might questions the
validity in your stance of attacking users for not providing
the information that -you- feel is needed, instead of simply
asking for additional detail.

It's no wonder the list is dry and gentoo is losing it's path.
--
gentoo-sparc@lists.gentoo.org mailing list

Re: [gentoo-sparc] Another quiet question

[Hamish Greig]

Leif, lose the attitude. You are asking questions of this list and 
asking the list to do work ascertaining what you have done and what you 
are capable of doing. Please read
http://www.catb.org/~esr/faqs/smart-questions.html
We know nothing of your problems except that you can cut and paste 
errors. I am not offended by your terseness, just frustrated that you 
aren't being forthcoming with more information, which would allow people 
to immediately help or state inability to help past where you have 
already got to. The extra information you have given below doesn't 
particularly help and as I think you want the problem fixed I suggest 
you become involved in the solution instead of expecting a solution to 
be given to you because you are using gentoo's product. Open source tech 
support doesn't work like that unless you have a support contract (== $$$)
Thanks
Hamish

Leif Sawyer wrote:
> Hamish Greig [mailto:hgreig@bigpond.net.au] 
>> I think the reason no-one responds to your posts are because 
>> they are not structured in any methodical way. No sequence 
>> showing how you've already tried to investigate the problem, 
>> just a post asking for an answer, which doesn't get a lot of 
>> respect from people who've taken time and effort to learn 
>> things already.
> 
> I'm sorry that my terseness offends your sensibilities.  All
> the information that I had available was in the post, i.e.,
> gcc failed to build.
> 
>> What more than this dump can you tell us about this error? 
> 
> it's reproducable.  it's not caused by OOM, but obviously by
> a build-level error, because certain objects that the source
> code thinks should be available, aren't.  Perhaps looking at
> the detail I provided a bit closer might reveal that fact, in
> an obvious sort of manner (i.e., an ld error)
> 
>> What have you already done to investigate it? what level of 
>> skill do you have in this area? are we expected to fix it for 
>> you step by step or to guide you to a resolution?
> 
> Since I'm neither a maintainer, nor a GCC developer, but simply
> a gentoo-sparc user, my job is to report the bugs that I see.
> 
> If you are a developer or maintainer, one might questions the
> validity in your stance of attacking users for not providing
> the information that -you- feel is needed, instead of simply
> asking for additional detail.
> 
> It's no wonder the list is dry and gentoo is losing it's path.


-- 
gentoo-sparc@lists.gentoo.org mailing list

Re: [gentoo-sparc] Another quiet question

[Javier O. Augusto]

Leif, have you tried compiling the official latest gcc release instead?

check this out..
http://gcc.gnu.org/gcc-4.2/buildstat.html

I would take the latest gcc tarball and give it a shot. You could
eventually find out if there's a problem with you build environment or
your ebuild.

Hope it helps!

Regards,
jay_of_today

-- 
gentoo-sparc@lists.gentoo.org mailing list

Re: [gentoo-sparc] Correctable ECC Error question...

[Hamish Greig]

Leif Sawyer wrote:
> Is there a way to map the information given by the ECC error
> into a specific RAM module on my UltraSparc 2?
> 
> Jan  8 20:21:46 wormhole kernel: CPU[1]: Correctable ECC Error
> AFSR[100000] AFAR[0000000046592940] UDBL[0] UDBH[0] TL>1[0]
> 
> Jan  8 21:57:17 wormhole kernel: CPU[1]: Correctable ECC Error
> AFSR[100000] AFAR[0000000046592940] UDBL[0] UDBH[0] TL>1[0]
> 
> (message repeats, exactly, except for timestamps, 11 more times)
> 

http://dlc.sun.com/pdf/802-2561-11/802-2561-11.pdf

section 4.5

It took me a minute to find this on the sun site, it was weirdly named, 
called "ultra2 service manual", go figure!, I can see why you didn't 
find it yourself.




-- 
gentoo-sparc@lists.gentoo.org mailing list

RE: [gentoo-sparc] Correctable ECC Error question...

[Leif Sawyer]

> From: Hamish Greig [mailto:hgreig@bigpond.net.au] 
> Leif Sawyer wrote:
> > Is there a way to map the information given by the ECC error into a 
> > specific RAM module on my UltraSparc 2?
> > 
> > Jan  8 20:21:46 wormhole kernel: CPU[1]: Correctable ECC Error 
> > AFSR[100000] AFAR[0000000046592940] UDBL[0] UDBH[0] TL>1[0]
> > 
> > Jan  8 21:57:17 wormhole kernel: CPU[1]: Correctable ECC Error 
> > AFSR[100000] AFAR[0000000046592940] UDBL[0] UDBH[0] TL>1[0]
> > 
> > (message repeats, exactly, except for timestamps, 11 more times)
> > 
> 
> http://dlc.sun.com/pdf/802-2561-11/802-2561-11.pdf
> 

Sure, service manual works great for Sun error codes, but I'm
trying to map the linux error code into the sparc line.

And what I -don't- see, aside from the register information,
is what the -address- of the fault was.  Or maybe that's encoded
somehow in the statis bit?

I did try google to figure it out, but only found solaris references
that showed I should be seing and address, and linux folks asking
the same questions.

--
gentoo-sparc@lists.gentoo.org mailing list