Failing to crosscompile on Linux

[Mandacarú Cascavel]

Hi, Friends.

NetBSD-current (-m amd64) stops the crosscompilling process on a Debian amd64 
unstable box in the following place:

cc  -O   -o make  ar.o arscan.o  commands.o default.o dir.o  expand.o file.o 
function.o  getopt.o getopt1.o implicit.o  job.o main.o misc.o  read.o remake.o 
remote-stub.o  rule.o signame.o strcache.o  variable.o version.o vpath.o  
hash.o glob/libglob.a 
glob/libglob.a(glob.o): In function `glob_in_dir':
glob.c:(.text+0x2c0): undefined reference to `__alloca'
glob.c:(.text+0x3b4): undefined reference to `__alloca'
glob.c:(.text+0x4a0): undefined reference to `__alloca'
glob.c:(.text+0x5a3): undefined reference to `__alloca'
glob/libglob.a(glob.o): In function `glob':
glob.c:(.text+0xadb): undefined reference to `__alloca'
glob/libglob.a(glob.o):glob.c:(.text+0xbe6): more undefined references to 
`__alloca' follow
collect2: error: ld returned 1 exit status

*** Failed target:  make
*** Failed command: cc -O -o make ar.o arscan.o commands.o default.o dir.o 
expand.o file.o function.o getopt.o getopt1.o implicit.o job.o main.o misc.o 
read.o remake.o remote-stub.o rule.o signame.o strcache.o variable.o version.o 
vpath.o hash.o glob/libglob.a 
*** Error code 1

Stop.
nbmake[10]: stopped in /home/usuario/netbsd/obj/tools/gmake/build

This is repeatedly happening from some days ago.

-- 
Mandacarú Cascavel 

Re: Failing to crosscompile on Linux

[Joerg Sonnenberger]

On Wed, Mar 28, 2018 at 06:08:46AM -0300, Mandacarú Cascavel wrote:
> NetBSD-current (-m amd64) stops the crosscompilling process on a Debian amd64 
> unstable box in the following place:

Well, find out what provides alloca -> __alloca on Debian? That seems
broken, it should always map to __builtin_alloca or remain as is.

Joerg

Re: nfs client issue at netbsd-8

[rjs]

On 2018-03-28 18:23, 6b...@6bone.informatik.uni-leipzig.de wrote:

Any ideas how to narrow down the cause?


I would try it with fewer mount options if you can, you seemed to be 
using

everything available in the original email.

Re: Kernel RNG ???

[Fredrik Pettai]

Hi,

I’ve stumbled upon this too with recently upgraded machine (to NetBSD 8.0_BETA 
(GENERIC.201803261630Z))

Kernel RNG “5887 68 5” runs test FAILURE: too many runs of 1 1s (2691 >=2685)
cprng 5887 68 5: failed statistical RNG test

The difference here is that the machine also loses network connectivity (& the 
USB keyboard).
unplugging / replugging the keyboard doesn’t show that the kernel is still 
working on the console.
(you’d expect to see output about the usb device unplugged / replugged)

I also tried to add a watchdog to reboot the server then it hangs, but that 
isn’t working, so it’s a weird state it hangs in…

# wdogctl
Available watchdog timers:
ipmi0, 0 second period
tco0, 30 second period [armed, user tickle, pid 441]

Any ideas ?

/P

> On 20 May 2015, at 23:46, Paul Goyette  wrote:
> 
> Perhaps we could make the messages a little bit less frightening?
> 
> Perhaps s/FAILURE/NOTICE/
> 
> 
> 
> On Wed, 20 May 2015, Christos Zoulas wrote:
> 
>> In article 
>> ,
>> <6b...@6bone.informatik.uni-leipzig.de> wrote:
>>> Hello,
>>> 
>>> dmesg reported:
>>> 
>>> Kernel RNG "2105 0 2" runs test FAILURE: too many runs of 3 1s (728 > 723)
>>> cprng 2105 0 2: failed statistical RNG test
>>> 
>>> Any ideas what could be the problem?
>>> 
>>> 
>>> kernel version: NetBSD 7.99.9
>>> distribution: netbsd-7 (version May 11)
>> 
>> It is not really a problem. Things like this can happen. If you see messages
>> like this continuously, then there is a problem. In current a bunch of RNG
>> diagnostic messages have been turned on in order to evaluate the quality
>> of the random number generation.
>> 
>> christos
>> 
>> 
> 
> -
> | Paul Goyette | PGP Key fingerprint: | E-mail addresses:   |
> | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
> | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org  |
> -

Re: Failing to crosscompile on Linux

[Mandacarú Cascavel]

On Wed, 28 Mar 2018 12:55:06 +0200
Joerg Sonnenberger  wrote:

> On Wed, Mar 28, 2018 at 06:08:46AM -0300, Mandacarú Cascavel wrote:
> > NetBSD-current (-m amd64) stops the crosscompilling process on a Debian 
> > amd64 unstable box in the following place:
> 
> Well, find out what provides alloca -> __alloca on Debian? That seems
> broken, it should always map to __builtin_alloca or remain as is.
> 
> Joerg

Danke, Joerg.
-- 
Mandacarú Cascavel 

daily CVS update output

[NetBSD source update]

Updating src tree:
P src/distrib/amd64/uefi-installimage/Makefile
P src/external/gpl3/gcc/dist/gcc/config/i386/constraints.md
P src/external/gpl3/gcc/dist/gcc/config/i386/i386-opts.h
P src/external/gpl3/gcc/dist/gcc/config/i386/i386-protos.h
P src/external/gpl3/gcc/dist/gcc/config/i386/i386.c
P src/external/gpl3/gcc/dist/gcc/config/i386/i386.h
P src/external/gpl3/gcc/dist/gcc/config/i386/i386.md
P src/external/gpl3/gcc/dist/gcc/config/i386/i386.opt
P src/external/gpl3/gcc/dist/gcc/config/i386/predicates.md
P src/external/gpl3/gcc/dist/gcc/doc/extend.texi
P src/external/gpl3/gcc/dist/gcc/doc/invoke.texi
P src/external/gpl3/gcc.old/dist/gcc/config/i386/constraints.md
P src/external/gpl3/gcc.old/dist/gcc/config/i386/i386-opts.h
P src/external/gpl3/gcc.old/dist/gcc/config/i386/i386-protos.h
P src/external/gpl3/gcc.old/dist/gcc/config/i386/i386.c
P src/external/gpl3/gcc.old/dist/gcc/config/i386/i386.h
P src/external/gpl3/gcc.old/dist/gcc/config/i386/i386.md
P src/external/gpl3/gcc.old/dist/gcc/config/i386/i386.opt
P src/external/gpl3/gcc.old/dist/gcc/config/i386/predicates.md
P src/external/gpl3/gcc.old/dist/gcc/doc/extend.texi
P src/external/gpl3/gcc.old/dist/gcc/doc/invoke.texi
P src/sys/arch/amd64/amd64/amd64_trap.S
P src/sys/arch/amd64/amd64/locore.S
P src/sys/arch/amd64/include/frameasm.h
P src/sys/arch/macppc/dev/pmu.c
P src/sys/arch/mips/mips/locore.S
P src/sys/arch/x86/conf/files.x86
P src/sys/arch/x86/x86/cpu.c
P src/sys/arch/x86/x86/cpu_ucode.c
U src/sys/arch/x86/x86/spectre.c
P src/sys/dev/sbus/mgx.c
P src/sys/netinet/tcp_input.c
P src/sys/netinet/tcp_var.h
P src/tools/gcc/gcc-version.mk
P src/usr.sbin/makefs/cd9660/cd9660_eltorito.c

Updating xsrc tree:


Killing core files:




Updating file list:
-rw-rw-r--  1 srcmastr  netbsd  51966121 Mar 29 03:03 ls-lRA.gz

Re: nfs client issue at netbsd-8

[6bone]

On Fri, 23 Mar 2018, SAITOH Masanobu wrote:


How old is your kernel?

If your kernel's ixgbe.c is older than 1.88.2.13 please update the latest
netbsd-8 and try. 1.88.2.13 (and 1.88.2.10) fixed serious interrupt problem.



I changed from 1.88.2.10 to 1.88.2.13. The problem was not solved. I have 
also tested the onboeard network card. After a few hours, the problem also 
occurred here. I still think it's a nfs problem.


It seems like the whole system is blocked. Not just the network. If no nfs 
drives are mounted, the problems will not occur.


Any ideas how to narrow down the cause?

Many thanks for you efforts

Regards
Uwe

Re: nfs client issue at netbsd-8

[Manuel Bouyer]

On Wed, Mar 28, 2018 at 06:23:56PM +0200, 6b...@6bone.informatik.uni-leipzig.de 
wrote:
> I changed from 1.88.2.10 to 1.88.2.13. The problem was not solved. I have
> also tested the onboeard network card. After a few hours, the problem also
> occurred here. I still think it's a nfs problem.
> 
> It seems like the whole system is blocked. Not just the network. If no nfs
> drives are mounted, the problems will not occur.
> 
> Any ideas how to narrow down the cause?

Can you enter ddb ? If so, can you see is some soft interrupt thread is
blocked ?

I also use NFS on a netbsd-8 host, without problems.

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--