On Sat, Nov 26, 2011 at 11:04:56AM -0700, Sverre Froyen wrote:
[...]
pool_cache operation. Perhaps the default allocator should use address space
below 4 GiB?
Definitively not, or you may run out of memory when you really need an address
below 4 GiB.
--
Manuel Bouyer bou...@antioche.eu.org
, the cisco and NetBSD will show
link up or not, but despinte showing link up it's not working.
tcpdump shows incoming packets through, so it may be a send-only problem.
No errors on the cisco side.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
takes approximately a minute. My
Seconded. On a ftp server with a large filesystem (5TB, 5M inodes), shutdown
takes a very long time too.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
On Wed, Dec 07, 2011 at 10:59:11AM +0100, Joerg Sonnenberger wrote:
On Wed, Dec 07, 2011 at 10:54:40AM +0100, Manuel Bouyer wrote:
On Wed, Dec 07, 2011 at 10:21:14AM +1100, Simon Burge wrote:
David Holland wrote:
There is at least one known structural problem where atime/mtime
these informations (with less granularity I admit) in
netstat -i outtput.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
in future releases of NetBSD.
If we want to add support for this, I'd suggest adding this to the statistics
reported by netstat -i, instead of driver-specific event counters.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
to a CS5536 in
the fuloong, but you can connect a JMH330 to any PATA controller
(and there's no way to detect this at run time).
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
], I'm not sure if that's enough for you.
[1] http://netbsd.gw.com/cgi-bin/man-cgi?workqueue++NetBSD-current
We can't destroy an enqueued work, nor wait for it to complete.
But this can probably be worked around by using a condvar.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans
to be i386-specific; a amd64 domU doens't crash.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
On Fri, Jan 13, 2012 at 09:53:46AM +0100, Manuel Bouyer wrote:
On Fri, Jan 13, 2012 at 06:04:15AM +0100, Emmanuel Dreyfus wrote:
Hi
I just discovered the oddity below, on a netbsd-5 domU. Is there a
reason for not calling that a bug? Does it happens only at mine?
It is a bug; please
: 0x0221
panic: HYPERVISOR_mmu_update failed
No, this is not a bug, especially not, if this is run by root.
It is a bug in the sense that the kernel should not ask the hypervisor
to map nonextistent memory.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront
On Mon, Jan 16, 2012 at 04:37:57PM +, David Holland wrote:
On Sun, Jan 15, 2012 at 08:37:37PM +0100, Manuel Bouyer wrote:
I don't think I'll be able to have this ready for netbsd-6, but I now know
this requires 2 changes that will require a kernel version bump, so theses
changes
On Mon, Jan 16, 2012 at 08:46:44PM +, David Holland wrote:
On Mon, Jan 16, 2012 at 07:37:19PM +0100, Manuel Bouyer wrote:
The fisrt change is to the buffer cache.
My first reaction is that I don't think it's a good idea to make major
changes to the buffer cache at this stage
called it buffer cache target or such.
your vtruncbuf2 function seems to imply needs to have separate
v_dirtyblkhd/v_cleanblkhd for each types.
It's possible, I didn't look at vnode cleaning yet.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la
the cache when a file is deleted or would be more difficult, isn't it ?
it allows us to have more than one such entities for a vnode.
it's what you want here, isn't it?
I'm not sure I'm understanding you. There is only one set of extended
attributes blocks per vnode.
--
Manuel Bouyer bou
On Tue, Jan 17, 2012 at 01:21:33AM +, David Holland wrote:
On Mon, Jan 16, 2012 at 10:28:57PM +0100, Manuel Bouyer wrote:
I consider lfs second-class citizen at this time and if forward
compat if broken for the lfs module on the branch it's probably not
a big deal).
I don't
just work with new generations of hardware.
Is there SAS controllers out there that are not RAID ?
I looked for one when I needed a new tape changer, and didn't find
anything with a SAS interface and no RAID (so I went fiber channel ...)
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans
On Tue, Jan 17, 2012 at 09:25:06PM +, David Holland wrote:
On Tue, Jan 17, 2012 at 07:31:17PM +0100, Manuel Bouyer wrote:
So, because of modules, we can't pullup new features to netbsd-6 ?
How is this different from netbsd-5?
Modules are not used by default on netbsd-5
changes to the buffer
cache now.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
On Wed, Jan 18, 2012 at 02:27:30PM -0500, Thor Lancelot Simon wrote:
On Wed, Jan 18, 2012 at 04:24:27PM +0100, Manuel Bouyer wrote:
On Wed, Jan 18, 2012 at 10:03:02AM +0100, Manuel Bouyer wrote:
It's not breaking it on the branch, it introducing a backward compat
problem with the lfs
, or can't, sleep holding the KERNEL_LOCK().
You can. tsleep() (and other sleeping primitives) will release/reaquire
it as needed.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
-invalidate instead.
Isn't this what bus_space_barrier(BUS_SPACE_BARRIER_SYNC) is for ?
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
On Thu, Jan 19, 2012 at 11:32:46AM -0800, Matt Thomas wrote:
On Jan 19, 2012, at 11:28 AM, Manuel Bouyer wrote:
On Thu, Jan 19, 2012 at 10:59:01AM -0800, Matt Thomas wrote:
For prefetchable regions (like framebuffers) mapped by bus_space_map,
there is a need to able force
the target (main or device memory) can be usefull.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
() that does nothing.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
. But that's a lot of work and is definitively not going to
be in netbsd-6
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
ffsv2 extattr; nothing will
be commited before the branch; releng accepts to have different code
in HEAD and netbsd-6. So I'll come back on the topic after netbsd-6
has been branched.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
to be compatible with FreeBSD ...
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
On Mon, Feb 06, 2012 at 04:47:35PM +, Emmanuel Dreyfus wrote:
On Mon, Feb 06, 2012 at 05:43:10PM +0100, Manuel Bouyer wrote:
note that the ffsv2 extended attribute on-disk format uses an int as
namespaces (just like the API). Nothing unworkable here, but it may
be tricky if we want
On Mon, Feb 06, 2012 at 05:00:05PM +, Emmanuel Dreyfus wrote:
On Mon, Feb 06, 2012 at 05:53:09PM +0100, Manuel Bouyer wrote:
But if you want to have system.foo distinct from security.foo, you have
to duplicate the namespace in the name itself, right ?
Yes, but if we want to tend
- USER foo
anything.foo - USER anything.foo
But then, if you see USER foo.bar in the filesystem, you don't know
if it should be mapped to user.foo.bar or foo.bar.
I don't think this can work.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront
On Mon, Feb 13, 2012 at 10:37:25AM +, Emmanuel Dreyfus wrote:
On Mon, Feb 13, 2012 at 11:27:29AM +0100, Manuel Bouyer wrote:
But then, if you see USER foo.bar in the filesystem, you don't know
if it should be mapped to user.foo.bar or foo.bar.
I don't think this can work.
If the disk
a tail pmap_kremove() call at the end
- __PMAP_NEEDS_UNMAP_BEFORE_FREE is defined for XEN in x86/include/pmap.h
Does anyone see a problem with this ?
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
Index: uvm/uvm_km.c
loopva=0x80001d1df000 loopsize=0x3000 vmem=0x80f01ae8
Ops. I can see why; we have start == end at the end of the loop.
We need to keep the start value. Restructuring the code to batch
calls to pmap_update() will probably fix it too :)
--
Manuel Bouyer bou...@antioche.eu.org
On Sat, Feb 18, 2012 at 10:12:36AM -0800, Chuck Silvers wrote:
On Sat, Feb 18, 2012 at 07:01:24PM +0100, Manuel Bouyer wrote:
- the calls to pmap_update() should be moved along with the calls to
pmap_kremove().
But not all pmap_kremove() are followed by a pmap_update
() calls weere collected.
Ok, so here's an updated patch
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
Index: uvm_km.c
===
RCS file: /cvsroot/src/sys/uvm/uvm_km.c,v
retrieving
/xref/src/sys/uvm/uvm_map.c#2310
P.S. During rmind-uvmplock branch work, I checked all pmap_[k]remove()
cases, that they have pmap_update() and there are no race conditions,
so we should be fine.
So should I move the pmap_update() back ?
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD
On Sat, Feb 18, 2012 at 09:16:45PM +, Mindaugas Rasiukevicius wrote:
Manuel Bouyer bou...@antioche.eu.org wrote:
On Sat, Feb 18, 2012 at 07:49:13PM +, Mindaugas Rasiukevicius wrote:
[...]
I also implemented the idea of removing the mappings and freeing page
in batch of 16
either. And if we go
this way, the existing pmap_update() calls are not in the right place to
make sure there's no write mapping behind when a page is freed ...
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
On Mon, Feb 20, 2012 at 08:52:38PM +, Mindaugas Rasiukevicius wrote:
Manuel Bouyer bou...@antioche.eu.org wrote:
since pmap_kremove() can defer its effects (though I guess it currently
doesn't for xen, since otherwise your latest patch wouldn't work? not
sure, I haven't found
, but I guess hypercalls like MMUEXT_INVLPG_MULTI takes
an array of uint32_t, so we can use more than 32 cpus here as well.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
is something we need. It could even be a gsoc
project ...
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
be fixed in 5.1_STABLE.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
makes the kernel occasionally panic
while running tests. It looks like a race condition causing memory corrution,
but this is hard to track down ...
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
it, then at last you can read some
data out of it. So it's just some parts of the media which are bad.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
to send PR?
Does it always fail in the same way, or does the panic happen at random
places ?
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
On Thu, Mar 08, 2012 at 04:00:05PM +0100, Martin Husemann wrote:
On Thu, Mar 08, 2012 at 03:51:05PM +0100, Manuel Bouyer wrote:
pmap_deactivate() at netbsd:pmap_deactivate+0x93
mi_switch() at netbsd:mi_switch+0x2c5
kpreempt() at netbsd:kpreempt+0xe2
Xpreemptrecurse
On Thu, Mar 08, 2012 at 04:13:41PM +0100, Martin Husemann wrote:
On Thu, Mar 08, 2012 at 04:07:19PM +0100, Manuel Bouyer wrote:
Does this bug also exist in netbsd-6 ?
Yes.
OK, I opened kern/46153 so releng can track it.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans
is MP-safe, it is correct.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
On Fri, Mar 09, 2012 at 04:30:56PM +0100, Martin Husemann wrote:
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?
if ncr53c9x is not MP-safe, it should be running
cold state.
What about hot-plug? (we have esp at pcmcia)
While it's not a big problem to not have KERNEL_LOCK() while cold
(execpt for DIAGNOSTIC), I really hope autoconf runs under KERNEL_LOCK()
for hot-plug devices. Otherwise bad things can happen ...
--
Manuel Bouyer bou
On Sun, Mar 11, 2012 at 12:19:45PM +0300, Aleksey Cheusov wrote:
On Thu, Mar 8, 2012 at 2:31 PM, Manuel Bouyer bou...@antioche.eu.org wrote:
On Thu, Mar 08, 2012 at 02:04:49PM +0300, Aleksey Cheusov wrote:
On my system this crash is reproducible. At least it repeated three
times with xdm
the LW_WEXIT flag.
What the patch does is always reprocess the lwp list if lwp_wait1() returns
and p_nlwps is still 1.
This doesn't cause new test failures (I did 2 runs) and I coudln't
reproduce the problem in kern/46168 with this patch.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26
, but the patch now works as expected.
Any objections?
Not from me :)
module tests are also failing for e.g. sparc.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
hypervisorbus could set the property ...
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
it's time to revisit the
mount(2) interface (proplist anyone ? :)
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
+0x71
sys_read() at netbsd:sys_read+0x62
syscall() at netbsd:syscall+0xc4
cpu1: End traceback...
There may have been an I/O error from the underlying device.
Does it ring a bell to someone ?
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
On Sun, Jun 24, 2012 at 01:07:51PM +0200, Manuel Bouyer wrote:
Hello,
I got this on a netbsd-5 host:
Sorry, typo. This is a netbsd-*6* host
panic: kernel diagnostic assertion uvm_page_locked_p(pg) failed: file
/dsk/l1/misc/bouyer/netbsd-6/src/sys/arch/x86/x86/pmap.c, line 3326
cpu1: Begin
to reset the bus and reinitialize the drive.
Yes, in netbsd-6 and HEAD you can detach/reattach devices using drvctl
(e.g. drvctl -d wd0; drvctl -r -a ata_hl atabus0). This works with
port multipliers too.
It looks like support for this in in netbsd-5 too (maybe not in earlier
netbsd-5)
--
Manuel
On Mon, Jun 25, 2012 at 08:50:23AM -0600, Greg Oster wrote:
On Mon, 25 Jun 2012 11:11:37 +0200
Manuel Bouyer bou...@antioche.eu.org wrote:
Hello,
why does raidframe retry failed I/O 5 times ? the wd(4) driver already
retries 5 times, which means a bad block is retried 25 times.
While
stalls I/O to this drive for 25 seconds,
which stalls anything else which also needs this drive for 25 seconds.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
smart, so I suspect this is
handled by the controllers's firmware and transparent for OS.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
On Tue, Jun 26, 2012 at 08:25:08AM -0400, Thor Lancelot Simon wrote:
On Tue, Jun 26, 2012 at 11:36:21AM +0200, Manuel Bouyer wrote:
All SAS controllers I'm aware of are very smart, so I suspect this is
handled by the controllers's firmware and transparent for OS.
On some systems you can
On Sat, Jun 30, 2012 at 02:00:51PM +0100, Mindaugas Rasiukevicius wrote:
Manuel Bouyer bou...@antioche.eu.org wrote:
panic: kernel diagnostic assertion uvm_page_locked_p(pg) failed: file
/dsk/l1/misc/bouyer/netbsd-6/src/sys/arch/x86/x86/pmap.c, line 3326
cpu1: Begin traceback... kern_assert
it was when I did the initial
work). limits have no persistent storage, they have to be recreated
after each new MFS mount (but is shouldn't be a big deal - or is was not
a big deal when quotactl(8) could be used for this, I've not looked at
how to do it with the new tools).
--
Manuel Bouyer bou
,c118e540,c118e000,d77f3d28,c02474cf,0,0,6) at
netbsd:xpq_flush_cache+0x66
xc_thread(c118e000,75,c0650200,0,c0100079,0,0,0,0,0) at
netbsd:xc_thread+0x7
With a xen-debug.gz hypervisor, do you have anything relevant in
xm dmesg ?
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans
On Fri, Aug 03, 2012 at 01:42:55AM +, Emmanuel Dreyfus wrote:
On Thu, Aug 02, 2012 at 10:26:44PM +0200, Manuel Bouyer wrote:
OK, so domUs are not allowed to flush the cache. Now we need to find what
causes this cross-call.
Watching what calls xc_lowpri() could help, but I'm not sure
to a target while with AHCI we have to
build one H2D FIS to set the reset bit and another one to reset it).
So, basically all the work has to be done in mvsata(4) :)
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
option maybe) ?
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
in cache are written (i.e. a WRITE FUA may pass previous writes).
It looks like there's not ordered tag in ATA.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
like flush is a big hammer and we really want to ask that
all writes before a barrier be done instead. But I'm unclear on the
details.
this needs to be investigated.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
On Fri, Aug 24, 2012 at 06:10:21PM +, Michael van Elst wrote:
bou...@antioche.eu.org (Manuel Bouyer) writes:
How do you think this should be handled ? have a sysctl to control
mfi's behavior per-controller (eventually with default depending on BBU
status), or have
controllers switch the cache to write-through mode themselves
if they detect the battery has failed.
For LSI this is configurable (write through, always write back and
write back with BBU)
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
On Fri, Aug 24, 2012 at 11:24:33PM +0200, Michael van Elst wrote:
On Fri, Aug 24, 2012 at 08:52:06PM +0200, Manuel Bouyer wrote:
The standard drivers always turn off write caching when the BBU
is not working.
No, this is something the user can control directly in firmware,
at last
a
SCSI deffered error sense, but I'm not sure).
Note that you don't have a way to know when data have been moved from the
write-back cache to disks.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
, and the status gets updated later by
calls to mfi_sensor_refresh() from sysmon_envsys.
Why are changes to ENVSYS_INDICATOR nor reported, and would it make
sense to have changes to ENVSYS_INDICATOR be reported too ?
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront
On Sun, Aug 26, 2012 at 11:47:46AM -0700, Paul Goyette wrote:
On Sun, 26 Aug 2012, Manuel Bouyer wrote:
Hello,
while hacking on mfi(4), I found that, while sysmon_envsys(9) reports
state change for ENVSYS_DRIVE sensors, such as:
mfi0: normal state on 'mfi0:0' (online)
mfi0: normal state
enough.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
that can be done about it easily ?
And, BTW, do we support FreeBSD threaded binaries ?
sysctl kern.smp.cpus may also be needed ...
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
On Wed, Sep 12, 2012 at 10:51:55PM +0200, Joerg Sonnenberger wrote:
On Wed, Sep 12, 2012 at 10:28:23PM +0200, Manuel Bouyer wrote:
Hello,
I'm trying to run a FreeBSD binary under emulation, but it dies in this
piece of code:
if (sysctl(mib, 2, _usrstack, len, NULL, 0) == -1
and
there are probably more lurking.
Is that with or without wapbl enabled?
FWIW, I've just seen this on a native i386 system while running a
pkg_delete. No WAPBL on this system.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
On Fri, Sep 14, 2012 at 03:19:19AM -0700, Brian Buhrow wrote:
} FWIW, I've just seen this on a native i386 system while running a
} pkg_delete. No WAPBL on this system.
hello. What version of NetBSD?
6.0_RC1
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience
ioctls in
linux_ioctl.c. Does anyone see a better way of handling this ?
More generaly, does anyone have any comments about this code ?
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
On Sun, Sep 16, 2012 at 03:23:22PM +0200, Manuel Bouyer wrote:
Hello,
the attached patch adds a pass-through ioctl interface, with the
As several of you noctied I forgot (once again) to attach the patch.
Here it is.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience
On Sun, Sep 16, 2012 at 10:43:40AM -0400, Thor Lancelot Simon wrote:
On Sun, Sep 16, 2012 at 03:23:22PM +0200, Manuel Bouyer wrote:
Hello,
the attached patch adds a pass-through ioctl interface, with the
necessery linux compat code, for mfi(4). This allows to run the
linux binary
, instead of reverse-engineering.
But we have to live with it, unfortunably.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
On Sun, Sep 16, 2012 at 05:15:44PM +, Christos Zoulas wrote:
In article 20120916152553.ga1...@antioche.eu.org,
Manuel Bouyer bou...@antioche.eu.org wrote:
-=-=-=-=-=-
On Sun, Sep 16, 2012 at 03:23:22PM +0200, Manuel Bouyer wrote:
Hello,
the attached patch adds a pass-through ioctl
(dev)-d_ioctl == mfiioctl
(or whatever its ioctl function is named).
But this assumes that the mfi driver is compiled in. it doesn't
look right, especially in the context of modules.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
On Mon, Sep 17, 2012 at 11:02:13PM +0700, Robert Elz wrote:
Date:Mon, 17 Sep 2012 17:47:08 +0200
From:Manuel Bouyer bou...@antioche.eu.org
Message-ID: 20120917154708.ga25...@asim.lip6.fr
| But this assumes that the mfi driver is compiled in. it doesn't
On Mon, Sep 17, 2012 at 02:31:35PM -0400, Christos Zoulas wrote:
On Sep 17, 6:08pm, bou...@antioche.eu.org (Manuel Bouyer) wrote:
-- Subject: Re: pass-through linux ioctl for mfi(4)
| Sorry but I can't see how a kernel with COMPAT_LINUX but without
| mfi would compile.
You you get
On Mon, Sep 17, 2012 at 02:30:03PM -0400, Christos Zoulas wrote:
On Sep 17, 5:47pm, bou...@antioche.eu.org (Manuel Bouyer) wrote:
-- Subject: Re: pass-through linux ioctl for mfi(4)
| But this assumes that the mfi driver is compiled in. it doesn't
| look right, especially in the context
On Mon, Sep 17, 2012 at 03:02:56PM -0400, Christos Zoulas wrote:
On Sep 17, 8:42pm, bou...@antioche.eu.org (Manuel Bouyer) wrote:
-- Subject: Re: pass-through linux ioctl for mfi(4)
| On Mon, Sep 17, 2012 at 02:31:35PM -0400, Christos Zoulas wrote:
| On Sep 17, 6:08pm, bou
Hello,
so it seems we can't do much better in compat_linux.
Here's an updated patch, which checks the size before malloc in mfifioctl(),
and I also removed a debug printf in compat_linux.
I intend to commit this next weekend.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans
On Wed, Sep 19, 2012 at 11:51:24AM +0200, Roger Pau Monne wrote:
Manuel Bouyer wrote:
On Fri, Sep 14, 2012 at 03:19:19AM -0700, Brian Buhrow wrote:
} FWIW, I've just seen this on a native i386 system while running a
} pkg_delete. No WAPBL on this system.
hello. What version
On Wed, Sep 19, 2012 at 08:28:35PM +0200, Alan Barrett wrote:
On Wed, 19 Sep 2012, Manuel Bouyer wrote:
Here's an updated patch, which checks the size before malloc in mfifioctl(),
and I also removed a debug printf in compat_linux.
I intend to commit this next weekend.
Are these pass
appropriate place would be better ?
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
On Wed, Oct 10, 2012 at 08:22:05AM -0400, Thor Lancelot Simon wrote:
On Wed, Oct 10, 2012 at 12:02:21PM +0200, Manuel Bouyer wrote:
There's another case, which I think is worse: a raidframe volume, with
underlying disks with different maxphys. If it's a raid-1 you can't predict
from
+0x22d
syscall() at netbsd:syscall+0xc4
cpu20: End traceback...
Does it ring a bell to someone ?
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
On Wed, Oct 24, 2012 at 04:07:34PM +0200, Manuel Bouyer wrote:
Hello,
I just got this panic on a NFS server:
uvm_fault(0xfe9069ecf468, 0x0, 1) - e
fatal page fault in supervisor mode
trap type 6 code 0 rip 804bd391 cs 8 rflags 10246 cr2 c8 cpl 0 rsp
fe817503b660
panic
not sure the problem showed
up again, the server has run for weeks before hitting it).
Is the vwait() mandatory here ? To me it looks like the way things gets
locked, the same vnode won't be returned again anyway ...
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront
201 - 300 of 651 matches
Mail list logo
