On Tue, Jan 05, 2010 at 01:11:23PM +0100, Joerg Sonnenberger wrote:
Unless the polling for battery and TZ is disabled, it won't.
Do they deliver reliable data with these errors? If not, disabling sounds
like a valid option.
Martin
On Wed, Jan 06, 2010 at 08:42:12PM +, Christos Zoulas wrote:
Try 'shutdown -p now'. I've had problems with deadlocks when using halt -p
due to processes not dying on time and the kernel getting stuck on their
resources (or even panicking).
Another test is:
sysctl -w
On Mon, Feb 08, 2010 at 11:11:04AM +0100, Frank Wille wrote:
- Running a kthread and calling kpause() between the polls.
- Using a callout which reschedules itself after the poll.
The thread is quite a bit more heavyweight, but you have full freedom
to do what you want. The callout is pretty
On Mon, Feb 08, 2010 at 03:35:35PM +0100, Frank Wille wrote:
IMHO that would allow my callout to sleep on acquiring the mutex?
A softint can sleep, a callout can not.
Martin
I had only positive feedback on the proposal so far.
Attached is a updated version of the MI parts.
I did a bit of cleanup and added a way to pass device dependend cookies
trough to the i2c devices - I need this in a machine specific driver, and it
seems to be the simplest way to do this
On Sun, Mar 07, 2010 at 11:08:12PM +0100, Manuel Bouyer wrote:
I don't know, I didn't try then one by one.
It would be usefull to have a list of handlers which are run, to
ease debugging this sort of issue.
doesn't boot -v provide you with that sort of output?
Martin
On Wed, Mar 10, 2010 at 09:46:03PM +0900, Masao Uebayashi wrote:
[..] For example,
bus_addr_t of a device instance should be taught to struct device as
an attribute (or property or whatever you call).
What is *the* bus_addr_t of a device instance?
Then we can have a
unified way to calculate
On Wed, Mar 10, 2010 at 11:11:38PM +0900, Masao Uebayashi wrote:
What is *the* bus_addr_t of a device instance?
That depends.
On what?
And this answer has never been answered. This is why we have all the
messy MD bus code like rbus...
I disagree (not on messy, MD, rbus, but on above
On Wed, Mar 10, 2010 at 11:30:17PM +0900, Masao Uebayashi wrote:
Details of architectures and buses.
And also on the device - there might be multiple addresses needed.
I don't know how multiple MMUs work.
It just means that there is no global view of the VA - PA mapping,
especially the device
On Tue, Mar 16, 2010 at 05:26:20AM +, David Holland wrote:
After a fashion. Check how our LOCKDEBUG works. :-/
You mean crawls?
Martin
On Sun, Apr 11, 2010 at 09:17:28AM +0100, Iain Hibbert wrote:
whereas it worked fine with u3g afterwards. I don't know if some of that
work needs to be pulled up but it might be worth disabling uhmodem and
trying the u3g driver..
There was some fallout, but this seems to be fixed now - so
On Fri, May 07, 2010 at 09:28:31AM +, Andrew Doran wrote:
Right, on the face of it I don't see why this is something to be handled at
runtime.
Move consinit() past uvm_init() ;-}
Martin
On Fri, May 07, 2010 at 08:39:51PM +0100, Mindaugas Rasiukevicius wrote:
Well, kmem(9) is initialised very early, just after pool(9), in uvm_init(),
where I moved it couple years ago. Yes, 'cold' is unset very late. Since
allocation gets postponed anyway, is that a problem? You did not
On Fri, May 07, 2010 at 04:05:30PM -0400, Michael wrote:
kernel output anyway. All it needs is a sane way to decide wether it
can allocate memory or not.
So split init in a minimal (optional) version called from the consinit
functions, and a full grown init called at driver attach time (and
On Sat, May 22, 2010 at 08:29:22PM -0700, Paul Goyette wrote:
attempt to load from the filesystem. I expected it to fail, but the
failure mode is rather ungraceful
Maybe this would help?
Index: vfs_lookup.c
===
RCS file:
Looks good, but the __mp_friendly name is not quite obvious. Why not call
it __cacheline_aligned?
Martin
What are the arguments to bus_space_tag_create()?
I'm looking for a flag to tell it the bus endianess of the resulting tag,
as that would help to sort out an abstraction violation in SBUS - pcmcia
adapters. Support for that would be optional, of course.
Martin
On Thu, May 27, 2010 at 12:06:53PM -0500, David Young wrote:
You could also override bus_space_map() or whichever routine is most
suitable.
Yes, and for the sparc case it would work, but sparc64 can do it a
lot more elegantly, and I'm still looking for a way to request the MD
bus_space_*
On Sun, Jun 06, 2010 at 01:15:54AM -0500, David Young wrote:
Where in the kernel do I plug in an MI common page? I mean a
(read-only) page shared by the kernel and each user process.
Check kern/kern_lwp.c:lwp_ctl_alloc
Martin
On Tue, Jul 27, 2010 at 01:56:23AM +, Quentin Garnier wrote:
For free is a subjective thing. I don't think using device_register()
--which is a MD callback--to pass information between two MI drivers is
free.
Well, using a MD callback to attach MD information from ACPI somehow
makes sense
On Fri, Oct 15, 2010 at 08:26:34AM +0300, Jukka Ruohonen wrote:
This was discussed during the development process.
Where?
Martin
On Wed, Oct 06, 2010 at 05:04:06PM +0200, Martin Husemann wrote:
I'm testing the patch in -current with these hardware:
bge0 at pci2 dev 0 function 0: Broadcom BCM57780 Fast Ethernet
bge0: interrupting at ioapic0 pin 16
adjust device control 0x192000 - 0x195000
bge0: ASIC BCM57780 A1
On Fri, Oct 29, 2010 at 04:32:28PM -0700, Brian Buhrow wrote:
Hello. Is this something you can reproduce easily? I wonder if the
ethernet chip is just hanging, and the rest of the machine is fine?
The machine was fine otherwise. I didn't have time last night to experiment,
will
Let me play devils advocate for a minute:
If we create a library with such a wiered API that we need another library
to make use of that libary easy - maybe we are abusing that libary or
we should reconsider its API?
This is one of the ocassions where I would love to use C++ and templates
in the
Sorry, have been travelling too much lately. I verified the kernel that
showed the problem did indeed have the patch applied, but didn't get around
to doing any further diagnostics yet.
Martin
I just checked that at least my problem with the patch is NOT a regression:
it fails the same way w/o the patch.
So: something else to investigate, no reason to delay this.
Martin
Will this allow time to proceed while at the ddb prompt?
I considered using the feature to keep the fan controll loop active on
a SB1000 while in ddb (the alternative is to make fans run full speed on
ddb entry, which is a real nuisance if you are anywhere near the machine).
Martin
Disclaimer: I know nothing about LFS, but it seems to me that there is no
guarantee for curpg to not be NULL in the following code from
src/sys/ufs/lfs/lfs_vnops.c:
while (by_list || soff MIN(blkeof, endoffset)) {
if (by_list) {
/*
On Wed, Jan 05, 2011 at 04:25:09PM +, Eduardo Horvath wrote:
I think you're right. While I'm pretty sure that curpg won't be NULL on
the first iteration, I think it can be NULL on subsequent iterations. I'd
commit that change.
It shouldn't get there on subsequent iterations if it
On Wed, Jan 05, 2011 at 05:03:15PM +, Eduardo Horvath wrote:
If by_list is set we'll always get here, and I don't think we'd be called
if the vnode had no pages at all
Ok, I'll add a KASSERT() to check for that and re-run the tests.
Martin
On Wed, Jan 05, 2011 at 06:06:17PM +0100, Martin Husemann wrote:
Ok, I'll add a KASSERT() to check for that and re-run the tests.
Indeed, it never happens on first entry to the loop, but via the goto top
later.
I'll commit the original patch. Unfortunately I run into locking issues
later, so
On Wed, Jan 05, 2011 at 07:35:53PM +, Eduardo Horvath wrote:
Really? Last time I tried (about a month or two ago) I wasn't able to
hang LFS. OTOH, looks like there's been quite some churn since then.
What's your setup and what tests are you running?
I run src/tests/fs/vfs/t_full
After Christos recently added sigqueue and friends to -current, I tried to
use them to fix a long standing softfloat userland problem. One variant of
the problem shows up in sparc64 atf test runs (sparc64 uses softfloat
for 128 bit long double): the userland software, and our atf tests, expect
to
On Fri, Jan 14, 2011 at 07:14:43PM +0100, Matthias Drochner wrote:
If you have some basic FPU available, you could just cause
matching SIGFPEs using eg doubles. Eg assign
HUGE_VAL*HUGE_VAL to a double, or divide a double by zero.
The sun libm code does this in some cases.
That's certainly an
On Sat, Jan 15, 2011 at 10:26:13PM +0100, Christoph Egger wrote:
Hi!
I have a machine with two PCI graphic cards:
1x Radeon HD 4200
1x Radeon HD 5600
Starting X fails with the error message
Primary device is not PCI
Per discussion with macallen@ I implemented
On Sun, Jan 16, 2011 at 08:59:15PM +0100, Joerg Sonnenberger wrote:
That's what the version number is supposed to tell you.
Just thinking out loud: could we make the embedded date conditional
on some /etc/mk.conf variable, unset for standard builds?
Martin
On Tue, Jan 18, 2011 at 09:47:29AM +0100, Christoph Egger wrote:
In /var/log/X.org both Radeon devices are enlisted but none has been
selected as the primary one. X then quits with the message
Primary device is not PCI
I still don't understand what this means, and why it doesn't choose
one of
On Tue, Jan 18, 2011 at 11:39:35AM +0100, Christoph Egger wrote:
The function pci_device_is_boot_vga() is supposed to return
'true' for the pci vga device the firmware uses which is not
neccessarily the OS console device (it can be a serial console).
Ok. But your function answers this is the
On Tue, Jan 18, 2011 at 12:19:50PM +0100, Christoph Egger wrote:
According to macallan@ ttyE* is the first graphic device,
ttyF* the second, ttyG* the third, etc.
Yes, counting in NetBSD autoconfig probe order.
So yes, it is safe.
Depends on the exact question, which has been explained out
To summarize what goes on: on x86 archs (and AFAICT for NetBSD only there)
the X starup code enumerates all pci buses the kernel found, searching for
vga devices. If multiple are found, it prefers the one that the new function
marks. That's basically all about it.
If the new function says no to
On Tue, Jan 18, 2011 at 05:02:13PM +0100, Johnny Billquist wrote:
Ok. And that is good because...?
Various, the most prominent benefits:
- you can easily do binary patches
- you can verify code you touched that should have no effect realy did not
have any effect
- you can verify toolchain
On Fri, Jan 14, 2011 at 10:06:09AM -0800, Matt Thomas wrote:
I'm thinking the check should go away.
How about the variant below - it allows a process to deliver arbitrary
signals to itself, but only SI_USER/SI_QUEUE variants to foreign processes.
Perhaps the whole part inside the new if ()
On Mon, Jan 24, 2011 at 03:27:58PM +, Mindaugas Rasiukevicius wrote:
While looking at the bugs on still work-in-progress mips64 FPU code on
Matt's branch, it occurred to me that we could abstract SMP handling
complexity into MI interface. Basically, all architectures are using
similar
On Fri, Jan 28, 2011 at 11:14:44AM +0100, Stephan wrote:
What is going on here? Does the struct scsipi_xfer_mode *xm come from
the scsipi layer so it tells the driver what to do?
Yes, it is set from the target discovery code, so you should get a 1 bit
there for every target device that
On Fri, Jan 28, 2011 at 11:30:16AM +0100, Stephan wrote:
The discovery code you spoke from is part of every device driver,
isnt`t it? The scsipi man page tells about a XS_CTL_DISCOVERY flag in
xs_control, which i can?t find in the mpt driver. So how does e.g. the
mpt driver tell the scsipi
On Thu, Mar 10, 2011 at 07:45:20PM +0100, Manuel Bouyer wrote:
Can you see if tests/sbin/fsck_ffs completes fine on sparc64
(atf-run|atf-report in this directory) ?
All quota tests pass on sparc64 (see http://www.netbsd.org/~martin/sparc64-atf)
Martin
On Mon, Mar 28, 2011 at 03:50:46PM +0300, Jukka Ruohonen wrote:
I would go for (3), perhaps with a -s flag to halt(8). This would also solve
the user interface issue that remains unresolved in options (1) and (2).
Extending halt(8) has been discussed also previously (cf. e.g. [1]).
Don't mix
On Mon, Mar 28, 2011 at 08:16:09PM +0200, Joerg Sonnenberger wrote:
Implementing a real posix_spawn system calls could do that. Measuring
the impact for different work loads makes a nice research paper as side
effect. This includes both estimate the temporary memory used and the
performance
On Sat, Apr 02, 2011 at 11:30:16AM +0200, Manuel Bouyer wrote:
AFAIK dtrace doesn't work on non-modular kernels ...
Nor on most of our archs, and AFAICT there is not even a document
describing the (maybe nontrivial amount of) work needed to make it
work there.
Martin
On Wed, Apr 06, 2011 at 02:07:18AM +0300, Vladimir Kirillov wrote:
Hello, tech-kern@!
I really wanted a show proc command to avoid looking up process
information by running ps with all flags and intensive scrolling.
The show proc output mostly combines the outputs of all switches
in ps.
On Wed, Apr 06, 2011 at 11:03:47PM +1000, matthew green wrote:
since it works on lwps...can we call the MI version show lwp lwpaddr?
Ok for the address based variants:
show lwp
(shows curlwp)
show lwp 0xffce
(shows lwp at that address)
but with a pid/lid it gets strange:
show
Hi folks,
as described in PR 44774 (see
http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=44774), it is
currently not possible to use a standard NetBSD install CD on a system
wich normally boots from raid (at least on i386, amd64 or sparc64, where
a stock GENERIC kernel is used).
To fix
On Mon, Apr 18, 2011 at 01:06:23PM +0200, Klaus . Heinz wrote:
Instead of providing RB_NO_ROOT_OVERRIDE I would prefer something that
actually _lets_ me override everything else from boot.cfg.
Yes, I understand this wish (and it is not that hard to implement).
However, I think both are quite
On Mon, Apr 18, 2011 at 11:59:32PM +0900, Izumi Tsutsui wrote:
I thought passing root on cd0a from boot.cfg just worked on x86..
Maybe, but I'm not talking about x86 only.
Martin
On Wed, May 04, 2011 at 08:50:10PM +0900, Izumi Tsutsui wrote:
The problem is that there might be some ports whose MAXPARTITIONS is still 8
and such ports can't use type 8.
Why not? It is not used as a partiton of fd*.
MAKEDEV is already wrong for those ports, the fd nodes probably should have
On Thu, May 05, 2011 at 01:27:50AM +0900, Izumi Tsutsui wrote:
I'm afraid few developers will maintain MAKEDEV script properly,
and few users will rerun /dev/MAKEDEV on upgrade.
Nothing that usr.sbin/postinstall can't fix (or at least warn about)
Nowadays floppy is almost dead, so we don't
On Fri, May 06, 2011 at 04:53:41AM +0900, Izumi Tsutsui wrote:
If we fix kernels to use DISKUNIT() and DISKPART() macro
for FDUNIT() and FDTYPE(), we can bump a number of fd types
to MAXPARTITIONS with no further changes.
Nothing needs to be done by users in that case.
Oh, now I see what you
On Fri, May 06, 2011 at 04:45:55PM +0100, Jean-Yves Migeon wrote:
1 - I shall patch sysmon_pswitch_event and add a callback for sleep
that MD code can register,
Yes (or a list of callbacks, even, maybe not only MD code but various
subsystems might need this later).
Martin
On Sun, May 08, 2011 at 07:24:10PM +0200, Emmanuel Dreyfus wrote:
As I understand, FFS sits on top of UFS. We migrated from UFS1 to UFS2
some time ago (remeber the thing about the superblock that was
converted?), and now we can have FFS v1 or FFS v2 over UFS2. You choose
FFS v2 by formatting
On Sat, May 14, 2011 at 07:42:14PM +, David Holland wrote:
Should we change the dumpfs output to be more consistent with the
terminology we're trying to use?
Yes
On Thu, Jun 16, 2011 at 09:29:36AM +0200, Manuel Bouyer wrote:
So here's the formal question: would someone object if I add back
'options DIAGNOSTIC' to i386 and amd64 GENERIC and INSTALL kernels,
with a comment saying this should be disabled on release branch
(it would be up to releng to
On Thu, Jun 16, 2011 at 12:39:11AM +0800, Charles Zhang wrote:
- add the syscall to the src/sys/kern/syscall.master list
Use forward declarations in this version, like struct whatever *
instead of a typedef'd name, so the signature is valid all by itself.
Martin
On Thu, Jun 16, 2011 at 04:30:18PM +0100, Mindaugas Rasiukevicius wrote:
- Since performance is degraded and -current users concerned about it
will need to compile their own kernels anyway - I believe LOCKDEBUG
should be enabled as well. Perhaps LOCKDEBUG should become a part
of
On Fri, Jun 17, 2011 at 12:42:34AM +0400, Aleksej Saushev wrote:
I'd say that at least call ddb_vgapost should enter default sysctl.conf,
at least commented out. It isn't trivial to learn that the functionality
exists, and it is the only way to get to debugger on modern machines
without serial
On Wed, Jul 27, 2011 at 06:10:17PM +0100, David Laight wrote:
It is probably also worth avoiding allocating address 0 anyway.
What is it address 0 of? The physical address seen on the bus??
Yes, physical bus address, or offset 0 in whatever the parent window
maps to (think pcmcia or similar)
On Thu, Jul 28, 2011 at 03:13:28PM -0500, David Young wrote:
Here is a new snapshot of the PCI information that I'm reading out of
PCI Configuration Space. This time the format is slightly different,
and the property list includes the I/O-space reservations and the legacy
VGA regions.
This
I have a small (mostly conceptional) issue with sys/kern/exec_elf.c.
In my view the exec operation is kind of contstructor op for a vmspace,
but on the other hand exec needs to know where to put the interpreter,
which slightly differs if we are about to arrange for topdown VM layout.
My concrete
On Mon, Aug 29, 2011 at 02:36:04PM +0200, Aleksey Cheusov wrote:
If sender (chroot(2)) cares about unsharing kauth_cred_t
structure, all listeners will set their data without any problem provided
that kauth_key_t keys they use
are different. Key uniqueness is garanteed by
kauth_register_key.
On Tue, Aug 30, 2011 at 10:24:08AM +0300, Aleksey Cheusov wrote:
If all listerners unshare kauth_cred_t *unconditionally*, we lost data
set by kauth_cred_setdata. As I said later there is a workaround
(kauth_cred_getrefcnt or kauth_cred_copy) but I don't like it.
Ok, I got it now - thanks for
On Fri, Sep 09, 2011 at 09:37:08AM -0400, Matthew Mondor wrote:
and OpenBSD with it being absent on Linux. But pppd also uses the
in-kernel ppp support I think, which is probably different than Linux's.
The IP payload traffic should never go to userland, so I don't see how the
pty limit could
On Thu, Sep 15, 2011 at 09:20:56PM -0400, Michael wrote:
So, most wsdisplay drivers will hand you an 8bit colour-indexed framebuffer,
if you get higher colour depth it will be RGB unless you're on a Sun or SGI.
Aren't the mmap() details inherently MD anyway?
Though we should have some query
On Fri, Sep 16, 2011 at 08:10:35AM -0400, Michael wrote:
We do, and that's how the xf86-video-wsfb driver works.
And why does that not include the pixel format?
Martin
On Fri, Oct 21, 2011 at 12:35:51PM +0200, Manuel Bouyer wrote:
Yes, but I don't need to create a new syscall, with the versionning
issues this has.
Instead you force every (userland) consumer to do compat code itself,
and replace a simple structure conversion via copying with error prone
this
On Fri, Oct 21, 2011 at 02:54:59PM +0200, Manuel Bouyer wrote:
I don't understand this. The compat code (if any) is in the kernel.
And there's a whole class of compat code (type size change, or adding an
optional field) don't exist with a text-based format.
If you promise to keep the contents
On Thu, Nov 17, 2011 at 05:10:24PM +0100, Manuel Bouyer wrote:
With the old quotactl, the kernel has no way to tell if it really got a
string of a struct dqblk (or something else); it can just interpret the
pointer as a string and see if it works. If instead of a string it got
a dqblk whose
On Wed, Nov 30, 2011 at 10:44:42AM +0100, Frank Wille wrote:
I don't understand how NetBSD supports partitions larger than 2TB or
starting beyond the 2TB boundary (assuming a sector size of 512 bytes)...
Not with disklabels, but with wedges. While disklabel mixed the runtime
and on-disk
On Wed, Nov 30, 2011 at 11:49:46AM +0100, Frank Wille wrote:
Hmm... that means I would have to make a small boot/root partition,
which uses dkctl(8) to make the rest of the disk available?
Depends on what your firmware can boot. All new x86 machines can boot from
GPT.
And what about other
On Wed, Nov 30, 2011 at 12:33:12PM +0100, Frank Wille wrote:
There is an on-disk representation of the wedge?
Not an but many - anything suitable for your firmware or needs - so you
can use mac or amiga specific representations on the boot disk but GPT
on another (large) disk.
Martin
Hi folks,
during this years Summer of Code Charles Zhang and I implemented the
posix_spawn syscall. We are now at a point that, with some further minor
cleanup and debugging, this is ready to commit. The main changes are pretty
local, but to avoid code duplication a few of the existing file
On Mon, Dec 19, 2011 at 11:55:20AM +0100, haad wrote:
I can't see any test cases in newfiles.tar.gz. Maybe we should have
posix_spawn test cases before import.
As I said, there are test cases, but they are not fully ready yet. Of course
they will be at the time of commit.
Is RUMP
On Mon, Dec 19, 2011 at 04:18:38PM -0500, Thor Lancelot Simon wrote:
If it doesn't perform better -- do I misunderstand, or is that in fact the
case -- why dirty up the system with this superfluous interface?
No, I'm just saying that it does not make the existing fork/exec
path slower. We don't
On Tue, Dec 20, 2011 at 01:31:57AM +, YAMAMOTO Takashi wrote:
isn't it better to just swich to the newly created lwp and let it do these?
And have the parent lwp block on a cv untill the child signals it?
The parent would have to do all the copyin dance before and pass the full
information
On Tue, Dec 20, 2011 at 02:34:22PM +, YAMAMOTO Takashi wrote:
i haven't explored either.
Ok, I will give it a closer look (but that will take a few days).
well, i confess that i don't understand why in-kernel implementation is
desirable in the first place.
I don't know what alternatives
On Tue, Dec 27, 2011 at 09:19:48AM +, YAMAMOTO Takashi wrote:
vfork based implementation has its advantages. eg. less kernel code
i'm not sure what kind of dirty libpthread changes.
can you explain?
We would need to guarantee thread safeness of posix_spawn() - but vfork
itself is not.
On Wed, Dec 28, 2011 at 04:07:45AM +, YAMAMOTO Takashi wrote:
my understanding:
there is no need to stop other threads as far as posix_spawn is concerned.
so there is no big performace problems with a vfork-based implementation.
because our current implementation of vfork suspends the
On Sun, Jan 15, 2012 at 08:37:37PM +0100, Manuel Bouyer wrote:
Althrough I've done 1 as a POC, I prefer solution 2 (the patch is mostly the
same, with bflag remplaced by b_type). What do other think ?
(2) is conceptually what NTFS does IIUC. Consider a file to be a database
table to which
On Mon, Jan 16, 2012 at 10:39:45PM +0100, Manuel Bouyer wrote:
is branched. this won't ever be in netbsd-6 is not an option, I don't
think we can wait for netbsd-7 for this.
Why not?
Martin
Even if originally intended for something else, like Matt says, wouldn't it
be easier to just define two new flags for it like
BUS_SPACE_BARRIER_WB
BUS_SPACE_BARRIER_WBINV
and leave the rest of the API untouched?
Martin
On Tue, Jan 24, 2012 at 08:21:42PM +0100, Paul Fleischer wrote:
Is the usage of STACKALIGN indeed incorrect in this situation, or am I
missing the big picture?
I stumbled across this when revamping execve1 for posix_spawn recently.
The intention seems to be to align the stack on a 8 byte
On Tue, Jan 24, 2012 at 12:16:49PM -0800, Stephen M. Rumble wrote:
The ARM EABI requires 8-byte stack alignment at function entry. I don't know
if we're using the EABI, but this bug and its fix might indicate as much.
I don't think we do yet, but we should ;-)
Anyway, let's make a up-rounding
On Tue, Jan 24, 2012 at 03:30:37PM -0500, Matthew Mondor wrote:
Would this be considered wasteful? Of course, x86-64 MD code could
also be used...
I would prefer the x86 MD code, using the same technique as the (fixed)
arm code.
Maybe it could even depend on actual CPU type (i.e. SSE2
On Thu, Jan 26, 2012 at 04:16:35PM +0100, Joerg Sonnenberger wrote:
It overwrites the strong syscall symbols, so it covers libc itself as
well.
Rump will probably want to override posix_spawn completely to pass information
around (similar to the pre/post exec stuff it does). Worst case it need
Can you explain this new KASSERT?
+ KASSERT(vlen = sizeof(ai));
Martin
On Fri, Feb 03, 2012 at 10:25:36PM +0100, Martin Husemann wrote:
Can you explain this new KASSERT?
+ KASSERT(vlen = sizeof(ai));
Ah, never mind - it is an array, not a pointer.
Martin
On Fri, Feb 10, 2012 at 11:20:38AM +, YAMAMOTO Takashi wrote:
is it safe to release exec_lock?
Good catch - I'll defer the release untill the child has done it's rw_enter().
Martin
On Mon, Feb 13, 2012 at 06:56:00AM +, YAMAMOTO Takashi wrote:
Good catch - I'll defer the release untill the child has done it's
rw_enter().
it would deadlock if in the mean time another thread does rw_enter(WRITER)
on the lock.
Hmm, but we can't just use the existing parent lock in
On Mon, Feb 13, 2012 at 09:43:10AM +, YAMAMOTO Takashi wrote:
in this particular case, i think that the child does not actually
need to acquire the lock because the parent always keeps it locked.
probably some comments and assertion updates are necessary, tho.
Yeah, will fix it that way
Note that we already have file system snapshots for ffs file systems,
see fss(4). They are used for backup purposes (atomically create a snapshot,
while the file system is busy, then backup the now quiet snapshot) - among
others.
*)
What is it good for? The only practical use I can imagine are
On Fri, Mar 09, 2012 at 01:21:48PM +, Julian Coleman wrote:
This turned out to be because the kernel map was not large enough for machines
with 8GB or more of main memory. I've restricted sparc64 NKMEMPAGES to 2.5GB
in revision 1.49 of src/sys/arch/sparc64/include/param.h:
Note that this
On Fri, Mar 09, 2012 at 04:17:42PM +0100, Manuel Bouyer wrote:
assuming ncr53c9x is MP-safe, it is correct.
Just out of curiosity: assuming it isn't, what would be different?
Martin
1 - 100 of 619 matches
Mail list logo
