gainst DOS I guess). In this state
the code don't want to read it, but still wants to be notified when the
remote end is clsoed (or the file descriptor will stay forever).
I think we should close the socket in any case (read error, or protocol
error) but this is something I have to check with Xen de
out a read() ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Tue, Jun 15, 2021 at 09:28:22PM +0200, Edgar Fuß wrote:
> Is there a way (short of re-booting) to re-scan a SATA port for a disc absent
> (or dysfunctional) during the boot? I.e., something like scsictl rescan?
drvctl -r -a ata_hl atabusX
--
Manuel Bouyer
NetBSD: 26 ans d'expe
On Wed, May 26, 2021 at 05:35:53PM +1000, matthew green wrote:
> Manuel Bouyer writes:
> > On Tue, May 25, 2021 at 10:46:04PM -, Michael van Elst wrote:
> > > bou...@antioche.eu.org (Manuel Bouyer) writes:
> > >
> > > >Another issue could be
On Tue, May 25, 2021 at 10:46:04PM -, Michael van Elst wrote:
> bou...@antioche.eu.org (Manuel Bouyer) writes:
>
> >Another issue could be mstohz() called with a delay too short;
> >mstohz() will round it up to 1 tick.
>
>
> # define mstohz(ms) ((unsigned in
obe in dev/ic/wdc.c.
It's been a while since I last looked at this, but I think the code
you want to look at is wdc_drvprobe().
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
the kernel *do* avoid (eg, with adding
> > hz-1 and then dividing by hz) but there are a number that
> > do not...
>
> So, should we introduce a CPP macro or an inline function that abstracts
> the common code away in a way that avoids such rounding down and
> produces corre
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
.* sysctl values.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Thu, Apr 01, 2021 at 01:13:05PM -0700, Greg A. Woods wrote:
> At Thu, 1 Apr 2021 21:03:37 +0200, Manuel Bouyer
> wrote:
> Subject: UVM behavior under memory pressure
> >
> > Of course the system is very slow
> > Shouldn't UVM choose, in this case, to reclai
On Mon, Apr 05, 2021 at 09:30:16AM -0700, Greg A. Woods wrote:
> At Mon, 5 Apr 2021 10:46:19 +0200, Manuel Bouyer
> wrote:
> Subject: Re: regarding the changes to kernel entropy gathering
> >
> > If I understood it properly, there's no need for
On Wed, Mar 31, 2021 at 09:58:48PM -0400, Thor Lancelot Simon wrote:
> On Wed, Mar 31, 2021 at 11:24:07AM +0200, Manuel Bouyer wrote:
> > On Tue, Mar 30, 2021 at 10:42:53PM +, Taylor R Campbell wrote:
> > >
> > > There are no virtual RNG devices on the sy
On Thu, Apr 01, 2021 at 04:13:59AM +, RVP wrote:
> > [...]
>
> Does this /etc/entropy-file match what's there in your /boot.cfg?
irrelevant for Xen, as Xen uses the multiboot protocol.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
he 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
--
0 ??? collect
callout 108 skew estimate, collect, v, dv
cpurng 4096 rng estimate, collect, v
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
users--with all appropriate sysinst warnings of course.
If I understood it properly, there's no need for such a knob.
echo 0123456789abcdef0123456789abcdef > /dev/random
will get you back to the state we had in netbsd-9, with (pseudo-)randomness
collected from devices.
--
Manuel Bouyer
he "wait 0" message:
yes, because '0' means "infinity" for cv_timedwait().
This should be changed to make sure at that cv_timedwait() is called with
a timeout value of at last 1, or (maybe better) skip cv_timedwait() if
the value is 0.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Sun, Apr 11, 2021 at 01:28:46PM -, Michael van Elst wrote:
> bou...@antioche.eu.org (Manuel Bouyer) writes:
>
> >The size of the disk is indeed 790528 in the xenstore (and the dom0's
> >kernel message) but I don't know where this comes from.
>
> >The file is
791121 sectors long:
#dd if=FreeBSD-12.2-RELEASE-amd64-mini-memstick.img.orig
of=FreeBSD-12.2-RELEASE-amd64-mini-memstick.img
791121+0 records in
791121+0 records out
#ls -l FreeBSD-12.2-RELEASE-amd64-mini-memstick.img
-rw-r--r-- 1 root wheel 405053952 Apr 11 11:56
FreeBSD-12.2-RELEASE-amd64-mini-memstick.img
#expr 405053952 / 512
791121
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
, 13 Jan 7 15:19 17
Any idea on how to properly fix it ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Wed, Jan 12, 2022 at 07:56:09AM -0500, Christos Zoulas wrote:
>
>
> > On Jan 12, 2022, at 7:54 AM, Manuel Bouyer wrote:
> >
> > you can still do this, as long as you're not using a linux ln(1) binary.
>
> Where do you get the reference to the original inode?
On Wed, Jan 12, 2022 at 12:44:57PM -, Christos Zoulas wrote:
> In article ,
> Manuel Bouyer wrote:
> >-=-=-=-=-=-
> >
> >On Fri, Jan 07, 2022 at 03:20:04PM +0100, Manuel Bouyer wrote:
> >> Hello
> >> I'm trying to get a linux binary to run on NetBSD,
On Wed, Jan 12, 2022 at 07:19:14PM +0700, Robert Elz wrote:
> Date:Tue, 11 Jan 2022 22:20:15 +0100
> From: Manuel Bouyer
> Message-ID:
>
> | > What causes that EINVAL?
> |
> |
> | I'm not sure (somneone suggested that the file
On Wed, Jan 12, 2022 at 08:10:44AM -0500, Christos Zoulas wrote:
>
>
> > On Jan 12, 2022, at 8:08 AM, Manuel Bouyer wrote
> >>
> >> Where do you get the reference to the original inode? Try it...
> >
> > I don't understand. My patch doesn't cha
On Fri, Jan 07, 2022 at 03:20:04PM +0100, Manuel Bouyer wrote:
> Hello
> I'm trying to get a linux binary to run on NetBSD, as stated in this thread
> http://mail-index.netbsd.org/current-users/2022/01/06/msg041891.html
>
> Now I hit an issue where the linux process does a readlin
On Tue, Jan 11, 2022 at 11:34:45AM +0100, Martin Husemann wrote:
> On Tue, Jan 11, 2022 at 11:10:24AM +0100, Manuel Bouyer wrote:
> > +static inline bool
> > +procfs_proc_is_linux_compat(void)
> > +{
> > + const char *emulname = curlwp->l_proc->p_emul->e_na
On Tue, Jan 11, 2022 at 08:00:53PM +, David Holland wrote:
> On Tue, Jan 11, 2022 at 11:10:24AM +0100, Manuel Bouyer wrote:
> > The attached diff changes the procfs behavior to match the linux one, for
> > linux processes:
> > comore:/home/bouyer>ls -l /proc/self/f
> to evbarm taking a root=dev argument passed from the bootloarder.
This is already there; it's used by Xen.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
it too, although it didn't end up killing processes.
But the nightly jobs (usual daily/security+ backup) ends up pushing to
swap lots of processes, while the file cache grows to more than half the
RAM (I have 16Gb). As a result the machine is really slow and none of the
nightly jobs complete before morning.
Decreasing kern.maxvnodes helps a lot.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
ed.
a pool cache has a backing pool. If there's no item in the pool cache, it
gets some memory from its backing pool.
The point of the cache here it to keep the physical address of items around,
so it doesn't have to be computed again
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
these messages on their domu machines and does
> anyone have ideas on
> how to correct the issue?
It's running out of mbuf clusters; this is the mclpl in vmstat -m
You can try increasing kern.mbuf.nmbclusters, or if that fail, rebuilding
a kernel with
options NMBCLUSTERS=
e.g.
op
t; yet, this machine has displayed this message about 6 times since it was
> rebooted about 5 hours
> ago.
>
> Am I missing something?
OK, so this is -current; it is the if_xennetrxbuf_cache pool cache which
is failing. This one has no limits.
--
Manuel Bouyer
NetBSD: 26
st?
I think it's more than this; it's to use the right instruction on the
right CPU. But I don't remember the details
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Fri, Jul 08, 2022 at 12:17:25PM +, Emmanuel Dreyfus wrote:
> On Fri, Jul 08, 2022 at 11:55:13AM +0200, Manuel Bouyer wrote:
> > I think it's more than this; it's to use the right instruction on the
> > right CPU. But I don't remember the details
>
> This tests a CPU
eems to sort-of mirror the on-screen messages up to
> the point the NetBSD boot runs. I tried
> consdev com0,9600
> from the boot prompt but that hung the machine.
On some systems I have to set the ioaddr too
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
le?
If you can setup a serial console, it may make things much easier.
I almost always use serial consoles on dev machines; I don't remember the
details but doing the equivalent of a putchar very early was possible.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
ve it working
early in boot, as early as the consinit() call in init_x86_64().
I'm almost sure I used printf() in init_x86_64 with a serial console
(but after the consinit() call or course).
I definitively used it in pmap_bootstrap().
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
need to have physical disks assigned to one (or more) RAID volume,
and then the RAID volume has to be exported as one (or more) virtual disks.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
le "getextattr system.test" tries to read attribue system.test in
namespace system.
Is it the expected behavior (i.e. did I misinterpret the man page) ?
Or should getextattr strip the namespace component in the second use
case ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Thu, Mar 23, 2023 at 12:51:35PM +0100, Manuel Bouyer wrote:
> hello,
> trying to set up glusterfs on NetBSD I ran into issues with extended
> attributes
> (on a FFSv2ea). Basically glusterfs tries to setup attributes in the
> trusted namespace, and if I undertood it properly i
On Wed, Mar 22, 2023 at 04:38:26PM +, Taylor R Campbell wrote:
> > Date: Wed, 22 Mar 2023 17:18:45 +0100
> > From: Manuel Bouyer
> >
> > I did this but it didn't unblock the python process. It did tell me:
> > #rndctl -L /tmp/foo
> > rndctl: no entr
of network traffic, but nothing seems
to work. I can't switch any of my devices to estimate.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Wed, Mar 22, 2023 at 03:59:18PM +, Taylor R Campbell wrote:
> > Date: Wed, 22 Mar 2023 16:33:55 +0100
> > From: Manuel Bouyer
> >
> > I upgraded a Xen guest from -7 to 10, and run into:
> > entropy: pid 17200 (python) blocking due to lack of entropy
> &g
probably need a sdspi to make the translation
between sdmmc commands and our SPI drivers.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
a),%ebp
movl%ebx,(%ebp)
movl$0,4(%ebp)
#endif
How can this work on Xen when GENPVH is defined ?
Shouldn't this be made conditional on vm_guest == VM_GUEST_XENPVH ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Mon, Dec 11, 2023 at 10:22:18AM +0100, Emile `iMil' Heitor wrote:
>
> Hi Manuel,
>
> On Mon, 11 Dec 2023, Manuel Bouyer wrote:
>
> > #ifndef GENPVH
> > /* get a page for HYPERVISOR_shared_info */
> > addl$PAGE_SIZE, %ebx
> > addl
ldn't the #ifndef GENPVH really be #ifdef XENPVHVM ?
In the same way, the #ifndef GENPVH in xen_machdep.c should either be
#ifdef XENPVHVM or #ifdef XEN
because we probably want to build kernels with both XENPVHVM and GENPVH
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
__kernel_end.
> This brings us to init_xen_early(), which is failing but that's another story.
Of course, this is *not* a Xen VM, so no surprise that start_xen32
isn't working.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Wed, Nov 29, 2023 at 12:41:53PM +0100, Emile `iMil' Heitor wrote:
> On Wed, 29 Nov 2023, Manuel Bouyer wrote:
>
> > Of course, this is *not* a Xen VM, so no surprise that start_xen32
> > isn't working.
>
> I'm just sharing the progress here, in ca
tps://github.com/NetBSD/src/blob/trunk/sys/arch/amd64/amd64/locore.S#L738
I don't think you can use start_xen32 as is, as it expects a Xen environnemwnt.
You may need to write a new start routine, or make a difference between Xen
vs non-Xen in the existing one.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
It's a nontrivial change to our USB stack requiring some care
> to get right, but this is far and away the biggest shortcoming of our
> USB stack and we should unquestionably do it.
Strongly seconded.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
601 - 651 of 651 matches
Mail list logo