Re: Failure to build amd64 current
Thank you so much: yes it would make sense: I would have created the objs dir for the tools but not for the release or something I did a fresh check out of the tree and the full command in one row, with the release this time. I was starting to get an error I had in the past (VCSVersion.h not found) for which only this worked. I understand the build process put things in /usr/src as well. It should work. 🤞 Thank you Matthew! Best, — Germain > On Mar 20, 2023, at 4:27 PM, matthew green wrote: > >  >> >> `./build.sh -j 6 -u -x -U -o -T ../obj/tooldir.NetBSD-9.3-amd64 release >> install-image' > > have you tried without "-o"? that might be the trigger here. > it should work, but maybe it's broken in the src/compat build. > > thanks. > > > .mrg.
Failure to build amd64 current
Hello!
I have amd64/9.3 on which I am trying to build amd64-current.
It dies on errors of the like in gcc/i386:
===8<===8<===
/usr/src/../obj/tooldir.NetBSD-9.3-amd64/bin/x86_64--netbsd-gcc -nodefaultlibs
-shared -Wl,-soname,libgcc_s.so.1 -Wl,--warn-shared-textrel
-Wl,-Map=libgcc_s.so.1.map -m32 --sysroot=/usr/src/obj/destdir.amd64
-nodefaultlibs -Wl,-z -Wl,nodelete
-Wl,--version-script=/usr/src/external/gpl3/gcc.old/lib/libgcc/libgcc_s/libgcc.map
-Wl,-z,relro -o libgcc_s.so.1.0.tmp -Wl,-rpath,/usr/lib/i386
-L=/usr/lib/i386 -Wl,-x -Wl,--whole-archive libgcc_s_pic.a
-Wl,--no-whole-archive -m32
/usr/obj/tooldir.NetBSD-9.3-amd64/bin/../lib/gcc/x86_64--netbsd/10.4.0/../../../../x86_64--netbsd/bin/ld:
i386:x86-64 architecture of input file
`/usr/src/obj/destdir.amd64/usr/lib/../lib/i386/crti.o' is incompatible with
i386 output
...
/usr/obj/tooldir.NetBSD-9.3-amd64/bin/../lib/gcc/x86_64--netbsd/10.4.0/../../../../x86_64--netbsd/bin/ld:
libgcc_s_pic.a(unwind-dw2.pico):unwind-dw2.c:(.text.unlikely+0x1): more
undefined references to `abort' follow
/usr/obj/tooldir.NetBSD-9.3-amd64/bin/../lib/gcc/x86_64--netbsd/10.4.0/../../../../x86_64--netbsd/bin/ld:
libgcc_s_pic.a(enable-execute-stack.pico): file class ELFCLASS64 incompatible
with ELFCLASS32
/usr/obj/tooldir.NetBSD-9.3-amd64/bin/../lib/gcc/x86_64--netbsd/10.4.0/../../../../x86_64--netbsd/bin/ld:
final link failed: file in wrong format
collect2: error: ld returned 1 exit status
*** Failed target: libgcc_s.so.1.0
*** Failed commands:
${_MKTARGET_BUILD}
=> @echo '# ' " build " libgcc_s/libgcc_s.so.1.0
rm -f ${.TARGET}
=> rm -f libgcc_s.so.1.0
${LIBCC} ${LDLIBC} -shared ${SHLIB_SHFLAGS} ${_LDFLAGS.${_LIB}} -o
${.TARGET}.tmp ${_LIBLDOPTS} -Wl,--whole-archive ${SOLIB}
-Wl,--no-whole-archive ${_LDADD.${_LIB}}
=> /usr/src/../obj/tooldir.NetBSD-9.3-amd64/bin/x86_64--netbsd-gcc
-nodefaultlibs -shared -Wl,-soname,libgcc_s.so.1 -Wl,--warn-shared-textrel
-Wl,-Map=libgcc_s.so.1.map -m32 --sysroot=/usr/src/obj/destdir.amd64
-nodefaultlibs -Wl,-z -Wl,nodelete
-Wl,--version-script=/usr/src/external/gpl3/gcc.old/lib/libgcc/libgcc_s/libgcc.map
-Wl,-z,relro -o libgcc_s.so.1.0.tmp -Wl,-rpath,/usr/lib/i386 -L=/usr/
===>8===>8===
`./build.sh -j 6 -u -x -U -o -T ../obj/tooldir.NetBSD-9.3-amd64 release
install-image'
was the command for that run (I had a succesful build of tools before, but
forgot to put `release'.
I am trying now w/ `./build.sh -m amd64 -r -x -U tools release install-image'
(after having nuked my `/usr/obj') but I anticipate it'll fail as well (I tried
other combination of specifying the architecture, removing the parallel jobs.)
Thank you!
Kindest regards,
--
Germain
--
Germain Le Chapelain
Re: HEADS UP: Merging drm update
On Wed, 5 Jan 2022 10:20:45 +0200 Andrius V wrote: > I am also not sure how to redirect boot > messages to serial attached through USB to see if any backtrace is > available. I had the same question actually! I looked around for a bit, even for linux or what and couldn't find something obvious. It sounds like it'd be helpful though! Thank you, Germain -- Germain Le Chapelain
Re: Entropy problem [was Re: CVS Problem (again) ,Slightly lesser old code, but old still [was Re: Console problem ,older code]]
On Fri, 4 Dec 2020 06:42:20 - (UTC) mlel...@serpens.de (Michael van Elst) wrote: > germain.lechapel...@lanvaux.fr (Germain Le Chapelain) writes: > > >This time the crash was in pkg_add itself (=E2=80=98segmentation fault (core= > > dump)=E2=80=99) > > [...] Removing /var/db/pkg/pkgdb.byfile.db and > rebuilding it with "pkg_admin rebuild" helped. Thank you kindly for your answer, Mr. van Elst; Later I came across another email about pkgdb moving from /var/db to /usr/pkg I also got a message about that later on (trying to build from pkgsrc after using pkg_add) the message instructed to simply move the db which sounded a bit too good to be true. After doing so I was getting circular dependencies in cwrappers. I remember the email/ update -I forgot- had additional instructions regarding something-pkg-2020-10-20 and that was actually part of the error message, but.. .. I figured I should not mix pre-built binary install w/ current code. Or at least not do so and complain ;) So I did a blank re-install of current (9.99.76 ?) and I am now back to the earlier problem of the entropy (Re-included riastradh) It's building firefox again, I haven't yet tried any work-around mentioned in the email introducing the change But I am confused about the issue, why this arises. I thought the way randomness was implemented is that you would initialize one seed-number to an amd64 and it would pass you back random #s, anytime and at any rate, *guaranteed* to be random, provided that for sure your initial # was random... Anyways. I will dig in .. things.. Right now , I am going over https://en.wikipedia.org/wiki/RDRAND and I am on board with that so far.. :/ Thank you! Kindest regards, -- Germain Le Chapelain
Re: Entropy problem [was Re: CVS Problem (again) ,Slightly lesser old code, but old still [was Re: Console problem ,older code]]
I have gotten another crash, simply running ‘pkg_add firefox’ This was on a fresh , blank install of 9.1 This time the crash was in pkg_add itself (‘segmentation fault (core dump)’) However, I cannot find a pkg_add.core where it happened I got a message ‘the database in [/usr/pkg/share/applications] could not be updated’ just before. Kindest regards, — Germain > Le 21 nov. 2020 à 18:59, Germain Le Chapelain a écrit : > > On Sat, 21 Nov 2020 00:45:26 -0800 > Germain Le Chapelain wrote: > >> the moment I launched midori, >> >> Then, kernel panic > > I have fallen back to 8.2 for now. > It holds! > > I did get the time out once more, I wonder if it is when the device goes > inactive for a while, but > I was ssh-ing to it. > > Aside from that everything is really hunky-dory, (Actually I find it a better > experience in comparaison to 9.1: > . framebuffer on console > . no extra bootloader menu. Had I messed-up on install?) > > Videos are a little slow in full screen, in spite of i915 seemingly working > perfect (>1000fps on glxgears.) > > This is with firefox68. I'm giving a shot to pkgsrc's as we speak (maybe a > couple days of compilation ;) > Speaking of which this was my 1st time using precompiled binaries. It is > like entering a new dimension :|.) > > I can put up a PR for the crash on 9.1: I kept dump & kernel. > And.. I will be getting back on -current on Dec 1st!.. > > Thank you, > > Kindest regards, > > Germain > > -- > Germain Le Chapelain
Re: Entropy problem [was Re: CVS Problem (again) ,Slightly lesser old code, but old still [was Re: Console problem ,older code]]
On Sat, 21 Nov 2020 00:45:26 -0800 Germain Le Chapelain wrote: > the moment I launched midori, > > Then, kernel panic I have fallen back to 8.2 for now. It holds! I did get the time out once more, I wonder if it is when the device goes inactive for a while, but I was ssh-ing to it. Aside from that everything is really hunky-dory, (Actually I find it a better experience in comparaison to 9.1: . framebuffer on console . no extra bootloader menu. Had I messed-up on install?) Videos are a little slow in full screen, in spite of i915 seemingly working perfect (>1000fps on glxgears.) This is with firefox68. I'm giving a shot to pkgsrc's as we speak (maybe a couple days of compilation ;) Speaking of which this was my 1st time using precompiled binaries. It is like entering a new dimension :|.) I can put up a PR for the crash on 9.1: I kept dump & kernel. And.. I will be getting back on -current on Dec 1st!.. Thank you, Kindest regards, Germain -- Germain Le Chapelain
Re: Entropy problem [was Re: CVS Problem (again) ,Slightly lesser old code, but old still [was Re: Console problem ,older code]]
On Sat, 21 Nov 2020 00:45:26 -0800 Germain Le Chapelain wrote: > I will keep this core on the side, I was dabbling again in X , while scp-ing the crash dump. It was very slow. In my message log: Nov 21 00:56:20 Nima /netbsd: [ 4249.1782296] 0001317c : Nov 21 00:56:20 Nima /netbsd: [ 4249.1782296] 00013180 : 7a006002 Nov 21 00:56:20 Nima /netbsd: [ 4249.1782296] 00013184 : 00024284 Nov 21 00:56:20 Nima /netbsd: [ 4249.1782296] 00013188 : 0 Nov 21 00:56:26 Nima /netbsd: [ 4255.1618669] kern info: [drm] stuck on render ring Nov 21 00:56:26 Nima /netbsd: [ 4255.1618669] kern info: [drm] GPU HANG: ecode 5:0:0x 86fefffc, reason: Ring hung, action: reset Nov 21 00:56:26 Nima /netbsd: [ 4255.1618669] kern error: [drm:(/usr/src/sys/external /bsd/drm2/dist/drm/i915/i915_gem.c:3196)i915_context_is_banned] *ERROR* gpu hanging t oo fast, banning! Nov 21 00:56:26 Nima /netbsd: [ 4255.1618669] drm/i915: Resetting chip after gpu hang Nov 21 00:56:26 Nima /netbsd: [ 4255.1718734] 000115ec : Nov 21 00:56:26 Nima /netbsd: [ 4255.1718734] 000115f0 : 7a006002 Nov 21 00:56:26 Nima /netbsd: [ 4255.1718734] 000115f4 : 00024084 Nov 21 00:56:26 Nima /netbsd: [ 4255.1718734] 000115f8 : Nov 21 00:56:26 Nima /netbsd: [ 4255.1718734] 000115fc : Nov 21 00:56:26 Nima /netbsd: [ 4255.1718734] 00011600 : 7a006002 All the rest is those garbled hexademical numbers. I think my graphic adapter is just faulty on this device. Could it be the root of all my issue on this laptop? -- Germain Le Chapelain
Re: Entropy problem [was Re: CVS Problem (again) ,Slightly lesser old code, but old still [was Re: Console problem ,older code]]
On Fri, 20 Nov 2020 19:32:15 -0800 Germain Le Chapelain wrote: > So I will put on 9.1 for now, but I am happy doing more testing later, So I did, and I was having a blast installing binary package, until the moment I launched midori, Then, kernel panic: (gdb) bt #0 0x80222aaa in cpu_reboot () #1 0x80993216 in vpanic () #2 0x809932c7 in panic () #3 0x80224aed in trap () #4 0x8021d56b in alltraps () #5 0x80abea38 in i915_error_object_create () #6 0x80ac0f44 in i915_capture_error_state () #7 0x80acd2b6 in i915_handle_error () #8 0x808009d9 in linux_workqueue_thread () #9 0x80209747 in lwp_trampoline () #10 0x in ?? () (gdb) source /usr/src/sys/arch/i386/gdbscripts/stack (gdb) stack Cannot access memory at address 0x41033a98 Nima$ crash -M netbsd.core -N netbsd Crash version 9.1, image version 9.1. System panicked: trap Backtrace from time of crash is available. crash> bt _KERNEL_OPT_NARCNET() at 0 ?() at c90041031000 vpanic() at vpanic+0x169 snprintf() at snprintf startlwp() at startlwp calltrap() at calltrap+0x11 i915_capture_error_state() at i915_capture_error_state+0xef1 i915_handle_error() at i915_handle_error+0x89 linux_workqueue_thread() at linux_workqueue_thread+0x14e crash> I will keep this core on the side, I don't really know how to investigate kernel I will retry the latest source (w/ athn.c@1.24 ;p ), maybe debunk more the entropy thing Thank you! Kind regards, -- Germain Le Chapelain
Entropy problem [was Re: CVS Problem (again) ,Slightly lesser old code, but old still [was Re: Console problem ,older code]]
On Fri, 20 Nov 2020 18:20:10 -0800 Germain Le Chapelain wrote: > From it, everything looks great at first glance: > only python is blocked on `entrop/2' in top, and I cannot ping google.fr It is the change https://mail-index.netbsd.org/current-users/2020/05/01/msg038495.html that seems to cause me trouble. I tried applying the work-around steps detailed : o recreate the entropy file o feed urandom to random (or vice-versa) and syctl entropy consildated to 1 But the issues were still there. I need to move on for the next two weeks on that (And have a functional laptop on NetBSD for a business trip before Wednesday, if possible :p.) So I will put on 9.1 for now, but I am happy doing more testing later, (Finger crossed that it will support the Atheros!.) Thank you, Kindest regards -- Germain Le Chapelain (Cc Taylor, for the entropy change)
Re: CVS Problem (again) ,Slightly lesser old code, but old still [was Re: Console problem ,older code]
On Thu, 19 Nov 2020 01:59:28 -0800 Germain Le Chapelain wrote: > I will try soon w/ the code from when I sent the mail two weeks back, So that I got the time out again (I think ? Sorry I should have taken notes.) It was 9.99.68 > Then if it doesn't fix it with the latest (including change from Sunday.) That seemingly cleared the problem (could sync to cvs) I only had the ath0 time out once , I think it was related to low battery (could it?) This code is 9.99.75 Anyways ,I was having a great time, until building in pkgsrc simply halted: I get message looking like : Python 3.7 is blocked waiting for entropy I can no longer ssh into the laptop, >From it, everything looks great at first glance: only python is blocked on `entrop/2' in top, and I cannot ping google.fr I do not have the change from sunday ( athn.c 1.24: Don't unlock without having taken the lock. ) I don't assume this is what will fix, nor that it is related. I will do my homework and look up what `entrop' means in `top' and dig from there Thanks! Kindest regards, Germain -- Germain Le Chapelain
Re: CVS Problem (again) ,Slightly lesser old code, but old still [was Re: Console problem ,older code]
On Thu, 19 Nov 2020 11:14:45 +0100 Martin Husemann wrote: > On Thu, Nov 19, 2020 at 01:59:28AM -0800, Germain Le Chapelain wrote: > > But I wonder if: > > > > 1) I should use netbsd-9 > > 2) Atheros works reliably, > > Both work very well for me, but: there are lots of atheros chip variants, > and bugs often are only triggered by certain wlan AP actions (so I may be > lucky). > > Martin Thank you Martin! I will definitely have another look w/ TCP dump after all that. Then, to whichever debugs of atheros: because it says in the manpage that `device timeouts ain't supposed to happen' I think. I don't think ssh keep alive comes into play here as it wouldn't be more than a couple seconds stall before disconnecting (if there is a stall at all actually.) Oh! And I forgot to mention, to your earlier point about the hard-drive: The computer had a lot of problems while running on Windows: Weird `semi-stalls' when watching youtube: The computer would come to a crawl , the video would freeze and the sound would be slown-down by 10 (and be extremely shoppy: like hearing a 10Hz rendition of the original play back slown down.) Anyways, it would only make sense for the hardware to act up similarly. In fact one of the goal for landing BSD on it was to get a better insight of what could be wrong inside, or if it was only software-related. Thank you again! Kindest regards, -- Germain Le Chapelain
Re: CVS Problem (again) ,Slightly lesser old code, but old still [was Re: Console problem ,older code]
On Wed, 18 Nov 2020 22:41:31 -0800 Germain Le Chapelain wrote: > > Hi ! > > In my attempt to debunk, I ran into another snag: > > While re-checking out pkgsrc, we got : > > client_loop: send disconnect: Broken pipe > cvs [checkout aborted]: end of file from server (conslut above messages if > any) Mm: athn0: device timeout, and in dmesg: athn0: autoconfiguration error: device timeout After that , I can no longer ping the router at 192.168.0.1, and pinging the very machine from its IP (192.168.0.107) is extremely spotty at best I see there are very recent updates (as recent as last sunday.) I will try soon w/ the code from when I sent the mail two weeks back, Then if it doesn't fix it with the latest (including change from Sunday.) But I wonder if: 1) I should use netbsd-9 2) Atheros works reliably, Thank you, Kindest regards, Germain -- Germain Le Chapelain
CVS Problem (again) ,Slightly lesser old code, but old still [was Re: Console problem ,older code]
Hi ! In my attempt to debunk, I ran into another snag: While re-checking out pkgsrc, we got : client_loop: send disconnect: Broken pipe cvs [checkout aborted]: end of file from server (conslut above messages if any) I've had it in the past! What's troubling now is that it is a completely different computer altogether, using Wi-Fi instead of wire, and I got the snapshot wrong so it is a different version for the OS: (9.99.68, the other is 8.99.51) Almost a year appart! I wonder if this could be that we're behind a static IP ? I am pretty sure any mirror will work, once more. Or on Cygwin (that use to work too.) Anyways I will try with the latest sources and report. The image installed like a charm on a Toshiba Tecra though :) Bye-bye Windows! Thank you, Kindest regards, -- Germain On Wed, 4 Nov 2020 20:07:41 -0800 Germain Le Chapelain wrote: > Dear NetBSD, > > > I am experiencing problem switching consoles with the keys ctrl-alt-fn. -- Germain Le Chapelain
Console problem ,older code
Dear NetBSD, I am experiencing problem switching consoles with the keys ctrl-alt-fn. I was dabbling with x11vnc. The screen is black , ctrl-alt-f1-to-9 does nothing. If I type I see what I type (as if a process was running. ctrl-c or whatnot does nothing.) When I picked it up in this state, top was showing x11vnc still running but no X. (The system acced as a server as no problems whatsoever.) end of Xorg.0.log: [537362.838] (II) NOUVEAU(0): Modeline "1600x900"x0.0 106.00 1600 1664 1706 2324 900 903 906 912 -hsync -vsync (45.6 kHz e) [537363.610] Failed to switch from vt05 to vt01: Device busy [537364.410] Failed to switch from vt05 to vt01: Device busy [537365.083] Failed to switch from vt05 to vt02: Device busy [537365.948] Failed to switch from vt05 to vt03: Device busy [537367.786] Failed to switch from vt05 to vt01: Device busy [537368.794] Failed to switch from vt05 to vt01: Device busy [537369.128] Failed to switch from vt05 to vt02: Device busy [537369.793] Failed to switch from vt05 to vt03: Device busy [537370.282] Failed to switch from vt05 to vt04: Device busy [537490.248] Failed to switch from vt05 to vt01: Device busy [537491.177] Failed to switch from vt05 to vt02: Device busy [537491.231] Failed to switch from vt05 to vt02: Device busy [609487.625] Failed to switch from vt05 to vt01: Device busy [609488.856] Failed to switch from vt05 to vt01: Device busy [609489.594] Failed to switch from vt05 to vt02: Device busy [609490.538] Failed to switch from vt05 to vt02: Device busy [609491.259] Failed to switch from vt05 to vt03: Device busy [609492.107] Failed to switch from vt05 to vt04: Device busy [609494.157] Failed to switch from vt05 to vt06: Device not configured [609496.607] Failed to switch from vt05 to vt01: Device busy [609497.519] Failed to switch from vt05 to vt02: Device busy [609500.684] Failed to switch from vt05 to vt02: Device busy [609501.748] Failed to switch from vt05 to vt02: Device busy [609502.405] Failed to switch from vt05 to vt03: Device busy [611645.475] (II) UnloadModule: "kbd" [611645.475] (II) UnloadModule: "mouse" [611645.482] (II) NOUVEAU(0): NVLeaveVT is called. [611659.495] (II) Server terminated successfully (0). Closing log file. (So I may have quit the session properly. Sorry this was a few days back.) I run an older version of HEAD: germ$ uname -a NetBSD germ 8.99.51 NetBSD 8.99.51 (GENERIC) #2: Thu Jul 18 16:25:29 PDT 2019 german@germ:/home/german/work/netbsd/src/sys/arch/amd64/compile/obj/GENERIC amd64 everything by default (I think nouveau was coming in by default ? Maybe I enabled it, either way I use it for my NVidia. germ$ cat /etc/ttys # # from: @(#)ttys 5.1 (Berkeley) 4/17/89 # $NetBSD: ttys,v 1.6 2012/06/13 20:49:12 martin Exp $ # # name getty typestatus comments # console "/usr/libexec/getty Pc" wsvt25 on secure constty "/usr/libexec/getty Pc" wsvt25 off secure ttyE0 "/usr/libexec/getty Pc" wsvt25 off secure ttyE1 "/usr/libexec/getty Pc" wsvt25 on secure ttyE2 "/usr/libexec/getty Pc" wsvt25 on secure ttyE3 "/usr/libexec/getty Pc" wsvt25 on secure tty00 "/usr/libexec/getty std.9600" unknown off secure tty01 "/usr/libexec/getty std.9600" unknown off secure tty02 "/usr/libexec/getty std.9600" unknown off secure tty03 "/usr/libexec/getty std.9600" unknown off secure tty04 "/usr/libexec/getty std.9600" unknown off secure tty05 "/usr/libexec/getty std.9600" unknown off secure tty06 "/usr/libexec/getty std.9600" unknown off secure tty07 "/usr/libexec/getty std.9600" unknown off secure g I can certainly restart, update and retry. We can even switch to a proper release instead. Is this actually a better way for us ? (It is a production system, but the service is absolutely non-essential, so we are happy to test.) I came here for the education. I remember running into problems around there before too. What would *YOU* do ? ;) Thank you! Kindest regards, -- Germain Le Chapelain for Lanvaux Computer Games Limited
Fw: (Not so) New Install
Hi! So I have been running on a new install (8.99?) since a few weeks now. I tried UEFI first (because I am not sure what it is about) and that would stall on start-up. I have a T510. I forgot the error message sorry. Anyways the other version works great. I figured I would start a new thread with the problems [1] [2] I had before as well as the new ones: (Feels like it belongs in netbsd-current more than netbsd-users where they were before.) o CVS: I am still getting the `broken pipe' error when trying to sync from the main server. I will try commenting out locally the key that comes with the install, o Attaching GDB to a process: - Effectively I am not seeing the problem of seeing a thread twice anymore. So that's a big plus! (That was the leading reason for the update.) - the GDB front-end of XEmacs is now slightly broken and showing what seems to be control characters where the colors of the debug text should change (For instance: "(gdb) bt #0 [34m0x7f32d444295a[m in [33mread[m () from /usr/lib/libc.so.12") That's really not a big deal though. I suppose I should be using plain GDB. Even better it forced me into giving another shot at the real Emacs (as opposed to XEmacs) and I have to say it's quite the killer with all those frames. - A few packages did not compile/install out of the box for me. I kept the log (with the errors) I can open individual PRs and/or start looking on my side. From memory among them were: . MLDonkey . Firefox As always, thank you for all the softwares! Kind regards, Germain [1] http://mail-index.netbsd.org/netbsd-users/2019/05/18/msg022899.html [2] http://mail-index.netbsd.org/netbsd-users/2019/01/24/msg022102.html -- Germain Le Chapelain Software Engineer Lanvaux
