Re: amd64-current live image build failure
> cat work.mbr.truncated work.efi imgroot.fs work.gpt > work.img
> /dumps/sysbuild/amd64/tools/bin/nbgpt work.img biosboot -i 2
> -c
> /dumps/sysbuild/amd64/obj/home/sysbuild/src/distrib/amd64/liveimage/emuimage/work/usr/mdec/gptmbr.bin
> nbgpt: work.img: No primary GPT header; run create or recover
If you are trying an update build (with -u) and your previous build
was using source tree files before UEFI changes against liveimage,
https://mail-index.netbsd.org/source-changes/2024/04/13/msg150802.html
a stale work.mbr (${WORKMBR}) image doesn't contain GPT (but MBR)
so ${TOOL_GPT} on the update build may fail.
The similar issue (against the secondary GPT headers) occured
if IMAGE size is changed:
https://gnats.netbsd.org/56132
Maybe we should note it (remove work.mbr on updating builds)
in doc/UPDATING?
---
Izumi Tsutsui
Re: fdisk and alignment
> I was using fdisk to setup a USB key on NetBSD-10 and noticed its > still defaulting to 63 sector offset, including when "1m" is entered: fdisk(8) man says: > -A ptn_alignment[/ptn_0_offset] [..] >If > the first partition is not defined then the alignment and offset > for disks larger than 128GB is set to 2048 (1MB). --- Izumi Tsutsui
Re: FYI: new X server in -current, among other X things
mrg@ wrote: > > > (1) out of bounds problem in xserver/hw/xfree86/modes/xf86Crtc.h [snip] > this looks simple enough to just do. > > > (2) "-flipPixels" option removal [snip] > go for it. Both committed. Thanks! https://mail-index.netbsd.org/source-changes/2022/07/30/msg140050.html https://mail-index.netbsd.org/source-changes/2022/07/30/msg140049.html > we have a few things reverted, we maybe should > talk to upstream to have them either revert there or at least > provide the removed features elsewhere. I filed issues and mentioned if these mono support could be reverted, but no positive comments. https://gitlab.freedesktop.org/xorg/xserver/-/issues/1057 Maybe we should prepare gitlab merge request, but I'm not sure if non-member can do it.. --- Izumi Tsutsui
Re: FYI: new X server in -current, among other X things
I wrote:
> mrg@ wrote:
>
> > i've updated most of xsrc to their latest versions.
> > fontconfig and Mesa are remaining. i've tested the
> > new code on amd64 and arm64, and built several ports
> > to confirm they still build. the biggest change is
> > the new xorg-server.
>
> On 1.21.x, I'm afraid there are two known issue for ancient Tier-II ports.
>
>
> (1) out of bounds problem in xserver/hw/xfree86/modes/xf86Crtc.h
>
> OpenBSD/luna88k maintainer (Kenji Aoyama) reported the following fix
> was neceesary for non-XFree86 driver based dumb server (on luna88k etc.):
> https://gist.github.com/ao-kenji/afb0ea5b6dca04975161f84ab41ba32b
> https://gist.github.com/ao-kenji/b0fd6b876605ba1b2b43309233566153
>
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/xserver/hw/xfree86/modes/xf86Crtc.h#rev1.16
I turns out that at least luna68k Xorg server (happens to?) works
without this change, but anyway upstream 1.22.x branch already
has this fix:
https://gitlab.freedesktop.org/xorg/xserver/-/commit/75d70612888f18339703315549db781a22c0cb23
I wonder if we should pull this fix or not for our (1.)21.1.4 tree..
> (2) "-flipPixels" option removal
>
> "-flipPixels" option (that inverts black and white on 1bpp server)
> has been removed since 1.21.
>
> https://gitlab.freedesktop.org/xorg/xserver/-/commit/d1c00c859c6676fbb540420c9055788bc19cb18f
>
> As noted in the log the upstream authors claim
> "No supported driver supports 1bpp anymore, nor has in a very long time."
>
> Howeverwe we still have several working servers (xf86-video-wsfb based
> servers on mac68k and luna68k, monolithic servers for sun3 and x68)
> and at least there was a report that this option was mandatory on SE/30.
> So I would like to revert this change.
It also turns out that the above changes also remove a menber from
ScrnInfoRec structure in hw/xfree86/common/xf86str.h and it breaks
ABIs of xf86-video-* drivers.
However fortunately the removed member "Bool flipPixels" in the
SrcnInfoRec has not been used for -flipPixels options so we can
safely pull back -flipPixels support by reverting the changes
except xf86str.h.
If there is no particular comments I would like to commit the
attached (reverting -flipPixels removal) patch.
---
Index: external/mit/xorg-server/dist/hw/xfree86/common/xf86.h
===
RCS file: /cvsroot/xsrc/external/mit/xorg-server/dist/hw/xfree86/common/xf86.h,v
retrieving revision 1.5
diff -u -p -d -r1.5 xf86.h
--- external/mit/xorg-server/dist/hw/xfree86/common/xf86.h 15 Jul 2022
02:18:59 - 1.5
+++ external/mit/xorg-server/dist/hw/xfree86/common/xf86.h 24 Jul 2022
14:58:35 -
@@ -79,6 +79,14 @@ extern _X_EXPORT Bool xf86DRI2Enabled(vo
#define XF86SCRNINFO(p) xf86ScreenToScrn(p)
+#define XF86FLIP_PIXELS() \
+ do { \
+ if (xf86GetFlipPixels()) { \
+ pScreen->whitePixel = (pScreen->whitePixel) ? 0 : 1; \
+ pScreen->blackPixel = (pScreen->blackPixel) ? 0 : 1; \
+ } \
+ while (0)
+
#define BOOLTOSTRING(b) ((b) ? "TRUE" : "FALSE")
/* Compatibility functions for pre-input-thread drivers */
@@ -278,6 +286,8 @@ xf86GetWeight(void);
extern _X_EXPORT Gamma
xf86GetGamma(void);
extern _X_EXPORT Bool
+xf86GetFlipPixels(void);
+extern _X_EXPORT Bool
xf86ServerIsExiting(void);
extern _X_EXPORT Bool
xf86ServerIsResetting(void);
Index: external/mit/xorg-server/dist/hw/xfree86/common/xf86Globals.c
===
RCS file:
/cvsroot/xsrc/external/mit/xorg-server/dist/hw/xfree86/common/xf86Globals.c,v
retrieving revision 1.1.1.7
diff -u -p -d -r1.1.1.7 xf86Globals.c
--- external/mit/xorg-server/dist/hw/xfree86/common/xf86Globals.c 15 Jul
2022 02:12:51 - 1.1.1.7
+++ external/mit/xorg-server/dist/hw/xfree86/common/xf86Globals.c 24 Jul
2022 14:58:35 -
@@ -188,6 +188,7 @@ int xf86FbBpp = -1;
int xf86Depth = -1;
rgb xf86Weight = { 0, 0, 0 };
+Bool xf86FlipPixels = FALSE;
Gamma xf86Gamma = { 0.0, 0.0, 0.0 };
Bool xf86AllowMouseOpenFail = FALSE;
Index: external/mit/xorg-server/dist/hw/xfree86/common/xf86Helper.c
===
RCS file:
/cvsroot/xsrc/external/mit/xorg-server/dist/hw/xfree86/common/xf86Helper.c,v
retrieving revision 1.6
diff -u -p -d -r1.6 xf86Helper.c
--- external/mit/xorg-server/dist/hw/xfree86/common/xf86Helper.c15 Jul
2022 02:18:59 - 1.6
+++ external/mit/xorg-server/dist/hw/xfree86/common/xf86Helper.c24 Jul
2022 14:58:36 -
@@ -952,8 +952,14 @@ xf86SetDpi(ScrnInfoPtr pScrn, int x, int
void
xf86SetBlackWhitePixels(ScreenPtr pScreen)
{
-pScreen->whitePixel = 1;
-pScreen->blackPixel = 0;
+if (xf86FlipPixels) {
+pScreen->whitePixel = 0;
+pScreen->blackPixel = 1;
+}
+else {
+pScreen->whitePixel = 1;
+pScreen->blackPixel = 0;
+}
}
/*
@@
Re: FYI: new X server in -current, among other X things
Thanks for your work. mrg@ wrote: > i've updated most of xsrc to their latest versions. > fontconfig and Mesa are remaining. i've tested the > new code on amd64 and arm64, and built several ports > to confirm they still build. the biggest change is > the new xorg-server. On 1.21.x, I'm afraid there are two known issue for ancient Tier-II ports. (1) out of bounds problem in xserver/hw/xfree86/modes/xf86Crtc.h OpenBSD/luna88k maintainer (Kenji Aoyama) reported the following fix was neceesary for non-XFree86 driver based dumb server (on luna88k etc.): https://gist.github.com/ao-kenji/afb0ea5b6dca04975161f84ab41ba32b https://gist.github.com/ao-kenji/b0fd6b876605ba1b2b43309233566153 https://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/xserver/hw/xfree86/modes/xf86Crtc.h#rev1.16 (2) "-flipPixels" option removal "-flipPixels" option (that inverts black and white on 1bpp server) has been removed since 1.21. https://gitlab.freedesktop.org/xorg/xserver/-/commit/d1c00c859c6676fbb540420c9055788bc19cb18f As noted in the log the upstream authors claim "No supported driver supports 1bpp anymore, nor has in a very long time." Howeverwe we still have several working servers (xf86-video-wsfb based servers on mac68k and luna68k, monolithic servers for sun3 and x68) and at least there was a report that this option was mandatory on SE/30. So I would like to revert this change. I've filed several issue reports about the 1bpp server including this, but it looks the upstream has ~no interest to keep it. https://gitlab.freedesktop.org/xorg/xserver/-/issues/1057 https://gitlab.freedesktop.org/xorg/xserver/-/issues/1056 Thanks, --- Izumi Tsustui
Re: i386/amd64 image generated trough mkimage stuck on primary bootsrap at boot
mlelstv@ wrote:
> r...@sdf.org (RVP) writes:
>
> >@@ -255,7 +255,7 @@
> > echo ${bar} Populating ffs filesystem ${bar}
> > ${MAKEFS} -rx ${endian} -N ${release}/etc -t ffs \
> > -O ${ffsoffset} \
> >--o d=4096,f=8192,b=65536 -b $((${extra}))m \
> >+-o d=8192,f=2048,b=16384 -b $((${extra}))m \
> > -F "$tmp/selected_sets" ${image} "${release}" "${mnt}"
>
>
> Sounds like the disklabel is incorrect then. FFS requires that
> the fragment size (not so much the blocksize) is correct, but the
> scripts seem to be inconsistent.
>
> N.B. unset fsize (== 0) defaults to fsize = BLKDEV_IOSIZE (== 2048).
I doubt recent newfs(8) or bootloaders refer bsize and fsize
in disklabel.
IIRC libsa/sa/ufs.c requires large heapsize to read blocksize,
from ffs, so sometimes it fails to load on blocksize=65536 fs.
(but I'm nots sure 64KB blocksize is valied on FFS because
newfs(8) man page just says 4KB-32KB for it)
---
Izumi Tsutsui
Re: Script to create bootable arm images?
martin@ wrote:
> On Thu, Jun 23, 2022 at 02:17:28PM -0600, Brook Milligan wrote:
> > Is there a script somewhere that is being used to create the bootable
> > arm issues that are available on https://nycdn.netbsd.org/pub/arm/? If
> > so, where?
>
> It is build by build.sh, e.g. this is the invocation for a recent earmv7hf
> build run:
>
> ===> build.sh command:/home/source/ab/HEAD/src/build.sh -m evbarm -a
> earmv7hf -B 202206240040Z -V NETBSD_OFFICIAL_RELEASE=no -D
> /home/builds/ab/HEAD/evbarm-earmv7hf/202206240040Z-dest -M
> /home/builds/ab/HEAD/evbarm-earmv7hf/202206240040Z-obj -R
> /home/builds/ab/HEAD/evbarm-earmv7hf/202206240040Z-rlse -T
> /home/builds/ab/HEAD/evbarm-earmv7hf/202206240040Z-tools -U -X
> /home/source/ab/HEAD/xsrc -P -x -N2 -V TMPDIR=/tmp -V BUILD=yes -V
> MAKECONF=/home/builds/etc/make.conf -V MKDEBUG=yes -j16 release install-image
I doubt install-image supports all arm's ones.
I guess several of them use src/distrib/embedded.
- "build.sh install-image" uses "install_image" targets in
src/distrib/${MACHINE}/Makefile, currently prepared for
amd64, evbarm (looks like only for UEFI based ones?), i386
- for several arm boards such as Raspberry Pi etc, the image binaries
are built during "make release" in src/etc by scripts and Makefile
in src/distrib/embedded and they are invoked from
src/etc/etc.evbarm/Makefile.inc via targets like "snap_md_post" and
"smp_rpi" etc.
- src/distrib/utils/embedded/mkimage calls makefs(8), fdisk(8),
disklabel(8), and other tools to create board specific images
persrc/distrib/utils/embedded/conf/${h}.conf settings
---
Izumi Tsutsui
Re: High vm scan rate and dropped keystrokes thru X?
> NetBSD 9.2, amd64, 16GiB RAM, quad core + hyperthreading. > > I've repeatedly noticed an issue where a large amount of disk reads can > result in lost keystrokes, jerky mouse behaviour and other weirdness. : > "vmstat 1" during these events shows climbing runqueue, falling free > memory, high reclaim rate, very high scan rate, and 8 CPUs worth of > system time - and I hear the BIOS spinning up the CPU fan. What "vmstat -m" shows? if kmem-160 (or kmem-192) has a large number, maybe caused by radeondrmkms(4) leaks. https://mail-index.netbsd.org/netbsd-bugs/2021/07/12/msg072460.html --- Izumi Tsutsui
Re: Anyone feel like fixing pkgsrc/emulators/tme ?
I wrote:
> The attached blind patch seems to work around on NetBSD/i386 9.2.
But still fails on NetBSD/amd64 9.2.
The debug build says:
---
% tmesh SUN4-75
assertion "extend >= TME_RECODE_SIZE_8 && extend < ic->tme_recode_ic_reg_size"
failed: file "./host/x86/rc-x86-insns.c", line 341, function
"_tme_recode_x86_insn_ext"
Abort (core dumped)
%
---
gdb says:
---
% gdb /s/obj.x86_64/pkgsrc/emulators/tme/work.x86_64/tme-0.8/tmesh/.libs/tmesh
GNU gdb (GDB) 8.3
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64--netbsd".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from
/s/obj.x86_64/pkgsrc/emulators/tme/work.x86_64/tme-0.8/tmesh/.libs/tmesh...
(gdb) run SUN4-75
Starting program:
/s/obj.x86_64/pkgsrc/emulators/tme/work.x86_64/tme-0.8/tmesh/.libs/tmesh SUN4-75
assertion "extend >= TME_RECODE_SIZE_8 && extend < ic->tme_recode_ic_reg_size"
failed: file "./host/x86/rc-x86-insns.c", line 341, function
"_tme_recode_x86_insn_ext"
Program received signal SIGABRT, Aborted.
0x76c0bcf679aa in _lwp_kill () from /usr/lib/libc.so.12
(gdb) bt
#0 0x76c0bcf679aa in _lwp_kill () from /usr/lib/libc.so.12
#1 0x76c0bcf6725a in abort () at /usr/src/lib/libc/stdlib/abort.c:74
#2 0x76c0bcea8507 in __assert13 (file=,
line=, function=, failedexpr=)
at /usr/src/lib/libc/gen/assert.c:72
#3 0x76c0c6c0e54e in _tme_recode_x86_insn_ext (ic=0x76c0c727b000,
insn=0x7f7fffb09330) at ./host/x86/rc-x86-insns.c:340
#4 0x76c0c6c120d7 in _tme_recode_x86_tlb_busy (ic=0x76c0c727b000,
address_type=0x7f7fffb09454, x86_tlb_type=0x7f7fffb093b0)
at ./host/x86/rc-x86-tlb.c:198
#5 0x76c0c6c143e1 in _tme_recode_x86_chain_subs (ic=0x76c0c727b000,
chain=0x7f7fffb09450, chain_thunk=0x76c0c735b240,
chain_info_call_or_return=16) at ./host/x86/rc-x86-chain.c:787
#6 0x76c0c6c15271 in tme_recode_chain_thunk (ic=0x76c0c727b000,
chain=0x7f7fffb09450) at ./host/x86/rc-x86-chain.c:1645
#7 0x76c0b942dd9c in _tme_sparc32_recode_chain_init (ic=0x76c0c6ebf280)
at sparc-rc-chain.c:511
#8 0x76c0b943481a in tme_sparc_recode_init (ic=0x76c0c6ebf280)
at sparc-recode.c:998
#9 0x76c0b942359f in tme_sparc_new (ic=0x76c0c6ebf280,
args=0x76c0c735b1c0, extra=0x0, _output=0x7f7fffb09718) at sparc-misc.c:855
#10 0x76c0b943d084 in tme_ic_sparc_LTX_cy7c601_new (
element=0x76c0c73533c8, args=0x76c0c735b1c0, extra=0x0,
_output=0x7f7fffb09718) at cy7c601.c:259
--Type for more, q to quit, c to continue without paging--
#11 0x76c0c6c1638b in tme_element_new (element=0x76c0c73533c8,
args=0x76c0c735b1c0, extra=0x0, _output=0x7f7fffb09718) at element.c:188
#12 0x76c0c7005890 in _tmesh_command_connect (tmesh=0x76c0c7343000,
value=0x7f7fffb09690, _output=0x7f7fffb09718) at tmesh-cmds.c:587
#13 0x76c0c7005ffd in tmesh_eval (_tmesh=0x76c0c7343000,
_output=0x7f7fffb09718, _yield=0x7f7fffb09704) at tmesh-cmds.c:899
#14 0x004026a5 in main (argc=2, argv=0x7f7fffb097d8) at tmesh.c:631
(gdb)
---
So it looks disabling "x86" on x86_64 (as kludge) seems to work around:
---
$NetBSD: patch-configure,v 1.1 2020/08/13 05:59:52 tsutsui Exp $
- Fix wrong comparison.
--- configure.orig 2010-06-05 19:57:30.0 +
+++ configure
@@ -12948,7 +12948,7 @@ echo $ECHO_N "checking for target recode
# get the host recode parts:
case "${target}" in
-i[3456789]86-*-netbsd* | x86_64-*-netbsd* | i[3456789]86-*-linux*)
+i[3456789]86-*-netbsd* | i[3456789]86-*-linux*)
recode_hosts="mmap x86"
;;
*) recode_hosts= ;;
@@ -12980,12 +12980,12 @@ fi
{ echo "$as_me:$LINENO: checking for target miscellaneous support" >&5
echo $ECHO_N "checking for target miscellaneous support... $ECHO_C" >&6; }
case "${target}" in
-i[3456789]86-* | x86_64-*) misc_hosts="x86" ;;
+i[3456789]86-*) misc_hosts="x86" ;;
*) misc_hosts=no ;;
esac
{ echo "$as_me:$LINENO: result: ${misc_hosts}" >&5
echo "${ECHO_T}${misc_hosts}" >&6; }
-if test "x${misc_hosts}" = no; then
+if test "x${misc_hosts}" = xno; then
misc_hosts=
fi
---
Izumi Tsutsui
Re: Anyone feel like fixing pkgsrc/emulators/tme ?
> > but starting tmesh via gdb works??
>
> i've had some crashes with pkgsrc/graphics/blender lately that
> go away in gdb. (it's kinda annoying, the -g enabled blender
> takes a really long time for gdb to load...)
The attached blind patch seems to work around on NetBSD/i386 9.2.
(even I'm not sure what PROT_MPROTECT() expects..)
---
$NetBSD$
--- libtme/host/recode-mmap.c.orig 2008-07-01 02:00:53.0 +
+++ libtme/host/recode-mmap.c
@@ -82,7 +82,12 @@ tme_recode_host_thunks_alloc(struct tme_
size_run,
(PROT_READ
| PROT_WRITE
-| PROT_EXEC),
+#ifdef PROT_MPROTECT
+| PROT_MPROTECT(PROT_EXEC)
+#else
+| PROT_EXEC
+#endif /* PROT_MPROTECT */
+),
(MAP_SHARED
#ifdef MAP_ANON
| MAP_ANON
---
Izumi Tsutsui
Re: Anyone feel like fixing pkgsrc/emulators/tme ?
r through a macro: No such file or directory [/display0.0]: cannot generate keysym 'R6' directly, or through a macro: No such file or directory [/display0.0]: cannot generate keysym 'R5' directly, or through a macro: No such file or directory [/display0.0]: cannot generate keysym 'R4' directly, or through a macro: No such file or directory [/display0.0]: cannot generate keysym 'acute' directly, or through a macro: No such file or directory [/display0.0]: cannot generate keysym 'SunUndo' directly, or through a macro: No such file or directory [/display0.0]: cannot generate keysym 'SunProps' directly, or through a macro: No such file or directory [/display0.0]: cannot generate keysym 'R3' directly, or through a macro: No such file or directory [/display0.0]: cannot generate keysym 'R2' directly, or through a macro: No such file or directory [/display0.0]: cannot generate keysym 'R1' directly, or through a macro: No such file or directory [/display0.0]: cannot generate keysym 'SunF37' directly, or through a macro: No such file or directory [/display0.0]: cannot generate keysym 'SunF36' directly, or through a macro: No such file or directory [/display0.0]: cannot generate keysym 'SunAgain' directly, or through a macro: No such file or directory [/display0.0]: cannot generate keysym 'SunStop' directly, or through a macro: No such file or directory [/display0.0]: cannot generate keysym 'SunAltGraph' directly, or through a macro: No such file or directory tmesh> --- Not sure what happens though. Note sun3 emulation works fine even on NetBSD/i386 9.2 + pkgsrc-2021Q2 so this seems sun4c emulation specific. --- Izumi Tsutsui
Re: -current build.sh install-image failure
> > > /home/sysbuild/amd64/tools/bin/nbgpt work.img biosboot -i 2 > > > -c > > > /home/sysbuild/amd64/obj/home/sysbuild/src/distrib/amd64/installimage/work/usr/mdec/gptmbr.bin > > > nbgpt: work.img: No secondary GPT header; run recover > > > *** Failed target: NetBSD-9.99.82-amd64-install.img > > > *** Failed command: /home/sysbuild/amd64/tools/bin/nbgpt work.img > > > biosboot -i 2 -c > > > /home/sysbuild/amd64/obj/home/sysbuild/src/distrib/amd64/installimage/work/usr/mdec/gptmbr.bin > > > *** Error code 1 > > > Stop. > > > nbmake[4]: stopped in /home/sysbuild/src/distrib/amd64/installimage > > > . > > > > This is due to a stale installation file. There is ongoing discussion > > of this problem for PR 56132. Please look there! As a work-around, > > > > rm -rf /build/netbsd-local/obj/amd64/distrib/amd64/installimage/ > > Thanks, removing the directory let me complete the build. My usual > first reaction to a build failure is to 'make cleandir' in the source > directories and remove the old obj directory completely; in most cases > if there were a real problem it has already been addressed by NetBSD > developers and the build is OK; in this case I had removed all the > obj, tools and destdir directories just three days ago and didn't > expect an early fallout... The main problem is that iso_image, live_image, and install_image targets of build.sh (and src/Makefile) hide detailed directory structures for building images, so currently there is no way to "clean objects only in image dirs". A possible way is to add explicit targets like iso_image_clean, live_image_clean, and install_image_clean etc. in all Makefiles under src/distrib? Anyway, we have workarounds but still need review by Makefile gurus: https://mail-index.netbsd.org/netbsd-bugs/2021/04/29/msg071345.html https://mail-index.netbsd.org/netbsd-bugs/2021/05/01/msg071360.html --- Izumi Tsutsui
Re: thorpej-cfargs branch merged
thorpej@ wrote: > Folks -- > > I just merged the thorpej-cfargs branch, which contains some > mostly-mechanical cleanups and some small but very useful enhancements > to the device auto configuration subsystem. Maybe several section 5 and 9 man pages should be updated to sync with the changes? config(5), autoconf(9), config(9), etc. (though I'm not sure if they reflected reality even before merge) Thanks, --- Izumi Tsutsui
Re: Automated report: NetBSD-current/i386 build failure
> I just committed usr.bin/make/var.c r1.270 which seems to fix > everything. Confirmed. Thanks for a quick response. --- Izumi Tsutsui
Re: Proposal to remove driver for the Cabletron EA41x SCSI Ethernetadapter
> We have a driver for this device in sys/dev/scsipi/if_se.c. It was pretty > popular with the pc532 crowd back in the day because SCSI was the only > expansion bus the pc532 had. > > There are changes coming to the network stack and it's unlikely that (a) > anyone has such a device to test it, and (b) that the driver even works > currently because it's been so long since probably anyone ran this code. > > I propose we remove this driver. There were some users also on port-mac68k: https://mail-index.netbsd.org/port-mac68k/2006/11/06/.html https://mail-index.netbsd.org/port-mac68k/2007/12/07/0002.html Note there is another Ethernet-over-SCSI solution using RaspberyPi as a SCSI device: http://retropc.net/gimons/rascsi/index.html and rin@ has a driver for it (based on se(4)): https://twitter.com/labdrunker/status/961526192334499840 https://twitter.com/labdrunker/status/963418617722281985 It's still worth to consider and design about Ethernet-over-SCSI layer. --- Izumi Tsutsui
Re: Anyone currently using fxp(4)?
> Is anyone currently using fxp(4) successfully? I am having trouble with link > stability on a new-in-box i82559 card, but on a non-x86 platform. With dhcpcd(8)? It looks fxp(4) resets MII during initialization so dhcpcd(8) mis-recognizes that the link is down, at least on 7.1.2. https://gnats.netbsd.org/53390 --- Izumi Tsutsui
Re: what's pio.h?
> So I see that we install machine/pio.h which defines functions like > these (amd64): > > inb, insb, inw, insw, inl, insl; outb, outsb, ... For i386, they are still inline functions. I guess we can still enable them by i386_iopl(2) for ancient programs using direct I/O in 386BSD days. (note options(4) says we also had /dev/io in 1.1 and prior.) For amd64 (and powerpc), they seem used only for kernel (like ) and provided by amd64/cpufunc.S etc. Maybe they are not expected to work for userland binaries. (though x86_64 still has x86_64_iopl(2) in libarch) --- Izumi Tsutsui
Re: X server being killed a lot
> Izumi Tsutsui wrote: > >> Do we know what combination of things is causing X to be killed ? > > > >I can reproduce it by Xorg server + Firefox 62 + makefs(8) creating > >4GB FFS image on NetBSD/i386 8.0 (i.e. on building live images). > > How is your X server configured ? Is it operating on a framebuffer in > main memory or VRAM on a separate graphics card ? My machine has RADEON HD 5450 so it has own VRAM, I think > The sizes shown in top(1) for X on my system are smaller than several > other processes. This is with an AMD Radeon GPU with 1GB VRAM. top(1) on the same environment says: --- Memory: 1976M Act, 974M Inact, 57M Wired, 139M Exec, 867M File, 16M Free Swap: 8192M Total, 1578M Used, 6614M Free PID USERNAME PRI NICE SIZE RES STATE TIME WCPUCPU COMMAND 2521 tsutsui 430 1588M 1118M parked/0 36:33 1.22% 1.22% firefox 708 tsutsui 850 1431M 764M select/0 484.2H 0.88% 0.88% ruby24 73 tsutsui 850 383M 145M select/0 117:56 0.00% 0.00% Xorg : --- Always Xorg was killed, not ruby24 or firefox: --- % zgrep 'out of swap' /var/log/messages* /var/log/messages:Oct 14 00:53:12 mirage /netbsd: UVM: pid 1962.1 (Xorg), uid 0 killed: out of swap /var/log/messages:Oct 18 23:27:19 mirage /netbsd: UVM: pid 4634.1 (Xorg), uid 0 killed: out of swap /var/log/messages.0.gz:Aug 22 00:45:01 mirage /netbsd: UVM: pid 2257.1 (Xorg), uid 0 killed: out of swap /var/log/messages.1.gz:Aug 6 22:35:49 mirage /netbsd: UVM: pid 394.1 (Xorg), uid 0 killed: out of swap /var/log/messages.1.gz:Aug 13 14:34:55 mirage /netbsd: UVM: pid 491.1 (Xorg), uid 0 killed: out of swap /var/log/messages.1.gz:Aug 13 17:18:07 mirage /netbsd: UVM: pid 2576.1 (Xorg), uid 0 killed: out of swap /var/log/messages.1.gz:Aug 15 13:07:11 mirage /netbsd: UVM: pid 970.1 (Xorg), uid 0 killed: out of swap /var/log/messages.4.gz:Jul 7 11:49:25 mirage /netbsd: UVM: pid 481.1 (Xorg), uid 0 killed: out of swap /var/log/messages.4.gz:Jul 22 09:29:25 mirage /netbsd: UVM: pid 75.1 (Xorg), uid 0 killed: out of swap /var/log/messages.4.gz:Jul 22 22:43:04 mirage /netbsd: UVM: pid 75.1 (Xorg), uid 0 killed: out of swap /var/log/messages.4.gz:Jul 22 22:48:24 mirage /netbsd: UVM: pid 4999.1 (Xorg), uid 0 killed: out of swap /var/log/messages.4.gz:Jul 22 22:50:08 mirage /netbsd: UVM: pid 14199.1 (Xorg), uid 0 killed: out of swap /var/log/messages.4.gz:Jul 22 22:58:48 mirage /netbsd: UVM: pid 3339.1 (Xorg), uid 0 killed: out of swap /var/log/messages.4.gz:Jul 22 23:09:28 mirage /netbsd: UVM: pid 11407.1 (Xorg), uid 0 killed: out of swap /var/log/messages.4.gz:Jul 22 23:12:20 mirage /netbsd: UVM: pid 29705.1 (Xorg), uid 0 killed: out of swap /var/log/messages.4.gz:Jul 22 23:21:39 mirage /netbsd: UVM: pid 1100.1 (Xorg), uid 0 killed: out of swap /var/log/messages.5.gz:Jun 2 20:48:55 mirage /netbsd: UVM: pid 846.1 (Xorg), uid 0 killed: out of swap /var/log/messages.5.gz:Jun 3 03:09:12 mirage /netbsd: UVM: pid 14182.1 (Xorg), uid 0 killed: out of swap /var/log/messages.5.gz:Jun 4 02:29:10 mirage /netbsd: UVM: pid 1260.1 (Xorg), uid 0 killed: out of swap /var/log/messages.5.gz:Jun 9 06:50:52 mirage /netbsd: UVM: pid 10595.1 (Xorg), uid 0 killed: out of swap /var/log/messages.5.gz:Jun 9 20:33:06 mirage /netbsd: UVM: pid 14867.1 (Xorg), uid 0 killed: out of swap /var/log/messages.5.gz:Jun 18 21:49:19 mirage /netbsd: UVM: pid 12485.1 (Xorg), uid 0 killed: out of swap /var/log/messages.5.gz:Jun 18 22:23:54 mirage /netbsd: UVM: pid 26101.1 (Xorg), uid 0 killed: out of swap /var/log/messages.5.gz:Jun 20 00:42:46 mirage /netbsd: UVM: pid 491.1 (Xorg), uid 0 killed: out of swap /var/log/messages.5.gz:Jun 23 06:34:39 mirage /netbsd: UVM: pid 22067.1 (Xorg), uid 0 killed: out of swap /var/log/messages.5.gz:Jun 30 00:06:18 mirage /netbsd: UVM: pid 12055.1 (Xorg), uid 0 killed: out of swap /var/log/messages.6.gz:May 5 17:40:40 mirage /netbsd: UVM: pid 74.1 (Xorg), uid 0 killed: out of swap /var/log/messages.6.gz:May 12 03:31:54 mirage /netbsd: UVM: pid 26634.1 (Xorg), uid 0 killed: out of swap /var/log/messages.6.gz:May 12 05:49:47 mirage /netbsd: UVM: pid 7793.1 (Xorg), uid 0 killed: out of swap /var/log/messages.6.gz:May 12 15:31:58 mirage /netbsd: UVM: pid 7632.1 (Xorg), uid 0 killed: out of swap /var/log/messages.6.gz:May 13 12:07:35 mirage /netbsd: UVM: pid 28029.1 (Xorg), uid 0 killed: out of swap /var/log/messages.6.gz:May 13 15:27:24 mirage /netbsd: UVM: pid 1197.1 (Xorg), uid 0 killed: out of swap /var/log/messages.6.gz:May 13 20:54:15 mirage /netbsd: UVM: pid 833.1 (Xorg), uid 0 killed: out of swap /var/log/messages.6.gz:May 17 00:28:20 mirage /netbsd: UVM: pid 3351.1 (Xorg), uid 0 killed: out of swap /var/log/messages.7.gz:May 4 11:01:59 mirage /netbsd: UVM: pid 1588.1 (Xorg), uid 0 killed: out of swap % --- Note I updated the machine from 7.1.2 to 8.0_RC1 on April 30 (and no 'out of swap' messages in older logs). --- Izumi Tsutsui
Re: X server being killed a lot
> Do we know what combination of things is causing X to be killed ? I can reproduce it by Xorg server + Firefox 62 + makefs(8) creating 4GB FFS image on NetBSD/i386 8.0 (i.e. on building live images). IIRC no such problem on 7.x days. (though Firefox was also smaller in those days) --- Izumi Tsutsui
Re: X server being killed a lot
> When I'm running a bulk build, the X server is a likely victim. > > UVM: pid 28091.1 (X), uid 0 killed: out of swap > > I'm not really sure why because I have lots of swap. > > Swap: 148G Total, 27G Used, 121G Free I also see the similar problem, on NetBSD/i386 8.0 with 8GB swap. Jul 22 09:29:25 mirage /netbsd: UVM: pid 75.1 (Xorg), uid 0 killed: out of swap Jul 22 22:43:04 mirage /netbsd: UVM: pid 75.1 (Xorg), uid 0 killed: out of swap Jul 22 22:48:24 mirage /netbsd: UVM: pid 4999.1 (Xorg), uid 0 killed: out of swap Jul 22 22:50:08 mirage /netbsd: UVM: pid 14199.1 (Xorg), uid 0 killed: out of swap Jul 22 22:58:48 mirage /netbsd: UVM: pid 3339.1 (Xorg), uid 0 killed: out of swap Jul 22 23:09:28 mirage /netbsd: UVM: pid 11407.1 (Xorg), uid 0 killed: out of swap Jul 22 23:12:20 mirage /netbsd: UVM: pid 29705.1 (Xorg), uid 0 killed: out of swap Jul 22 23:21:39 mirage /netbsd: UVM: pid 1100.1 (Xorg), uid 0 killed: out of swap It seems easily reproducible by running firefox and makefs(8) to create learge iso/ffs images. --- Izumi Tsutsui
Re: Floppy image overflow
>http://www.netbsd.org/~rin/atari_floppy_20160207.patch > > Now it reduces over 15KB from instbin :-). I'll commit it if there's no > objection. Thanks. I have a feeling that it would be better to add src/distrib/x_newfs etc. like src/distrib/x_disklabel and specify it in distrib/atari/floppies/install/list so that other poor ports can share them. --- Izumi Tsutsui
Re: libgnumalloc (i386) problems? Seen wih squid
gcw@ wrote: > Disassembly of section .text: > > : > 0: 8b 44 24 08 mov0x8(%esp),%eax > 4: c7 44 24 08 01 00 00movl $0x1,0x8(%esp) > b: 00 > c: 0f af 44 24 04 imul 0x4(%esp),%eax > 11: 89 44 24 04 mov%eax,0x4(%esp) > 15: eb e9 jmp0 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70798 As noted, "-O2 -fno-optimize-strlen" or "-O1" work around. (it replaces malloc() + memset(0) with calloc()) gmalloc.c in emacs may also be affected. --- Izumi Tsutsui
Re: tools build failure on Linux (and fix)
n54@ wrote:
> >> -__RCSID("$NetBSD: regsub.c,v 1.1 2016/01/09 02:00:14 christos
> >> Exp $");
:
> I just looked again, and the tools refer to the build.sh framework..
> can someone else reproduce it?
For tools, __RCSID() is defined in src/tools/compat/compat_defs.h
http://nxr.netbsd.org/xref/src/tools/compat/compat_defs.h?r=1.103#580
Not sure if we should have __RCSID() in sources to be committed/merged
into upstream (i.e. sources in external dirs), though.
---
Izumi Tsutsui
Re: Error in src/BUILDING document?
pgoyette@ wrote: According to src/BUILDING live-imageCreate NetBSD live images in the RELEASEDIR/RELEASEMACHINEDIR/installation/liveimage directory. ... : So, is the documentation wrong? Or is the build.sh results wrong? (Or have I completely misinterpreted something?) It looks the documentation was not updated after changes of default dirs defined in src/etc/Makefile: http://cvsweb.netbsd.org/bsdweb.cgi/src/etc/Makefile#rev1.398 --- Izumi Tsutsui
Re: Preparation for creating netbsd-7 branch
matt@ wrote: What about acorn26 and acorn32? Are you willing to step up and fix any apcs32 bugs in gcc? I have no idea if acorn26 still runs (I've made a significant effort to ensure it does). It would greatly simplify the ARM world if it would just die. :) acorn32 uses an armv3 processor which I have no idea if EABI supports. earmv3 anyone? Anyone willing to give it a shot? How many machines running out there run NetBSD? If there are more acorn26 machines than I can count with my thumbs, I'd be surprised. acorn32? Single digits? Sometimes you just have to say goodbye (pc532) to a supported platform. Removal of ports should be handled by Core, and you are a member of Core group. Why didn't you propose the removal in the Core's meeting etc. when you dicided to purge old arm ABI? Anyway, lack of documentation is still the serious problem. I am exactly the wrong person to write it. I know the space intimately so I don't know what a new person needs to know because it would never occur to me. If you would not like to handle such non-technical matters (release binary builds, upgrade mechanism etc.) at all, you should always have got prior approvals from persons who will work on such dumb items you don't like. Otherwise release users will get useless binaries like mips ports in 6.0 release. --- Izumi Tsutsui
Re: Preparation for creating netbsd-7 branch
skrll@ wrote: On 07/21/14 06:49, Izumi Tsutsui wrote: matt@ wrote: For the next release, core/releng should decide per current implementation: - how the default userland MACHINE_ARCH should be deteremined What do you mean by default? What (and how) MACHINE_ARCH should releng (binary builders) specify for each arm port on NetBSD 7.0 release? Personally, I hope we'll see builds for most (probably no need for v[67] sf) MACHINE_ARCH values. As matt said the RPI needs all the help it can get :) releng already says we don't have enough resources. - how to handle migration from old ABI to new one on sysinst In essence, this is no different from upgrading an i386 userland to an amd64 userland. So, your answer is We will never prepare such upgrade path right? I don't know how you got from Matt's statement to your question. I think there are solutions here. Where? There is no upgrade path from i386 to amd64 in sysinst. (we only had a.out to ELF) - which MACHINE_ARCH binaries should be prepared for official packages etc. for the new MACHINE_ARCH strategies. I have not seen an ARMv6 or ARMv7 machine without floating point yet. It doesn't answer the question at all. The question is which MACHINE_ARCH. I think the answer is the best one for your hardware. I'm asking about for official packages, not mine. --- Izumi Tsutsui
Re: Preparation for creating netbsd-7 branch
skrll@ wrote:
On 07/21/14 10:25, Izumi Tsutsui wrote:
skrll@ wrote:
On 07/21/14 06:49, Izumi Tsutsui wrote:
matt@ wrote:
For the next release, core/releng should decide per current
implementation:
- how the default userland MACHINE_ARCH should be deteremined
What do you mean by default?
What (and how) MACHINE_ARCH should releng (binary builders) specify
for each arm port on NetBSD 7.0 release?
Personally, I hope we'll see builds for most (probably no need for v[67]
sf) MACHINE_ARCH values. As matt said the RPI needs all the help it can
get :)
releng already says we don't have enough resources.
Really? Where did releng say that?
http://mail-index.netbsd.org/current-users/2014/07/21/msg025327.html
We probably don't have the ressources for providing binaries
for each {,e}arm{,hf} variants.
IMO, non-earm ABI builds should be dropped in favour of earm and a
subset of evbarm earm variants should be made available.
Something (build.sh/wiki/both) can document each evbarm board to the
correct MACHINE_ARCH variant based could then be provided.
build.sh already contains useful information here
zoom$ grep earm /usr/src/build.sh
MACHINE=catsMACHINE_ARCH=earmv4 ALIAS=ecats
MACHINE=evbarm MACHINE_ARCH=earm ALIAS=evbearm-el
MACHINE=evbarm MACHINE_ARCH=earmeb ALIAS=evbearm-eb
MACHINE=evbarm MACHINE_ARCH=earmhf ALIAS=evbearmhf-el
MACHINE=evbarm MACHINE_ARCH=earmhfeb ALIAS=evbearmhf-eb
MACHINE=evbarm MACHINE_ARCH=earmv4 ALIAS=evbearmv4-el
MACHINE=evbarm MACHINE_ARCH=earmv4eb ALIAS=evbearmv4-eb
MACHINE=evbarm MACHINE_ARCH=earmv5 ALIAS=evbearmv5-el
MACHINE=evbarm MACHINE_ARCH=earmv5eb ALIAS=evbearmv5-eb
MACHINE=evbarm MACHINE_ARCH=earmv6 ALIAS=evbearmv6-el
MACHINE=evbarm MACHINE_ARCH=earmv6hf ALIAS=evbearmv6hf-el
MACHINE=evbarm MACHINE_ARCH=earmv6eb ALIAS=evbearmv6-eb
MACHINE=evbarm MACHINE_ARCH=earmv6hfeb ALIAS=evbearmv6hf-eb
MACHINE=evbarm MACHINE_ARCH=earmv7 ALIAS=evbearmv7-el
MACHINE=evbarm MACHINE_ARCH=earmv7eb ALIAS=evbearmv7-eb
MACHINE=evbarm MACHINE_ARCH=earmv7hf ALIAS=evbearmv7hf-el
MACHINE=evbarm MACHINE_ARCH=earmv7hfeb ALIAS=evbearmv7hf-eb
MACHINE=hpcarm MACHINE_ARCH=earm ALIAS=hpcearm
MACHINE=iyonix MACHINE_ARCH=earm ALIAS=eiyonix
MACHINE=netwinder MACHINE_ARCH=earmv4 ALIAS=enetwinder
MACHINE=shark MACHINE_ARCH=earmv4 ALIAS=eshark
MACHINE=zaurus MACHINE_ARCH=earm ALIAS=ezaurus
zoom$
The evbarm board information can be derived from
http://nxr.netbsd.org/xref/src/etc/etc.evbarm/Makefile.inc
Building all arm ports for acorn32 compatibility is madness.
I know it has possible combinations.
My first question is
Which MACHINE_ARCH should be used for each arm port on the next release
It's non-technical, but probably determined by marketing and resources.
Ramdom comments won't help to get a proper conclusion, I'm afraid.
- how to handle migration from old ABI to new one on sysinst
In essence, this is no different from upgrading an i386 userland to an
amd64 userland.
So, your answer is
We will never prepare such upgrade path
right?
I don't know how you got from Matt's statement to your question. I think
there are solutions here.
Where?
There is no upgrade path from i386 to amd64 in sysinst.
(we only had a.out to ELF)
Someone(tm) needs to add it. SMOP, right?
Yes. It isn't a technical issue either.
My question to releng/core is
What should be done for the NetBSD 7.0 release?
I'm afraid we can't solve the issue until
the target branch (or even release) date
without proper plan.
---
Izumi Tsutsui
Re: Preparation for creating netbsd-7 branch
joerg@ wrote: On Mon, Jul 21, 2014 at 06:25:07PM +0900, Izumi Tsutsui wrote: There is no upgrade path from i386 to amd64 in sysinst. (we only had a.out to ELF) How much of an upgrade path do you need? Remove /dev, install sets as usual, rerun MAKEDEV should be enough... For example, prepare/move old compat libs if users also want to use old binaries? http://nxr.netbsd.org/xref/src/distrib/utils/sysinst/aout2elf.c Preparing and testing such upgrade mechanism would be a bit boring work (there are few developers who care releases and sysinst itself) so I'm afraid no one will take it... --- Izumi Tsutsui
Re: Preparation for creating netbsd-7 branch
It looks most your messages are caught by filter on mail.NetBSD.org host.
Could you check you yahoo mailer settings?
skrll@ wrote:
On 07/21/14 17:25, Izumi Tsutsui wrote:
skrll@ wrote:
On 07/21/14 15:32, Izumi Tsutsui wrote:
skrll@ wrote:
http://mail-index.netbsd.org/current-users/2014/07/21/msg025327.html
We probably don't have the ressources for providing binaries
for each {,e}arm{,hf} variants.
Probably?
Anyway, I don't think anyone is asking for all variants.
Well, I asked to releng/core, and one of releng member answered it.
That's all.
My first question is
Which MACHINE_ARCH should be used for each arm port on the next
release
It's non-technical, but probably determined by marketing and resources.
What's wrong with my suggestion? Feel free to suggest improvements.
You just mentioned possible combinations.
No I didn't.
Let me be more explicit
MACHINE=acorn26MACHINE_ARCH=arm
MACHINE=acorn32MACHINE_ARCH=arm
MACHINE=catsMACHINE_ARCH=earmv4
MACHINE=evbarm MACHINE_ARCH=earmv[67]hf{,eb}
MACHINE=evbarm MACHINE_ARCH=earm{,eb}
MACHINE=netwinder MACHINE_ARCH=earmv4
MACHINE=shark MACHINE_ARCH=earmv4
MACHINE=zaurus MACHINE_ARCH=earm
That is, use earm where possible, no softfloat for v[67].
This is 8 ABI combinations.
- What about epoc32, hpcarm, and iyonix?
I'd guess
MACHINE=epoc32MACHINE_ARCH=arm
MACHINE=hpcarmMACHINE_ARCH=earmv4
MACHINE=iyonix MACHINE_ARCH=earm
Maybe the port-masters/users can test?
Unfortunately all these ports are orphaned.
If not, leave as MACHINE_ARCH=arm
I'd rather suggest to switch to earm only on confirmed ports.
- Have you confirmed cats with earmv4?
(especially ELF to a.out conversion for the Cyclone firmware)
I've been running earmv4 on my cats for a long time now.
Ok, it's fine.
- Does zaurus really work with earm?
In sys/arch/zaurus/stand it builds Linux binaries
and I don't know if we can build it with earm toolchain.
(I was asked it by joerg and answered it, but no further response)
Don't know - maybe the port-masters/users can test. If not, leave as
MACHINE_ARCH=arm
It's also orphaned.
I wonder if it's really worth to introduce new ABI
into ancient Tier-II machines.
---
Izumi Tsutsui
Re: Preparation for creating netbsd-7 branch
rjs@ wrote: Izumi Tsutsui wrote: skrll@ wrote: I'd guess MACHINE=hpcarmMACHINE_ARCH=earmv4 Maybe the port-masters/users can test? I can test hpcarm on an iPAQ. Ok, good to hear. Unfortunately all these ports are orphaned. There were updates to hpcarm recently to get it to work on WZERO3 hardware, what is needed for it not to be considered orphaned ? orphaned means there is no portmainter to make a decision. http://www.netbsd.org/people/port-maintainers.html I have W-ZERO3 and Zaurus machines, but I'm not so motivated because I'm not sure what's the actual benefits and risk/concerns on switching to earm on such XScale generation machines. (most important part is lack of migration method, of course) Is there any documents/articles that describe earm on NetBSD? If not, we won't have enough brave users. --- Izumi Tsutsui
Re: Preparation for creating netbsd-7 branch
christos@ wrote: On Jul 20, 3:50am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: -- Subject: Re: Preparation for creating netbsd-7 branch | christos@ wrote: | | In article 140719232527.m0121...@mirage.ceres.dti.ne.jp, | Izumi Tsutsui tsut...@ceres.dti.ne.jp wrote: | On behalf of the release engineering team, I am happy to announce that | the release process for NetBSD 7.0 is now underway. | | Does anyone (core? releng?) has a particular plan about | the default MACHINE_ARCH for each arm ports? | | Let's discuss it. What do you propose? | | I asked matt@ on port-arm last year and got no answer. | http://mail-index.netbsd.org/port-arm/2013/10/26/msg002073.html | I think (other) Core members should handle it. Yes, I've been trying to follow that thread. Can you please summarize the problem and propose a solution? Is it a backwards compatibility issue? Or do we need to worry about binaries produced with sf on hf able machines in the future? Why would one do that? To be compatible with old machines? The main problem is lack of design description with random changes. http://mail-index.netbsd.org/port-arm/2013/10/26/msg002069.html http://mail-index.netbsd.org/port-arm/2013/10/27/msg002075.html Without specification, no idea what is intentional and what is broken. Anyway, most concerns are too late to discuss. - MACHINE_ARCH should be static or dynamic - how sysctl hw.machine_arch should be handled - different MACHINE_ARCH for kernel and userland should be allowed or not - different MACHINE_ARCH should be used for armv4/v6/v7 or not - a single kernel should handle different MACHINE_ARCH userland or not - should we use different MACHINE_ARCH for softfloat and hardfloat or not All of these usages have been changed from other MACHINE_ARCH. For the next release, core/releng should decide per current implementation: - how the default userland MACHINE_ARCH should be deteremined - how to handle migration from old ABI to new one on sysinst - which MACHINE_ARCH binaries should be prepared for official packages etc. for the new MACHINE_ARCH strategies. --- Izumi Tsutsui
Re: Preparation for creating netbsd-7 branch
matt@ wrote: For the next release, core/releng should decide per current implementation: - how the default userland MACHINE_ARCH should be deteremined What do you mean by default? What (and how) MACHINE_ARCH should releng (binary builders) specify for each arm port on NetBSD 7.0 release? - how to handle migration from old ABI to new one on sysinst In essence, this is no different from upgrading an i386 userland to an amd64 userland. So, your answer is We will never prepare such upgrade path right? - which MACHINE_ARCH binaries should be prepared for official packages etc. for the new MACHINE_ARCH strategies. I have not seen an ARMv6 or ARMv7 machine without floating point yet. It doesn't answer the question at all. The question is which MACHINE_ARCH. You are making a mountain out of a molehill. Providing a simple mechanism for an optimized userland for an embedded system (which most ARMs are) is a good thing. You never mentioned such simple mechanism goal in public, did you? The probelm is all your changes have been committed without public discussion and proper article. That's all. You never answered any questions either, and you never wrote proper commit logs. (PR numbers, reports on public mailing lists etc.) You have never answered other core member's question about mips64 breakage either, put no comments to recent fixes. It looks far from proper behavior as a core member.. --- Izumi Tsutsui
Re: Preparation for creating netbsd-7 branch
christos@ wrote: Please correct me if I am wrong: - The default userland is selected by installing the toolchain that produces that kind of userland. The binaries are branded via an Elf note that are of this kind of machine arch. - I am not sure if migration works, but presumably a hardfloat kernel should be able to handle softfloat binaries. I.e. recompilation is advised, but nothing more. - Each MACHINE should have its default MACHINE_ARCH. This could change over time. There are multiple evbarm flavors built for different hardware with different capabilities. No idea about correctness, but for NetBSD 7.0 we needs some choice. --- Izumi Tsutsui
Re: Preparation for creating netbsd-7 branch
On behalf of the release engineering team, I am happy to announce that the release process for NetBSD 7.0 is now underway. Does anyone (core? releng?) has a particular plan about the default MACHINE_ARCH for each arm ports? --- Izumi Tsutsui
Re: Preparation for creating netbsd-7 branch
christos@ wrote: In article 140719232527.m0121...@mirage.ceres.dti.ne.jp, Izumi Tsutsui tsut...@ceres.dti.ne.jp wrote: On behalf of the release engineering team, I am happy to announce that the release process for NetBSD 7.0 is now underway. Does anyone (core? releng?) has a particular plan about the default MACHINE_ARCH for each arm ports? Let's discuss it. What do you propose? I asked matt@ on port-arm last year and got no answer. http://mail-index.netbsd.org/port-arm/2013/10/26/msg002073.html I think (other) Core members should handle it. --- Izumi Tsutsui
Re: amd64 hangs during boot
=Kernel from freshly built sources from this morning on amd64 hangs =during boot. = =Last message: = =xhci0: xhci_open addr 0 depth 0 port 0 speed 3 I got that when I tried booting a -current installer. Disabling the USB 3 host controller in BIOS allowed it to boot, though obviously without the xhci. xhci was just recently added to GENERIC which is why you are seeing it now. cvs log says: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/usb/xhci.c#rev1.1 Add work-in-progress xhci(4) driver code. and the author said: http://mail-index.netbsd.org/source-changes-d/2013/10/23/msg006179.html I would like to state at this time that I am not directly responsible for any unexpected whatevers due to this change. So adding xhci into GENERIC looks a bit stupid and it should be reverted. --- Izumi Tsutsui
Re: dhcpd build break
--- dhcp6.c 21 Jun 2013 19:33:08 - 1.1.1.1
+++ dhcp6.c 22 Jun 2013 02:28:35 -
@@ -638,7 +638,8 @@ dhcp6_makemessage(struct interface *ifp)
o-len = encode_rfc1035(hostname, p + 1);
if (o-len == 0)
*p = 0x04;
- o-len = htons(++o-len);
+ ++o-len;
+ o-len = htons(o-len);
}
if (n_options) {
I get a successful build.sh release.
For readability, it's better to use an explicit temporary variable,
to keep o-len in the target byteorder:
---
len_tmp = encode_rfc1035(hostname, p + 1);
if (len_tmp == 0)
*p = 0x04;
o-len = htons(len_tmp + 1);
---
BTW, a magic 0x04 seems also awful for readers...
---
Izumi Tsustui
