How about change boot to use whatever boot.cfg says is the default
boot option, and boot ...anything... to be the override-the-menu
command?
How does the attached look? It should implement the suggested idea.
The changes you propose sound like a good idea, however, I'm not sure
I
With sources up-to-date, I'm seeing:
# build librumphijack/librumphijack.so.0.0
...
librumphijack.a(hijack.o):(.eh_frame+0x1c): warning: relocation emitted
against readonly section
Me too, for all mips ports, apparently. I've not seen this error
message before, and would like hints
For reference I include the dmesg outputs which I could capture
since the network device *is* supported.
Bah, forgot the -current dmesg. Here it is.
- Håvard
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013
The
It's not at all clear to me where maildrop directory is. And it is
also not clear to me why this is broken, since I took great pains to
avoid modifying the postfix {master,main}.cf files during etcupdate.
I hit that last week - I think it is a change postfix...
$ ls -ld
Ooopppsss!
red-face
Seems like I forgot the -p option when untarring the distribution
sets!
Been there, done that, wasn't too pleasant... :)
Regards,
- Håvard
Hi,
for some odd reason that I've not yet found, the file
/usr/include/gcc-4.5/mm_malloc.h is being included by one of the
configure tests for the net/libcmis package, and configure is
failing with this error:
/usr/include/gcc-4.5/mm_malloc.h:34:64: error: declaration of 'int
Another datapoint maybe. I've manage to rebuild a few 7.0_BETAs
without scratching the old obj files and all arch i386 has
survived those upgrades. The only system that has crashed for
me was arch amd64. Was that what you where running on your
machine too?
Yep, testing with NetBSD/amd64.
-
Hi,
I'm running netbsd-7 code on my new Lenovo T430 laptop. I'm
using code from November 27 at the moment, with the DRM/KMS
kernel, and there are a few glitches:
1) Sometimes the rendering of images e.g. in a web browser
(firefox) is mangled / interlaced (not sure how to best
describe
Hi,
I've recently been installing NetBSD on a new Lenovo RD350
server. I first tried booting from USB disk and from a USB
CD-ROM drive, and both the install kernels loaded just fine.
However, the boot medium was not probed by the 7.0_BETA amd64
kernel.
The kernel on NetBSD 6.1.3 CD-ROM install
I've recently been installing NetBSD on a new Lenovo RD350
server. I first tried booting from USB disk and from a USB
CD-ROM drive, and both the install kernels loaded just fine.
However, the boot medium was not probed by the 7.0_BETA amd64
kernel. [...]
Anyone else seeing something
A kernel compiled with options USB_DEBUG doesn't provide any
more information that I can see [...]
With additionally usbdebug and uhubdebug set to 10 resulted in
the attached boot messages. cd0 is still not probed.
Regards,
- Håvard
Apr 28 23:39:11 tos-res su: he to root on /dev/pts/2
This is PR kern/48494 :(
I tried a -current kernel, no improvement.
I also tried the change which was suggested in the PR (and then
reverted), and that also made no difference.
Regards,
- Håvard
Hi,
I've recently had occasion to try to install NetBSD on a new
Lenovo RD350 1U server. I've tried the following versions and
boot device combinations:
7.0_BETA from USB flash disk
7.0_BETA from a USB CD-ROM
7.99.10 from a USB CD-ROM
6.1.3 from a USB CD-ROM
I've also hooked up a Dell USB
I've recently been installing NetBSD on a new Lenovo RD350
server. I first tried booting from USB disk and from a USB
CD-ROM drive, and both the install kernels loaded just fine.
However, the boot medium was not probed by the 7.0_BETA amd64
kernel. [...]
Anyone else seeing something
On Thu, Jul 30, 2015 at 10:25:36PM +0200, Havard Eidnes wrote:
I tried to configure a port channel (agr0).
When I configure the port channel only with bnx0 or only with bnx1
everything works. If I use bnx0 and bnx1, the Cisco switch sets one of
the two links to suspended mode.
If I'm
I tried to configure a port channel (agr0).
When I configure the port channel only with bnx0 or only with bnx1
everything works. If I use bnx0 and bnx1, the Cisco switch sets one of
the two links to suspended mode.
If I'm not terribly mistaken, the problem is that both physical
interfaces are
>> Meanwhile the hardware random generator sits there unused.
>
> Does it sit there completely unused, or did it get used a little at
> boot time?
It generated some bits at boot time, but apparently not early
enough, because on each reboot the kernel log looks like this:
...
total memory = 1024
> And while I'm on a roll I might as well promote -P as well. I think
> that unless you know what you are doing, -d and -P is probably
> switches you always want to apply when you do cvs update.
I agree -- that's why my ~/.cvsrc contains:
update -d -P
diff -u
rdiff -u
Regards,
- Håvard
Hi,
on a couple of arm boxes I have I've been observing the
development of the entropy estimate, what "rndctl -s" calls "bits
currently stored in pool" over time.
I've also tried to read some of the code to understand the
behaviour.
If I understand correctly, randomness sources come in two
Hi,
I have a couple of ODROID C1 boxes. One of them appear to have
intermittent networking problems, in particular with receiving
packets.
droid# uname -a
NetBSD droid.urc.uninett.no 7.99.58 NetBSD 7.99.58 (ODROID-C1) #0: Thu Jan 12
10:12:54 CET 2017
Hi,
this afternoon I attempted to upgrade NetBSD from 7.1_STABLE to
8.0_BETA on an amd64-running machine in our lab. It has an aac
controller, probed like so:
aac0 at pci6 dev 0 function 0: IBM ServeRAID 8k
aac0: interrupting at ioapic0 pin 17
aac0: Enabling 64-bit address support
aac0: Enable
Hi,
the OpenSSH in NetBSD has for quite a while had the "high-
performance networking" patches applied.
However, despite this, we are observing rather low performance
when copying files over a distance, e.g. we have a pair of hosts
running netbsd-7 code, placed some 14-15ms apart, where scp'ing
Hi,
>
> # Improves TCP performance significantly with ssh.
> net.inet.tcp.recvbuf_auto=1
> net.inet.tcp.sendbuf_auto=1
> net.inet.tcp.sendbuf_max=16777216
> net.inet.tcp.recvbuf_max=16777216
Thanks for the suggestions, and I've done some initial
adjustments with beneficial results. I was a bit
> On 01.04.2018 16:53, Havard Eidnes wrote:
>> And some of the internal functions in libexecinfo are apparently
>> static, so not present in the symbol table for display in the
>> debugger, making debugging all that much harder.
>>
>> Sigh!
>>
>>
>>> I don't see an ATF machine for powerpc, there shall be one available.
>>>
>>> http://releng.netbsd.org/test-results.html
>>
>> Mm, OK, doing the tests on netbsd-8 on this MacMini G4 should be
>> fairly straight-forward.
>
> Not so. The machine wedged partway through the tests, it's in
> the
>> Hm, I am suspecting that nobody has actually tested whether
>> backtrace() really works on NetBSD/powerpc... I'll write a
>> simple test of that in C tomorrow.
>
> Yes, this looks more like dysfunctional backtrace(3).
>
> We have got an ATF test for this:
>
>
>> I don't see an ATF machine for powerpc, there shall be one available.
>>
>> http://releng.netbsd.org/test-results.html
>
> Mm, OK, doing the tests on netbsd-8 on this MacMini G4 should be
> fairly straight-forward.
Not so. The machine wedged partway through the tests, it's in
the office and
Hi,
I decided it might be a good idea to run the self-tests in llvm
5.0.1 on powerpc. However, after the test and utilities are
built, it appears to spin while doing the first test. The run
log shows:
[100%] Built target LLVMHello_exports
[100%] Built target LLVMHello
Scanning dependencies of
And ... as follow-up I thought I'd check whether "make test" in
lang/llvm (5.0.1nb1) works on NetBSD/amd64 8.0_BETA. And while the
selftest setup seems to work fine on this platform, there are quite a
bit of unexpected failures:
Expected Passes: 20309
Expected Failures : 130
>> And ... as follow-up I thought I'd check whether "make test" in
>> lang/llvm (5.0.1nb1) works on NetBSD/amd64 8.0_BETA. And while the
>> selftest setup seems to work fine on this platform, there are quite a
>> bit of unexpected failures:
>>
>> Expected Passes: 20309
>> Expected
> Yes. I had a similar problem. The build would fill up the
> /tmp/ directory and die from exhausted resources. I had /tmp/
> created with tmpfs and had a constraint of 64M. The answer for
> me was to create /tmp in /etc/fstab with tmpfs and no size
> constraint. Then Rust would build, but it
>> I just updated one of my source trees to netbsd-7, and did a
>> fresh rebuild (empty obj and dest, host oldish 7.1_STABLE), but
>> got:
>
> For what value of "just"? You need something from today around noon UTC
> or newer.
My update was done 13:06 UTC+1, but via a cvs mirror, so possibly
a
Hi,
I just updated one of my source trees to netbsd-7, and did a
fresh rebuild (empty obj and dest, host oldish 7.1_STABLE), but
got:
compile libc/compat___msgctl13.o
In file included from /usr/src/lib/libc/compat/sys/compat___msgctl13.c:48:0:
/usr/src/sys/compat/sys/msg.h: In function
> The failure doesn't give much of a clue about what's happened.
> The last lines in the build.log are:
>
> running: /pkg_comp/work/pkg/lang/rust/work/rust-bootstrap/bin/cargo build
> --manifest-path
> /pkg_comp/work/pkg/lang/rust/work/rustc-1.42.0-src/src/bootstrap/Cargo.toml
> --frozen
>
> I suspect what is commonly the problem here is related to the fact
> that cvs has such a phase at the beginning where it is scanning
> through the file system, which can take quite a while. Some NAT
> devices along the path sometimes have timeouts on existing connections
> that if no traffic is
> On Wed, Mar 31, 2021 at 12:12:31AM +, Taylor R Campbell wrote:
>> This is false. If the VM host provided a viornd(4) device then NetBSD
>> would automatically collect, and count, entropy from the host, with no
>> manual intervention.
>
> I would love to see instructions how to do this - I
> Is that file encrypted?
As I understand it, no.
> I think I'd prefer possibly insecure, but difficult to obtain from outside
> like disk drive interrupt timing low order bits than that. Regardless of
> how unproven that method might be.
Do note, the existing randomness sources are still
>> My question is, how can we tell what random sources a system actually
>> has, i.e. is there some flag that cpuctl identify shows when a system
>> has RDRAND/RDSEED?
>
> What about architectures that have nothing like RDRAND/RDSEED? Are
> they, effectively, totally unsupported now?
Nope, not
>> Do note, the existing randomness sources are still being sampled and
>> mixed into the pool, so even if the starting state from the saved
>> entropy may be known (by violating the security of the storage),
>> it's still not possible to predict the complete stream of randomness
>> data once the
>> > No amount of uptime and activity was increasing the entropy in my
>> > system before I patched it.
>>
>> As I understand it, entropy was being contributed. What wasn't
>> happening was the random driver code recognizing and acknowledging that
>> entropy, because it had no way to tell how
>> (gdb) print *cv
>> $1 = {cv_shared = 0x6c652e73, cv_closure = 0x761713184050}
>> (gdb) print *cv->shared
>> There is no member named shared.
>> (gdb) print *cv->cv_shared
>> Cannot access memory at address 0x6c652e73
>> (gdb) print *cv->cv_shared->ci_ops
>> Cannot access memory at address
Hi,
one machine I'm testing NetBSD on feels sort of sluggish, which
is strange because it's got lots of RAM (128GB) and a pair of
Xeon(R) CPU E5-2650 CPUs, for a total of 16 physical cores and 32
with hyperthreading.
It looks like one of the CPUs is using most of its time doing
interrupt
> Try booting with the CD drive disabled (via userconf)
with "disable cd*", basically no change:
stest: {5} vmstat -i
interrupt total rate
TLB shootdown 1693 28
cpu0 timer 5716 95
msix2 vec 0 1465 24
msix6 vec 0 2438 40
ioapic0 pin 21
Hi,
lately I have been dusting off and testing a Cobalt RAQ2 I bought
a while ago. Fan's been replaced (the old one spun only
intermittently and made noises...) It has a
viaide0: VIA Technologies VT82C586 (Apollo VP) ATA33 controller
and an internal 40-pin connector for a normal 3.5" PATA
>> Unfortunately the additional shared library changes require
>> another round of package rebuilds from scratch. Everyone
>> building packages against netbsd-10: please start a new round
>> from scratch.
>
> Does that mean the pkgsrc-2023Q2 binary packages for 10_BETA 2
> that have been
Hi,
I have recently had a bear of a time getting the new rust which
landed in pkgsrc-wip the other day to build natively on several
of the targets we support for NetBSD.
The problem is that the "bootstrap" program (a rust executable)
lands on its nose with a SIGSEGV, and dumps core (without
Hi,
following up on my own message, I finally had the presence of
mind to look at what gdb on armv7 would tell me, if anything,
because that build failed as well.
And... it tells quite a bit more than the other two:
armv7: {2} gdb
> Program terminated with signal SIGSEGV, Segmentation fault.
...
> #0 0x60d0fe74 in _cpuset_isset () from /usr/lib/libc.so.12
> #1 0x03d2bf8c in std::sys::unix::thread::available_parallelism ()
...
> At least it gives a bit of clue about where to go looking for the
> null pointer
>>for i in 0..u64::MAX {
>>match libc::_cpuset_isset(i, set) {
>> [...]
>> but ... under which conditions would it seg-fault inside that
>> function?
>
> What's does the Rust impl. of _cpuset_isset() look like? Does it
> take ints by any
>> All of these applications depends on the "MROUTING" kernel option,
>> it seems, which is mostly default-off, except for a few (tending
>> on the more obscure side) kernel configs. I wonder if anyone
>> knows the history there.
>
> I'm not really sure why MROUTING is default off [...]
Isn't
Well,
following up on my own posting of yesterday evening.
There's good and not so good news: the good news is that my G4
Mac Mini running -current finally managed to build rust-1.62.1
from pkgsrc-current (using llvm from pkgsrc, not the internal
one). The bad news is that I don't have a
Hi,
I'm running NetBSD-current on one of my 1G Mac Mini G4 systems,
doing pkgsrc bulk building.
This go-around I've managed to build llvm, and next up is rust. This
is proving to be difficult -- my system will consistently wedge it's
user-land (still responding to ping, no response on the
>> I tried going into libexec/ld.elf_so and running "make
>> install" but that didn't work or even come close.
>
> It would be something like:
>
> cd src/libexec/ld.elf_so
> ${TOOLDIR}/bin/nbmake-${arch} dependall
> ${TOOLDIR}/bin/nbmake-${arch} install
and if the tool nbmake
>> As always before such an operation, "do the kernel first".
>
> How do you do the kernel first without building the userland to
> build the updated tools?
The "do the kernel first" is sort of a "general warning".
Whether it is strictly needed depends on what version user-land
and what version
>> Indeed, this (without -O) works. The key is the HOST_CFLAGS
>> variable; I was thinking of just CFLAGS at first.
>
> I have had some luck with compiling old systems with -V
> HOST_CFLAGS=-fcommon.
>
> That only goes so far into the past, however. I thought the
> next step would be to try
>> It might be better to use corresponding older tools to build older
>> kernels. Modern gcc switched to -fno-common by default, so if you
>> want to compile an older kernel that has multiple variable definitions
>> you will need to arrange for -fcommon option to be used.
>
> Is there any way to
Hi,
a user contacted me about having a freshly installed version of
NetBSD-current for amd64 built with clang, and a failure to run
the provided "bootstrap kit" for rust, with the following error:
/usr/lib/libgcc_s.so.1: version GCC_3.3 required by
Hi,
I recently had reason to install NetBSD on a new (to me) server.
This server had previously ran Linux/Debian with a software RAID
setup over two drives.
The dmesg of the server is visible at
https://dmesgd.nycbug.org/index.cgi?do=view=7403
I wanted to continue to use software RAID with
Hi,
over the last couple of months I have seen at least two non-C
(rust and python) implementations of syslog() equivalent
functionality causing applications written in those languages to
become brittle.
The reason, I hear you ask?
In C, the return type of syslog() is void, so it can't return
> dependall ===> lib/../external/mpl/bind/lib/libdns
> create libdns/gssapictx.d
> /u/NetBSD/src.ks/external/mpl/bind/lib/libdns/../../dist/lib/dns/gssapictx.c:24:10:
> fatal error: gssapi/gssapi.h: No such file or directory
>24 | #include
> | ^
>
60 matches
Mail list logo
