On Mon, Aug 05, 2019 at 10:46:13AM +, ng0 wrote:
> Hi,
>
> I have a problem with a regression in my Google Summer of Code project
> which seems to only affect NetBSD in my last testing. The code can be
> found at https://git.gnunet.org/libmicrohttpd.git/log/?h=dev/ng0/gsoc2019
> or git cloned
On Thu, Aug 15, 2019 at 04:52:09PM +0100, Arthur Barlow wrote:
> I have some uncertainty about the application of the "-u" flag in
> build.sh. The docs say it prevents "make clean." But without it will
> rebuild everything, including tools. I've used the flag before
> without problems, but recen
Something bad happened to rump network tests, they are all broken
in -current, failing with cryptic messages like:
$target$reqs != $target$rels (llentrypl5 != llentrypl2)
Anyone have an idea what caused this? Can someone make the message ... better?
Martin
On Mon, Aug 19, 2019 at 03:06:37PM +0200, Martin Husemann wrote:
> Something bad happened to rump network tests, they are all broken
> in -current, failing with cryptic messages like:
>
> $target$reqs != $target$rels (llentrypl5 != llentrypl2)
>
> Anyone have an idea wha
On Fri, Aug 23, 2019 at 06:13:30PM +, John Klos wrote:
> How are people supposed to set the block and fragment sizes in the NetBSD
> installer? If it's still possible, it certainly isn't easy to find.
Is it usefull anywhere?
I removed it, thinking noone would care. If there is use for it, I'l
On Fri, Aug 23, 2019 at 07:30:33PM +0100, Robert Swindells wrote:
> >But is it really needed?
>
> Someone using a disk with 4k blocks might want to set the fragment size
> to that and the block size to a multiple.
If we *have* to set that manually, something is wrong.
Besides, only disklabel pro
On Sat, Aug 24, 2019 at 07:56:16AM +0700, Robert Elz wrote:
> | Besides, only disklabel provides storage for this data,
>
> Huh? What is being discussed here? I assumed it was the makefs
> parameters that get used (and yes, two of those do get inserted in
> the a bsd disklabel, though I have
On Mon, Aug 26, 2019 at 03:13:29AM +, NetBSD Test Fixture wrote:
> This is an automatically generated notice of new failures of the
> NetBSD test suite.
>
> The newly failing test cases are:
>
> net/if_ipsec/t_ipsec_pfil:ipsecif_pfil_esp_null
> net/if_ipsec/t_ipsec_pfil:ipsecif_pfil_e
On Mon, Aug 26, 2019 at 11:03:06AM +0200, Martin Husemann wrote:
> This also broke the build for aarch64, hppa and sun2.
>
> 10:49 i think the problem is that we'll have to make it -lnpf -lnv
> 10:50 with the private library objdir added to the -L path or simil
On Mon, Sep 16, 2019 at 02:46:53PM +0300, Andreas Gustafsson wrote:
> On i386, MKZFS is not defined even though mk.conf(5) says it is.
> Which one is wrong, the code or the manpage?
The man page is wrong, MKZFS does not make sense on anything with a 32bit
kernel.
Martin
On Thu, Sep 19, 2019 at 12:25:11PM +1000, Paul Ripke wrote:
> Looks like the following patch is needed? A quick grep shows a bunch
> more instances - but I'm not sure how common this arrangement is
> outside of arm.
>
> diff --git a/sys/stand/efiboot/bootarm/Makefile
> b/sys/stand/efiboot/bootarm
On Thu, Sep 19, 2019 at 04:27:44PM +0100, Patrick Welche wrote:
> I'm pretty sure gdb used to pick up symbols automatically, but now I see
> on a fresh -current/amd64 box (with a nod to PR/38185):
>
> $ gdb `which calendar`
> GNU gdb (GDB) 8.3
> ...
> Reading symbols from /usr/bin/calendar...
> (N
On Fri, Sep 20, 2019 at 11:24:53AM +0100, Patrick Welche wrote:
> > I'll do a MKUPDATE=no build...
>
> It seems that MKUPDATE=yes and MKDEBUG=yes don't do what one might
> hope for...
It works fine if you started with a MKDEBUG=yes build, but it will not
properly create debug info for things that
On Mon, Sep 23, 2019 at 03:30:42PM +0100, Patrick Welche wrote:
> This morning, I updated the kernels of 2 -current/amd64 boxen to today's HEAD.
>
> One no longer goes multiuser. ls, /rescue/ls, /rescue/mount, /rescue/ps
> all claim "Bad syscall". cat is OK. Guessed libutil, but popping in new
> m
On Mon, Sep 30, 2019 at 06:33:04AM -0700, Paul Goyette wrote:
> If not already done, this should probably be added to src/UPDATING
This is a very generic advice that applies to all updates, and that
file is mostly for documenting special update build issues, so I am not
sure it is worth an entry f
On Mon, Sep 30, 2019 at 11:40:26AM -0500, John D. Baker wrote:
> As I build everything with MKDEBUG=yes MKDEBUG_LIB=yes. recent updates
> to the netbsd-9 branch cause build breakage. E.g., on i386 and sparc:
>>
> == 1 missing files in DESTDIR
> Files in flist but missing from DESTD
On Mon, Oct 21, 2019 at 11:54:44AM +0200, J. Hannken-Illjes wrote:
> Somewhere between Netbsd-8 and NetBSD-9 "tar" changed its behaviour
> when it has to extract a directory and the path exists as a symlink.
I still believe it should be fixed, but Jörg disagrees. You need to use -P
now. See PR 544
On Tue, Oct 22, 2019 at 06:37:44AM +0700, Robert Elz wrote:
> Date:Mon, 21 Oct 2019 21:20:25 +0200
> From:Joerg Sonnenberger
> Message-ID: <20191021192025.ga33...@bec.de>
>
> | That said, I don't really see a point in
> | allowing one form of arbitrary file replac
On Wed, Oct 23, 2019 at 11:47:39AM +0200, K. Schreiner wrote:
> with current source cvs upped an hour or so ago:
Are you sure? Doing a clean build?
The previous auto build failed the same way you noted, but the current
run seems to have worked (so I guess it has been fixed in between).
Martin
On Thu, Oct 24, 2019 at 06:56:57AM +0700, Robert Elz wrote:
> Date:Wed, 23 Oct 2019 23:30:47 +0200
> From:Joerg Sonnenberger
> Message-ID: <20191023213047.ga73...@bec.de>
>
> | (1) Abuse of symlinks to shuffle the tree somewhere else. IMO whoever
> | wants to do t
On Thu, Oct 24, 2019 at 10:17:17PM +0300, Valery Ushakov wrote:
> On Thu, Oct 24, 2019 at 05:26:41 +0200, Martin Husemann wrote:
>
> > Deal with this properly in sysinst would mean:
> >
> > 1) run a script like:
> > rm -f /tmp/list
> > for s in *.${suffix}
On Thu, Oct 31, 2019 at 09:00:53AM +0100, Anders Magnusson wrote:
> Here are the results, using gcc as the compiler:
>
> bison:
> nbi386:/home/ragge/pcc/cc/ccom >size cgram.o
> text data bss dec hex filename
> 25637 0 0 25637 6425 cgram.o
>
> yacc:
> nbi386:/h
On Sun, Nov 03, 2019 at 01:33:42PM -0600, Robert Nestor wrote:
> My system has multiple disks which allow me to install various versions of
> NetBSD. The disks are large and the system supports EFI, so for some time
> I?ve been doing installations with GPT wedges and using either BIOS or EFI
>
On Mon, Nov 04, 2019 at 08:52:31PM +0200, Yorick Hardy wrote:
> This might be more pango fallout:
>
> https://blogs.gnome.org/mclasen/2019/05/25/pango-future-directions/
>
> "Using Harfbuzz for font loading means that we will lose support
> for bitmap and type1 fonts. We think this is an accep
Not seen this locally, but that would be the switch to bsd/libarchive tar.
Maybe it does not unlink files before extraction and replaces them in-space?
I do the same kind of updates, but usually on a very quiet system.
The crashes you see are from other running processes? Joerg would likely
say:
On Tue, Mar 26, 2019 at 10:51:35AM +0200, Leonid Bobrov wrote:
> Hi, dear NetBSD and OpenBSD communities.
>
> I need to work with wscons, but I don't want to guess by examples
> how to work with it, can you please provide documentation for its
> API?
Please avoid such cross-postings. Also you did
On Wed, Dec 04, 2019 at 10:20:28PM +, Sevan Janiyan wrote:
> Hello,
> I've set the boot loader to load the pciverbose module by default via
> boot.cfg, this will result in a slightly different dmesg output (more
> info about devices)
... in new installations. This change will not affect existi
On Thu, Dec 05, 2019 at 11:06:48PM +, Sevan Janiyan wrote:
> Nevermind, pciverbose option has been enabled in the amd64 & i386
> GENERIC kernel configs instead.
Why?
Martin
Here is a simple recipe to reproduce the massive test lossage in -current:
cd /usr/tests/dev/raidframe && atf-run
In the output you will find:
tp-start: 1575709106.330783, t_raid, 7
tc-start: 1575709106.330864, old_numrows_config
tc-so:Executing command [ rump_server -lrumpvfs -lrumpdev
Here is gdb output from the rump_server core:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 rumpuser_mutex_spin_p (mtx=0x0)
at /work/src/lib/librumpuser/rumpuser_pth.c:166
166 /work/src/lib/librumpuser/rumpuser_pth.c: No such file or directory.
[Current thread is 1 (proce
On Sat, Dec 07, 2019 at 02:56:25PM +, Taylor R Campbell wrote:
> OOPS -- rmind removed pserialize_init from rump_init, so the mutex
> never got initialized. Fixed in rump.c 1.337!
ACK, test failures down to normal level.
Martin
On Wed, Dec 11, 2019 at 01:28:31PM -0500, Ron Georgia wrote:
> I installed NetBSD 9.0_RC1 as a guest on VirtualBox 5.2.34 r133883 with
> GhostBSD as a host. I enabled EFI and booted from the iso image. I did
> follow the "instructions" on creating a gpt partition for efi
I guess you followed the w
On Wed, Dec 11, 2019 at 01:34:27PM -0500, Ron Georgia wrote:
> Thanks for responding Martin. Actually I did both. Selecting GPT did set
> things up but it does not boot.
OK, it worked for me when I tried last (but that is a bit ago).
Does the UEFI offer the installed drive as a bootable target?
H
On Wed, Dec 11, 2019 at 10:30:44PM +, Chavdar Ivanov wrote:
> in efi with gpt; it performs the installation lege artis, but then the
> boot fails - the efi file tries and fails to find netbsd, nebsd.gz,
> onetbsd etc...
That sounds like a regression in bootx64.efi, checking
Martin
On Thu, Dec 12, 2019 at 07:54:08AM +0100, Martin Husemann wrote:
> On Wed, Dec 11, 2019 at 10:30:44PM +, Chavdar Ivanov wrote:
> > in efi with gpt; it performs the installation lege artis, but then the
> > boot fails - the efi file tries and fails to find netbsd, nebsd.gz,
On Thu, Dec 12, 2019 at 09:10:57AM +0100, Emmanuel Dreyfus wrote:
> Martin Husemann wrote:
>
> > Emmanuel, could you please have a look?
>
> I do not reproduce that one. Can you share the exact commands to build
> the testbed?
This one had been created manually and wo
On Thu, Dec 12, 2019 at 03:10:41PM +0100, Matthias Petermann wrote:
> The installation process with sysinst runs fine. Anyway, after reboot there
> seems to be no boot loader installed.
It would be interesting to see more details at this stage:
- how does it fail exactly
- what does "gpt show -a
On Thu, Dec 12, 2019 at 03:11:38PM +0100, Adam wrote:
> I have to set USE_XZ_SETS=no, remove "distrib" from objdir, re-build,
> then re-building again with USE_XZ_SETS=yes works fine.
Not sure I understood correctly, but doing update builds (build.sh -u)
when switching build options sounds like a
On Thu, Dec 12, 2019 at 09:24:09PM +, Chavdar Ivanov wrote:
> Today's -current has a proble installing in gpt mode - it claims not
> to be able to determine the geometry of the disk and does not give an
> option to format it in gpt mode at all.
I think I fixed the "no gpt mode" an hour ago or
On Fri, Dec 13, 2019 at 07:23:20AM +0100, Adam wrote:
> That was a clean build, but, yes, with MKUPDATE=yes.
Sorry, but I still do not get it. A clean build did not work, but then
cleaning and rebuilding did work?
The auto build cluster does clean builds and uses .tar.xz for some
architectures,
On Fri, Dec 13, 2019 at 03:26:07AM +0100, Emmanuel Dreyfus wrote:
> I still cannot reproduce it. I installed a VM from
> http://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-9/latest/images/NetBSD-9.0_RC1-a
> md64-uefi-install.img.gz
>
> It does not suggests creating an EFI partition.
Did you boot it
On Mon, Dec 16, 2019 at 08:52:29AM +, Emmanuel Dreyfus wrote:
> The attached patch fixes the bug by avoid using NAME= when there
> is no label. Once applied, rebuild src/sts/arch/i386/stand and
> install updated bootstrap.
This makes my old installation boot again!
Please commit + request pul
On Mon, Dec 16, 2019 at 12:50:39PM +, Emmanuel Dreyfus wrote:
> I thought about it, but requiring the user to enter an UUID to boot
> seems harsh.
Yes, but as a fallback it is good (and sometimes you have "serial console"
and working copy & paste - though with modern server management this se
On Tue, Dec 17, 2019 at 11:33:09AM +, Arthur Barlow wrote:
> I recently built the latest Current for amd64, (9.99.25), and I included
> the xsrc code with the build. I use ./build.sh -O ../obj -T ../tools -x
> distribution and then ./build.sh -O ../obj -T ../tools -x install=/ after
> building
On Wed, Dec 18, 2019 at 09:41:45AM +0100, Manuel Bouyer wrote:
> kernel diagnostic assertion "pg->offset >= nextoff" failed: file
> "/home/source/ab/HEAD/src/sys/miscfs/genfs/genfs_io.c", line 972
We see that on various architectures. Andrew, any news on that?
Martin
On Sun, Dec 29, 2019 at 08:42:36PM +, David Brownlee wrote:
> What is the current wisdom on printing from Firefox?
>
> It appears that from firefox-60 the ability to generale ps was
> removed, so the lpd backend was also removed.
It still works fine for me in firefox 70, but I compile with
On Sun, Jan 05, 2020 at 05:34:51AM -0800, Paul Goyette wrote:
> I see that we have an XZ_ARGS variable which we can force to define
> with ``-V XZ_ARGS=-T6'' and that appears that it will add the "-T6"
> argument when invoking xz to build sets.
... which won't help as the tools xz version is not t
On Tue, Feb 07, 2017 at 03:02:57PM +0900, Rin Okuyama wrote:
> How about dropping Apple and byte-swapped UFS support from fsck_ffs and
> newfs? Both seem to be useless for atari (is it right?). This reduces
> about 10KB from instbin, and the resulting filesystem successfully fits
> within 1.4MB.
I
On Fri, Feb 24, 2017 at 09:54:02AM -0300, Mandacarú Cascavel wrote:
> Everything worked well till NetBSD 7.99.60. From this version onwards
> sysinst produces a black screen. Updating the system from an iso-image
> presents no problem.
What architecture? Or please give a pointer to a concret inst
On Fri, Feb 24, 2017 at 02:03:06PM +0100, Martin Husemann wrote:
>
> What architecture? Or please give a pointer to a concret install kernal
> that you are testing.
Sorry, that information was there already - I can reproduce it on
real hardware!
Martin
On Fri, Feb 24, 2017 at 02:09:37PM +0100, Martin Husemann wrote:
> On Fri, Feb 24, 2017 at 02:03:06PM +0100, Martin Husemann wrote:
> >
> > What architecture? Or please give a pointer to a concret install kernal
> > that you are testing.
>
> Sorry, that informatio
On Mon, Feb 27, 2017 at 08:29:10PM +0200, Yorick Hardy wrote:
> Is anyone else experiencing GPU hangs since revision 1.14
> of src/sys/external/bsd/drm2/pci/drm_pci.c ?
Thanks for the hint, I'm testing if it is the cause for
http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=51997
and wi
On Mon, Feb 27, 2017 at 07:39:49PM +0100, Martin Husemann wrote:
> On Mon, Feb 27, 2017 at 08:29:10PM +0200, Yorick Hardy wrote:
> > Is anyone else experiencing GPU hangs since revision 1.14
> > of src/sys/external/bsd/drm2/pci/drm_pci.c ?
>
> Thanks for the hint, I'm
On Wed, Mar 01, 2017 at 01:30:50PM +0900, Kimihiro Nonaka wrote:
> Hi,
>
> 2017-03-01 3:21 GMT+09:00 Yorick Hardy :
>
> > It is not obvious to me why the MSI changes were problematic.
> > Do you have any ideas what went wrong?
>
> It seem necessary to implement pci_enable_msi() and pci_disable_m
On Wed, Mar 01, 2017 at 06:55:24PM +0900, Kimihiro Nonaka wrote:
> Updated the patch.
Still works fine for me!
Martin
On Fri, Mar 17, 2017 at 04:44:08PM +0100, Tom Ivar Helbekkmo wrote:
> Yup. It's adjusting the columns based on the max length of the first
> field. What the heck am I not seeing?
Yes, it does that for -ie[v], the printf's you listed are guarded by
if (type == EVCNT_TYPE_ANY)
Martin
On Thu, Mar 23, 2017 at 04:01:04PM +0800, Paul Goyette wrote:
> Perhaps there is a more appropriate sequence for startup? Should the vpn be
> created first?
I would suggest some syntax to mark interfaces as optional in the npf
configuration, and then npfd (or npf in-kernel, not sure) to watch ou
On Sat, Apr 01, 2017 at 05:31:20PM +1100, Geoff Wing wrote:
> The system installed as an old MBR (+63 sector) system.
> It did not add any dk stuff for /etc/fstab.
> It did NOT leave room to add the dk stuff at the start of the hard drive, so
> you cannot do "dkscan_bsdlabel" stuff on it and ad
On Sat, Apr 01, 2017 at 10:14:02PM +1100, Geoff Wing wrote:
> I'm not sure what you mean here. I presume you understand the purpose
> of dkscan_bsdlabel(8).
Yes (I think I created the userland version of it back then).
> I also presume you understand the commented out
> DKWEDGE_METHOD_* stuff.
See also PR 52000, though I haven't verified if that change is actually
causing it.
Martin
[Updating from 5 to 6 and then 7 ends up with libdrm.so from 6]
The definitive answer should be in the set lists, see below for various
branches:
src-5/distrib/sets/lists/xbase/shl.mi:./usr/X11R7/lib/libdrm.so.2.4
src-6-0/distrib/sets/lists/xbase/shl.mi:./usr/X11R7/lib/libdrm.so.3.2
src-6-1/dist
On Wed, May 24, 2017 at 04:59:58PM +0200, Christian Groessler wrote:
> making sure the compat library is up to date...
> make[1]: cannot open ../../../../../../compat/common/Makefile.
Do you have a full source tree? Why is it not finding that file relative
to your compile dir?
Martin
On Fri, May 26, 2017 at 11:11:21AM +0200, Christian Groessler wrote:
> Is there some default, that if /usr/obj exists, it's automatically used?
The exact rules for auto-guessing the objdir are complex (and I always
forget the details); it depends on /etc/mk.conf and your environment.
Mixing objdir
On Tue, Jun 06, 2017 at 07:32:20PM +0200, Thomas Klausner wrote:
> Mutex error: mutex_vector_exit,720: exiting unheld spin mutex
>
> lock address : 0xfe882ef8d0b8
> current cpu : 6
> current lwp : 0xfe881c147a40
> owner field : 0x0600 wait/spin: 0/1
This is
On Fri, Jun 30, 2017 at 04:55:40PM +0100, Patrick Welche wrote:
> On Fri, Jun 30, 2017 at 03:41:39PM +, m...@netbsd.org wrote:
> > On Fri, Jun 30, 2017 at 09:25:19AM +0100, Patrick Welche wrote:
> > > I'm happily running -current on a Ryzen 7 1700 / Asus PRIME X370-PRO.
> > > I wonder about its
On Sat, Jul 22, 2017 at 09:08:28PM +0200, Thomas Klausner wrote:
> Hi!
>
> With 8.99.1/amd64/20170721 I see a new problem building audio/musicpd:
>
> --- src/output/plugins/liboutput_plugins_a-AoOutputPlugin.o ---
> src/output/plugins/AoOutputPlugin.cxx:232:2: internal compiler error:
> Segmenta
On Sun, Jul 23, 2017 at 10:20:50PM -0500, John D. Baker wrote:
> Anyone else using a Soekris box with netbsd-8 or -current and 'dhcpcd'
> for acquiring the public IP from their ISP? Seeing long delays?
Can you show the ifconfig output while it tries to acquire the address?
Martin
On Fri, Aug 04, 2017 at 05:37:26PM +0900, Masanobu SAITOH wrote:
> Making sysinst UEFI friendly is important. Could someone
> do by 8.0-RELEASE?
Yes, I'm trying to get my patches for GPT handling in and will verify
UEFI installation with that.
Martin
On Sat, Aug 19, 2017 at 01:51:26PM +1000, Paul Ripke wrote:
> Remember, this config was working with netbsd-7. I had -maproot=root in
> exports, and just tried -maproot=0:0 with no change. Something appears
> to have changed somewhere (nfs client? inode lookups? console handling?)
> that appears to
In -current all(?) NFS tests started failing:
nfs_extendfile: [0.396107s] Failed: child died
nfs_extendfile_append: [0.420483s] Failed: child died
nfs_holywrite: [0.370887s] Failed: child died
nfs_overwrite512: [0.407758s] Failed: child died
nfs_overwrite64k: [0.381165s] Failed
On Mon, Aug 21, 2017 at 05:07:41PM +0200, Martin Husemann wrote:
> In -current all(?) NFS tests started failing:
>
> nfs_extendfile: [0.396107s] Failed: child died
> nfs_extendfile_append: [0.420483s] Failed: child died
> nfs_holywrite: [0.370887s] Fai
On Mon, Aug 21, 2017 at 05:18:22PM +0200, Martin Husemann wrote:
> rumpnfsd: another rpcbind is already running. Aborting.
Christos fixed it, nothing wrong with NFS in general, just the updated
rpcbind not cooperating well with the RUMP test environment (while the host
machine was already runn
On Tue, Aug 22, 2017 at 11:13:11AM +, Chavdar Ivanov wrote:
> Is this so at the moment? Anyone having the same?
mail.* seems to work ;-)
www works for me too.
Martin
If you are using NetBSD 8 BETA already, and are not updating from the
official "daily" builds, please note:
- The gcc internal specs have changed (rules for libgcc when building
shared binaries). This change requires a full build of ALL binaries
ever created with gcc 5.4.
- Failure to do
On Sat, Sep 02, 2017 at 03:47:09AM +, Thomas Mueller wrote:
> Does this also apply to NetBSD-current?
>
> When did the changes happen? My last update on i386 was Aug 30 (but amd64
> was last updated Jun 20):
There were various changes, but I think the last one that better be followed
by a c
On Sun, Oct 01, 2017 at 07:03:04AM -0400, Gary Duzan wrote:
>Can the pthread_attr fix for rust mentioned in
> http://mail-index.netbsd.org/pkgsrc-users/2017/08/03/msg025409.html
> be pulled up to netbsd-8? I'm getting the same thing there, and
> rust is required for the latest firefox.
I just
On Tue, Oct 10, 2017 at 03:03:22AM +, Thomas Mueller wrote:
> Is it currently possible to boot newer versions of NetBSD in UEFI mode?
-8 and -current should work, but the installer has not yet been updated
to reflect it.
> How would the boot/load code know where to find the root partition to
On Sat, Oct 14, 2017 at 03:23:05PM -0500, John D. Baker wrote:
> I was more drastic and nuked all of "src/external/gpl2/groff" and
> updated again.
That (plus the obj cleaning you did before) made it work for me as
well - this is since Joerg's commit to remove the rebuild rules for
generated and c
On Sat, Oct 21, 2017 at 07:11:38PM +0200, Frank Kardel wrote:
> Manual transcription:
> >> NetBSD/x86 EFI Bott (x86), Revision 1.0 (..) (from NetBSD 8.0_BETA)
> >> Memory: 252/1971496 k
> Press...
> booting hd0a:netbsd - starting in 0 seconds
> open betbsd: bad partition
It would probably help to
On Thu, Oct 26, 2017 at 11:02:13AM +0700, Robert Elz wrote:
> errno = 0;
> t = mktime(&tms);
> ATF_REQUIRE_ERRNO(0, t != (time_t)-1);
I guess the author meant to write:
errno = 0;
t = mktime(&tms);
ATF_REQUIRE(errno == 0;
ATF_REQUIRE(t != (t
On Sat, Nov 04, 2017 at 05:20:38AM +0800, Paul Goyette wrote:
> /build/netbsd-local/src_ro/lib/librump/../../sys/rump/../arch/arm/arm32/kobj_machdep.c:
> In function 'kobj_reloc':
> /build/netbsd-local/src_ro/lib/librump/../../sys/rump/../arch/arm/arm32/kobj_machdep.c:103:39:
> error: passing arg
On Thu, Nov 09, 2017 at 11:36:47PM +, Stefan Hertenberger wrote:
> Since some time i get a lot of dmesg spam
>
> ...
> ahcisata0 port 1: active 2 is 0x4001 tfd 0x2051
> ahcisata0 port 1: active 2 is 0x4001 tfd 0x2051
> ahcisata0 port 1: active 2 is 0x4001 tfd 0x2051
> ahcisata0 por
On Fri, Nov 10, 2017 at 10:11:43AM +0100, stefan@hertenberger.bayern wrote:
> Am 2017-11-10 09:57, schrieb Martin Husemann:
> > Can you show the dmesg part describing your ahcisata devices?
>
> ahcisata0 at pci0 dev 31 function 2: vendor 8086 product 1c03 (rev. 0x04)
> ahcisata
On Fri, Nov 10, 2017 at 02:11:12PM +0100, Jaromír Dole?ek wrote:
> The TFD 0x2051 corresponds to Media Changed error, with DRDY/ERR status
> bits. Is it possible this message appears every time you change media in
> the cd0?
>
> Alternatively, I imagine this could be generated if the drive is setu
On Tue, Nov 14, 2017 at 01:58:54PM +, NetBSD Test Fixture wrote:
> This is an automatically generated notice of new failures of the
> NetBSD test suite.
>
> The newly failing test cases are:
This was fallout fromt the gcc import, it should be fixed now.
Martin
On Thu, Nov 16, 2017 at 11:09:29AM +0100, Riccardo Mottola wrote:
> However, now I cannot compile programs, linking fails. I get this issue:
>
> ld: /usr/libexec/liblto_plugin.so: error loading plugin:
> /usr/libexec/liblto_plugin.so: Undefined PLT symbol "xasprintf" (symnum =
> 123)
You picked a
On Wed, Nov 22, 2017 at 12:28:03PM -0500, Derrick Lobo wrote:
> Hi SAITOH Masanobu
>
> > I sent a new pullup request:
> > http://releng.netbsd.org/cgi-bin/req-8.cgi?show=361
> >It's little hard to fix that problem with small patch. I'm going to send a
> >jumbo patch for ixg(4) to fix a lot o
On Fri, Dec 22, 2017 at 11:57:27AM +0200, Andreas Gustafsson wrote:
> Kamil Rytarowski wrote:
> > I've disabled suspend1 and suspend2.
>
> Thank you. The tests are now running to completion again.
There are > 100 new ptrace test failures in my runs though...
Martin
On Sat, Dec 23, 2017 at 02:08:54PM +0100, Thomas Klausner wrote:
> Hi!
>
> After updating to 8.99.9 I've experienced strange hangs. The keyboard
> and mouse don't work any longer, and it doesn't react to the power
> button, so I have to reset.
>
> >From earlier releases I had similar behaviour in
On Fri, Dec 22, 2017 at 12:10:47PM +0100, Martin Husemann wrote:
> On Fri, Dec 22, 2017 at 11:57:27AM +0200, Andreas Gustafsson wrote:
> > Kamil Rytarowski wrote:
> > > I've disabled suspend1 and suspend2.
> >
> > Thank you. The tests are now running to complet
On Sun, Dec 24, 2017 at 03:37:51PM +0100, Martin Husemann wrote:
> We are down to:
>
> Failed test cases:
> lib/libc/sys/t_ptrace_wait:signal3, lib/libc/sys/t_ptrace_wait3:signal3,
> lib/libc/sys/t_ptrace_wait4:signal3, lib/libc/sys/t_ptrace_wait6:signal3,
On Tue, Dec 26, 2017 at 08:43:51PM +0100, Tom Ivar Helbekkmo wrote:
> Christos Zoulas writes:
>
> > You need to make cleandir in libc and rebuild.
>
> I thought that was what a full build without "-u" did, but it obviously
> isn't.
That is what I thought too, but since the files are completely
On Tue, Dec 26, 2017 at 02:35:45PM -0500, Christos Zoulas wrote:
> So now it is really only one test case "signal3".
Yes.
> How about this (restoring the test to what it was before):
>
> -#if defined(__sparc__)
> +#if defined(__sparc__) && !defined(__sparc64__)
> atf_tc_expect_timeout("
On Wed, Dec 27, 2017 at 02:27:14PM +0100, Kamil Rytarowski wrote:
> There were recently changes for golang and signal handling there.. it
> looks to me that they affected stability of this test.
It is not about stability, it very consistently fails for me.
> I'm still focused on LLVM bits, so I r
On Wed, Dec 27, 2017 at 08:42:52AM -0500, Christos Zoulas wrote:
> Well, it is not failing on sparc64, that's the issue.
It is not expected to fail, but it is failing. The tracer process waits
for the child but the child does not exit - maybe the PT_CONTINUE did
not work or whatever.
Martin
On Wed, Dec 27, 2017 at 02:51:49PM +0100, Kamil Rytarowski wrote:
> This test used to be broken in the past, there are various new other
> problems (like emitting SIGSTOP instead of SIGTRAP).
I get SIGILL on arm, but the fix is pretty obvious, waiting for a test build
to check.
Martin
On Wed, Dec 27, 2017 at 02:51:38PM +0100, Martin Husemann wrote:
> On Wed, Dec 27, 2017 at 08:42:52AM -0500, Christos Zoulas wrote:
> > Well, it is not failing on sparc64, that's the issue.
>
> It is not expected to fail, but it is failing. The tracer process waits
> for
On Wed, Dec 27, 2017 at 07:53:50PM +0100, Martin Husemann wrote:
> I must be missing something, or the test works on alpha and x86 due to a
> bug, but correctly fails on other architectures.
The same difference can be seen very simply by running the attached
program under gdb:
(gdb) run
St
On Wed, Dec 27, 2017 at 08:17:46PM +0100, Kamil Rytarowski wrote:
> The breakpoint behavior is MD specific. On x86 we execute the
> instruction first and next report it in case of software breakpoint
> (int3). On sparc we need to manually ADVANCE the Instruction Pointer.
>
> We have a dedicated ma
On Wed, Dec 27, 2017 at 08:33:48PM +0100, Kamil Rytarowski wrote:
> This is not a x86 bug.
>
> It's an idiom in x86 to:
> - write software breakpoint
> - execute instruction (& move EIP/RIP)
> - detect trap
> - report to debugger
> - rewind IP
> - write original code
> - [offer prompt to a
601 - 700 of 740 matches
Mail list logo
