I'm not sure if I remember it correctly but we do not use zfs_replay.c
it used with zfs snapshots and last time I did work on it it wasn't
working.
On Thu, Jan 16, 2014 at 3:13 PM, J. Hannken-Illjes
wrote:
> On Jan 16, 2014, at 2:45 PM, Taylor R Campbell
> wrote:
>
>> Date: Thu, 16 Jan 2014 0
Can you use addr2line with that wapbl address to find out whal line is it.
On Nov 23, 2012 5:06 PM, "Edgar Fuß" wrote:
> > Try running `svn ...' as `lockstat -T rwlock svn ...'. By chance we get
> more
> > information on lock congestion.
> Ouch! I overlooked this post of yours until a colleague
On Sun, Oct 14, 2012 at 9:36 PM, Taylor R Campbell
wrote:
> The attached patches fixes a lot of issues in our zfs port mainly
> having to do with locking and our (insane) vop protocols. With it,
> many of the zfs tests pass much more reliably, although there remain a
> number that still fail, mai
Hi,
On Fri, May 4, 2012 at 5:15 PM, girish gulawani
wrote:
>
> apologies for cross-post. this is in follow-up to the earlier mail sent as
> below.
>
>> dear board members.
>> to briefly introduce: i've been an active BSD user from more than 12 yrs
>> now and did contribute a bit myself to the Net
Hi,
On Wed, Jan 11, 2012 at 11:24 AM, Emmanuel Dreyfus wrote:
> Hello
>
> Another caveat with DADHI porting: that require something like
> Linux Workqueues feature:
> http://www.kernel.org/doc/htmldocs/device-drivers/ch01s06.html
> (It only uses schedule_work, cancel_work_sync and flush_work).
>
Hi,
On Mon, Dec 19, 2011 at 1:23 AM, Martin Husemann wrote:
> 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
Hi,
On Sun, Aug 7, 2011 at 4:56 PM, Cherry G. Mathew wrote:
> Hi,
>
> I'd like to start merging in bits of the cherry-xenmp branch into
> -current over the coming week. The changes should be transparent, and
> shouldn't change any behaviour of -current. These include a few cleanups
> of MD code a
On Wed, Apr 6, 2011 at 1:44 PM, Vladimir Kirillov wrote:
> Hello, tech-kern@!
>
> Here's the diff for ddb(4):
> - reuse the common code for stack traces
> (and rely on sizeof(long) in most cases)
> - use db_read_* api to be usable from crash(8).
>
> I need this for cra
On Tue, Mar 1, 2011 at 11:55 AM, Andrew Doran wrote:
> On Mon, Feb 28, 2011 at 11:25:07AM -0500, Thor Lancelot Simon wrote:
>
>> On Mon, Feb 28, 2011 at 11:13:36AM +0200, haad wrote:
>> >
>> > With solaris.kmod we are compatible with solaris kernel, (we should
>&
Hi,
On Fri, Feb 25, 2011 at 11:35 PM, Joerg Sonnenberger
wrote:
>
> Hi all,
> there is a lot of code in sys/compat and changes in the kernel API tend
> to require changes in this code too. I would like to know which
> emulations are actually in use, what the status of emulation is (both in
> term
On Tue, Jan 18, 2011 at 5:02 PM, Johnny Billquist wrote:
> On 01/18/11 16:58, haad wrote:
>>>
>>> Just a curious question here. What problem are we trying to solve?
>>> What is the benefit for the rest of the world to not have the
>>> information?
>>&
> Just a curious question here. What problem are we trying to solve?
> What is the benefit for the rest of the world to not have the information?
> Just being curious...
We would like to have reproducable builds which means that if you will run
build on top of same src/ you resulting /obj dirs sh
On Tue, Jan 18, 2011 at 3:40 PM, der Mouse wrote:
>>> Except that tells me whether the kernel being booted is recent, not
>>> whether the bootloader doing the booting is.
>> No. It is the version in src/sys/sys/param.h. It doesn't have any
>> relation to the kernel you are running or booting.
>
>
On Tue, Jan 18, 2011 at 3:27 PM, der Mouse wrote:
pci_device_is_boot_vga()
>>> [...]
>> While X is probing the pci devices the driver enables all pci vga
>> devices. That is why checking for the 'firmware enabled' one fails.
>
> But checking for "the" firmware-enabled one is a broken idea.
On Tue, Aug 3, 2010 at 3:03 PM, Paul Goyette wrote:
> On Mon, 2 Aug 2010, Paul Goyette wrote:
>
>> On Tue, 3 Aug 2010, matthew green wrote:
>>
>>> i think this looks good enough. wait for some others eyes, though.
>>
>> No hurry. I'm going to try to add a new atf test case for the recursive
>> l
On Fri, Mar 26, 2010 at 12:04 AM, Paul Goyette wrote:
> On Thu, 25 Mar 2010, Matthias Drochner wrote:
>
>>
>> jeanyves.mig...@free.fr said:
>>>
>>> There should be some way to serialize/deserialize prop/plistref
>>> objects within the kernel, but I never found a solution. I suppose
>>> you will h
On Thu, Mar 25, 2010 at 11:54 PM, Matthias Drochner
wrote:
>
> jeanyves.mig...@free.fr said:
>> There should be some way to serialize/deserialize prop/plistref
>> objects within the kernel, but I never found a solution. I suppose
>> you will have to dig deeper than I did :/
>
> I think it should
Hi uebs,
>
> Fair enough.
>
> After some thinking, providing "traditional" view and persistent bits
> turns out to be not that difficult.
>
> /dev has a few reserved directory (like /dev/id). You have no freedom
> there. Any access other than that goes to devfsd. It has knowledge
> equivalt to
Hi folks,
I talked with andrew about this issue today and here is relevant part
of our discussion
ad@
KM_NOSLEEP... probably due to that implying UVM_MAP_TRYLOCK
The issue is that parts of kernel_map are pageable. Paging can take a
long time, and the map can be held locked while paging.
Therefor
19 matches
Mail list logo
