ens then ?
>
> No change. It attaches dwiic0 and then starts with the messages.
It could also be some sensors I guess. Any chance to see what attaches
at dwiic0 ? Maybe entering ddb before the console gets spammed ?
FWIW I have a laptop with the touchpad as ihidev@dwiic and it works
fine with RC6
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
6 i386PAE.
> So it might be time to drop the 'experimental' label if people are
> generally succeeding.
Sure; I've been using anita+xen for almost 4 months now, the results are
there:
http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
hello,
recent test runs have been failing on UDF filesystem tests with:
mount failed: Invalid argument
see http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/HEAD/
for details.
Any idea ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Mon, Jul 01, 2013 at 12:01:01PM +0200, Martin Husemann wrote:
> On Mon, Jul 01, 2013 at 10:09:38AM +0200, Manuel Bouyer wrote:
> > hello,
> > recent test runs have been failing on UDF filesystem tests with:
> > mount failed: Invalid argument
>
> The tests have been
s (ohci, ehci and uhci).
hopefully you'll there have a working keyboard in PS/2 compat mode.
Then when the kernel asks for init path, try /rescue/init
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
etbsd:atabusconfig_thread+0x29a
>
> "drive 0 not present", yet "port 1: device present" ?
looks like a simple reverted condition, can you try the attached patch ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
Index: siisata.c
==
On Thu, Aug 08, 2013 at 06:35:05PM +0100, Patrick Welche wrote:
> On Thu, Aug 08, 2013 at 07:06:31PM +0200, Manuel Bouyer wrote:
> > > "drive 0 not present", yet "port 1: device present" ?
> >
> > looks like a simple reverted condition, can yo
2580)
what does fdisk says about this disk ?
also, why is it called wd4 ? are there other drives in the system ?
Are you sure the BIOS disk you boot from matches this one ?
Another reason why /boot may not be found is that you used the wrong
first-stage boot sector: bootxx_ffsv2 with a ffsv1 filesystem or
vice-versa.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
r WDCTL_RST to clear and
it didn't clear).
It's either a dying disk or a cabling issue.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
large number of drives in the box it could also be a power
supply issue.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
> mount /
> cd dev
> ./MAKEDEV
fsck -p /
mount /
umount -f /dev
cd dev
./MAKEDEV
is more likely to work. If /dev is empty on disk, fsck and mount won't work.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Sat, Nov 23, 2013 at 10:27:25AM +0100, Lars Heidieker wrote:
> That's most likely PR/48372 it's fixed in current and needs pull up to
> the netbsd-6 branches.
Can you please send the pullup request ?
thanks
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
y to apply when running
> NetBSD(-current)?
Yes, it's in the source code: src/sys/dev/usb/usb_quirks.*
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
) kernel, that address is xen_timer_handler()
> and from a quick glance through the code, I suspect that it is saying that
> some callout handler is busted...
Yes, is has been there for a long time, but we failed to find where is
problem is exactly.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Mon, Dec 02, 2013 at 08:09:06PM +0700, Robert Elz wrote:
> Date:Mon, 2 Dec 2013 12:29:13 +0100
> From: Manuel Bouyer
> Message-ID: <20131202112913.ga...@asim.lip6.fr>
>
> | > But, the xendomains script has "REQUIRE: xend" in it ?
On Tue, Dec 03, 2013 at 08:55:06AM +0700, Robert Elz wrote:
> Date:Mon, 2 Dec 2013 12:29:13 +0100
> From: Manuel Bouyer
> Message-ID: <20131202112913.ga...@asim.lip6.fr>
>
> | > evtchn_do_event: handler 0x801f9c7f didn't l
On Tue, Dec 03, 2013 at 08:03:21PM +0700, Robert Elz wrote:
> Date:Tue, 3 Dec 2013 13:04:30 +0100
> From: Manuel Bouyer
> Message-ID: <20131203120430.ga26...@asim.lip6.fr>
>
> | I think what happens is:
> | - the kernel is running in a c
he ifconfig.vlan0 and ifconfig.bridge1 (in my
> case) files, and the order then becomes something that will work for me.
I like the idea ! I have the same issue on various systems, which I
solve using auto_ifconfig=NO and net_interfaces="...".
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
se has seen these recently?
> Do these messages indicate a failing cd drive? Or a failing
> controller card?
This message is when the adapter reports a "Interface fatal error".
What's strange is that the SATA error register is empty, so I wonder
if the adapter isn't jus
at is netstat -m and vmstat -m, to see if there
are mbuf allocation failures.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Fri, Dec 27, 2013 at 07:07:51PM -0800, Paul Goyette wrote:
> On Wed, 25 Dec 2013, Manuel Bouyer wrote:
>
> >On Tue, Dec 24, 2013 at 07:02:47PM -0800, Paul Goyette wrote:
> >>[...]
> >>Since the machine that hangs is my primary machine, I haven't yet
> >
n brocken in Xen by a security-related change.
> I'm assuming the DOM0 is Linux,
> so if there is a DOM0 bug I would need more detail about it to try
> to get it addressed by the hosting folks.
This has been fixed upstream, but I'm not sure the fix is in a released
version yet.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
ll these random connections coming from? And
> why would they ever have been ESTABLISHED in the first place?
Do you have some p2p tool running ? I'm seeing similar connections here,
and my best guess is that they're from rtorrent
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
I think I just fixed this.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
yscall+0x83
--- syscall (number 410) ---
bb6bdda7:
cpu3: End traceback...
Full log here:
http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/HEAD/
is this already fixed ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
n NetBSD doesn't (yet)
> have the ability to change the source MAC address.
you should be able to change it manually with ifconfig (or put the
appropriate commands in /etc/ifconfig.bnx*) so that both use the same address.
I've done this in the past and it worked.
--
Manuel Bo
ses the former, but
it's not supported by all interfaces. ifconfig uses the later.
agr should probably be fixed to use the later too, but I've never
had the time to look at it deeper.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
idea ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
ttempt several times doesn't help
> - once it returns to the menus without IP, the whole computer becomes
> extremely sluggish... just navigating with the arrow keys is a pain
>
> Perhaps this is a RC3 problem or an install kernel problem instead?
If GENERIC+miniroot doesn't wo
d be the problem, and how to fix it ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
See /usr/share/examples/fstab/ for more examples.
> /dev/sd0a / ffs rw,userquota 1 1
I would suggest using the new quota2, though.
See tunefs(8) and fsck_ffs(8)
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Mon, Dec 14, 2015 at 02:04:38PM +0100, 6b...@6bone.informatik.uni-leipzig.de
wrote:
> On Fri, 11 Dec 2015, Manuel Bouyer wrote:
>
> >On Fri, Dec 11, 2015 at 03:15:06PM +0100,
> >6b...@6bone.informatik.uni-leipzig.de wrote:
> >>I'am trying to activate quo
_read() at netbsd:sys_read+0x62
syscall() at netbsd:syscall+0xc4
cpu11: End traceback...
It's not the first time I see this panic, but I can't reproduce it on demand
(the previous one was in august, while backups are running every night on
several filesystems)
Does it ring a bell to someo
client starts the following services:
>
> rpcbind=YES
> nfs_client=YES
> lockd=YES
> statd=YES
>
> There is no firewall running.
>
> Is quota for nfs clients implemented under NetBSD?
Yes
> What can be the problem?
what does rpcinfo -p against the server r
s rpcqtype really RQUOTA_USRQUOTA ?
What is returning the second call ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
_nfs_get in lib/libquota/quota_nfs.c
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
shm
df-post-test localhost:/tmp/atf-run.mCXF4l/root 0 0
0 100% /tmp/atf-run.mCXF4l/mnt
[...]
the i386 tests are running to completion, as do amd64 on qemu tests.
Any idea ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Wed, Jan 27, 2016 at 09:17:28AM +0100, Martin Husemann wrote:
> On Wed, Jan 27, 2016 at 09:08:51AM +0100, Manuel Bouyer wrote:
> > fs/psshfs/t_psshfs (493/641): 3 test cases
> > inode_nos: atf-run: ERROR: tools::fs::file_info: Cannot get information
> > of /
>
On Wed, Jan 27, 2016 at 09:27:35AM +0100, Manuel Bouyer wrote:
> > It would be great to have an option to avoid the automatic removal of
> > the temporary test directory for such cases (assuming that is where the
> > core has been dumped). But since this test is a shell scr
On Wed, Jan 27, 2016 at 10:16:25AM +0100, Martin Husemann wrote:
> On Wed, Jan 27, 2016 at 09:51:47AM +0100, Manuel Bouyer wrote:
> > it also pass when atf-run is started from /usr/tests/fs
> > Trying again to run from /usr/tests/ ...
atf run from /usr/tests fails as in the automa
On Wed, Jan 27, 2016 at 04:06:08PM +0100, 6b...@6bone.informatik.uni-leipzig.de
wrote:
> On Mon, 25 Jan 2016, Manuel Bouyer wrote:
>
> >Date: Mon, 25 Jan 2016 15:28:49 +0100
> >From: Manuel Bouyer
> >To: 6b...@6bone.informatik.uni-leipzig.de
> >Cc: current-users@
FWIW in the last test run this problem showed up in netbsd-7/amd64
but HEAD passed. I've seen it only on amd64, never on i386.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Thu, Jan 28, 2016 at 08:35:08AM +0100, 6b...@6bone.informatik.uni-leipzig.de
wrote:
> On Wed, 27 Jan 2016, Manuel Bouyer wrote:
>
> >OK, it returns RPC_PROGNOTREGISTERED instead of RPC_PROGVERSMISMATCH.
> >Can you try the attached patch ?
>
> With the patch everythin
a why modules are that big these days ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
d).
>
> I just incrased the disk size in the configuration of the amd64 tests
> on babylon5, and will also increase anita's default disk size in the
> next release (assuming the increase in disk use is permanent).
actually it's because /stand did grow 10x. I don't think that's intended.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Tue, Feb 02, 2016 at 06:47:24PM +0800, Paul Goyette wrote:
> On Tue, 2 Feb 2016, Kamil Rytarowski wrote:
>
> >--[PinePGP]--[begin]--
> >On 02.02.2016 11:40, Manuel Bouyer wrote:
> >>Hello, on recent amd65 builds, /stan
gios CALL read(4,0xbf7fd4e0,0x1000)
19040 1 nagios RET read -1 errno 35 Resource temporarily unavailable
It looks like the read(2) syscall returns a EAGAIN when the caller
expect it to block if there's no data available.
Has anyone else seen this, or has an idea where to loo
On Sun, Feb 07, 2016 at 03:23:58PM +0100, Manuel Bouyer wrote:
> It looks like the read(2) syscall returns a EAGAIN when the caller
> expect it to block if there's no data available.
I could capture the pipe setup before getting the stream of EAGAIN:
20110 1 nagios EMUL &quo
On Sun, Feb 07, 2016 at 08:49:32PM +0100, Manuel Bouyer wrote:
> On Sun, Feb 07, 2016 at 03:23:58PM +0100, Manuel Bouyer wrote:
> > It looks like the read(2) syscall returns a EAGAIN when the caller
> > expect it to block if there's no data available.
>
> I could cap
ry because the same code is used after the pipe has been closed
(the child exited or has been killed) in this case it's OK to wait for
data or EOF which will happen very soon.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Tue, Feb 09, 2016 at 08:19:13PM +, Michael van Elst wrote:
> bou...@antioche.eu.org (Manuel Bouyer) writes:
>
> >It does retry because the same code is used after the pipe has been closed
> >(the child exited or has been killed) in this case it's OK to wait for
&g
hings go from bad to worse
> So, I'll recommend the same change for the cubietruck kernel.
It's strange, I'm running HEAD on a olimex lime2 (which has A20+axp20x too)
and never seen this. I also occasionally run on a cubieboard, but
it's usually not powered on for more tha
application,
but there's still something messy with poll (it says there's one descriptor
ready for read but there are two descriptors in the fileset).
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
Hello,
http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/HEAD/
NetBSD i386/Xen doesn't boot any more (since the 2016-05-20 07:10 UTC
build), init dies with:
exec /sbin/init: error 2
any idea ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
mmited a different fix, which is to remove the KASSERT and the grp
variable.
Thanks for the report !
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Fri, May 27, 2016 at 08:28:52PM +0300, Andreas Gustafsson wrote:
> Manuel Bouyer wrote:
> > http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/HEAD/
> > NetBSD i386/Xen doesn't boot any more (since the 2016-05-20 07:10 UTC
> > build), init dies with:
> > exec /sbin
ed yet...
>
> The kernel has
>
> PAX_SEGVGUARD=0
> PAX_MPROTECT=0
> PAX_ASLR=0
>
> Returned to a Thursday 26 May kernel...
>
> Thoughts?
reverting to locore.S 1.94 fixes the problem for me.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
8806272 < 9472135)
the server would then panic again with the same backtrace while going
multiuser (and this time I got a code dump).
So I disabled log on all filesystems, and it has been stable since
then.
Does it ring a bell ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
?
I'm not sure it has been fixed. I'm seeing such issues with arpwatch
or ndpwatch (which uses bpf too).
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
's been a while since I played with this, but I think this is used for
tifb (am335x SoCs, as found on the beaglebone). AFAIK It works fine for me
with a 16bit display.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
eudo-root at all!
Doens't this means that, without pseudo-root, ataraid can't be a boot
device anymore ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
w what could be missing in our driver ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Mon, Nov 14, 2016 at 06:19:05PM +0100, Manuel Bouyer wrote:
> Hello,
> I have this device:
> https://www.olimex.com/Products/Breadboarding/BB-CH340T/open-source-hardware
> which is detected by NetBSD as:
> uchcom0 at uhub2 port 3
> uchcom0: QinHeng Electronics USB2.0-Serial, r
ault, code=0
Faulted in DDB; continuing...
and so on.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
, I am a bit busy these
> days, so I cannot work more on that now.
I don't have time to look at it either.
But as pmap_init_lapic() seems to be the problem, I disabled it on Xen
(which doesn't need it anyway). So at last Xen/i386 guests shoud boot again
now.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
ime out. This is affecting amd64 and sparc on
> bablyon5 (i386 is not even building at the moment).
it also affects amd64 and i386 on Xen:
http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/HEAD/
(lib/libc/ssp/t_ssp takes 5719s ...)
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
map_kernel(); bus_dma(9) needs it.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
the problem is probably older than
that (the testbed used vcpus=1 until today)
Any idea ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Mon, Jan 13, 2020 at 11:42:17AM +, Andrew Doran wrote:
> Hi Manuel,
>
> On Mon, Jan 13, 2020 at 10:56:23AM +0100, Manuel Bouyer wrote:
> > Hello,
> > A current Xen domU kernel fails to boot with:
> > [ 1.000] hypervisor0 at mainbus0: Xen version 4.11.3nb1
pu_switchto() in cpu_hatch() it boots, but it seems
that all user processes are running on cpu0 only ...
I can't see what extra work the cpu_switchto() could be doing that would
matters, execpt maybe the %epb/rbp init. Any idea ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
0:00 0.00% 0.00% top
16883 bouyer330 8992K 2212K RUN/0 0:00 0.00% 0.00% nbmake
21137 bouyer330 7844K 1220K RUN/0 0:00 0.00% 0.00% sed
12098 bouyer330 4288K 164K RUN/0 0:00 0.00% 0.00% sh
22411 bouyer330 4288K 164K RUN/0 0:00 0.00% 0.00% cc
42 root 85080M 5768K poll/0 0:00 0.00% 0.00% sshd
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Mon, Jan 13, 2020 at 04:59:50PM +0100, Manuel Bouyer wrote:
> It also sets rsp and rbp. I think rbp is not set by anything else, at last
> in the Xen case.
> The different rbp value would explain why in one case we hit a KASSERT()
> in lwp_startup later.
> But I don't know w
On Mon, Jan 13, 2020 at 05:43:51PM +0100, Manuel Bouyer wrote:
> On Mon, Jan 13, 2020 at 04:59:50PM +0100, Manuel Bouyer wrote:
> > It also sets rsp and rbp. I think rbp is not set by anything else, at last
> > in the Xen case.
> > The different rbp value would explain why
On Mon, Jan 13, 2020 at 06:33:08PM +, Andrew Doran wrote:
> On Mon, Jan 13, 2020 at 05:43:51PM +0100, Manuel Bouyer wrote:
>
> > On Mon, Jan 13, 2020 at 04:59:50PM +0100, Manuel Bouyer wrote:
> > > It also sets rsp and rbp. I think rbp is not set by anything else, at
On Mon, Jan 13, 2020 at 07:11:21PM +, Andrew Doran wrote:
> On Mon, Jan 13, 2020 at 07:36:41PM +0100, Manuel Bouyer wrote:
>
> > On Mon, Jan 13, 2020 at 06:33:08PM +, Andrew Doran wrote:
> > > On Mon, Jan 13, 2020 at 05:43:51PM +0100, Manuel Bouyer wrote:
> >
On Mon, Jan 13, 2020 at 09:00:30PM +, Andrew Doran wrote:
> I reproduced it on native x86. It's a bug in the CPU topology code. Now
> fixed with revision 1.11 src/sys/kern/subr_cpu.c - sorry about that.
I confirm, I now see user activity on all CPUs. Thanks !
--
Manuel Bouyer
O via the xen backend would be the bottleneck.
>
> Instead DOM0 is only seldom busy for IO. DOMU is crawling along sleeping
>
> at all sorts of places:
What does
iostat 5
show about the disks, in the dom0 and domU ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Tue, Mar 10, 2020 at 06:48:14PM +0100, Frank Kardel wrote:
> [...]
>
> To me it looks more like locking issues or xen scheduling features.
yes, that could be. does vmstat -i show anything about IPIs ?
Is the domU otherwise responsive ?
--
Manuel Bouyer
NetBSD: 26 ans d&#
> Otherwise it is usually responsive. Sometimes things get stuck but switching
> a screen in screen seems to unstick things.
>
> It seems like "wakeups" get sometimes lost.
I guess it could be related to IPIs.
But I'm running daily tests on domUs and I didn't
seems that in netbsd9 IPIs don't show up as such.
But there should be some crosscall broadcast. On a netbsd-9 pbulk host
I see more broadcast than unicast.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
There have been scheduler-related fixes in the last few days; did you
try with an up to date kernel ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
if this would
cause problems ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Wed, Apr 08, 2020 at 08:26:33PM -, Michael van Elst wrote:
> bou...@antioche.eu.org (Manuel Bouyer) writes:
>
> >Hello,
> >we have a machdep.hypervisor sysctl which returns a specific string when
> >an hypervisor is detected. I'd like to change the string ret
paddr'
> /r0/build/current/tools/amd64/bin/i486--netbsdelf-ld: (.text+0x436):
> undefined reference to `HYPERVISOR_shared_info_pa'
Should be fixed now. Sorry for this
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
gt; error: out of memory
>
> and modload fails with the OOM error.
>
> Is this an expected behavior or a bug? (kern.securelevel is -1).
What does kern.module.path show for you ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
rch/xen/xen/hypervisor.c:247:27: error: cast to pointer
> from integer of different size [-Werror=int-to-pointer-cast]
> HYPERVISOR_shared_info = (void *)(HYPERVISOR_shared_info_pa + KERNBASE);
Should be fixed with hypervisor.c 1.82
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
| grep !$
modstat | grep bpfjit
bpfjit misc filesys -09174 sljit
xen1:/#modload pciverbose
xen1:/#modstat | grep !$
modstat | grep pciverbose
pciverbose misc filesys -0 218 pci
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
a variable overflow somewhere but I can't see how it relates to
64Gb. Does it work with 16Gb ?
Also could you try with a PVH or HVM guest ? These ones would use modules
from /stand/amd64/ and not /stand/amd64-xen/ and should be close to native.
I don't have a box with that much
On Sun, May 10, 2020 at 02:36:15PM +0200, Rhialto wrote:
> Probably similarly, linking fails when building an amd64 MODULAR kernel,
> with some Xen-related undefined symbol errors:
Yes I posted a question to tech-kern, asking how to resolve this, I got
no reply so far.
--
Manuel
ake 3x more time to boot ...
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
0x78): undefined reference to `msipic_get_pci_info'
> /home/sysbuild/amd64/tools/bin/x86_64--netbsd-ld: pci_intr_machdep.o:
> in function `pci_intr_release':
> pci_intr_machdep.c:(.text+0x775): undefined reference to
> `x86_pci_msix_release'
Did you clean the build director
..
[ 872.0704774] dumping to dev 168,1 (offset=524254, size=0): not possible
[ 872.0704774] rebooting...
Any idea what could have changed to cause this ?
2020-05-26 08:40 UTC builds did complete tests.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
is change matches what other OSes do with 'devtype=cdrom',
we were an outsider here.
For PV or PVH domUs you can omit the devtype keyword, it's only
needed for HVM guests (if you want to boot from the cdrom image).
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
Hello,
I will be upgrading the storage on {ftp,www,rsync,anoncvs}.fr.netbsd.org
in the next 2 days. This will requires several reboots and services
interruptions while datas are being moved around.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
nclude
> ^~
> compilation terminated.
> netbsd.c:30:10: fatal error: xen/xenio3.h: No such file or directory
This header is in src/sys/arch/xen/include, it should be installed along with
xenio.h
I just commited a fix for this.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
Hello,
in tests from 2020-10-25:
http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/HEAD/
anita fails with
Could not locate a CD medium in any drive with the distribution sets
(for both amd64 and i386)
martin, could you please have a look ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience f
On Tue, Oct 27, 2020 at 10:14:45AM +0100, Martin Husemann wrote:
> On Tue, Oct 27, 2020 at 09:42:41AM +0100, Manuel Bouyer wrote:
> > Hello,
> > in tests from 2020-10-25:
> > http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/HEAD/
> > anita fails with
> > Could no
t/romlayout32flat.lds out/rom16.strip.o
> out/rom32seg.strip.o out/code32flat.o -o out/rom.o
> ld: out/code32flat.o: in function `memmove':
> /usr/pkgsrc/sysutils/xentools413/work/seabios-rel-1.12.1/./src/string.c:206:
> undefined reference to `memcpy'
strange, I don't get t
nce the rnd rototill. Virtual devices are
not trusted.
The only way is to manually seed the pool.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Tue, Mar 30, 2021 at 10:42:53PM +, Taylor R Campbell wrote:
> > Date: Tue, 30 Mar 2021 23:53:43 +0200
> > From: Manuel Bouyer
> >
> > On Tue, Mar 30, 2021 at 02:40:18PM -0700, Greg A. Woods wrote:
> > > [...]
> > >
> > > Perhaps
1 - 100 of 289 matches
Mail list logo
