Re: tweaks needed for 10 branch

[Andrew Cagney]

On Tue, 11 Jul 2023 at 16:03, matthew green  wrote:
>
> can you try commenting/removing this line (@L44 in -current) in
> external/gpl3/gcc/usr.bin/Makefile.inc:
>
>CXXFLAGS+=   -std=gnu++98
>
> i started seeing at least the gcc.c failure with GCC 10.5, and it
> seems that the upstream build doesn't use this by default now, and
> removing it fixed the build for me.

I started with an unmodified tree (i.e., above not applied), it died..
But a pull and re-try built.  For reference tip is:

commit 54cd507a2324fb39b6955bf3284dfa6d9a92090b (HEAD -> trunk,
origin/trunk, origin/HEAD)
Author: mrg 
Date:   Wed Jul 12 07:35:15 2023 +

don't force gnu++98 here.

fixes build issues seen with GCC 10.5, as well as hopefully ones reported
by Andrew Cagney on current-users.

thanks

Re: tweaks needed for 10 branch

[Andrew Cagney]

On Sun, 2 Jul 2023 at 11:54, Jason Thorpe  wrote:
>
>
>
> > On Jul 2, 2023, at 7:41 AM, Martin Husemann  wrote:
> >
> > On Sat, Jul 01, 2023 at 05:47:53PM -0400, Andrew Cagney wrote:
> >> just fyi, had to tweak this when building; to be honest I'm a bit puzzled
> >
> > Yes, puzzling - it is not clear what standard apple tools default to
> > after latest updates.
>
> I am going to assume that Andrew is using the Xcode 15 beta.  The NetBSD host 
> tools build fine with Xcode 14.3.

I wish.  The bootstrap compiler was:

[cagney@fedora ~]$ gcc --version
gcc (GCC) 13.1.1 20230614 (Red Hat 13.1.1-4)

The attrib ordering problem was fixed in mainline with:

commit a522e94176ebbb9251e648aee7a0e2c42bc4869a
Author: christos 
Date:   Sun Jan 15 18:12:37 2023 +

Apply 9cfe9507fcc22cd4a0c4da486ea1c7f0de6b075f for C23 attribute compliance.
Requested by Jan-Benedict Glaw.

something to pull up (according to git it isn't on netbsd-10 branch)

tweaks needed for 10 branch

[Andrew Cagney]

just fyi, had to tweak this when building; to be honest I'm a bit puzzled
Index: external/apache2/llvm/dist/llvm/include/llvm/Support/Signals.h
===
RCS file: 
/cvsroot/src/external/apache2/llvm/dist/llvm/include/llvm/Support/Signals.h,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 Signals.h
--- external/apache2/llvm/dist/llvm/include/llvm/Support/Signals.h  30 May 
2021 01:26:36 -  1.1.1.2
+++ external/apache2/llvm/dist/llvm/include/llvm/Support/Signals.h  1 Jul 
2023 20:40:33 -
@@ -15,6 +15,7 @@
 #define LLVM_SUPPORT_SIGNALS_H
 
 #include 
+#include 
 
 namespace llvm {
 class StringRef;
Index: lib/libc/time/zic.c
===
RCS file: /cvsroot/src/lib/libc/time/zic.c,v
retrieving revision 1.87
diff -u -r1.87 zic.c
--- lib/libc/time/zic.c 13 Dec 2022 19:08:42 -  1.87
+++ lib/libc/time/zic.c 1 Jul 2023 20:40:42 -
@@ -472,20 +472,23 @@
 ** Memory allocation.
 */
 
-static ATTRIBUTE_NORETURN void
+ATTRIBUTE_NORETURN
+static void
 memory_exhausted(const char *msg)
 {
fprintf(stderr, _("%s: Memory exhausted: %s\n"), progname, msg);
exit(EXIT_FAILURE);
 }
 
-static ATTRIBUTE_NORETURN void
+ATTRIBUTE_NORETURN
+static void
 size_overflow(void)
 {
   memory_exhausted(_("size overflow"));
 }
 
-static ATTRIBUTE_REPRODUCIBLE ptrdiff_t
+ATTRIBUTE_REPRODUCIBLE
+static ptrdiff_t
 size_sum(size_t a, size_t b)
 {
 #ifdef ckd_add
@@ -500,7 +503,8 @@
   size_overflow();
 }
 
-static ATTRIBUTE_REPRODUCIBLE ptrdiff_t
+ATTRIBUTE_REPRODUCIBLE
+static ptrdiff_t
 size_product(ptrdiff_t nitems, ptrdiff_t itemsize)
 {
 #ifdef ckd_mul
@@ -515,7 +519,8 @@
   size_overflow();
 }
 
-static ATTRIBUTE_REPRODUCIBLE ptrdiff_t
+ATTRIBUTE_REPRODUCIBLE
+static ptrdiff_t
 align_to(ptrdiff_t size, ptrdiff_t alignment)
 {
   ptrdiff_t lo_bits = alignment - 1, sum = size_sum(size, lo_bits);
@@ -680,7 +685,8 @@
   }
 }
 
-static ATTRIBUTE_NORETURN void
+ATTRIBUTE_NORETURN
+static void
 usage(FILE *stream, int status)
 {
   fprintf(stream,
@@ -3754,7 +3760,8 @@
return nsubs;
 }
 
-static ATTRIBUTE_NORETURN void
+ATTRIBUTE_NORETURN
+static void
 time_overflow(void)
 {
error(_("time overflow"));

modifying 9.9999 boot-com.iso using growisofs made init panic

[Andrew Cagney]

I'm trying to automate a KVM install.

With 9.3 I've got two ISOs:
 boot-com.iso - unchanged
 install.iso - modified to contain a script that does a 1.5 style install
the framework boots the VM from the unmodified boot-com.iso, and then
sends commands to mount install.iso and run the script

With 9... because there's no install.iso (true?) I'm instead
modifying boot-com.iso (from nycdn).  My problem is that when the ISO
is modified using growisofs it seems to cause init to abort (no
message, kernel then panics).  The command I'm using is:
growisofs -M $@.tmp -l \
-input-charset utf-8 \
-graft-points \
/base.sh=$(KVM_NETBSD_BASE_DOMAIN).base.sh
if boot-com.iso isn't modified then, like for 9.3, it boots fine.

Is this expected?

Re: .gdbinit files in the repository

[Andrew Cagney]

On Tue, 22 Nov 2022 at 11:49, Thomas Klausner  wrote:
>
> Hi!
>
> Should these files be there?
>
> /usr/src> find . -name .gdbinit
> ./external/gpl3/binutils/dist/gprof/.gdbinit
> ./external/gpl3/binutils.old/dist/gprof/.gdbinit
> ./external/gpl3/gdb/dist/gdb/testsuite/gdb.base/gdbinit-history/unlimited/.gdbinit
> ./external/gpl3/gdb/dist/gdb/testsuite/gdb.base/gdbinit-history/zero/.gdbinit
> ./external/gpl3/gdb/dist/sim/ppc/.gdbinit
> ./external/gpl3/gdb/dist/gprof/.gdbinit
> ./external/gpl3/gdb.old/dist/gdb/testsuite/gdb.base/gdbinit-history/unlimited/.gdbinit
> ./external/gpl3/gdb.old/dist/gdb/testsuite/gdb.base/gdbinit-history/zero/.gdbinit
> ./external/gpl3/gdb.old/dist/sim/ppc/.gdbinit
> ./external/lgpl3/gmp/dist/.gdbinit
>
> Looks to me like they should be deleted by the *2netbsd import preparation 
> scripts.

Is there a problem?  For instance, removing
gdb/testsuite/gdb.base/gdbinit-history/unlimited/.gdbinit would break
that test (if someone were to desire to run it).

On Tue, 22 Nov 2022 at 11:49, Thomas Klausner  wrote:
>
> Hi!
>
> Should these files be there?
>
> /usr/src> find . -name .gdbinit
> ./external/gpl3/binutils/dist/gprof/.gdbinit
> ./external/gpl3/binutils.old/dist/gprof/.gdbinit
> ./external/gpl3/gdb/dist/gdb/testsuite/gdb.base/gdbinit-history/unlimited/.gdbinit
> ./external/gpl3/gdb/dist/gdb/testsuite/gdb.base/gdbinit-history/zero/.gdbinit
> ./external/gpl3/gdb/dist/sim/ppc/.gdbinit
> ./external/gpl3/gdb/dist/gprof/.gdbinit
> ./external/gpl3/gdb.old/dist/gdb/testsuite/gdb.base/gdbinit-history/unlimited/.gdbinit
> ./external/gpl3/gdb.old/dist/gdb/testsuite/gdb.base/gdbinit-history/zero/.gdbinit
> ./external/gpl3/gdb.old/dist/sim/ppc/.gdbinit
> ./external/lgpl3/gmp/dist/.gdbinit
>
> Looks to me like they should be deleted by the *2netbsd import preparation 
> scripts.
>
> Ok to remove?
>  Thomas

Re: github.com/NetBSD/src 5 days old?

[Andrew Cagney]

On Mon, 27 Apr 2020 at 23:25, Greg A. Woods  wrote:
>
> At Mon, 27 Apr 2020 21:32:11 +0200, Thomas Klausner  wrote:
> Subject: Re: github.com/NetBSD/src 5 days old?
> >
> > This is an old discussion. If you are interested in this, read the
> > archives of the tech-repository mailing list.
> >
> > https://mail-index.netbsd.org/tech-repository/tindex.html
>
> Perhaps you could point to a specific thread or message?

The details are all found here:
https://mail-index.netbsd.org/tech-repository/2020/02/17/msg000685.html

> I've never found anything there explaining the actual rationale for Hg.
>
> --
> Greg A. Woods 
>
> Kelowna, BC +1 250 762-7675   RoboHack 
> Planix, Inc.  Avoncote Farms 

Re: File sharing over virtio-9p

[Andrew Cagney]

On Tue, 21 May 2019 at 03:28, Ryota Ozaki  wrote:
>
> Hi,
>
> The following two patches enables a NetBSD guest running
> on a Linux KVM to share files with its host over virtio-9p.

> Have fun,
>   ozaki-r

Thanks.

Re: patch for build.sh to guess native MACHINE_ARCH

[Andrew Cagney]

On Tue, 30 Apr 2019 at 05:17, matthew green  wrote:
>
> hi folks.
>
>
> anyone ever tried to run build.sh on a system like evbarm
> and it defaulted to "earm", even on arm64 systems?
>
> this simple patch makes build.sh guess MACHINE_ARCH with
> MACHINE, instead of then finding a default on the list.
>
> this only changes the behaviour when you run build.sh
> without any -m or -a option and it guesses from the local
> system.  with this patch, it will default to build for
> the native host.
>
> comments?

Thanks.

> .mrg.
>
>
> Index: build.sh
> ===
> RCS file: /cvsroot/src/build.sh,v
> retrieving revision 1.331
> diff -p -u -r1.331 build.sh
> --- build.sh25 Apr 2019 05:12:49 -  1.331
> +++ build.sh30 Apr 2019 09:13:52 -
> @@ -1416,6 +1416,7 @@ parseoptions()
> [ "${uname_s}" = "NetBSD" ] ||
> bomb "MACHINE must be set, or -m must be used, for cross 
> builds."
> MACHINE=${uname_m}
> +   MACHINE_ARCH=${uname_p}
> fi
> if $opt_m && ! $opt_a; then
> # Settings implied by the command line -m option

Re: $ sudo ifconfig run0 up list scan

[Andrew Cagney]

FYI,

I reproduced this on an amd64 box where the builtin wifi worked (so I
know it isn't my wpa_supplicant config :-).  I filed kern/53047.

I guess I should still find an unlocked hub.

On 3 February 2018 at 04:11, Tom Ivar Helbekkmo <t...@hamartun.priv.no> wrote:
> Andrew Cagney <andrew.cag...@gmail.com> writes:
>
>> I'm guessing it should list both my and a few near by networks?  I'm
>> getting no output and wpa_supplicant never gets past scanning.
>
> Same here.  On my Raspberry Pi model B+:
>
> NetBSD 8.99.10 (OTIUM) #7: Mon Jan  1 14:03:12 CET 2018
> 
> r...@barsoom.hamartun.priv.no:/usr/obj/sys/arch/evbarm/compile.evbarm/OTIUM
> [...]
> run0 at uhub1 port 3
> run0: Ralink (0x1044) 802.11 n WLAN (0x800d), rev 2.00/1.01, addr 5
> run0: MAC/BBP RT3070 (rev 0x0201), RF RT3020 (MIMO 1T1R), address 
> 6c:f0:6c:f0:bf:3e
> run0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
> run0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 
> 36Mbps 48Mbps 54Mbps
>
> I've been unable to get wpa_supplicant to connect this to anything --
> and 'ifconfig run0 list scan' generates no output.
>
> -tih
> --
> Most people who graduate with CS degrees don't understand the significance
> of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

$ sudo ifconfig run0 up list scan

[Andrew Cagney]

I'm guessing it should list both my and a few near by networks?  I'm
getting no output and wpa_supplicant never gets past scanning.
(I guess I get to find a base station with _no_ encryption and try that ...)

Andrew

NetBSD 8.0_BETA (ODROID-C1) #3: Wed Jan 17 22:30:46 EST 2018
netbsd-build/8/evbearmv7hf-el/sys/arch/evbarm/compile/ODROID-C1
...
run0 at uhub2 port 1
run0: Ralink (0xb05) 802.11 n WLAN (0x1784), rev 2.00/1.01, addr 3
run0: MAC/BBP RT3071 (rev 0x0213), RF RT3022 (MIMO 2T2R), address
e0:cb:e0:cb:b1:32
run0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
run0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps
24Mbps 36Mbps 48Mbps 54Mbps
(asus N13 USB)

Re: Remove fortune quotes attributed to or providing admiration of Adolf Hitler [pr bin/52735]

[Andrew Cagney]

On 19 November 2017 at 13:14,  wrote:

> I still think that we should remove offensive quotes, and if people
> cannot agree on it, all of fortune.
>
> Don't confuse my interest in de-escalation with giving up.
>

Yes, remove.  Be it the file or the entire program.   NetBSD is technical.
If living in the past is your desire, start here:
http://www.tuhs.org/archive_sites.html

Andrew

Re: Remove fortune quotes attributed to or providing admiration of Adolf Hitler [pr bin/52735]

[Andrew Cagney]

On 19 November 2017 at 15:16, Hisashi T Fujinaka  wrote:
> On Sun, 19 Nov 2017, Andy Ruhl wrote:
>
>> On Sun, Nov 19, 2017 at 8:44 AM, Joerg Sonnenberger  wrote:
>>>
>>> choice in the tonal sense, he was a brilliant orator and there are many
>>> useful quotes from him. Heck, he is often found on the list of most
>>> inspirational quotes. If anything, there should be more and better
>>> quotes from him in the database.
>>
>>
>> Yeah that's a step too far for me.
>>
>> Preserving the fortune program as it is for historical context is fine
>> for me. Adding more quotes from this jerk isn't productive. That would
>> send the wrong message. People can find these quotes elsewhere.
>>
>> In that sense I guess my position is preserving fortune as a
>> historical relic, nothing more. It's a snapshot in time of what the
>> developers of this stuff were thinking.
>
>
> I suggested that /usr/games just be moved to pkgsrc on irc. This makes a
> good argument for that move, to me, because there's no reason to be
> carrying around all that code if it's just for 'historic' purposes.

Yes please.

Re: nick-nhusb merge coming soon

[Andrew Cagney]

On 28 April 2016 at 06:56, Paul Goyette  wrote:
> On Wed, 13 Apr 2016, Paul Goyette wrote:
>
>> Does this include xhci support for USB3 (ie, removal of the "experimental"
>> tag)?
>
>
> FWIW, I finally got around to checking the status of USB3 on my machine.
>
> Firstly, let me note that I do not have any USB3 peripherals.  My only USB3
> equipment is the USB3 support on the motherboard itself.
>
> With an older 7.99.26 kernel, USB is totally screwed if I enable the USB3
> ports.  In order for _any_ USB device (ie, my mouse and keyboard) to work, I
> need to disable USB3 support in the BIOS.
>
> I'm happy to note that this restriction no longer exists!  With a kernel
> built from today's sources, the system boots just fine with all USB3 BIOS
> settings enabled, and the USB keyboard and mouse function normally.

If you have an install image USB stick handy, does it work when
plugged into a USB3 port?
I keep being tripped up by that one, and for multiple OSs.  Guess I
should give it another go :-)

Re: console=fb ignored when root=sd0a on pi (model Bv2)

[Andrew Cagney]

On 29 February 2016 at 04:48, Michael van Elst <mlel...@serpens.de> wrote:
> andrew.cag...@gmail.com (Andrew Cagney) writes:
>
>>has any one else tried or noticed this?
>
>>root=ld0a console=fb - things work as expected and shortly after
>>starting switch to hdmi
>>root=sd0a console=fb - things stick to the serial port?
>
> Nice. Does it work if you revert the order?

Yes, putting console=fb first avoids the problem:

NetBSD/evbarm (rpi) booting ...
[ Kernel symbol table missing! ]
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016
The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.

NetBSD 7.99.26 (RPI) #0: Mon Feb 22 14:20:58 EST 2016

cagney@morgan:/home/cagney/NetBSD/trunk/evbearmv6hf-el/sys/arch/evbarm/compile/RPI
total memory = 448 MB
avail memory = 433 MB
sysctl_createv: sysctl_create(machine_arch) returned 17
mainbus0 (root)
cpu0 at mainbus0 core 0: 700 MHz ARM1176JZ-S r0p7 (ARM11J V6ZK core)
cpu0: DC enabled IC enabled WB enabled LABT
cpu0: 16KB/32B 4-way L1 VIPT Instruction cache
cpu0: 16KB/32B 4-way write-back-locking-C L1 VIPT Data cache
vfp0 at cpu0: VFP11, rounding, exceptions
obio0 at mainbus0
bcmicu0 at obio0
bcmmbox0 at obio0 intr 65: VC mailbox
vcmbox0 at bcmmbox0
bcmtmr0 at obio0 intr 3: VC System Timer
vchiq0 at obio0 intr 66: BCM2835 VCHIQ
bcmpm0 at obio0: Power management, Reset and Watchdog controller
bcmdmac0 at obio0: DMA0 DMA2 DMA4 DMA5 DMA8 DMA9 DMA10
bcmrng0 at obio0: RNG
plcom0 at obio0 intr 57
plcom0: txfifo disabled
plcom0: console
genfb0 at obio0: switching to framebuffer console

vs:

NetBSD/evbarm (rpi) booting ...
[ Kernel symbol table missing! ]
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016
The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.

NetBSD 7.99.26 (RPI) #0: Mon Feb 22 14:20:58 EST 2016

cagney@morgan:/home/cagney/NetBSD/trunk/evbearmv6hf-el/sys/arch/evbarm/compile/RPI
total memory = 448 MB
avail memory = 433 MB
sysctl_createv: sysctl_create(machine_arch) returned 17
mainbus0 (root)
cpu0 at mainbus0 core 0: 700 MHz ARM1176JZ-S r0p7 (ARM11J V6ZK core)
cpu0: DC enabled IC enabled WB enabled LABT
cpu0: 16KB/32B 4-way L1 VIPT Instruction cache
cpu0: 16KB/32B 4-way write-back-locking-C L1 VIPT Data cache
vfp0 at cpu0: VFP11, rounding, exceptions
obio0 at mainbus0
bcmicu0 at obio0
bcmmbox0 at obio0 intr 65: VC mailbox
vcmbox0 at bcmmbox0
bcmtmr0 at obio0 intr 3: VC System Timer
vchiq0 at obio0 intr 66: BCM2835 VCHIQ
bcmpm0 at obio0: Power management, Reset and Watchdog controller
bcmdmac0 at obio0: DMA0 DMA2 DMA4 DMA5 DMA8 DMA9 DMA10
bcmrng0 at obio0: RNG
plcom0 at obio0 intr 57
plcom0: txfifo disabled
plcom0: console
genfb0 at obio0
wsdisplay0 at genfb0 kbdmux 1
[...]

> --
> --
> Michael van Elst
> Internet: mlel...@serpens.de
> "A potential Snark may lurk in every tree."

Re: root on sd0a on odroid-c1

[Andrew Cagney]

On 22 February 2016 at 12:46, Andrew Cagney <andrew.cag...@gmail.com> wrote:
> On 20 February 2016 at 17:14, Michael van Elst <mlel...@serpens.de> wrote:
>> andrew.cag...@gmail.com (Andrew Cagney) writes:
>>
>>>so I simply added root=sd0a to /boot/boot.ini's boot line.  That resulted in:
>> [...]
>>>use one of: awge0 ld0[a-p] ddb halt reboot
>>
>>>Should this have worked?
>>
>> Apparently not, as there is no sd0a boot device.

Just FYI,

Tried a similar configuration on the Pi (i.e., same physical disk, but
did add ta powered USB hub), and it's working fine.  Hmm, perhaps it
is a power issue.

Andrew

>>>However, I get the feeling that there's more going on.  For instance,
>>>just adding an entry to /etc/fstab to mount of /dev/sd0a on /mnt fails
>>>during boot (fsck can't access /dev/rsd0a during the boot).  Yet once
>>>the system is booted it works fine.
>>
>> The USB disk is probably starting too slowly to be recognized at this
>> point. There needs to be some kind of spin-up delay in the kernel to
>> handle this situation.
>
> Ah.
>
> Is there any existing kernel event that would indicate a disk device
> has come on line?
>
> Andrew

root on sd0a on odroid-c1

[Andrew Cagney]

I've an odroid-c1 running current.  I'm trying to get the root file
system onto a USB disk and, I suspect, missing something obvious.

The default kernel has something like:

config netbsd root on ? type ?

so I simply added root=sd0a to /boot/boot.ini's boot line.  That resulted in:

sdmmc1: sdmmc_mem_enable failed with error 60
sdmmc1: couldn't enable card: 60
boot device: 
unknown device major 0x
root device:
use one of: awge0 ld0[a-p] ddb halt reboot

Should this have worked?  Given the device, moving root to a USB drive
isn't that unusual.

Next I built a kernel with:

  config netbsd-sd0 root on sd0 type ?

and set root=sd0a in boot.ini, that resulted in:

sdmmc1: sdmmc_mem_enable failed with error 60
sdmmc1: couldn't enable card: 60
boot device: 
device sd0 (0x1800) not configured
root device: sd0a
use one of: awge0 ld0[a-p] ddb halt reboot

Perhaps I should have specified "root on sd0a"?

However, I get the feeling that there's more going on.  For instance,
just adding an entry to /etc/fstab to mount of /dev/sd0a on /mnt fails
during boot (fsck can't access /dev/rsd0a during the boot).  Yet once
the system is booted it works fine.

Andrew

Re: Ways to report trace when boot panics [Was NetBSD 7.0 i386 panic during boot]

[Andrew Cagney]

On 12 October 2015 at 10:32, Robert Elz  wrote:
> Long long ago I did an implementation of config code (more or less a console)
> for a device that had nothing but ethernet.   For that (and to avoid the
> issue that would arise here, of needing specialised client code) I used telnet
> over TCP.   Sounds like a complex software stack, but wasn't really.   The
> TCP and telnet implementations were (I believe) fully standards compliant,
> but were extremely limited. The Telnet would refuse all option negotiation
> for example, and refuse to operate any way but how it wanted (legal, but not
> generally useful).  The TCP IP and ethernet were all polled, lockstep
> implementations (I send, you reply, one packet at a time).   That achieved
> by simply setting the window size for receive very low - whatever size packets
> the other end transmitted, became the window size...   Not useful in general,
> and definitely not efficient in any sense, but worked just fine for the
> purpose (only a single connection at a time of course.)   The whole
> implementation turned out to be surprisingly small.

Right.  Or even simpler, 'netcat -u'.  If things really are desperate
then the ethernet might just be the easiest way out.

Fwd: snprintf?

[Andrew Cagney]

FYI, want a bug report?

-- Forwarded message --
From: Andrew Cagney andrew.cag...@gmail.com
Date: 8 June 2015 at 12:22
Subject: snprintf?
To: lu...@lists.lua.org


Hi,

I just found a bug in an embedded port of lua which didn't support
sprintf().  Specifically, the work-around:

#define sprintf(s,fmt,...)  snprintf(s, sizeof(s), fmt, __VA_ARGS__)

is broken.  Consider correct code such as:

char *b = ...; sprintf(b, %d, 1);

found in lstrlib.c.

This, however, begs the question: should lua switch to snprintf()?

First, I don't think anyone will dispute that snprintf() is more
robust than sprintf().  Rather, the problem is with portability.
While snprintf() was formalized in c99, and almost all the C compilers
have been supporting it since forever, there's been one holdout -
Microsoft - they have had a somewhat recalcitrant attitude towards C
standards compliance and, consequently, snprintf wasn't an option
(Microsoft does have sprintf_s()  and _snprintf() but they have
different semantics).
http://en.cppreference.com/w/c/io/fprintf
https://msdn.microsoft.com/en-us/library/2ts7cx93%28v=vs.120%29.aspx

However, recently we've been seeing something of a shift in
Microsoft's attitude. Specifically Visual Studio 14/15 should support
things like snprintf:
http://blogs.msdn.com/b/vcblog/archive/2014/06/03/visual-studio-14-ctp.aspx

So I'd like to float the idea of adopting snprintf(), for instance:

- just assume snprintf (which would require a very recent Microsoft C compiler)

- define Lsnprintf() as snprintf() and use that, except on old windows
systems which can wrap _snprintf() and deal with the different
semantics

- define Lsnrintf() as snprintf() and use that, except on windows
where it is re-defined as sprintf() (ignore the length parameter);
this means things are no worse than what we have now

Andrew

Re: installboot: Old BPB too big, use -f (may invalidate file system)

[Andrew Cagney]

On 22 January 2015 at 14:12, Michael van Elst mlel...@serpens.de wrote:
 andrew.cag...@gmail.com (Andrew Cagney) writes:

Ah, but the installer does know this.  in fact I believe it:
- first formatted wd0a with ffsv2
- then tried to do the installboot on wd0a and failed
so if wd0a was set up wrong I'm already be deep in goop.

 newfs could clear that area of the bootblock when it is formatting
 the filesystem, but currently it does not touch the bootblock at all
 and you couldn't rule out that some other bootblock should be used
 that would be damaged.

True.  But if that were the case I'd have chosen the don't modify
this boot-block option.

 The best method is probably to warn the user and let him decide.

Given a message telling me that -f will destroy my file system, I'm
likely make the wrong decision :-)

This is from arch/i386.c
 * If the partition has a FAT (or NTFS) filesystem, then we must
 * preserve the BIOS Parameter Block (BPB).
yet the -f code doesn't check the predicate (I suspect it doesn't have
enough context to exhaustively test it).

On the other hand, the installer does have the entire context:
- my partition is NetBSD
- wd0a within that partition contains ffs (new or existing)
so, I think it could apply -f

Andrew

installboot: Old BPB too big, use -f (may invalidate file system)

[Andrew Cagney]

Hi,

While trying to squeeze a NetBSD-7 snapshot into a newly created
partition on a disk that already contains several other OSs, things
died with:

  installboot -o console=pc,speed=9600 /dev/rwd0a /usr/mdec/bootxx_ffsv2
  Old BPB too bug, use -f (may invalidate file system)

Huh?  Searching suggests this is is something that this only happens
with floppy disks and the like?

Some particulars that might be relevant to the install:

- the partition table and disk look something like:
  #1 ntfs
  #2 ntfs
  #3 my partition created using gparted
  #4 Extended
#5 ext3
#6 ext3

- for NetBSD, within #4, I used the defaults (new file system, ...)

- MPR boot blocks were not installed (existing grub)

- per above, pc console being installed, died
(I also tried telling it to leave things as-is and that got a core
dump from sysinst)

While I got around this by running the above with -f and restarting
the install, I've got to wonder why, when initializing a partition
from scratch, this would happen.

Andrew

Re: installboot: Old BPB too big, use -f (may invalidate file system)

[Andrew Cagney]

It probably wasn't clear from my e-mail - I'm using sysinst so I was
expecting things to to go smoothly

On 21 January 2015 at 15:22, Michael van Elst mlel...@serpens.de wrote:
 andrew.cag...@gmail.com (Andrew Cagney) writes:

While trying to squeeze a NetBSD-7 snapshot into a newly created
partition on a disk that already contains several other OSs, things
died with:

  installboot -o console=pc,speed=9600 /dev/rwd0a /usr/mdec/bootxx_ffsv2
  Old BPB too bug, use -f (may invalidate file system)


 This says that while installing a boot block, a (somewhat) valid
 BIOS Parameter Block in that location was detected that cannot
 be preserved because it is too large (the BPB is variably sized).
 It is necessary to preserve a BPB in case the partition contains
 a FAT or NTFS filesystem.

Thanks for the explanation.

From memory and guessing, the area covered by the start of partition 3
(where I'm putting NetBSD) has contained:
- random disk data
- netbsd
- an extended partition table (from memory that appears at the start
of a primary partition)
so perhaps in the distant past.

 Unfortunately installboot cannot determine wether the BPB is really
 needed or if the partition is or will be reformatted with something
 (like FFS or ext3) that doesn't require it. Thus the warning.

Ah, but the installer does know this.  in fact I believe it:
- first formatted wd0a with ffsv2
- then tried to do the installboot on wd0a and failed
so if wd0a was set up wrong I'm already be deep in goop.

 You didn't say where wd0a is located, a wrong disklabel might cause
 it to overlap some of your NTFS partitions. But if you are sure that
 you don't accidentally overwrite some innocent valid bootblock, then
 using installboot -f to clean the old BPB is the right thing to do.

I thought I mentioned that.  gparted created the primary partition,
and sysinst set up the NetBSD partitioning (wd0a, wd0b) within that.
I'm pretty sure that gparted and sysinst did things right.

Sounds like two bugs:
- the installer (installboot) getting confused by crud at the start of
a valid wd0a
- (as I mentioned) the installer crashing when told to not run installboot

Andrew

Re: netbsd-7, xorg and intel

[Andrew Cagney]

Perhaps try a current kernel?  I needed that to get netbsd-7 userland working.

pci0 at mainbus0 bus 0: configuration mode 1
pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
pchb0 at pci0 dev 0 function 0: vendor 8086 product 0104 (rev. 0x09)
i915drmkms0 at pci0 dev 2 function 0: vendor 8086 product 0116 (rev. 0x09)
drm: Memory usable by graphics device = 2048M
drm: Supports vblank timestamp caching Rev 2 (21.10.2013).
drm: Driver supports precise vblank timestamp query.
i915drmkms0: interrupting at ioapic0 pin 16 (i915)
drm: Wrong MCH_SSKPD value: 0x16040307
drm: This can cause pipe underruns and display issues.
drm: Please upgrade your BIOS to fix this.
intelfb0 at i915drmkms0
i915drmkms0: info: registered panic notifier
intelfb0: framebuffer at 0x80008e29d000, size 1366x768, depth 32,
stride 5504
wsdisplay0 at intelfb0 kbdmux 1: console (default, vt100 emulation),
using wskbd0
wsmux1: connecting to wsdisplay0

Just be wary of kern/49368: 8(?) pixel artifacts in X, eventual kernel
crash; the workaround is to disable acceleration

On 28 November 2014 at 05:27, Manuel Bouyer bou...@antioche.eu.org wrote:
 Hello,
 I upgraded a laptop (with an intel 965GM) to netbsd-7 and can't get xorg to
 work properly.
 When I start xorg without config file, it uses the vesa driver and
 can't use the display's native mode (1280x800); I guess because this is
 not a standard VESA mode.
 When I try to force the use of the Intel driver, it says no screen
 found just as if the driver didn't find the card.

 Is there something missing in netbsd-7 for intel graphics ?

 Below are the relevant lines of the dmesg, and Xorg.log

 [...]
 acpivga0 at acpi0 (VID): ACPI Display Adapter
 acpiout0 at acpivga0 (TV, 0x0200): ACPI Display Output Device
 acpiout1 at acpivga0 (CRT, 0x0100): ACPI Display Output Device
 acpiout2 at acpivga0 (LCD, 0x0400): ACPI Display Output Device
 acpiout3 at acpivga0 (DVI, 0x0300): ACPI Display Output Device
 acpivga0: connected output devices:
 acpivga0:   0x0100 (acpiout1): Ext. Monitor, head 0, bios detect
 acpivga0:   0x0200 (acpiout0): TV, head 0, bios detect
 acpivga0:   0x0400 (acpiout2): Unknown Output Device, head 0, bios detect
 acpivga0:   0x0300 (acpiout3): Unknown Output Device, head 0, bios detect
 acpivga1 at acpi0 (VID2): ACPI Display Adapter
 acpivga1: failed to evaluate \_SB_.PCI0.VID2._DOD: AE_BAD_DATA
 [...]
 attimer1: attached to pcppi1
 pci0 at mainbus0 bus 0: configuration mode 1
 pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
 pchb0 at pci0 dev 0 function 0: vendor 0x8086 product 0x2a00 (rev. 0x0c)
 agp0 at pchb0: i965-family chipset
 agp0: detected 7676k stolen memory
 agp0: aperture at 0xe000, size 0x2000
 vga1 at pci0 dev 2 function 0: vendor 0x8086 product 0x2a02 (rev. 0x0c)
 vga1: WARNING: ignoring 64-bit BAR @ 0x10
 vga1: WARNING: ignoring 64-bit BAR @ 0x18
 wsdisplay0 at vga1 kbdmux 1: console (80x25, vt100 emulation), using wskbd0
 wsmux1: connecting to wsdisplay0
 i915drm0 at vga1: Intel i965GM
 i915drm0: AGP at 0xe000 256MB
 i915drm0: Initialized i915 1.6.0 20080730
 vendor 0x8086 product 0x2a03 (miscellaneous display, revision 0x0c) at pci0 
 dev 2 function 1 not configured


 [  1303.371]
 X.Org X Server 1.10.6
 Release Date: 2011-07-08
 [  1303.371] X Protocol Version 11, Revision 0
 [  1303.371] Build Operating System: NetBSD/i386  -
 [  1303.371] Current Operating System: NetBSD samarcande.soc.lip6.fr 7.0_BETA 
 NetBSD 7.0_BETA (GENERIC.201411250930Z) i386
 [  1303.371] Build Date: 01 August 2011  01:01:00AM
 [  1303.371]
 [  1303.371] Current version of pixman: 0.32.6
 [  1303.372]Before reporting problems, check http://wiki.X.Org
 to make sure that you have the latest version.
 [  1303.372] Markers: (--) probed, (**) from config file, (==) default 
 setting,
 (++) from command line, (!!) notice, (II) informational,
 (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
 [  1303.372] (==) Log file: /var/log/Xorg.0.log, Time: Fri Nov 28 11:20:22 
 2014
 [  1303.372] (==) Using config file: /etc/X11/xorg.conf
 [  1303.372] (==) No Layout section.  Using the first Screen section.
 [  1303.372] (**) |--Screen Screen0 (0)
 [  1303.372] (**) |   |--Monitor default monitor
 [  1303.372] (**) |   |--Device Card0
 [  1303.372] (==) No monitor specified for screen Screen0.
 Using a default monitor configuration.
 [  1303.372] (==) Not automatically adding devices
 [  1303.372] (==) Not automatically enabling devices
 [  1303.373] (==) FontPath set to:
 /usr/X11R7/lib/X11/fonts/misc/,
 /usr/X11R7/lib/X11/fonts/TTF/,
 /usr/X11R7/lib/X11/fonts/Type1/,
 /usr/X11R7/lib/X11/fonts/75dpi/,
 /usr/X11R7/lib/X11/fonts/100dpi/
 [  1303.373] (==) ModulePath set to /usr/X11R7/lib/modules
 [  1303.373] (==) |--Input Device Mouse0
 [  1303.373] (==) |--Input Device Keyboard0
 [  1303.373] (==) No Layout section. Using the first mouse device.
 [  1303.373] 

Re: Intel HD Graphics 3000 support/getting started

[Andrew Cagney]

Just to expand a little, I've the same built in graphics and my screen
should do 720p, so this is what I did:

- I tried 6.1.5 and, like you, found it couldn't do 720p; yes painful
I did notice, though, that while Xorg was loading the correct driver,
it wasn't detecting that the screen could do 720p.  That could be
kernel,  that could be Xorg, and that could be both (I'd tend towards
kernel though as I know Linux has been able to do 720p on this laptop
for several years)

- I next tried 7.x beta
I noticed that the Xorg driver had been updated (tech-x11@ suggests
early this year), but still no 720p, grrr

- finally, I started looking at current, always first the kernel
Pop, 720p at last (but per kern/49368 need to turn off acceleration)

So like Greg Troxel described - I'm running a userland from the
netbsd-7 branch and a kernel from current.

I guess that gives you two options:
- like I suggested boot a current kernel and see what happens (don't
override /netbsd though); no luck then ...
- install netbsd-7 beta and then add a current kernel

On 22 November 2014 at 04:23, William D. Jones thor0...@comcast.net wrote:
 With my current userland, the hardware is detected by Xorg, but Xorg falls
 back to using the VESA driver. The only resolution available there is
 1024x768... on a widescreen monitor. It's not a pleasant experience. Am I
 supposed to be getting more resolutions with the current Intel Xorg driver?
 Using xrandr to set them doesn't work either- I get errors trying to program
 the CRTC (don't remember the errors specifically offhand).

 In essence, the 6.1.5 kernel and X server both WORK on my hardware, just
 that I'd be hard pressed to get any work done on it.

 Also 7-beta userland with a current kernel? Is there a tar.gz file of a
 stable 7-beta userland (one that will not be changing daily) available on
 the FTP server?