On Tue, Aug 13, 2013 at 7:02 PM, Steven Hartland
wrote:
> Could you provide the output from camcontrol identify for these
> disks I want to just double check the formatting before commiting as I
> don't have these disks here in labs.
>
>Regards
>Steve
>
Here's one for X25-M G2 and Intel
On Thu, Jul 11, 2013 at 12:52 PM, Jordan K. Hubbard <
jordan.hubb...@gmail.com> wrote:
>
> On Jul 11, 2013, at 7:27 AM, Julian Elischer wrote:
>
> > I could imagine that we could stash away a vimage stack just for this
> purpose.
> > yould set it up on boot and leave it detached until you need it
On Wed, Jan 23, 2013 at 1:25 PM, Wojciech Puchar
wrote:
>>> gives single drive random I/O performance.
>>
>>
>> For reads - true. For writes it's probably behaves better than RAID5
>
>
> yes, because as with reads it gives single drive performance. small writes
> on RAID5 gives lower than single d
On Wed, Jan 23, 2013 at 1:09 PM, Mark Felder wrote:
> On Wed, 23 Jan 2013 14:26:43 -0600, Chris Rees wrote:
>
>>
>> So we have to take your word for it?
>> Provide a link if you're going to make assertions, or they're no more than
>> your own opinion.
>
>
> I've heard this same thing -- every vde
On Wed, Jan 23, 2013 at 12:22 PM, Wojciech Puchar
wrote:
>>> While RAID-Z is already a king of bad performance,
>>
>>
>> I don't believe RAID-Z is any worse than RAID5. Do you have any actual
>> measurements to back up your claim?
>
>
> it is clearly described even in ZFS papers. Both on reads an
On Mon, Jan 21, 2013 at 1:06 PM, Pawel Jakub Dawidek wrote:
> On Fri, Jan 18, 2013 at 08:26:04AM -0800, m...@freebsd.org wrote:
>> > Should it be set to a larger initial value based on min(physical,KVM)
>> > space
>> > available?
>>
>> It needs to be smaller than the physical space, [...]
>
> O
On Sat, Sep 1, 2012 at 10:03 PM, Artem Belevich wrote:
> On Sat, Sep 1, 2012 at 9:29 PM, Artem Belevich wrote:
>> I've just noticed that freebsd commits on github come with a git note.
>> If you look past the diff of the commit, you will see a note that
>> contain
On Sat, Sep 1, 2012 at 9:29 PM, Artem Belevich wrote:
> I've just noticed that freebsd commits on github come with a git note.
> If you look past the diff of the commit, you will see a note that
> contains path and revision number.
>
> For example:
> https://github.com
On Sat, Sep 1, 2012 at 7:44 PM, asp imho wrote:
> Hi all,
>
> I've a generic question about how the program looks before and after it is
> loaded into the memory.
>
> I see that the TEXT_START_ADDR = 0x08048000 (found this in
> ~src/contrib/binutils/ld/emulparams/elf_i386.sh)
>
> when I do a procs
On Sat, Sep 1, 2012 at 5:50 PM, Bryan Drewery wrote:
>>> More generally tho, I'm curious how one is supposed to use the
>>> seemingly more official repositories without this bit of data; I'd
>>> expect I must be missing some critical clue.
I've just noticed that freebsd commits on github come
Hi,
On Sat, Sep 1, 2012 at 11:24 AM, Daniel Hagerty wrote:
> How does one map between svn commit IDs and git IDs with this
> repository? Most git-svn repositories include a git-svn-id: header at
> the end of commit messages, but this repository doesn't. The
> freebsd-head repository at git:
On Thu, Mar 15, 2012 at 10:49 PM, Maninya M wrote:
> # sysctl debug.kdb.enter=1
>
> --
>
> But when I type that the computer hangs!
Did you by any chance do that from a terminal window in X11
environment? If that's the case, then kernel debugger is running, you
just don't see anything because
On Wed, Mar 14, 2012 at 11:25 AM, Maninya M wrote:
> Then typed this to force a panic:
>
> sysctl debug.kdb.panic=1
>
> The computer just hung after this, and after waiting for a while I pressed
> the reboot button.
> It said "no core dumps found" while rebooting.
First, make sure you have swap s
On Wed, Mar 14, 2012 at 9:31 AM, Maninya M wrote:
> How can I capture the states of all running processes at a particular point
> in time? How can I retrieve this information for later use?
Go into DDB. Do 'panic'. wait for the kernel to finish dumping core.
Once system reboots and saves kernel c
On Tue, Feb 28, 2012 at 1:06 PM, Wojciech Puchar
wrote:
right. but still 32 pages is 128kB, but i see 64kB I/Os in systat/vmstat
>>>
>>> Right, but the comment says to not define MAX_PAGEOUT_CLUSTER to a value
>>> greater
>>> than 32, but you did that. So all bets could be off unless you ex
On Tue, Feb 28, 2012 at 2:21 AM, Andriy Gapon wrote:
> on 28/02/2012 11:43 Wojciech Puchar said the following:
+++ swap_pager.c 2012-02-25 13:19:51.0 +0100
@@ -119,7 +119,7 @@
* The 32-page limit is due to the radix code (kern/subr_blist.c).
*/
#ifndef MAX
On Thu, Jan 26, 2012 at 6:54 AM, John Baldwin wrote:
>> > 3. The code in bcache.c doesn't really implement an LRU - it implements
>> > 'least recently added' algorithm, i.e. a kind of queue. Not that
>> > it matters much, since it flushes the elements two seconds after
>> > caching them any
2012/1/23 Edward Tomasz Napierała :
> Some time ago I've spent some time on trying to speed up loading
> modules by the loader(8). Result can be found at:
>
> http://people.freebsd.org/~trasz/fast-loader-3.diff
>
> This patch solves three issues:
>
> 1. As it is now, the code in biosdisk.c tries v
On Mon, Oct 24, 2011 at 5:21 PM, Chuck Tuffli wrote:
> Is there an easy way to determine the amount of bus_dma memory
> allocated by a driver? Something similar to vmstat -m
>
Would "devinfo -r" do?
--Artem
___
freebsd-hackers@freebsd.org mailing list
2011/10/5 Dag-Erling Smørgrav :
> Michael Bushkov writes:
>> 2. Consequences of the aforementioned problem can probably be
>> corrected by using _setsockopt(..., SO_NOSIGPIPE) in
>> __open_cached_connection() in nscachedcli.c
>
> That sounds like a workaround rather than a fix...
Not necessarily.
2011/10/5 Michael Bushkov :
> There are probably 2 things here:
> 1. There's some error in nsswitch<->nscd communication protocol that
> causes nsswitch to write into the closed socket. This is not trivial
> to investigate and will require analyzing nscd and client process logs
> side by side (and
2011/10/4 Dag-Erling Smørgrav :
> Any chance of getting a backtrace from an unpatched nscd? Ideally with
> the change described here:
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/136073#reply1
>
> To test, stop nscd, then run it from the command line like so:
>
> $ su -
> # cd /tmp
> # ulimi
2011/10/4 Dag-Erling Smørgrav :
> Trond Endrestøl writes:
>> It's in daily use at Gjøvik Technical College (Fagskolen i Gjøvik),
>> here in Norway. Both the mail and web servers authenticates our users
>> by LDAP, and nscd certainly speeds up the lookups.
>
> OK. No trouble with clients dying of
On Tue, Sep 20, 2011 at 6:34 AM, Fabien Thomas wrote:
> git merge-base upstream/svn_trunk upstream/svn_stable_8
> does not work.
Ditto here.
>
> it seems that at some point in time it was working.
> (upstream = live tree, origin = my sandbox)
> I will need to dig a little more to understand the
On Thu, Jul 21, 2011 at 5:37 AM, Subbsd wrote:
> Hi
>
> I try to use dtrace in jail on FreeBSD-9-64.
> Kernel have options:
> ---
> include GENERIC
> ident GENERIC-DTRACE
> options KDTRACE_FRAME # Ensure frames are compiled in
> options KDTRACE_HOOKS # Kernel DTrace h
On Sat, Jul 2, 2011 at 6:57 AM, Martin Möller
wrote:
> Hi Hackers,
>
> why does these function allow seeking beyond the EOF of a file in
> O_RDONLY/²rb² mode ?
Perhaps because the standard explicitly says that it's allowed:
http://pubs.opengroup.org/onlinepubs/009695399/functions/lseek.html
> Ho
Hi,
On Wed, Jun 15, 2011 at 2:55 PM, Dan Nelson wrote:
> In the last episode (Jun 15), Yuri said:
>> When I test performance of the code, I always observe dependency of CPU
>> user time on the presence of other CPU intense processes. Same CPU-only
>> deterministic process that on the quiet machi
On Mon, Jun 6, 2011 at 1:02 PM, Kostik Belousov wrote:
> On Mon, Jun 06, 2011 at 12:47:38PM -0700, Artem Belevich wrote:
>> Jack,
>>
>> Quite a while back you've posted I/OAT driver. Unfortunately the link
>> you posted does not seem to have the drivers any
Jack,
Quite a while back you've posted I/OAT driver. Unfortunately the link
you posted does not seem to have the drivers any more. Do you still
have them available somewhere?
Do you know if Intel has technical info on the DMA engine available? I
believe long time back when it was still I/OAT it w
On Mon, May 2, 2011 at 7:15 AM, Robert Schulze wrote:
> Hi,
>
> Am 02.05.2011 16:06, schrieb Artem Belevich:
>>
>> Second problem -- res on success will always be "" as you've just did
>> *ptr=0.
>
> thats right, the copy should look like:
>
&
On Mon, May 2, 2011 at 6:00 AM, Robert Schulze wrote:
> Hi,
>
> Am 02.05.2011 14:13, schrieb Martin Möller:
>>
>> Criteria:
>> o Receive the value of
>> o Check the Environment: Is really sourrounded by 'GET '
>> and
>> 'HTTP/1.1' ?!
>
> these quite simple criteria might be matched
On Fri, Apr 29, 2011 at 8:37 PM, Doug Barton wrote:
> On 04/29/2011 20:34, Warren Block wrote:
>>
>> On Fri, 29 Apr 2011, Devin Teske wrote:
>>
>>> I'm still leaning toward just making the "V" in "Verbose" and "S" in
>>> "Single
>>> User" bolded.
>>
>> Why not just underline hotkey characters? Tha
On Fri, Apr 22, 2011 at 10:58 AM, Robert Lorentz
wrote:
> Hi,
>
> I'm very interested in getting started with FreeBSD development. My interests
> are wide but specifically core OS, performance, scheduling, cryptography,
> perhaps filesystems etc.
>
> I have seen the "Ideas" list and there is som
On Sat, Apr 9, 2011 at 10:15 AM, Joe Schaefer wrote:
> While I am thrilled about the newfound zfs stability that upgrading to 8
> has brought, one of the things that seems to have been dropped is
> support for process memory limits. I have a few servers that occasionally
> run out of swap due to
On Tue, Apr 5, 2011 at 7:00 PM, Israel Jacques wrote:
> I'll be looking to go through:
> src/sys/vm
> src/lib/libc/gen/setproctitle.c
> src/sys/kern/sysv_shm.c
> ...and the VM portion of the "4.4BSD" book.
> (I just received my FreeBSD book today!)
You may also want to take a look at "Solaris Int
>>> I have one comment though. I am not sure about renaming syscall.ko to
>>> syscall_freebsd.ko.
>> I've renamed it for consistency with other systrace provider variants.
>> I can change it back.
>
> I think that I would prefer this.
> If only for POLA reasons.
Done. New patch is here:
https://s
> I have one comment though. I am not sure about renaming syscall.ko to
> syscall_freebsd.ko.
You mean systrace_freebsd.ko.
I've renamed it for consistency with other systrace provider variants.
I can change it back.
> Perhaps we could keep the old name? Or add a new module
> under that name t
On Tue, Dec 21, 2010 at 1:26 AM, Artem Belevich wrote:
> On Mon, Dec 20, 2010 at 3:15 AM, Andriy Gapon wrote:
>> It would be nice to get the i386 counterpart too when this goes into the
>> tree.
>
> Here's updated version that has syscall:linux32 worki
On Mon, Dec 20, 2010 at 3:15 AM, Andriy Gapon wrote:
> It would be nice to get the i386 counterpart too when this goes into the tree.
Here's updated version that has syscall:linux32 working on i386, too.
https://sites.google.com/site/abc678site/files/dt-systrace-20101221.patch.gz
--Artem
__
I've posted updated version of the patch here:
https://sites.google.com/site/abc678site/files/dt-systrace.patch.gz
This patch uses DTrace module field to specify syscall's compat
variant in the syscall probe name.
The patch also adds syscall probe for linux32 binaries on amd64. I'll
try to add i3
> Maybe a little bit related: do you know about my (unfortunately
> out-of-date) branch to add dtrace providers to the linuxulator?
> http://svn.freebsd.org/viewvc/base/user/netchild/linuxulator-dtrace/
>
> If you are interested feel free to borrow things from there.
I'll take a look.
>> I'm lean
y to proceed.
Thanks,
--Artem
-- Forwarded message --
From: Andriy Gapon
Date: Sat, Dec 11, 2010 at 11:15 AM
Subject: Re: kern/152822: [patch] DTrace: syscall provider for compat/freebsd32
To: Artem Belevich
Cc: John Baldwin
on 11/12/2010 21:07 Artem Belevich said the following:
> I wonder if
Hi,
Could someone review the patch in the PR? It adds DTrace syscall32
provider that allows syscall probing for 32-bit binaries running under
emulation.
http://www.freebsd.org/cgi/query-pr.cgi?pr=152822
Thanks,
--Artem
-- Forwarded message --
From: Artem Belevich
Date: Fri
On Thu, Dec 2, 2010 at 9:46 PM, Artem Belevich wrote:
> On Thu, Dec 2, 2010 at 9:20 PM, Brandon Gooch
> wrote:
>> I've been tinkering with DTrace a bit, and I've notice something
>> peculiar on each system I've tried it on.
>>
>> Sending ^C from
On Thu, Dec 2, 2010 at 9:20 PM, Brandon Gooch
wrote:
> I've been tinkering with DTrace a bit, and I've notice something
> peculiar on each system I've tried it on.
>
> Sending ^C from the keyboard in the terminal (console, XTerm, Konsole)
> produces no output [1].
>
> For example, while trying out
Hi,
On Thu, Dec 2, 2010 at 12:51 PM, Andrew Duane wrote:
>
> I've been poking at some bugs we have around pushing user memory to/past the
> limits of our box, and decided to try seeing what happens on a stock FreeBSD
> system (7.1 in this case).
>
> Basically I have a program that mallocs big m
On Fri, Nov 26, 2010 at 1:48 PM, Andriy Gapon wrote:
> on 26/11/2010 21:10 Artem Belevich said the following:
>> On Fri, Nov 26, 2010 at 5:54 AM, Andriy Gapon wrote:
>>>> I will appreciate reviews and testing.
>>>
>>> Should I wait for any pending comments?
On Fri, Nov 26, 2010 at 5:54 AM, Andriy Gapon wrote:
>> I will appreciate reviews and testing.
>
> Should I wait for any pending comments?
> Otherwise I am confident enough in the patch to commit it.
Some time back I used to have reproducible crash related to dtrace/cyclic:
http://unix.derkeiler.
amp;ch->mtx, "AHCI channel lock", NULL, MTX_DEF);
resource_int_value(device_get_name(dev),
device_get_unit(dev), "pm_level", &ch->pm_level);
I did mention it on freebsd-current@ some time back:
http://lists.freebsd.org/pipermail/freebsd-current/2009-November/013645.h
There's another case of '&' used improperly.
http://svn.freebsd.org/viewvc/base?view=revision&revision=90385
if (hdr.elf.e_ident[EI_OSABI] & ELFOSABI_FREEBSD) {
is_shlib = 1;
} else {
hdr.elf.e_ident[EI_OSABI] is not a bitmask and '==' should've been used instead.
Now ldd.c has
On Sun, Aug 22, 2010 at 1:45 PM, Andriy Gapon wrote:
> Unfortunately I don't have any conclusive results to report.
> The numbers seem to be better with the patch, but they are changing all the
> time
> depending on system usage.
> I couldn't think of any good test that would reflect real-world u
Aug 23, 2010 at 1:44 PM, jhell wrote:
> On 08/23/2010 16:42, jhell wrote:
>> On 08/23/2010 03:28, Artem Belevich wrote:
>>> Can anyone test the patch on a system with mix of UFS/ZFS filesystems
>>> and see if the change mitigates or solves the issue with inactive
>>
ystem.
--Artem
On Sun, Aug 22, 2010 at 11:12 PM, Andriy Gapon wrote:
> on 23/08/2010 02:52 Artem Belevich said the following:
>> Do you by any chance have a graph showing kstat.zfs.misc.arcstats.size
>> behavior in addition to the stuff included on your graphs now?
>
> Yes,
Do you by any chance have a graph showing kstat.zfs.misc.arcstats.size
behavior in addition to the stuff included on your graphs now? All I
can tell from your graphs is that v_free_count+v_cache_count shifted a
bit lower relative to v_free_target+v_cache_min. It would be
interesting to see what ef
Interesting. Looking at dwarf parsing sources in DTrace, and there are
comments that suggest that ctfconvert should've been able to deal with
zero-sized arrays.
Look at die_sou_resolve() in cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c
One observation, if you add a real member to the union that
tion when I run objdump --section-headers. But since this was not there
> in the binary
> but still FBT was able to instrument the *entry* of the function I was
> curious does FBT provider
> need the CTF info for function entry/return ?
>
> --
> Shrikanth R K
>
> On
You may be confusing CTF info and the probes. Those are different things.
CTF info just describes data types and variable/function location.
DTrace later uses it to figure out where and how to install the
probes.
Probes are installed dynamically, at runtime when DTrace program is
run. That's why
Hi,
I've ran into a problem on 8-stable/amd64 today. Basically any attempt
to pass 2GB chunk of data to write(2) returns EINVAL. It looks like
we're limiting amount of data to be written to INT_MAX which looks
rather restrictive on LP64 platforms. NetBSD/OpenBSD do use SSIZE_MAX
which does seem t
It may be worth it to look at Solaris' cyclic facillity for ideas.
sys/cddl/dev/cyclic/cyclic.c
--Artem
On Wed, Mar 31, 2010 at 7:22 AM, Roman Divacky wrote:
> On Wed, Mar 31, 2010 at 04:05:33AM -0800, Tsuyoshi Ozawa wrote:
>> Thank you for replying !
>>
>> The patch for FreeBSD 8.0 original s
> Seriously, simply because of curiosity - are MIPS CPUs used in any
> kind of "general purpose" machines?
I'm not aware of any multi-core general-purpose MIPS box.
Low-end MIPS CPUs are ubiquitous in low-end networking gear.
High-end multicore MIPS chips are mostly going into mid-to-high end
netw
MIPS variants with many cores/threads have been in production for
quite a while, though for some reason that happened without too much
PR noise.
http://www.rmicorp.com/products/XLR_732.htm
http://www.caviumnetworks.com/OCTEON_MIPS64.html
--Artem
On Thu, Feb 11, 2010 at 11:18 AM, Ivan Voras wr
Good to hear that it's usable for you even on a relatively low-memory
system. Now, throw in an SSD for L2ARC, more RAM for ARC (and L2ARC
housekeeping) and then it starts to really shine.
As for better than expected performance, in my not-so scientific
benchmarks (copying 10G-large files on 8-disk
>> Anyone know if it is adjustable on a system with 1024MB of ram ? Is this
>> just being auto calculated by some other value ?
You may want to make sure that vm.kmem_size is set to a value much
larger than vfs.zfs.arc_max. Default value may be too small to allow
such a large ARC.
On a side note,
> Note that some tools that poke around in kernel innards won't work -
> ps and lsof are the most obvious. ktrace works but the resultant
> ktrace.out files need to read with an amd64 kdump.
Some of those issues can be solved by using within 32-bit jail
statically linked 64-bit binaries. It does
On Mon, Jun 22, 2009 at 5:31 PM, wrote:
> ad11: 953869MB at ata5-slave SATA300
..
> ad14: 476940MB at ata7-master SATA300
> ad16: 476940MB at ata8-master SATA300
..
># zpool create storage raidz ad11 ad14 ad16
> I seem to have less storage than I'd expect. Is there something wrong
> with this s
I see this performance difference on my boxes.
First one has Core2Duo(E5-something), 4GB and runs RELENG_7/i386.
lzotest is very fast.
Second box is Core2Quad (Q9450), 8GB RAM and runs -current as of about
a week ago. lzo2 binary built from ports is *slow*. However, 32-bit
binary from the first b
By the way, this part of Alan's patch fixes a bug in RELENG7 where
mapbase is passed to vm_map_find uninitialized. -CURRENT already has
this change applied. Perhaps it's worth committing in RELENG7, too.
--- ./kern/link_elf_obj.c.orig 2008-09-01 11:06:44.0 -0700
+++ ./kern/link_elf_obj.c
> SVN rev 180308 on 2008-07-05 19:34:33Z by alc
>
> Enable the creation of a kmem map larger than 4GB.
> Submitted by: Tz-Huan Huang
>
> Make several variables related to kmem map auto-sizing static.
> Found by: CScout
I did apply Tz-Huan Huang's patch that he pointed to shortly after
you've
Alan,
Thanks a lot for the patch. I've applied it to RELENG_7 and it seems
to work great - "make -j8 buildworld" succeeds, linux emulation seems
to work well enough to run linux-sun-jdk14 binaries, ZFS ARC size is
bigger, too. So far I didn't see any ZFS-related KVM shortages either.
The only pro
69 matches
Mail list logo
