On Wed, Sep 05, 2018 at 08:28:27PM -, Michael van Elst wrote:
> bou...@antioche.eu.org (Manuel Bouyer) writes:
>
> >Hello,
> >in vnd.c rev 1.255, vnode_has_large_blocks() has been introduced, and
> >will cause vnd to use VOP_READ/VOP_WRITE instead of VOP_BMAP/VOP_S
On Wed, Sep 05, 2018 at 11:27:51PM +0200, Manuel Bouyer wrote:
> > The backing store and the geometry are initialized before vndthread
> > is started, getdisksize() shouldn't fail and I'm sure it didn't
> > at that time.
>
> AFAIK getdisksize() returns the para
ion about vnd
related to xen suspend/resume ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
ragments FFS
for their domUs backing store.
The performance penaltly of VOP_READ/VOP_WRITE is just inacceptable
for a Xen setup.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Sun, Sep 09, 2018 at 11:49:20AM -, Michael van Elst wrote:
> bou...@antioche.eu.org (Manuel Bouyer) writes:
>
> >I strongly dissagree. I have 512-byte-sectors domUs running for years on a
> >dom0 with 64k blocks/8k fragements. This works ! I'm I'm probably not the
> &
.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Thu, Sep 06, 2018 at 06:46:12AM -, Michael van Elst wrote:
> bou...@antioche.eu.org (Manuel Bouyer) writes:
>
> >thinking about it more, I think this is the wrong approach. For example,
> >if the vnd is for a linux domU, getdisksize() won't return anything
>
locks, then making a reference to vp again (even dereferencing it), and
> it might have been nuked from low orbit (freed) since we last had
> guarantees about it.
>
> Am I missing something?
When we get these, usecount is 1, so nothing else should have a reference
to this vnode,
I have simplefb in my kernel, but u-boot doesn't configure it,
yet I boot with console=fb and if works ...
Without this I can't get console to framebuffer when u-boot doens't know
about it.
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
m: allwinner,simple-framebuffer isn't specific
enough. At the time FDT_CONSOLE is called we don't know which variant of
debe we have, so we don't if we'll can handle it.
So I choose a way which allows fallback to simplefb when needed
(and actually it's needed on all but a10 and a20).
--
Manuel
ce. We could add a
> helper to ofw_subr.c for this.
I guess this should work.
I'll try this tomorow.
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
*[]) to remove nodes
matching on compatible strings; for completeness I also added
fdt_remove_byhandle(int) but I don't need it.
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
Index: dev/fdt/fd
On Thu, Apr 05, 2018 at 07:40:35AM -0300, Jared McNeill wrote:
> On Thu, 5 Apr 2018, Manuel Bouyer wrote:
>
> > Does it really do that ?
> > Reading the sources nothing is displayed until simplefb_attach() is called.
> > simplefb_console_consinit() calls genfb_cnatta
On Wed, Apr 04, 2018 at 07:25:41PM -0300, Jared McNeill wrote:
> On Thu, 5 Apr 2018, Manuel Bouyer wrote:
>
> > looking closer at it I can't see how this change would be a problem.
> > With this /chosen/stdout-path may point to a path that doens't
> > exists, or is not ok
On Thu, Apr 05, 2018 at 08:08:13AM -0300, Jared McNeill wrote:
> On Thu, 5 Apr 2018, Manuel Bouyer wrote:
>
> > On Thu, Apr 05, 2018 at 07:40:35AM -0300, Jared McNeill wrote:
> > > On Thu, 5 Apr 2018, Manuel Bouyer wrote:
> > >
> > > > Does it really do
On Thu, Apr 05, 2018 at 07:13:19AM -0300, Jared McNeill wrote:
> On Thu, 5 Apr 2018, Manuel Bouyer wrote:
>
> > But still, being able to switch the console from the bootargs is convenient.
> > On the device I'm working with, the normal stdout-path would be the
> > graphic
switch to graphics,
I can change my kernel config to have the serial port probed sooner, for the
time being.
Would that be OK with you ?
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
On Wed, Apr 04, 2018 at 06:24:44PM +0200, Manuel Bouyer wrote:
> Hello,
> What's missing from the sunxi video drivers is console handling.
> I got this working, but this needs some change to the simplefb driver.
I also need the attached change. Without it, if u-boot did use the se
On Mon, Mar 26, 2018 at 03:11:09PM +0800, Paul Goyette wrote:
> [...]
>
> The opt_* files are only applicable when building kernels, not for building
> modules.
OK, I guess this is what _KERNEL_OPT is for.
The I would use -DXEN=1 -DPAE=1, because that's what is in opt_xen.h
--
M
magic!
>
> Anyway, it seems to me that, when building the XEN (or PAE) variants of each
> module, they should be built with -DXEN (or -DPAE) options. There is at
I think it has to be in opt_xen.h, not on the command line
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 a
at this time but I'm confident
that this panel interface won't need much changes to get a working display.
The panel driver is incomplete (it misses the backlight handling, and could
also support non-lvds panels) but I'll leave this to someone with the hardware.
--
Manuel Bouyer <
ect of pmap_update.
I think it's because if we get a fault, then this VA is not mapped
in the page table, and so it can't be cached in any TLB. So there is
nothing to flush in this case.
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
s a bit smaller, but that's not
a big deal.
>
> I'd like to see this evolve at some point to work closer with the DRM2 APIs,
> as it seems that there may be quite a bit of overlap.
Sure. A working implementation of the fdt endpoints should help with this.
--
Manuel Bouyer <bou...@antio
a clock name. But for this I need to
use a struct sunxi_ccu_clk * instead of struct clk *.
So what should I do to solve this ? Introduce clk_get_domain() or
clk_set_parent_byname() in sys/dev/clk/, or use struct sunxi_ccu_clk in
the sunxi drivers ?
--
Manuel Bouyer <bou...@antioche.eu.org>
On Mon, Mar 19, 2018 at 09:17:08PM -0300, Jared McNeill wrote:
>
>
> On Mon, 19 Mar 2018, Manuel Bouyer wrote:
>
> > On Mon, Mar 19, 2018 at 05:20:45PM -0300, Jared McNeill wrote:
> > > I see what you mean now. The issue I have with clk_set_parent_byname is
> >
On Tue, Mar 20, 2018 at 06:20:12PM -0300, Jared McNeill wrote:
> On Tue, 20 Mar 2018, Manuel Bouyer wrote:
>
> > > But yeah, you can see them on the tcon nodes, named by the
> > > "clock-output-names" property. It looks like those clocks use the
> >
On Tue, Mar 20, 2018 at 07:09:15PM -0300, Jared McNeill wrote:
> On Tue, 20 Mar 2018, Manuel Bouyer wrote:
>
> > > The code for the pixel clock would be part of the display driver. The
> > > parent
> > > of that clock is part the CCU. Maybe we
On Mon, Mar 19, 2018 at 04:03:56PM -0300, Jared McNeill wrote:
> On Mon, 19 Mar 2018, Manuel Bouyer wrote:
>
> > Looking at what we have now, I see 2 ways for doing this:
> > - clk_set_parent(). But this one takes a "struct clk*" as parent,
> > and I d
On Mon, Mar 19, 2018 at 03:02:09PM +0100, Manuel Bouyer wrote:
> Hello
> right now, at last in the arm/sunxi port, for clocks with MUXes we never
> explicitely set the parent: we use whatever is there at boot.
> For the display drivers I need to set the parent, as this
ree.
Maybe there would be one way to avoid referencing arbitrary clocks
(and the need for a clk_set_parent_byname()): add a
struct clk * clk_get_parent_byindex(struct clk *, int)
which would allow enumerating the possible parents of a clk.
I think this would work for me.
--
Manuel Bouyer <bo
On Tue, Mar 20, 2018 at 05:26:15PM -0300, Jared McNeill wrote:
> On Tue, 20 Mar 2018, Manuel Bouyer wrote:
>
> > but pushing driver-specific clock setup in the ccu also looks wrong
> > to me, and could appear as black magic.
>
> It's not driver specific. The TCON needs a
On Tue, Oct 02, 2018 at 12:29:51PM +0200, J. Hannken-Illjes wrote:
> A warning is not sufficient as we may be using the wrong block hints list.
>
> Snapshots are checked on read-write mounts only.
OK, so at last we can boot single-user and run fsck ...
--
Manuel Bouyer
NetBS
On Tue, Oct 02, 2018 at 12:11:49PM +0200, J. Hannken-Illjes wrote:
>
> > On 18. Sep 2018, at 16:39, J. Hannken-Illjes
> > wrote:
> >
> >
> >> On 18. Sep 2018, at 16:33, Manuel Bouyer wrote:
> >>
> >> On Tue, Sep
ly we can't do larger than 64k.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
t() which is a NOP could damage
anything.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
s it won't hurt but I still think it won't cover all cases
(see the recent thread in tech-kern). I have in mind something where we
could first try with bmap/strategy and if that fail, retry with read/write,
at run time. The cost of a bmap/strategy failure would be low as there
would be no I/O invo
On Wed, Sep 12, 2018 at 09:37:46AM +, Emmanuel Dreyfus wrote:
> On Wed, Sep 12, 2018 at 09:48:21AM +0200, Manuel Bouyer wrote:
> > Yes, IHMO it should not panic but complains and ignore the invalid
> > snapshots.
> > In your case you had to mount the FS read/write to f
+fsck too, but we should not have
to go there to go back to a mountable filesystem).
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Wed, Sep 19, 2018 at 12:08:02AM +0200, Emmanuel Dreyfus wrote:
> Manuel Bouyer wrote:
>
> > > The code in sys/dev/vnd.c is abls to handle I/O either using
> > > bmap/strategy, or using read/write. The later is more efficient,
> >
> > that's clearl
HOT he should know what he's doing.
Maybe we could leave out the FFS_NO_SNAPSHOT change, and just clear the
extra fs_snapinum[] entry ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
r bugs in ipf, and I run several servers
(netbsd-8) facing internet, with ipv6 and quite a bit of traffic. No
problems with ipf AFAIK. the tools could be a bit smarter with ipv6
rules and I intend to look at this, but it's not a big deal for daily use.
--
Manuel Bouyer
NetBSD: 26 ans d'exper
ipf instead of reinventing the
wheel, ipf would probably be in much better shaoe now.
I'm still using ipf because npf miss the features I need (essentialy
groups). Each time I mentioned this, no comments on this topic were made.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
t efforts between 3 firewalls.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
ctly reflect the real behaviour
I didn't play much with ipftest. But in any case this doesn't prevent
using ipf
> -- rule numbers in ipfstat sometimes don't match
that's an annoyance, but it doens't prevent using it
> -- keep state doesn't work with ICMP6
I avoid keep-state as much as possi
les,
processing can stop at the end of the group, or continue with other rules.
This is what makes groups usefull.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
d 26110.1 (gcc) at netbsd:_kernel_lock+0xc4:
Any idea how to process from here ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
cket filter rule file is parsed
(e.g. in a Xen dom0)
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Tue, Jun 25, 2019 at 10:43:32AM +0200, Michael van Elst wrote:
> On Tue, Jun 25, 2019 at 09:49:46AM +0200, Manuel Bouyer wrote:
> > On Mon, Jun 24, 2019 at 09:56:35PM -, Michael van Elst wrote:
> > > IMHO such functionality doesn't belong into the kernel, it's much ea
ife much easier for e.g. ipfilter in Xen dom0, where the domU's virtual
interfaces have unpredicatble names.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Mon, Jun 24, 2019 at 04:20:59AM -0700, Jason Thorpe wrote:
>
> > On Jun 24, 2019, at 12:15 AM, Manuel Bouyer wrote:
> >
> > I'd like to see this in NetBSD. I'd also like packet filters to be able
> > to use the description instead of the name for interfaces. This
On Mon, Jun 24, 2019 at 04:59:04AM -0700, Jason Thorpe wrote:
>
> > On Jun 24, 2019, at 4:29 AM, Manuel Bouyer wrote:
> >
> > I'd say that we should explicitely mention if we're looking up a name or
> > a description, to avoid confusion. For example if wm0 has desc
On Fri, Apr 19, 2019 at 11:10:07AM +0200, Manuel Bouyer wrote:
> [...]
> So cpu 1 is indeed running the LWP hodling the spin lock, and it looks
> like it's itself waiting for a mutex.
> Now I have to find why "mach cpu 1" hangs, and how to avoid it ...
I found the reason
On Fri, Apr 19, 2019 at 11:13:40AM +0100, Nick Hudson wrote:
> On 19/04/2019 10:10, Manuel Bouyer wrote:
> > Overnight lockdebug did find something:
> > login: [ 1908.3939406] Mutex error: mutex_vector_enter,504: spinout
> >
> > [ 1908.3939406] lock addres
n pid 21532.1 (gcc) at netbsd:_kernel_lock+0x19c:
So cpu 1 is indeed running the LWP hodling the spin lock, and it looks
like it's itself waiting for a mutex.
Now I have to find why "mach cpu 1" hangs, and how to avoid it ...
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
d with pm_lock as
aarch64 does. I will try this.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Fri, Apr 19, 2019 at 10:34:22AM +0100, Nick Hudson wrote:
> On 19/04/2019 10:10, Manuel Bouyer wrote:
> [snip]
>
>
> Did you see my suggestion for getting the backtrace from the lwp on the
> "other" cpu?
Yes, it didn't give anything interestng. I guess it is be
On Thu, Apr 18, 2019 at 04:32:56PM +0200, Manuel Bouyer wrote:
> Hello,
> I got several hard hang while building packages on an allwinner a20 (lime2)
> I use distcc so there is moderate network traffic in addition to
> local CPU load.
>
> most of the time I can't enter ddb from
On Thu, Apr 18, 2019 at 04:32:56PM +0200, Manuel Bouyer wrote:
> [...]
>
> (the common point is the dwc_gmac_intr() call, which ends up in pool_get().
> pool_get() seems to spin on the mutex_enter(>pr_lock); call
> just before startover:.
> Unfortunably I can't get a stack tr
[redirected to port-arm]
On Fri, Apr 19, 2019 at 12:47:11PM +0200, Manuel Bouyer wrote:
> On Fri, Apr 19, 2019 at 08:33:00PM +1000, matthew green wrote:
> > > So here's our deadlock: cpu 0 holds the kernel lock and wants the pool
> > > spin
> > > mutex; cpu 1
On Tue, Sep 10, 2019 at 05:43:51PM +0200, Manuel Bouyer wrote:
> On Tue, Sep 10, 2019 at 04:38:46PM +0100, Robert Swindells wrote:
> >
> > Manuel Bouyer wrote:
> > >I'm trying to build a evbarm kernel with
> > >options SLJIT
> > >options
On Tue, Sep 10, 2019 at 04:38:46PM +0100, Robert Swindells wrote:
>
> Manuel Bouyer wrote:
> >I'm trying to build a evbarm kernel with
> >options SLJIT
> >options BPFJIT
>
> Are you building a 32 or 64-bit kernel ?
32-bits.
--
Manuel Bouyer
On Tue, Sep 10, 2019 at 05:01:43PM +0100, Robert Swindells wrote:
>
> Manuel Bouyer wrote:
> >On Tue, Sep 10, 2019 at 04:38:46PM +0100, Robert Swindells wrote:
> >>
> >> Manuel Bouyer wrote:
> >> >I'm trying to build a evbarm kernel with
On Sun, Jul 21, 2019 at 06:57:30PM +, m...@netbsd.org wrote:
> On Sun, Jul 21, 2019 at 08:52:52PM +0200, Manuel Bouyer wrote:
> > On Sun, Jul 21, 2019 at 06:43:04PM +, m...@netbsd.org wrote:
> > > On Sun, Jul 21, 2019 at 11:55:23AM -0400, Greg Troxel wrote:
> > >
On Sun, Jul 21, 2019 at 07:20:08PM +, Taylor R Campbell wrote:
> > Date: Sun, 21 Jul 2019 20:52:52 +0200
> > From: Manuel Bouyer
> >
> > /dev/randon actually works as documented and if rust wants /dev/urandom
> > behavior it should use /dev/urandom. Also
et explained why
a compiler needs that much random bits.
BTW, while talking about packages availability, when will the bootstrap
kit for i386 be available ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
he average speed I got from pkgbuild.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Thu, Sep 26, 2019 at 04:52:35PM +0200, Maxime Villard wrote:
> Le 26/09/2019 à 16:47, Manuel Bouyer a écrit :
> > On Thu, Sep 26, 2019 at 04:40:33PM +0200, Maxime Villard wrote:
> > > >
> > > > Actually this is not clear. We have linux binaries in pkgsrc.
&g
On Thu, Sep 26, 2019 at 04:40:33PM +0200, Maxime Villard wrote:
> >
> > Actually this is not clear. We have linux binaries in pkgsrc.
>
> ... And? We have 22000 packages in pkgsrc.
How is it relevant ? I install less than 200. But there is suse_base in them
--
Manuel Bouye
On Thu, Sep 26, 2019 at 06:45:44PM +0200, Maxime Villard wrote:
> Le 26/09/2019 à 18:15, Manuel Bouyer a écrit :
> > On Thu, Sep 26, 2019 at 05:28:11PM +0200, Maxime Villard wrote:
> > > Le 26/09/2019 à 17:25, Brian Buhrow a écrit :
> > > > [...]
> > > >
so we shouldn't do anything"? Even as it's
> already been clear that the majority doesn't use compat_linux?
Actually this is not clear. We have linux binaries in pkgsrc.
> Is it such a Herculean effort to type "modload compat_linux" for the
> people that want to use Linux binaries? In order to keep the majority
> safe from the bugs and vulnerabilities?
Maybe some of them don't even know they are using compat_linux ...
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Thu, Sep 26, 2019 at 05:18:34PM +0200, Maxime Villard wrote:
> Le 26/09/2019 à 17:15, Manuel Bouyer a écrit :
> > On Thu, Sep 26, 2019 at 05:10:01PM +0200, Maxime Villard wrote:
> > > issues for a clearly marginal use case, and given t
nce of the opposite either).
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
> > than they are now because the primary developers aren't concern with making
> > things work or secure anymore.
>
> Nobody is making compat_linux work, nobody is making compat_linux secure.
Actually it *does* work. Secure, I don't know.
--
Manuel Bouyer
NetBSD:
otstrap (Ada).
>
> These are fairly easy to fix and I don't mind helping with the work but
> it would be nice for someone to run a before/after bulk build of pkgsrc
> to see what breaks.
Sure. Also, I use NETBSD_COMPAT* on a regular basis for upgrade (boot new
kernel with old userland then upgra
me compat feature.
If the toolchain can be in pkgsrc, then I it should be much easier.
At some point I could build linux binaries running a linux gcc under
compat_linux.
Maybe it's just a matter of adding a suse_toolchain package ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
ysctl.
>
> Any major and specific objections?
not from me.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
job ! thanks !
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
at is used
> immediately upon mount.
I think the point is, when the root inode is corrupted, you can't unmount
then filesystem.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
before attaching the
hypervisor device. And I need CPUs to be set up to attach the hypervisor
device. So I have a xen_hvm_init() function called early.
Is there a way, in this function, to detect if hypervisor has been disabled by
userconf ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront
I use ipf on netbsd-9 and didn't notice issues.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
0130Z_atf.html#failed-tcs-summary
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
is not compiled in.
And maybe more I didn't think about.
For me the second option would be best; I can live with the first one too.
The third is ugly.
Any idea/comment ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
with this ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
Index: dev/pci/pci_map.c
===
RCS file: /cvsroot/src/sys/dev/pci/pci_map.c,v
retrieving revision 1.39
diff -u -p -u -r1.39 pci_map.c
--- dev/pci
r a PCI device according to the PCI
> specs?
No idea. But the FreeBSD comments says that bad thing could happen
when writing arbitrary values with decoding enabled (they don't mention Xen
specifically), and it makes sense to me.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Mon, May 04, 2020 at 09:17:28PM +0200, Manuel Bouyer wrote:
> Hello,
> while trying to boot a Xen PVH kernel as dom0, I found that Xen doesn't
> allow changing memory-mapped PCI BARs if memory decode is enabled in the
> command register. FreeBSD disables I/O or memory decoding in
On Sat, May 16, 2020 at 05:24:32AM -0700, Chuck Silvers wrote:
> On Wed, May 13, 2020 at 08:20:15PM +0200, Manuel Bouyer wrote:
> > Hello,
> > for Xen I need some non-standard VM operation: the tools want to map
> > some Xen objects for which we don't have a physical addre
tbsd:wapbl_circ_write+0x103
> [ 8909.352675] wapbl_flush() at netbsd:wapbl_flush+0x26f
> [ 8909.352675] ffs_sync() at netbsd:ffs_sync+0x20a
> [ 8909.362679] VFS_SYNC() at netbsd:VFS_SYNC+0x35
> [ 8909.362679] sched_sync() at netbsd:sched_sync+0x98
> [ 8909.362679] cpu5: End traceback...
So your disk is bad, with write errors, and it looks like there is
a bug in dk in this case
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Tue, Sep 22, 2020 at 02:50:37PM +0300, Andreas Gustafsson wrote:
> Manuel Bouyer wrote:
> > I think we should find and remove theses (or make them conditional)
> > instead of adding unconditional new ones
>
> It would already be conditional in the sense that it's only pr
On Tue, Sep 22, 2020 at 02:31:50PM +0300, Andreas Gustafsson wrote:
> Manuel Bouyer wrote:
> > I'm not sure we want a user-triggerable kernel printf enabled by default.
> > This could be used to DOS the system (especially on serial consoles)
>
> You can already t
On Tue, Sep 22, 2020 at 03:05:34PM +0300, Andreas Gustafsson wrote:
> Manuel Bouyer wrote:
> > If you run a dd on /dev/random I guess the system will run out of
> > entropy pretty fast.
>
> In -current, entropy does not run out.
So, how can it block ?
--
Manuel Bouyer
ndom,
> and I'm finding it useful when testing changes aimed at fixing PR
> 55659.
>
> OK to commit?
I'm not sure we want a user-triggerable kernel printf enabled by default.
This could be used to DOS the system (especially on serial consoles)
--
Manuel Bouyer
NetBSD: 26 ans d
On Tue, Sep 22, 2020 at 03:23:59PM +0300, Andreas Gustafsson wrote:
> Manuel Bouyer wrote:
> > > In -current, entropy does not run out.
> >
> > So, how can it block ?
>
> When there's too little entropy to begin with. Once you have
> gathered enough, it
On Thu, Oct 01, 2020 at 06:11:20PM +0200, Martin Husemann wrote:
> On Thu, Oct 01, 2020 at 05:57:12PM +0200, Manuel Bouyer wrote:
> > Source Bits Type Flags
> > /dev/random 0 ??? estimate, collect, v
> [..]
> > seed
ow is it preserved across reboot ? Where does the kernel stores it
> > ?
>
> Shutdown process will store a new seed file
ha OK, so it's preserved on shutdown(8), not reboot(2)
which, basically. means that one should not use reboot, halt or poweroff
any more ...
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
/
Any idea ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
but I don't remember the details (and couldn't find a PR about it either).
Does it ring a bell to someone ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Tue, Jan 12, 2021 at 01:20:39PM +0100, Martin Husemann wrote:
> On Tue, Jan 12, 2021 at 01:11:00PM +0100, Manuel Bouyer wrote:
> > I think I've seen some mails about a similar problem in the past few months
> > but I don't remember the details (and couldn't find a PR
On Sun, Nov 15, 2020 at 12:23:00PM +0100, Reinoud Zandijk wrote:
> [...]
>
> IIRC, XEN uses Qemu too (regretfully) :-/
It depends. it uses qemu for or (PV)HVM guests only. PV or PVH guests don't
need it.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Tue, Feb 02, 2021 at 07:39:39PM +, Roy Marples wrote:
> On 02/02/2021 18:20, Manuel Bouyer wrote:
> > Hello,
> > I've been debugging an issue wuth Xen, where xenstored loops at 100%
> > CPU on poll(2).
> > after code analysis it's looping on closed Unix socket d
On Tue, Feb 02, 2021 at 07:47:09PM +, Roy Marples wrote:
> On 02/02/2021 19:43, Manuel Bouyer wrote:
> > On Tue, Feb 02, 2021 at 07:39:39PM +, Roy Marples wrote:
> > > On 02/02/2021 18:20, Manuel Bouyer wrote:
> > > > Hello,
> > > > I've been de
501 - 600 of 651 matches
Mail list logo
