Joerg Sonnenberger writes:
On Wed, Jul 01, 2015 at 10:48:29PM +1000, matthew green wrote:
last i tried, it was only a couple of minor fixes needed
to make x86 build without MULTIPROCESSOR.
The only reason I know why you would want that is to disable the use of
the LAPIC. Everything
David Holland writes:
On Fri, May 01, 2015 at 07:48:37PM +0200, Joerg Sonnenberger wrote:
On Fri, May 01, 2015 at 01:58:34PM -0300, Leandro Santi wrote:
A quick look at build.sh shows that one of the first things that
needs to be done is to map the MACHINE name to the CPU architecture
I agree that evb* is confusing and increasingly meaningless and would
like to see us transition away from it.
I contend that moving to sys/arch/cpu is incorrect which there are
multiple MACHINE values for that CPU. sys/tem/mips (haha!) or
sys/platform/mips (yuk) or sys/arch/cpusys or
The problem also exists with failed hard disks, where filesystem
... or failed sd cards. i have a brand newly failed card that
hangs for ever upon any access... :-)
this is going to be more common in the future, so a general
solution does seem like the right idea. i had to reboot...
Thor Lancelot Simon writes:
On Sat, Jun 20, 2015 at 03:18:48AM +0200, Kamil Rytarowski wrote:
I see no reason to capitulate and drop the original naming, refreshed
for the current kernel design in favor of some invented linuxism.
You're going to cause massive confusion if you write
nfs mountd/server should work 32 bit compat in -current. please
send-pr any problems.
thanks!
.mrg.
i've got an in-progress patch to split nfssvc to avoid as much
code-copying as possible. lots of tangles, so lots of things
to tease out, but hopefully this will be done soon..
.mrg.
Martin Husemann writes:
I've been looking at adding the missing things to compat/netbsd32
recently, mainly to make the default N32 userland on mips64 more usefull
and able to run our full test suite.
Most missing pieces are just oversights/lazyness and easy to fill in.
However, I wonder
what sort of support from ddb do you need? ddb supports run-time
addition of commands, so i imagine that with the right glue you
could easily add a lua ddb command with a module.
.mrg.
hi Andrew! :)
Who is appalled to discover that pc532 support has been removed!
get your GCC and binutils and GDB pals to put the support back
in the toolchain and we'll have something to talk about :-)
note that we've revived the playstation2 port now that its has
had its toolchain components
On Wed, May 13, 2015 at 01:52:05PM +0200, Kamil Rytarowski wrote:
A FreeBSD developer studying our examples told me that we traditionally use
u_int in place of unsigned [int] - calling the usage of 'unsigned' a
linuxism.
I have no opinions on it. How is it?
Personally, I consider the
BTW, devsw_attach() doesn't automatically generate the major. It does
a lookup in the majors table. If there is no entry in the table, you
get an error.
see eg this line in devsw_attach():
newptr = kmem_zalloc(new * DEVSWCONV_SIZE, KM_NOSLEEP);
for what happens
3. Is it possible to automatically create a device file in /dev from a
module?
Not really, at least not from a loaded kernel module.
sure you can. ipfilter was doing this back with LKMs in the 90s :-)
BTW, devsw_attach() doesn't automatically generate the major. It does
a lookup
matthew green writes:
BTW, devsw_attach() doesn't automatically generate the major. It does
a lookup in the majors table. If there is no entry in the table, you
get an error.
see eg this line in devsw_attach():
newptr = kmem_zalloc(new * DEVSWCONV_SIZE
Maxime Villard writes:
Le 22/03/2015 19:27, Jean-Yves Migeon a écrit :
Le 20/03/2015 17:44, Maxime Villard a écrit :
In fact, I have a better solution.
What about adding a .enabled={0;1} sysctl to each compat module? This way
the Linux/FreeBSD modules are available by default, but not
Is the ignoring of attach priority a general characteristic of
indirect buses, and might it make sense for config to be able to
explicitly prioritise the order the cfdata[] entries? I know uebayasi@
has been rototilling config and wondered if he could be interested...
:)
The problem
delayed console isn't a bad
idea -- i'd like to be able to have multiple console output as well,
like linux has provided with 'console=vga console=com1' since at
least 2.4 days...
.mrg.
Thoughts?
-Brian
On Mar 4, 9:10am, matthew green wrote:
} Subject: re: i386 vs radeondrmkms problem - isa
hi folks.
i've been trying to find a least-ugly solution to the radeondrmkms
on i386 problem. quick summary of what's wrong:
radeondrmkms doesn't complete attachments (and most
importantly create a wsdisplay) until mountroot completes.
this means it happens quite late
Christos Zoulas writes:
In article 2015021322.g...@norite.fritz.box,
Izaak yitz...@inbox.ru wrote:
On Fri, Feb 13, 2015 at 05:17:24PM +, Christos Zoulas wrote:
In article 20150208103806.ga1...@norite.fritz.box, Izaak
yitz...@inbox.ru wrote:
Having read through many files, I
If the diskless client is i386 or amd64, configuration via 'dhcpcd'
during startup works just fine.
There are no arch differences in the code, so I find this surprising.
dhcpcd has grown a little bigger since the initial import, mainly due to
the configurable DHCP option engine to mimic
hi folks.
while trying to fix any midi/sequencer issues i've seen in the
last year, noticed that any attempt to call 'midiplay' on more
than one midi device at the same time, while not allowed, would
leave the sequencer device always busy.
i tracked this down to an ugly race condition inside
Maxime Villard writes:
Hi,
a bug I spotted some weeks ago:
-- libexec/httpd/auth-bozo.c l.139 --
base64_decode(const unsigned char *in, size_t ilen, unsigned char *out,
size_t olen)
{
unsigned char *cp;
size_t i;
cp =
Good point. There must be a way for drivers to declare if
CALLOUT_MPSAFE or not. Need to extend if_flags.
Hmm, if_flags.
http://mail-index.netbsd.org/tech-net/2009/01/27/msg000985.html
Do we have to care about kvm(3) users (i.e., netstat) as well as
the callout_t issue?
[ .. ]
Ryota Ozaki writes:
On Mon, Nov 24, 2014 at 5:26 PM, matthew green m...@eterna.com.au wrote:
could you also fix netstat, etc., to use sysctl to obtain this
info, while you're at it, so we can provide a stable ABI for this
such that changing internel kernel information doesn't matter
could you also fix netstat, etc., to use sysctl to obtain this
info, while you're at it, so we can provide a stable ABI for this
such that changing internel kernel information doesn't matter.
.mrg.
I have added another option. The bootloader may pass a string
that is interpreted as in 2. or 3. Like the other options, the
data is passed in a global variable from MD to MI code.
Previously defined variables are:
boothowto - boot flags
booted_device - the boot disk and
Izaak writes:
Hi,
I am interested in working on the project to convert kernel printf to
the appropriate aprint or log function:
http://wiki.netbsd.org/projects/project/aprint/
There was a short discussion about modifying log(9) in June:
Christos Zoulas writes:
In article 544e69a5.6040...@m00nbsd.net,
Maxime Villard m...@m00nbsd.net wrote:
Can someone explain me what this means?
sys/compat/netbsd32/netbsd32_compat_50.c:
256 (void) copyout(atv,
257 SCARG_P32(uap, olddelta),
258
Michael van Elst writes:
bou...@antioche.eu.org (Manuel Bouyer) writes:
definitively not. I want a panic.
Definitely an administrative decision then. You could make it a
mount option :)
indeed.
istr that solaris has onerror=panic|remount|unmount|...? option.
.mrg.
Definitely an administrative decision then. You could make it a
mount option :)
indeed.
istr that solaris has onerror=panic|remount|unmount|...? option.
Same for Linux.
But before you can make it a mount option, the filesystem code
must be able to handle the cases without panic
i think having various different types (that often alias to other
types, depending on the platform) is the right thing.
we have data represented in signed/unsigned int/long/32/64 bit,
and i think the only really safe way to do that is to provide the
explicit types used. ie, give me a
Martin Husemann writes:
There was a recent discussion on port-sparc64 about the cpufreq(9) interface,
and I noticed it basically is a single, global interface, which stores
a single cookie.
This sounds a bit restrictive; for one it assumes identical cpus and available
frequencies for all
prlw1cloexec 2336 10 /usr 7439186 -r--r--r-- 58736 r
prlw1cloexec 2336 13 /home1375614 -rw-r--r-- 18 r
fd 10 is /usr/X11R7/lib/X11/fonts/TTF/VeraSeBd.ttf
fd 13 is /home/prlw1/.xsmstartup
looks like X has some close-on-exec problems as well. xsm is
Finally, adding cfgread/cfgwrite commands to pcictl seems like a step in
the wrong direction. I know that this is UNIX and we're duty-bound to
give everyone enough rope, but may we reconsider our assisted-suicide
policy just this one time? :-)
How well has blindly poking configuration
Sounds reasonable to me, although it looks like GCC's old builtin
memcmp expansion actually failed to implement our specification: it
returns -1, 0, or +1, like your patch, rather than the difference of
the first differing bytes or zero as our man page specifies. For most
uses it
David Young writes:
On Mon, Aug 18, 2014 at 11:28:13AM +0200, Maxime Villard wrote:
Hi,
my code scanner reports in several places lines like these:
return ERROR_CODE/func(XXX);
return VALUE;
In some of your examples, it looks like code may have been copied and
pasted. Is
no idea on the real problem, but to answer why you might get
strange returns from copyin/copyout().
these can trigger page faults, which in turn can trigger paging
(in this case, most likely from swap.) the result of that is
eventually handed back to copyout(), so you kind of have to read
much
i didn't look too closely, but this:
+#include uvm/uvm.h /* for vtophys on arm */
should probably be uvm_extern.h.
.mrg.
+ if (secsize DEV_BSIZE) {
+#ifdef DIAGNOSTIC
+ printf(Invalid block secsize %d\n, secsize);
+#endif
+ error = EINVAL;
+ goto error_exit;
+ }
if (argp-flags MSDOSFSMNT_GEMDOSFS) {
if (secsize != GEMDOSFS_BSIZE) {
That's an
Christos Zoulas writes:
In article 7469.1405225...@splode.eterna.com.au,
matthew green m...@eterna.com.au wrote:
hi folks.
something really nasty happens on drmkms kernels if the vesa xorg
driver is loaded. they're not compatible and won't become that way.
the way xf86-video-vesa
hi folks.
something really nasty happens on drmkms kernels if the vesa xorg
driver is loaded. they're not compatible and won't become that way.
the way xf86-video-vesa handles this is by a libpciaccess call to
determine if the device has a kernel driver attached. i've implemented
this below
But doesn't mknod automagically know the driver's major number from
its name? I always used to do:
mknod /dev/foo0 c foo 0
And 'foo' got automatically resolved to the proper major number.
Does that work for modules too?
oh, it should!
i forgot about this. nice.
(it uses kern.drivers
Christos Zoulas writes:
In article 53ac78b6.9090...@runbox.com, Jan Sucan su...@runbox.com wrote:
Hello,
I am interested in NetBSD kernel and I have written a simple character
pseudo device driver module which calculates Fibonacii numbers. It works
but there is something I am not
Christos Zoulas writes:
Well, let's not propagate the evil design! I is is one thing having:
void *p = malloc(n);
free(p);
where you know p is going to be NULL when it fails and another having:
foo *p;
error = allocate_foo(p);
free_foo(p);
and expect
let's not forget my favourite mis-feature of MSI/MSI-X:
if you misconfigure the address, interrupts might cause main memory to
be corrupted. i've seen this happen, and it was rather difficult to
diagnose the real culprit..
i'm a little confused about bus_msi(9) -- pci_intr(9) is already an MD
I think that Mindaugas is being pragmatic here. Developers are not
equally brilliant[*], observant of the rules, or perceptive of the
patterns, layers, or abstractions in the code. He is writing the code
in a way that discourages us from casually misusing or breaking it by
getting under
matthew green:
all we have to do is, like this case, simply not install them.
But i had to learn that this would break fstat(1) and pmap(1).
So i do not dare to uphold my proposal to remove the semi-private
header files.
yeah - i saw that right after i sent my post :)
if those parts can
i'm pretty sure your plan will work fine. the things you'll
need to deal with on top of what i've seen so far are related
to the sets creation. in src/distrib/sets/lists/comp you'll
find all these files you're looking at not installing now.
they'll need to be marked obsolete in here.
you could
At the time I filed the PRs they were contested by AD because the libc
counterparts were already documented, with the syscalls considered the
private interface. I personally believe that all syscalls should be
documented in NetBSD (and recently I have learned that I'm not the only
one to
However, it has a quirk that I don't think our scheduler will deal with.
It has 4 Cortex-A15 cores @ 1.4Ghz and 4 Cortex-A7 cores @ 1.2Ghz. Even
if the frequencies weren't different, the A15 cores at least twice as
fast per cycle than the A7. That asymmetry is going to cause havoc with
Such byte lane offset adjust ment is required only if
- byte registers are wired to LSByte in 32bit bus
- byte lane wiring are swapped by hardware (like osiop(4))
but most (all?) PCI bus_space(9) implementations swap
byteorder of PCI access by software (i.e. in MD bus_space(9)).
FYI: not
Latest revision of the netbsd32 swapctl patch
this looks good now.
thanks for dealing with this properly!
.mrg.
this is gross. all those magic numbers turn my stomach.
can you please define a compat structure using appropriately
placed __packed members to force the correct values, and then
use these structures as necessary.
thanks,
.mrg.
this is gross. all those magic numbers turn my stomach.
can you please define a compat structure using appropriately
placed __packed members to force the correct values, and then
use these structures as necessary.
... which is basically what dsl was suggesting, but with
more useful
times and the only snags I've run into are that very old i386 NetBSD-0.x
binaries won't run and there is a compatibility bug in the socket code
whereby 32-bit programs can't use local sockets to talk to other programs
via AF_LOCAL sockets.
are there PRs for these problems?
Other than
oh, one thing i forgot to mention.
i386 and amd64 do NOT have compatible /dev. if you boot an amd64
kernel, make sure you run an amd64 MAKEDEV in /dev.
yes, this sucks big time.
.mrg.
i386 and amd64 do NOT have compatible /dev. if you boot an amd64
kernel, make sure you run an amd64 MAKEDEV in /dev.
Yes, I noticed that. Fortunately, raidframe causes most of /etc/fstab to
be shielded from that.
it does?
the biggest problem is that eg, i386 wd1a is amd64 wd0i and
i386
Since nobody opposes, I am going to commit that. Perhaps the option name
could be better: NATIVE_EMULROOT or EMULROOT_NATIVE?
--- sys/kern/kern_exec.c.orig 2014-01-21 16:55:00.0 +0100
+++ sys/kern/kern_exec.c2014-01-21 16:55:13.0 +0100
@@ -184,9 +184,13 @@
does it reload and reexport file systems if you mount something and
mountd should be told to export it?
i don't see any utility in having nfs server auto unload.
.mrg.
i don't see any utility in having nfs server auto unload.
It's no different than any other auto-loaded module, such as compat. If
a module is auto-loaded, the system makes a single attempt (after an
appropriate timeout) to auto-unload. The module is notified and given
an opportunity
On Mon, 09 Dec 2013, Mouse wrote:
I actually don't see anything that promises that a pointer to a
function type may be converted to a pointer to void, nor back
again (except, in each direction, when the original pointer is
nil), much less promising anything about the results if it is
Run a single nfsd and it all works much better.
On that basis should the NetBSD default be changed from -n 4?
i definitely would object to such a change.
i see slowness from multiple clients when i run nfsd with just
one thread. i've never seen the problem dsl has seen with a
netbsd nfs
The problem is a change in the semantics of local domain
socket addresses. Previously, they had a fixed size, and the
path name contained within the address was therefor normally
'\0'-terminated. Now the address is the common socket address
part plus the pathname, where the terminating '\0'
} I would be interested in knowing an actual example of the comparison
} problem with the CIRCLEQ macro, if the concern isn't theoretical. Since
Uh, do you really think people would be doing all this work
for something that was theoretical? The problem is that gcc 4.8
optimises out
hi folks.
while preparing to update to GCC 4.8 i discovered that our sys/queue.h
CIRCLEQ macros violate C aliasing rules, ultimately leading to the
compiler eliding comparisons it declared as always false.
unfortunately, changing these macros to be strictly C requires changing
the ABI of them,
I would like to change the way vmem(9) allocates boundary tags towards
using a pool(9) for that.
This de-duplicates code and makes it possible to release memory pages
used for boundary tags.
early patch any comments?
i fear adding another way that vmem and pool can loop, ala my
post a
Personally, I think the underlying structure of files should not be made
visible to apps at all - they should just see a byte stream (perhaps with
an advisory useful block size to write in).
i would buy this argument if mmap()ing a large sparse file
and filling it up randomly (but with
a sunblade 2500 with 4GB ram and one cpu hung earlier today. the
stack trace of the active lwp from ddb shows me that there is a
loop between pool/uvm/vmem in low memory condition.
show uvm says that there is only 1 free page, and the bt is:
db{0} bt
intr_list_handler(59c86d0, a, e0017ed0,
Not altering the BUS_CNTL register would seem easier. However, detach does
work if that's not possible.
well -- this doesn't help ddb or dropping to the prom directly
does it?
i think a solution that leaves it working without any special
detach needed is the best idea here.
.mrg.
hi folks.
as part of the GCC 4.8 preparation work, we're seeing many new
warnings where variables are only used inside KASSERT(), but
the non-diag kernel builds trigger errors.
my solution, rather than marking these variables with __USE(),
is to change KASSERT() into a real function that
ps: I had been meaning to rant like this for some time, your message just
provided the incentive today!
:-)
i will note that i'm also a fan of using -o async FFS mounts in
the right place. i just wouldn't do it for a file server :-)
I tried moving a client NFS mount to async. The result is that the
server never sees a filesync again from that client.
Further testing shows that server with -o log / client with -o async has
no performance problem. OTOH, the client sometimes complain about write
errors. -o async
Memory: 15G Act, 113M Inact, 15M Wired, 29M Exec, 15G File, 112K Free
Swap: 8192M Total, 8192M Free
the file cache shouldn't be allowed to use that much memory.
why do you say that? vm.filemax is not really a maximum, it
can use all free memory if there isn't memory pressure.
however,
Parity Re-write is 79% complete.
OK, so this is really more about how parity checking works than
anything else (i guess.)
for RAID1, it reads both disks and compares them, and if one
fails it will write the master data. (more generally, it
reads all disks and if anything fails parity check it
what does raidctl -s and -m (separate commands) say?
It's an obvious optimization to keep type already in the directory
itself. But is there any other reason why it was added there? It
obviously means you have the same information in two places, with all
struct dirent is not stored on the disk, but created during
eg readdir() system call via
On Sat, 06 Jul 2013, Manuel Bouyer wrote:
But I would expect close() to do an implicit fsync() as well,
and return the error if the implicit fsync() didn't succeed (but
still closing the file). As I already mentionned, linux behaves
this way, and I guess applications expects this
I'm fairly sure that fork work fail (cleanly) for 'lack of physical
memory' or 'lack of KVA', at least not without the world exploding
at the same time. So I'd guess you are just hitting the 'ulimit -p'
soft limit on the number of processes.
FYI: fork() hangs if there is not enough KVA, in
wd0(ixpide0:0:0): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133) (using DMA)
ah, this is probably fixable by changing your BIOS to use AHCI
instead of IDE.
(we really need to fix ixpide in this situation.)
.mrg.
spl(9) has a number of details that might be useful to this thread.
.mrg.
SPARC64 X products from Fujitsu ?
http://pr.fujitsu.com/jp/news/2013/01/18.html
... the least sister of Kei Super computer technology.
mrg@ was working on SPARC64-V ( or was it -VI? Whatever is
used in PrimePower 250 ) support.
Here goes the quick summary of spec. Compared to T4,
As you move Lua to the kernel space, dist location should be moved to
sys/external.
I am not movin Lua to the kernel space, I am using it there, too. It
is the same Lua that is usable in userland, so there is no sense in
changing the source location.
doesn't matter. if you have code
I want to import the lua(4) device driver, which is currently a module only,
which seems wrong.
Is sys/dev/lua/ a good place?
can you give a little more details on what is included?
at a guess, if there are more than a couple of files
then sys/dev/lua is an OK place, otherwise just
is there a way to structure the code such that there
are more modules (whether modloaded or statically
linked) such that:
gpiosim_lua: gpiosim lua
Did you mean having two gpiosim modules, one with and one without Lua?
no.
i mean having a gpiosim_lua module that adds lua support
this is going to upset dyoung i'm sure :) but it seems to me that
if these invasive changes to individual subsystems are needed like
this, and we want them to be optional, then imo they should be on
a per-subsystem basis, not global. eg something like:
options LINEDISC_LUA
(Okay, that's not quite true. Using always_inline doesn't necessarily
mean committing to gcc. But _depending on_ always_inline does, ISTM.)
there are at least 3 other compilers i'm aware of that support
always_inline attribute, along with many of other GCC specific
features that aren't part
I've reread the whole thread but I don't understand how fch* and fexec*
differ.
As far as I can see all they cause the same sort of problems.
So, a solution should be the same for all of them.
AFAIK (i didn't write a test), fchroot() outside of the chroot
is already disallowed by the
you'll need to make sure all the modules build with -DXEN, which isn't
something someone has done or can tell you for sure method for it.
probably just setting DBG=-O2 -DXEN is most likely.
you'll also need to rebild your kernel with this line changed:
sys/arch/amd64/include/pmap.h:#define
On Fri, Nov 16, 2012 at 12:52:30PM +, Julian Yon wrote:
On Fri, 16 Nov 2012 08:34:29 +
David Laight da...@l8s.co.uk wrote:
On Thu, Nov 15, 2012 at 10:14:18PM +0100, Joerg Sonnenberger wrote:
Frankly, I still don't see the point why something would want to
use it.
I would like to know if there is an NetBSD equivalent for devd(offered
by FreeBSD) or Udev(offerred by Linux) utility that can automatically
detect device connect/disconnect, attach/detach to/from the system.
see devpubd(8) -- it monitors autoconf activity and can run scripts
to do whatever.
On Wed, Nov 07, 2012 at 02:30:22PM +0100, Edgar Fu? wrote:
But it did. Twice.
Third time, same backtrace. In this case, a simple
mkdir x
on the same file system as before.
That's a plain FFSv1 sized 553MB with 64k blocks. The only unusual thing is
it has some 10 inodes.
backwards compatible with older kernels. New kernels seeing a '0' in
that spot would simply pick 'fifo' as before. One question is whether
to use 0,1,2,3 to encode the strategy, or to use letters, or whatever.
But that's just a minor implementation detail.
considering the random garbage we
fwiw, you can usually work around this with setting
SHELL=/bin/sh when invoking gdb.
.mrg.
That's interessting what size does the arena have on the system with
512mb? Probably limited by NKMEMPAGES_MAX_DEFAULT, so it might need to
be larger on those.
i noticed macppc already defines this to 256MB. trying that now.
.mrg.
Yes, that's what I think. Having the
with some help from chuq@ we've narrowed this down to the
kmem_arena being under 10% empty:
db call uvm_km_va_starved_p
1
which keeps the main loop from sleeping. but why this is full and
not being fixed by the page daemon isn't a mystery.
.mrg.
That's interessting what size does the arena have on the system with
512mb? Probably limited by NKMEMPAGES_MAX_DEFAULT, so it might need to
be larger on those.
i noticed macppc already defines this to 256MB. trying that now.
.mrg.
I committed the fix to make swapcontext/setcontext usage safe with
libpthread. This involved modifying assembly code in libc for various
ports, something that could not be tested before the change.
there's an easy way to run tests for a bunch of platforms via emulators,
(we run several
OK. Indeed it doesn't looks very good. The 32bit binary aborts on a 32bit host
becuase of the missing above sysctl , but I couldn't get neither the
32 or 64bit binaries to run at all on a 64bit host.
doesn't look like amd64 has any support for freebsd at all.
I'd like to two add one more argument to pmap_kenter_pa
and two more to pmap_enter.
To pmap_kenter_pa, I want to add a vsize_t after the pa argument:
void pmap_kenter_pa(vaddr_t va, paddr_t pa, vsize_t len,
vm_prot_t prot, u_int flags);
To pmap_enter, I want to add the same
I have a (mpt) SAS with seven discs connected.
The discs attach as sd0..sd6, but the SCSI target numbers are 0..5 and 7.
It appears to me that someone is skippig ID 6 for the controller.
It doesn't hurt too much, but it took me a while to find out why detaching
targets 2, 3, 4 and 5 worked
201 - 300 of 414 matches
Mail list logo
