Re: tweaks needed for 10 branch
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
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
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
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
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?
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
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
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
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 wrote: > Andrew Cagney 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
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]
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]
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
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)
On 29 February 2016 at 04:48, Michael van Elst 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
On 25 February 2016 at 09:47, Nick Hudson wrote:
> On 02/25/16 14:34, Andrew Cagney wrote:
>>
>> On 22 February 2016 at 12:46, Andrew Cagney
>> wrote:
>>>
>>> On 20 February 2016 at 17:14, Michael van Elst
>>> 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?
>
>
> Can you post a full dmesg?
see below...
> As Michael says the usb explore code doesn't wait properly here. There was
> code, but it's bit rotted.
>
>
>> 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.
>
>
> Maybe.
It turns out this was beginners luck. The pi also, occasionally,
can't see sd0 early in the boot process.
>>
>> 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.
>
>
> There used to be one as mentioned above.
>
> Can you try -current as of today - I made a change to dwctwo(4) this morning
> that *might* help here.
>
> Nick
QA5:A;SVN:B72;POC:17F;STS:0;BOOT:0;INIT:10;BOOT:1;INIT:0;READ:0;CHECK:0;PASS:1;
---
* Welcome to Hardkernel's ODROID-C... (Built at 19:33:00 Dec 8 2014) *
---
CPU : AMLogic S805
MEM : 1024MB (DDR3@792MHz)
BID : HKC1310001
S/N : HKC11122F37DF98C
0x009f
check SD_boot_type:0x1 card_type:0x1
Loading U-boot...success.
U-boot(odroidc@) (Mar 08 2015 - 11:08:17)
DRAM: 1 GiB
relocation Offset is: 2ff1c000
MMC: SDCARD: 0, eMMC: 1
IR init is done!
*** Warning - bad CRC, using default environment
mmc save env ok
vpu clk_level = 3
set vpu clk: 18215Hz, readback: 18215Hz(0x701)
mode = 6 vic = 4
set HDMI vic: 4
mode is: 6
viu chan = 1
config HPLL
config HPLL done
reconfig packet setting done
MMC read: dev # 0, block # 33984, count 12288 ... 12288 blocks read: OK
There is no valid bmp file at the given address
Vendor: Man 1a5051 Snr 033000ad Rev: 0.0 Prod: SD
Type: Removable Hard Disk
Capacity: 30750.0 MB = 30.0 GB (62976000 x 512)
Partition Start Sector Num Sectors Type
1 8192122880 c
2393216 2142464 a9
Net: Meson_Ethernet
init suspend firmware done. (ret:0)
Hit Enter key to stop autoboot -- : 1 0
exit abortboot: 0
reading boot.ini
173 bytes read
Loading boot.ini from mmc0:1 (vfat)
Executing the script...
setenv bootargs "root=sd0a awge0.mac-address=${ethaddr}"
setenv bootcmd "fatload mmc 0:1 0x2100 netbsd-ODROID-C1.ub; bootm
0x2100"
run bootcmd
reading netbsd-ODROID-C1.ub
6031432 bytes read
## Booting kernel from Legacy Image at 2100 ...
Image Name: NetBSD/amlogic 7.99.26
Image Type: ARM NetBSD Kernel Image (uncompressed)
Data Size:6031368 Bytes = 5.8 MiB
Load Address: 0010
Entry Point: 0010
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
uboot time: 5316626 us.
## Transferring control to NetBSD stage-2 loader (at address 0010) ...
[ 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 (ODROID-C1) #1: Fri Feb 26 11:00:27 EST 2016
cagney@morgan:/home/cagney/NetBSD/trunk/evbearmv7hf-el/sys/arch/evbarm/compile/ODROID-C1
total memory = 1024 MB
avail memory = 1007 MB
sysctl_createv: sysctl_create(machine_arch) returned 17
mainbus0 (root)
cpu0 at mainbus0 core 0: 1536 MHz Cortex-A5 r0p1 (Cortex V7A core)
cpu0: DC enabled IC enabled WB disabled EABT branch prediction enable
console=fb ignored when root=sd0a on pi (model Bv2)
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? Andrew
Re: root on sd0a on odroid-c1
On 22 February 2016 at 12:46, Andrew Cagney wrote: > On 20 February 2016 at 17:14, Michael van Elst 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
Re: root on sd0a on odroid-c1
On 20 February 2016 at 17:14, Michael van Elst 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. > > >>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
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]
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.
Re: Fwd: snprintf?
Just to clarify on one point: the bug is in NetBSD's port, not the original Lua sources. Lua doesn't need to do anything (and, so far, doesn't appear to to be that interested either). It might be prudent to apply some sort of fix to the 7.x branch. Andrew On 8 June 2015 at 16:19, Marc Balmer wrote: > Am 08.06.15 um 18:24 schrieb Andrew Cagney: >> FYI, want a bug report? > > I think this is best handled on the Lua mailing list. > >> >> -- Forwarded message -- >> From: Andrew Cagney >> 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 >> >
Fwd: snprintf?
FYI, want a bug report? -- Forwarded message -- From: Andrew Cagney 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
arm based chrome books
Ok, I'll be the sucker that asks ... Has anyone looked at getting NetBSD running on the latest crop of ARM based chromebooks from Samsung, Acer, ... that have processors based on the Cortex-A15 core. Andrew
Re: installboot: Old BPB too big, use -f (may invalidate file system)
On 22 January 2015 at 14:12, Michael van Elst 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
Re: installboot: Old BPB too big, use -f (may invalidate file system)
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 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
installboot: Old BPB too big, use -f (may invalidate file system)
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: netbsd-7, xorg and intel
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 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 "" > [ 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]
Re: Intel HD Graphics 3000 support/getting started
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 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?
Re: Intel HD Graphics 3000 support/getting started
What happens if you boot a current kernel (with your 6.1.5 userland)? It can't be worse, and if it works and doesn't crash, would provide a useful data point for kern/49368 Otherwise, I know a 7-beta userland with a current kernel do work for that hardware. On 20 November 2014 19:12, William D. Jones wrote: > Hello all, > > I know based on previous posts that Intel graphics drivers are available in > current. However, I'm currently a bit puzzled on how to get started with > these drivers due to lack of information about what specific drivers are > available, how to enable them, and how to setup X so I get beyond 1024x768 > resolution. > > To start, I have a Lenovo Thinkpad W520 as my laptop, with Intel HD Graphics > 3000, so getting a new gfx card is infeasible. Is this particular card > supported in amd64 current at this time? > > If so, what is the easiest way to get started if my current NetBSD > installation is 6.1.5 (which does not have such support and limits me to a > 4:3 ratio on a 16:9 monitor :P)? I know for now that I should disable > acceleration based on Firefox issues, which were mentioned in another post > on this list. If it's not currently supported, well- I just have to wait for > now :P. nv doesn't support my discrete gfx card (Quadro 2000M). > > Thanks in advance for any help you can give me! > > Sincerely, > > -- > William D. Jones > Rowan University | ECE | 2012 > Member IEEE > Member Tau Beta Pi > thor0...@comcast.net > Message sent using 'Windows Live Mail' client.
how to disable touch-pad tap-to-click
According to Windows I've an Elan SmartPad which can be configured to disable tap-to-click (it has buttons). I can't see how to do this under netbsd, any suggestions? The driver is pms: wskbd0 at pckbd0: console keyboard pms0 at pckbc1 (aux slot) pckbc1: using irq 12 for aux slot wsmouse0 at pms0 mux 0 Looking at the output from option PMSDEBUG it seems to me that the tap-to-click is coming from the device.
