Re: HEADS UP: plan to switch many ports over to GCC 12 soon

[Rin Okuyama]

Hi uwe@, thanks for hints!!

On 2024/07/01 14:38, Valery Ushakov wrote:

[trimmed the cc list down]

On Mon, Jul 01, 2024 at 09:59:54 +0900, Rin Okuyama wrote:


With in-tree GCC 12.4, kernel crashes just same as 12.3 :(

Even a single character is output to console. I tried to
drop some features from kernel config to reduce size
significantly, but it does not help. On the other hand,
same kernel works just fine if compiled by GCC 10.5.


Are binutils the same?  I'd first rule out section alignment/layout
issues (cf. netwinder changes to make netbsd-10 work again).


Yes, 2.39 for both. No significant difference for `readelf -a netbsd`.


I'd compile the kernel with gcc 10, then remove (stow away, really)
half the object files and compile with gcc 12.  If the result works,
repeat with the half of the remaining half.  If it doesn't - restore
the gcc10 objects and bisect them.  I had to this couple of times on
previous gcc uprqades.


I tried this way, then bisectioning did not work at all! I needed to
restore almost all files to ones compiled by GCC10.

I've found that GCC12 even miscompiles this one for -O1 and higher!


short
func(int i)
{

switch (i) {
case 0:
return 0xdead;
case 1:
return 0xbeaf;
default:
return 1;
}
}

 :
   0:   04 8b   bf  c 
   2:   43 60   mov r4,r0
   4:   01 88   cmp/eq  #1,r0
   6:   04 89   bt  12 
   8:   0b 00   rts
   a:   01 e0   mov #1,r0
   c:   04 90   mov.w   18 ,r0   ! dead
   e:   0b 00   rts
  10:   09 00   nop
  12:   02 90   mov.w   1a ,r0   ! beaf
  14:   0b 00   rts
  16:   09 00   nop
  18:   ad de   mov.l   2d0 ,r14
  1a:   af be   bsr fd7c 


Apparently, `tst r4,r4` is optimized out by mistake :(

This seems to be hacked around by this patch:


--- a/external/gpl3/gcc/dist/gcc/config/sh/sh_treg_combine.cc
+++ b/external/gpl3/gcc/dist/gcc/config/sh/sh_treg_combine.cc
@@ -1528,7 +1528,11 @@ sh_treg_combine::try_optimize_cbranch (rtx_insn 
*insn)

 bool
 sh_treg_combine::gate (function *)
 {
+#if 0
   return optimize > 0;
+#else
+  return false;
+#endif
 }

 unsigned int


With this hack, system boots into multiuser with DIAGNOSTIC, and now
it is running full ATF overnight without panic until now.

What I still haven't understood is why this causes the critical
problem for us with GCC 12.4. There are no significant changes b/w
10.5 and 12.4 (and 14.1) for gcc/config/sh. Also, it seems to
work for other Dreamcast community.

(There are one commit b/w 10.5 and 12.4 for sh_treg_combine.cc,
but reverting it does not change the situation.)

Anyway, I will commit the hack and report to upstream, if there's
no regression for ATF.


Sorry, I sitll haven't moved back most of my small machines from my
self-isolation lair, so my landisk is currently not here to test.


Never mind! Looking forward to your comeback to sh3 world :)

Thanks,
rin


-uwe

Re: HEADS UP: plan to switch many ports over to GCC 12 soon

[Rin Okuyama]

On 2024/06/30 14:51, Rin Okuyama wrote:

GCC 12.4 came out recently and i'll be updating to that, and
it has some sh fixes, maybe for this?


The situation for sh3 is getting worse since these note were
added last year. Kernel from recent -current does not boot on
landisk, even if compiled with `DBG=O1`.

This does not change if two upstream commits b/w GCC 12.3 and
12.4 in `gcc/config/sh` are cherry-picked :(


With in-tree GCC 12.4, kernel crashes just same as 12.3 :(

Even a single character is output to console. I tried to
drop some features from kernel config to reduce size
significantly, but it does not help. On the other hand,
same kernel works just fine if compiled by GCC 10.5.

I've noticed that GCC/sh is relatively active these days;
some people are developing their own SDK for Dreamcast.
These updates made our configuration stale?

Thanks,
rin

Re: HEADS UP: plan to switch many ports over to GCC 12 soon

[Rin Okuyama]

Hi,

On 2024/06/30 8:44, matthew green wrote:

sh3, m68k, m68000, and vax remain.  m68k is ready i believe,


Agreed.


m68000 doesn't yet build fully,


Only libasan is currently broken. With attached patch, I've
confirmed libasan successfully builds, and system boots
multiuser on TME.

I've never tested asan on sun2, as it does not work anyway.
Also, affects of this patch for other m68k ports are not
even compile-tested...

For sun2, GCC cannot build natively for years. It may be
better just to disable asan for m68000.

Thanks,
rindiff --git a/external/gpl3/gcc/dist/gcc/config/m68k/m68k.md 
b/external/gpl3/gcc/dist/gcc/config/m68k/m68k.md
index e4208cf323f..2e08eca18e5 100644
--- a/external/gpl3/gcc/dist/gcc/config/m68k/m68k.md
+++ b/external/gpl3/gcc/dist/gcc/config/m68k/m68k.md
@@ -6266,7 +6266,8 @@
return ("move.l #_GLOBAL_OFFSET_TABLE_@GOTPC, %0\n\t"
"lea (-6, %%pc, %0), %0");
   else
-   return "lea (%%pc, _GLOBAL_OFFSET_TABLE_@GOTPC), %0";
+   return ("move.l #_GLOBAL_OFFSET_TABLE_@GOTPC, %0\n\t"
+   "lea (%%pc, %0.l),%0");
 }
   else
 return ("movel #_GLOBAL_OFFSET_TABLE_, %0\n\t"

Re: HEADS UP: plan to switch many ports over to GCC 12 soon

[Rin Okuyama]

[CC added for port-sh3@, dropped for port-mips@ and port-powerpc@]

Hi,

On 2024/06/30 14:19, matthew green wrote:

On Sun, 2024-06-30 at 09:44 +1000, matthew green wrote:

sh3 may be problematic,


I can almost certainly test sh3. I should even be able to make a new
bootable disk for an end to end test.


oh the problem is it's broken -- rin@ could talk more about it,
i'm just going on the notes in README.gcc12:

[20]: kernel needs -O1 for ffs32() and ffs_nodealloccg() for multi-user boot. 
Even if the whole kernel is built with -O1, it panics during ATF:
   kernel/t_sysv (92/935): 3 test cases
   msg: [ 3981.4751382] panic: kernel diagnostic assertion "msghdr->msg_spot >= 
0" failed: file "../../../../kern/sysv_msg.c", line 426

[22]: single-user shell crashes. if userland is built with DBG=-O1, it boots 
into multi-user mode.
   however, at least db(3) is broken, by which files are corrupted when 
edited by vi(1).

i didn't try landisk gxemul yet.

GCC 12.4 came out recently and i'll be updating to that, and
it has some sh fixes, maybe for this?


The situation for sh3 is getting worse since these note were
added last year. Kernel from recent -current does not boot on
landisk, even if compiled with `DBG=O1`.

This does not change if two upstream commits b/w GCC 12.3 and
12.4 in `gcc/config/sh` are cherry-picked :(

I was just going to examine changes b/w 10.5 and 12.3...

Thanks,
rin

Re: Automated report: NetBSD-current/i386 build failure

[Rin Okuyama]

Should be fixed now.

Thanks,
rin

On 2024/06/29 17:20, Rin Okuyama wrote:

Oops, sorry, I was just going to fix this.

On 2024/06/29 17:15, NetBSD Test Fixture wrote:

This is an automatically generated notice of a NetBSD-current/i386
build failure.

The failure occurred on babylon4.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2024.06.29.07.52.16.

An extract from the build.sh output follows:

 /tmp/build/2024.06.29.07.52.16-i386/tools/bin/i486--netbsdelf-gcc 
-O2   -fPIE    -std=gnu99    -Wall -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wno-sign-compare  
-Wsystem-headers   -Wno-traditional   -Wa,--fatal-warnings  
-Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra 
-Wno-unused-parameter -Wno-sign-compare -Wold-style-definition 
-Wsign-compare -Wformat=2  -Wno-format-zero-length  -Werror 
--sysroot=/tmp/build/2024.06.29.07.52.16-i386/destdir 
-I/tmp/build/2024.06.29.07.52.16-i386/src/sbin/disklabel  -c
/tmp/build/2024.06.29.07.52.16-i386/src/sbin/apmlabel/apmlabel.c -o 
apmlabel.o.o

 --- dependall-sys ---
 --- dependall-stand ---
 --- dependall-mbr_bootsel ---
 --- dependall-boot ---
 
/tmp/build/2024.06.29.07.52.16-i386/src/sys/arch/i386/stand/boot/biosboot/../boot2.c:79:10: fatal error: libi386.h: No such file or directory

    79 | #include 
   |  ^~~
 compilation terminated.
 --- dependall-usr.sbin ---
 
CC=/tmp/build/2024.06.29.07.52.16-i386/tools/bin/i486--netbsdelf-gcc 
/tmp/build/2024.06.29.07.52.16-i386/tools/bin/nbmkdep -s .o\ .ln\ .d 
-d -f .depend accton.d


The following commits were made between the last successful build and
the first failed build:

 2024.06.29.07.36.02 rin 
src/sys/arch/i386/stand/netboot/Attic/Makefile 1.32
 2024.06.29.07.36.02 rin 
src/sys/arch/i386/stand/netboot/Attic/Makefile.netboot 1.12
 2024.06.29.07.36.02 rin 
src/sys/arch/i386/stand/netboot/Attic/conf.c 1.5
 2024.06.29.07.36.02 rin 
src/sys/arch/i386/stand/netboot/Attic/dev_net.c 1.17
 2024.06.29.07.36.02 rin 
src/sys/arch/i386/stand/netboot/Attic/dev_net.h 1.4
 2024.06.29.07.36.02 rin 
src/sys/arch/i386/stand/netboot/Attic/devopen.c 1.9
 2024.06.29.07.36.02 rin 
src/sys/arch/i386/stand/netboot/Attic/main.c 1.19
 2024.06.29.07.36.02 rin 
src/sys/arch/i386/stand/netboot/Attic/start_rom.S 1.4
 2024.06.29.07.36.03 rin 
src/sys/arch/i386/stand/netboot/3c509/Attic/Makefile 1.2
 2024.06.29.07.36.03 rin 
src/sys/arch/i386/stand/netboot/3c590/Attic/Makefile 1.2
 2024.06.29.07.36.03 rin 
src/sys/arch/i386/stand/netboot/3c90xb/Attic/Makefile 1.2
 2024.06.29.07.36.03 rin 
src/sys/arch/i386/stand/netboot/Attic/version 1.9
 2024.06.29.07.36.03 rin 
src/sys/arch/i386/stand/netboot/i82557/Attic/Makefile 1.2
 2024.06.29.07.36.03 rin 
src/sys/arch/i386/stand/netboot/ne2000_isa/Attic/Makefile 1.5
 2024.06.29.07.36.03 rin 
src/sys/arch/i386/stand/netboot/pcnet_isapnp/Attic/Makefile 1.2
 2024.06.29.07.36.03 rin 
src/sys/arch/i386/stand/netboot/pcnet_pci/Attic/Makefile 1.2
 2024.06.29.07.36.03 rin 
src/sys/arch/i386/stand/netboot/wd80x3/Attic/Makefile 1.3
 2024.06.29.07.38.07 rin src/sys/arch/i386/stand/Makefile.booters 
1.97
 2024.06.29.07.38.07 rin 
src/sys/arch/i386/stand/genprom/Attic/Makefile 1.11
 2024.06.29.07.38.07 rin 
src/sys/arch/i386/stand/genprom/Attic/genprom.c 1.9
 2024.06.29.07.40.18 rin 
src/sys/arch/i386/stand/lib/netif/Attic/3c509.c 1.11
 2024.06.29.07.40.18 rin 
src/sys/arch/i386/stand/lib/netif/Attic/3c509.h 1.8
 2024.06.29.07.40.18 rin 
src/sys/arch/i386/stand/lib/netif/Attic/3c590.c 1.16
 2024.06.29.07.40.18 rin 
src/sys/arch/i386/stand/lib/netif/Attic/3c90xb.c 1.16
 2024.06.29.07.40.18 rin 
src/sys/arch/i386/stand/lib/netif/Attic/Makefile.inc 1.7
 2024.06.29.07.40.18 rin 
src/sys/arch/i386/stand/lib/netif/Attic/am7990.c 1.9
 2024.06.29.07.40.18 rin 
src/sys/arch/i386/stand/lib/netif/Attic/dp8390.c 1.7
 2024.06.29.07.40.18 rin 
src/sys/arch/i386/stand/lib/netif/Attic/dp8390.h 1.7
 2024.06.29.07.40.18 rin 
src/sys/arch/i386/stand/lib/netif/Attic/elink3.c 1.5
 2024.06.29.07.40.19 rin 
src/sys/arch/i386/stand/lib/netif/Attic/etherdrv.h 1.11
 2024.06.29.07.40.19 rin 
src/sys/arch/i386/stand/lib/netif/Attic/i82557.c 1.12
 2024.06.29.07.40.19 rin 
src/sys/arch/i386/stand/lib/netif/Attic/lance.h 1.3
 2024.06.29.07.40.19 rin 
src/sys/arch/i386/stand/lib/netif/Attic/ne.c 1.8
 2024.06.29.07.40.19 rin 
src/sys/arch/i386/stand/lib/netif/Attic/ne.h 1.4
 2024.06.29.07.40.19 rin 
src/sys/arch/i386/stand/lib/netif/Attic/netif_small.c 1.13
 2024.06.29.07.40.19 rin 
src/sys/arch/i386/stand/lib/netif/Attic/netif_small.h 1.6
 2024.06.29.07.40.19 rin 
src/sys/arch/i386/stand/lib/netif/Attic/pcnet_isapnp.c 1.9
 2024.06.29.07.40.19 rin 
src/sys/arch/i386/stand/lib/netif/Attic/pcnet_pci.c 1.9
 2024.06.29.07.40.19 rin 
src/sys/arch/i386/stand/lib/netif/Attic

Re: Automated report: NetBSD-current/i386 build failure

[Rin Okuyama]

Oops, sorry, I was just going to fix this.

On 2024/06/29 17:15, NetBSD Test Fixture wrote:

This is an automatically generated notice of a NetBSD-current/i386
build failure.

The failure occurred on babylon4.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2024.06.29.07.52.16.

An extract from the build.sh output follows:

 /tmp/build/2024.06.29.07.52.16-i386/tools/bin/i486--netbsdelf-gcc -O2   
-fPIE-std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes 
-Wpointer-arith -Wno-sign-compare  -Wsystem-headers   -Wno-traditional   
-Wa,--fatal-warnings  -Wreturn-type -Wswitch -Wshadow -Wcast-qual 
-Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare 
-Wold-style-definition -Wsign-compare -Wformat=2  -Wno-format-zero-length  
-Werror --sysroot=/tmp/build/2024.06.29.07.52.16-i386/destdir 
-I/tmp/build/2024.06.29.07.52.16-i386/src/sbin/disklabel  -c
/tmp/build/2024.06.29.07.52.16-i386/src/sbin/apmlabel/apmlabel.c -o apmlabel.o.o
 --- dependall-sys ---
 --- dependall-stand ---
 --- dependall-mbr_bootsel ---
 --- dependall-boot ---
 
/tmp/build/2024.06.29.07.52.16-i386/src/sys/arch/i386/stand/boot/biosboot/../boot2.c:79:10:
 fatal error: libi386.h: No such file or directory
79 | #include 
   |  ^~~
 compilation terminated.
 --- dependall-usr.sbin ---
 CC=/tmp/build/2024.06.29.07.52.16-i386/tools/bin/i486--netbsdelf-gcc 
/tmp/build/2024.06.29.07.52.16-i386/tools/bin/nbmkdep -s .o\ .ln\ .d -d -f 
.depend accton.d

The following commits were made between the last successful build and
the first failed build:

 2024.06.29.07.36.02 rin src/sys/arch/i386/stand/netboot/Attic/Makefile 1.32
 2024.06.29.07.36.02 rin 
src/sys/arch/i386/stand/netboot/Attic/Makefile.netboot 1.12
 2024.06.29.07.36.02 rin src/sys/arch/i386/stand/netboot/Attic/conf.c 1.5
 2024.06.29.07.36.02 rin src/sys/arch/i386/stand/netboot/Attic/dev_net.c 
1.17
 2024.06.29.07.36.02 rin src/sys/arch/i386/stand/netboot/Attic/dev_net.h 1.4
 2024.06.29.07.36.02 rin src/sys/arch/i386/stand/netboot/Attic/devopen.c 1.9
 2024.06.29.07.36.02 rin src/sys/arch/i386/stand/netboot/Attic/main.c 1.19
 2024.06.29.07.36.02 rin src/sys/arch/i386/stand/netboot/Attic/start_rom.S 
1.4
 2024.06.29.07.36.03 rin 
src/sys/arch/i386/stand/netboot/3c509/Attic/Makefile 1.2
 2024.06.29.07.36.03 rin 
src/sys/arch/i386/stand/netboot/3c590/Attic/Makefile 1.2
 2024.06.29.07.36.03 rin 
src/sys/arch/i386/stand/netboot/3c90xb/Attic/Makefile 1.2
 2024.06.29.07.36.03 rin src/sys/arch/i386/stand/netboot/Attic/version 1.9
 2024.06.29.07.36.03 rin 
src/sys/arch/i386/stand/netboot/i82557/Attic/Makefile 1.2
 2024.06.29.07.36.03 rin 
src/sys/arch/i386/stand/netboot/ne2000_isa/Attic/Makefile 1.5
 2024.06.29.07.36.03 rin 
src/sys/arch/i386/stand/netboot/pcnet_isapnp/Attic/Makefile 1.2
 2024.06.29.07.36.03 rin 
src/sys/arch/i386/stand/netboot/pcnet_pci/Attic/Makefile 1.2
 2024.06.29.07.36.03 rin 
src/sys/arch/i386/stand/netboot/wd80x3/Attic/Makefile 1.3
 2024.06.29.07.38.07 rin src/sys/arch/i386/stand/Makefile.booters 1.97
 2024.06.29.07.38.07 rin src/sys/arch/i386/stand/genprom/Attic/Makefile 1.11
 2024.06.29.07.38.07 rin src/sys/arch/i386/stand/genprom/Attic/genprom.c 1.9
 2024.06.29.07.40.18 rin src/sys/arch/i386/stand/lib/netif/Attic/3c509.c 
1.11
 2024.06.29.07.40.18 rin src/sys/arch/i386/stand/lib/netif/Attic/3c509.h 1.8
 2024.06.29.07.40.18 rin src/sys/arch/i386/stand/lib/netif/Attic/3c590.c 
1.16
 2024.06.29.07.40.18 rin src/sys/arch/i386/stand/lib/netif/Attic/3c90xb.c 
1.16
 2024.06.29.07.40.18 rin 
src/sys/arch/i386/stand/lib/netif/Attic/Makefile.inc 1.7
 2024.06.29.07.40.18 rin src/sys/arch/i386/stand/lib/netif/Attic/am7990.c 
1.9
 2024.06.29.07.40.18 rin src/sys/arch/i386/stand/lib/netif/Attic/dp8390.c 
1.7
 2024.06.29.07.40.18 rin src/sys/arch/i386/stand/lib/netif/Attic/dp8390.h 
1.7
 2024.06.29.07.40.18 rin src/sys/arch/i386/stand/lib/netif/Attic/elink3.c 
1.5
 2024.06.29.07.40.19 rin src/sys/arch/i386/stand/lib/netif/Attic/etherdrv.h 
1.11
 2024.06.29.07.40.19 rin src/sys/arch/i386/stand/lib/netif/Attic/i82557.c 
1.12
 2024.06.29.07.40.19 rin src/sys/arch/i386/stand/lib/netif/Attic/lance.h 1.3
 2024.06.29.07.40.19 rin src/sys/arch/i386/stand/lib/netif/Attic/ne.c 1.8
 2024.06.29.07.40.19 rin src/sys/arch/i386/stand/lib/netif/Attic/ne.h 1.4
 2024.06.29.07.40.19 rin 
src/sys/arch/i386/stand/lib/netif/Attic/netif_small.c 1.13
 2024.06.29.07.40.19 rin 
src/sys/arch/i386/stand/lib/netif/Attic/netif_small.h 1.6
 2024.06.29.07.40.19 rin 
src/sys/arch/i386/stand/lib/netif/Attic/pcnet_isapnp.c 1.9
 2024.06.29.07.40.19 rin 
src/sys/arch/i386/stand/lib/netif/Attic/pcnet_pci.c 1.9
 2024.06.29.07.40.19 rin src/sys/arch/i386/stand/lib/netif/Attic/wd80x3.c 
1.11
 2024.06.29.07.40.19 rin src/sys/arch/i386/stand/lib/test/Attic/ether_bpf.c 

Re: Aquantia AQC100 issues

[Rin Okuyama]

Hi Andrius,

If you still have this AQC100 in working condition, can you try this patch?

https://gist.github.com/rokuyama/ab6ba1a0fac7fa15f243d63a99e14f33

I've collected three fibre aq(4) variants (all rev 2), and link status
interrupts work just fine for me. I think that link intr did not work for
you, not due to fibre variant, but hardware revision. If this is correct,
the patch above should work...

Thanks,
rin

On Fri, Apr 24, 2020 at 7:10 AM Andrius V  wrote:
>
> Thank you for the help and updated code. Retested on current branch,
> works as expected. Possibly worth to mention AQC100 in  aq.4 as well?
>
>
> On Thu, Apr 23, 2020 at 8:33 AM Ryo Shimizu  wrote:
> >
> >
> > >Yes, the patch solves the problem. Linked is up immediately after the boot.
> >
> > I'm relieved. In the interim, I'll commit a fix that always polling 
> > linkstat when FIBRE.
> >
> > thanks,
> > --
> > ryo shimizu
>

Re: Driver support for Intel I225/I226 Ethernet adapters

[Rin Okuyama]

I've committed igc(4) driver for Intel I225 and I226 series NICs with
one-week delay ;)

As noted in the commit log, it is still experimental; it lacks some
logic for minor error
handling paths, but it works almost fine for both LP64/ILP32 and
big-/little-endian.

Have fun!
rin

On Fri, Sep 22, 2023 at 9:00 PM Pierre Pronchery  wrote:
>
> Hi :)
>
> > On 22. Sep 2023, at 11:36, Rin Okuyama  wrote:
> >
> > Sorry for the late response.
>
> No worries!
>
> > On Mon, Sep 18, 2023 at 6:01 AM Pierre Pronchery  wrote:
> >> I am wondering if anyone has any plans to work on supporting Intel’s I225 
> >> and/or I226 series of Ethernet adapters in NetBSD?
> >>
> >> I have a board with a couple I226-V chips here (CW-J6-NAS, as per 
> >> https://cwwk.net/products/j6412-j6413-nas-board-six-sata3-0-dual-m-2-i226-v-nics).
> >>  It works great with NetBSD so far, but only the Realtek-based Ethernet 
> >> chip is recognised.
> >>
> >> I’ll be happy to test tentative drivers on request.
> >
> > knakahara@,  msaitoh@, and I are working on importing igc(4) driver
> > from OpenBSD.
> > It already works almost fine. We will commit it next week if no
> > serious problem appears :)
>
> This is awesome to hear, thank you!
>
> Looking forward to testing it,
> --
> khorben

Re: Anyone having a problem with cross building arm* tools on current?

[Rin Okuyama]

makestrs.c is in xsrc. You need to prepare xsrc to X11SRCDIR or,
specify ``MKX11=no'' in /etc/mk.conf.

Thanks,
rin

On 2023/06/17 6:45, Dave Tyson wrote:

With a very recent checkout of NetBSD-current I am seeing a failure to
build tools on arm6, aarch64 (and probably arm7), build.sh bombs out:

dependall-dtc ===> . (with: dependall-makestrs dependall-makekeys
dependall-cvslatest)
dependall ===> makestrs
nbmake[2]: nbmake[2]: don't know how to make makestrs.c. Stop

nbmake[2]: stopped in /usr/src/tools/makestrs

*** Failed target:  dependall-makestrs
*** Failed command: _makedirtarget() { dir="$1"; shift; target="$1";
shift; case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .)
this=""; real="/usr/src/tools" ;; *) this="${dir}/";
real="/usr/src/tools/${dir}" ;; esac; show=${this:-.}; echo "${target}
===> ${show%/}${1:+ (with: $@)}"; cd "${real}" &&
/usr/src/../tools/arm6/bin/nbmake _THISDIR_="${this}" "$@" ${target};
}; _makedirtarget makestrs dependall
*** Error code 2

Stop.
nbmake[1]: stopped in /usr/src/tools

Dave

Re: namespace pollution? clone()

[Rin Okuyama]

On 2022/08/01 23:22, Thomas Klausner wrote:

On Mon, Aug 01, 2022 at 11:20:11PM +0900, Rin Okuyama wrote:

On 2022/08/01 23:13, Martin Husemann wrote:

On Mon, Aug 01, 2022 at 03:57:19PM +0200, Thomas Klausner wrote:

The attached diff survived a complete amd64-current build. Ok to commit?


Looks good to me.


Can you please mention _GNU_SOURCE in clone(2)?


Thanks for the reminder - done!


Thanks!

rin

Re: namespace pollution? clone()

[Rin Okuyama]

On 2022/08/01 23:13, Martin Husemann wrote:

On Mon, Aug 01, 2022 at 03:57:19PM +0200, Thomas Klausner wrote:

The attached diff survived a complete amd64-current build. Ok to commit?


Looks good to me.


Can you please mention _GNU_SOURCE in clone(2)?

Thanks,
rin

Re: WDCTL_RST failed for drive 0 / wd0: IDENTIFY failed (SATA autodetection issue after installation)

[Rin Okuyama]

Thank you for the detailed report!

I've added these controllers for the quirk list. With ahcisata_pci.c rev 1.63
and later, AHCISATA_EXTRA_DELAY kernel option is no longer required.

Thanks,
rin

On 2022/05/27 15:02, Matthias Petermann wrote:

Hello Rin,

the option AHCISATA_EXTRA_DELAY seems to fix the problem for both systems below.

As discussed I send here the two dmesg with:

  - dmesg.nuc5.txt: from my NUC5 with AHCI and a Seagate hard disk.

  - dmesg.fujitsu.txt: from my Esprimo, with AHCI and wd2 (Seagate) and wd3 
(WD).

A few more notes:

  - On the NUC, I had intermediately and temporarily replaced the hard drive. In the 
process, the reproducibility of the problem suffered. Before I "moved" the 
cables, I could see the problem every time I booted. Now it's more of a coincidence that 
it happens (even with the original hard drive installed).

  - On the Esprimo - when the error occurs at almost every cold boot - 
according to my observations, both mechanical hard disks are always affected 
(wd2 and wd3). The SSDs (wd0 and wd1), on the other hand, are always detected 
correctly.

More generally, the state of the cabling seems to contribute at least somewhat 
to the problems. With the NUC, unplugging and plugging in changed the 
probability of occurrence. With the Fujitsu, I noticed the problems more since 
I installed a 4x SATA dock. That the problem is almost certainly related to the 
AHCI SATA delay would be judged by the fact that it only occurs with NetBSD 
9.99.x and not with 9.2 or FreeBSD/Linux.

Especially with the Fujitsu, however, I had already exchanged cables several times 
beforehand and tried different things, because I had initially suspected a pure cabling 
problem. However, it seems to me at the moment that the cabling at most changes the 
timing and this is set so "on edge" that the problem sometimes occurs and 
sometimes not.

Kind regards
Matthias


Am 24.05.2022 um 18:23 schrieb Rin Okuyama:

Hi,

The recent change for probe timing should only affect ahcisata(4).
Is your SATA controller ahcisata(4)? If so,

(1) please try kernel built with:

---
options AHCISATA_EXTRA_DELAY
---

If it works around the problem,

(2) please send us full dmesg of your machine.

Then, we can add your controller to the quirk list. At once it is
registered to the list, AHCISATA_EXTRA_DELAY option is no longer
required.

Thanks,
rin

On 2022/05/25 0:49, Matthias Petermann wrote:

A small addendum: disabling the Intel Platform Trust technology in the BIOS did 
not help me (had read this in another post of the linked thread).

However, by plugging in additional USB devices (a mouse) I apparently caused the 
necessary delay, which the disk would have needed in the first case to execute the 
WDCTL_RST without errors. This "workaround" is a shaky one though, an extremely 
close call. I don't even want to think about what I would do to a production server if 
this happened to me on a reboot.

Kind regards
Matthias


Am 24.05.2022 um 17:31 schrieb Matthias Petermann:


Hello all,

with one of the newer builds of 9.99 (unfortunately I can't narrow it down 
more) I have a problem on a NUC5 with a Seagate Firecuda SATA hard drive 
(hybrid HDD/SSD).

As long as I boot from the USB stick (for installation, as well as later for 
booting the kernel with root redirected to the wd0) the hard drive wd0 is 
recognized correctly and works without problems.

When I boot directly from the wd0 hard drive, I get through the boot loader 
fine, which also still loads the kernel correctly into memory. However, when 
running the initialization or hardware detection, there is then a problem with 
the initialization of wd0:

```
WDCTL_RST failed for drive 0
wd0: IDENTIFY failed
```

The error pattern seems to be not quite rare and probably the closest to it is 
this post:

http://mail-index.netbsd.org/current-users/2022/03/01/msg042073.html

Recent changes to the SATA autodetection timing are mentioned there. This would 
fit my experience, since I had the problem neither with 9.1 (build from 
02/16/2021) nor with older 9.99 versions. Does anyone know more specifics about 
this timing thing, as well as known workarounds if there are any? I have 
several NUC5s with exactly this model of hard drive running stably for several 
years - it would be a shame if I now have to replace them for such a reason.

Many greetings
Matthias

Re: WDCTL_RST failed for drive 0 / wd0: IDENTIFY failed (SATA autodetection issue after installation)

[Rin Okuyama]

Hi,

The recent change for probe timing should only affect ahcisata(4).
Is your SATA controller ahcisata(4)? If so,

(1) please try kernel built with:

---
options AHCISATA_EXTRA_DELAY
---

If it works around the problem,

(2) please send us full dmesg of your machine.

Then, we can add your controller to the quirk list. At once it is
registered to the list, AHCISATA_EXTRA_DELAY option is no longer
required.

Thanks,
rin

On 2022/05/25 0:49, Matthias Petermann wrote:

A small addendum: disabling the Intel Platform Trust technology in the BIOS did 
not help me (had read this in another post of the linked thread).

However, by plugging in additional USB devices (a mouse) I apparently caused the 
necessary delay, which the disk would have needed in the first case to execute the 
WDCTL_RST without errors. This "workaround" is a shaky one though, an extremely 
close call. I don't even want to think about what I would do to a production server if 
this happened to me on a reboot.

Kind regards
Matthias


Am 24.05.2022 um 17:31 schrieb Matthias Petermann:


Hello all,

with one of the newer builds of 9.99 (unfortunately I can't narrow it down 
more) I have a problem on a NUC5 with a Seagate Firecuda SATA hard drive 
(hybrid HDD/SSD).

As long as I boot from the USB stick (for installation, as well as later for 
booting the kernel with root redirected to the wd0) the hard drive wd0 is 
recognized correctly and works without problems.

When I boot directly from the wd0 hard drive, I get through the boot loader 
fine, which also still loads the kernel correctly into memory. However, when 
running the initialization or hardware detection, there is then a problem with 
the initialization of wd0:

```
WDCTL_RST failed for drive 0
wd0: IDENTIFY failed
```

The error pattern seems to be not quite rare and probably the closest to it is 
this post:

http://mail-index.netbsd.org/current-users/2022/03/01/msg042073.html

Recent changes to the SATA autodetection timing are mentioned there. This would 
fit my experience, since I had the problem neither with 9.1 (build from 
02/16/2021) nor with older 9.99 versions. Does anyone know more specifics about 
this timing thing, as well as known workarounds if there are any? I have 
several NUC5s with exactly this model of hard drive running stably for several 
years - it would be a shame if I now have to replace them for such a reason.

Many greetings
Matthias

Re: Configure Serial Adapter

[Rin Okuyama]

On 2022/05/11 22:06, Rin Okuyama wrote:

Alternatively, you can buy a well-supported product. I'm using one from
CableCreation with uftdi(4) driver. This is sold worldwide, e.g.:

https://www.amazon.com/dp/B075YHFMC7


Robert tells me that CableCreation has PL2303 models besides FTDI ones,
which I meant in the previous message.

If you want to use uftdi(4) driver, you have to choose the latter.

Thanks,
rin

Re: Configure Serial Adapter

[Rin Okuyama]

On 2022/05/11 20:36, Robert Nestor wrote:

First, I was mistaken about this Prolific PL2303 USB Serial Adapter cable being 
a null modem.  It’s just a straight turn cable but I have a null modem dongle 
attached to it on the DB-9 end.

As for the USB port on the system it’s attached to, this port has been used for 
various other devices (disks, geek sticks, weather station) without any issues. 
 Rebooting the system with and without the DB-9 end connected always gives the 
same NOMEM results though.


Your device seems to be supported by OpenBSD's uplcom(4).

Probably, this commit does trick:

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/uplcom.c#rev1.76

See also this one:

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/uplcom.c#rev1.78

Alternatively, you can buy a well-supported product. I'm using one from
CableCreation with uftdi(4) driver. This is sold worldwide, e.g.:

https://www.amazon.com/dp/B075YHFMC7

Thanks,
rin

Re: IDENTIFY failed

[Rin Okuyama]

Sorry for the late reply.

Patrick, Jun, thank you very much for testing!

I've committed the patch:
http://mail-index.netbsd.org/source-changes/2021/11/19/msg133924.html

Thanks,
rin

On 2021/11/10 1:10, Patrick Welche wrote:

On Mon, Nov 08, 2021 at 08:42:44PM +0900, Rin Okuyama wrote:

Jun, Patrick, thank you for dmesg (and discussion offlist).

For Jun, the problem is no longer reproducible even with the original
copy of kernel, which failed before.

So, I've just added AHCI_QUIRK_EXTRA_DELAY quirk for Patrick's machine:

https://gist.github.com/rokuyama/7535594fc42a7867e3890702aee34c5c

With this patch, AHCISATA_EXTRA_DELAY option is no longer required for
this machine.


I cvs updated, rebuilt the kernel without the DELAY, and checked that
the problem still existed. (it does) Then applied your gist patch, and
had a successful reboot!

(I haven't tried reducing the delay)


Thanks,

Patrick

Re: IDENTIFY failed

[Rin Okuyama]

Jun, Patrick, thank you for dmesg (and discussion offlist).

For Jun, the problem is no longer reproducible even with the original
copy of kernel, which failed before.

So, I've just added AHCI_QUIRK_EXTRA_DELAY quirk for Patrick's machine:

https://gist.github.com/rokuyama/7535594fc42a7867e3890702aee34c5c

With this patch, AHCISATA_EXTRA_DELAY option is no longer required for
this machine.

Also, I've added AHCISATA_EXTRA_DELAY_MS option. You can specify how
many extra msec's the driver should sleep with AHCISATA_EXTRA_DELAY
quirk or AHCISATA_EXTRA_DELAY option. The default is still 500ms, but
you can adjust delays like:

options AHCISATA_EXTRA_DELAY_MS=100

I will commit the patch if there's no objection.

Thanks,
rin

Re: IDENTIFY failed

[Rin Okuyama]

On 2021/11/04 23:28, Brian Buhrow wrote:

Hello.  Without going and reading the probe routines, I wonder if we 
can create some sort
of hybrid approach?  Specifically, probe with the shorter delays, then, if we 
get a timeout,
reset and probe with the longer delays?  That wil cause hardware that doesn't 
exhibit the
behavior to work with the faster probes, while slowing the non-working 
hardware, slightly
during boot, while it's probed twice.  Again, I'm not sure how dificult it is 
to introduce that
logic, but it's a similar logic we used to determine if old PATA drives needed 
specific ATA
commands to address blocks over 148GB, or something like that.  (We'd try the 
command with the
standard command and, if it failed, then try it with the altered command and 
set a quirk.)


I'm not sure whether this is possible. The failure should be related to
ahci_probe_drive(), but the error itself occurs afterward in wdattach().
I wonder whether we can start it over with extra delays from when
wdattach() fails.

If possible, this needs modifications for MI ata(4) layer. If the
affected HWs are limited, it should be cleaner to add a quirk to work
around them.

Thanks,
rin

Re: IDENTIFY failed

[Rin Okuyama]

Yeah. Patrick, Jun, experiment to adjust delays will be appreciated a lot,
if you have time. But, dmesg should be helpful enough :)

Thanks,
rin

On 2021/11/04 21:04, Jared McNeill wrote:

It's also possible that 2 full seconds of delays are unnecessary. Do those 
delays really need to be 500ms each?

On Thu, 4 Nov 2021, Rin Okuyama wrote:


Yeah, I know that. But, we already have two problem reports. What I am
concerned about is similar problems will occur for a lot of machines.

(Thinking again...) But, yes, by this way, innocent people will be punished
forever by extra seconds per boot...

Hmm, if affected hardware is somehow limited, we can just introduce something
like AHCI_QUIRK_EXTRADELAY. Otherwise, we can reconsider, for example, before
NetBSD 10 is released.

Jun, Patrick, can you please provide full dmesg for your machines?

Thanks,
rin

On 2021/11/04 19:58, Jared McNeill wrote:

 From the commit message:

   There are a handful of inexplicable 500ms delays introduced to the drive
   detect path in this driver, slowing boot. They can be re-enabled with
   options AHCISATA_EXTRA_DELAY, but should not be enabled for normal
   kernels.
   If a delay does need to be introduced in these places, the value should
   either be more carefully selected or the scope limited to hardware that
   requires the extra delay.

I don't have any hardware that has problems with the delays removed, so go 
ahead and revert this commit if you're happy with that as a solution. It would 
be better to fix the problem properly though as this costs multiple seconds per 
drive at boot.

Take care,
Jared


On Thu, 4 Nov 2021, Rin Okuyama wrote:


Can't we put back AHCISATA_EXTRA_DELAY by default?

IIUC, the option affects only probe/reset; no bad effects for
I/O performance.

Thanks,
rin

On 2021/11/01 21:19, Patrick Welche wrote:

On Fri, Oct 29, 2021 at 01:05:26PM +0900, Jun Ebihara wrote:

From: matthew green 
Subject: re: IDENTIFY failed
Date: Fri, 29 Oct 2021 07:18:09 +1100


autoconfiguration error: ahcisata0 port 1: setting WDCTL_RST failed for drive 0

https://mail-index.netbsd.org/current-users/2021/10/27/msg041615.html

this one has reduced timeframe, too:

between
NetBSD 9.99.91 (GENERIC) #0: Tue Oct 12 19:57:53 UTC 2021 OK
NetBSD 9.99.92 (GENERIC) #0: Mon Oct 25 20:32:38 UTC 2021 Failed

which changed how some interrupt handling works, and:
http://mail-index.netbsd.org/source-changes/2021/10/11/msg132941.html
which removed some delays in the probe path.  possibly this one
is more likely to be at fault since it touches the probe path
directly.


add
/usr/src/sys/arch/amd64/conf/GENERIC.local
options AHCISATA_EXTRA_DELAY

compile kernel


That did the trick - thanks! (Wanted to be near the box before trying it)


Cheers,

Patrick

Re: IDENTIFY failed

[Rin Okuyama]

Yeah, I know that. But, we already have two problem reports. What I am
concerned about is similar problems will occur for a lot of machines.

(Thinking again...) But, yes, by this way, innocent people will be punished
forever by extra seconds per boot...

Hmm, if affected hardware is somehow limited, we can just introduce something
like AHCI_QUIRK_EXTRADELAY. Otherwise, we can reconsider, for example, before
NetBSD 10 is released.

Jun, Patrick, can you please provide full dmesg for your machines?

Thanks,
rin

On 2021/11/04 19:58, Jared McNeill wrote:

 From the commit message:

   There are a handful of inexplicable 500ms delays introduced to the drive
   detect path in this driver, slowing boot. They can be re-enabled with
   options AHCISATA_EXTRA_DELAY, but should not be enabled for normal
   kernels.
   If a delay does need to be introduced in these places, the value should
   either be more carefully selected or the scope limited to hardware that
   requires the extra delay.

I don't have any hardware that has problems with the delays removed, so go 
ahead and revert this commit if you're happy with that as a solution. It would 
be better to fix the problem properly though as this costs multiple seconds per 
drive at boot.

Take care,
Jared


On Thu, 4 Nov 2021, Rin Okuyama wrote:


Can't we put back AHCISATA_EXTRA_DELAY by default?

IIUC, the option affects only probe/reset; no bad effects for
I/O performance.

Thanks,
rin

On 2021/11/01 21:19, Patrick Welche wrote:

On Fri, Oct 29, 2021 at 01:05:26PM +0900, Jun Ebihara wrote:

From: matthew green 
Subject: re: IDENTIFY failed
Date: Fri, 29 Oct 2021 07:18:09 +1100


autoconfiguration error: ahcisata0 port 1: setting WDCTL_RST failed for drive 0

https://mail-index.netbsd.org/current-users/2021/10/27/msg041615.html

this one has reduced timeframe, too:

between
NetBSD 9.99.91 (GENERIC) #0: Tue Oct 12 19:57:53 UTC 2021 OK
NetBSD 9.99.92 (GENERIC) #0: Mon Oct 25 20:32:38 UTC 2021 Failed

which changed how some interrupt handling works, and:
    http://mail-index.netbsd.org/source-changes/2021/10/11/msg132941.html
which removed some delays in the probe path.  possibly this one
is more likely to be at fault since it touches the probe path
directly.


add
/usr/src/sys/arch/amd64/conf/GENERIC.local
options AHCISATA_EXTRA_DELAY

compile kernel


That did the trick - thanks! (Wanted to be near the box before trying it)


Cheers,

Patrick

Re: IDENTIFY failed

[Rin Okuyama]

Can't we put back AHCISATA_EXTRA_DELAY by default?

IIUC, the option affects only probe/reset; no bad effects for
I/O performance.

Thanks,
rin

On 2021/11/01 21:19, Patrick Welche wrote:

On Fri, Oct 29, 2021 at 01:05:26PM +0900, Jun Ebihara wrote:

From: matthew green 
Subject: re: IDENTIFY failed
Date: Fri, 29 Oct 2021 07:18:09 +1100


autoconfiguration error: ahcisata0 port 1: setting WDCTL_RST failed for drive 0

https://mail-index.netbsd.org/current-users/2021/10/27/msg041615.html

this one has reduced timeframe, too:

between
NetBSD 9.99.91 (GENERIC) #0: Tue Oct 12 19:57:53 UTC 2021 OK
NetBSD 9.99.92 (GENERIC) #0: Mon Oct 25 20:32:38 UTC 2021 Failed

which changed how some interrupt handling works, and:
http://mail-index.netbsd.org/source-changes/2021/10/11/msg132941.html
which removed some delays in the probe path.  possibly this one
is more likely to be at fault since it touches the probe path
directly.


add
/usr/src/sys/arch/amd64/conf/GENERIC.local
options AHCISATA_EXTRA_DELAY

compile kernel


That did the trick - thanks! (Wanted to be near the box before trying it)


Cheers,

Patrick

Re: Automated report: NetBSD-current/i386 test failure

[Rin Okuyama]

This test still fails as:

kqueue: [5.986468s] Failed: dir/b did not receive NOTE_LINK

Can you please take a look?

Thanks,
rin

On 2021/10/21 5:43, NetBSD Test Fixture wrote:

This is an automatically generated notice of a new failure of the
NetBSD test suite.

The newly failing test case is:

 fs/tmpfs/t_link:kqueue

The above test failed in each of the last 4 test runs, and passed in
at least 26 consecutive runs before that.

The following commits were made between the last successful test and
the failed test:

 2021.10.20.03.08.16 thorpej src/sys/coda/coda_vnops.c,v 1.116
 2021.10.20.03.08.17 thorpej src/sys/fs/msdosfs/msdosfs_vnops.c,v 1.107
 2021.10.20.03.08.17 thorpej src/sys/fs/nilfs/nilfs_vnops.c,v 1.45
 2021.10.20.03.08.17 thorpej src/sys/fs/ptyfs/ptyfs_vnops.c,v 1.67
 2021.10.20.03.08.17 thorpej src/sys/fs/puffs/puffs_vnops.c,v 1.223
 2021.10.20.03.08.17 thorpej src/sys/fs/sysvbfs/sysvbfs_vnops.c,v 1.68
 2021.10.20.03.08.17 thorpej src/sys/fs/tmpfs/tmpfs_rename.c,v 1.11
 2021.10.20.03.08.17 thorpej src/sys/fs/tmpfs/tmpfs_subr.c,v 1.114
 2021.10.20.03.08.17 thorpej src/sys/fs/tmpfs/tmpfs_vnops.c,v 1.148
 2021.10.20.03.08.17 thorpej src/sys/fs/udf/udf_rename.c,v 1.14
 2021.10.20.03.08.17 thorpej src/sys/fs/udf/udf_vnops.c,v 1.117
 2021.10.20.03.08.17 thorpej src/sys/fs/union/union_vnops.c,v 1.79
 2021.10.20.03.08.17 thorpej src/sys/fs/unionfs/unionfs_vnops.c,v 1.17
 2021.10.20.03.08.18 thorpej src/sys/fs/v7fs/v7fs_vnops.c,v 1.32
 2021.10.20.03.08.18 thorpej src/sys/kern/vfs_vnode.c,v 1.128
 2021.10.20.03.08.18 thorpej src/sys/kern/vfs_vnops.c,v 1.224
 2021.10.20.03.08.18 thorpej src/sys/kern/vnode_if.sh,v 1.72
 2021.10.20.03.08.18 thorpej src/sys/kern/vnode_if.src,v 1.83
 2021.10.20.03.08.18 thorpej src/sys/miscfs/deadfs/dead_vnops.c,v 1.66
 2021.10.20.03.08.18 thorpej src/sys/miscfs/genfs/genfs.h,v 1.38
 2021.10.20.03.08.18 thorpej src/sys/miscfs/genfs/genfs_rename.c,v 1.6
 2021.10.20.03.08.18 thorpej src/sys/miscfs/genfs/genfs_vnops.c,v 1.216
 2021.10.20.03.08.18 thorpej src/sys/miscfs/genfs/layer_vnops.c,v 1.72
 2021.10.20.03.08.18 thorpej src/sys/miscfs/umapfs/umap_vnops.c,v 1.62
 2021.10.20.03.08.18 thorpej src/sys/nfs/nfs_bio.c,v 1.200
 2021.10.20.03.08.18 thorpej src/sys/nfs/nfs_kq.c,v 1.32
 2021.10.20.03.08.18 thorpej src/sys/nfs/nfs_vnops.c,v 1.321
 2021.10.20.03.08.18 thorpej src/sys/rump/librump/rumpvfs/rumpfs.c,v 1.166
 2021.10.20.03.08.18 thorpej src/sys/sys/event.h,v 1.49
 2021.10.20.03.08.18 thorpej src/sys/sys/vnode.h,v 1.298
 2021.10.20.03.08.19 thorpej 
src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vnops.c,v 1.76
 2021.10.20.03.08.19 thorpej src/lib/libc/sys/kqueue.2,v 1.55
 2021.10.20.03.08.19 thorpej src/sys/ufs/chfs/chfs_vnops.c,v 1.46
 2021.10.20.03.08.19 thorpej src/sys/ufs/ext2fs/ext2fs_readwrite.c,v 1.78
 2021.10.20.03.08.19 thorpej src/sys/ufs/ext2fs/ext2fs_rename.c,v 1.12
 2021.10.20.03.08.19 thorpej src/sys/ufs/ext2fs/ext2fs_vnops.c,v 1.136
 2021.10.20.03.08.19 thorpej src/sys/ufs/lfs/lfs_rename.c,v 1.25
 2021.10.20.03.08.19 thorpej src/sys/ufs/lfs/lfs_vnops.c,v 1.340
 2021.10.20.03.08.19 thorpej src/sys/ufs/lfs/ulfs_readwrite.c,v 1.28
 2021.10.20.03.08.19 thorpej src/sys/ufs/lfs/ulfs_vnops.c,v 1.55
 2021.10.20.03.08.19 thorpej src/sys/ufs/ufs/ufs_acl.c,v 1.3
 2021.10.20.03.08.19 thorpej src/sys/ufs/ufs/ufs_extern.h,v 1.88
 2021.10.20.03.08.19 thorpej src/sys/ufs/ufs/ufs_readwrite.c,v 1.127
 2021.10.20.03.08.19 thorpej src/sys/ufs/ufs/ufs_rename.c,v 1.14
 2021.10.20.03.08.19 thorpej src/sys/ufs/ufs/ufs_vnops.c,v 1.260
 2021.10.20.03.08.19 thorpej src/tests/kernel/kqueue/t_vnode.c,v 1.2
 2021.10.20.03.09.45 thorpej src/sys/sys/param.h,v 1.705
 2021.10.20.03.13.14 thorpej src/sys/kern/vnode_if.c,v 1.115
 2021.10.20.03.13.14 thorpej src/sys/rump/include/rump/rumpvnode_if.h,v 1.37
 2021.10.20.03.13.14 thorpej src/sys/rump/librump/rumpvfs/rumpvnode_if.c,v 
1.37
 2021.10.20.03.13.14 thorpej src/sys/sys/vnode_if.h,v 1.108
 2021.10.20.03.26.20 thorpej src/lib/libc/sys/kqueue.2,v 1.56
 2021.10.20.05.00.37 rillig src/usr.bin/indent/indent.c,v 1.140
 2021.10.20.05.00.37 rillig src/usr.bin/indent/indent.h,v 1.39
 2021.10.20.05.00.37 rillig src/usr.bin/indent/io.c,v 1.98
 2021.10.20.05.07.08 rillig src/usr.bin/indent/indent.c,v 1.141
 2021.10.20.05.14.21 rillig src/tests/usr.bin/indent/opt_bacc.c,v 1.4
 2021.10.20.05.14.21 rillig src/usr.bin/indent/indent.c,v 1.142
 2021.10.20.05.14.21 rillig src/usr.bin/indent/indent.h,v 1.40
 2021.10.20.05.14.21 rillig src/usr.bin/indent/io.c,v 1.99
 2021.10.20.05.14.21 rillig src/usr.bin/indent/pr_comment.c,v 1.80
 2021.10.20.05.26.46 rillig src/usr.bin/indent/indent.c,v 1.143
 2021.10.20.05.26.46 rillig src/usr.bin/indent/indent.h,v 1.41
 2021.10.20.05.26.46 rillig 

Re: Build failure for evbarmv6hf due to new OpenSSH

[Rin Okuyama]

Hi,

this should be fixed differently by christos@:

http://mail-index.netbsd.org/source-changes/2021/09/03/msg132014.html

Thanks,
rin

On 2021/09/03 20:14, Patrick Welche wrote:

On Fri, Sep 03, 2021 at 06:46:20PM +0900, Rin Okuyama wrote:

Build for evbarmv6hf{,eb} fails due to collision of symbol tilde_expand b/w
libedit and new libopenssh:


I just hit this too, and was bemused by why the amd64 build wasn't affected:

# find /usr/src/distrib/amd64 -name list | grep ssh
# find /usr/src/distrib/evbarm  -name list | grep ssh
/usr/src/distrib/evbarm/instkernel/sshramdisk/list


... applying your patch locally!


Cheers,

Patrick

Build failure for evbarmv6hf due to new OpenSSH

[Rin Okuyama]

Hi,

Build for evbarmv6hf{,eb} fails due to collision of symbol tilde_expand b/w
libedit and new libopenssh:


#  link  obj.evbarm-earmv6hfeb/ramdiskbin
/build/tools/lib/gcc/armv6eb--netbsdelf-eabihf/10.3.0/../../../../armv6eb--netbsdelf-eabihf/bin/ld:
 /build/dest/evbarm-earmv6hfeb/usr/lib/libssh.a(misc.o): in function 
`tilde_expand':
misc.c:(.text+0x2364): multiple definition of `tilde_expand'; 
/build/dest/evbarm-earmv6hfeb/usr/lib/libedit.a(readline.o):readline.c:(.text+0x3544):
 first defined here
collect2: error: ld returned 1 exit status


tilde_expand() in libedit should be global for compatibility with readline.
Mangle OpenSSH one, which cannot be static unfortunately?


--- crypto/external/bsd/openssh/dist/misc.h 2 Sep 2021 11:26:18 -   
1.22
+++ crypto/external/bsd/openssh/dist/misc.h 3 Sep 2021 09:41:16 -
@@ -45,6 +45,11 @@ struct ForwardOptions {
 
 /* misc.c */
 
+#ifdef __NetBSD__

+/* XXX avoid collision with libedit/readline */
+#definetilde_expandopenssh_tilde_expand
+#endif
+
 char   *chop(char *);
 voidrtrim(char *);
 void   skip_space(char **);


Thanks,
rin

Re: Automated report: NetBSD-current/i386 build failure

[Rin Okuyama]

On 2021/07/19 10:28, David Holland wrote:

that is... less than helpful :-(

it looks like CVS randomly didn't commit some of my changes,
investigating...


Logs below are usually more helpful.

On 2021/07/19 9:42, NetBSD Test Fixture wrote:

Logs can be found at:

 
http://releng.NetBSD.org/b5reports/i386/commits-2021.07.html#2021.07.18.23.57.34


Thanks,
rin

Re: linux emul and newer glibc

[Rin Okuyama]

Hi,

On 2021/06/28 2:40, Manuel Bouyer wrote:

Hello,
I'm trying to run a binary which wants GLIBCXX_3.4.21, while with the suse
packages we have GLIBCXX_3.4.19. Before I try grabbing newer libraries,
has anyone tried to run linux binaries with more recent libraries ?


For my amd64 machine, GLIBCXX_3.4.28 (from glibc 2.32) works just fine,
which is extracted manually from Fedora 33 by pkgsrc/pkgtools/rpm2pkg.

Thanks,
rin

Re: Big-endian mode supported for Raspberry Pi [0-3] with bootable images available

[Rin Okuyama]

Hi,

Hmm, I have never seen such a panic. If it is reproducible,
it should be worth to send a PR.

Thanks,
rin

On 2021/01/07 5:51, John Klos wrote:

Thank you for all your hard work!

The images work just fine out of the box. After a few hours of compiling, there 
was a panic. This is a 3B+ (the 1400 MHz one):

[ 18045.402869] ifree: dev = 0xa801, ino = 35088, fs = /
[ 18045.402869] panic: ffs_freefile_common: freeing free inode
[ 18045.414509] cpu0: Begin traceback...
[ 18045.414509] trace fp c0004376f810
[ 18045.414509] fp c0004376f840 vpanic() at c04e5d5c 
netbsd:vpanic+0x14c
[ 18045.424917] fp c0004376f8a0 panic() at c04e5e54 
netbsd:panic+0x44
[ 18045.424917] fp c0004376f930 ffs_freefile_common.isra.0() at 
c0422f44 netbsd:ffs_freefile_common.isra.0+0x2d4
[ 18045.436775] fp c0004376f9a0 ffs_freefile() at c0427bb4 
netbsd:ffs_freefile+0xf4
[ 18045.445200] fp c0004376fa00 ffs_reclaim() at c0434968 
netbsd:ffs_reclaim+0x110
[ 18045.445200] fp c0004376fa40 VOP_RECLAIM() at c0556cfc 
netbsd:VOP_RECLAIM+0x34
[ 18045.455684] fp c0004376fa70 vcache_reclaim() at c0548a6c 
netbsd:vcache_reclaim+0x14c
[ 18045.465203] fp c0004376fb40 vrelel() at c0549520 
netbsd:vrelel+0x2a0
[ 18045.465203] fp c0004376fba0 vn_close() at c054dcfc 
netbsd:vn_close+0x44
[ 18045.477720] fp c0004376fbd0 closef() at c047c448 
netbsd:closef+0x60
[ 18045.477720] fp c0004376fc10 fd_free() at c047f3c0 
netbsd:fd_free+0xf8
[ 18045.488230] fp c0004376fc90 exit1() at c048a5cc 
netbsd:exit1+0xfc
[ 18045.488230] fp c0004376fd80 sys_exit() at c048af08 
netbsd:sys_exit+0x38
[ 18045.498527] fp c0004376fdb0 syscall() at c008ef1c 
netbsd:syscall+0x18c
[ 18045.508234] fp c0004376fe60 trap_el0_sync() at c00903f0 
netbsd:trap_el0_sync+0x380
[ 18045.508234] tf c0004376fed0 el0_trap() at c00927f0 
netbsd:el0_trap
[ 18045.518235]  trapframe 0xc0004376fed0 (304 bytes) 
[ 18045.518235] pc=fd5f181b0c14,   spsr=8000
[ 18045.518235]    esr=5601,    far=f53aaf49a000
[ 18045.529932] x0=, x1=
[ 18045.529932] x2=00020013e000, x3=ff837b80
[ 18045.529932] x4=, x5=fd5f1844a3c0
[ 18045.541002] x6=, x7=4545524348363400
[ 18045.541002] x8=fd5f, x9=0003
[ 18045.541002]    x10=fd5f18221000,    x11=0030
[ 18045.552073]    x12=fd5f18239a00,    x13=fd5f17c008c0
[ 18045.552073]    x14=0014,    x15=4008
[ 18045.552073]    x16=00020013d1f8,    x17=fd5f181b0c10
[ 18045.563146]    x18=0041,    x19=
[ 18045.563146]    x20=00020013d000,    x21=ff838fe0
[ 18045.563146]    x22=00020013df80,    x23=
[ 18045.574215]    x24=ff838fe0,    x25=f33f
[ 18045.574215]    x26=,    x27=
[ 18045.574215]    x28=, fp=x29=ff837b80
[ 18045.585287] lr=x30=00020011c890, sp=ff837b80
[ 18045.585287] 
[ 18045.585287] cpu0: End traceback...
[ 18045.594926] rebooting...



This was a clean big endian filesystem on a USB attached SSD on its first boot. 
Trying to fully fsck didn't work (I don't have a record - it was on the local 
console), and trying to fsck on a little endian Pi gave this:

http://mail-index.netbsd.org/port-arm/2020/12/26/msg007132.html

I decided to make a clean little endian filesystem and restart. However, 
enabling WAPBL in fstab causes the boot to fail with messages saying that the 
filesystem is read-only, then:

mount /dev/sd0a /
mount_ffs: /dev/sd0a on /: specified device does not match mounted device

Perhaps it should be noted somewhere that WAPBL can't be used on other-endian 
systems, and a more meaningful error presented when it is attempted?

John Klos

Re: Automated report: NetBSD-current/i386 build failure

[Rin Okuyama]

Sorry for breakage. I'll fix this.

rin

On 2020/12/19 17:40, NetBSD Test Fixture wrote:

This is an automatically generated notice of a NetBSD-current/i386
build failure.

The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2020.12.19.07.19.30.

An extract from the build.sh output follows:

 /tmp/build/2020.12.19.07.19.30-i386/tools/bin/i486--netbsdelf-objcopy -x  
maxfilename.o
 --- dependall-sys ---
 --- dependall-arch ---
 In file included from 
/tmp/build/2020.12.19.07.19.30-i386/src/sys/arch/i386/stand/boot/biosboot/../../../../../lib/libsa/lfsv1.c:30:
 
/tmp/build/2020.12.19.07.19.30-i386/src/sys/arch/i386/stand/boot/biosboot/../../../../../lib/libsa/ufs.c:
 In function 'lfsv1_open':
 
/tmp/build/2020.12.19.07.19.30-i386/src/sys/arch/i386/stand/boot/biosboot/../../../../../lib/libsa/ufs.c:586:9:
 error: 'FS' {aka 'struct salfs'} has no member named 'lfs_version'
   586 |   fs->lfs_version != REQUIRED_LFS_VERSION ||
   | ^~
 --- dependall-external ---
 --- maxpathname.o ---
 #   compile  libgroff/maxpathname.o
 /tmp/build/2020.12.19.07.19.30-i386/tools/bin/i486--netbsdelf-c++ 
-frandom-seed=d9de403b -O2 -D__GETOPT_PREFIX=groff_ -Werror -fPIE -fno-rtti 
-fno-exceptions   --sysroot=/tmp/build/2020.12.19.07.19.30-i386/destdir 
-DHAVE_CONFIG_H 
-I/tmp/build/2020.12.19.07.19.30-i386/src/external/gpl2/groff/include 
-I/tmp/build/2020.12.19.07.19.30-i386/src/external/gpl2/groff/dist/src/include  
-c
/tmp/build/2020.12.19.07.19.30-i386/src/external/gpl2/groff/dist/src/libs/libgroff/maxpathname.cpp
 -o maxpathname.o
 --- dependall-usr.sbin ---
 --- dependall-hdaudioctl ---
 --- hdaudioctl.d ---
 #create  hdaudioctl/hdaudioctl.d
 CC=/tmp/build/2020.12.19.07.19.30-i386/tools/bin/i486--netbsdelf-gcc 
/tmp/build/2020.12.19.07.19.30-i386/tools/bin/nbmkdep -f hdaudioctl.d.tmp  --   
-std=gnu99   -D_KERNTYPES --sysroot=/tmp/build/2020.12.19.07.19.30-i386/destdir 
/tmp/build/2020.12.19.07.19.30-i386/src/usr.sbin/hdaudioctl/hdaudioctl.c &&  mv 
-f hdaudioctl.d.tmp hdaudioctl.d
 --- dependall-external ---
 --- dependall-gpl3 ---
 checking for getrlimit... yes
 --- dependall-sys ---
 *** [lfsv1.o] Error code 1
 --- dependall-external ---
 --- dependall-mpl ---

The following commits were made between the last successful build and
the failed build:

 2020.12.19.07.19.30 rin src/sys/lib/libsa/ufs.c,v 1.77

Logs can be found at:

 
http://releng.NetBSD.org/b5reports/i386/commits-2020.12.html#2020.12.19.07.19.30

Re: Big-endian mode supported for Raspberry Pi [0-3] with bootable images available

[Rin Okuyama]

On 2020/12/03 21:46, Michael van Elst wrote:

rokuyama...@gmail.com (Rin Okuyama) writes:


vchiq(4) and vcaudio(4) are not supported in big-endian mode. This
requires heavy modifications to third party source codes. Anyway, we
will switch to vc4 drm driver, hopefully soon.


The vc4 driver is not a replacement for vchiq or vcaudio, but since
it kills vchiq, you then also need a hardware driver for audio (and
a second one for RPI4 which has different audio hardware).


Thanks for correction. Yeah, we need independent audio driver in
that case. I hope that the new driver gets simpler than vchiq...

Thanks,
rin

Big-endian mode supported for Raspberry Pi [0-3] with bootable images available

[Rin Okuyama]

I'm happy to announce that big-endian mode has been supported for
Raspberry Pi [0-3] in -current. Bootable disk images are available in
official daily snapshots. You can enjoy aarch64eb/armeb world on your
Pi's by just flashing these images to microSD!

vchiq(4) and vcaudio(4) are not supported in big-endian mode. This
requires heavy modifications to third party source codes. Anyway, we
will switch to vc4 drm driver, hopefully soon.

Pi 4 is not supported also. It needs ACPI, but acpica does not support
big-endian environments. This is really headache...

Other devices and features are supported in a similar manner as in
little-endian modes. Please tell me if you find endian-related bugs.

Available architectures and supported models are:

- aarch64eb

Pi 3 is supported by GENERIC64 kernel.

Bootable image is:
http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/latest/evbarm-aarch64eb/binary/gzimg/arm64.img.gz

- earmv7hfeb and earmv7eb

Pi [2-3] are supported by GENERIC kernel.

Bootable image for earmv7hfeb is:
http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/latest/evbarm-earmv7hfeb/binary/gzimg/armv7.img.gz

- earmv6hfeb and earmv6eb

Pi [0-1] are supported by RPI, and Pi 2 is supported by RPI2 kernel.

Bootable image for earmv6hfeb is:
http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/latest/evbarm-earmv6hfeb/binary/gzimg/rpi.img.gz

Enjoy,
rin

Re: Automated report: NetBSD-current/i386 build failure

[Rin Okuyama]

On 2020/10/30 2:10, Rin Okuyama wrote:

On 2020/10/30 1:58, nia wrote:

It should be fixed already.


Please also try build for sun2, which does not support shlib;
All programs linked to libsqlite3 need -lm explicitly.


Periodic build for sun2 and vax is broken due to the sqlite3 change:

https://releng.netbsd.org/builds/HEAD/202010292030Z/

Nia, please fix them.

Note that vax uses its own (i.e., non-IEE754) floating-point formats.

Thanks,
rin

Re: Automated report: NetBSD-current/i386 build failure

[Rin Okuyama]

On 2020/10/30 1:58, nia wrote:

It should be fixed already.


Please also try build for sun2, which does not support shlib;
All programs linked to libsqlite3 need -lm explicitly.

Thanks,
rin

Re: Automated report: NetBSD-current/i386 test failure

[Rin Okuyama]

On 2020/10/22 12:06, Chuck Silvers wrote:

On Wed, Oct 21, 2020 at 08:30:17PM +0900, Rin Okuyama wrote:

On 2020/10/21 20:10, Andreas Gustafsson wrote:

Two days ago, the NetBSD Test Fixture wrote:

This is an automatically generated notice of new failures of the
NetBSD test suite.

The newly failing test cases are:

  sbin/resize_ffs/t_grow:grow_16M_v0_8192
  sbin/resize_ffs/t_grow:grow_16M_v1_16384
  sbin/resize_ffs/t_grow:grow_16M_v2_32768
  sbin/resize_ffs/t_grow_swapped:grow_16M_v0_65536
  sbin/resize_ffs/t_grow_swapped:grow_16M_v1_4096
  sbin/resize_ffs/t_grow_swapped:grow_16M_v2_8192
  sbin/resize_ffs/t_shrink:shrink_24M_16M_v0_32768
  sbin/resize_ffs/t_shrink:shrink_24M_16M_v1_65536
  sbin/resize_ffs/t_shrink_swapped:shrink_24M_16M_v0_4096
  sbin/resize_ffs/t_shrink_swapped:shrink_24M_16M_v1_8192


These are still failing as of source date 2020.10.21.06.36.10, and the
commit that triggered the failures has now been identified:

2020.10.18.18.22.29 chs src/sys/rump/librump/rumpvfs/vm_vfs.c 1.39
2020.10.18.18.22.29 chs src/sys/uvm/uvm_page.c 1.248
2020.10.18.18.22.29 chs src/sys/uvm/uvm_pager.c 1.130

Logs from real amd64 hardware are at:


http://www.gson.org/netbsd/bugs/build/amd64-baremetal/commits-2020.10.html#2020.10.18.18.22.29


This seems due to src/sys/rump/librump/rumpvfs/vm_vfs.c 1.39;
tests pass if only this commit is reverted in librumpvfs.so.


I committed a fix for this just now.
thanks for pointing it out.


The tests now pass for me. Thank you for quick fix!

rin

Re: Automated report: NetBSD-current/i386 test failure

[Rin Okuyama]

On 2020/10/21 20:10, Andreas Gustafsson wrote:

Two days ago, the NetBSD Test Fixture wrote:

This is an automatically generated notice of new failures of the
NetBSD test suite.

The newly failing test cases are:

 sbin/resize_ffs/t_grow:grow_16M_v0_8192
 sbin/resize_ffs/t_grow:grow_16M_v1_16384
 sbin/resize_ffs/t_grow:grow_16M_v2_32768
 sbin/resize_ffs/t_grow_swapped:grow_16M_v0_65536
 sbin/resize_ffs/t_grow_swapped:grow_16M_v1_4096
 sbin/resize_ffs/t_grow_swapped:grow_16M_v2_8192
 sbin/resize_ffs/t_shrink:shrink_24M_16M_v0_32768
 sbin/resize_ffs/t_shrink:shrink_24M_16M_v1_65536
 sbin/resize_ffs/t_shrink_swapped:shrink_24M_16M_v0_4096
 sbin/resize_ffs/t_shrink_swapped:shrink_24M_16M_v1_8192


These are still failing as of source date 2020.10.21.06.36.10, and the
commit that triggered the failures has now been identified:

   2020.10.18.18.22.29 chs src/sys/rump/librump/rumpvfs/vm_vfs.c 1.39
   2020.10.18.18.22.29 chs src/sys/uvm/uvm_page.c 1.248
   2020.10.18.18.22.29 chs src/sys/uvm/uvm_pager.c 1.130

Logs from real amd64 hardware are at:

   
http://www.gson.org/netbsd/bugs/build/amd64-baremetal/commits-2020.10.html#2020.10.18.18.22.29


This seems due to src/sys/rump/librump/rumpvfs/vm_vfs.c 1.39;
tests pass if only this commit is reverted in librumpvfs.so.

Thanks,
rin

Re: 9.99.73 NFS file corruption

[Rin Okuyama]

On 2020/10/19 1:56, Reinoud Zandijk wrote:

On Sun, Oct 18, 2020 at 05:59:11PM +0900, Rin Okuyama wrote:

On 2020/10/18 2:25, Anthony Mallet wrote:

As Chuck suggested in another e-mail, reverting uvm_bio.c to previous 1.121
$NetBSD: uvm_bio.c,v 1.121 2020/07/09 09:24:32 rin Exp $
appears to fix the issue (at least the test script was working 3 times
in a row while it always failed with uvm_bio.c:1.222).


Thank you very much for providing test case. I can reproduce the
problem on amd64 and i386. I've reverted that commit.


Thanks! You just beat me. I just tested it with NetBSD/amd64 6.99.73 (23 sept)
and that passed. The uvm_bio.c switched in that timeframe indeed and I was
about to suggest this :)


Yeah, thank you for your report. And sorry for inconvenience...

Thanks,
rin

Re: 9.99.73 NFS file corruption

[Rin Okuyama]

On 2020/10/18 2:25, Anthony Mallet wrote:

I made some progress on this, and could apparently fix something. See
attached a sample script that reliably reproduces the issue.

To summarize: when the script is run on the NFS client, changes in the
sqlite database do appear on the NFS client, but do not appear on
the server.

As Chuck suggested in another e-mail, reverting uvm_bio.c to previous 1.121
$NetBSD: uvm_bio.c,v 1.121 2020/07/09 09:24:32 rin Exp $
appears to fix the issue (at least the test script was working 3 times
in a row while it always failed with uvm_bio.c:1.222).


Thank you very much for providing test case. I can reproduce the
problem on amd64 and i386. I've reverted that commit.

I'm so sorry everyone for breakage.

Thanks,
rin

 Forwarded Message 
Subject: CVS commit: src/sys/uvm
Date: Sun, 18 Oct 2020 08:52:15 +
From: Rin Okuyama 
Reply-To: source-change...@netbsd.org
To: source-changes-f...@netbsd.org

Module Name:src
Committed By:   rin
Date:   Sun Oct 18 08:52:15 UTC 2020

Modified Files:
src/sys/uvm: uvm_bio.c

Log Message:
PR kern/55658

Revert rev 1.122:
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/uvm/uvm_bio.c#rev1.122

If this commit is applied to NFS client, changes to files in client
side are sometimes invisible in server side, which results in file
corruption.

Demonstrated by test code provided by Anthony Mallet:
https://mail-index.netbsd.org/current-users/2020/10/17/msg039708.html

Whether the test case above passes or not depends on architectures
and size of NFS I/O specified by -r and -w options of mount_nfs(8)
(the default size is 32KB for x86 and 8KB for other archs).

Whereas it fails on amd64 and i386 with the default size, it passes
on other archs (aarch64, arm, alpha, m68k, and powerpc at least) with
their default. On most ports, it fails with some I/O sizes.

However, the condition for failure is still unclear; whereas it fails
with 2KB I/O size on amiga (m68k, 8KB page), it passes with same I/O
size on alpha (8KB page). It may depends on some VM parameters or
details in pmap implementation, or some race conditions are involved.

Great thanks to Anthony Mallet for providing the test code, and sorry
everyone for breakage.


To generate a diff of this commit:
cvs rdiff -u -r1.122 -r1.123 src/sys/uvm/uvm_bio.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: file system corruption

[Rin Okuyama]

On 2020/10/15 20:27, Thomas Klausner wrote:

On Thu, Oct 15, 2020 at 12:03:36PM +0100, Patrick Welche wrote:

Is yours a ryzen system? (mine is, and it has filesystem issues - just
trying to see why it is not a common issue)


Yes:


There was a report on Twitter (in Japanese):

https://twitter.com/rin5roid/status/1312728335299104768

GCC for aarch64 built by Ryzen causes SIGILL, while that built by
Intel processor works without problems. I've never observed such a
failure (I'm using only Intel processors at the moment).

Thanks,
rin

Re: NetBSD-7.0 boots OK and NetBSD-8.0 hangs/crashes during boot on a MacBook7,1

[Rin Okuyama]

On 2020/07/06 10:05, Greg A. Woods wrote:

NetBSD-7.2 boots fine from USB on the MacBook Pro (MacBook7,1) (with the
help of rEFIT on a second USB stick).

NetBSD-8.2 and newer, including the most recent -current, hangs during
boot and the kernel messages appear to have torn video:

  http://www.planix.ca/~woods/macbookpro-netbsd-boot-fail.jpg

...

In any case, what might have been changed after 8.0 that broke the video
output?  Where do I look?  Is amd64 video now the genfb(4) device code?
Or is it still vga(4)?  If it's genfb(4), then I do see commits about
doing anti-aliasing, and maybe the video junk I see could possibly be
explained by such a thing.


It seems that stride of framebuffer is not correctly set.

Your laptop has an NVIDIA GPU, doesn't it? If so, nouveaufb(4) is used
instead of genfb(4), which is normally used when booted from UEFI. It
should be worth trying

userconf disable nouveau*

for UEFI bootloader.

Thanks,
rin

powerpc userland broken b/w 2020/06/21 00:39 to 06/22 05:34 UTC

[Rin Okuyama]

For powerpc ports, src/sys/arch/powerpc/mcontext.h rev 1.20
(existed b/w 2020/06/21 00:39:59 to 2020/06/22 05:34:57)
turned out to be incorrect.

Userland built with this file does not work on kernel as of today.

If you have installed that userland, you need to install base.tgz,
i.e., libc, rtld, and libpthread, *prior* to updating kernel.
Then, update kernel and other userland binaries.

If you didn't installed the affected userland, you can (and should)
follow normal updating path.

I am so sorry for the inconvenience.

Thanks,
rin

Re: Automated report: NetBSD-current/i386 test failure

[Rin Okuyama]

Hi,

On 2020/06/19 21:04, Martin Husemann wrote:

On Fri, Jun 19, 2020 at 08:56:32PM +0900, Rin Okuyama wrote:

I will make these tests (and similar ones in kernel/t_trapsignal) skipped on
QEMU, if there's no objection.


No objections from me.
Could you file a qemu bug for this, please?


Thank you for your comment. I can reproduce the problem on QEMU 5.0.0.
I will send a report to them.

Thanks,
rin

Re: Automated report: NetBSD-current/i386 test failure

[Rin Okuyama]

This seems due to QEMU bug, as also observed in
tests/lib/libc/gen/t_siginfo:sigfpe_flt, see:

http://cvsweb.netbsd.org/bsdweb.cgi/src/tests/lib/libc/gen/t_siginfo.c#rev1.20

Actually, these tests pass on
(1) VirtualBox, and
(2) real hardware under amd64 kernel with COMPAT_NETBSD32.

I will make these tests (and similar ones in kernel/t_trapsignal) skipped on
QEMU, if there's no objection.

Thanks,
rin

On 2020/06/19 19:31, Rin Okuyama wrote:

I will examine this.

Thanks,
rin

On 2020/06/19 19:28, NetBSD Test Fixture wrote:

This is an automatically generated notice of new failures of the
NetBSD test suite.

The newly failing test cases are:

 lib/libc/sys/t_ptrace_wait3:traceme_crash_fpe
 lib/libc/sys/t_ptrace_wait3:traceme_signalignored_crash_fpe
 lib/libc/sys/t_ptrace_wait3:traceme_signalmasked_crash_fpe
 lib/libc/sys/t_ptrace_wait3:traceme_vfork_crash_fpe
 lib/libc/sys/t_ptrace_wait3:traceme_vfork_signalignored_crash_fpe
 lib/libc/sys/t_ptrace_wait3:traceme_vfork_signalmasked_crash_fpe
 lib/libc/sys/t_ptrace_wait4:traceme_crash_fpe
 lib/libc/sys/t_ptrace_wait4:traceme_signalignored_crash_fpe
 lib/libc/sys/t_ptrace_wait4:traceme_signalmasked_crash_fpe
 lib/libc/sys/t_ptrace_wait4:traceme_vfork_crash_fpe
 lib/libc/sys/t_ptrace_wait4:traceme_vfork_signalignored_crash_fpe
 lib/libc/sys/t_ptrace_wait4:traceme_vfork_signalmasked_crash_fpe
 lib/libc/sys/t_ptrace_wait4:unrelated_tracer_sees_crash_fpe
 lib/libc/sys/t_ptrace_wait4:unrelated_tracer_sees_signalignored_crash_fpe
 lib/libc/sys/t_ptrace_wait4:unrelated_tracer_sees_signalmasked_crash_fpe
 lib/libc/sys/t_ptrace_wait6:traceme_crash_fpe
 lib/libc/sys/t_ptrace_wait6:traceme_signalignored_crash_fpe
 lib/libc/sys/t_ptrace_wait6:traceme_signalmasked_crash_fpe
 lib/libc/sys/t_ptrace_wait6:traceme_vfork_crash_fpe
 lib/libc/sys/t_ptrace_wait6:traceme_vfork_signalignored_crash_fpe
 lib/libc/sys/t_ptrace_wait6:traceme_vfork_signalmasked_crash_fpe
 lib/libc/sys/t_ptrace_wait6:unrelated_tracer_sees_crash_fpe
 lib/libc/sys/t_ptrace_wait6:unrelated_tracer_sees_signalignored_crash_fpe
 lib/libc/sys/t_ptrace_wait6:unrelated_tracer_sees_signalmasked_crash_fpe
 lib/libc/sys/t_ptrace_wait:traceme_crash_fpe
 lib/libc/sys/t_ptrace_wait:traceme_signalignored_crash_fpe
 lib/libc/sys/t_ptrace_wait:traceme_signalmasked_crash_fpe
 lib/libc/sys/t_ptrace_wait:traceme_vfork_crash_fpe
 lib/libc/sys/t_ptrace_wait:traceme_vfork_signalignored_crash_fpe
 lib/libc/sys/t_ptrace_wait:traceme_vfork_signalmasked_crash_fpe
 lib/libc/sys/t_ptrace_waitid:traceme_crash_fpe
 lib/libc/sys/t_ptrace_waitid:traceme_signalignored_crash_fpe
 lib/libc/sys/t_ptrace_waitid:traceme_signalmasked_crash_fpe
 lib/libc/sys/t_ptrace_waitid:unrelated_tracer_sees_crash_fpe
 lib/libc/sys/t_ptrace_waitid:unrelated_tracer_sees_signalignored_crash_fpe
 lib/libc/sys/t_ptrace_waitid:unrelated_tracer_sees_signalmasked_crash_fpe
 lib/libc/sys/t_ptrace_waitpid:traceme_crash_fpe
 lib/libc/sys/t_ptrace_waitpid:traceme_signalignored_crash_fpe
 lib/libc/sys/t_ptrace_waitpid:traceme_signalmasked_crash_fpe
 lib/libc/sys/t_ptrace_waitpid:traceme_vfork_crash_fpe
 lib/libc/sys/t_ptrace_waitpid:traceme_vfork_signalignored_crash_fpe
 lib/libc/sys/t_ptrace_waitpid:traceme_vfork_signalmasked_crash_fpe
 lib/libc/sys/t_ptrace_waitpid:unrelated_tracer_sees_crash_fpe
 lib/libc/sys/t_ptrace_waitpid:unrelated_tracer_sees_signalignored_crash_fpe
 lib/libc/sys/t_ptrace_waitpid:unrelated_tracer_sees_signalmasked_crash_fpe

The above tests failed in each of the last 4 test runs, and passed in
at least 26 consecutive runs before that.

The following commits were made between the last successful test and
the failed test:

 2020.06.17.08.23.18 rin src/tests/lib/libc/sys/t_ptrace_wait.h,v 1.29
 2020.06.17.08.42.16 rin src/tests/lib/libc/sys/t_ptrace_signal_wait.h,v 1.2
 2020.06.17.08.42.16 rin src/tests/lib/libc/sys/t_ptrace_wait.h,v 1.30
 2020.06.17.09.11.13 msaitoh src/sys/dev/pci/ixgbe/ixgbe.c,v 1.231

Logs can be found at:

 
http://releng.NetBSD.org/b5reports/i386/commits-2020.06.html#2020.06.17.09.11.13

Re: Automated report: NetBSD-current/i386 test failure

[Rin Okuyama]

I will examine this.

Thanks,
rin

On 2020/06/19 19:28, NetBSD Test Fixture wrote:

This is an automatically generated notice of new failures of the
NetBSD test suite.

The newly failing test cases are:

 lib/libc/sys/t_ptrace_wait3:traceme_crash_fpe
 lib/libc/sys/t_ptrace_wait3:traceme_signalignored_crash_fpe
 lib/libc/sys/t_ptrace_wait3:traceme_signalmasked_crash_fpe
 lib/libc/sys/t_ptrace_wait3:traceme_vfork_crash_fpe
 lib/libc/sys/t_ptrace_wait3:traceme_vfork_signalignored_crash_fpe
 lib/libc/sys/t_ptrace_wait3:traceme_vfork_signalmasked_crash_fpe
 lib/libc/sys/t_ptrace_wait4:traceme_crash_fpe
 lib/libc/sys/t_ptrace_wait4:traceme_signalignored_crash_fpe
 lib/libc/sys/t_ptrace_wait4:traceme_signalmasked_crash_fpe
 lib/libc/sys/t_ptrace_wait4:traceme_vfork_crash_fpe
 lib/libc/sys/t_ptrace_wait4:traceme_vfork_signalignored_crash_fpe
 lib/libc/sys/t_ptrace_wait4:traceme_vfork_signalmasked_crash_fpe
 lib/libc/sys/t_ptrace_wait4:unrelated_tracer_sees_crash_fpe
 lib/libc/sys/t_ptrace_wait4:unrelated_tracer_sees_signalignored_crash_fpe
 lib/libc/sys/t_ptrace_wait4:unrelated_tracer_sees_signalmasked_crash_fpe
 lib/libc/sys/t_ptrace_wait6:traceme_crash_fpe
 lib/libc/sys/t_ptrace_wait6:traceme_signalignored_crash_fpe
 lib/libc/sys/t_ptrace_wait6:traceme_signalmasked_crash_fpe
 lib/libc/sys/t_ptrace_wait6:traceme_vfork_crash_fpe
 lib/libc/sys/t_ptrace_wait6:traceme_vfork_signalignored_crash_fpe
 lib/libc/sys/t_ptrace_wait6:traceme_vfork_signalmasked_crash_fpe
 lib/libc/sys/t_ptrace_wait6:unrelated_tracer_sees_crash_fpe
 lib/libc/sys/t_ptrace_wait6:unrelated_tracer_sees_signalignored_crash_fpe
 lib/libc/sys/t_ptrace_wait6:unrelated_tracer_sees_signalmasked_crash_fpe
 lib/libc/sys/t_ptrace_wait:traceme_crash_fpe
 lib/libc/sys/t_ptrace_wait:traceme_signalignored_crash_fpe
 lib/libc/sys/t_ptrace_wait:traceme_signalmasked_crash_fpe
 lib/libc/sys/t_ptrace_wait:traceme_vfork_crash_fpe
 lib/libc/sys/t_ptrace_wait:traceme_vfork_signalignored_crash_fpe
 lib/libc/sys/t_ptrace_wait:traceme_vfork_signalmasked_crash_fpe
 lib/libc/sys/t_ptrace_waitid:traceme_crash_fpe
 lib/libc/sys/t_ptrace_waitid:traceme_signalignored_crash_fpe
 lib/libc/sys/t_ptrace_waitid:traceme_signalmasked_crash_fpe
 lib/libc/sys/t_ptrace_waitid:unrelated_tracer_sees_crash_fpe
 lib/libc/sys/t_ptrace_waitid:unrelated_tracer_sees_signalignored_crash_fpe
 lib/libc/sys/t_ptrace_waitid:unrelated_tracer_sees_signalmasked_crash_fpe
 lib/libc/sys/t_ptrace_waitpid:traceme_crash_fpe
 lib/libc/sys/t_ptrace_waitpid:traceme_signalignored_crash_fpe
 lib/libc/sys/t_ptrace_waitpid:traceme_signalmasked_crash_fpe
 lib/libc/sys/t_ptrace_waitpid:traceme_vfork_crash_fpe
 lib/libc/sys/t_ptrace_waitpid:traceme_vfork_signalignored_crash_fpe
 lib/libc/sys/t_ptrace_waitpid:traceme_vfork_signalmasked_crash_fpe
 lib/libc/sys/t_ptrace_waitpid:unrelated_tracer_sees_crash_fpe
 lib/libc/sys/t_ptrace_waitpid:unrelated_tracer_sees_signalignored_crash_fpe
 lib/libc/sys/t_ptrace_waitpid:unrelated_tracer_sees_signalmasked_crash_fpe

The above tests failed in each of the last 4 test runs, and passed in
at least 26 consecutive runs before that.

The following commits were made between the last successful test and
the failed test:

 2020.06.17.08.23.18 rin src/tests/lib/libc/sys/t_ptrace_wait.h,v 1.29
 2020.06.17.08.42.16 rin src/tests/lib/libc/sys/t_ptrace_signal_wait.h,v 1.2
 2020.06.17.08.42.16 rin src/tests/lib/libc/sys/t_ptrace_wait.h,v 1.30
 2020.06.17.09.11.13 msaitoh src/sys/dev/pci/ixgbe/ixgbe.c,v 1.231

Logs can be found at:

 
http://releng.NetBSD.org/b5reports/i386/commits-2020.06.html#2020.06.17.09.11.13

Re: Build error with MKDEBUG=yes

[Rin Okuyama]

On 2020/06/08 9:21, Paul Goyette wrote:

With MKDEBUG=yes I get

==  1 missing files in DESTDIR  
Files in flist but missing from DESTDIR.
File wasn't installed ?
--
./usr/libdata/debug/usr/tests/lib/libprop/t_basic.debug
  end of 1 missing files  ==
*** [checkflist] Error code 1


This is with sources updated on 2020-06-07 at 19:48:54 UTC


Should be fixed now.

rin

Re: build failure when optimizing

[Rin Okuyama]

On 2020/05/28 0:42, Tobias Nygren wrote> There is an -mno-sse2 flag on the 
command line and it conflicts with

your -mfpmath=sse flag. This COPTS setting comes from
src/libexec/ld.elf_so/Makefile. You can remove the flag but expect
random breakage, it is there for a reason. Probably the easiest fix is
to add something like CFLAGS:=${CFLAGS:N-msse*:N-mfpmath=sse} at the
bottom on the Makefile to undo your settings for this file only.


This is why:

http://cvsweb.netbsd.org/bsdweb.cgi/src/libexec/ld.elf_so/Makefile#rev1.105


Disable use of various X86 extensions since _rtld_bind_start doesn't
save the necessary registers.


Thanks,
rin

Re: NFS: panic with "locking against myself" for vp->v_interlock

[Rin Okuyama]

On 2020/04/17 6:29, Rin Okuyama wrote:

Panic occurred for my powerpc/ibm4xx:

[   1.000] NetBSD 9.99.56 (OBS266) #195: Fri Apr 17 05:33:35 JST 2020
[   1.000]  rin@latipes:/build/src/sys/arch/evbppc/compile/OBS266
...
[ 994.4196596] Mutex error: mutex_vector_enter,542: locking against myself


This seems fixed by nfs_node.c rev 1.126:
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/nfs/nfs_node.c#rev1.126

Uptime of my ibm4xx box now exceeds one day with heavy NFS I/O.

Thank you so much hannken@ for working on this!!

rin

Re: build failure in libz

[Rin Okuyama]

Hi,

# This problem had already been fixed. My previous message was
# stalled somehow and delivered after preceding ones...

On 2020/04/23 13:57, Michael van Elst wrote:

rokuyama...@gmail.com (Rin Okuyama) writes:


It seems that files in the following directories are rolled back to
rev 1.x after removing & re-adding to phil-wifi branch:



src/common/dist/zlib
src/crypto/external/bsd/heimdal
src/crypto/dist/ipsec-tools



For example for src/common/dist/zlib/inflate.h, 1.1 is checked out
whereas 1.1.1.2 should be.



The default branch information (which was the vendor branch for these
files) was removed and cvs would return the trunk version instead.

This is usually an admin operation, but it also happens when removing
a file and temporarily in a commit.


Thank you for your message. What a confusing feature! I could not
imagine such a behavior without your explanation...

rin

Re: build failure in libz

[Rin Okuyama]

Hi,

It seems that files in the following directories are rolled back to
rev 1.x after removing & re-adding to phil-wifi branch:

src/common/dist/zlib
src/crypto/external/bsd/heimdal
src/crypto/dist/ipsec-tools

For example for src/common/dist/zlib/inflate.h, 1.1 is checked out
whereas 1.1.1.2 should be.

I don't understand why commits to phil-wifi affected to -HEAD...

Thanks,
rin

On 2020/04/22 7:41, Thomas Klausner wrote:

Hi!

I'm running a userland from 2020-04-12/amd64 when NetBSD built fine for me.

When I try building NetBSD-current now, it fails in libz with:


#   compile  libz/infback.o
gcc -O2   -std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes 
-Wpointer-arith -Wno-sign-compare  -Wsystem-headers   -Wno-traditional   
-Wa,--fatal-warnings  -Wreturn-type -Wswitch -Wshadow -Wcast-qual 
-Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Werror   -fPIE 
-fstack-protector -Wstack-protector   --param ssp-buffer-size=1
-I/usr/src/common/dist/zlib  -D_FORTIFY_SOURCE=2 -c -
Wno-error=implicit-fallthrough   /usr/src/common/dist/zlib/infback.c -o 
infback.o
/usr/src/common/dist/zlib/infback.c: In function ‘inflateBackInit_’:
/usr/src/common/dist/zlib/infback.c:69:12: error: ‘struct inflate_state’ has no 
member named ‘wnext’; did you mean ‘next’?
  state->wnext = 0;
 ^
 next
/usr/src/common/dist/zlib/infback.c: In function ‘inflateBack’:
/usr/src/common/dist/zlib/infback.c:481:25: warning: this statement may fall 
through [-Wimplicit-fallthrough=]
  state->mode = LEN;
  ^
/usr/src/common/dist/zlib/infback.c:483:9: note: here
  case LEN:
  ^~~~
*** Error code 1


And

/usr/src/common/dist/zlib/inflate.c: In function 'inflateMark':
/usr/src/common/dist/zlib/inflate.c:1559:47: error: 'struct inflate_state' has 
no member named 'back'
  return (long)(((unsigned long)((long)state->back)) << 16) +
^~
/usr/src/common/dist/zlib/inflate.c:1561:44: error: 'struct inflate_state' has 
no member named 'was'; did you mean 'last'?
  (state->mode == MATCH ? state->was - state->length : 0));
 ^~~
 last

I don't see a mail about this from the build bots, and I don't see any
relevant changes between April 12 and today (about an hour ago) that'd
explain it.

Any ideas?
  Thomas

Re: build failure in libz

[Rin Okuyama]

On 2020/04/22 16:01, Martin Husemann wrote:

On Wed, Apr 22, 2020 at 03:48:30PM +0900, Rin Okuyama wrote:

I don't understand why commits to phil-wifi affected to -HEAD...



ARGH - I hate cvs.

Will fix...


Seems fixed now. Thank you!

rin

NFS: panic with "locking against myself" for vp->v_interlock

[Rin Okuyama]

Hi,

Panic occurred for my powerpc/ibm4xx:

[   1.000] NetBSD 9.99.56 (OBS266) #195: Fri Apr 17 05:33:35 JST 2020
[   1.000]  rin@latipes:/build/src/sys/arch/evbppc/compile/OBS266
...
[ 994.4196596] Mutex error: mutex_vector_enter,542: locking against myself

[ 994.4196596] lock address : 0x07f8aee8
[ 994.4196596] current cpu  :  0
[ 994.4196596] current lwp  : 0x07e5ed80
[ 994.4196596] owner field  : 0x07e5ed80 wait/spin:0/0

[ 994.4196596] panic: lock error: Mutex: mutex_vector_enter,542: locking 
against myself: lock 0x7f8aee8 cpu 0 lwp 0x7e5ed80
[ 994.4196596] cpu0: Begin traceback...
[ 994.4196596] 0x0070bbe0: at vpanic+0x130
[ 994.4196596] 0x0070bc10: at panic+0x50
[ 994.4196596] 0x0070bc50: at lockdebug_abort+0xe4
[ 995.0399050] 0x0070bc70: at mutex_spin_enter+0x208
[ 995.0399050] 0x0070bcb0: at genfs_do_putpages+0x1d4
[ 995.0399050] 0x0070be00: at VOP_PUTPAGES+0x44
[ 995.0399050] 0x0070be30: at nfs_delayedtruncate+0x68
[ 995.0399050] 0x0070be40: at nfs_unlock+0x24
[ 995.0399050] 0x0070be50: at VOP_UNLOCK+0x3c
[ 995.0399050] 0x0070be70: at vrelel+0x36c
[ 995.4298209] 0x0070bea0: at nfs_sync+0xa0
[ 995.4796968] 0x0070bed0: at sched_sync+0x11c
[ 995.4796968] 0x0070bf20: at cpu_lwp_bootstrap+0xc
[ 995.5797291] 0x0070bfe8: at 0xfffc
[ 995.5797291] cpu0: End traceback...
Stopped in pid 0.37 (system) at netbsd:vpanic+0x134:or  r3, r29, r29
db>

Whereas vp->v_interlock is asserted in nfs_sync() via nfs_sync_selector(),
nfs_unlock() tries to obtain it again via nfs_delayedtruncate() -->
genfs_do_putpages().

Thanks,
rin

Re: Xen kernel diagnostic assertion "powerof2(align)" failed

[Rin Okuyama]

On 2019/11/05 4:10, Manuel Bouyer wrote:

On Sun, Nov 03, 2019 at 11:07:48AM +0200, Andreas Gustafsson wrote:

Manuel Bouyer wrote:

Hello,
the xen test run for the 201911010850Z build fails with:
[   1.1185040] panic: kernel diagnostic assertion "powerof2(align)" failed: file 
"/usr/src/sys/uvm/uvm_map.c", line 196

[...]

Has it been fixed since then ?


Yes, by:

   commit 2019.11.01.13.04.22 rin src/sys/uvm/uvm_map.c 1.366


thanks, I confirm it's fixed



I was relieved to hear that. Sorry for breakage.

Thanks,
rin

Re: How to best build a smalle libcurses for tiny crunched installers?

[Rin Okuyama]

Also, we have USE_WIDECHAR make(1) macro. If widechar support is
dropped, nvi does not require its built-in regex. This may help
your work :-).

external/nvi/usr.bin/nvi/Makefile:
 5  USE_WIDECHAR?=yes
...
58  # For wide char support
59  .if ${USE_WIDECHAR} == "yes"
60  SRCS+=  regcomp.c regerror.c regexec.c regfree.c
61  CPPFLAGS+=-I${DIST}/regex -D__REGEX_PRIVATE -DUSE_WIDECHAR
62  .endif

Thanks,
rin

On 2019/07/27 23:12, Martin Husemann wrote:

On Sat, Jul 27, 2019 at 04:03:17PM +0200, Martin Husemann wrote:

Sun3 still fails as we need a non-WCHAR version of nvi for that.
Any takers? Interestingly only a single missing symbol:

src/external/bsd/nvi/dist/cl/cl_funcs.c:65: undefined reference to `waddnwstr'


... and that already was #ifdef USE_WIDECHAR - yay!

Martin

Re: Automated report: NetBSD-current/i386 test failure

[Rin Okuyama]

On 2019/04/07 1:00, Andreas Gustafsson wrote:

Christos Zoulas wrote:

Must be, but I can't reproduce it, can you run gdb on the core file?


No need to go hunting or a core, simply running "date" with no
arguments will reproduce it.  Doing that under gdb shows:

   (gdb) where
   #0  0xac643b67 in ?? () from /lib/libc.so.12
   #1  0xac644496 in strftime_lz () from /lib/libc.so.12
   #2  0xac6444f2 in strftime_z () from /lib/libc.so.12
   #3  0xac64454b in strftime () from /lib/libc.so.12
   #4  0x00846af8 in main ()

I'll get you a backtrace with debug symbols later.


Hi,

Segmentation fault occurs depending on /etc/localtime:

% sudo ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
% date
Sun Apr  7 21:19:05 JST 2019
% sudo ln -sf /usr/share/zoneinfo/UTC /etc/localtime
% date
zsh: segmentation fault (core dumped)  date

Also, it does not take place if strftime.c,v 1.43 is reverted
(regardless of whether v 1.44 is applied or not).

Backtrace is attached below.

Thanks,
rin
---
% gdb date date.core
GNU gdb (GDB) 8.0.1
...
[New process 1]
Core was generated by `date'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x6fe6496ba120 in _add (ptlim=0x6fe64a0d1400 "",
pt=0x6fe64a0d1015 '\245' ...,
str=0x1 )
at /build/src/lib/libc/time/strftime.c:740
740 /build/src/lib/libc/time/strftime.c: No such file or directory.
(gdb) bt
#0  0x6fe6496ba120 in _add (ptlim=0x6fe64a0d1400 "",
pt=0x6fe64a0d1015 '\245' ...,
str=0x1 )
at /build/src/lib/libc/time/strftime.c:740
#1  _fmt (sp=, format=0x1a2c0276f "Z %Y",
format@entry=0x1a2c0275b "+%a %b %e %H:%M:%S %Z %Y",
t=t@entry=0x6fe649a0f460, pt=0x6fe64a0d1015 '\245' ...,
pt@entry=0x6fe64a0d1000 "+Sun Apr  7 12:19:13 ", '\245' ..., 
ptlim=ptlim@entry=0x6fe64a0d1400 "", warnp=warnp@entry=0x7f7fff48f4cc,
loc=) at /build/src/lib/libc/time/strftime.c:548
#2  0x6fe6496baa1a in _strftime_lz (sp=,
s=s@entry=0x6fe64a0d1000 "+Sun Apr  7 12:19:13 ", '\245' ..., maxsize=maxsize@entry=1024,
format=format@entry=0x1a2c0275b "+%a %b %e %H:%M:%S %Z %Y",
t=t@entry=0x6fe649a0f460, loc=)
at /build/src/lib/libc/time/strftime.c:152
#3  0x6fe6496baa41 in _strftime_z (sp=,
s=s@entry=0x6fe64a0d1000 "+Sun Apr  7 12:19:13 ", '\245' ..., maxsize=maxsize@entry=1024,
format=format@entry=0x1a2c0275b "+%a %b %e %H:%M:%S %Z %Y",
t=t@entry=0x6fe649a0f460) at /build/src/lib/libc/time/strftime.c:132
#4  0x6fe6496baa84 in strftime (
s=0x6fe64a0d1000 "+Sun Apr  7 12:19:13 ", '\245' ...,
maxsize=1024, format=0x1a2c0275b "+%a %b %e %H:%M:%S %Z %Y",
t=0x6fe649a0f460) at /build/src/lib/libc/time/strftime.c:708
#5  0x0001a2c020a5 in main (argc=, argv=)
at /build/src/bin/date/date.c:157
(gdb) q
%

Re: Mesa update

[Rin Okuyama]

This is because Makefile didn't handle objdir correctly.
Should be fixed now.

Thanks,
rin

On 2019/04/06 22:42, Patrick Welche wrote:

On Sat, Apr 06, 2019 at 05:18:58AM +1100, matthew green wrote:

thanks for the original work and fixing this i386 thing!


If you would like to do an update build, you will likely have to remove
many directories in OBJDIR/external/mit/xorg/lib/*.
I didn't test this, sorry.


you may also have to blow away ./usr/X11R7 in the destdir.  i recall
hving a build problem related to headers not being updated.


I blew away /usr/obj completely, and just tried, on amd64, a

   sh build.sh -j32 -x -r release

so DESTDIR would have been empty too, and get (twice):

--- dependall ---
nbmake[7]: nbmake[7]: don't know how to make /usr/src/external/bsd/llvm/librt/li
bLLVMTransformsCoroutines/libLLVMTransformsCoroutines_pic.a. Stop
nbmake[7]: stopped in /usr/src/external/mit/xorg/lib/gallium


Cheers,

Patrick

Re: Cross-compile sparc64 on amd64 w/ MKCOMPAT=no fails

[Rin Okuyama]

Applied. Thank you for report!

rin

On 2019/03/24 2:56, K. Schreiner wrote:

Hi,

with current source as of an hour or so ago cross-compiling sparc64 on
amd64 w/ MKCOMPAT=no fails with:

checkflist ===> distrib/sets
==  1 missing files in DESTDIR  
Files in flist but missing from DESTDIR.
File wasn't installed ?
--
./usr/include/g++/bits/sparc
  end of 1 missing files  ==
--- checkflist ---
*** [checkflist] Error code 1
nbmake[1]: stopped in /u/NetBSD/src/distrib/sets
1 error
nbmake[1]: stopped in /u/NetBSD/src/distrib/sets
--- distribution ---
*** [distribution] Error code 2


After fixing src/distrib/sets/lists/comp/md.sparc64 all is well.

Index: distrib/sets/lists/comp/md.sparc64
===
RCS file: /cvsroot/src/distrib/sets/lists/comp/md.sparc64,v
retrieving revision 1.208
diff -u -r1.208 md.sparc64
--- distrib/sets/lists/comp/md.sparc64  17 Feb 2019 05:29:08 -  1.208
+++ distrib/sets/lists/comp/md.sparc64  23 Mar 2019 17:55:01 -
@@ -1,5 +1,4 @@
  # $NetBSD: md.sparc64,v 1.208 2019/02/17 05:29:08 mrg Exp $
-./usr/include/g++/bits/sparc   comp-c-include
  ./usr/include/g++/bits/sparc  comp-c-include  compat
  ./usr/include/g++/bits/sparc/c++config.h  comp-c-include  
gcc,compat
  ./usr/include/g++/bits/sparc64comp-c-include  
compat


Kurt

Re: Further jemalloc fallout

[Rin Okuyama]

On 2019/03/17 1:08, Chavdar Ivanov wrote:

Still doesn't work for me with


Puzzling...


(talking about doc/guide). And neither does emacs-git, I am getting:

   CCLD temacs.in
ld: warning: libfontconfig.so.2, needed by
/usr/pkgsrc/wip/emacs-git/work/.buildlink/lib/libpangocairo-1.0.so,
may conflict with libfontconfig.so.1
ld: warning: libfreetype.so.18, needed by
/usr/pkgsrc/wip/emacs-git/work/.buildlink/lib/libpangocairo-1.0.so,
may conflict with libfreetype.so.6
ld: warning: libfreetype.so.18, needed by
/usr/pkgsrc/wip/emacs-git/work/.buildlink/lib/libpangocairo-1.0.so,
may conflict with libfreetype.so.6
ld: warning: libfreetype.so.18, needed by
/usr/pkgsrc/wip/emacs-git/work/.buildlink/lib/libpangocairo-1.0.so,
may conflict with libfreetype.so.6
ld: /usr/pkgsrc/wip/emacs-git/work/.buildlink/lib/libgdk-3.so:
undefined reference to `epoxy_has_glx'
gmake[1]: *** [Makefile:634: temacs.in] Error 1
gmake[1]: Leaving directory '/usr/pkgsrc/wip/emacs-git/work/emacs/src'
gmake: *** [Makefile:423: src] Error 2
*** Error code 2

Stop.
make[1]: stopped in /usr/pkgsrc/wip/emacs-git


Ah, configure does not work well. I manually added "-lepoxy" here.

Thanks,
rin

Re: Further jemalloc fallout

[Rin Okuyama]

On 2019/03/16 22:00, Thomas Klausner wrote:

On Sat, Mar 16, 2019 at 09:48:51PM +0900, Rin Okuyama wrote:

I can build it on amd64 -current as of yesterday.


Works for me as well, as does emacs-git (thanks, Rin!). I gave up on
wm/notion and shells/zsh seems stable using its own malloc.
  Thomas



Thanks! shells/zsh works fine for me both on amd64 and aarch64.
Probably we can disable --enable-zsh-mem for next zsh update.

rin

Re: Further jemalloc fallout

[Rin Okuyama]

Hmm, strange. This is my environment:

NetBSD latipes 8.99.35 NetBSD 8.99.35 (AMD64) #0: Fri Mar 15 13:00:54 JST 2019  
rin@latipes:/build/src/sys/arch/amd64/compile/AMD64 amd64

13:00 JST = 4:00 GMT here.

Thanks,
rin

On 2019/03/16 21:57, Chavdar Ivanov wrote:

Yes, I have no trace of 'notyet' in jemalloc.c .
...

cvs diff -r 1.6 -r 1.7 jemalloc.c

Index: jemalloc.c
===
RCS file: /cvsroot/src/external/bsd/jemalloc/dist/src/jemalloc.c,v
retrieving revision 1.6
retrieving revision 1.7
diff -r1.6 -r1.7
2342,2346c2342
< #ifdef notyet
<   /*
<* sshd depends on realloc(p, 0) returning non-NULL
<* disable for compatibility for now
<*/
---



2349d2344
< #endif


uname -a

NetBSD ymir 8.99.35 NetBSD 8.99.35 (GENERIC) #5: Fri Mar 15 00:10:32
GMT 2019  
sysbuild@ymir:/home/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC
amd64

I'll rebuild once more just in case.

On Sat, 16 Mar 2019 at 12:48, Rin Okuyama  wrote:


Hi,

I can build it on amd64 -current as of yesterday.

Are you sure this fix is applied?
http://cvsweb.netbsd.org/bsdweb.cgi/src/external/bsd/jemalloc/dist/src/jemalloc.c#rev1.7

Thanks,
rin

On 2019/03/16 20:55, Chavdar Ivanov wrote:

On yesterdays amd64 -current and fully updated pkgsrc, trying to build
doc/guide I get:
..
Writing HTML.manifest
-> Building ascii output
[Checking tools for typesetting...OK]
/usr/bin/sed -e 's/[01];/"/g' pkgsrc.html > pkgsrc.tmp.html
/usr/pkg/bin/w3m -dump -O iso-8859-1 -no-graph  pkgsrc.tmp.html |
/usr/bin/sed -e 's/[^[:print:]]/ /g' > pkgsrc.txt
-> Building pdf output
[Checking tools for typesetting...OK]
env SP_ENCODING=iso-8859-1  SGML_CATALOG_FILES= openjade -d
/usr/pkgsrc/doc/guide/work/pkgsrc-guide-20190316/share/default.dsl -c
/usr/pkgsrc/doc/guide/work/pkgsrc-guide-20190316/share/catalog -c
/usr/pkgsrc/doc/guide/work/pkgsrc-guide-20190316/../htdocs/share/xml/catalog
-c /usr/pkg/share/sgml/catalog -c
/usr/pkg/share/sgml/docbook/dsssl/modular/catalog -c
/usr/pkg/share/sgml/docbook/4.5/catalog -i sgml.includes  -V
%generate-article-toc% -t tex  -i output.print -i output.print.tex -i
output.print.niceheaders -o pkgsrc.tex
/usr/pkg/share/sgml/docbook/dsssl/modular/dtds/decls/xml.dcl
pkgsrc.xml
: 
/home/sysbuild/src/external/bsd/jemalloc/lib/../dist/src/arena.c:271:
Failed assertion: "bitmap_get(slab_data->bitmap,
_info->bitmap_info, regind)"
*** Signal 6

Stop.
make: stopped in /usr/pkgsrc/doc/guide/work/pkgsrc-guide-20190316
*** Error code 1

Stop.
make[1]: stopped in /usr/pkgsrc/doc/guide
*** Error code 1
...

Re: Further jemalloc fallout

[Rin Okuyama]

Hi,

I can build it on amd64 -current as of yesterday.

Are you sure this fix is applied?
http://cvsweb.netbsd.org/bsdweb.cgi/src/external/bsd/jemalloc/dist/src/jemalloc.c#rev1.7

Thanks,
rin

On 2019/03/16 20:55, Chavdar Ivanov wrote:

On yesterdays amd64 -current and fully updated pkgsrc, trying to build
doc/guide I get:
..
Writing HTML.manifest
-> Building ascii output
[Checking tools for typesetting...OK]
/usr/bin/sed -e 's/[01];/"/g' pkgsrc.html > pkgsrc.tmp.html
/usr/pkg/bin/w3m -dump -O iso-8859-1 -no-graph  pkgsrc.tmp.html |
/usr/bin/sed -e 's/[^[:print:]]/ /g' > pkgsrc.txt
-> Building pdf output
[Checking tools for typesetting...OK]
env SP_ENCODING=iso-8859-1  SGML_CATALOG_FILES= openjade -d
/usr/pkgsrc/doc/guide/work/pkgsrc-guide-20190316/share/default.dsl -c
/usr/pkgsrc/doc/guide/work/pkgsrc-guide-20190316/share/catalog -c
/usr/pkgsrc/doc/guide/work/pkgsrc-guide-20190316/../htdocs/share/xml/catalog
-c /usr/pkg/share/sgml/catalog -c
/usr/pkg/share/sgml/docbook/dsssl/modular/catalog -c
/usr/pkg/share/sgml/docbook/4.5/catalog -i sgml.includes  -V
%generate-article-toc% -t tex  -i output.print -i output.print.tex -i
output.print.niceheaders -o pkgsrc.tex
/usr/pkg/share/sgml/docbook/dsssl/modular/dtds/decls/xml.dcl
pkgsrc.xml
: 
/home/sysbuild/src/external/bsd/jemalloc/lib/../dist/src/arena.c:271:
Failed assertion: "bitmap_get(slab_data->bitmap,
_info->bitmap_info, regind)"
*** Signal 6

Stop.
make: stopped in /usr/pkgsrc/doc/guide/work/pkgsrc-guide-20190316
*** Error code 1

Stop.
make[1]: stopped in /usr/pkgsrc/doc/guide
*** Error code 1
...

Re: Panic on current on mac68k

[Rin Okuyama]

On 2019/02/25 18:02, Martin Husemann wrote:

On Sun, Feb 24, 2019 at 09:33:36PM +, John Klos wrote:

On a Quadra 605 which has been running netbsd-8 without issues for ages, it
seems -current isn't happy. I don't see any obvious recent changes which
might cause this. Ideas?


My Quadra runs 8.99.34 from Feb 18 just fine -
but that is with Rin's scsi patches. Rin, anything preventing you from
commiting that?


I was going to revive the patch according to input from tsutsui,
but it is stalled due to strange kernel crashes.

Martin, do you use GENERIC? GENERIC kernel with and without
the patch does not work on my Quadra 840AV. I observe what you
reported before:

https://mail-index.netbsd.org/tech-kern/2018/10/17/msg024139.html

Strangely enough, it crashes in other places and other ways,
depending on source date, kernel config file, compiler versions,
and compile options: illegal instruction, FPU trap, or MMU fault.

And crashes do not occur for some combinations.

I tried to narrow the problem down by dropping lines from GENERIC,
but the behavior changed randomly. I also tried to bisect it, but
I cannot yet :-(.

Even for netbsd-8, kernel can crash if config file is modified from
GENERIC.

I have not observed such crashes on my amiga with 68060. I wonder
whether other ports with 68040 works or not.

Thanks,
rin

Re: Automated report: NetBSD-current/i386 build failure

[Rin Okuyama]

Sorry I forgot to commit a file outside sys/module.
Should be fixed now.

Thanks,
rin

On 2019/02/17 15:15, NetBSD Test Fixture wrote:

This is an automatically generated notice of a NetBSD-current/i386
build failure.

The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2019.02.17.04.19.39.

An extract from the build.sh output follows:

 rip_call < sce->sce_user_end) ||
  ^
 
/tmp/bracket/build/2019.02.17.04.19.39-i386/src/sys/arch/usermode/modules/syscallemu/syscallemu_x86.c:67:33:
 error: comparison between signed and unsigned integer expressions 
[-Werror=sign-compare]
(rip_call + frame->tf_err >= sce->sce_user_start &&
  ^~
 
/tmp/bracket/build/2019.02.17.04.19.39-i386/src/sys/arch/usermode/modules/syscallemu/syscallemu_x86.c:68:33:
 error: comparison between signed and unsigned integer expressions 
[-Werror=sign-compare]
 rip_call + frame->tf_err < sce->sce_user_end)) {
  ^
 --- dependall-solaris ---
 --- xdr.d ---
 #create  solaris/xdr.d
 
CC=/tmp/bracket/build/2019.02.17.04.19.39-i386/tools/bin/i486--netbsdelf-gcc 
/tmp/bracket/build/2019.02.17.04.19.39-i386/tools/bin/nbmkdep -f xdr.d.tmp  --  
 -std=gnu99   -I/tmp/bracket/build/2019.02.17.04.19.39-i386/src/common/include 
-DDIAGNOSTIC --sysroot=/tmp/bracket/build/2019.02.17.04.19.39-i386/destdir 
-I/tmp/bracket/build/2019.02.17.04.19.39-i386/src/sys/../external/cddl/osnet/sys
 
-I/tmp/bracket/build/2019.02.17.04.19.39-i386/src/sys/../external/cddl/osnet/dist/common/acl
 
-I/tmp/bracket/build/2019.02.17.04.19.39-i386/src/sys/../external/cddl/osnet/dist/common
 
-I/tmp/bracket/build/2019.02.17.04.19.39-i386/src/sys/../external/cddl/osnet/dist/uts/common/zmod
 
-I/tmp/bracket/build/2019.02.17.04.19.39-i386/src/sys/../external/cddl/osnet/dist/uts/common
 
-I/tmp/bracket/build/2019.02.17.04.19.39-i386/src/sys/../external/cddl/osnet/sys/sys
 -I/tmp/bracket/build/2019.02.17.04.19.39-i386/src/common/include -DDIAGNOSTIC 
-nostdinc -I. -I/tmp/bracket/build/2019.02.17.04.19.39-i386/src/sy
  s/modules/solaris -isystem /tmp/bracket/build/2019.02.17.04.19.39-i386/src/sys 
-isystem /tmp/bracket/build/2019.02.17.04.19.39-i386/src/sys/arch -isystem 
/tmp/bracket/build/2019.02.17.04.19.39-i386/src/sys/../common/include -D_KERNEL -D_LKM 
-D_MODULE -DSYSCTL_INCLUDE_DESCR 
/tmp/bracket/build/2019.02.17.04.19.39-i386/src/sys/../external/cddl/osnet/dist/uts/common/rpc/xdr.c
 &&  mv -f xdr.d.tmp xdr.d
 --- dependall-dm ---
 /tmp/bracket/build/2019.02.17.04.19.39-i386/tools/bin/nbctfconvert -L 
VERSION dm_ioctl.o
 --- dependall-../arch/usermode/modules/syscallemu ---
 cc1: all warnings being treated as errors
 *** [syscallemu_x86.o] Error code 1
 nbmake[8]: stopped in 
/tmp/bracket/build/2019.02.17.04.19.39-i386/src/sys/arch/usermode/modules/syscallemu
 1 error

The following commits were made between the last successful build and
the failed build:

 2019.02.17.03.57.31 rin src/sys/modules/Makefile.inc,v 1.7
 2019.02.17.04.05.41 rin src/sys/modules/Makefile.inc,v 1.8
 2019.02.17.04.05.41 rin src/sys/modules/accf_httpready/Makefile,v 1.3
 2019.02.17.04.05.41 rin src/sys/modules/acpiacad/Makefile,v 1.4
 2019.02.17.04.05.41 rin src/sys/modules/acpibat/Makefile,v 1.5
 2019.02.17.04.05.41 rin src/sys/modules/acpibut/Makefile,v 1.4
 2019.02.17.04.05.41 rin src/sys/modules/acpicpu/Makefile,v 1.7
 2019.02.17.04.05.41 rin src/sys/modules/acpidalb/Makefile,v 1.3
 2019.02.17.04.05.41 rin src/sys/modules/acpifan/Makefile,v 1.3
 2019.02.17.04.05.42 rin src/sys/modules/acpilid/Makefile,v 1.4
 2019.02.17.04.05.42 rin src/sys/modules/acpipmtr/Makefile,v 1.3
 2019.02.17.04.05.42 rin src/sys/modules/acpitz/Makefile,v 1.4
 2019.02.17.04.05.42 rin src/sys/modules/acpiverbose/Makefile,v 1.5
 2019.02.17.04.05.42 rin src/sys/modules/acpivga/Makefile,v 1.3
 2019.02.17.04.05.42 rin src/sys/modules/acpiwdrt/Makefile,v 1.2
 2019.02.17.04.05.42 rin src/sys/modules/acpiwmi/Makefile,v 1.4
 2019.02.17.04.05.42 rin src/sys/modules/adosfs/Makefile,v 1.2
 2019.02.17.04.05.42 rin src/sys/modules/aibs/Makefile,v 1.5
 2019.02.17.04.05.42 rin src/sys/modules/aio/Makefile,v 1.2
 2019.02.17.04.05.42 rin src/sys/modules/amdsmn/Makefile,v 1.2
 2019.02.17.04.05.43 rin src/sys/modules/amdtemp/Makefile,v 1.2
 2019.02.17.04.05.43 rin src/sys/modules/amdzentemp/Makefile,v 1.2
 2019.02.17.04.05.43 rin src/sys/modules/apple_smc/Makefile,v 1.3
 2019.02.17.04.05.43 rin src/sys/modules/apple_smc_acpi/Makefile,v 1.2
 2019.02.17.04.05.43 rin src/sys/modules/apple_smc_fan/Makefile,v 1.2
 2019.02.17.04.05.43 rin src/sys/modules/apple_smc_temp/Makefile,v 1.2
 2019.02.17.04.05.43 rin src/sys/modules/asus/Makefile,v 1.3
 2019.02.17.04.05.43 rin src/sys/modules/ati_pcigart/Makefile,v 1.2
 

Re: compiling if_mue.c fails

[Rin Okuyama]

Hi,

Should be fixed now. Sorry for breakage.

Thanks,
rin

On 2019/02/07 6:35, K. Schreiner wrote:

Hi,

with source cvs-updated an hour or so ago build.sh release for
evbearmv7hf-el fails:


/u/NetBSD/src/sys/dev/usb/if_mue.c: In function 'mue_miibus_statchg':
/u/NetBSD/src/sys/dev/usb/if_mue.c:69:2: error: 'sc' may be used uninitialized 
in this function [-Werror=maybe-uninitialized]
 device_printf((sc)->mue_dev, "%s: " fmt, __func__, ##args);
 ^
/u/NetBSD/src/sys/dev/usb/if_mue.c:362:20: note: 'sc' was declared here
 struct mue_softc *sc;
   ^~

cc1: all warnings being treated as errors
--- if_mue.o ---
*** [if_mue.o] Error code 1
nbmake[2]: stopped in 
/u/NetBSD/arch/evbearmv7hf-el/obj/sys/arch/evbarm/compile/BEAGLEBONE


Kurt

Re: netipsec/keysock.h: No such file or directory

[Rin Okuyama]

Hi,

On 2018/09/26 19:41, Robert Swindells wrote:


Andreas Gustafsson  wrote:

Some architectures (sparc, pmax, maybe others) are failing to build as
of source date 2018.09.25.22.23.22, with the error message

src/usr.bin/netstat/pfkey.c:79:30: fatal error: netipsec/keysock.h: No
such file or directory


Looks like it got incorrectly marked as obsolete when the ISDN code was
removed.



Fixed. Thank you for your report!

rin

Re: module(7) vs KERN_AS (Re: HEADS-UP: Recent atari install floppy overflow)

[Rin Okuyama]

On 2018/09/19 15:57, Rin Okuyama wrote:

Hi,

Currently, KERN_AS is set in Makefile.arch. However, it should be
determined on whether module(7) is enabled or not, for *all* ports,
something like

   OPT_MODULAR=    %MODULAR%
   .if !empty(OPT_MODULAR)
   KERN_AS=    obj
   .else
   KERN_AS=    library
   .endif

Therefore, it is not a good idea to have the common segment of
codes above in all Makefile.arch. We would have three options:

(1) use sys/conf/Makefile.conf

(2) add %MODULAR directive and emitmodular() function in config(1)

(3) set OPT_MODULAR in Makefile.arch, and change a default value for
KERN_AS depending on its value in sys/lib/libkern/Makefile.inc

(1) does not work since %MODULAR% is not expanded if it is in
sys/conf/Makefile.conf. And (2) seems too much for me. Therefore,
I propose (3) as a compromise. Please find the attached patch (MD
part is only for amd64 as an example).


Committed:
http://mail-index.netbsd.org/source-changes/2018/09/22/msg099343.html

Thanks,
rin

Re: small sysinst(8) without extended partitioning support

[Rin Okuyama]

On 2018/09/21 1:00, Christos Zoulas wrote:

On Sep 20,  9:32pm, rokuy...@rk.phys.keio.ac.jp (Rin Okuyama) wrote:

...

| Thanks, committed! How about this?
| http://mail-index.netbsd.org/port-atari/2018/09/19/msg000586.html

Instead of the nested if, perhaps would use ?= in the two KERN_AS assignments
(less code), otherwise I am all for centralizing it.


Thank you for your thorough check and comment. I'll commit it in
the weekend.

rin

Re: small sysinst(8) without extended partitioning support

[Rin Okuyama]

On 2018/09/20 22:29, Martin Husemann wrote:

On Thu, Sep 20, 2018 at 10:23:00PM +0900, Rin Okuyama wrote:

On 2018/09/20 22:17, Martin Husemann wrote:

On Thu, Sep 20, 2018 at 10:16:49PM +0900, Rin Okuyama wrote:

Oops, sorry, I will revert it for now, and rework after your
changes are committed.


No, please don't revert it - I'll deal with the merge.


I see. Let me apologize again for disturbing your work...


No need, your work is very welcome!


Thanks. From now on, I will take more time b/w announcement and
commitment of large diffs.

rin

Re: small sysinst(8) without extended partitioning support

[Rin Okuyama]

On 2018/09/20 22:17, Martin Husemann wrote:

On Thu, Sep 20, 2018 at 10:16:49PM +0900, Rin Okuyama wrote:

Oops, sorry, I will revert it for now, and rework after your
changes are committed.


No, please don't revert it - I'll deal with the merge.


I see. Let me apologize again for disturbing your work...

rin

Re: small sysinst(8) without extended partitioning support

[Rin Okuyama]

On 2018/09/20 22:11, Martin Husemann wrote:

On Thu, Sep 20, 2018 at 09:32:21PM +0900, Rin Okuyama wrote:


I've confirmed sysinst(8) with and without this option works on amd64.


Go for it.


Thanks, committed! How about this?


Can you please give a bit more time before such changes?
I am working on huge diffs to sysinst and this is a nightmare of a merge.


Oops, sorry, I will revert it for now, and rework after your
changes are committed.

rin

Re: small sysinst(8) without extended partitioning support

[Rin Okuyama]

On 2018/09/20 20:47, Christos Zoulas wrote:

In article <7a30a32c-4224-54c3-a3cf-0587b1b9f...@rk.phys.keio.ac.jp>,
Rin Okuyama   wrote:

-=-=-=-=-=-

Hi,

Although the recent floppy overflow for atari was gone, I expected
that it surely occurs again in the near future.

I propose to add NOPARTMAN option to sysinst(8), which drops extended
partitioning support provided by partman.c. If this option is enabled,
about 30KB is reduced for crunched binary for atari install floppy.
It should be useful also for old ports with sysinst(8).

It requires

- separate extended partitioning stuffs from menu.mi to menu.pm
- 8 extra #if(n)def's

I've confirmed sysinst(8) with and without this option works on amd64.


Go for it.


Thanks, committed! How about this?
http://mail-index.netbsd.org/port-atari/2018/09/19/msg000586.html

rin

small sysinst(8) without extended partitioning support

[Rin Okuyama]

Hi,

Although the recent floppy overflow for atari was gone, I expected
that it surely occurs again in the near future.

I propose to add NOPARTMAN option to sysinst(8), which drops extended
partitioning support provided by partman.c. If this option is enabled,
about 30KB is reduced for crunched binary for atari install floppy.
It should be useful also for old ports with sysinst(8).

It requires

- separate extended partitioning stuffs from menu.mi to menu.pm
- 8 extra #if(n)def's

I've confirmed sysinst(8) with and without this option works on amd64.

Any suggestions?

Thanks,
rin
Index: usr.sbin/sysinst/Makefile.inc
===
RCS file: /home/netbsd/src/usr.sbin/sysinst/Makefile.inc,v
retrieving revision 1.12
diff -p -u -r1.12 Makefile.inc
--- usr.sbin/sysinst/Makefile.inc   16 Sep 2018 09:15:12 -  1.12
+++ usr.sbin/sysinst/Makefile.inc   20 Sep 2018 00:59:46 -
@@ -13,18 +13,22 @@ WARNS=  4
 
 SRCS+= menu_defs.c msg_defs.c main.c install.c upgrade.c \
txtwalk.c run.c factor.c net.c disks.c disks_lfs.c util.c geom.c \
-   label.c target.c md.c sizemultname.c configmenu.c checkrc.c partman.c
+   label.c target.c md.c sizemultname.c configmenu.c checkrc.c
 
 SRCS+= ${MD_OPTIONS:MAOUT2ELF:S/AOUT2ELF/aout2elf.c/}
 SRCS+= ${MENUS_MD:Mmenus.mbr:S/menus.mbr/mbr.c/}
 SRCS+= ${CPPFLAGS:M-DWSKBD:S/-DWSKBD/wskbd.c/}
 SRCS+= ${NODISKLABEL:D:Ubsddisklabel.c savenewlabel.c}
+SRCS+= ${NOPARTMAN:D:Upartman.c}
 
 DPSRCS+= defs.h
 
 SYSINSTLANG?=  en
 LANGUAGES?=de en es fr pl
 
+MENUS_MI=  menus.mi
+MENUS_MI+= ${NOPARTMAN:D:Umenus.pm}
+
 MSG_MD?=   msg.md.${SYSINSTLANG}
 MENUS_MD?= menus.md.${SYSINSTLANG}
 
@@ -48,7 +52,8 @@ CATALOGDIR=   /usr/share/sysinst/catalog
 CPPFLAGS+= -I. -I${.CURDIR}/../.. -I${.CURDIR} \
-DREL=\"${DISTRIBVER}\" -DMACH=\"${MACHINE}\" \
-DMACH_${MACHINE} -DARCH_${MACHINE_ARCH} \
-   ${NODISKLABEL:D-DNO_DISKLABEL}
+   ${NODISKLABEL:D-DNO_DISKLABEL} \
+   ${NOPARTMAN:D-DNO_PARTMAN}
 
 .if defined(NETBSD_OFFICIAL_RELEASE) && ${NETBSD_OFFICIAL_RELEASE} == "yes"
 CPPFLAGS+= -DSYSINST_FTP_HOST=\"ftp.NetBSD.org\" -DNETBSD_OFFICIAL_RELEASE
@@ -168,7 +173,7 @@ msg.def: msg.mi.${SYSINSTLANG} ${MSG_MD}
${TOOL_SED} "s/@@MACHINE@@/${MACHINE}/" | \
${TOOL_AWK} -f ${UNIF_AWK} -v defines="${MD_OPTIONS}" > ${.TARGET}
 
-menus.def: menus.mi ${MENUS_MD} msgtouch
+menus.def: ${MENUS_MI} ${MENUS_MD} msgtouch
${_MKTARGET_CREATE}
${TOOL_SED} "s/@@VERSION@@/${DISTRIBVER}/" ${.ALLSRC} | \
${TOOL_SED} "s/@@MACHINE@@/${MACHINE}/" | \
Index: usr.sbin/sysinst/defs.h
===
RCS file: /home/netbsd/src/usr.sbin/sysinst/defs.h,v
retrieving revision 1.18
diff -p -u -r1.18 defs.h
--- usr.sbin/sysinst/defs.h 16 Sep 2018 09:15:12 -  1.18
+++ usr.sbin/sysinst/defs.h 20 Sep 2018 08:39:49 -
@@ -613,9 +613,16 @@ void   unwind_mounts(void);
 inttarget_mounted(void);
 
 /* from partman.c */
+#ifndef NO_PARTMAN
 int partman(void);
-int pm_partusage(pm_devs_t *, int, int);
 int pm_getrefdev(pm_devs_t *);
+void update_wedges(const char *);
+#else
+static inline int partman(void) { return -1; }
+static inline int pm_getrefdev(pm_devs_t *x __unused) { return -1; }
+#define update_wedges(x) __nothing
+#endif
+int pm_partusage(pm_devs_t *, int, int);
 void pm_setfstype(pm_devs_t *, int, int);
 int pm_editpart(int);
 void pm_rename(pm_devs_t *);
@@ -626,13 +633,16 @@ int pm_cgd_edit(void *, part_entry_t *);
 int pm_gpt_convert(pm_devs_t *);
 void pm_wedges_fill(pm_devs_t *);
 void pm_make_bsd_partitions(pm_devs_t *);
-void update_wedges(const char *);
 
 /* flags whether to offer the respective options (depending on helper
programs available on install media */
 int have_raid, have_vnd, have_cgd, have_lvm, have_gpt, have_dk;
 /* initialize above variables */
+#ifndef NO_PARTMAN
 void check_available_binaries(void);
+#else
+#define check_available_binaries() __nothing
+#endif
 
 /* from bsddisklabel.c */
 intmake_bsd_partitions(void);
Index: usr.sbin/sysinst/install.c
===
RCS file: /home/netbsd/src/usr.sbin/sysinst/install.c,v
retrieving revision 1.4
diff -p -u -r1.4 install.c
--- usr.sbin/sysinst/install.c  10 May 2015 10:14:02 -  1.4
+++ usr.sbin/sysinst/install.c  20 Sep 2018 00:42:05 -
@@ -47,7 +47,11 @@ do_install(void)
 {
int find_disks_ret;
int retcode = 0;
+#ifndef NO_PARTMAN
partman_go = -1;
+#else
+   partman_go = 0;
+#endif
 
 #ifndef DEBUG
msg_display(MSG_installusure);
Index: usr.sbin/sysinst/main.c
===
RCS file: /home/netbsd/src/usr.sbin/sysinst/main.c,v
retrieving revision 1.9
diff -p -u -r1.9 main.c
--- usr.sbin/sysinst/main.c 

Re: module(7) vs KERN_AS (Re: HEADS-UP: Recent atari install floppy overflow)

[Rin Okuyama]

I found that we already have a similar code in
sys/compat/common/Makefile.inc:

https://nxr.netbsd.org/xref/src/sys/compat/common/Makefile.inc#17

17
18  # Default values:
19  COMPATDST?= ${.OBJDIR}/lib/compat
20  .if !empty(OPT_MODULAR)
21  COMPAT_AS?= library
22  .else
23  COMPAT_AS?= obj
24  .endif
25  COMPATDOTDIR?= ../../.
26

On 2018/09/19 15:57, Rin Okuyama wrote:

Hi,

Currently, KERN_AS is set in Makefile.arch. However, it should be
determined on whether module(7) is enabled or not, for *all* ports,
something like

   OPT_MODULAR=    %MODULAR%
   .if !empty(OPT_MODULAR)
   KERN_AS=    obj
   .else
   KERN_AS=    library
   .endif

Therefore, it is not a good idea to have the common segment of
codes above in all Makefile.arch. We would have three options:

(1) use sys/conf/Makefile.conf

(2) add %MODULAR directive and emitmodular() function in config(1)

(3) set OPT_MODULAR in Makefile.arch, and change a default value for
KERN_AS depending on its value in sys/lib/libkern/Makefile.inc

(1) does not work since %MODULAR% is not expanded if it is in
sys/conf/Makefile.conf. And (2) seems too much for me. Therefore,
I propose (3) as a compromise. Please find the attached patch (MD
part is only for amd64 as an example).

Thoughts?

Thanks,
rin

On 2018/09/18 21:52, m...@netbsd.org wrote:

I'd like to propose the following to remove dead code intended for
modules, which are not enabled.

module(7) vs KERN_AS (Re: HEADS-UP: Recent atari install floppy overflow)

[Rin Okuyama]

Hi,

Currently, KERN_AS is set in Makefile.arch. However, it should be
determined on whether module(7) is enabled or not, for *all* ports,
something like

  OPT_MODULAR=  %MODULAR%
  .if !empty(OPT_MODULAR)
  KERN_AS=  obj
  .else
  KERN_AS=  library
  .endif

Therefore, it is not a good idea to have the common segment of
codes above in all Makefile.arch. We would have three options:

(1) use sys/conf/Makefile.conf

(2) add %MODULAR directive and emitmodular() function in config(1)

(3) set OPT_MODULAR in Makefile.arch, and change a default value for
KERN_AS depending on its value in sys/lib/libkern/Makefile.inc

(1) does not work since %MODULAR% is not expanded if it is in
sys/conf/Makefile.conf. And (2) seems too much for me. Therefore,
I propose (3) as a compromise. Please find the attached patch (MD
part is only for amd64 as an example).

Thoughts?

Thanks,
rin

On 2018/09/18 21:52, m...@netbsd.org wrote:

I'd like to propose the following to remove dead code intended for
modules, which are not enabled.

Index: sys/conf/Makefile.kern.inc
===
RCS file: /home/netbsd/src/sys/conf/Makefile.kern.inc,v
retrieving revision 1.265
diff -p -u -r1.265 Makefile.kern.inc
--- sys/conf/Makefile.kern.inc  27 Aug 2018 05:35:22 -  1.265
+++ sys/conf/Makefile.kern.inc  19 Sep 2018 06:34:04 -
@@ -157,8 +157,8 @@ LINK_O?=@${_MKSHMSG} "   link  ${.CURDI
 ##
 ## (3) libkern and compat
 ##
-## Set KERN_AS in the port Makefile to "obj" or "library".  The
-## default is "library", as documented in $S/lib/libkern/Makefile.inc.
+## Set OPT_MODULAR in the port Makefile if module(7) should be enabled,
+## as documented in $S/lib/libkern/Makefile.inc.
 ##
 
 ### find out what to use for libkern
Index: sys/lib/libkern/Makefile.inc
===
RCS file: /home/netbsd/src/sys/lib/libkern/Makefile.inc,v
retrieving revision 1.45
diff -p -u -r1.45 Makefile.inc
--- sys/lib/libkern/Makefile.inc27 May 2018 01:14:50 -  1.45
+++ sys/lib/libkern/Makefile.inc19 Sep 2018 06:31:38 -
@@ -7,7 +7,8 @@
 #  objects are to be built.  Defaults to ${.OBJDIR}/lib/kern.
 #  KERN_AS may be set to 'obj' to build a object from the library's
 #  object files.  (Otherwise, a library will be built.)
-#  Defaults to 'library'.
+#  Defaults to 'obj' if OPT_MODULAR is set. Otherwise,
+#  'library' is used as a default value.
 #  KERNMISCCPPFLAGS
 #  Miscellaneous cpp flags to be passed to the library's Makefile
 #  when building.
@@ -18,7 +19,13 @@
 
 # Default values:
 KERNDST?=  ${.OBJDIR}/lib/kern
-KERN_AS?=  library
+.if !defined(KERN_AS)
+.if !empty(OPT_MODULAR)
+KERN_AS=   obj
+.else
+KERN_AS=   library
+.endif
+.endif
 KERNDOTDIR?= ../../.
 
 KERNDIR=   ${S:S@^.@${KERNDOTDIR}@:q}/lib/libkern
Index: sys/arch/amd64/conf/Makefile.amd64
===
RCS file: /home/netbsd/src/sys/arch/amd64/conf/Makefile.amd64,v
retrieving revision 1.73
diff -p -u -r1.73 Makefile.amd64
--- sys/arch/amd64/conf/Makefile.amd64  22 Aug 2018 12:07:42 -  1.73
+++ sys/arch/amd64/conf/Makefile.amd64  19 Sep 2018 06:22:20 -
@@ -63,11 +63,6 @@ CFLAGS+= ${KASANFLAGS.${.IMPSRC:T}:U${KA
 ## (3) libkern and compat
 ##
 OPT_MODULAR=   %MODULAR%
-.if !empty(OPT_MODULAR)
-KERN_AS=   obj
-.else
-KERN_AS=   library
-.endif
 
 ##
 ## (4) local objects, compile rules, and dependencies

Re: Error in vi (or in man page)

[Rin Okuyama]

On 2018/09/14 20:37, Christos Zoulas wrote:

In article ,
Rin Okuyama   wrote:

...

It would be better to fix our vi in accordance with POSIX. Thoughts?


I think it is better to keep the behavior (exit) and fix the man page.
vim exits too. It is usually the case that the user does not want to
edit the file with the same name!


Well, I agree that the current behavior is safer for users.
I fixed the manpage.

Thanks,
rin

Re: Error in vi (or in man page)

[Rin Okuyama]

Hi,

On 2018/09/14 8:49, Paul Goyette wrote:

Current vi(1) man page says

     -r Recover the specified files, or, if no files are specified,
    list the files that could be recovered.  If no recoverable
    files by the specified name exist, the file is edited as if
    the -r option had not been specified.

However, in actuality, if no recoverable files by the specified name
exist, vi simply reports that fact, and does nothing;  it does not
edit the file "as if the -r option had not been specified."

     #  ls kern_time_50.c
     kern_time_50.c
     # vi -r kern_time_50.c
     No files named kern_time_50.c, readable by you, to recover
     #


POSIX says
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ex.html


If the -r option was specified, ... If no recovery information
about a file is available, an informational message to this effect
shall be written, and the edit shall proceed as usual.


This seems consistent with our manpage.

On the other hand, /usr/ucb/vi from Solaris 11 (based on Bill Joy's vi)
behaves strangely; if no recovery information is present, it allocate
an empty buffer even if there's a file of the specified name!

It would be better to fix our vi in accordance with POSIX. Thoughts?

Thanks,
rin

Re: Driver for Raspberry Pi 3B+ ethernet adapter (Microchip LAN75xx/LAN78xx)

[Rin Okuyama]

On 2018/08/25 14:41, Martin Husemann wrote:

Great!

Please commit, we can improve it in-tree.


Thank you :-). I'll commit it after some off-list discussions finish.

On 2018/08/25 17:12, Jun Ebihara wrote:

I make kernel,and works well.
http://cdn.netbsd.org/pub/NetBSD/misc/jun/raspberry-pi/2018-08-25-earmv6hf/kernel7.img-RPI3

https://github.com/ebijun/NetBSD/commit/47cf0a2eaac3d2bb25caa9648fa85a18c54f1d41#diff-595f326ad183ce9b77c21d202a019821

many thanx!


Thank you for testing and making kernel image!

rin

Driver for Raspberry Pi 3B+ ethernet adapter (Microchip LAN75xx/LAN78xx)

[Rin Okuyama]

I've ported mue(4), driver for Microchip LAN75xx/LAN78xx known as
internal NIC of Raspberry Pi 3B+, from OpenBSD.

Here's source codes as well as patch for other parts of kernel:
  http://www.NetBSD.org/~rin/mue20180825

The driver has been tested on following devices:

- Raspberry Pi 3B+ (LAN7800)
- Z-TEK ZE582 (LAN7500) on both RPI3b+ and ThinkPad X60 (amd64)

dmesg and performance on RPI3b+ are as follows:

% dmesg
...
mue0 at uhub2 port 1
mue0: SMSC (0x424) LAN7800 USB 3.1 gigabit ethernet device (0x7800), rev 
2.10/3.00, addr 7
mue0: LAN7800
mue0: Ethernet address xx:xx:xx:xx:xx:xx
ukphy0 at mue0 phy 1: OUI 0x00800f, model 0x0013, rev. 2
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-FDX, auto
...
% scp somewhere:random.128m .
random.128m 100%  128MB  12.4MB/s  14.1MB/s   00:10
% scp random.128m somewhere:
random.128m 100%  128MB   9.1MB/s   9.3MB/s   00:14

Basically, the driver works fine. However, if the media type is set to
something other than 1000baseT-FDX, data transmission becomes quite
unstable. Also, ukphy(4) mistakenly recognize 1000baseT as a supported
media type, although the adapters do not support it. I suspect that
MII of the adapters has bugs...

I thank ryo@ for letting me know how to obtain MAC address from
bcmmbox(4).

I'd like to commit it in this weekend if there's no objection.

Thanks,
rin

Re: Automated report: NetBSD-current/i386 test failure

[Rin Okuyama]

On 2017/11/14 23:09, Martin Husemann wrote:

On Tue, Nov 14, 2017 at 01:58:54PM +, NetBSD Test Fixture wrote:

This is an automatically generated notice of new failures of the
NetBSD test suite.

The newly failing test cases are:


This was fallout fromt the gcc import, it should be fixed now.


All these tests are passed on amd64 built from -current as of few hours ago.

rin

Re: postfix 3.1.4 imported in current

[Rin Okuyama]

On 2017/02/19 4:49, Jaromír Doleček wrote:

2017-02-18 19:09 GMT+01:00 Joerg Sonnenberger :

On Sat, Feb 18, 2017 at 11:32:39AM -0500, Christos Zoulas wrote:

Sure, the first is easier. For the second we need icu in base
(http://site.icu-project.org/). We could discuss the second in tech-userlevel.


No ICU in base. Just no.


I share this sentiment, too.

Do we use the bind-bundled idnkit for our bind build? Possibly we can
reuse the same for the postfix code too, if it's good enough for bind
it should be good enough for postfix.

It would be a shame to have smptutf8 just disabled.


Hmm, at the first sight, postfix uses ICU for two purposes:

(1) ASCII/UTF-8 domain name conversion
(2) casefold UTF-8 text for caseless comparison

(1) can be replaced by idnkit if someone writes wrapper functions.
(2) seems to be lacking from idnkit. We probably can write stripped-
down version of that function, derived from ICU.

Anyhow, it needs some work to enable smptutf8...

Thanks,
rin

Re: postfix 3.1.4 imported in current

[Rin Okuyama]

On 2017/02/19 1:03, Rin Okuyama wrote:

Or should we import ucasemap.h to enable EAI support?


That is part of ICU:

  http://icu-project.org/apiref/icu4c/index.html

Why don't we turn off at the moment?

rin
===
--- src/external/ibm-public/postfix/dist/conf/main.cf.orig  2017-02-19 
01:19:46.090737614 +0900
+++ src/external/ibm-public/postfix/dist/conf/main.cf   2017-02-19 
01:21:02.019848210 +0900
@@ -684,3 +684,6 @@
 #
 readme_directory = /usr/share/examples/postfix
 #inet_protocols = ipv4
+
+# XXX: We do not support this on NetBSD at the moment.
+smtputf8_enable = no

Re: postfix 3.1.4 imported in current

[Rin Okuyama]

On 2017/02/14 10:22, Christos Zoulas wrote:

Please see:

http://www.postfix.org/COMPATIBILITY_README.html


When sending a mail, postfix complains:

  sendmail: warning: smtputf8_enable is true, but EAI support is not compiled in
  postdrop: warning: smtputf8_enable is true, but EAI support is not compiled in

Since postfix 3.0, smptutf8_enable = yes by default, which supports mail
addresses encoded by UTF8. However, we disable it at the moment:

src/external/ibm-public/postfix/Makefile.inc

 1  #   $NetBSD: Makefile.inc,v 1.18 2017/02/14 01:16:43 christos Exp $
..
12  CPPFLAGS+= -DNETBSD4 -DUSE_SASL_AUTH -DNO_EAI \
..

By removing -DNO_EAI, build fails with:

  src/external/ibm-public/postfix/dist/src/util/casefold.c:96:30: fatal error: 
unicode/ucasemap.h: No such file or directory
  compilation terminated.
  mkdep: compile failed.

Could I add "smtputf8_enable = no" to /etc/postfix/main.cf to appease
postfix? Or should we import ucasemap.h to enable EAI support?

Thanks,
rin

Re: INSTALL kernel exceeds 5MB for zaurus

[Rin Okuyama]

On 2017/02/09 2:54, Christos Zoulas wrote:

In article <55ee8f0c-691b-4dd3-b0e9-bdec4fb16...@rk.phys.keio.ac.jp>,
Rin Okuyama  <rokuy...@rk.phys.keio.ac.jp> wrote:

Build fails for zaurus because the INSTALL kernel exceeds 5MB:

  http://releng.netbsd.org/builds/HEAD/201702072140Z/

I've found that there is extra space in the ramdisk. Is it OK to reduce
the ramdisk by, for example, 80KB (2256 -> 2176KB)? Then, the INSTALL
kernel fits within 5MB.


Let's do that for now...


Besides, I propose for the kernel side,

  - drop DKWEDGE_METHOD_APPLE (0.4KB)

and for the ramdisk side,

  - drop FFS_EI and Apple UFS supports from fsck_ffs and newfs (13.4KB)
  - drop shutdown (3.5KB)

Then, we can save 17.3KB of the INSTALL kernel. Extra spaces for the
main kernel and ramdisk become 62.5KB and 232KB, respectively.


And leave those for later :-)


OK, I'll commit the former part, after some double check :-).

Thanks,
rin

Re: __empty in cdefs.h conflicts with g++/bits/stl_deque.h

[Rin Okuyama]

On 2017/02/09 3:01, Christos Zoulas wrote:

On Feb 9,  2:54am, rokuy...@rk.phys.keio.ac.jp (Rin Okuyama) wrote:
-- Subject: __empty in cdefs.h conflicts with g++/bits/stl_deque.h

| Hi,
|
| Build failure occurs after introduction of __empty to sys/cdefs.h.
| It seems to conflict with g++/bits/stl_deque.h.

Fixed.


Thanks. I fixed sbin stuff, too.

rin

Re: INSTALL kernel exceeds 5MB for zaurus

[Rin Okuyama]

On 2017/02/09 2:27, Swift Griggs wrote:

On Thu, 9 Feb 2017, Rin Okuyama wrote:

 - drop FFS_EI and Apple UFS supports from fsck_ffs and newfs (13.4KB)


I've tried to use Apple UFS file systems under NetBSD and had mixed results 
anyhow. At one point, I experienced some corruption, too (but it was probably 
because of something I did). So, it's not something that I, for one, would 
miss. I do like being able to read their old disklabels, though (apple UFS).


I'm just talking on the install media for zaurus. I do *not* mean that
Apple UFS support should be withdrawn from NetBSD. The failure of it is
another problem. It would be better to send PR if possible.

Thanks,
rin

__empty in cdefs.h conflicts with g++/bits/stl_deque.h

[Rin Okuyama]

Hi,

Build failure occurs after introduction of __empty to sys/cdefs.h.
It seems to conflict with g++/bits/stl_deque.h.

Thanks
rin

--- nv50_ir_lowering_gm107.pico ---
In file included from /var/build/dest/i386/usr/include/g++/deque:64:0,
 from /var/build/xsrc/external/mit/MesaLib/dist/src/gallium/driv
ers/nouveau/codegen/nv50_ir.h:29,
 from /var/build/xsrc/external/mit/MesaLib/dist/src/gallium/driv
ers/nouveau/codegen/nv50_ir_lowering_gm107.cpp:24:
/var/build/dest/i386/usr/include/g++/bits/stl_deque.h: In member function 'std::
_Deque_base<_Tp, _Alloc>::_Deque_impl std::_Deque_base<_Tp, _Alloc>::_M_move_imp
l()':
/var/build/dest/i386/usr/include/g++/bits/stl_deque.h:647:21: error: expected ';
' before '{' token
  _Deque_base __empty{__alloc};
 ^
/var/build/dest/i386/usr/include/g++/bits/stl_deque.h:648:9: error: invalid use
of 'void'
  __empty._M_initialize_map(0);
 ^
/var/build/dest/i386/usr/include/g++/bits/stl_deque.h:652:30: error: invalid use
 of 'void'
  _M_impl._M_swap_data(__empty._M_impl);
  ^

INSTALL kernel exceeds 5MB for zaurus

[Rin Okuyama]

Build fails for zaurus because the INSTALL kernel exceeds 5MB:

  http://releng.netbsd.org/builds/HEAD/201702072140Z/

I've found that there is extra space in the ramdisk. Is it OK to reduce
the ramdisk by, for example, 80KB (2256 -> 2176KB)? Then, the INSTALL
kernel fits within 5MB.

Besides, I propose for the kernel side,

  - drop DKWEDGE_METHOD_APPLE (0.4KB)

and for the ramdisk side,

  - drop FFS_EI and Apple UFS supports from fsck_ffs and newfs (13.4KB)
  - drop shutdown (3.5KB)

Then, we can save 17.3KB of the INSTALL kernel. Extra spaces for the
main kernel and ramdisk become 62.5KB and 232KB, respectively.

Thanks,
rin

Re: Floppy image overflow

[Rin Okuyama]

On 2017/02/08 13:13, Christos Zoulas wrote:

Sounds, great! Thanks!


Thanks :-).

On 2017/02/09 0:42, Izumi Tsutsui wrote:

I'm afraid these unused functions should be "do {} while (/*CONSTCOND*/0)"
rather than "empty" comments because they could be used in if clauses
without braces (which is allowed in our /usr/share/misc/style):
 https://nxr.netbsd.org/xref/src/sbin/fsck_ffs/inode.c?r=1.71#421
---
if (is_ufs2)
swap_dinode2(inodebuf, lastinum - inumber);
else
swap_dinode1(inodebuf, lastinum - inumber);
bwrite(fswritefd, (char *)inodebuf, dblk, size);
---

All other part looks fine.


Thank you so much for your detailed review. I fixed and committed it!

rin

Re: Floppy image overflow

[Rin Okuyama]

christos, tsutsui, thank you for your useful comments! I've updated
the patch accordingly:

  http://www.netbsd.org/~rin/atari_floppy_20160208.patch

On 2017/02/07 23:51, Christos Zoulas wrote:

I am not enamored  with more ifdef's but this seems ok to me.


Neither do I :-). In the new version, I've removed most of ifdef's.
Instead, I define flags like needswap or isappleufs as (0), and unused
functions as /* nothing */. The today's compiler is clever enough to
optimize out what we don't need, and we obtain the same (!) results as
before.

On 2017/02/07 23:54, Izumi Tsutsui wrote:

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.


I've added src/distrib/x_{fsck_ffs,newfs} and brief instruction there.

Note that the original Makefile in src/sbin/{fsck_ffs,newfs} has been
split into Makefile and Makefile.common, not Makefile.inc as in the
case of x_ifconfig. This is because Makefile.inc conflicts with
bsd.subdir.mk. I will also rename it for x_ifconfig, and do some clean
up after committing the main patch.

Thanks,
rin

Re: Floppy image overflow

[Rin Okuyama]

On 2017/02/07 17:32, Martin Husemann wrote:

On Tue, Feb 07, 2017 at 03:02:57PM +0900, Rin Okuyama wrote:

How about dropping Apple and byte-swapped UFS support from fsck_ffs and
newfs? Both seem to be useless for atari (is it right?). This reduces
about 10KB from instbin, and the resulting filesystem successfully fits
within 1.4MB.


I like it!


Thank you for your comment! I've updated the patch:

  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.

rin

Re: Floppy image overflow

[Rin Okuyama]

On 12 Jan 2017 14:32:59 +0100, Martin Husemann wrote:

Hey folks,

in -current the atari build fails due to the 1.4MB floppy image
overflowing.

See: http://releng.netbsd.org/cgi-bin/builds.cgi

Any ideas what to strip out?


How about dropping Apple and byte-swapped UFS support from fsck_ffs and
newfs? Both seem to be useless for atari (is it right?). This reduces
about 10KB from instbin, and the resulting filesystem successfully fits
within 1.4MB.

Thanks,
Rin

--- src/distrib/atari/floppies/common/Makefile.images.orig  2017-02-07 
07:14:09.304814268 +0900
+++ src/distrib/atari/floppies/common/Makefile.images   2017-02-07 
14:11:13.928606822 +0900
@@ -8,6 +8,8 @@
 WARNS= 1
 DBG=   -Os -m68020-60  # -m68020-60 seems to generate smaller binaries
 DBG+=  -DNDEBUG# to remove assert(3) macro
+CRUNCHENV+=NOAPPLEUFS=1# disable Apple UFS support
+CRUNCHENV+=NOUFSBSWAP=1# disable byte-swapped UFS support
 
 CRUNCHBIN=	instbin

 LISTS= ${.CURDIR}/list ${.CURDIR}/../common/list.images
--- src/sbin/fsck_ffs/Makefile.orig 2017-02-07 14:09:42.700416503 +0900
+++ src/sbin/fsck_ffs/Makefile  2017-02-07 11:29:54.319623708 +0900
@@ -6,8 +6,20 @@
 PROG=  fsck_ffs
 MAN=   fsck_ffs.8
 SRCS=  dir.c inode.c main.c pass1.c pass1b.c pass2.c pass3.c pass4.c \
-   pass5.c pass6.c fsutil.c setup.c utilities.c ffs_bswap.c ffs_subr.c \
-   ffs_tables.c ffs_appleufs.c partutil.c snapshot.c quota2.c quota2_subr.c
+   pass5.c pass6.c fsutil.c setup.c utilities.c ffs_subr.c \
+   ffs_tables.c partutil.c snapshot.c quota2.c quota2_subr.c
+
+.if defined(NOAPPLEUFS)
+CPPFLAGS+=-DNOAPPLEUFS
+.else
+SRCS+= ffs_appleufs.c
+.endif
+
+.if defined(NOUFSBSWAP)
+CPPFLAGS+=-DNOUFSBSWAP
+.else
+SRCS+= ffs_bswap.c
+.endif
 
 FSCK=	${NETBSDSRCDIR}/sbin/fsck

 DUMP=  ${NETBSDSRCDIR}/sbin/dump
--- src/sbin/fsck_ffs/fsck.h.orig   2017-02-07 14:09:42.702586585 +0900
+++ src/sbin/fsck_ffs/fsck.h2017-02-07 13:51:55.865661950 +0900
@@ -156,6 +156,7 @@
 struct fs *altsblock;
 struct cg *cgrp;
 struct fs *sblocksave;
+#ifndef NOUFSBSWAP
 #definesbdirty() \
do { \
memmove(sblk.b_un.b_fs, sblock, SBLOCKSIZE); \
@@ -164,6 +165,14 @@
ffs_sb_swap(sblk.b_un.b_fs, sblk.b_un.b_fs); \
sblk.b_dirty = 1; \
} while (0)
+#else
+#definesbdirty() \
+   do { \
+   memmove(sblk.b_un.b_fs, sblock, SBLOCKSIZE); \
+   sb_oldfscompat_write(sblk.b_un.b_fs, sblocksave); \
+   sblk.b_dirty = 1; \
+   } while (0)
+#endif
 #definecgdirty()   do {copyback_cg(); cgblk.b_dirty = 1;} 
while (0)
 
 #define appleufsdirty() \

@@ -362,3 +371,8 @@
return bswap64(x);
else return x;
 }
+
+/* XXX */
+#ifdef NOUFSBSWAP
+#defineufs_rw32(x, ns) (x)
+#endif
--- src/sbin/fsck_ffs/inode.c.orig  2017-02-07 14:09:42.704024121 +0900
+++ src/sbin/fsck_ffs/inode.c   2017-02-07 11:33:09.813269777 +0900
@@ -46,7 +46,9 @@
 #include 
 #include 
 #include 
+#ifndef NOUFSBSWAP
 #include 
+#endif
 
 #ifndef SMALL

 #include 
@@ -64,8 +66,10 @@
 static ino_t startinum;
 
 static int iblock(struct inodesc *, long, u_int64_t);

+#ifndef NOUFSBSWAP
 static void swap_dinode1(union dinode *, int);
 static void swap_dinode2(union dinode *, int);
+#endif
 
 int

 ckinode(union dinode *dp, struct inodesc *idesc)
@@ -342,6 +346,7 @@
return ((union dinode *)((caddr_t)pbp->b_un.b_buf + blkoff));
 }
 
+#ifndef NOUFSBSWAP

 static void
 swap_dinode1(union dinode *dp, int n)
 {
@@ -385,6 +390,7 @@
}
}
 }
+#endif
 
 /*

  * Special purpose version of ginode used to optimize first pass
@@ -417,6 +423,7 @@
lastinum += fullcnt;
}
(void)bread(fsreadfd, (caddr_t)inodebuf, dblk, size);
+#ifndef NOUFSBSWAP
if (doswap) {
if (is_ufs2)
swap_dinode2(inodebuf, lastinum - inumber);
@@ -424,6 +431,7 @@
swap_dinode1(inodebuf, lastinum - inumber);
bwrite(fswritefd, (char *)inodebuf, dblk, size);
}
+#endif
dp = (union dinode *)inodebuf;
}
ret = dp;
@@ -750,12 +758,16 @@
}
getblk(, cgtod(sblock, cg), sblock->fs_cgsize);
memcpy(cgp, cgblk.b_un.b_cg, sblock->fs_cgsize);
+#ifndef NOUFSBSWAP
if ((doswap && !needswap) || (!doswap && needswap))
ffs_cg_swap(cgblk.b_un.b_cg, cgp, sblock);
+#endif
if (!cg_chkmagic(cgp, 0))
pfatal("CG %d: ALLOCINO: BAD MAGIC NUMBER\n", cg);
+#ifndef NOUFSBSWAP
if (doswap)
cgdirty();
+#endif
setbit(cg_inosused(cgp, 0), ino % sblock->fs_ipg);
cgp->cg_cs.cs_nifree--;
sblock->fs_cstotal.cs_nifree--;
@@ -830,8 +842,10 @@
cg = ino_to_cg(sblock, ino);
getblk(, cgtod(sblock, 

Re: evbarm builds failing

[Rin Okuyama]

On 2016/12/30 0:25, co...@sdf.org wrote:

I've only seen INSTALL stuff being super-duper
minimal thus far. the LOONGSON INSTALL kernel doesn't
even have 'dmesg'.

A tiny install was great for quickly loading over the
network.


I still don't understand why should we reduce just 500KB of kernel size.
Is it then OK with you that the install kernel for RPI includes drivers
for all USB devices? Most of them are not essential for installation.


RPI has another much nicer option for installing, which
is dd'ing rpi.img to an SD card. comes with everything,
all the sets, etc.


Firmware images were added to the install kernels by this commit:

  
http://cvsweb.netbsd.org/bsdweb.cgi/src/distrib/evbarm/instkernel/sshramdisk/Makefile#rev1.4

The discussion in port-arm, raised in the commit log,

  http://mail-index.netbsd.org/port-arm/2014/08/01/msg002548.html

originated from this post to current-users:

  http://mail-index.netbsd.org/current-users/2014/07/13/msg025239.html

The submitter needed urtwn(4) for connecting RPI to his network. Should
users like him use a large SD card image only for < 100KB firmware? We
can provide an alternative choice by increasing only 500KB of kernel size.

At least, would you please ask port-arm before removing firmware images?

Thanks,
Rin

Re: evbarm builds failing

[Rin Okuyama]

On 2016/12/29 23:04, co...@sdf.org wrote:

armv7--netbsdelf-eabihf-mdsetimage: fs image (2048 bytes) too big for 
buffer (15204352 bytes)

the install kernels tend to be small and minimal... all of the
firmware in ${DESTDIR}/libdata/firmware is for wifi and for
radeon, I don't think it's absolutely essential. it's not
standard hardware for RPI.

Should it not install this firmware at all?


Why don't we simply increase buffer to 2MB? I'd prefer to maximize
available options for users rather than minimize the install kernels.
I agree with you if we need floppy disks to install for evbarm, but
we do not. And it is not always true that some devices are not
"standard" for evbarm just because they are not for RPI.

On 2016/12/29 23:13, Martin Husemann wrote:

I have also seen my alpha's root disk overflow recently, and of course
it can't use any of this (I did not yet get around to install the TC-USB
adaptor).

Maybe we should put firmware in different sets based on the bus the
device "usually" attaches to?


Hmm, it seems difficult to distinguish which devices are available for
a given port. For example, my AlphaServer and Sun Blade have xhci port
(via PCI to PCI-E bridge), although I've not seriously tested yet ;-).

  NetBSD 7.99.43 (DS10) #2: Thu Dec  1 19:16:36 JST 2016
  rin@xxx:xxx
  COMPAQ AlphaServer DS10 466 MHz, s/n
  ...
  ppb0 at pci0 dev 15 function 0: vendor 12d8 product e111 (rev. 0x02)
  ppb0: PCI Express capability version 1  x1 @ 
2.5GT/s
  pci1 at ppb0 bus 2
  pci1: i/o space, memory space enabled, rd/line, wr/inv ok
  xhci0 at pci1 dev 0 function 0: vendor 1912 product 0015 (rev. 0x02)
  xhci0: interrupting at dec 6600 irq 39
  xhci0: xHCI version 1.0
  usb0 at xhci0: USB revision 3.0

Thanks,
Rin

Re: uniq(1) is broken

[Rin Okuyama]

On 2016/10/16 15:18, Abhinav Upadhyay wrote:

Your patch looks good, I tested and committed. Thanks for the fix :-)


Fix confirmed. Thanks for your review and commit.

Rin

uniq(1) is broken

[Rin Okuyama]

uniq(1) is currently broken:

  % cat test
  1
  12
  1
  1
  % uniq test
  1
  12
  1
  1

This bug was introduced to uniq.c rev. 1.19,

  http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/uniq/uniq.c#rev1.19

where the size of buffer and the length of line are mixed up.
Please apply the attached patch. Beside fixing this bug, a tiny
optimization has been made; do not call skip() twice per line.

Thanks,
Rin

--- src/usr.bin/uniq/uniq.c.orig2016-10-16 08:11:18.115254706 +0900
+++ src/usr.bin/uniq/uniq.c 2016-10-16 09:33:36.693367693 +0900
@@ -65,12 +65,12 @@
 int
 main (int argc, char *argv[])
 {
-   const char *t1, *t2;
+   const char *prevp, *thisp;
FILE *ifp, *ofp;
int ch;
char *prevline, *thisline, *p;
size_t prevlinesize, thislinesize, psize;
-   size_t prevlinecompsize, thislinecompsize;
+   size_t prevlen, thislen;
 
 	setprogname(argv[0]);

ifp = ofp = NULL;
@@ -127,11 +127,15 @@
 
 	if ((p = fgetln(ifp, )) == NULL)

return 0;
-   prevlinesize = psize;
+   prevlinesize = prevlen = psize;
if ((prevline = malloc(prevlinesize + 1)) == NULL)
err(1, "malloc");
(void)memcpy(prevline, p, prevlinesize);
prevline[prevlinesize] = '\0';
+   if (numfields || numchars)
+   prevp = skip(prevline, );
+   else
+   prevp = prevline;
 
 	thislinesize = psize;

if ((thisline = malloc(thislinesize + 1)) == NULL)
@@ -143,22 +147,18 @@
err(1, "realloc");
thislinesize = psize;
}
+   thislen = psize;
(void)memcpy(thisline, p, psize);
thisline[psize] = '\0';
-   thislinecompsize = thislinesize;
-   prevlinecompsize = prevlinesize;
 
 		/* If requested get the chosen fields + character offsets. */

-   if (numfields || numchars) {
-   t1 = skip(thisline, );
-   t2 = skip(prevline, );
-   } else {
-   t1 = thisline;
-   t2 = prevline;
-   }
+   if (numfields || numchars)
+   thisp = skip(thisline, );
+   else
+   thisp = thisline;
 
 		/* If different, print; set previous to new value. */

-   if (thislinecompsize != prevlinecompsize || strcmp(t1, t2)) {
+   if (thislen != prevlen || strcmp(thisp, prevp)) {
char *t;
size_t ts;
 
@@ -169,6 +169,8 @@

ts = prevlinesize;
prevlinesize = thislinesize;
thislinesize = ts;
+   prevp = thisp;
+   prevlen = thislen;
repeats = 0;
} else
++repeats;

build fails due to intrctl on ARM

[Rin Okuyama]

Build fails due to intrctl(8) on ARM, whose char is unsigned. Please
apply the attached patch.

Thanks,
Rin

--- src/usr.sbin/intrctl/intrctl.c.orig 2016-10-16 05:31:55.270511416 +0900
+++ src/usr.sbin/intrctl/intrctl.c  2016-10-16 05:32:14.437245115 +0900
@@ -118,7 +118,7 @@
void *handle;
size_t intridlen;
int compact = 0;
-   char ch;
+   int ch;
 
 	while ((ch = getopt(argc, argv, "c")) != -1) {

switch (ch) {

Re: help for OpenSSL update needed

[Rin Okuyama]

On 2016/10/14 16:24, Martin Husemann wrote:

I'm a bit confused what you are trying to do. We support v9 (or v8plus)
machines only with sparc64 kernels (and the sparc SUN4U kernel is just
a 32bit sparc64 kernel actually).

You can then run (as you did) either sparc64 (v9, 64bit) userland or
plain sparc (v8, 32bit) userland. We have no special support to compile
sparc userland for v8plus (maybe by forcing COPTS?).


Thank you for your kind explanation. I was confused, but I've got to
understand (I think).

Rin

Re: help for OpenSSL update needed

[Rin Okuyama]

On 2016/10/13 4:02, Rin Okuyama wrote:

On 2016/10/13 3:16, S.P.Zeidler wrote:

If you don't use an ASM method it should fall back to C and that should
always work, just be a bit slower, and most of the ASM in sparc only kicks
in if MACHINE is sparc64.


Ah, I've realized the situation at last (I'm newbie to sparc). I checked two
cases of MACHINE == MACHINE_ARCH == sparc{,64}, but we also have to test yet
another case of MACHINE_ARCH == sparc && MACHINE == sparc64. Yes, I will do
it later (-current is broken at the moment, due to import errors of gdb.old).


Oops, the combination of MACHINE_ARCH == sparc && MACHINE == sparc64 is
rejected by build.sh. When do it forcibly, compile errors occur here and
there. ".if ${MACHINE} == sparc64" in somewhere/arch/sparc is paraphrase
of ".ifdef notdef"?

Sorry for getting off the subject,
Rin

Re: gdb.old is broken

[Rin Okuyama]

On 2016/10/13 10:20, Christos Zoulas wrote:

I think I got them all now... Bug in CVS, adds CVS directories when you
add files, but does not add the directories.


On 2016/10/13 10:24, Christos Zoulas wrote:

No, worries, is it ok now?


Thank you. Now, all the imported files are present in /usr/src.

Rin

Re: gdb.old is broken

[Rin Okuyama]

On 2016/10/13 8:45, Rin Okuyama wrote:

Some files are missing in gdb.old. FYI, I listed files imported by this commit
  http://mail-index.netbsd.org/source-changes/2016/10/12/msg078360.html
but not added by this one
  http://mail-index.netbsd.org/source-changes/2016/10/12/msg078361.html
Please find the attached file.


Some files listed here are present in /usr/src (I don't know why).
I listed files imported but actually missing in /usr/src. Sorry for
bothering you many times.

Rin


actually_missing.xz
Description: application/xz

gdb.old is broken

[Rin Okuyama]

Hi,

Some files are missing in gdb.old. FYI, I listed files imported by this commit
  http://mail-index.netbsd.org/source-changes/2016/10/12/msg078360.html
but not added by this one
  http://mail-index.netbsd.org/source-changes/2016/10/12/msg078361.html
Please find the attached file.

Thanks,
Rin


missing_files.xz
Description: application/xz

Re: help for OpenSSL update needed

[Rin Okuyama]

On 2016/10/13 3:16, S.P.Zeidler wrote:

# Some .S files in arch/sparc* are generated but not used. Is this OK?


That's mostly me being a completionist. Makes working on checking if they
have an advantage and activating them if yes at a later date easier.


OK, I understand. I agree with your strategy.


If you don't use an ASM method it should fall back to C and that should
always work, just be a bit slower, and most of the ASM in sparc only kicks
in if MACHINE is sparc64.


Ah, I've realized the situation at last (I'm newbie to sparc). I checked two
cases of MACHINE == MACHINE_ARCH == sparc{,64}, but we also have to test yet
another case of MACHINE_ARCH == sparc && MACHINE == sparc64. Yes, I will do
it later (-current is broken at the moment, due to import errors of gdb.old).

Thanks,
Rin

Re: help for OpenSSL update needed

[Rin Okuyama]

On 2016/10/12 7:37, S.P.Zeidler wrote:

I added your patch (with two modifications, see below) plus fixes that
make i386 and sparc* compile (and fix i386, which is tested) into my
changes and created a new diff from it:
http://www.netbsd.org/~spz/openssl-1.0.2j-forHEAD-3.diff.xz


I also tested it on UltraSPARC-IIe. Both sparc64 and sparc (GENERIC32.UP
kernel from sparc64 and userland from sparc) version passed the 29 tests
in /usr/tests/crypto/libcrypto.

# Some .S files in arch/sparc* are generated but not used. Is this OK?

Thanks,
Rin