Re: [gentoo-user] Vcore unstable?

[R0b0t1]

On Sat, May 26, 2018 at 6:50 PM,   wrote:
>
> i have a machine i just put lm sensors etc. on.  xsensors shows "Vcore"
> fluctuating between 1.12 and 1.3v.  stays at 1.12V when idling but increases
> with load.  Is this remotely normal behavior for an athlon chip in a desk
> top?  It's either some sort of throttling or the Vcore power supply is
> failing, obviously i'd like to know which.  If it's the power supply i can
> likely fix it if it needs to be fixed.  Also occurs to me that xsensors
> could be usefull tracking down intermittent issues.  I used it to monitor a
> power supply i wasn't sure about for about a week and it stayed nice.
>
> mad.scientist.at.large (a good madscientist)
> --
>

If it increases with load the regulator is working properly. The
higher voltage is needed to induce a higher current slew rate, i.e.
how fast the electrons accelerate, i.e. chip frequency.

Cheers,
 R0b0t1

Re: [gentoo-user] crossdev arm-unknown-linux-gnu failed

[R0b0t1]

On Sat, May 26, 2018 at 10:35 PM, Andrew Udvare  wrote:
>
>
>> On 2018-05-26, at 23:32, Andrew Udvare  wrote:
>>
>> You probably mean to use another triple name. The last part is the C 
>> library, so you probably mean:
>>
>> arm-unknown-Linux-glibc
>
> That is:
>
> arm-unknown-linux-glic
>
> It is case-sensitive.
>

You may need to fix the profile yourself, but the typical triplet is
now "arm-linux-gnueabihf." There is a tracker issue on this. Most
things compile for me, some breakage in @system.

Cheers,
 R0b0t1

[gentoo-user] X upgrade and firefox

[Ian Zimmerman]

Since the last Xorg upgrade the week of May 20th, firefox seems to quit
(ie. crash) sporadically when I play chess on lichess.org.  That leaves
me very unhappy :-( There is a log message:

[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been 
called
[xcb] Aborting, sorry about that.
firefox: 
/var/tmp/portage/x11-libs/libX11-1.6.5/work/libX11-1.6.5/src/xcb_io.c:259: 
poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.

At first I thought this was a firefox problem because it was updated
about the same time.  But then I intentionally downgraded firefox back
to what I thought was the "stable" version (52.6.0), and the problem
persists, so I now think it is X, either xcb or some other piece.

Has anyone seen similar?

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

Re: [gentoo-user] crossdev arm-unknown-linux-gnu failed

[Andrew Udvare]

> On 2018-05-26, at 23:32, Andrew Udvare  wrote:
> 
> You probably mean to use another triple name. The last part is the C library, 
> so you probably mean:
> 
> arm-unknown-Linux-glibc

That is:

arm-unknown-linux-glic

It is case-sensitive.

---
Andrew

Re: [gentoo-user] crossdev arm-unknown-linux-gnu failed

[Andrew Udvare]

> On 2018-05-26, at 23:06, tu...@posteo.de wrote:
> 
> Hi,
> 
> too feed a STM32F103C8T6 MCU (Core-M3) with some code to execute,
> I want a compiler. For that I did a 
> 
>crossdev arm-unknown-linux-gnu
> 
> . That one failed to build (gcc, binytils seem to be ok).
> 
> Unfortunately I did not really understand, what the great concerto
> of logfiles (attached) are want to tell me. On the internet I found
> an older thread of a person who seems (?) to have similiar problems
> with the same target compiler, but no solution there was.
> 
> I am running Gentoo linux on a AMD Phenom(tm) II X6 1090T Processor.
> This is a 64 bit system. The system is updated regularly.
> 
> I would be very happy, if someone, who better understand the topic,
> could help me to get this thing running -- thank you very much in
> advance for any help!


I see in your log:

Configuration arm-unknown-linux-gnu not supported

You probably mean to use another triple name. The last part is the C library, 
so you probably mean:

arm-unknown-Linux-glibc

---
Andrew

[gentoo-user] crossdev arm-unknown-linux-gnu failed

[tuxic]

Hi,

too feed a STM32F103C8T6 MCU (Core-M3) with some code to execute,
I want a compiler. For that I did a 

crossdev arm-unknown-linux-gnu

. That one failed to build (gcc, binytils seem to be ok).

Unfortunately I did not really understand, what the great concerto
of logfiles (attached) are want to tell me. On the internet I found
an older thread of a person who seems (?) to have similiar problems
with the same target compiler, but no solution there was.

I am running Gentoo linux on a AMD Phenom(tm) II X6 1090T Processor.
This is a 64 bit system. The system is updated regularly.

I would be very happy, if someone, who better understand the topic,
could help me to get this thing running -- thank you very much in
advance for any help!

Cheers!
Meino

PS: Logfiles are attached as mentioned in the below
outout: Last output of the process to console was:
-   

 * crossdev version:  20180508
 * Host Portage ARCH: amd64
 * Target Portage ARCH:   arm
 * Target System: arm-unknown-linux-gnu
 * Stage: 4 (C/C++ compiler)
 * USE=multilib:  no
 * ABIs:  default

 * binutils:  binutils-[latest]
 * gcc:   gcc-[latest]
 * headers:   linux-headers-[latest]
 * libc:  glibc-[latest]

 * CROSSDEV_OVERLAY:  /usr/local/portage
 * PORT_LOGDIR:   /var/log/portage
 * PORTAGE_CONFIGROOT:/
 * Portage flags: 


 * leaving sys-devel/binutils in /usr/local/portage
 * leaving sys-devel/gcc in /usr/local/portage
 * leaving sys-kernel/linux-headers in /usr/local/portage
 * leaving sys-libs/glibc in /usr/local/portage
 * leaving sys-devel/gdb in /usr/local/portage
 * leaving metadata/layout.conf alone in /usr/local/portage


 * Log: /var/log/portage/cross-arm-unknown-linux-gnu-binutils.log
 * Emerging cross-binutils ...  
  [ ok ]
 * Log: /var/log/portage/cross-arm-unknown-linux-gnu-linux-headers-quick.log
 * Emerging cross-linux-headers-quick ...   
  [ ok ]
 * Log: /var/log/portage/cross-arm-unknown-linux-gnu-glibc-headers.log
 * Emerging cross-glibc-headers ... 
  [ ok ]
 * Log: /var/log/portage/cross-arm-unknown-linux-gnu-gcc-stage1.log
 * Emerging cross-gcc-stage1 ...

 * error: gcc failed :(
 * 
 * If you file a bug, please attach the following logfiles:
 * /var/log/portage/cross-arm-unknown-linux-gnu-info.log
 * /var/log/portage/cross-arm-unknown-linux-gnu-gcc-stage1.log.xz
 * /var/tmp/portage/cross-arm-unknown-linux-gnu/gcc*/temp/gcc-config.logs.tar.xz
[1]18278 exit 1 crossdev arm-unknown-linux-gnu

-   

 (B*(B crossdev version:  20180508
 (B*(B Host Portage ARCH: amd64
 (B*(B Target Portage ARCH:   arm
 (B*(B Target System: arm-unknown-linux-gnu
 (B*(B Stage: 4 (C/C++ compiler)
 (B*(B USE=multilib:  no
 (B*(B ABIs:  default

 (B*(B binutils:  binutils-[latest]
 (B*(B gcc:   gcc-[latest]
 (B*(B headers:   linux-headers-[latest]
 (B*(B libc:  glibc-[latest]

 (B*(B CROSSDEV_OVERLAY:  /usr/local/portage
 (B*(B PORT_LOGDIR:   /var/log/portage
 (B*(B PORTAGE_CONFIGROOT:/
 (B*(B Portage flags: 


Portage 2.3.40 (python 2.7.14-final-0, default/linux/amd64/17.0/no-multilib, 
gcc-7.3.0, glibc-, 4.16.12-RT x86_64)
=
System uname: 
Linux-4.16.12-RT-x86_64-AMD_Phenom-tm-_II_X6_1090T_Processor-with-gentoo-2.5
KiB Mem: 8222068 total,   5037600 free
KiB Swap:6291452 total,   6291452 free
Timestamp of repository gentoo: Sun, 27 May 2018 02:30:01 +
Head commit of repository gentoo: 090b200fa862768e5db2ad569d32fa42f495408b
sh bash 4.4_p19
ld GNU ld (Gentoo 2.30 p2) 2.30.0
app-shells/bash:  4.4_p19::gentoo
dev-java/java-config: 2.2.0-r4::gentoo
dev-lang/perl:5.26.2::gentoo
dev-lang/python:  2.7.14-r2::gentoo, 3.5.5-r1::gentoo, 3.6.5-r1::gentoo
dev-util/cmake:   3.11.2::gentoo

[gentoo-user] Vcore unstable?

[mad.scientist.at.large]

i have a machine i just put lm sensors etc. on.  xsensors shows "Vcore" 
fluctuating between 1.12 and 1.3v.  stays at 1.12V when idling but increases 
with load.  Is this remotely normal behavior for an athlon chip in a desk top?  
It's either some sort of throttling or the Vcore power supply is failing, 
obviously i'd like to know which.  If it's the power supply i can likely fix it 
if it needs to be fixed.  Also occurs to me that xsensors could be usefull 
tracking down intermittent issues.  I used it to monitor a power supply i 
wasn't sure about for about a week and it stayed nice.

mad.scientist.at.large (a good madscientist)
--

Re: [gentoo-user] AMD microcode problem - Fam15h ( FYI )

[Corbin Bird]

On 05/25/2018 08:50 PM, Adam Carter wrote:
>
> > For me dmesg says;
> > [    1.538275] microcode: CPU0: patch_level=0x06000852
> >
> > but i still have lwp in /proc/cpuinfo. Are you at 0x06000852 ?
> .
> This is my dmesg output :
> .
> [    1.111448] microcode: microcode updated early to new
> patch_level=0x06000852
>
>
> Ok then it looks like the mno-lwp is responsible for lwp's absence in
> your /proc/cpuinfo.
>
> FWIW, no stability problems for me so far. (FX-8350 + 4.16.11).
>
.
I should have clarified ... the '-mno-lwp' was added as a result of the
comparison of the two /proc/cpuinfo files.I was very curious about WHAT
exactly the microcode update did.

The CPU I am using is a FX-9590.

Question : Is there a PSP in your CPU?

Corbin