On Thu, Dec 13, 2018 at 03:29:03AM +, David Holland wrote:
> On Wed, Dec 12, 2018 at 10:27:04PM +0100, Joerg Sonnenberger wrote:
> > On Wed, Dec 12, 2018 at 08:46:33PM +0100, Micha? G?rny wrote:
> > > While researching libc++ test failures, I've discovered that NetBSD
> > > suffers from the
On Mon, Dec 17, 2018 at 02:35:11PM -0800, Jason Thorpe wrote:
>
>
> > On Dec 17, 2018, at 2:00 PM, Maxime Villard wrote:
> >
> > Now I'm re-putting the subject on the table, because, as if it wasn't
> > already glaringly obvious, COMPAT_SVR4 is broken beyond repair. I keep
> > unintentionally f
On Tue, Dec 18, 2018 at 08:53:54AM -0500, Thor Lancelot Simon wrote:
> They did _not_ cause measureable performance problems of any kind, and
> though it is theoretically possible to do this sort of thing via a
> tightly-protected userspace helper process, I prototyped that too and
> it gets very u
On Sun, Dec 23, 2018 at 04:36:46PM +0100, Maxime Villard wrote:
> Having said that, you would be getting much better results if you were just
> emulating SunOS (or something else) directly rather than going through the
> expense of finding out which NetBSD version had the most functional
> compat_s
On Sun, Dec 23, 2018 at 09:04:12AM -0800, Jason Thorpe wrote:
> Anyway, one drawback of the module approach is that you have to be
> down-securelevel to load one. So, any system that wants to run this
> test would have to pre-load the module at boot time.
We have lots of module tests that are ski
On Mon, Jan 14, 2019 at 07:43:49PM -0500, Krizhan Mariampillai wrote:
> Dear Sir/Madam,
>
>
> I am a current university student fascinated in operating systems. I am
> interested on working on the following project:
> https://wiki.netbsd.org/projects/project/ffs-fallocate/ I?m curious if this
> p
On Thu, Jan 17, 2019 at 09:52:17PM +0100, Kamil Rytarowski wrote:
> The problem is that when we are in coredump_getseghdrs_elf64() and call
> copyin_proc() -> copyin_vmspace() -> copyin() we trigger a trap that is
> translated through trap() -> ... -> genfs_getpages() to EINVAL as there
> are no pa
Sorry, I completely fail to parse this - can you start from scratch and
just describe the problem you think you are seeing?
Martin
On Fri, Jan 18, 2019 at 10:01:22AM +0100, Kamil Rytarowski wrote:
> It's interrupted because we cannot access the pages that are not
> assigned (which is the cause of the original crash emitting SIGBUS).
Which pages are not assigned? core dumps in general do work, so there
must be something specia
On Fri, Jan 18, 2019 at 10:13:47AM +0100, Kamil Rytarowski wrote:
> On 18.01.2019 10:08, Martin Husemann wrote:
> > On Fri, Jan 18, 2019 at 10:01:22AM +0100, Kamil Rytarowski wrote:
> >> It's interrupted because we cannot access the pages that are not
> >> ass
On Wed, Jan 30, 2019 at 07:59:13PM +0900, Rin Okuyama wrote:
> I think we agree to add API something like
>
> On 2019/01/29 17:32, Maxime Villard wrote:
> > int
> > m_addjcl(struct mbuf *m, int how, int size)
Just a minor nit: avoid "JCL" in any names - it causes great pain for some
rea
On Sat, Feb 02, 2019 at 01:16:47PM -0400, Jared McNeill wrote:
> It might be worth requesting a pull-up to netbsd-8 as well.
Don't think we can do that (it requires a kernel version bump, doesn't it?)
Martin
On Fri, Feb 08, 2019 at 02:07:44PM +, Emmanuel Dreyfus wrote:
> Hello
>
> I am still working on LTFS, and during a dump to the tape, the
> ltfs process got a SIGSEGV. crash(8) tells me that one of its thread
> has this kernel backtracee:
Don't you get a userland core and gdb tells you t
On Fri, Feb 08, 2019 at 03:19:07PM +, Emmanuel Dreyfus wrote:
> As I understand, that means SIGSEGV is not caused by userland
> code, but by kernel code. I assume that if I do a SCSI command
> that access unmapped memory, I would get something like this?
> But no thread seems to be undergoing a
On Tue, Feb 12, 2019 at 03:18:19PM +0100, Kamil Rytarowski wrote:
> Is it viable to get merged the Hyper-V support for NetBSD-9?
What is missing? I thought it all went in already (and even pulled up to -8)?
Martin
On Sun, Feb 17, 2019 at 04:43:52PM +0900, Tetsuya Isaki wrote:
> I wrote atf tests for atomic_ops(3).
> These does not test the atomicity but can find a easy bug.
> Is this ok to commit?
> (I know there is a similar path tests/lib/libc/sync but
> I think it's better to not merge)
Why not?
Or we c
On Sun, Feb 17, 2019 at 06:45:31PM +0900, Tetsuya Isaki wrote:
> Well then, I add atomic_ops part this time. And I will
> prepare sync_* tests and add them in tests/lib/libc/atomic
> (in order to replace tests/lib/libc/sync).
Thanks a lot!
Martin
On Mon, Apr 01, 2019 at 10:02:57AM -0700, Brian Buhrow wrote:
> 2. For me to use npf at all, I absolutely need to have the
> route-through/reply-to feature. Pf has that feature.
Can you explain what that does (or give an example)?
I have used "map" rules in ipnat.conf in the past with IPF, an
On Mon, Apr 01, 2019 at 07:55:15PM -0400, Aaron B. wrote:
> On Sat, 30 Mar 2019 02:30:06 +0100
> Jan Danielsson wrote:
>
> > On 2019-03-30 01:19, Matt Sporleder wrote:
> > > What features, exactly, are missing?
> >
> >Runtime NAT reconfiguration. miniupnpd wants to be able to
> > add/remove
On Tue, Apr 02, 2019 at 11:02:56AM +0200, Jan Danielsson wrote:
>2) Hey, I'm at a.b.c.d, and I would like external port X to redirect
> to me at port Y. (NAT rule, this isn't supported yet).
OK, but that is easy to add.
Martin
On Thu, Apr 04, 2019 at 10:33:47PM +0100, Mindaugas Rasiukevicius wrote:
> > - altq (Thor Lancelot Simon)
> Note: NPF can easily integrate with an already existing packet shaping
> mechanism, such as ALTQ, using packet/mbuf tagging. Writing NPF extensions
> to do such simple things like tagging i
On Thu, May 02, 2019 at 09:46:08AM +0200, yarl-bau...@mailoo.org wrote:
> Hello,
>
> What do you think of the following, at least the idea, the patch is probably
> not very clean?
> With this, i2c device driver module can use information gathered at i2cbus
> attachment.
> direct match is then po
Stupid question: since this is all very rare and non-performance critical,
why isn't it done as a single register per call? Adding more registers
when thy arrive in newer cpu variants, and not worrying about how they
are saved (XSAVE or similar) nor what format is used in the kernel?
So a debugger
On Tue, May 28, 2019 at 10:46:44AM -0700, Jason Thorpe wrote:
>
> > On May 28, 2019, at 10:37 AM, Martin Husemann wrote:
> >
> > Stupid question: since this is all very rare and non-performance critical,
> > why isn't it done as a single register per call? Ad
On Tue, May 28, 2019 at 10:54:45AM -0700, Jason Thorpe wrote:
> The registers are dumped in an ELF note in the same format that
> ptrace gets. We don't currently handle anything other than integer
> registers and basic FP registers in core files at the moment. Look for
> "coredump_note" in sys/ke
On Tue, May 28, 2019 at 07:50:34PM +0200, Micha? Górny wrote:
> Well, if we are only to consider new registers, then we're talking about
> 16 'pure' ymm registers + 32 zmm registers + 8 kN registers + 1 state
> register, multiply by two... 114 PT_* requests?
Integers are plenty, but the core file
On Sat, Jun 29, 2019 at 12:42:50AM +, paul.kon...@dell.com wrote:
> I'm baffled that this is even debatable. The system supports running
> 32 bit code in a 64 bit system. Obviously you must be able to debug
> such processes.
I totally agree, this is a must. Some architectures making it a PIT
On Sun, Jul 21, 2019 at 02:41:57PM +, co...@sdf.org wrote:
> hi,
>
> since netbsd won't stop using broken setups like xen (which don't
> provide randomness) to build packages, why don't we give up on
> /dev/random entirely?
Replacing the /dev/random device node by a symlink to /dev/urandom so
On Sun, Jul 21, 2019 at 06:33:27PM +, co...@sdf.org wrote:
> It currently blocks for literally hours/days. We can't have the OS not
> function due to this purity.
A rust build blocking (due to rustc or the rust libraries doing stupid
things) is very much different from "the OS not function".
On Tue, Aug 20, 2019 at 06:41:53AM +, Emmanuel Dreyfus wrote:
> On Mon, Aug 19, 2019 at 11:48:42AM -0400, Mouse wrote:
> > Is there any particular reason this was done?
>
> No sure about the change, but linkat(2) let you choose the behavior using
> the AT_SYMLINK_FOLLOW flag.
It may be unint
Hey folks,
I am trying to use vnconfig on an evbmip64-eb machine (ERLITE), with
a netbsd32 userland.
The ioctl conversion for VNDIOCSET fails, due to a size mismatch:
ioctl(0xc0284600 != c0244600 [VNDIOCSET32])
If I decode that correctly all is fine but the size of the argument structure,
which
On Wed, Sep 04, 2019 at 04:51:06AM +1000, matthew green wrote:
> this is bogus (thanks, 9 year old me.) can you try this?
> it removes the __packed and replaces references to the
> properly aligned types. compile tested only.
That works on mips, thanks!
Martin
On Thu, Sep 12, 2019 at 09:49:53PM -0700, Tom Spindler (moof) wrote:
> Maybe if xz were cranked down to -2 or -3 it'd be better at not
> that much of a compression loss, or it defaulted to the higher
> compression level only when doing a `build.sh release`.
If I remember the original size tests co
On Thu, Sep 12, 2019 at 09:49:53PM -0700, Tom Spindler (moof) wrote:
> > PS: The xz compression for the debug set takes 36 minutes on my machine.
> > We shoudl do something about it. Matt to use -T for more parallelism?
>
> On older machines, xz's default settings are pretty much unusable,
> and U
On Fri, Sep 13, 2019 at 06:59:42AM -0400, Greg Troxel wrote:
> I'd like us to keep somewhat separate the notions of:
>
> someone is doing build.sh release
>
> someone wants min-size sets at the expense of a lot of cpu time
>
>
> I regularly do build.sh release, and rsync the releasedir bits
On Fri, Sep 13, 2019 at 01:15:07PM +0200, Martin Husemann wrote:
> The default is MKDEBUG=no so you probably will not notice the compression
> difference that much.
>
> If you set MKDEBUG=yes you can just as easily set USE_XZ_SETS=no
> (or USE_PIGZGZIP=yes if you have pigz instal
On Fri, Sep 13, 2019 at 01:33:20AM +, Emmanuel Dreyfus wrote:
> Module Name: src
> Committed By: manu
> Date: Fri Sep 13 01:33:20 UTC 2019
>
> Modified Files:
> src/sys/kern: kern_subr.c
>
> Log Message:
> Accept root device specification as NAME=label
>
>
> To generate a dif
On Sat, Sep 14, 2019 at 06:26:34AM +, Martin Husemann wrote:
> > Log Message:
> > Accept root device specification as NAME=label
[..]
> Why is this needed?
>
> I have been using
>
> config netbsd root on "wedge:Guru-Root" ty
On Thu, Sep 26, 2019 at 07:21:17PM +0200, Kamil Rytarowski wrote:
> As I have proposed. MUSL+LTP for catching functional regressions/bugs
> AND fuzzing to catch crashes can be good enough to keep it trusted. The
> kernel certainly needs a lot of bug fixes, but instead of disabling this
> crucial fe
On Thu, Sep 26, 2019 at 09:40:22PM +0200, tlaro...@polynum.com wrote:
> If the vulnerabilities can only be exploited by running Linux binaries,
> IMHO, the point is moot: the ones that don't run Linux binaries are not
> affected; the ones that do need to run some Linux binaries will have to
> add t
On Fri, Sep 27, 2019 at 08:50:55PM +0200, Rhialto wrote:
> I have been pondering it for a while and it seems more complicated than
> I first thought... it seems that the actual value of delta isn't even
> important, but what rnd_delta_estimate() makes of it.
There is also the question whether it
Hey folks,
I am wondering, despite the fact that we are trying to phase out as many
uses of disklabels as fast as we can, if we should add an ioctl to the
disk devices that tells us if a label has been found.
Currently the only method to check a "blank" disk is to run
disklabel -r $mydis
On Mon, Sep 30, 2019 at 11:15:02AM +1000, matthew green wrote:
> however, disklabel fails at >2TiB for 512 byte sector, so i'm
> now thinking that fixing this doesn't really solve the problem
> for the future properly -- disklabel doesn't return a true
> label here anyway... so it seems that we sho
I guess noone would object a metafont2wsfont converter tool.
Look at the true type tool Michael mentioned in xsrc/local and do something
similar for metafont.
Martin
On Thu, Oct 03, 2019 at 02:42:10PM +0200, Rhialto wrote:
> I was thinking the other day that it might be useful if gpt had a
> subcommand to spit out a script to duplicate the partitioning of a disk,
> but without the "unique" parts. The script would of course be
> hand-editable for any changes one
On Thu, Oct 03, 2019 at 09:51:40AM -0600, Warner Losh wrote:
> NetBSD is, of course, free to do what it likes. My semi-outsider's view
> suggests, though, that the FreeBSD experience is relevant and timely.
So this discussion wandered off topic a bit. Of course NetBSD already
supports gpt and ther
Hi folks,
Constantine and I disagree on a small change he made recently. The issue
does not come up in any normal environment, and has apparently not happened
at all in the last years (or so). The bug is pretty old. Actually it is a
combination of several bugs that triggered it now:
- when confi
On Wed, Nov 06, 2019 at 12:31:37PM +0100, Maxime Villard wrote:
> __read_once(x)
> __write_once(x, val)
The names are really not helpfull for understanding what is supposed to happen
here.
Martin
On Wed, Nov 06, 2019 at 06:57:07AM -0800, Jason Thorpe wrote:
> > This matches atomic_load_relaxed() / atomic_write_relaxed(), but we do
> > not deal with atomics here.
>
> Fair enough. To me, the names suggest "compiler is allowed to apply
> relaxed constraints and tear the access if it wants"..
On Fri, Nov 22, 2019 at 08:42:19AM +0700, Robert Elz wrote:
> Date:Fri, 22 Nov 2019 01:04:56 +0100
> From:Kamil Rytarowski
> Message-ID: <1a9d9b40-42fe-be08-d7b3-e6ecead5b...@gmx.com>
>
>
> | I think that picking C11 terminology is the way forward.
>
> Use a name
On Sat, Dec 07, 2019 at 06:16:43AM -, Michael van Elst wrote:
> the overhead is still rather small (does a VAX have audio?).
Yes, I have a VAX with working audio (but you can ignore it for this
discussion ;-})
Martin
On Sun, Jan 05, 2020 at 09:01:33PM -0500, mo...@netbsd.org wrote:
> I'd be interested to hear any test results anyone cares to report.
It runs silently and exits with 0 for me on a netbsd-7, netbsd-8 and -current
machine (didn't try -9).
Martin
On Mon, Jan 13, 2020 at 05:32:13PM +1100, Simon Burge wrote:
> > One interesting point:
> >
> > Yours are
> > > wd0:
> > [ ... ]
> >
> > Mine is also Samsung SSD 860 EVO:
> > [ ... ]
I have:
wd0 at atabus0 drive 0
wd0:
wd0: drive supports 1-sector PIO transfers, LBA48 addressing
wd0: 476 GB,
On Mon, Jan 13, 2020 at 12:07:44PM +0100, Jaromír Dole?ek wrote:
> If they are known broken, seems we indeed need to add a quirk entry to
> disable NCQ for these drives, and push it into NetBSD 9.0 branch.
Please restrict to the affected sata controllers too.
I have:
ahcisata0 at pci2 dev 0 func
On Mon, Jan 13, 2020 at 10:39:19PM +1100, Simon Burge wrote:
> I _think_ the problem is restricted to 860 EVO drives, not 860 PRO drives.
Duh - sorry for not reading properly
Martin
On Tue, Feb 04, 2020 at 07:03:28AM -0400, Jared McNeill wrote:
> [...] Unfortunately the default ddb.onpanic=0
> strikes again and I can't get any more information than this:
[..]
> [ 364.3342263] dump to dev 92,33 not possible
> [ 364.3342263] rebooting...
I wonder if we should try to find out if
On Sat, Feb 08, 2020 at 06:19:43AM -0800, Paul Goyette wrote:
> The module should be MODULE_CLASS_DRIVER. And there should be a
> sys/module/fault/Makefile to build the module, along with changes to
> sys/module/Makefile (to descend into the fault directory) and to
> src/distrib/sets/lists/modules
On Sat, Feb 29, 2020 at 01:48:39AM +0530, Naman Jain wrote:
> Hi team,
>
> I am a final year undergraduate in Computer Science and Engineering at the
> Indian Institute of Technology, Kanpur. In the NetBSD project idea-list, I
> found the project for adding chdir() support for posix_spawn() quite
On Sun, Mar 08, 2020 at 09:58:05PM +0100, Kamil Rytarowski wrote:
> Aaron (as he was mentioned by name), is a voting member in the C++
> committee and actively working on harmonizing C and C++ standards. There
> is a good chance that C and C++ will be synced here (they definitely
> should).
Yes, t
On Mon, Mar 09, 2020 at 01:34:23PM +0100, Kamil Rytarowski wrote:
> We instruct a C compiler that pointer used in the pserialize macros is
> never NULL, as the side effect of adding to it 0.
I question that side effect.
The C++ standard disagrees with your interpration, I have not seen clear
sta
On Mon, Mar 09, 2020 at 09:38:31AM -0400, Aaron Ballman wrote:
> The way I read this is:
>
> "If the pointer operand points to an element of an array object" -- it
> does not (null is not a valid array object).
> "Moreover, if the expression P points to the last element of an array
> object" -- it
On Mon, Mar 09, 2020 at 12:41:37PM -0400, Aaron Ballman wrote:
> > You could view NULL as a special pointer pointing to an inaccessible
> > zero sized object. Adding 0 to it still points to the same special
> > non-object. I guess that is how the C++ folks see it.
>
> This wording has always been
On Thu, Mar 19, 2020 at 12:10:43PM +0530, Saketh Maddamsetty wrote:
> Hi, I am Saketh Maddamsetty, a third-year CSE student at IIT Kanpur. I am
> interested in the project "Tickless NetBSD with high-resolution timers".
>
> I have gone through the project description and have some doubts. Just
> w
-current just had a serious regression in test results, it seems like
~all networking tests are failing now:
Failed test cases:
dev/audio/t_audio:AUDIO_WSEEK,
lib/libc/sys/t_ptrace_sigchld:traceme_raise1,
lib/libc/sys/t_ptrace_wait:core_dump_procinfo,
lib/libc/sys/t_ptrace_wait3:core_dump_p
rump.route: SO_RERROR: Socket operation on non-socket
Many of the ones not failing "silently" show that.
Martin
On Mon, Mar 30, 2020 at 03:44:49PM +0300, Andreas Gustafsson wrote:
> Martin Husemann wrote:
> > -current just had a serious regression in test results, it seems like
> > ~all networking tests are failing now:
>
> Many (most?) of these have been failing for more than a week
On Mon, Mar 30, 2020 at 02:25:01PM -0400, Christos Zoulas wrote:
> What is your build host?
> I am running the latest build I installed built from NetBSD/current to
> NetBSD/current.
I see the same fallout on a NetBSD-current build on a NetBSD-current
(but it crept in delayed, probably because so
On Fri, Apr 03, 2020 at 06:04:44PM +0300, Andreas Gustafsson wrote:
> Christos Zoulas wrote:
> > >That should take care of the failing network related tests that contain
> > >rump.route commands, but that's not all of the failing tests.
> >
> > Thanks! I fixed that now. Let's see how many break af
On Sat, Apr 04, 2020 at 09:38:19AM -0400, Christos Zoulas wrote:
> I am still puzzled by this as the tests never failed on my machine!
I still see test failure on macppc and sparc64, some of them might
be related to libpcap being miscompiled (see my other PR).
Martin
On Mon, Apr 06, 2020 at 04:58:50PM +0300, John m0t wrote:
> Hello;
> I want to purchase a Tenda W311m wifi usb dongle with the RT5370
> chipset.
> I couldn't find anything related in my search.
> Does netbsd 9 support this dongle?
run0 at uhub6 port 2
run0: Ralink (0x148f) 802.11 n WLAN (0
On Mon, Apr 06, 2020 at 06:21:22PM +0300, John m0t wrote:
> Did you have that device?
> where is the excerpt from?
> and that is a good new; thank you.
Yes, I have that device and it works for me.
The excerpt was from the kernel boot messages of one of my systems (though
it is running -current,
On Mon, Apr 06, 2020 at 06:32:47PM +0300, John m0t wrote:
> Is your device tenda W311m?
Don't know - it is some random unbranded nano plug and I don't remember the
marketing name it came with originally.
Martin
On Wed, Apr 22, 2020 at 05:53:46PM -0400, Mouse wrote:
> s = splhigh()
> while (fewer than n samples copied)
> DMASYNC_POSTREAD for sample at offset o
That should be PREREAD (to make sure the dma'd data is visible for the
cpu)
>
On Mon, May 18, 2020 at 06:21:10PM -0400, Mouse wrote:
> >> Always encrypted swap would be even better but ... slow machines.
> > Compared to the time required to put the pages out to disk?
>
> That comparison is relevant only if the system has nothing better to do
> than wait for the page out/in.
Hey folks,
triggered by some experiments simonb did on mips I wrote a script to find
the functions using the bigest stack frame in my current sparc64 kernel.
The top 15 list is:
Frame/b Function
4096pci_conf_print at pci_subr.c:4812
4096dtv_demux_read at dtv_demux.c:493
3536SHA3_Self
On Sun, May 31, 2020 at 07:48:57AM -0400, Michael wrote:
> > 3248radeonfb_pickres at radeonfb.c:4127
> > 2304radeonfb_set_cursor at radeonfb.c:3690
>
> I'll deal with these unless someone wants to beat me to it.
Great!
I wonder what to do about twoway_memmem() - the memmem() function
see
On Mon, Jun 01, 2020 at 08:35:13PM +0200, Rocky Hotas wrote:
> pci_aprint_devinfo(pa, NULL);
>
> if (pci_mapreg_map(pa, FAA_MMREG_BAR, PCI_MAPREG_TYPE_MEM, 0,
> &sc->sc_regt, &sc->sc_regh, &sc->sc_reg_pa, 0) != 0 ) {
> aprint_error_dev(sc->sc_dev, "can't ma
On Wed, Jun 10, 2020 at 11:41:51AM +0200, Rocky Hotas wrote:
> Base address register at 0x10
> type: 32-bit nonprefetchable memory
> base: 0x1011
so it is PCI_MAPREG_TYPE_MEM ("memory" in the type line), and the mapping
should just work.
Does the map address (0x1011) make sense on tha
On Wed, Jun 10, 2020 at 04:12:03PM +0200, Radoslaw Kujawa wrote:
> I suspect there are two options: either something has bit-rotted in
> Cobalt-specific PCI code, or the ancient gxemul from 2012 does not work
> correctly anymore.
FWIW, Anders Gavare is quite responsive to email, if there is a hint
On Sun, Jun 14, 2020 at 09:07:45PM +, David Holland wrote:
> It seems to me that all of the following is mechanical and should be
> automatically generated, beyond what makesyscalls already does:
>- all the code that calls copyin/copyout
It is probably too early and I had too few coffee -
On Mon, Jun 15, 2020 at 10:56:04PM +, David Holland wrote:
> A less glib example: line 3186 of vfs_syscalls.c, in stat or more
> precisely sys___stat50, has a handwritten call to copyout() to
> transfer the stat results back to userspace.
OK, this could be improved if we had the IOR/IOW/IORW f
On Wed, Jun 17, 2020 at 11:36:11PM +, Taylor R Campbell wrote:
> Thoughts? Comments? Objections? Musical numbers by Groucho Marx on
> the nature of consensus?
I like all of it, especially the fpu kernel thread part you did leave
out for now, which I wanted since we started thinking about in
On Thu, Jun 18, 2020 at 10:26:10PM +, Taylor R Campbell wrote:
> # cpuctl identify 0 | grep -w AES
> cpu0: features1 0x7fbae3bf
> ^^^
> The highlighted part in `features1' is the important thing.
FWIW I did that on all amd64 machines I have in production and
On Fri, Jun 19, 2020 at 10:20:46AM +0100, Sevan Janiyan wrote:
>
>
> On 19/06/2020 07:37, Martin Husemann wrote:
> > the other two are quite old (probably on the border for your 10 years
> > estimate, maybe even slightly older and I'm suprised too, usualy
> > amd6
On Tue, Jun 23, 2020 at 11:14:30PM +0200, Jaromír Dole?ek wrote:
> No lazy FPU save logic please. It was eradicated from x86 for a reason:
> https://access.redhat.com/solutions/3485131
Taylor added code (in the proposed changes, not for general x86 context
switches) to avoid leaks like that in his
On Sat, Jul 04, 2020 at 02:00:04PM +0200, Jaromír Dole?ek wrote:
> Can anybody using clang please confirm kernel build with
> -Wframe-larger-than=3584?
Side note: 3584 is inacceptably large, we need to trim it down to ~1k.
Martin
On Tue, Jul 07, 2020 at 02:46:52PM +1000, Simon Burge wrote:
> ${GENASSYM} -- ${CC} ${CFLAGS:N-Wa,*} ${CPPFLAGS} ${PROF} \
> ${GENASSYM_CPPFLAGS} > assym.h.tmp && \
Can we instead delete the stack usage option in CFLAGS, CPPFLAGS or
GENASSYM_CPPFLAGS (wherever it ends up now)?
Hey folks,
I have two eMMC modules that with recentish -current do not work in my
Odroid C2 board (both used to work in older versions, but I don't know
when exactly it did break).
I enabled mmc debug and got the dump below.
Jared has one very similar module and it works for him (he also has ano
On Thu, Jul 16, 2020 at 03:07:59PM -, Michael van Elst wrote:
>
> >[ 1.6805785] sdmmc_mmc_command: cmd=5, arg=0, flags=0x4302
> >[ 1.6905781] sdmmc1: cmd 5 arg=0 data=0x0 dlen=0 flags=0x4302 (error 60)
>
> >[ 1.7305788] sdmmc_mmc_command: cmd=55, arg=0, flags=0x4432
> >[ 1.7305788] sd
I tried a brute force change (replacing the SDMMC_LOCK/UNLOCK macros)
and this seems to get rid of some strange timings, but not solve the
problem.
Martin
[ 1.000] Found CTF at 0xc0d04ad0, size 0x88a3d
[ 1.000] Loaded initial symtab at 0xc0d8d510, strtab at
0xc000
On Tue, Sep 01, 2020 at 01:48:33AM +0100, Peter Kay wrote:
> I also note the GENERIC amd64 kernel includes a symbol table, and i386
> does not. I presume this is by design for space reasons?
I guess because DTRACE needs it?
You can get full kernel symbols by setting MKKDEBUG=yes in /etc/mk.conf
o
Hey folks,
we have two functions that get passed strange arguments for historic
reasons:
void ether_ifattach(struct ifnet *, const uint8_t *);
void ether_ifdetach(struct ifnet *);
Both functions do *not* work with arbitrary ifnet *, but require the
pointer to be part of struct et
On Tue, Sep 15, 2020 at 10:33:30AM +0200, Ignatios Souvatzis wrote:
> I notice, however, that you'd need to touch all ethernet (and, for
> symmetry, all FDDI) drivers. This is a lot of code.
Right, probably not worth the churn.
Martin
On Wed, Sep 16, 2020 at 12:05:26PM +0200, Anthony Mallet wrote:
> I was also wondering if it would be possible to pass arguments to the
> primary or secondary bootloader via reboot(2) and the boothowto
> flags. But this doesn't seem doable. Right?
This works fine on e.g. sparc*; I can do: shutdown
On Tue, Sep 22, 2020 at 02:12:19PM +0200, Manuel Bouyer wrote:
> So, how can it block ?
When the system never had enough entropy.
I would consider this a bug in the setup of the system, but as of now we do
not deal with it at all during installation, and on systems that are not
installed (bootabl
On Thu, Sep 24, 2020 at 06:37:43AM +, nia wrote:
> On Tue, Sep 22, 2020 at 02:32:23PM +0200, Manuel Bouyer wrote:
> > OK, so the printf should never happen when the system has been properly
> > configured. In this case I have no objection.
>
> No, it will happen frequently in VMs and on non-re
On Thu, Oct 01, 2020 at 05:57:12PM +0200, Manuel Bouyer wrote:
> Source Bits Type Flags
> /dev/random 0 ??? estimate, collect, v
[..]
> seed 0 ??? estimate, collect, v
No random number generator and you did not seed the machine.
On another
On Thu, Oct 01, 2020 at 06:30:29PM +0200, Manuel Bouyer wrote:
> that doens't explain why the other sources of entropy, which were working
> bedore, are not working any more.
I'll let Taylor explain that in more details (my own memorized management
summary: they used to lie and now don't - but th
On Tue, Nov 03, 2020 at 10:23:30PM +0100, Reinoud Zandijk wrote:
> To be clear, do we want to (keep) supporting legacy devices? Its not required
> in 1.0 and could clean up the code a lot!
Yes, we need that still, as not all hosts offer the newer ones.
Martin
On Tue, Nov 03, 2020 at 10:20:27PM +, co...@sdf.org wrote:
> The QEMU people mentioned that even if "legacy virtio" IDs are used,
> there's a bit to show that it's compatible with newer virtio.
> Things that claim old virtio probably do both old & new.
Yeah, but last I tried there were some en
501 - 600 of 707 matches
Mail list logo
