Re: CVS commit: src

[Jason Thorpe]

> On Sep 3, 2019, at 5:04 AM, Sevan Janiyan  wrote:
> 
> On 03/09/2019 12:59, Brad Spencer wrote:
>> One possible alternative to that is to install OpenZFS on MacOS and
>> create a ZFS filesystem inside of whatever...
> 
> Or a disk image which is case sensitive (hfs/apfs) problem is then that
> it's slow.

If your Mac has APFS, it's not quite that bad -- you can create a new file 
system that's case-insensitive inside the same APFS container as the file 
system with your home directory and space-share with that file system (the 
default behavior).  You can do this all within Disk Utility without having to 
remember any command line magic.  There is not a performance penalty for this.  
And the case-sensitive path is a well-tested, since that's what iOS uses.

But there is definitely an annoyance penalty.  It's an extra step (or two) that 
shouldn't be necessary.  At least not without announcing the deprecation of 
support for case-insensitive host platforms, and providing a transition period 
for people rather than letting them be surprised (and then stuck) when they 
went to update their source tree.

For Macs that aren't on APFS (I have an iMac at home in this situations that I 
build on all the time), they're just screwed by this change.  Essentially, any 
Mac model that was not supported by macOS 10.14 is possibly stuck with HFS+ 
(this is because 10.13 only converted all-flash Macs to APFS; systems with HDDs 
remained on HFS+).

While we're at it, are we going to say that pkgsrc is now case-sensitive-only, 
too?  And if not, then why are we being lazy about src?

-- thorpej

Re: CVS commit: src

[Jason Thorpe]

> On Sep 2, 2019, at 10:36 PM, Robert Elz  wrote:
> 
> I doubt that any of them really are truly
> case insensitive ... rather than are insenstive to the case of ascii
> chars, and that's usually it.

APFS on macOS is truly case-insensitive, not just for ASCII.  FWIW.

-- thorpej

Re: CVS commit: src/sys

[Jason Thorpe]

> On Jul 23, 2019, at 10:07 AM, Jason Thorpe  wrote:
> 
> 
> 
>> On Jul 23, 2019, at 9:14 AM, Rin Okuyama  wrote:
>> 
>> Ah, you are right. We leaks uninitialized memory via mmap.
>> 
>> However, I'm not sure that it is safe to write DMA buffer
>> above sc->sc_vramsize after bus_dmamap_load?
>> 
>> Thoughts, ARM experts?

Also, didn't Jared make a change to the Allwinner u-boot configs that ensure 
the frame buffer is page-aligned?  Should we make that change everywhere?

> 
> Since fundamental memory allocation is done on page boundaries, would it 
> suffice to simply ensure that the "leaked" memory is zero'd out first?  I 
> mean, nothing else can use it for anything meaninful...
> 
> -- thorpej
> 

-- thorpej

Re: CVS commit: src/sys

[Jason Thorpe]

> On Jul 23, 2019, at 9:14 AM, Rin Okuyama  wrote:
> 
> Ah, you are right. We leaks uninitialized memory via mmap.
> 
> However, I'm not sure that it is safe to write DMA buffer
> above sc->sc_vramsize after bus_dmamap_load?
> 
> Thoughts, ARM experts?

Since fundamental memory allocation is done on page boundaries, would it 
suffice to simply ensure that the "leaked" memory is zero'd out first?  I mean, 
nothing else can use it for anything meaninful...

-- thorpej

Re: CVS commit: src/sys/compat/sys

[Jason Thorpe]

> On Jun 26, 2019, at 7:10 PM, matthew green  wrote:
> 
>> Always include the 32 bit structure and definitions on _LP64 regardless
>> of compat32 being on or off, because we want the headers to work when
>> compiling modular kernels. Of course the 32 bit structs do not make sense
>> on platforms that don't have 32 bit modes (alpha), but we don't have
>> a define for that and it does not hurt.
> 
> i've been using _LP64 && !__alpha__ for this when it strikes.
> 
> sub-optimal, but also easy to grep and find :-)

Perhaps we should define "_LP64_ONLY" in  for this type of 
situation?

-- thorpej

Re: CVS commit: src/sys/arch/x86/x86

[Jason Thorpe]

> On May 15, 2019, at 9:19 PM, Maxime Villard  wrote:
> 
> Le 16/05/2019 à 04:36, SAITOH Masanobu a écrit :
>> Module Name: src
>> Committed By:msaitoh
>> Date:Thu May 16 02:36:30 UTC 2019
>> Modified Files:
>>  src/sys/arch/x86/x86: procfs_machdep.c
>> Log Message:
>>  Use ci_feat_val[7] instead of directly getting cpuid 7 edx.
>> To generate a diff of this commit:
>> cvs rdiff -u -r1.28 -r1.29 src/sys/arch/x86/x86/procfs_machdep.c
>> Please note that diffs are not public domain; they are subject to the
>> copyright notices on the relevant files.
> 
> The microcode updates CPUID7, if you read ci_feat_val you have the
> initial value, not the updated value. So reading CPUID7 was the right
> thing to do.

Should the microcode update procedure fix up the cached copy?

-- thorpej

Re: CVS commit: src/sys

[Jason Thorpe]

> On May 13, 2019, at 7:17 AM, Greg Troxel  wrote:
> 
> 2) Your option 2 seems to involve two things at once:
> 
>  - migration to lwp_specificadata
>  - using DEBUG instead of DIAGNOSTIC to control the leak check feature
> 
> I do not understand why changing the nature of the implementation is
> linked to how it is enabled.

I think Ozaki-san saying that the 3% performance hit only happens when 
lwp_specificdata is used, and hence that it would need to be wrapped in DEBUG 
rather than DIAGNOSTIC.

The original negligible-impact implementation did NOT use lwp_specificdata, and 
thus was fine for DIAGNOSTIC.  I believe Ozaki-san's preference is to use 
*this* implementation so that it can be exposed to a wider audience.  The 
lwp_specificdata approach was only explored after someone else suggested a 
preference for it.

At least, that's my understanding of the situation.

Now, choose wisely :-)

-- thorpej

Re: CVS commit: src/tools

[Jason Thorpe]

> On May 7, 2019, at 3:52 PM, Herbert J. Skuhra  wrote:
> 
> On Tue, 07 May 2019 12:23:12 +0200, "J. Hannken-Illjes" wrote:
>> 
>> 
>>> On 7. May 2019, at 12:17, matthew green  wrote:
>>> 
 Diff is NOT reversed.
>>> 
>>> ah yes, i see.  please commit.
> 
> Crossbuilding is still broken.

I just checked in a fix for this.

> 
> On FreeBSD 12.0-STABLE (amd64) and Arch GNU/Linux building earmv7hf and amd64 
> I get:
> 
> #   compile  libprop/prop_dictionary.lo
> cc -O   -I/usr/home/herbert/source/netbsd/src/tools/libprop/../compat 
> -I/usr/home/herbert/source/netbsd/src/tools/libprop/../../common/include 
> -I/usr/home/herbert/source/netbsd/src/../build/earmv7hf/tools/include/nbinclude
>  -DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64  
> -I/usr/home/herbert/source/netbsd/src/../build/earmv7hf/tools/include 
> -I/usr/home/herbert/source/netbsd/src/../build/earmv7hf/tools/include/nbinclude
>  -c -o prop_dictionary.lo.o
> /usr/home/herbert/source/netbsd/src/tools/libprop/../../common/lib/libprop/prop_dictionary.c
> 
> /usr/home/herbert/source/netbsd/src/tools/libprop/../../common/lib/libprop/prop_dictionary.c:37:10:
>  fatal error: 'sys/rbtree.h' file not found 
> #include
>  
> ^~
> 
> 1 error generated.
>  
> 
> *** Failed target:  prop_dictionary.lo
> *** Failed command: cc -O 
> -I/usr/home/herbert/source/netbsd/src/tools/libprop/../compat 
> -I/usr/home/herbert/source/netbsd/src/tools/libprop/../../common/include 
> -I/usr/home/herbert/source/netbsd/src/../build/earmv7hf/tools/include/nbinclude
>  -DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 
> -I/usr/home/herbert/source/netbsd/src/../build/earmv7hf/tools/include 
> -I/usr/home/herbert/source/netbsd/src/../build/earmv7hf/tools/include/nbinclude
>  -c -o prop_dictionary.lo.o 
> /usr/home/herbert/source/netbsd/src/tools/libprop/../../common/lib/libprop/prop_dictionary.c
>  
> *** Error code 1
> 
> Stop.
> 
> -- 
> Herbert

-- thorpej

Re: CVS commit: src/tools

[Jason Thorpe]

I'll take a look at this this evening.

> On May 7, 2019, at 3:52 PM, Herbert J. Skuhra  wrote:
> 
> On Tue, 07 May 2019 12:23:12 +0200, "J. Hannken-Illjes" wrote:
>> 
>> 
>>> On 7. May 2019, at 12:17, matthew green  wrote:
>>> 
 Diff is NOT reversed.
>>> 
>>> ah yes, i see.  please commit.
> 
> Crossbuilding is still broken.
> 
> On FreeBSD 12.0-STABLE (amd64) and Arch GNU/Linux building earmv7hf and amd64 
> I get:
> 
> #   compile  libprop/prop_dictionary.lo
> cc -O   -I/usr/home/herbert/source/netbsd/src/tools/libprop/../compat 
> -I/usr/home/herbert/source/netbsd/src/tools/libprop/../../common/include 
> -I/usr/home/herbert/source/netbsd/src/../build/earmv7hf/tools/include/nbinclude
>  -DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64  
> -I/usr/home/herbert/source/netbsd/src/../build/earmv7hf/tools/include 
> -I/usr/home/herbert/source/netbsd/src/../build/earmv7hf/tools/include/nbinclude
>  -c -o prop_dictionary.lo.o
> /usr/home/herbert/source/netbsd/src/tools/libprop/../../common/lib/libprop/prop_dictionary.c
> 
> /usr/home/herbert/source/netbsd/src/tools/libprop/../../common/lib/libprop/prop_dictionary.c:37:10:
>  fatal error: 'sys/rbtree.h' file not found 
> #include
>  
> ^~
> 
> 1 error generated.
>  
> 
> *** Failed target:  prop_dictionary.lo
> *** Failed command: cc -O 
> -I/usr/home/herbert/source/netbsd/src/tools/libprop/../compat 
> -I/usr/home/herbert/source/netbsd/src/tools/libprop/../../common/include 
> -I/usr/home/herbert/source/netbsd/src/../build/earmv7hf/tools/include/nbinclude
>  -DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 
> -I/usr/home/herbert/source/netbsd/src/../build/earmv7hf/tools/include 
> -I/usr/home/herbert/source/netbsd/src/../build/earmv7hf/tools/include/nbinclude
>  -c -o prop_dictionary.lo.o 
> /usr/home/herbert/source/netbsd/src/tools/libprop/../../common/lib/libprop/prop_dictionary.c
>  
> *** Error code 1
> 
> Stop.
> 
> -- 
> Herbert

-- thorpej

Re: CVS commit: src/tools

[Jason Thorpe]

> On May 7, 2019, at 12:32 PM, matthew green  wrote:
> 
> did you start from a clean *tooldir*?  that would be the bit
> that matters.  if one had an existing tooldir with nbpax in
> it, then this problem wouldn't occur.
> 
> that's my only guess to what happened...

Yah, that's probably it.

-- thorpej

Re: CVS commit: src/tools

[Jason Thorpe]

> On May 7, 2019, at 3:17 AM, matthew green  wrote:
> 
>> Diff is NOT reversed.
> 
> ah yes, i see.  please commit.

I bootstrapped the whole system 3 or 4 times without having this extra 
dependency and didn't see a build failure, so I'm a little confused, but 
whatever.

Thanks for fixing it.

-- thorpej

Re: CVS commit: src/sys/compat/freebsd

[Jason Thorpe]

> On Apr 6, 2019, at 10:45 AM, Robert Elz  wrote:
> 
> Actually, fetching & storing registers (register_t) is a common enough
> thing that it might be worth having ufetch_reg (and ustore_reg), probably
> as MD #defines that map into one of the other calls.

The only situation I know of where it's wacky is sparc64-built-as-ILP32 and 
mips64-built-as-ILP32, where register_t is 64-bit and long is 32-bit.

-- thorpej

Re: CVS commit: src/sys/arch/x86/acpi

[Jason Thorpe]

> On Mar 3, 2019, at 10:31 AM, m...@netbsd.org wrote:
> 
> Maybe we can use the longer name to avoid the confusion? PG_WIRED
> 
> (PG_W as writable exists in other archs, and there's precedence for
> PG_WIRED too)

Agreed, PG_WIRED is a better name for this.

-- thorpej

Re: CVS commit: src/sys/dev/pci

[Jason Thorpe]

> On Jan 28, 2019, at 8:11 AM, Masanobu SAITOH  wrote:
> 
> On 2019/01/28 15:07, Jason Thorpe wrote:
>> Doesn’t it seem a little dangerous to just blindly enable?
> 
> You mean it should be enable only when the secondary bridge is configured
> correctly?
> 
> Both FreeBSD and OpenBSD blindly enabled it. One of the difference between
> NetBSD and others is that they configure unconfigured bridge.

Right, if the address decoders aren't programmed properly, it seems like you 
could get into all sorts of trouble.

I really feel like the correct way to solve the problem is to fully configure 
the bus using information from ACPI.

-- thorpej

Re: CVS commit: src/sys/dev/pci

[Jason Thorpe]

Doesn’t it seem a little dangerous to just blindly enable?

-- thorpej
Sent from my iPhone.

> On Jan 28, 2019, at 6:09 AM, SAITOH Masanobu  wrote:
> 
> Module Name:src
> Committed By:msaitoh
> Date:Mon Jan 28 04:09:51 UTC 2019
> 
> Modified Files:
>src/sys/dev/pci: ppb.c
> 
> Log Message:
> Explicitly enable bus masterling in case BIOS, UEFI or firmware don't enable
> it. Might fix PR kern/53811.
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.65 -r1.66 src/sys/dev/pci/ppb.c
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 

Re: CVS commit: src/etc

[Jason Thorpe]

> On Jan 13, 2019, at 5:08 PM, David Holland 
>  wrote:
> 
> Is there a way we could, for example, leverage the current hacks for
> chowning console devices to grant access to wpa_supplicant?

Some of this could be achieved with ttyaction(5), certainly.

-- thorpej

Re: CVS commit: src/etc

[Jason Thorpe]

> On Jan 13, 2019, at 5:21 AM, Greg Troxel  wrote:
> 
> Even if you have to be root, these changes are still hugely useful.
> "sudo wpa_cli" is not that hard, even if it seems like it should not be
> necessary.

...but made slightly more annoying seeing as how sudo is not part of the base 
OS.

-- thorpej

Re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys/dev/usb)

[Jason Thorpe]

> On Jan 6, 2019, at 5:36 AM, Martin Husemann  wrote:
> 
> On Sun, Jan 06, 2019 at 08:31:53AM -0500, Greg Troxel wrote:
>> Why do we generate code with unaligned access in user space?  That seems
>> surprising, if the processor isn't happy about it.
> 
> The processor is happy with it, both in user- and kernel space.
> Only special memory regions mapped uncached make it trap.

There is a performance penalty for unaligned accesses, and not even all ARM 
versions can do it in a way that produces the expected results.  The device in 
question here is a USB device, and we support pre-ARMv6 systems that have USB 
capability.

> Nick suggest to change the mapping for bus_dma to cached, which would avoid
> the issue but may expose bugs in device drivers.

That's probably a good idea in any case, because there will almost certainly be 
a performance benefit, but I still think ensuring that drivers don't perform 
unaligned accesses is desirable.

-- thorpej

Re: CVS commit: src

[Jason Thorpe]

> On Jan 1, 2019, at 9:53 PM, m...@netbsd.org wrote:
> 
>> You're conflating two things that aren't related.  Mesa's use of LLVM is 
>> conceptually similar to the "Canadian cross", and at no point should the 
>> compiler run-times of the "build", "host", or "target" systems ever 
>> intermingle.
> 
> How come?
> 
> If an arrow means dynamic linking,
> 
> Octave -> Octave JIT -> LLVM 1
> |
> Mesa
> |
> LLVM 2
> 
> LLVM1 has someFunction(int x, int y)
> LLVM2 has someFunction(int x)

Yes, I see your point and it's clear that I misunderstood what you were saying. 
 But, the email I sent directly following addresses this situation.  My 
suggested solution would be:

Octave -> Octave JIT -> LLVM 1
|
Mesa
|
LLVM2-but-with-renamed-symbols-that-only-Mesa-knows, so you'd have:

LLVM1's someFunction(int x, int y)
...and...
LLVM2's __Mesa_Private_LLVM_someFunction(int x)

This could be done using the same mechanism by which we rename symbols in libc, 
or as a separate post-processing step similar to what librump does.

> I'm under the impression that, due to the flat namespace, whether a call
> to someFunction works correctly depends on which symbol is picked up
> first, LLVM1's or LLVM2's.
> 
> And, this applies to in-library calls in LLVM too.
> 
> This does seem to be the case. if I load a WebGL thing,
> 
>> pmap -p `pgrep firefox` |grep -i llvm
> 777D9FA0  56024K read/exec /usr/pkg/lib/libLLVM-7.so
> 777DA30B6000   2044K   /usr/pkg/lib/libLLVM-7.so
> ..
> 
> Fortunately Firefox does not use LLVM twice in different ways, so
> failures don't happen.
> (Also the Octave scenario is not possible any more)

...also, it seems like the GNU-style symbol versioning support might be another 
way to solve this, yah?

-- thorpej

Re: CVS commit: src

[Jason Thorpe]

> On Jan 1, 2019, at 9:23 PM, m...@netbsd.org wrote:
> 
> I'll note I don't know of a single package using LLVM and a library as
> well as libGL, even though it looks like it should be a likely scenario.
> 
> The closest example was Octave that uses 3D graphs (with acceleration)
> and at some opint had a LLVM-based JIT, but had given up on it because
> it was an unexpected amount of work to keep up with LLVM.

If this is something we're concerned about, then the right thing to would be to 
make a private version of the LLVM libraries with symbols renamed into a 
private namespace for Mesa to use, so that an application linking against Mesa 
*and* some other version of LLVM's internals would work.

-- thorpej

Re: CVS commit: src

[Jason Thorpe]

> On Jan 1, 2019, at 8:26 PM, m...@netbsd.org wrote:
> 
> Having two versions of LLVM in use by a binary is going to fail in
> surprising ways.
> 
> Base can be several years old at some point, increasing the odds of the
> LLVM non-compatibility biting us.
> And libGL is very widely used.

You're conflating two things that aren't related.  Mesa's use of LLVM is 
conceptually similar to the "Canadian cross", and at no point should the 
compiler run-times of the "build", "host", or "target" systems ever intermingle.

-- thorpej

Re: CVS commit: src

[Jason Thorpe]

> On Jan 1, 2019, at 11:23 AM, Martin Husemann  wrote:
> 
> Yeah (and to waste more than an additional hour in a full build of
> NetBSD) - but then we need a working plan how to provide libllvm as
> part of the installed system, not only headers for building libmesa.

I'm not arguing the merits of it one way or the other, just trying to explain 
why it's needed in this particular instance.  I agree that the issues involved 
here are thorny (especially if LLVM isn't providing API / ABI stability from 
release to release), and there are a lot of trade-offs to be weighed.

But I really just wanted to point out that this isn't really a toolchain issue. 
 IMO, the best way to handle this situation is to decouple "LLVM used to 
provide JIT / VM services to system libraries or other subsystems" from "LLVM 
used as compiler toolchain component".  The former, which is what Maya needs in 
this case, is something that can be updated on a different frequency from the 
latter (at the cost of source tree bloat, but whatever, not that big of a 
deal), and can be narrowed in scope (don't necessarily need the language 
front-ends or CPU-target back-ends that the normal compiler toolchain requires).

-- thorpej

Re: CVS commit: src

[Jason Thorpe]

> On Jan 1, 2019, at 8:02 AM, Robert Swindells  wrote:
> 
> How does the usage of libLLVM from MesaLib make use of the LLVM headers
> at *runtime* ?
> 
> If they are not needed at runtime then why do they need to be installed
> on a target machine ?

What's needed on the target machine are the LLVM libraries, and the headers are 
needed to use the APIs provided by those libraries.  This isn't any different 
than the target system's libc needing the headers installed that define the 
interfaces to libc so that some application that also runs on the target can 
use functions from libc.  The headers are needed so that MesaLib can get the 
interface descriptions for functions in the LLVM libraries, which it links 
against.

LLVM is more than just a build-time host tool... more and more it is being used 
to provide system run-time services on the target system, and I'm not talking 
about what is traditionally referred to as the "compiler runtime" (e.g. the 
libgcc analogue) ... I'm referring to the compiler (and the virtual machine it 
implements) itself.

-- thorpej

Re: CVS commit: src

[Jason Thorpe]

> On Jan 1, 2019, at 6:34 AM, Martin Husemann  wrote:
> 
> Can you explain how the MesaLib build uses llvm?
> 
> This kinda sounds like you need a special build time binary that would
> live in $TOOLDIR and it is not exactly clear how installing some headers
> helps building this tool (as you can not assume a NetBSD build host).

LLVM is used in the graphics pipeline at run-time to generate native code that 
runs on the GPU.

-- thorpej

Re: CVS commit: src/sys/arch/evbmips/conf

[Jason Thorpe]

> On Dec 30, 2018, at 4:34 PM, Sevan Janiyan  wrote:
> 
> On 30/12/2018 16:16, Jason Thorpe wrote:
>> Maybe create a std.evmips that the various std. files can
>> include to get options that you want for everything?
> 
> Noted, I was thinking about the pull up to the 8 branch and making that
> as easy as possible. I don't have anything else further at the moment,
> should I go ahead any way?

I would say pull this up to -8, and then make another cleanup pass.

> 
> 
> Sevan

-- thorpej

Re: CVS commit: src/sys/arch/evbmips/conf

[Jason Thorpe]

> On Dec 30, 2018, at 6:51 AM, Sevan Janiyan  wrote:
> 
> Modified Files:
>   src/sys/arch/evbmips/conf: ADM5120 ADM5120-NB ADM5120-USB ALCHEMY AP30
>   CI20 CPMBR1400 DB120 ERLITE GDIUM LINKITSMART7688 LOONGSON MALTA
>   MERAKI RB153 RB433UAH SBMIPS WGT624V3 XLSATX ZYXELKX

Maybe create a std.evmips that the various std. files can include to get 
options that you want for everything?

-- thorpej

Re: Weak x86 aliases

[Jason Thorpe]

> On Dec 28, 2018, at 10:14 AM, Mathew, Cherry G.  wrote:
> 
> ic, this probably explains why it's used sparingly so far. Thanks for the 
> explanation. I'll try to educate myself on this wrt enabling this for modload.

We use weak symbols all over the place in user space.  It's just that the 
kernel-resident linker doesn't support them (yet?), so we can't use them for 
symbols that are part of the ABI exposed to modules.

> The other option for me is a bunch of ugly #ifdefs , which I'm trying to 
> minimise.

Reducing #ifdefs is a laudable goal.

-- thorpej

Re: CVS commit: src

[Jason Thorpe]

> On Dec 26, 2018, at 4:11 PM, Taylor R Campbell 
>  wrote:
> 
> Job reference counting is currently slightly busted -- my draft for
> threadpool_schedule_job didn't increment it correctly, and your
> threadpool_schedule_job doesn't handle failure in threadpool_job_hold.


Ok, I looked at this some last night, and was up early this morning and took a 
peek at it again, and I think getting rid of the refcnt is going to be tough.

The rub is the special handling of "assigned to overseer" in cancel_async.  
Because of that, you can't really use job_thread as a proxy for "held", and 
there's a small window in the overseer thread where neither the pool nor the 
job are locked because of locking order (which is job -> pool), yet the job is 
referenced; this happens when there is a thread to give the job to, we pull the 
job off the overseer queue, but we can't lock the job until we drop the tp_lock 
-- it's during that window where we have phantom reference that needs to be 
accounted for.

So, here's how I think it can be fixed:

-- Must continue to use atomics for job_hold / job_rele.

-- job_hold remains lockless, but job_rele can only be called **without** the 
job_lock held, because it needs to acquire the lock in the unlikely case it 
performs a cv_broadcast (see below).  Also need a job_rele_locked.

-- In schedule_job, always job_hold for either case (overseer or direct 
hand-off to idle thread).  This is the job's lifecycle reference, and will be 
dropped either in cancel_async or in job_done.

-- In cancel_async, only job_rele_locked after successfully removing it from 
the overseer queue (protected by tp_lock).  Note the job_lock is held by the 
caller of cancel_async.

-- In overseer thread, after grabbing a local reference to the job, do a 
job_hold before dropping the tp_lock, to prevent racing with cancel_async.  
This is a temporary hold while we do our work, and will always be released, 
regardless of job being cancelled beneath us or given to a thread.  Note the 
most likely scenario is that the job was NOT cancelled beneath us, and thus we 
will not be dropping the last reference, and therefore we don't want to take 
the job_lock again in this common case just to drop our temporary reference.

-- job_done should assert there is always at least 1 reference, and should 
directly decrement it rather than doing job_rele, because it already has the 
job_lock held and always does the cv_broadcast anyway.

-- Don't need to handle any overflow in job_hold / job_rele ... there reference 
count should ever one be 0 (totally idle), 1 (scheduled/running OR phantom 
reference), or 2 (scheduled AND phantom reference).  We can assert no overflow 
in job_hold.

-- thorpej

Re: Weak x86 aliases

[Jason Thorpe]

> On Dec 28, 2018, at 6:44 PM, John Nemeth  wrote:
> 
> However, having said that, I suspect that your work with PVHVM
> (and presumably PVH after that) will make the idea of having seperate
> modules for Xen obsolete.  I.e. it appears to me that we're headed
> to a world where a single kernel will work both on raw iron and
> under Xen.

Indeed, Xen x86(-64) modules should be completely compatible with normal 
x86(-64) modules.  If they're not, it means we're leaking too much internal goo 
into the ABI.

-- thorpej

Re: Weak x86 aliases

[Jason Thorpe]

> On Dec 28, 2018, at 1:32 PM, Paul Goyette  wrote:
> 
> The in-kernel linker doesn't deal with weak symbols at all.  It would
> need a lot of thought to get it right.  For example, if module A
> (containing a weak reference) gets loaded, its weak references don't
> resolve.  Then module B gets loaded and defines the symbol(s).  Do we
> "go back" and re-run the linker for module A?  Or do we allow the
> results to be different depending on module load order?  (If module B
> were loaded first, and then module A, the weak reference would get
> resolved.)

This is why we should't try to support them in the kernel :-)

-- thorpej

Re: Weak x86 aliases

[Jason Thorpe]

> On Dec 28, 2018, at 6:06 AM, Cherry G.Mathew  wrote:
> 
> I don't like the imperative in your tone. NVMM is the user of modloader,
> not PVHVM. So if you feel like your usecase needs fixing, I'd say it's
> your problem - or don't use modules, but see below.

...but as the person who committed the change that broke it, you're 
responsible.  His use case didn't need fixing until you introduced weak symbols 
that our kernel loader can't currently resolve.

-- thorpej

Re: CVS commit: src

[Jason Thorpe]

> On Dec 27, 2018, at 6:04 AM, Jason Thorpe  wrote:
> 
> -- job_hold remains lockless, but job_rele can only be called **without** the 
> job_lock held, because it needs to acquire the lock in the unlikely case it 
> performs a cv_broadcast (see below).  Also need a job_rele_locked.

Correction -- all cases of job_rele can be called with the job_lock held.  (I 
mis-read the block of the code in the overseer where the job_lock is dropped 
immediately before calling job_rele.)

Index: kern_threadpool.c
===
RCS file: /cvsroot/src/sys/kern/kern_threadpool.c,v
retrieving revision 1.12
diff -u -p -r1.12 kern_threadpool.c
--- kern_threadpool.c   27 Dec 2018 04:45:29 -  1.12
+++ kern_threadpool.c   27 Dec 2018 14:37:46 -
@@ -134,7 +134,7 @@ static void threadpool_percpu_destroy(st
 
 static threadpool_job_fn_t threadpool_job_dead;
 
-static int threadpool_job_hold(struct threadpool_job *);
+static voidthreadpool_job_hold(struct threadpool_job *);
 static voidthreadpool_job_rele(struct threadpool_job *);
 
 static voidthreadpool_overseer_thread(void *) __dead;
@@ -650,19 +650,16 @@ threadpool_job_destroy(struct threadpool
(void)strlcpy(job->job_name, "deadjob", sizeof(job->job_name));
 }
 
-static int
+static void
 threadpool_job_hold(struct threadpool_job *job)
 {
unsigned int refcnt;
 
do {
refcnt = job->job_refcnt;
-   if (refcnt == UINT_MAX)
-   return EBUSY;
+   KASSERT(refcnt != UINT_MAX);
} while (atomic_cas_uint(>job_refcnt, refcnt, (refcnt + 1))
!= refcnt);
-
-   return 0;
 }
 
 static void
@@ -670,16 +667,16 @@ threadpool_job_rele(struct threadpool_jo
 {
unsigned int refcnt;
 
+   KASSERT(mutex_owned(job->job_lock));
+
do {
refcnt = job->job_refcnt;
KASSERT(0 < refcnt);
if (refcnt == 1) {
-   mutex_enter(job->job_lock);
refcnt = atomic_dec_uint_nv(>job_refcnt);
KASSERT(refcnt != UINT_MAX);
if (refcnt == 0)
cv_broadcast(>job_cv);
-   mutex_exit(job->job_lock);
return;
}
} while (atomic_cas_uint(>job_refcnt, refcnt, (refcnt - 1))
@@ -703,6 +700,16 @@ threadpool_job_done(struct threadpool_jo
curlwp->l_name = job->job_thread->tpt_lwp_savedname;
lwp_unlock(curlwp);
 
+   /*
+* Inline the work of threadpool_job_rele(); the job is already
+* locked, the most likely scenario (XXXJRT only scenario?) is
+* that we're dropping the last reference (the one taken in
+* threadpool_schedule_job()), and we always do the cv_broadcast()
+* anyway.
+*/
+   KASSERT(0 < job->job_refcnt);
+   unsigned int refcnt __diagused = atomic_dec_uint_nv(>job_refcnt);
+   KASSERT(refcnt != UINT_MAX);
cv_broadcast(>job_cv);
job->job_thread = NULL;
 }
@@ -725,6 +732,8 @@ threadpool_schedule_job(struct threadpoo
return;
}
 
+   threadpool_job_hold(job);
+
/* Otherwise, try to assign a thread to the job.  */
mutex_spin_enter(>tp_lock);
if (__predict_false(TAILQ_EMPTY(>tp_idle_threads))) {
@@ -740,7 +749,6 @@ threadpool_schedule_job(struct threadpoo
__func__, job->job_name, job->job_thread));
TAILQ_REMOVE(>tp_idle_threads, job->job_thread,
tpt_entry);
-   threadpool_job_hold(job);
job->job_thread->tpt_job = job;
}
 
@@ -786,6 +794,7 @@ threadpool_cancel_job_async(struct threa
mutex_spin_enter(>tp_lock);
TAILQ_REMOVE(>tp_jobs, job, job_entry);
mutex_spin_exit(>tp_lock);
+   threadpool_job_rele(job);
return true;
} else {
/* Too late -- already running.  */
@@ -889,15 +898,13 @@ threadpool_overseer_thread(void *arg)
}
 
/* There are idle threads, so try giving one a job.  */
-   bool rele_job = true;
struct threadpool_job *const job = TAILQ_FIRST(>tp_jobs);
TAILQ_REMOVE(>tp_jobs, job, job_entry);
-   error = threadpool_job_hold(job);
-   if (error) {
-   TAILQ_INSERT_HEAD(>tp_jobs, job, job_entry);
-   (void)kpause("pooljob", false, hz, >tp_lock);
-   continue;
-   }
+   /*
+* Take an extra reference on the job temporarily so that
+* it won't disappear on us while we have both locks dropped.
+   

Re: CVS commit: src

[Jason Thorpe]

> On Dec 26, 2018, at 8:32 PM, Taylor R Campbell 
>  wrote:
> 
> LGTM if it works!

Doesn't trip any asserts in the unit tests... I'm going to push this in and 
then do the ref counting change as a separate commit.

-- thorpej

Re: CVS commit: src

[Jason Thorpe]

> On Dec 26, 2018, at 7:52 PM, Taylor R Campbell 
>  wrote:
> 
> Probably wanna dereference job->job_thread _before_ setting it to
> NULL!

Picky, picky :-)

Index: kern_threadpool.c
===
RCS file: /cvsroot/src/sys/kern/kern_threadpool.c,v
retrieving revision 1.11
diff -u -p -r1.11 kern_threadpool.c
--- kern_threadpool.c   26 Dec 2018 22:16:26 -  1.11
+++ kern_threadpool.c   27 Dec 2018 04:07:45 -
@@ -107,6 +107,7 @@ TAILQ_HEAD(thread_head, threadpool_threa
 
 struct threadpool_thread {
struct lwp  *tpt_lwp;
+   char*tpt_lwp_savedname;
struct threadpool   *tpt_pool;
struct threadpool_job   *tpt_job;
kcondvar_t  tpt_cv;
@@ -693,6 +694,15 @@ threadpool_job_done(struct threadpool_jo
KASSERT(job->job_thread != NULL);
KASSERT(job->job_thread->tpt_lwp == curlwp);
 
+   /*
+* We can safely read this field; it's only modified right before
+* we call the job work function, and we are only preserving it
+* use here; no one cares if it conains junk afterward.
+*/
+   lwp_lock(curlwp);
+   curlwp->l_name = job->job_thread->tpt_lwp_savedname;
+   lwp_unlock(curlwp);
+
cv_broadcast(>job_cv);
job->job_thread = NULL;
 }
@@ -977,24 +987,25 @@ threadpool_thread(void *arg)
 
struct threadpool_job *const job = thread->tpt_job;
KASSERT(job != NULL);
-   mutex_spin_exit(>tp_lock);
-
-   TP_LOG(("%s: running job '%s' on thread %p.\n",
-   __func__, job->job_name, thread));
 
/* Set our lwp name to reflect what job we're doing.  */
lwp_lock(curlwp);
-   char *const lwp_name = curlwp->l_name;
+   char *const lwp_name __diagused = curlwp->l_name;
+   thread->tpt_lwp_savedname = curlwp->l_name;
curlwp->l_name = job->job_name;
lwp_unlock(curlwp);
 
+   mutex_spin_exit(>tp_lock);
+
+   TP_LOG(("%s: running job '%s' on thread %p.\n",
+   __func__, job->job_name, thread));
+
/* Run the job.  */
(*job->job_fn)(job);
 
-   /* Restore our lwp name.  */
-   lwp_lock(curlwp);
-   curlwp->l_name = lwp_name;
-   lwp_unlock(curlwp);
+   /* lwp name restored in threadpool_job_done(). */
+   KASSERTMSG((curlwp->l_name == lwp_name),
+   "someone forgot to call threadpool_job_done()!");
 
/* Job is done and its name is unreferenced.  Release it.  */
threadpool_job_rele(job);


-- thorpej

Re: CVS commit: src

[Jason Thorpe]

> On Dec 26, 2018, at 4:11 PM, Taylor R Campbell 
>  wrote:
> 
> Caveat: Need to
>   take care of the lwp name in threadpool_job_done so that we never
>   point at the job_name of a job in oblivion.

Something like this.

Index: kern_threadpool.c
===
RCS file: /cvsroot/src/sys/kern/kern_threadpool.c,v
retrieving revision 1.11
diff -u -p -r1.11 kern_threadpool.c
--- kern_threadpool.c   26 Dec 2018 22:16:26 -  1.11
+++ kern_threadpool.c   27 Dec 2018 03:46:07 -
@@ -107,6 +107,7 @@ TAILQ_HEAD(thread_head, threadpool_threa
 
 struct threadpool_thread {
struct lwp  *tpt_lwp;
+   char*tpt_lwp_savedname;
struct threadpool   *tpt_pool;
struct threadpool_job   *tpt_job;
kcondvar_t  tpt_cv;
@@ -695,6 +696,15 @@ threadpool_job_done(struct threadpool_jo
 
cv_broadcast(>job_cv);
job->job_thread = NULL;
+
+   /*
+* We can safely read this field; it's only modified right before
+* we call the job work function, and we are only preserving it
+* use here; no one cares if it conains junk afterward.
+*/
+   lwp_lock(curlwp);
+   curlwp->l_name = job->job_thread->tpt_lwp_savedname;
+   lwp_unlock(curlwp);
 }
 
 void
@@ -977,24 +987,22 @@ threadpool_thread(void *arg)
 
struct threadpool_job *const job = thread->tpt_job;
KASSERT(job != NULL);
-   mutex_spin_exit(>tp_lock);
-
-   TP_LOG(("%s: running job '%s' on thread %p.\n",
-   __func__, job->job_name, thread));
 
/* Set our lwp name to reflect what job we're doing.  */
lwp_lock(curlwp);
-   char *const lwp_name = curlwp->l_name;
+   thread->tpt_lwp_savedname = curlwp->l_name;
curlwp->l_name = job->job_name;
lwp_unlock(curlwp);
 
+   mutex_spin_exit(>tp_lock);
+
+   TP_LOG(("%s: running job '%s' on thread %p.\n",
+   __func__, job->job_name, thread));
+
/* Run the job.  */
(*job->job_fn)(job);
 
-   /* Restore our lwp name.  */
-   lwp_lock(curlwp);
-   curlwp->l_name = lwp_name;
-   lwp_unlock(curlwp);
+   /* lwp name restored in threadpool_job_done(). */
 
/* Job is done and its name is unreferenced.  Release it.  */
threadpool_job_rele(job);


-- thorpej

Re: CVS commit: src

[Jason Thorpe]

> On Dec 26, 2018, at 5:25 PM, Jason Thorpe  wrote:
> 
> I think this the way to go.  I’ll look at it a little later tonight.
> 
> -- thorpej
> Sent from my iPhone.
> 
>> On Dec 26, 2018, at 4:11 PM, Taylor R Campbell 
>>  wrote:
>> 
>> 2. Chuck the job reference count altogether.  Just use job_thread as a
>>  proxy for whether it's in use.  User must not call
>>  threadpool_schedule_job concurrently with threadpool_job_destroy;
>>  if a job may have been scheduled, user must cancel it before
>>  destroying it.

To elaborate -- this is the same requirement in the task(9) API -- In fact, my 
unit test tripped over this requirement by virtue of using implicit-task-done, 
and so the safe thing to do is always cancel before destroying unless you're 
doing extra bookkeeping in the caller where you're using other means to ensure 
jobs / tasks are complete.

-- thorpej

Re: CVS commit: src

[Jason Thorpe]

I think this the way to go.  I’ll look at it a little later tonight.

-- thorpej
Sent from my iPhone.

> On Dec 26, 2018, at 4:11 PM, Taylor R Campbell 
>  wrote:
> 
> 2. Chuck the job reference count altogether.  Just use job_thread as a
>   proxy for whether it's in use.  User must not call
>   threadpool_schedule_job concurrently with threadpool_job_destroy;
>   if a job may have been scheduled, user must cancel it before
>   destroying it.

Re: CVS commit: src

[Jason Thorpe]

> On Dec 26, 2018, at 10:04 AM, Taylor R Campbell 
>  wrote:
> 
> Can you use a module initialization routine for this, or call it in
> main if you don't want to deal with modules, instead of sprinkling
> RUN_ONCE in various places?

I thought about using a module initializer, the timing of when it's run might 
be too late or too early (or maybe at a perfect time, if you're lucky).  I 
generally dislike static initialization functions if lazy initialization can be 
used reasonably, and I thought this was such an application for it, but it's 
not a hill I'm willing to die on, so static initialization it is.

> Can we just have struct threadpool_job in the header file like I did
> originally, without the strict aliasing violations, ABI conditionals,
> ?  What does this buy us?  We don't have a culture of abusing
> abstractions simply because they happen to be written in header files,
> so we don't need to put technical measures in the way of such abuse.

I reverted it.  I prefer truly opaque objects being presented to the clients of 
an API, but again, not this hill.

>> +/* Idle out threads after 30 seconds */
>> +#define THREADPOOL_IDLE_TICKS   mstohz(30 * 1000)
> 
> Maybe this should be a sysctl knob?

Yah, I'll add that a little later.

>> +struct threadpool_unbound {
>> +/* must be first; see threadpool_create() */
>> +struct threadpool   tpu_pool;
> 
> Why must this be first?  Unless this is really crucial for some
> performance-critical reason, let's try to avoid putting constraints
> like this into new code.

I've rearranged it so callers of threadpool_create() and threadpool_destroy() 
manage the storage themselves.

>> +#ifdef THREADPOOL_VERBOSE
>> +#define TP_LOG(x)   printf x
>> +#else
>> +#define TP_LOG(x)   /* nothing */
>> +#endif /* THREADPOOL_VERBOSE */
> 
> Maybe make these dtrace probes?

That is my plan.

> Atomics here don't hurt but are not necessary because this is always
> done when the caller has exclusive access to the pool.  (This was a
> mistake in the original, sorry!)  This should just do
> 
>   KASSERT(mutex_owned(>tp_lock));
>   pool->tp_refcnt++;
> 
> which will always succeed with a 64-bit reference count.

Done.

> The atomics here don't hurt, but the mutex operations do, because this
> is called with the threadpool's lock held.  (Again, mistake in the
> original, sorry!)  This should just do
> 
>   KASSERT(mutex_owned(>tp_lock));
>   KASSERT(0 < pool->tp_refcnt);
>   if (--pool->tp_refcnt == 0)
>   cv_broadcast(>tp_overseer.tpt_cv);

Done.  The recursive acquisition would have been really hard to trigger, which 
is why my unit test missed it.

> For this to work, threadpool_overseer_thread and threadpool_thread must
> call threadpool_rele while holding the lock.
> 
> There's no issue with doing that: they don't use the pool afterward,
> and destruction -- including mutex_destroy(>tp_lock) -- can't
> proceed until the thread that called threadpool_rele releases the lock
> too.
> 
> Alternative, requiring more rototilling: The overseer could just join
> the worker threads when dying, and threadpool_destroy could just join
> the overseer -- then we could skip the reference counting altogether.
> Not sure whether this is a net win in bookkeeping, though.

The additional bookkeeping cost doesn't seem work it ... having to actively 
track active threads in addition to the idle ones, and then having to join them 
one at a time.  The reference count game is a lot easier.

> Not a KNF rule, but I'd prefer it if either every branch is braced or
> no branch is braced, rather than a mixture of braced and unbraced
> branches in a single `if'.

Done.  (Well, at at least the lines I managed to find at a cursory glance.)

> 
>> +static int
>> +threadpool_job_hold(threadpool_job_impl_t *job)
>> +{
>> +unsigned int refcnt;
>> +do {
> 
> KNF, blank line between declarations and body.

Fixed.  (Deleting that line was a honest-to-goodness mistake.)

> 
>> +refcnt = job->job_refcnt;
>> +if (refcnt == UINT_MAX)
>> +return EBUSY;
>> +} while (atomic_cas_uint(>job_refcnt, refcnt, (refcnt + 1))
>> +!= refcnt);
>> +
> 
> Trailing whitespace.

F***ing vim.  I should install nvi on all of my Macs.

> (Consider (setq show-trailing-whitespace t) if you use Emacs!)

No thanks :-)

>> +bool
>> +threadpool_cancel_job_async(threadpool_t *pool, threadpool_job_t *ext_job)
>> +{
>> +threadpool_job_impl_t *job = THREADPOOL_JOB_TO_IMPL(ext_job);
>> +
>> +KASSERT(mutex_owned(job->job_lock));
>> +
>> +/*
>> + * XXXJRT This fails (albeit safely) when all of the following
>> + * are true:
>> + *
>> + *  => "pool" is something other than what the job was
>> + * scheduled on.  This can legitimately occur if,
>> + * for example, a job is percpu-scheduled on CPU0
>> + * and then CPU1 attempts 

Re: CVS commit: src/sys/kern

[Jason Thorpe]

> On Dec 24, 2018, at 9:51 PM, m...@netbsd.org wrote:
> 
> Heavily contended whitespace

Cage match material.

-- thorpej

Re: CVS commit: src/sys/dev/usb

[Jason Thorpe]

> On Dec 15, 2018, at 2:30 AM, SAITOH Masanobu  wrote:
> 
> Module Name:  src
> Committed By: msaitoh
> Date: Sat Dec 15 10:30:58 UTC 2018
> 
> Modified Files:
>   src/sys/dev/usb: if_urtwn.c
> 
> Log Message:
> Make IODATA WN-G150UMW work:
> - Increase delay to prevent "could not send firmware command". The value
>  is taken from FreeBSD.
> -Increase delay to prevent "timeout waiting for firmware readiness". The
>  vaule is taken from Linux.

This is worth a pull-up to netbsd-8, I think.  I get that firmware readiness 
error a lot on one of the urtwn devices I have on a RPI (I don't have I handy, 
so I can't tell you the exact model right now).

-- thorpej

Re: CVS commit: src/sys/dev/i2c

[Jason Thorpe]

> On Dec 14, 2018, at 2:05 PM, Michael Lorenz  wrote:
> 
> Module Name:  src
> Committed By: macallan
> Date: Fri Dec 14 22:05:36 UTC 2018
> 
> Modified Files:
>   src/sys/dev/i2c: ds1307.c files.i2c
> 
> Log Message:
> add options DSRTC_YEAR_START_2K for machines which use 2000 and not 1970
> as base to count years from, like Iyonix.
> While there apply the offset when writing to the clock as well.

This should not be done with a compile-time option.  A better way to handle 
this is to define a device property ("rtc-base-year" maybe?) as an and to use 
that if the property exists.  You can then set it in the iyonix 
device_register() function when you get a "dsrtc".

-- thorpej

Re: CVS commit: src/sys/net

[Jason Thorpe]

Panic seems not optimal.  A rate limited log message at LOG_ERROR seems better.

-- thorpej
Sent from my iPhone.

> On Dec 13, 2018, at 12:54 PM, Rin Okuyama  wrote:
> 
> Module Name:src
> Committed By:rin
> Date:Thu Dec 13 20:54:50 UTC 2018
> 
> Modified Files:
>src/sys/net: ether_sw_offload.c
> 
> Log Message:
> Panic rather than silently dropping packets when TX offload options are
> enabled for unsupported frame types.
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.3 -r1.4 src/sys/net/ether_sw_offload.c
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 

Re: CVS commit: src/sys

[Jason Thorpe]

Fixed.

> On Dec 9, 2018, at 7:50 AM, Jason Thorpe  wrote:
> 
> Investigating now...
> 
>> On Dec 9, 2018, at 7:39 AM, m...@netbsd.org wrote:
>> 
>> On Sat, Dec 08, 2018 at 05:46:15PM +, Jason R Thorpe wrote:
>>> @@ -2508,13 +2525,7 @@ comcnattach(bus_space_tag_t iot, bus_add
>>> {
>>> struct com_regs regs;
>>> 
>>> -   memset(, 0, sizeof regs);
>>> -   regs.cr_iot = iot;
>>> -   regs.cr_iobase = iobase;
>>> -   regs.cr_nports = COM_NPORTS;
>>> -#ifdef COM_REGMAP
>>> -   memcpy(regs.cr_map, com_std_map, sizeof (regs.cr_map));
>>> -#endif
>>> +   com_init_regs(, iot, (bus_space_handle_t)0/*XXX*/, iobase);
>>> 
>>> return comcnattach1(, rate, frequency, type, cflag);
>>> }
>> 
>> This breaks the build for sparc:
>> https://releng.netbsd.org/builds/HEAD/201812090350Z/sparc64.build.failed
>> 
>> /home/source/ab/HEAD/src/sys/dev/ic/com.c: In function 'comcnattach':
>> /home/source/ab/HEAD/src/sys/dev/ic/com.c:2511:2: error: conversion to 
>> non-scalar type requested
>> com_init_regs(, iot, (bus_space_handle_t)0/*XXX*/, iobase);
>> ^
>> 
>> Any idea?
> 
> -- thorpej
> 

-- thorpej

Re: CVS commit: src/sys

[Jason Thorpe]

Investigating now...

> On Dec 9, 2018, at 7:39 AM, m...@netbsd.org wrote:
> 
> On Sat, Dec 08, 2018 at 05:46:15PM +, Jason R Thorpe wrote:
>> @@ -2508,13 +2525,7 @@ comcnattach(bus_space_tag_t iot, bus_add
>> {
>>  struct com_regs regs;
>> 
>> -memset(, 0, sizeof regs);
>> -regs.cr_iot = iot;
>> -regs.cr_iobase = iobase;
>> -regs.cr_nports = COM_NPORTS;
>> -#ifdef  COM_REGMAP
>> -memcpy(regs.cr_map, com_std_map, sizeof (regs.cr_map));
>> -#endif
>> +com_init_regs(, iot, (bus_space_handle_t)0/*XXX*/, iobase);
>> 
>>  return comcnattach1(, rate, frequency, type, cflag);
>> }
> 
> This breaks the build for sparc:
> https://releng.netbsd.org/builds/HEAD/201812090350Z/sparc64.build.failed
> 
> /home/source/ab/HEAD/src/sys/dev/ic/com.c: In function 'comcnattach':
> /home/source/ab/HEAD/src/sys/dev/ic/com.c:2511:2: error: conversion to 
> non-scalar type requested
>  com_init_regs(, iot, (bus_space_handle_t)0/*XXX*/, iobase);
>  ^
> 
> Any idea?

-- thorpej

Re: CVS commit: src/sys/kern

[Jason Thorpe]

> On Dec 3, 2018, at 11:27 AM, Christos Zoulas  wrote:
> 
> I don't think that the things that KASLR randomizes by default are useful
> to debugging. I.e. you can't depend on two successive kernel crashes to
> have identical PTE addresses; OTOH you can depend that the text addresses
> are the same (which are for GENERIC and are not for GENERIC_KASLR).

Oh, that depends.  I would say if you are debugging a low-level VM problem, 
being able to have a predictable PTE address at the time of a crash could be 
VERY helpful.

-- thorpej

Re: CVS commit: src/sys/dev

[Jason Thorpe]

Shouldn't this be  instead?

IMO, pulling in  implicitly is generally harmful (there is a lot 
of namespace pollution there...)

> On Nov 19, 2018, at 9:23 AM, Maya Rashish  wrote:
> 
> Module Name:  src
> Committed By: maya
> Date: Mon Nov 19 09:23:05 UTC 2018
> 
> Modified Files:
>   src/sys/dev: audio_dai.h
> 
> Log Message:
> include sys/param.h for EINVAL used in this header.
> 
> (Make it more standalone)
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.2 -r1.3 src/sys/dev/audio_dai.h
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 

-- thorpej

Re: CVS commit: src/external/apache2/mDNSResponder/dist/mDNSPosix

[Jason Thorpe]

Thanks!  This has been bothering me for a while, but I hadn’t had a chance to 
look at it.

-- thorpej
Sent from my iPhone.

> On Nov 19, 2018, at 8:14 AM, Christos Zoulas  wrote:
> 
> Module Name:src
> Committed By:christos
> Date:Mon Nov 19 08:14:28 UTC 2018
> 
> Modified Files:
>src/external/apache2/mDNSResponder/dist/mDNSPosix: mDNSPosix.c
> 
> Log Message:
> It is not an error if we did not find any IPv4 interfaces. It could
> be the case we never have V4 interfaces (in a V6 system) so this
> is bogus. The code was recently changed to ignore loopback interfaces.
> If mdnsd was started too early, this means that no interfaces would
> be found (since interfaces down, with no addresses, or tentative
> are ignored). I put back the loopback interfaces yesterday to avoid
> this error, but this seems like the left hand not knowing what the
> right hand does because whoever removed the loopback interfaces
> from the list, did not read the 'self discovery' comment and the
> special code that deals with loopback in this file. Nevertheless,
> I think it is better to ignore the loopback interfaces in the long
> run, but it is ok to keep them around since the code is handling
> them just fine (and works both with and without them).
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.15 -r1.16 \
>src/external/apache2/mDNSResponder/dist/mDNSPosix/mDNSPosix.c
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 

Re: Merge majors.{arm32,aarch64} into single file (Re: CVS commit: src/sys/arch/evbarm/conf)

[Jason Thorpe]

> On Aug 18, 2018, at 5:02 PM, Rin Okuyama  wrote:
> 
> (1) rename majors.arm32 to majors.arm
> (2) remove majors.aarch64
> (3) make everyone include majors.arm
> 
> I will commit if there's no objection.


Correct.  Thank you for making this change.

-- thorpej

Re: CVS commit: src/sys/arch/evbarm/conf

[Jason Thorpe]

> On Aug 18, 2018, at 8:49 AM, Rin Okuyama  wrote:
> 
> On 2018/08/19 0:06, Jason Thorpe wrote:
>>> On 2018/08/18 20:08, Rin Okuyama wrote:
>>>> Ah, then it should be "if ARM32". It was "if arm32" in rev. 1.31.
>>> 
>>> Sorry, not 1.31 but 1.30.
>> That's because all options are normalized to lower-case.
> 
> Oops, not "if" but "ifdef".
> 
> "ifdef" statements refer "attrtab", whose entries are not normalized to
> lower-case. Therefore, "ifdef arm32" becomes false even if we have
> "options ARM32", as I wrote in the previous message:
> 
> http://mail-index.netbsd.org/source-changes-d/2018/08/18/msg010463.html
> 
> Well, this is a very confusing behavior of config(1). We should normalize
> everything to lower-case, provided no one depends on this behavior...

Well, interestingly enough, this works (of course):

# files common to arm32 implementations
filearch/arm/arm32/arm32_machdep.c  arm32
filearch/arm/arm32/bus_dma.carm32
.
.
.

I'm a little confused why "ifdef" would reference the attrtab, though...it 
seems like it should be looking at the options / flags table.  (It's been a 
long time since I was deep in the bowels of config(1), though, so entirely 
possible that something drastic has changed while I wasn't paying attention...)

-- thorpej

Re: CVS commit: src/sys/arch/evbarm/conf

[Jason Thorpe]

> On Aug 18, 2018, at 7:59 AM, Rin Okuyama  wrote:
> 
> On 2018/08/18 20:08, Rin Okuyama wrote:
>> Ah, then it should be "if ARM32". It was "if arm32" in rev. 1.31.
> 
> Sorry, not 1.31 but 1.30.

That's because all options are normalized to lower-case.

-- thorpej

Re: CVS commit: src/sys/arch/aarch64

[Jason Thorpe]

> On Aug 5, 2018, at 1:55 AM, Martin Husemann  wrote:
> 
> On Sat, Aug 04, 2018 at 06:33:20AM -0700, Jason Thorpe wrote:
>> It only matters when setting / removing breakpoints, so it seems like
>> you want to defer changing page protection right until then.
> 
> Can't we do the breakpoint changes via the direct map instead?

That would probably work, too, at the expense of some possible additional cache 
fiddling.

-- thorpej

Re: CVS commit: src/sys/arch/aarch64

[Jason Thorpe]

> On Aug 4, 2018, at 2:09 AM, Maxime Villard  wrote:
> 
> Regarding the DDB ifndef, probably there must be
> a bit in ARM64 saying "disable page protection", so it could be set when
> we enter DDB, and we could remove the ifndef.


It only matters when setting / removing breakpoints, so it seems like you want 
to defer changing page protection right until then.

Even if there's not a single bit that will do it (I honestly don't know), why 
not just fiddle with the L2 descriptor directly?

-- thorpej

Re: CVS commit: src/sys/dev/i2c

[Jason Thorpe]

> On Jun 30, 2018, at 10:50 AM, Frank Kardel  wrote:
> 
> Hi Jason !
> 
> It is not so odd as your comment suggests. The I2C address is stored in the 
> device EEPROM and perfectly survives a power off.

Ah! If the data sheet mentions this fact, I completely missed it.

I'm afraid I probably did break it, so let's figure out how to fix... can it be 
programmed to an arbitrary address, or are there a set of specific ones you can 
chose from?

> 
> All we need to be able to is to explicitly configure the device at a 
> different address. I hope this capability was not disabled with this check-in 
> as that would make my second sensor at 0x29 useless and prohibit multiple 
> sensors on a I2C bus.
> 
> For configuring the I2C address to a different value see the pkgsrc package 
> hytctl.
> 
> Thanks for re-working the attachment logic.
> 
> Frank
> 
> 
> On 06/16/18 23:24, Jason R Thorpe wrote:
>> Module Name: src
>> Committed By:thorpej
>> Date:Sat Jun 16 21:24:36 UTC 2018
>> 
>> Modified Files:
>>  src/sys/dev/i2c: hytp14.c
>> 
>> Log Message:
>> More cleanup to i2c autoconfiguration:
>> 
>> - Get all of the drivers onto the new match quality constants.
>> - Introduce a new helper function, iic_use_direct_match(), that has
>>   all of the logic for direct-config matching.  If it returns true,
>>   the driver returns the match result (which may be 0).  If it returns
>>   false, the driver does indirect-config matching.
>> - iic_compat_match() now returns a weighted match quality; matches to
>>   lower-indexed "compatible" device property are more-specific matches,
>>   and return a better match quality accordingly.
>> 
>> XXX This driver is an odd-ball with respect to the hardware device.
>> See comments in the match routine.  Unclear how best to handle it.
>> 
>> 
>> To generate a diff of this commit:
>> cvs rdiff -u -r1.7 -r1.8 src/sys/dev/i2c/hytp14.c
>> 
>> Please note that diffs are not public domain; they are subject to the
>> copyright notices on the relevant files.
>> 
> 

-- thorpej

Re: CVS commit: src/sys/dev/fdt

[Jason Thorpe]

> On Jun 20, 2018, at 12:29 PM, Jared McNeill  wrote:
>> Sure, but where is the code for the brcm2835 platform that *processes* it?  
>> I see stuff for parsing console / fb options, but not for standard boot 
>> flags.
> 
> Firmware puts the string in /chosen/bootargs and we pick it up here: 
> https://nxr.netbsd.org/xref/src/sys/arch/evbarm/fdt/fdt_machdep.c#378 
> 
> 
> The standard args are then processed here: 
> https://nxr.netbsd.org/xref/src/sys/arch/evbarm/fdt/fdt_machdep.c#491 
> 
Ok, got it, thanks.

-- thorpej

Re: CVS commit: src/sys/dev/fdt

[Jason Thorpe]

> On Jun 20, 2018, at 9:56 AM, Jared McNeill  wrote:
> 
> On Wed, 20 Jun 2018, Jason Thorpe wrote:
> 
>> ofctl(8) is pretty useless for this purpose because it doesn't show you 
>> which driver instance has attached to a given device tree node.  As for 
>> passing generic boot args, it's not obvious how one does that on the RPI 
>> (and I don't even see the hook that processes the generic boot args 
>> bcm283x_platform).
> 
> https://www.raspberrypi.org/documentation/configuration/cmdline-txt.md


Sure, but where is the code for the brcm2835 platform that *processes* it?  I 
see stuff for parsing console / fb options, but not for standard boot flags.

-- thorpej

Re: CVS commit: src/sys/dev/fdt

[Jason Thorpe]

> On Jun 20, 2018, at 2:06 AM, Jared McNeill  wrote:
> 
> Not a fan of this, some of these paths can get fairly long (boot the 
> VEXPRESS_A15 kernel to see for yourself) and the path is only really useful 
> if you are debugging something.

Sigh.

> If you want to see the debugging information we already have a way to do that 
> with boot -x. You can also inspect the whole tree at runtime with ofctl(8).

ofctl(8) is pretty useless for this purpose because it doesn't show you which 
driver instance has attached to a given device tree node.  As for passing 
generic boot args, it's not obvious how one does that on the RPI (and I don't 
even see the hook that processes the generic boot args bcm283x_platform).


> 
> 
> On Wed, 20 Jun 2018, Jason R Thorpe wrote:
> 
>> Module Name: src
>> Committed By:thorpej
>> Date:Wed Jun 20 05:59:18 UTC 2018
>> 
>> Modified Files:
>>  src/sys/dev/fdt: fdtbus.c
>> 
>> Log Message:
>> In fdtbus_print(), aprint_normal the path to the device (rather than
>> aprint_debug).  This info is every bit as useful as, say, PCI device
>> locations.
>> 
>> 
>> To generate a diff of this commit:
>> cvs rdiff -u -r1.17 -r1.18 src/sys/dev/fdt/fdtbus.c
>> 
>> Please note that diffs are not public domain; they are subject to the
>> copyright notices on the relevant files.
>> 
>> 

-- thorpej

Re: CVS commit: src/sys/arch/x86/x86

[Jason Thorpe]

> On Jun 7, 2018, at 7:59 AM, m...@netbsd.org wrote:
> 
> You've changed a default and selectively fixed the one driver that
> people noticed breaks from it. How do you know the rest aren't broken?

As you know, there is very little certainty in this world.  For example, how 
can I be certain that I won’t be hit by a bus when crossing the street? (Pun 
intended.)  At best, I can take precautions to minimize my risk.

In this case, here are the precautions I have taken:

- I have used a method of probing for i2c devices that is widely considered to 
be the best approach for doing so in a general way.

- The method I have selected is equivalent to the SMBus “quick” command.

- The overwhelming majority of “intelligent” i2c controllers that provide an 
“exec” interface to our i2c subsystem are, in fact, specifically SMBus 
controllers, and thus will, by their nature, support this operation.

- The other general-purpose “intelligent” i2c controllers that provide an 
“exec” interface should also, at the hardware layer, should support this 
operation because it’s a completely legal i2c bus sequence that should be free 
of side-effects.

- Per a lengthy discussion on tech-kern, we know of a specific, odd case of 
“intelligent” i2c controller that is fairly neutered, which we have 
special-cased.  It is truly the odd-ball.

- For the non-intelligent i2c controllers that use the i2c subsystem’s bit-bang 
logic, if this method doesn’t work, it’s simply a software bug that should be 
fixed.

Of course, you’re also ignoring the fact that i2c configuration was already 
somewhat broken in -current on a bunch of platforms, due to the effects of 
fixing another bug.  So, at the very least, this is moving the needle forward 
after a consensus among various stakeholders that this was a good approach.

In all my years of being involved with NetBSD, I have always made a good faith 
effort to improve the system to benefit the community, and attempt to correct 
my mistakes promptly when I make them.  If there’s one thing I’m certain of, 
it’s that.




> 
> On Thu, Jun 07, 2018 at 01:35:31PM +, Jason R Thorpe wrote:
>> Module Name: src
>> Committed By:thorpej
>> Date:Thu Jun  7 13:35:31 UTC 2018
>> 
>> Modified Files:
>>  src/sys/arch/x86/x86: x86_autoconf.c
>> 
>> Log Message:
>> In device_register(), if the device is an "iic" child of "imcsmb",
>> attach a I2C_PROP_INDIRECT_DEVICE_WHITELIST property that limits
>> the allowed devices to "spdmem" and "sdtemp".  Also set the
>> I2C_PROP_INDIRECT_PROBE_STRATEGY property to I2C_PROBE_STRATEGY_NONE,
>> since that controller can't issue any of the "quick" commands.
>> 
>> XXX It would be nice to be able to do this in the imcsmb driver
>> itself, but the way autoconfiguration works makes that infeasible.
>> 
>> 
>> To generate a diff of this commit:
>> cvs rdiff -u -r1.76 -r1.77 src/sys/arch/x86/x86/x86_autoconf.c
>> 
>> Please note that diffs are not public domain; they are subject to the
>> copyright notices on the relevant files.
>> 
> 
>> Modified files:
>> 
>> Index: src/sys/arch/x86/x86/x86_autoconf.c
>> diff -u src/sys/arch/x86/x86/x86_autoconf.c:1.76 
>> src/sys/arch/x86/x86/x86_autoconf.c:1.77
>> --- src/sys/arch/x86/x86/x86_autoconf.c:1.76 Thu Nov  9 01:02:56 2017
>> +++ src/sys/arch/x86/x86/x86_autoconf.c  Thu Jun  7 13:35:31 2018
>> @@ -1,4 +1,4 @@
>> -/*  $NetBSD: x86_autoconf.c,v 1.76 2017/11/09 01:02:56 christos Exp $   
>> */
>> +/*  $NetBSD: x86_autoconf.c,v 1.77 2018/06/07 13:35:31 thorpej Exp $
>> */
>> 
>> /*-
>>  * Copyright (c) 1990 The Regents of the University of California.
>> @@ -35,7 +35,7 @@
>>  */
>> 
>> #include 
>> -__KERNEL_RCSID(0, "$NetBSD: x86_autoconf.c,v 1.76 2017/11/09 01:02:56 
>> christos Exp $");
>> +__KERNEL_RCSID(0, "$NetBSD: x86_autoconf.c,v 1.77 2018/06/07 13:35:31 
>> thorpej Exp $");
>> 
>> #include 
>> #include 
>> @@ -54,6 +54,8 @@ __KERNEL_RCSID(0, "$NetBSD: x86_autoconf
>> #include 
>> #include 
>> 
>> +#include 
>> +
>> #include "acpica.h"
>> #include "wsdisplay.h"
>> 
>> @@ -547,6 +549,36 @@ device_register(device_t dev, void *aux)
>> {
>>  device_t isaboot, pciboot;
>> 
>> +/*
>> + * The Intel Integrated Memory Controller has a built-in i2c
>> + * controller that's rather limited in capability; it is intended
>> + * only for reading memory module EERPOMs and sensors.
>> + */
>> +if (device_is_a(dev, "iic") &&
>> +device_is_a(dev->dv_parent, "imcsmb")) {
>> +static const char *imcsmb_device_whitelist[] = {
>> +"spdmem",
>> +"sdtemp",
>> +NULL,
>> +};
>> +prop_array_t whitelist = prop_array_create();
>> +prop_dictionary_t props = device_properties(dev);
>> +int i;
>> +
>> +for (i = 0; imcsmb_device_whitelist[i] != NULL; i++) {
>> +prop_string_t pstr = prop_string_create_cstring_nocopy(
>> +   

Re: CVS commit: src/sys/arch/arm/broadcom

[Jason Thorpe]

> On Jun 7, 2018, at 5:14 AM, Jonathan A. Kollasch  
> wrote:
> 
> I don't disagree.  That said, making use of this hardware design did not
> seem the most straightforward to me.  If you can find a better way to do
> it, that'd be great.

Yah, it’s definitely awkward to use, although one advantage it does have is 
making it easy to use the high-speed i2c modes.  The way it supports 10-bit 
addressing is just totally brain-dead, though.

I have some ideas how I want to do it, but it’s not critical right now.

-- thorpej

Re: CVS commit: src

[Jason Thorpe]

> On May 27, 2018, at 5:15 AM, Jared McNeill  wrote:
> 
> Where did you get the compat strings used in tsllux_compats? Linux uses 
> "amstaos" as vendor prefix, and always exact chip IDs (never anything like 
> tsl256x).

Thin air.  I’ll update them.


> 
> 
> On Sun, 27 May 2018, Jason R Thorpe wrote:
> 
>> Module Name: src
>> Committed By:thorpej
>> Date:Sun May 27 05:31:20 UTC 2018
>> 
>> Modified Files:
>>  src/distrib/sets/lists/man: mi
>>  src/share/man/man4: Makefile
>>  src/sys/dev/i2c: files.i2c
>> Added Files:
>>  src/share/man/man4: tsllux.4
>>  src/sys/dev/i2c: tsl256x.c tsl256xreg.h
>> 
>> Log Message:
>> Add a driver for the Taos TSL256x light sensors.
>> 
>> 
>> To generate a diff of this commit:
>> cvs rdiff -u -r1.1589 -r1.1590 src/distrib/sets/lists/man/mi
>> cvs rdiff -u -r1.654 -r1.655 src/share/man/man4/Makefile
>> cvs rdiff -u -r0 -r1.1 src/share/man/man4/tsllux.4
>> cvs rdiff -u -r1.91 -r1.92 src/sys/dev/i2c/files.i2c
>> cvs rdiff -u -r0 -r1.1 src/sys/dev/i2c/tsl256x.c src/sys/dev/i2c/tsl256xreg.h
>> 
>> Please note that diffs are not public domain; they are subject to the
>> copyright notices on the relevant files.
>> 
>> 

-- thorpej

Re: CVS commit: src/sys/dev/sysmon

[Jason Thorpe]

Unknown of course

-- thorpej
Sent from my iPhone.

> On May 26, 2018, at 2:15 PM, Jason R Thorpe  wrote:
> 
> Module Name:src
> Committed By:thorpej
> Date:Sat May 26 21:15:46 UTC 2018
> 
> Modified Files:
>src/sys/dev/sysmon: sysmon_envsys.c
> 
> Log Message:
> Avoid dereferencing NULL if we attempt to look up an known unit type.
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.142 -r1.143 src/sys/dev/sysmon/sysmon_envsys.c
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 

Re: CVS commit: src/sys

[Jason Thorpe]

> On May 25, 2018, at 11:23 AM, Jaromír Doleček  
> wrote:
> 
> 2018-05-22 12:18 GMT+02:00 Martin Husemann :
>> Here are timing results:
> 
> While 37% speedup is nice, I see there isn't nearly as huge difference
> as for my machine. Could you please try with some file which fits
> whole in the page cache?
> 
>> Unfortunatley with ubc_direct enabled, it panics quickly:
> 
> There is a comment in uvm_bio.c about some platforms not being able to
> write to individual bytes atomically, and hence software having to do
> read/modify/write. Could this be  somehow causing the machine check on
> Alpha?

I don’t think that’s what’s happening here… from the machine check logout frame 
that Ross Harvey so kindly decoded in the 21272 Core Logic driver, it looks 
like a bogus bus_space_read_something to a PCI memory region is happening (it’s 
a Target Abort on a PCI memory read … it’s been a while, but I think I’m 
interpreting that right…)

32-bit PCI address:  address  = 0x38d67870, 0x0

It would be instructive to see what PCI device has a memory BAR that covers 
that address.

If there isn’t one, then I suspect we’re looking at a memory stomper.

> Jaromir

-- thorpej

Re: CVS commit: src/tests/lib/libc/sys

[Jason Thorpe]

> On May 24, 2018, at 10:45 PM, Kamil Rytarowski  wrote:
> 
> Fixed!

Confirmed!  Thanks!

-- thorpej

Re: CVS commit: src/tests/lib/libc/sys

[Jason Thorpe]

This change seems to have broken building on 32-bit platforms (certainly at 
least for 32-bit ARM):

#   compile  sys/t_ptrace_wait.o
/nbsd/tools/bin/armv6--netbsdelf-eabihf-gcc -O2   -std=gnu99-Wall 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare  
-Wsystem-headers   -Wno-traditional   -Wa,--fatal-warnings  -Wreturn-type 
-Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter 
-Wno-sign-compare -Wsign-compare -Wformat=2  -Wno-format-zero-length  -Werror 
-Wno-missing-noreturn   -fPIE--sysroot=/nbsd/destdir/rpi 
-I/Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/../../..  -c   
-D_KERNTYPES 
/Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.c
In file included from 
/Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.c:59:0:
/Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h: In 
function 'trigger_bus':
/Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:561:20: 
error: cast from pointer to integer of different size 
[-Werror=pointer-to-int-cast]
  FORKEE_ASSERT_NEQ((uintmax_t)fp, (uintmax_t)NULL);
^
/Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:158:18: 
note: in definition of macro 'FORKEE_ASSERT_NEQ'
  uintmax_t vx = (x);  \
  ^
/Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:561:35: 
error: cast from pointer to integer of different size 
[-Werror=pointer-to-int-cast]
  FORKEE_ASSERT_NEQ((uintmax_t)fp, (uintmax_t)NULL);
   ^
/Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:159:18: 
note: in definition of macro 'FORKEE_ASSERT_NEQ'
  uintmax_t vy = (y);  \
  ^
/Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:565:20: 
error: cast from pointer to integer of different size 
[-Werror=pointer-to-int-cast]
  FORKEE_ASSERT_NEQ((uintmax_t)p, (uintmax_t)MAP_FAILED);
^
/Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:158:18: 
note: in definition of macro 'FORKEE_ASSERT_NEQ'
  uintmax_t vx = (x);  \
  ^
/Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:565:34: 
error: cast from pointer to integer of different size 
[-Werror=pointer-to-int-cast]
  FORKEE_ASSERT_NEQ((uintmax_t)p, (uintmax_t)MAP_FAILED);
  ^
/Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:159:18: 
note: in definition of macro 'FORKEE_ASSERT_NEQ'
  uintmax_t vy = (y);  \
  ^
cc1: all warnings being treated as errors

*** Failed target:  t_ptrace_wait.o


Maybe uintptr_t is a better type to cast to?


> On May 23, 2018, at 6:18 AM, Kamil Rytarowski  wrote:
> 
> Module Name:  src
> Committed By: kamil
> Date: Wed May 23 13:18:09 UTC 2018
> 
> Modified Files:
>   src/tests/lib/libc/sys: t_ptrace_wait.h
> 
> Log Message:
> Add new auxiliary functions in ATF ptrace(2) tests
> 
> Introduce:
> - trigger_trap()
> - trigger_segv()
> - trigger_ill()
> - trigger_fpe()
> - trigger_bus()
> 
> These functions generate appropriate signals caused by crashes.
> 
> A debugger is required to collect the crashes regardless of signal masking,
> catching or ignoring rules.
> 
> While there, append __used argument to can_we_set_dbregs().
> 
> Sponsored by 
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.5 -r1.6 src/tests/lib/libc/sys/t_ptrace_wait.h
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 

-- thorpej

Re: CVS commit: src/sys

[Jason Thorpe]

FWIW, I checked in the Alpha changes.  They were trivial.  SH3 and MIPS I 
didn’t do because there’s extra work to do to handle virtually indexed caches.  
(In the case of SH3, it’s actually the SH4 that has the issue, and I do have a 
Dreamcast, so I may get to that one eventually...)

-- thorpej
Sent from my iPhone.

> On May 19, 2018, at 8:16 AM, Jason Thorpe <thor...@me.com> wrote:
> 
> I can make the Alpha pmap changes if someone’s willing to test them (I no 
> longer have Alpha hardware).
> 
> -- thorpej
> Sent from my iPhone.
> 
>> On May 19, 2018, at 8:03 AM, Jaromir Dolecek <jdole...@netbsd.org> wrote:
>> 
>> implement the new interface for amd64; I hear alpha and mips might be 
>> relatively
>> easy to add too, but I lack the knowledge

Re: CVS commit: src/sys

[Jason Thorpe]

I can make the Alpha pmap changes if someone’s willing to test them (I no 
longer have Alpha hardware).

-- thorpej
Sent from my iPhone.

> On May 19, 2018, at 8:03 AM, Jaromir Dolecek  wrote:
> 
> implement the new interface for amd64; I hear alpha and mips might be 
> relatively
> easy to add too, but I lack the knowledge

Re: CVS commit: src/sys/arch/alpha/conf

[Jason Thorpe]

Can you send me dmesg from this machine?  We should be using direct-config if 
we can.

-- thorpej
Sent from my iPhone.

> On May 15, 2018, at 11:25 AM, Julian Coleman  wrote:
> 
> Hi,
> 
>> Oh, but to be clear, the iic instances themselves would not be in conflict, 
>> because they are direct-configured by THEIR parents, and alipm and tsc wont 
>> both exist on a given machine.
> 
> Just for info, as it's fixed now.  The DS20L has both:
> 
>  alipm0 at pci0 dev 17 function 0: 74KHz clock
>  iic0 at alipm0: I2C bus
>  tsciic0 at tsc0
>  iic1 at tsciic0: I2C bus
> 
> (and I assume the CS20 is the same).
> 
> Regards,
> 
> Julian

Re: CVS commit: src/sys/arch/alpha/conf

[Jason Thorpe]

Oh, but to be clear, the iic instances themselves would not be in conflict, 
because they are direct-configured by THEIR parents, and alipm and tsc wont 
both exist on a given machine.

It’s the i2c devices themselves I was referring to in my previous message.

The autoconfig system used to be able to handle “foo0” being specified at 
multiple parents (but it would only attach one of them).  Has that changed?

-- thorpej
Sent from my iPhone.

> On May 14, 2018, at 6:24 PM, Jason Thorpe <thor...@me.com> wrote:
> 
> They would have conflicted already in the old stuff.  This would be a great 
> application for using direct configuration of i2c on this platform.
> 
> -- thorpej
> Sent from my iPhone.
> 
>> On May 14, 2018, at 6:11 PM, Jonathan A. Kollasch <jakll...@netbsd.org> 
>> wrote:
>> 
>> Module Name:src
>> Committed By:jakllsch
>> Date:Mon May 14 22:11:30 UTC 2018
>> 
>> Modified Files:
>>   src/sys/arch/alpha/conf: GENERIC
>> 
>> Log Message:
>> Move iic0 at alipm? to iic1.  Using iic0 will conflict with the
>> iic0 at tsciic? on the API CS20.
>> 
>> XXX: Enumerate the similar-to-DS20L I2C devices on the CS20, which
>> IIRC are not all on the tsciic(4) I2C bus, and comment GENERIC
>> accordingly.
>> 
>> 
>> To generate a diff of this commit:
>> cvs rdiff -u -r1.380 -r1.381 src/sys/arch/alpha/conf/GENERIC
>> 
>> Please note that diffs are not public domain; they are subject to the
>> copyright notices on the relevant files.
>> 

Re: CVS commit: src/sys/arch/alpha/conf

[Jason Thorpe]

They would have conflicted already in the old stuff.  This would be a great 
application for using direct configuration of i2c on this platform.

-- thorpej
Sent from my iPhone.

> On May 14, 2018, at 6:11 PM, Jonathan A. Kollasch  wrote:
> 
> Module Name:src
> Committed By:jakllsch
> Date:Mon May 14 22:11:30 UTC 2018
> 
> Modified Files:
>src/sys/arch/alpha/conf: GENERIC
> 
> Log Message:
> Move iic0 at alipm? to iic1.  Using iic0 will conflict with the
> iic0 at tsciic? on the API CS20.
> 
> XXX: Enumerate the similar-to-DS20L I2C devices on the CS20, which
> IIRC are not all on the tsciic(4) I2C bus, and comment GENERIC
> accordingly.
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.380 -r1.381 src/sys/arch/alpha/conf/GENERIC
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 

Re: CVS commit: src/sys/dev

[Jason Thorpe]

Still, it’ll make it easier if we ever need to consult the foreign driver 
again.  A starting point to start looking at their diffs.

-- thorpej
Sent from my iPhone.

> On May 11, 2018, at 9:56 AM, m...@netbsd.org wrote:
> 
> initially I picked up the revisions one by one, but found out some
> of my changes were broken and undid them, and wanted to stick
> to minimal changes to a working driver.
> 
> jared said that our driver is intentionally different too.

Re: CVS commit: src/sys/dev

[Jason Thorpe]

> On May 11, 2018, at 12:41 AM, Maya Rashish  wrote:
> 
> Module Name:  src
> Committed By: maya
> Date: Fri May 11 07:41:11 UTC 2018
> 
> Modified Files:
>   src/sys/dev/ic: bwfm.c bwfmreg.h bwfmvar.h
>   src/sys/dev/sdmmc: if_bwfm_sdio.c
>   src/sys/dev/usb: if_bwfm_usb.c

It’s really helpful to also synchronize the foreign RCS ID tags when you’re 
synchronizing the code; not just blindly synchronize them, of course, but to 
correctly reflect what version of the code we’re on par with.  Can you go back 
and do so with these changes?

> 
> Log Message:
> sync with openbsd bwfm to some extent.

Can you outline which changes you skipped?

> 
> add a txcheck
> set chip active/passive for more kinds of chips
> add wrapper around setting active/passive
> detect chip RAM
> make bwfm_rx take an mbuf
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.10 -r1.11 src/sys/dev/ic/bwfm.c
> cvs rdiff -u -r1.2 -r1.3 src/sys/dev/ic/bwfmreg.h
> cvs rdiff -u -r1.1 -r1.2 src/sys/dev/ic/bwfmvar.h
> cvs rdiff -u -r1.2 -r1.3 src/sys/dev/sdmmc/if_bwfm_sdio.c
> cvs rdiff -u -r1.4 -r1.5 src/sys/dev/usb/if_bwfm_usb.c
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 

-- thorpej

Re: CVS commit: src/sys/kern

[Jason Thorpe]

> On Apr 13, 2018, at 12:24 PM, matthew green  wrote:
> 
> we could also make this only relevant on ports with cpus that
> have faster cpus, leaving older systems with smaller logs.
> (the seconds part shouldn't change, i think, as there is no
> reason to believe any port has longer uptime than another.)

I would actually argue that slower systems should tend to have a longer uptime. 
 After all, there’s less opportunity for something to go wrong per unit of wall 
clock time :-)

-- thorpej

Re: CVS commit: src/sys

[Jason Thorpe]

On Apr 12, 2010, at 3:15 PM, Antti Kantee wrote:

 Module Name:  src
 Committed By: pooka
 Date: Mon Apr 12 22:15:32 UTC 2010
 
 Modified Files:
   src/sys/conf: files
   src/sys/kern: kern_lwp.c
   src/sys/sys: lwp.h
 Added Files:
   src/sys/kern: subr_lwp_specificdata.c
 
 Log Message:
 Separate lwp specificdata data structure management from lwp cpu/vm
 management.
 
 No functional change.
 
 (specificdata routines went from kern_lwp.c to subr_lwp_specificdata.c)

I find this sort of re-factoring somewhat irritating.  Can't you just #ifndef 
_RUMP_BUILD or some such so that we don't have to constantly split related 
functions into separate files?

 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.985 -r1.986 src/sys/conf/files
 cvs rdiff -u -r1.143 -r1.144 src/sys/kern/kern_lwp.c
 cvs rdiff -u -r0 -r1.1 src/sys/kern/subr_lwp_specificdata.c
 cvs rdiff -u -r1.129 -r1.130 src/sys/sys/lwp.h
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

-- thorpej

Re: CVS commit: src/sys/dev/cardbus

[Jason Thorpe]

On Mar 4, 2010, at 10:49 AM, David Young wrote:

 Use %zu and %zx for printf'ing bus_size_t.

These aren't quite right.  We should probably define PRIxxx macros for the 
bus.h scalar types.

-- thorpej

Re: CVS commit: src/sys/uvm

[Jason Thorpe]

On Feb 12, 2010, at 6:36 AM, Hubert Feyrer wrote:

 Replacing common code with a function sounds ok, but I've never seen either 
 size or importance as justification of a goto.

goto is a useful construct, and there is nothing wrong with using it in the way 
it is being used here.

-- thorpej

Re: CVS commit: src/external/cddl/osnet/lib/libnvpair

[Jason Thorpe]

On Feb 17, 2010, at 11:10 AM, Nick Hudson wrote:

 On Wednesday 17 February 2010 17:36:32 Christos Zoulas wrote:
 Module Name: src
 Committed By:christos
 Date:Wed Feb 17 17:36:32 UTC 2010
 
 Modified Files:
  src/external/cddl/osnet/lib/libnvpair: Makefile
 
 Log Message:
 Fix build issue with our make system building libnvpair.so from libnvpair.c
 and libnvpair.so from *.so by renaming libnvpair.c to lib_nvpair.c
 
 Isn't it time to fix bsd.lib.mk to stop using .so for anything other than a 
 DSO?

Agreed.

 
 I remember .pico being suggested last time this was brought up.
 
 Nick

-- thorpej

Re: CVS commit: src/sys/dev/pci

[Jason Thorpe]

On Feb 4, 2010, at 1:13 AM, SAITOH Masanobu wrote:

 Module Name:  src
 Committed By: msaitoh
 Date: Thu Feb  4 09:13:23 UTC 2010
 
 Modified Files:
   src/sys/dev/pci: if_wm.c if_wmreg.h
 
 Log Message:
 - Count Receive error, CRC error, Alignment error, Symbol error, Sequence
  error, Carrier extension error and Receive length error into ierror.
  Fixes PR#30349 reported by UMEZAWA Takeshi.
 - Count Missed packet (rx fifo overflow) and Receive no buffers (rx ring full)
  into iqdrops.

Isn't iqdrops really meant for to reflect a drop when placing into the software 
queue above the driver?

 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.195 -r1.196 src/sys/dev/pci/if_wm.c
 cvs rdiff -u -r1.35 -r1.36 src/sys/dev/pci/if_wmreg.h
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

-- thorpej

Re: CVS commit: src

[Jason Thorpe]

On Feb 3, 2010, at 12:56 PM, Roy Marples wrote:

 Module Name:  src
 Committed By: roy
 Date: Wed Feb  3 20:56:54 UTC 2010
 
 Modified Files:
   src/lib/libterminfo: Makefile genhash genman genthash
   src/tools: Makefile
 Added Files:
   src/lib/libterminfo: hash.c termcap_hash.c terminfo.5
 Removed Files:
   src/tools/nbperf: Makefile
 
 Log Message:
 Store our generated files in CVS and remove nbperf from the toolchain.
 This allows us to build consistent libs without an ever changing hash.
 

nbperf should still be in the toolchain ... even though it is not used by the 
build, it is still used as a developer tool.

 
 To generate a diff of this commit:
 cvs rdiff -u -r1.2 -r1.3 src/lib/libterminfo/Makefile \
src/lib/libterminfo/genhash
 cvs rdiff -u -r1.1 -r1.2 src/lib/libterminfo/genman \
src/lib/libterminfo/genthash
 cvs rdiff -u -r0 -r1.1 src/lib/libterminfo/hash.c \
src/lib/libterminfo/termcap_hash.c src/lib/libterminfo/terminfo.5
 cvs rdiff -u -r1.134 -r1.135 src/tools/Makefile
 cvs rdiff -u -r1.1 -r0 src/tools/nbperf/Makefile
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

-- thorpej

Re: CVS commit: src/usr.sbin/powerd

[Jason Thorpe]

On Jan 28, 2010, at 12:19 AM, Martin Husemann wrote:

 - it is unclear how scripts could make use of the fact which subsystem
   triggered the pmf event they are dealing with

When I wrote that code, I did hot have a concrete example usage scenario for 
power-type-specific scripts, but since these scripts essentially embody 
configuration information, it did seem reasonable to allow for such a scenario.

-- thorpej

Re: CVS commit: src/usr.sbin/powerd

[Jason Thorpe]

On Jan 26, 2010, at 12:37 PM, Jukka Ruohonen wrote:

 * Apparently there is only a single location for the scripts. Thus, remove
   the references to /etc/powerd/scripts/apm and /etc/powerd/scripts/acpi.

This is incorrect.  apm vs. acpi vs. whatever else.. the code still has support 
for them.  Please put this back.  Just because apm-specific and acpi-specific 
scripts do not yet exist doesn't mean that the code does not support them.

-- thorpej

Re: CVS commit: src/sys/dev/acpi

[Jason Thorpe]

On Dec 3, 2009, at 1:04 PM, Christoph Egger wrote:

 Module Name:  src
 Committed By: cegger
 Date: Thu Dec  3 21:04:29 UTC 2009
 
 Modified Files:
   src/sys/dev/acpi: acpi.c files.acpi
 Added Files:
   src/sys/dev/acpi: acpi_pci.c acpi_pci.h
 
 Log Message:
 Enumerate ACPI PCI devices. Allows to link PCI with ACPI devices.
 Patch presented on tech-kern@
 http://mail-index.netbsd.org/tech-kern/2009/11/28/msg006552.html
 

Shouldn't we just attach PCI busses @ ACPI instead of mainbus?

 'nice work' Jukka Ruohonen
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.136 -r1.137 src/sys/dev/acpi/acpi.c
 cvs rdiff -u -r0 -r1.1 src/sys/dev/acpi/acpi_pci.c \
src/sys/dev/acpi/acpi_pci.h
 cvs rdiff -u -r1.62 -r1.63 src/sys/dev/acpi/files.acpi
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

-- thorpej

Re: CVS commit: src

[Jason Thorpe]

On Nov 18, 2009, at 2:28 PM, Thomas E. Spanjaard wrote:

 Jason Thorpe wrote:
 On Nov 18, 2009, at 12:40 PM, David Young wrote:
 
 I see.  I will describe spllower(9) and splraise(9) in an i386 page,
 instead.
 
 They should not be documented at all.  They are not interfaces that are 
 meant to be used in any user-serviceable way.
 
 Section 9 isn't about user-serviceable interfaces anyway, unless the
 user is a kernel developer, in which case it is relevant :).

No, it's not.  spllower() and splraise() are not really part of the kernel API. 
 They are implementation details that can be described with comments in code.

-- thorpej

Re: CVS commit: src

[Jason Thorpe]

On Nov 2, 2009, at 9:08 PM, David Young wrote:

 Module Name:  src
 Committed By: dyoung
 Date: Tue Nov  3 05:08:19 UTC 2009
 
 Modified Files:
   src/sys/arch/i386/i386: copy.S
 Added Files:
   src/share/man/man9/man9.i386: return_address.9
   src/sys/arch/i386/include: return.h
 
 Log Message:
 Add return_address(9) for reading the Nth return address from the call
 stack.

What's the intended usage?  How is __builtin_return_address() not sufficient?

 
 
 To generate a diff of this commit:
 cvs rdiff -u -r0 -r1.1 src/share/man/man9/man9.i386/return_address.9
 cvs rdiff -u -r1.18 -r1.19 src/sys/arch/i386/i386/copy.S
 cvs rdiff -u -r0 -r1.1 src/sys/arch/i386/include/return.h
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

-- thorpej

Re: CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs

[Jason Thorpe]

On Oct 29, 2009, at 4:25 PM, Bill Stouder-Studenmund wrote:

 Where you able to look at the repository at macosforge.org before it shut 
 down? I think that would show a take at solving similar issues.

Note that the XNU vnode lifecycle, referencing, and locking implementation is 
significantly different from ours.

-- thorpej

Re: panic? - Re: CVS commit: src

[Jason Thorpe]

Surprising, since I specifically try to avoid an xcall in that case.   
I'll look later today.


-- thor...@iphone

On Oct 17, 2009, at 3:41 AM, Frank Kardel kar...@netbsd.org wrote:


Hi Jason !

I now get a KASSERT() assertion failure during boot in
subr_xcall.c:199: KASSERT(xc_tailp  xc_headp);

Hand copied call stack:
subr_xcall
pool_cache_invalidate
pmap_grow_kernel
uvm_map_prepare
uvm_map
uvm_km_alloc
vga_post_init
... more into autoconfig/device/bus scanning

Frank

Jason R Thorpe wrote:

Module Name:src
Committed By:thorpej
Date:Thu Oct 15 20:50:13 UTC 2009

Modified Files:
   src/share/man/man9: pool_cache.9
   src/sys/kern: subr_pool.c
   src/sys/sys: pool.h

Log Message:
- pool_cache_invalidate(): broadcast a cross-call to drain the per- 
CPU

 caches before draining the global cache.
- pool_cache_invalidate_local(): remove.


To generate a diff of this commit:
cvs rdiff -u -r1.12 -r1.13 src/share/man/man9/pool_cache.9
cvs rdiff -u -r1.175 -r1.176 src/sys/kern/subr_pool.c
cvs rdiff -u -r1.66 -r1.67 src/sys/sys/pool.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/etc/rc.d

[Jason Thorpe]

On Oct 6, 2009, at 1:22 AM, Adam Hamsik wrote:

 Hi,
 On Oct,Tuesday 6 2009, at 9:03 AM, Alan Barrett wrote:
 
 On Mon, 05 Oct 2009, Adam Hamsik wrote:
 Modified Files:
 src/etc/rc.d: mountall
 
 Log Message:
 Add support for mounting zfs filesystems to mountall script. ZFS 
 configuration
 is stored in /etc/zpool.cache and it is automatically loaded to kernel from
 filesystem. Filesystems are then configured accordingly to their properties
 loaded from cache file.
 
 Is /etc/zpool.cache a human-edited configuration file (in which
 case, why the .cache name?), or is it a machine-readable database (in
 which case, why is it in /etc?), or is it something else?
 
 It is a binary file. Something like binary plist. Do you have any better 
 place for it ? I think that we should keep it in etc until we start work on a 
 zfs on root support then we will need to move it some where else anyway.

It belongs in /var/db ... but I'd like to ask why you need it at all?

 
 Regards
 
 Adam.

-- thorpej

Re: CVS commit: src/sys

[Jason Thorpe]

On Oct 2, 2009, at 8:48 AM, Antti Kantee wrote:


Module Name:src
Committed By:   pooka
Date:   Fri Oct  2 15:48:42 UTC 2009

Modified Files:
src/sys/conf: files
src/sys/kern: kern_subr.c
Added Files:
src/sys/kern: subr_humanize.c

Log Message:
Give humanize_number  format_bytes their own spots in the sun and  
move

from kern_subr to subr_humanize.


This stuff really ought just to be in libkern.




To generate a diff of this commit:
cvs rdiff -u -r1.958 -r1.959 src/sys/conf/files
cvs rdiff -u -r1.200 -r1.201 src/sys/kern/kern_subr.c
cvs rdiff -u -r0 -r1.1 src/sys/kern/subr_humanize.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


-- thorpej

Re: CVS commit: src/lib/libc/arch/m68k/sys

[Jason Thorpe]

On Oct 3, 2009, at 3:28 PM, Frank Wille wrote:


Module Name:src
Committed By:   phx
Date:   Sat Oct  3 22:28:33 UTC 2009

Modified Files:
src/lib/libc/arch/m68k/sys: cerror.S

Log Message:
SystemV-R4 ABI for M68k returns pointers in %a0, so we have to make  
sure
that CERROR returns -1 in %a0 in addition to %d0 and %d1, to make  
functions
like mmap(2), mremap(2), shmat(2) or sbrk(2) return -1 in case of an  
error.
A side effect of this bug was a segfault caused by jemalloc, when  
mmap()

failed.


Wow, old bug.  Nice find!




To generate a diff of this commit:
cvs rdiff -u -r1.14 -r1.15 src/lib/libc/arch/m68k/sys/cerror.S

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


-- thorpej

Re: CVS commit: src/usr.sbin/puffs/rump_smbfs

[Jason Thorpe]

On Sep 18, 2009, at 9:10 AM, David Laight wrote:


It is all rather similar to the proliferation of memory pools - for
things where 'malloc' would be fine.


The old-school kernel malloc was almost never fine ... but pools  
have another advantage -- use of a direct-mapped segment on  
architectures so-equipped.  And for those not so-equipped, greatly  
reduced pressure on kmem_map.


Now, if we could only get rid of kmem_map / kernel malloc completely  
(which requires making it illegal to allocate memory in interrupt  
context).


-- thorpej

Re: CVS commit: [matt-nb5-mips64] src/sys/conf

[Jason Thorpe]

On Sep 4, 2009, at 9:19 PM, Matt Thomas wrote:



On Sep 4, 2009, at 8:59 PM, Izumi Tsutsui wrote:


Modified Files:
src/sys/conf [matt-nb5-mips64]: Makefile.kern.inc

Log Message:
Don't abort if DBSYM fails.


It was intentionally changed to fatal:
http://cvsweb.NetBSD.org/bsdweb.cgi/src/sys/conf/Makefile.kern.inc#rev1.70

. Make this error a fatal build time error

---
Izumi Tsutsui


I see no reason to make it fatal.  It means that when I build a  
kernel with

DEBUG, my kernel build will fail.  That's stupid.

/u1/netbsd-nb5-mips64/tools/bin/mips64el--netbsd-strip -g -X -o  
netbsd netbsd.gdb

/u1/netbsd-nb5-mips64/tools/bin/mips64el--netbsd-dbsym netbsd
mips64el--netbsd-dbsym: symbol table (6124416 bytes) too big for  
buffer (175000 bytes)

Increase options SYMTAB_SPACE in your kernel config

-rwxr-xr-x  1 matt  staff   9262360 Sep  4 20:28 MALTA64/netbsd
-rwxr-xr-x  1 matt  staff  29851080 Sep  4 20:28 MALTA64/netbsd.gdb


We should figure out a way to make symbols appendable as an ELF  
section.




  textdata bss dec hex filename
2609483  223104  267656 3100243  2f4e53 MALTA64/netbsd
2609483  223104  267656 3100243  2f4e53 MALTA64/netbsd.gdb


-- thorpej

Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips/include

[Jason Thorpe]

On Aug 21, 2009, at 10:29 AM, Matt Thomas wrote:


Module Name:src
Committed By:   matt
Date:   Fri Aug 21 17:29:42 UTC 2009

Modified Files:
src/sys/arch/mips/include [matt-nb5-mips64]: types.h

Log Message:
Adapt to ABI variations.  Make sure mips_reg_t == register_t.
Add PRIx{{P,V}{ADDR,SIZE}} and PRIxREGISTER{,32} macros to assist
printing out above types.


What's the point of having both?  Why not just register_t and be done  
with it





To generate a diff of this commit:
cvs rdiff -u -r1.43.36.1 -r1.43.36.2 src/sys/arch/mips/include/types.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


-- thorpej

Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips/include

[Jason Thorpe]

On Aug 22, 2009, at 4:30 PM, Matt Thomas wrote:



On Aug 22, 2009, at 4:25 PM, Jason Thorpe wrote:



On Aug 21, 2009, at 10:29 AM, Matt Thomas wrote:


Module Name:src
Committed By:   matt
Date:   Fri Aug 21 17:29:42 UTC 2009

Modified Files:
src/sys/arch/mips/include [matt-nb5-mips64]: types.h

Log Message:
Adapt to ABI variations.  Make sure mips_reg_t == register_t.
Add PRIx{{P,V}{ADDR,SIZE}} and PRIxREGISTER{,32} macros to assist
printing out above types.


What's the point of having both?  Why not just register_t and be  
done with it


Mostly to avoid casting.  If it's X, use PRIxX and don't worry.


No, what's the point of having mips_reg_t ???

-- thorpej

Re: CVS commit: src/etc/rc.d

[Jason Thorpe]

On Aug 3, 2009, at 10:45 AM, Perry E. Metzger wrote:


Module Name:src
Committed By:   perry
Date:   Mon Aug  3 17:45:48 UTC 2009

Modified Files:
src/etc/rc.d: named ntpdate

Log Message:
ntpdate can't work without named because a modern ntp.conf has dns
names in it. We therefore now depend on it.

However, this would have then created a circular dependency because  
named

depended on SERVERS, and racoon was before SERVERS and required kdc,
and kdc needs the time to be right and thus depended on ntp.

Instead, have named depend on NETWORKING (so that there is a network
there), mountcritremote (so we know that named has a directory to work
from) and syslogd (so that named has some place to spew information).

I'm not sure this is perfect, but it is certainly a big improvement
over constantly failing ntpdate runs during boot.


Definitely not perfect .. named might also depend on ntp (by way of  
kdc) if GSS-TSIG is enabled.


Explicit dependencies are the pits.  Launch on demand is the way to go.

-- thorpej