> On Jul 2, 2023, at 7:41 AM, Martin Husemann wrote:
>
> On Sat, Jul 01, 2023 at 05:47:53PM -0400, Andrew Cagney wrote:
>> just fyi, had to tweak this when building; to be honest I'm a bit puzzled
>
> Yes, puzzling - it is not clear what standard apple tools default to
> after latest
Is anyone out there using the “cxgb” driver for Chelsio T3 10GbE interfaces?
If so, please ping me off-list.
Merci d’avance!
-- thorpej
> On Aug 1, 2022, at 7:22 AM, Thomas Klausner wrote:
>
> On Mon, Aug 01, 2022 at 11:20:11PM +0900, Rin Okuyama wrote:
>> On 2022/08/01 23:13, Martin Husemann wrote:
>>> On Mon, Aug 01, 2022 at 03:57:19PM +0200, Thomas Klausner wrote:
The attached diff survived a complete amd64-current
> On Jun 24, 2022, at 11:02 AM, Brook Milligan wrote:
>
> build.sh works great to create, for example, binary/gzimg/armv7.img.gz.
>
> However, that is not necessarily a bootable image, at least on some systems.
> In addition, various u-boot magic files must be added to the FAT partition
> On Feb 16, 2022, at 1:51 AM, Thomas Klausner wrote:
>
> Hi!
>
> NetBSD recently got an eventfd interface which is supposedly
> compatible to Linux's.
>
> net/zeromq uses eventfds and has lots of assertions in its test code,
> and I looked at one of them. It basically makes a new eventfd
> On Feb 10, 2022, at 4:58 AM, Martin Husemann wrote:
>
> The kernel lock is held too long while the graphics card is configured.
> I have seen that with some Nvidia cards, where I just have not been able
> to boot LOCKDEBUG kernels (example in PR 55185).
>
> You can patch out the kernel
Hey folks...
Perhaps you, like me, are frustrated that USB serial devices can get enumerated
in non-deterministic ways, which makes putting those device names in
configuration files (such as /etc/remote) less than useful.
I threw together a little devpubd hook to fix this problem for those
> On Dec 8, 2021, at 10:52 AM, Greg A. Woods wrote:
>
> That's one bullet I've dodged entirely already since my oldest systems
> are running netbsd-5 stable. (Though in theory isn't there supposed to
> be COMPAT support for SA?)
int
compat_60_sys_sa_register(lwp_t *l,
const struct
> On Nov 24, 2021, at 8:13 AM, Jason Thorpe wrote:
>
>> Subsequent boot of the same kernel and userland didn't crash on shutdown.
>
> Ok, I have reviewed the code and I think I know what’s wrong… I misunderstood
> the semantics of (*fo_restart)(). Easy fix.
Ok,
> On Nov 23, 2021, at 9:48 PM, Chavdar Ivanov wrote:
>
> Were you using any programs that use eventfd(2)?
>
> (can't get it out of the quote for some reason)
>
> Most likely; I was using KDE atm; I usually quit any DE before shutting down,
> but on this occasion I didn't. Besides, this was
> On Nov 23, 2021, at 3:21 PM, Chavdar Ivanov wrote:
>
> Hi,
>
>
> On a kernel from yesterday - 22/11/2021 - upon 'shutdown -p now' I get:
>
> ...
>
> var/crash crash -M netbsd.50.core -N netbsd.50
> Crash version 9.99.92, image version 9.99.92.
> crash: _kvm_kvatop(0)
> Kernel compiled
> On Oct 20, 2021, at 5:27 AM, Jason Thorpe wrote:
>
>
>
>> On Oct 20, 2021, at 5:11 AM, Andreas Gustafsson wrote:
>>
>> This is a semi-automatically generated notice of a failure to run the
>> ATF test suite to completion on NetBSD-current/i386.
>
> On Oct 20, 2021, at 5:11 AM, Andreas Gustafsson wrote:
>
> This is a semi-automatically generated notice of a failure to run the
> ATF test suite to completion on NetBSD-current/i386.
>
> The systems panics at:
>
> lib/libposix/bsd/t_rename (409/913): 1 test cases
> rename: [
> On Sep 20, 2021, at 8:42 PM, Ryo ONODERA wrote:
>
> Hi,
>
> Thanks for your great work!!!
>
> C++ programs, for example pkgsrc/net/zeromq, use eventfd(2)
> however /usr/include/sys/eventfd.h does not support C++ use.
>
> Could you use __BEGIN_DECLS/__END_DECLS?
Oh! Yes, please feel
> On Aug 17, 2021, at 10:28 AM, Dave Tyson wrote:
>
> The device appears at address 0x77 (it's a BMP085) with i2cscan, the data
> sheet indicates the read address=0xEF/write address=0xEE. I just put 0x77 in
> the address field and assume the read/write bit on the wire is added based on
>
> On Aug 8, 2021, at 8:28 PM, bch wrote:
>
> > cvs update: `src/sys/dev/acpi/acpi_i2c.h' is no longer in the repository
>
>
> This is still wanted by acpi_i2c.c
CVS did the Wrong Thing (SHOCKER). Should be fixed now.
Thanks for bringing it to my attention!!
-- thorpej
The Qlogic ISP SCSI / FC driver PCI front-end appears to universally support
using 64-bit PCI DMA addresses, based on my reading of this code block in
isp_pci_dmasetup():
if (sizeof (bus_addr_t) > 4) {
if (rq->req_header.rqs_entry_type == RQSTYPE_T2RQS)
> On Jul 1, 2021, at 4:37 PM, Jason Thorpe wrote:
>
>> On Jul 1, 2021, at 1:53 PM, Björn Johannesson wrote:
>>
>>
>> Yep. That fixes the media problems. Great!
>> Would it be easy to backport the media fix to netbsd9?
>
> I think so, yes. I’ll se
> On Jul 1, 2021, at 1:53 PM, Björn Johannesson wrote:
>
>
> Yep. That fixes the media problems. Great!
> Would it be easy to backport the media fix to netbsd9?
I think so, yes. I’ll send a pull-up request for that.
Thanks for your patience with this!
-- thorpej
> On Jun 30, 2021, at 4:04 PM, Björn Johannesson wrote:
>
> -current Thinkpad A31
> # ifconfig -m ne2
> ne2: flags=0x8843 mtu 1500
> ec_capabilities=0x1
> ec_enabled=0
.
.
.
Ok, I think this should fix the media problem:
https://www.netbsd.org/~thorpej/dp8390-media-patch-v1.txt
> On Jun 30, 2021, at 2:31 PM, Björn Johannesson wrote:
>
> Hello again.
>
> We are really close now! :)
> We can now detach a card that has been used w/o kernel panic.
> Detaching a card that has not been used sends the detach event now.
Oh, great! I’m glad that whatever else I fixed had
> On Jun 29, 2021, at 4:35 PM, Björn Johannesson wrote:
>
> Hello and thanks again for looking into this. I really appreciate it.
No problem. It’s all of my MII / ifmedia locking changes that probably broke
it in the first place :-)
> We have some progress. The patch compiles after fixing
> On Jun 29, 2021, at 1:11 PM, Jason Thorpe wrote:
>
>
>
>> On Jun 29, 2021, at 9:50 AM, Jason Thorpe wrote:
>>
>> I’ll see if I can figure out the link change problem later.
>
> Ok, I think I see what’s wrong with the link change problem. Hold.
> On Jun 29, 2021, at 9:50 AM, Jason Thorpe wrote:
>
> I’ll see if I can figure out the link change problem later.
Ok, I think I see what’s wrong with the link change problem. Hold.
-- thorpej
> On Jun 29, 2021, at 9:31 AM, Jason Thorpe wrote:
>
>> Oh, I see what’s happening here… ifmedia_fini() is being called twice. Let
>> me see if I can de-tangle this quickly.
>
> Oh, actually, ifmedia_fini() is being called on an ifmedia structure that was
> never
> On Jun 29, 2021, at 9:29 AM, Jason Thorpe wrote:
>
>> On Jun 27, 2021, at 1:35 PM, Björn Johannesson wrote:
>>
>> Removing the card once it has been up and downed panics the kernel.
>>
>> [ 1567.2547189] uvm_fault(0xc158f1e0, 0, 2) -> 0xe
>> [
> On Jun 27, 2021, at 1:35 PM, Björn Johannesson wrote:
>
> Removing the card once it has been up and downed panics the kernel.
>
> [ 1567.2547189] uvm_fault(0xc158f1e0, 0, 2) -> 0xe
> [ 1567.3087962] fatal page fault in supervisor mode
> [ 1567.3639110] trap type 6 code 0x2 eip 0xc011808e cs
> On Jun 27, 2021, at 7:40 AM, Björn Johannesson wrote:
>
> Hello.
>
> Decided to try out -current/i386 on a Thinkpad A31. If I boot with, or insert,
> my ne(4) pcmcia card the kernel crashes. It works on NetBSD 9.
> The cardbus ex(4) or pcmcia wi(4) does not crash the kernel.
> I see there
> On Apr 28, 2021, at 1:11 AM, Chavdar Ivanov wrote:
>
> --- src/VBox/Additions/common/VBoxGuest/VBoxGuest-netbsd.c.ORIG
> 2021-04-28 08:30:19.546105988 +0100
> +++ src/VBox/Additions/common/VBoxGuest/VBoxGuest-netbsd.c
> 2021-04-28 08:35:01.833286272 +0100
> @@ -416,7 +416,12 @@
> if
> On Apr 27, 2021, at 5:23 PM, Valery Ushakov wrote:
>
> On Tue, Apr 27, 2021 at 21:45:10 +0100, Chavdar Ivanov wrote:
>
>> I switched early today my VirtualBox NetBSD-current guest; as usual, I
>> rebuilt the additions (it works without them, but it is better to have
>> them - e.g. without
> On Apr 24, 2021, at 4:44 PM, Jason Thorpe wrote:
>
> Folks --
>
> I just merged the thorpej-cfargs branch, which contains some
> mostly-mechanical cleanups and some small but very useful enhancements to the
> device auto configuration subsystem. I've made an effor
> On Apr 24, 2021, at 6:53 PM, Izumi Tsutsui wrote:
>
> thorpej@ wrote:
>
>> Folks --
>>
>> I just merged the thorpej-cfargs branch, which contains some
>> mostly-mechanical cleanups and some small but very useful enhancements
>> to the device auto configuration subsystem.
>
> Maybe
Folks --
I just merged the thorpej-cfargs branch, which contains some mostly-mechanical
cleanups and some small but very useful enhancements to the device auto
configuration subsystem. I've made an effort to build just about every kernel
config we have, and boot said kernel on a reasonable
> On Apr 24, 2021, at 5:42 AM, nia wrote:
>
> I wonder if there's an initialization order difference
> somewhere.
If you want to have control over the initialization order, you need to set
auto_ifconfig=NO. On one of my systems that has a bunch of Qemu VMs:
auto_ifconfig=NO
> On Apr 17, 2021, at 10:48 AM, Manuel Bouyer wrote:
>
> Well, the build fails later with the same error.
> Using "-V HOST_CFLAGS=-std=gnu99" allows the tools to build; maybe
> this should be the default ?
Just fix the code to not use that style of declaration?
-- thorpej
> On Jan 31, 2021, at 12:41 PM, Simon J. Gerraty wrote:
>
> David Holland wrote:
>> "static volatile sig_atomic_t reap_children;"
>
> I chose int (which is what sig_atomic_t is) for portability.
sig_atomic_t has been around for a fairly long time now, and NOT using it has a
negative
> On Jan 25, 2021, at 1:13 AM, Ryo ONODERA wrote:
>
> Hi,
>
> When my laptop builds NetBSD/amd64-current on NetBSD/amd64-current,
> I get the following error.
> My DTRACE7 kernel is almost as same as GENERIC, except no options DIAGNOSTIC.
>
> x.o ieee8023ad_lacp_sm_ptx.o
> On Jan 24, 2021, at 5:38 PM, Robert Elz wrote:
>
>Date:Sun, 24 Jan 2021 16:25:55 -0800
>From: Jason Thorpe
>Message-ID:
>
> | > If would be nice if rump weren't so bloody fragile.
>
> It would indeed.
>
> | I am not
> On Jan 24, 2021, at 12:10 PM, Jason Thorpe wrote:
>
>
>> On Jan 24, 2021, at 11:31 AM, Robert Elz wrote:
>>
>> /tmp/build/2021.01.24.17.44.16-i386/tools/lib/gcc/i486--netbsdelf/9.3.0/../../../../i486--netbsdelf/bin/ld:
>> /tmp/build/2021.01.24.17.44.1
> On Nov 10, 2020, at 5:49 PM, Brad Spencer wrote:
>
> --- sys/net/if_wg.c.DIST 2020-10-26 10:36:30.391354264 -0400
> +++ sys/net/if_wg.c 2020-10-30 19:13:46.910323221 -0400
> @@ -98,8 +98,8 @@
> #include
> #include
>
> -#ifdef INET6
> #include
> +#ifdef INET6
> #include
> #include
> On Nov 10, 2020, at 9:06 AM, Vincent DEFERT <20@defert.com> wrote:
>
>
> On 10/11/2020 17:53, Jason Thorpe wrote:
>> Yah, that's Amazon Smile, and NetBSD is already on it.
>
> Are there geographic restrictions to this program?
> I can't find it on smi
> On Nov 10, 2020, at 6:18 AM, Jeffrey Walton wrote:
>
> NetBSD should consider Amazon, too. They have a program for donations
> to nonprofits. Amazon is a big marketplace with lots of users. The
> trust relationship is already in place for millions of potential
> donors.
Yah, that's Amazon
> On Aug 22, 2020, at 11:35 AM, Jason A. Donenfeld wrote:
>
> it needs to be done right,
Can you be specific about what is wrong?
-- thorpej
> On Aug 11, 2020, at 6:59 AM, Thomas Klausner wrote:
>
> Is this a known problem or should I file a bug report?
Always file a bug report :-)
-- thorpej
> On Jul 30, 2020, at 6:24 AM, MLH wrote:
>
> For about the last week I have started seeing usb configuration
> errors when various usb devices are plugged in. I went back to a
> Jul 7 kernel and all works great there but not sure when the problems
> started.
>
> With -current as of Jul 29,
> On Jun 29, 2020, at 5:13 PM, Kamil Rytarowski wrote:
>
>>
>> The atexit() function shall register the function pointed to by func, to be
>> called without arguments at normal program termination. At normal program
>> termination, all functions registered by the atexit() function shall be
> On Jun 29, 2020, at 9:09 AM, Rhialto wrote:
>
> But I wonder if there is any standards text that
> describes whether this particular scenario is supposed to work.
Quoting from "The Open Group Base Specifications Issue 7, 2018 edition"
The atexit() function shall register the function
> On Jun 26, 2020, at 9:09 AM, Julian Coleman wrote:
>
> Hi all,
>
>> We have a driver for this device in sys/dev/scsipi/if_se.c. It was pretty
>> popular with the pc532 crowd back in the day because SCSI was the only
>> expansion bus the pc532 had.
>>
>> There are changes coming to the
> On Jun 14, 2020, at 7:01 PM, Christos Zoulas wrote:
>
>
> Hello folks,
>
> I've renamed blacklist to blocklist, so if you are currently using it,
> you should rename things accordingly:
>
> - rc.conf variable
> - /var/db/blacklist.db file
> - npf table name
>
>
> On Jun 8, 2020, at 10:33 AM, Jason Thorpe wrote:
>
>
>> On Jun 8, 2020, at 10:02 AM, NetBSD Test Fixture wrote:
>>
>> This is an automatically generated notice of new failures of the
>> NetBSD test suite.
>>
>> T
> On Jun 8, 2020, at 10:02 AM, 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/t_ifconfig:ifconfig_description
>sbin/gpt/t_gpt:backup_2part
I think this is just a
> On Jun 6, 2020, at 10:19 AM, Jared McNeill wrote:
>
> On Sat, 6 Jun 2020, Jason Thorpe wrote:
>
>>
>>> On Jun 6, 2020, at 9:21 AM, Jared McNeill wrote:
>>>
>>> KASSERT-aside, I am left wondering based on that stack trace how copyout on
> On Jun 6, 2020, at 10:19 AM, Jared McNeill wrote:
>
> On Sat, 6 Jun 2020, Jason Thorpe wrote:
>
>>
>>> On Jun 6, 2020, at 9:21 AM, Jared McNeill wrote:
>>>
>>> KASSERT-aside, I am left wondering based on that stack trace how copyout on
> On Jun 6, 2020, at 9:21 AM, Jared McNeill wrote:
>
> KASSERT-aside, I am left wondering based on that stack trace how copyout on
> aarch64 can fail here at all (that seems to be the only way that lwp_exit
> from sys__lwp_create can happen).
What were you doing at the time? I guess
+rmind@
+ad@
> On Jun 6, 2020, at 5:00 AM, Jared McNeill wrote:
>
> Looks like I hit another one on this path with your latest fix in place:
>
> [ 3737.4034537] panic: kernel diagnostic assertion "l == curlwp ||
> ((l->l_flag & LW_SYSTEM) && pcu_valid == 0)" failed: file
>
> On Jun 1, 2020, at 6:36 AM, Kamil Rytarowski wrote:
>
> lwp_exit() used to work for curlwp and !curlwp.
>
> There is a regression that there was introduced code called from
> lwp_exit() calling lwp_thread_cleanup(l) that asserts curlwp,
> effectively enforcing lwp_exit() to be operational
> On Apr 29, 2020, at 1:56 PM, Robert Swindells wrote:
>
>
> On Apr 27, 2020, at 8:50 AM, Thomas Klausner wrote:
>>
>> I think this commit broke lang/oracle8-jre:
>
> Linux Java doesn't crash now for me but doesn't do much, top(1) shows it
> to be waiting on a futex.
>
> Tried doing "java
> On Apr 29, 2020, at 11:53 AM, Jason Thorpe wrote:
>
> What am I doing wrong?
>
> ../src/api/environment.cc: In function 'void
> node::SetIsolateCreateParamsForNode(v8::Isolate::CreateParams*)':
> ../src/api/environment.cc:215:39: error: 'uv_get_constrained_memory
What am I doing wrong?
../src/api/environment.cc: In function 'void
node::SetIsolateCreateParamsForNode(v8::Isolate::CreateParams*)':
../src/api/environment.cc:215:39: error: 'uv_get_constrained_memory' was not
declared in this scope
const uint64_t constrained_memory =
> On Apr 28, 2020, at 4:25 PM, Robert Swindells wrote:
>
> Jason Thorpe wrote:
>>> On Apr 27, 2020, at 8:50 AM, Thomas Klausner wrote:
>>>
>>> I think this commit broke lang/oracle8-jre:
>>
>> This is a Linux binary running under COMPAT_LINUX
> On Apr 27, 2020, at 8:50 AM, Thomas Klausner wrote:
>
> I think this commit broke lang/oracle8-jre:
This is a Linux binary running under COMPAT_LINUX? It would be strange if it
broke it because it essentially makes the whole system do what the Linux
emulation was already doing.
I'll
> On Mar 28, 2020, at 10:08 AM, Paul Goyette wrote:
>
> I've filed PR kern/55121 for this issue...
>
> I _do_ have a crash dump available if anyone wants me to provide any
> additional info.
I've analyzed the problem and have a fix. It's due to the incredibly misguided
DVF_DETACH_SHUTDOWN
> On Mar 22, 2020, at 12:34 PM, Andrew Doran wrote:
>
> This works well for me on amd64, but I haven't tried it on other machines.
> From code inspection I can see that some architectures need more work so
> this is disabled on them until I can make the needed changes: hppa, mips,
> powerpc
> On Mar 16, 2020, at 2:32 AM, Ignatios Souvatzis wrote:
>
> Ah, isn't scsi-ethernet something generic, so that the driver should be
> independent of chipset?
Not in the case of the driver were have, at least.
-- thorpej
Hey folks --
I've just checked in a large diff that implements an MP-safe locking protocol
for the ifmedia / mii layers used by many Ethernet and Wifi drivers. I've
tested this fairly extensively, and have gotten some testing help from others
as well. But I can't cover everything, so if you
We have a driver for this device in sys/dev/scsipi/if_se.c. It was pretty
popular with the pc532 crowd back in the day because SCSI was the only
expansion bus the pc532 had.
There are changes coming to the network stack and it's unlikely that (a) anyone
has such a device to test it, and (b)
> On Mar 12, 2020, at 6:36 PM, SAITOH Masanobu wrote:
>
> I have some cards. Those are too old, some cards doesn't work (broken).
I agree they're too old :-). I mainly care about making sure I break the
minimal set when working on net_mpsafe stuff. I know this driver worked on
Alpha and
Is anyone currently using fxp(4) successfully? I am having trouble with link
stability on a new-in-box i82559 card, but on a non-x86 platform.
Thx.
-- thorpej
> On Mar 1, 2020, at 7:56 AM, Andreas Gustafsson wrote:
>
> Are you saying fixing one or the other is not your responsibility,
> and if so, whose?
What I'm saying is it doesn't reflect a bug in the core functionality. I
acknowledge that it's an issue that needs to be addressed, but there
> On Mar 1, 2020, at 8:05 AM, Andrius V wrote:
>
> Hi,
>
> Was the build failure noticed? Seems like this commit is at fault:
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/pci/if_stge.c.diff?r1=1.79=1.80_with_tag=MAIN=h
>
Working on this now.
> ../../../../dev/pci/if_stge.c: In
> On Feb 8, 2020, at 4:04 PM, Paul Goyette wrote:
>
> The package no longer builds. Fails with (among others)
>
> error: 'struct ifnet' has no member named 'if_ibytes'; did you mean
> 'if_index'?
"struct ifnet" is private to the kernel. This application should be using the
properly
Oh, I see what I did wrong there. Nick and I missed this in our testing because
we didn't get link-change interrupts. I'll fix this now.
> On Feb 7, 2020, at 2:47 AM, Jaromír Doleček wrote:
>
> [ 11.1618248] panic: LOCKDEBUG: Mutex error: mutex_vector_enter,509:
> assertion failed:
> On Feb 7, 2020, at 12:40 AM, Jason Thorpe wrote:
>
> Actually, I just got confirmation from nick that my patch fixes the problem,
> so I’ll check it in shortly.
Ok, this should be fixed now. Please let me know if you encounter any problems
with it.
-- thorpej
Actually, I just got confirmation from nick that my patch fixes the problem, so
I’ll check it in shortly.
-- thorpej
Sent from my iPhone.
> On Feb 7, 2020, at 12:35 AM, Jason Thorpe wrote:
>
> I have a potential fix for that that I can send you shortly ... the link
> state ch
I have a potential fix for that that I can send you shortly ... the link state
change handler needs to be a work queue instead of a soft int. Can you test it?
-- thorpej
Sent from my iPhone.
> On Feb 6, 2020, at 11:41 PM, Jaromír Doleček
> wrote:
>
> Hi,
>
> I get repeatable panic with
> On Jan 20, 2020, at 3:44 PM, Christos Zoulas wrote:
>
> In article <20200120185023.gd28...@homeworld.netbsd.org>,
> Andrew Doran wrote:
>> Fix committed with sys/kern/kern_rwlock.c rev 1.62. I didn't see the
>> problem as I am running with LOCKDEBUG.
>>
>> Apologies for the disruption.
>
Folks --
I'm planning to remove the "le at pci" attachment ... it has long since been
supplanted by the pcn(4) driver, which supports a lot more PCnet-PCI chips, and
also does direct DMA from memory rather than copying to/from a fixed buffer.
If you're using "le at pci", please stop and switch
> On Dec 23, 2019, at 12:08 PM, Chavdar Ivanov wrote:
>
> I don't know if it is to do with similar, but I am getting on amd64:
This is already fixed:
$NetBSD: xen_intr.c,v 1.18 2019/12/23 13:35:37 thorpej Exp $
$NetBSD: intr.h,v 1.53 2019/12/23 13:35:37 thorpej Exp $
(...under
> On Dec 5, 2019, at 4:26 AM, David Brownlee wrote:
>
> In the LSI/mfii arena:
>
> The 3008 based LSI cards (LSI 9340-8i or IBM M1215) seem quite nice,
> though I'd probably need a cable adaptor for the ports. Or I could
> step back to a 2008 card like the LSI SAS 9211-8i and not worry about
> On Aug 15, 2019, at 8:15 PM, John Franklin wrote:
>
> because I usually use the Ubiquiti APs for WiFi. For WiFi performance and
> management on a budget, they’re hard to beat.
+1. I use Ubiquiti to cover the 3 levels of my house + back yard, and it works
flawlessly (total of 4 APs to do
> On May 29, 2019, at 11:02 AM, matthew green wrote:
>
> i was hoping to find time to bisect the intel driver tree from
> the 2014-snapshot to the top of tree to find where the display
> issues appeared, but perhaps we should switch back to the old
> driver for now until i or someone has
> On May 29, 2019, at 5:36 AM, Paul Goyette wrote:
>
> I am curious why we need to apparently build all of the LLVM stuff for a
> release? If LLVM is needed as part of the build, it should be built as
> host tools; I don't understand why we _also_ need to build LLVM for the
> target machine.
> On May 16, 2019, at 5:18 PM, Mathew, Cherry G. wrote:
>
> Silly unrelated question. Does anyone have pinebook 'ROM' image originals
> somewhere for download ?
I preserved mine (and installed a 64GB module in its place that has my NetBSD
install). I have a Pine64 eMMC->USB adapter, so I
> On May 14, 2019, at 9:33 AM, Ron Georgia wrote:
>
> If I understand correctly:
> 1. boot Pinebook from microSD loaded with Pinebook NetBSD ARM Bootable Images
> from https://www.invisible.ca/arm/
> 2. download arm64.img from
>
FYI -- this has already been fixed.
> On May 7, 2019, at 10:06 PM, NetBSD Test Fixture wrote:
>
> This is an automatically generated notice of a NetBSD-current/i386
> build failure.
>
> The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
> using sources from CVS date
> On May 7, 2019, at 4:54 PM, Andrew Luke Nesbit
> wrote:
> This is a really great thread, which I am enjoying very much.
>
> I don't use any BPi because I am a user of Orange Pi (especially the
> OPi+2E).
>
> But considering they are very close in architecture and use
> (essentially) the
> On May 7, 2019, at 2:37 PM, Jared McNeill wrote:
>
> On Tue, 7 May 2019, Markus Kilbinger wrote:
>
>> - I was not able to bootarm.efi this kernel from its local ffs2 (!)
>> netbsd partition on the sdcrad. Is bootarm.efi limited to ffs1?
>
> It uses ffs support from libsa, so I would
> On Apr 8, 2019, at 2:40 PM, Julian Coleman wrote:
>
> Hi all,
>
> Upgraded my QNAP TS-201 (sandpoint) to current, and all binaries crash with:
What kind of CPU is in this device? It's possible that jemalloc is making a
page size assumption that isn't true for this particular powerpc CPU
> On Apr 6, 2019, at 7:52 AM, Jason Thorpe wrote:
>
>
>> /tmp/bracket/build/2019.04.06.11.54.25-sparc/tools/lib/gcc/sparc--netbsdelf/7.4.0/../../../../sparc--netbsdelf/bin/ld:
>> disabling relaxation; it will not work with multiple definitions
>> collect2: error
> On Apr 5, 2019, at 11:51 PM, Paul Goyette wrote:
>
> It seemts to me that the original intent of this directory was for
> "things that [help] test the modules system". But recently we seem
> to have acquired at least a couple entries here which are "module-
> that-help-test-other-things".
> On Apr 6, 2019, at 5:59 AM, Andreas Gustafsson wrote:
>
> The sparc build is also failing, with a different error than i386 and amd64:
>
> /tmp/bracket/build/2019.04.06.11.54.25-sparc/tools/bin/sparc--netbsdelf-gcc
> -shared -Wl,-soname,librump.so.0 -Wl,--warn-shared-textrel
>
> On Mar 26, 2019, at 8:17 AM, Michael van Elst wrote:
>
> That is not caught by QUEUEDEBUG but caused by QUEUEDEBUG.
Well, to be fair, the code had a use-after-free bug. ASAN might have caught it
as well.
-- thorpej
> On Mar 26, 2019, at 3:44 AM, Christoph Badura wrote:
>
> This is caught by QUEUEDEBUG.
>
> This is the relevant code in
> sys/dev/sysmon/sysmon_envsys.c:sysmon_envsys_unregister()
>
> TAILQ_FOREACH(edata, >sme_sensors_list, sensors_head) {
>
> On Mar 15, 2019, at 2:48 PM, Robert Elz wrote:
> Upon reflection, there is no hurry to fix this one, unlike the previous
> one which was screwing up the b5 tests - we (at least currently) have no
> tests which do anything as crazy as the code sequence to trigger this, so
> we can take our
> On Mar 15, 2019, at 2:56 PM, Robert Elz wrote:
>
> Actually, on a bit more reflection, perhaps the best way forward
> is to work out a better method of implementing the shm() stuff
> puerly out of uvm facilities (with minimal, less than is there now,
> extra data structs) - so
> On Mar 15, 2019, at 1:28 PM, Jason Thorpe wrote:
>
> bool
> uvm_map_entry_wiring_changed(
Minor nit... in retrospect, this function should be called
uvm_map_entry_wiring_will_change().
-- thorpej
Careful, Robert, you're going to end up the designated maintainer of UVM at
this rate :-)
> On Mar 15, 2019, at 12:11 PM, Robert Elz wrote:
>
> However, the relationship between the shm() functions and the uvm
> (m*() functions) looks to be something of a mess - we really cannot keep
> a state
> On Mar 14, 2019, at 10:27 AM, Robert Elz wrote:
>
>Date:Thu, 14 Mar 2019 08:06:58 -0700
>From: Jason Thorpe
>Message-ID: <134778ad-a675-414a-bbb3-7eeeaf2c2...@me.com>
>
> | Great sleuthing, you pretty much nailed it.
>
> OK, g
On Mar 14, 2019, at 5:44 AM, Robert Elz wrote:
>
> am guessing at the UVMHIST_LOG() stuff (copy/paste/edit...)
>
> Does all of this sound plausible, and reasonable to do ?
> Please do remember, that before this, I have never been
> anywhere near uvm or anything pmap related, so have mercy!
> On Mar 13, 2019, at 10:27 AM, Robert Elz wrote:
>
> Some progress.
>
> #1 touching the buffer that malloc() returns (which is page aligned)
> made no difference - it is likely that the malloc llibrary would have
> done that in any case (the malloc is for just one page, so either it
> is
1 - 100 of 113 matches
Mail list logo
