On 2 Oct 2018, at 18:15, Alan Somers wrote:
>> 3. Remove a check of trail enablement/suspension from audit_new() --
>> at the point where this function has been entered, we believe that
>> system-call auditing is already in force, or we wouldn't get here,
>> so simply proceed to
On 3 Apr 2015, at 11:41, Hans Petter Selasky wrote:
> On 04/03/15 11:31, Robert N. M. Watson wrote:
>> TCP/IP covert and side channels
>
> Hi,
>
> Can you provide a reference to a document in the area of "TCP/IP covert and
> side channels" which is consi
On 3 Apr 2015, at 10:24, Hans Petter Selasky wrote:
>> Before engaging further in this conversation, and trying to modify the
>> behaviour of the TCP/IP stack, you need to educate yourself about the design
>> and history of the protocols involved. Otherwise, you're going to repeatedly
>> sugge
On 3 Apr 2015, at 09:40, Hans Petter Selasky wrote:
>> There are countless covert channels in TCP/IP; breaking the IP
>> implementation to close a covert channel is probably not a worthwhile
>> investment.
>
> The IP ID channel is a _broadcast_ channel to all devices connected to the
> same n
On 3 Apr 2015, at 02:38, Hans Petter Selasky wrote:
> I would like have a comment on one final issue about the IP ID field.
>
> Given two [small] prime numbers: P and Q
>
> Assume you have a firewall that separate two networks, called A and B, that
> are not allowed to communicate.
>
> In net
On 2 Apr 2015, at 21:54, Hans Petter Selasky wrote:
>>> Please go read about how IP fragmentation works. Having an identical IP
>>> ID in ip_fragment() is the point of the function!
>>
>> rwatson: You're right, the more fragment flag gets set there, I
>> overlooked that bit. Sorry.
>>
>> glebi
On 2 Apr 2015, at 19:24, Hans Petter Selasky wrote:
> In my sketchup I assume that packets for the same destination will not be
> re-ordered. I see that the current ip_reass() code does not care about TCP or
> UDP port numbers at all. Maybe we should add code to check that the packet
> belongs
> On 15 Jan 2015, at 12:35, Joerg Sonnenberger wrote:
>
> On Wed, Jan 14, 2015 at 11:44:00PM +, Robert Watson wrote:
>> - As we anticipate embedding mbufs headers within variable-size regions of
>>memory in the future, change the definitions of byte arrays embedded in
>>mbufs to be
On 7 Jan 2015, at 20:48, Gleb Smirnoff wrote:
> R> > Shouldn't this come w/ a FreeBSD version bump for drivers to use?
> R>
> R> Yes, probably. Old drivers will continue to work fine in not checking the
> R> return value (for now), but drivers seeing backporting will probably want
> a
> R> _
On 7 Sep 2014, at 11:23, Gleb Smirnoff wrote:
> R> Modified: head/sys/sys/mbuf.h
> R>
> ==
> R> --- head/sys/sys/mbuf.hFri Sep 5 16:40:47 2014(r271173)
> R> +++ head/sys/sys/mbuf.hFri Sep 5 16:46:28 20
On 17 Mar 2014, at 01:48, Eitan Adler wrote:
>> Fix a comment in capability.h: it got renamed to capsicum.h, not
>> capability.h.
>
> Perhaps it makes to sense to add a #warning statement to the file as well?
>
> Additionally, is it intended that this file live forever or will be
> removed a
On 17 Mar 2014, at 07:54, David Malone wrote:
>> (1) Merge a software implementation of the Toeplitz hash specified in
>> RSS implemented by David Malone. This is used to allow suitable
>> pcbgroup placement of connections before the first packet is
>> received from the NIC. So
On 15 Mar 2014, at 17:29, Adrian Chadd wrote:
>> I'd characterise this work as "early" in that it would benefit from
>> performance optimisation, device-driver work, and feature enhancement (e.g.,
>> not just stuff like load rebalancing, but also statistics to detect RSS
>> configuration problem
On 5 Feb 2014, at 19:05, John Baldwin wrote:
> A short term solution that would permit non-security jails without having to
> do the longer term work that Robert would like might be to add a new per-jail
> flag that in effect means "no security at all". You would then modify one
> place (pri
On 4 Feb 2014, at 13:23, Julian Elischer wrote:
> On 2/4/14, 3:40 PM, Robert N. M. Watson wrote:
>> On 3 Feb 2014, at 23:53, Doug Ambrisko wrote:
>>
>>> It's unfortunate that vimage requires jail. I want to use vimage but
>>> not have the security
On 4 Feb 2014, at 10:05, Ivan Voras wrote:
> On 31 January 2014 18:28, James Gritton wrote:
>> On 1/31/2014 5:34 AM, Robert Watson wrote:
>
>>> Frankly, I'd like to see this backed out and not reintroduced. If it must
>>> be retained, then it needs a much more clear warning that enabling this
On 4 Feb 2014, at 07:53, Adrian Chadd wrote:
> I really would rather see Xorg gain whatever abstraction is necessary
> to probe/attach/interface with a DRI API supported graphics card.
>
> So, this then becomes a question of whether this is needed for DRI API
> supported graphics cards, or whet
On 3 Feb 2014, at 23:53, Doug Ambrisko wrote:
> It's unfortunate that vimage requires jail. I want to use vimage but
> not have the security restrictions of a jail. To do this I patched
> jail to basically let everything through. It would be nice to be
> able to run jail in an insecure mode w
On 20 Nov 2013, at 20:11, Julian Elischer wrote:
>> Currently, it is quite easy to make mistakes regarding individual mbuf
>> chains vs. lists of mbuf chains. This leads me to wonder whether a new
>> type, perhaps simply constructed on the stack before passing in, should be
>> used for KPIs
On 14 Nov 2013, at 11:06, Edward Tomasz Napierała wrote:
> Wiadomość napisana przez Robert Watson w dniu 14 lis 2013, o godz. 09:07:
>> On Tue, 12 Nov 2013, Edward Tomasz Napierala wrote:
>>
>>> Mention acl_get_brand_np(3).
>>>
>>> MFC after: 2 weeks
>>> Sponsored by: The FreeBSD Founda
On 2 Jan 2013, at 21:02, Andrew Turner wrote:
>> This seemed to do the trick; what do you think of the attached? This
>> isn't a board-specific change, so I dropped it into the common
>> fdt_mips.c code. On the other hand, this left it a bit open as to
>> what the right compatible= line to use wa
On 1 Jan 2013, at 22:08, Andrew Turner wrote:
>> On a semi-related note: the current obstacle to moving more devices
>> over to using FDT on BERI is that our FDT implementation appears to
>> require a PIC to be configured. We're not actually using a PIC on
>> BERI currently. It works fine attache
On 1 Jan 2013, at 19:17, Andrew Turner wrote:
> This looks like it is too late in the boot process. If you are using
> FDT you will need to use the FDT uart which is initialised in cninit.
On a semi-related note: the current obstacle to moving more devices over to
using FDT on BERI is that our
On 1 Jan 2013, at 19:17, Andrew Turner wrote:
>> @@ -76,6 +85,17 @@ mips_init(void)
>> {
>> int i;
>>
>> +#ifdef FDT
>> +#ifndef FDT_DTB_STATIC
>> +#error "mips_init with FDT requires FDT_DTB_STATIC"
>> +#endif
>> +
>> +if (OF_install(OFW_FDT, 0) == FALSE)
>> +while (1)
Hi Garrett:
Thanks for the report -- I didn't realise tinderbox was now building all
kernels, or I would have merged my fix from P4 more quickly.
The patch you've attached isn't quite the right one -- BERI supports both FDT
and non-FDT kernels, so we shouldn't build the Openfirmware headers in
On 29 Dec 2012, at 14:50, Adrian Chadd wrote:
>> The standing consensus is that we try not to break certain classes of device
>> drivers, not that we don't ever change any kernel interfaces. The reason is
>> that we don't have a formal definition of "public" and do not wish to use
>> the defin
On 29 Dec 2012, at 04:43, Alfred Perlstein wrote:
> Yes. Kib and I chatted offline, it seems that the SOP is really "there is no
> guarantee about KPI when talking about VFS" so the headache that it would be
> to write the shim layer and maintain it (particularly considering the 9.x
> release
On 29 Dec 2012, at 06:40, Adrian Chadd wrote:
> There's likely a bunch of companies/users that would love things to
> not change during a stable branch and there's likely a bunch of
> companies/users that would hate things being immutable during a stable
> branch.
>
> There's never been a formal
On 19 Dec 2012, at 10:57, Andrey Zonov wrote:
>>> I think you should not MFC this one quickly -- let's wait for it to
>>> shake out in the -CURRENT userbase for a few months to see what
>>> breaks. I wouldn't be surprised if a fair number of applications
>>> (both publicly available, and local a
On 29 Nov 2012, at 07:02, Simon J. Gerraty wrote:
> On Wed, 28 Nov 2012 20:17:33 -0800, Alfred Perlstein writes:
>> I've seen what happens with large groups, it doesn't scale and basically
>> you wind up with the following type of reviewers:
>
> The issues you cite, are the result of taking a g
On 29 Nov 2012, at 04:17, Alfred Perlstein wrote:
> I've seen what happens with large groups, it doesn't scale and basically you
> wind up with the following type of reviewers:
I think we have to assume best intent here -- the goal of code review in
complex critical components is not to elimin
g the bugs later, in the field, where it is hardest to do so.
Robert
>
> Sent from my iPhone
>
> On Nov 28, 2012, at 10:25 AM, "Robert N. M. Watson"
> wrote:
>
>>
>> On 28 Nov 2012, at 17:51, Gleb Smirnoff wrote:
>>
>>> On Wed, Nov
On 28 Nov 2012, at 17:51, Gleb Smirnoff wrote:
> On Wed, Nov 28, 2012 at 09:39:15AM -0800, Alfred Perlstein wrote:
> A> Personally I don't think we need any more anchors attached to people's
> A> feet when developing FreeBSD.
> A>
> A> Mistakes will happen, they will happen in head. Slowing do
On 27 Nov 2012, at 23:29, Andre Oppermann wrote:
>> Andre.. this breaks incoming connections. TCP is immediately reset and
>> never even gets to the
>> listener process. You need to back out of fix this urgently please.
>
> I just found out and fixed it. Sorry for the bre
On 27 Nov 2012, at 22:54, Andre Oppermann wrote:
Andre.. this breaks incoming connections. TCP is immediately reset and
never even gets to the
listener process. You need to back out of fix this urgently please.
>>>
>>> I just found out and fixed it. Sorry for the breakage.
>>
On 28 May 2012, at 09:36, Konstantin Belousov wrote:
> On Sun, May 27, 2012 at 07:49:36AM +1000, Bruce Evans wrote:
>> On Sat, 26 May 2012, Konstantin Belousov wrote:
>>
>>> On Sat, May 26, 2012 at 10:21:25PM +1000, Bruce Evans wrote:
>>> The 'low level' AKA magic happens in several *_fetch_sysc
On 29 Feb 2012, at 07:50, Mikolaj Golub wrote:
> JE> well that's exactly what I AM questioning.. how often will this be used?
> JE> one person using this once in all of history isn't a real requirement
> JE> for inclusion.
>
> This information may be very useful when troubleshooting unexpected
On 21 Jan 2012, at 13:33, Hans Petter Selasky wrote:
Just to clarify, are you saying that:
(1) We should not ever do an errata note + binary update for the most
important of these bug fixes, just wait for them to ship in FreeBSD
8.3/9.1?
(2) We should do errat
On 21 Jan 2012, at 11:30, Hans Petter Selasky wrote:
> Author: hselasky
> Date: Wed Jan 18 07:57:17 2012
> New Revision: 230302
> URL: http://svn.freebsd.org/changeset/base/230302
>
> Log:
> MFC r230032, r230050, r230090, r230091 and r228493.
> - Various XHCI and
On 20 Jan 2012, at 21:29, Hans Petter Selasky wrote:
> On Friday 20 January 2012 16:16:00 Robert Watson wrote:
>> On Wed, 18 Jan 2012, Hans Petter Selasky wrote:
>>> Author: hselasky
>>> Date: Wed Jan 18 07:57:17 2012
>>> New Revision: 230302
>>> URL: http://svn.freebsd.org/changeset/base/230302
On 26 Nov 2011, at 17:48, Kostik Belousov wrote:
>> in138:~% procstat -x 2008
>> PID COMM AUXV VALUE
>> 2008 nginxAT_PHDR 0x400040
>> 2008 nginxAT_PHENT 56
>> 2008 nginxAT_PHNUM 8
>> 2008 nginx
On 6 Nov 2011, at 05:51, Mikolaj Golub wrote:
> On Sun, 6 Nov 2011 10:47:20 + (UTC) Mikolaj Golub wrote:
>
> MG> Author: trociny
> MG> Date: Sun Nov 6 10:47:20 2011
> MG> New Revision: 227207
> MG> URL: http://svn.freebsd.org/changeset/base/227207
>
> MG> Log:
> MG> Cache SO_REUSEPORT so
On 10 Sep 2011, at 12:35, Robert N. M. Watson wrote:
>> I understand your point. The change is not breaking any KPIs towards
>> userspace. The structure in question is only used within the kernel and
>> kernel
>> modules.
>
> Right -- exactly my point. If
On 10 Sep 2011, at 12:10, Hans Petter Selasky wrote:
>> For most other classes of hardware device driver framework KPIs --
>> especially things like PCI bus attachment, busdma, CAM, ifnet, and GEOM
>> frameworks, our MFC rules would strictly disallow this sort of change, on
>> the grounds that it
On 27 Aug 2011, at 09:21, Navdeep Parhar wrote:
> Shouldn't opt_comconsole.h be included in subr_kdb.c for this part to
> actually work?
Should now be fixed; do let me know if not!
Robert
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.o
On 27 Aug 2011, at 09:21, Navdeep Parhar wrote:
>> (3) options BREAK_TO_DEBUGGER and options ALT_BREAK_TO_DEBUGGER continue
>> to behave as before -- only now instead of compiling in
>> break-to-debugger support, they change the default values of the
>> above sysctls to enable tho
On 4 Jun 2011, at 15:30, Kristof Provost wrote:
> div_bind probably also needs to surround the call to in_pcbbind with
> INP_HASHW(UN)LOCK(...)
>
> I'm currently running 222680. I've only now seen the issue, but I've also
> just now activated INVARIANTS.
Hi Kristof:
Thanks for the detailed rep
On 24 Apr 2011, at 12:49, Alexander Motin wrote:
>>> Reverting is not an option. _Constructive_ propositions are welcome.
>>
>> It is the policy of this project that the release engineering team has
>> final authority over what ships in a release. It is entirely within
>> scope to revert this ch
On 24 Apr 2011, at 17:32, Alexey Dokuchaev wrote:
> On Sun, Apr 24, 2011 at 06:28:48PM +0300, Alexander Motin wrote:
>> What's about creating some kind of symlinks, it could be nice if it
>> worked, but I don't see the way to do it on disk(9) or GEOM layers
>> without breaking device's access cou
On 3 Mar 2011, at 13:14, Alexander Leidinger wrote:
> Quoting Robert Watson (from Thu, 3 Mar 2011 11:14:59
> + (GMT)):
>
>> On Tue, 1 Mar 2011, Dmitry Chagin wrote:
>>
>>> Teach kdump to decode linux syscalls names too.
>>>
>>> Fix bug introduced in my previous commit: the kernel always
On 1 Mar 2011, at 14:53, Alexander Leidinger wrote:
> Quoting Robert Watson (from Tue, 1 Mar 2011 13:23:37
> + (UTC)):
>
>> Author: rwatson
>> Date: Tue Mar 1 13:23:37 2011
>> New Revision: 219129
>> URL: http://svn.freebsd.org/changeset/base/219129
>>
>> Log:
>> Add initial support for
On 1 Mar 2011, at 16:55, Ryan Stone wrote:
> I'm a bit confused. The 8.2 release notes claim that userland dtrace
> support was added to 8.2. Is this incorrect?
>
> http://www.freebsd.org/releases/8.2R/relnotes.html
>
> Userland support for the dtrace(1) subsystem has been added. This
> allow
On 1 Mar 2011, at 15:21, John Baldwin wrote:
> Looks like head/sys/sys/capability.h wasn't added by accident?
Indeed -- a classic case of things building fine but a missing svn add --
thanks!
Robert___
svn-src-all@freebsd.org mailing list
http://list
On 4 Feb 2011, at 13:30, Michael Tuexen wrote:
>> Hmm. It might be better to add a new NETISR_SCTP and use netisr's support
>> for multithreading?
> That sounds really good.
>
> Is it possible that different network cards put packets in the same queue?
> That would be helpful in the case of SC
On 4 Feb 2011, at 10:56, John Baldwin wrote:
> The difference here is that FOREACH_THREAD_IN_PROC() is just a
> TAILQ_FOREACH(). The CPU iterators are more complex.
>
> I agree that that we should have topology-aware iterators, though part of the
> problem is what do you iterate? We'd have to
On 26 Jan 2011, at 23:41, m...@freebsd.org wrote:
> Upon further consideration, I don't think sbuf_new_for_sysctl() should
> be doing the wire. Whether the buffer needs to be wired or not is up
> to the implementation of the individual sysctl; *most* of them will be
> holding a lock when doing s
On 26 Jan 2011, at 21:14, m...@freebsd.org wrote:
>> The kinds of cases I worry about are things like the tcp connection
>> monitoring sysctls. Most systems have a dozen, hundred, or a thousand
>> connections. Some have half a million or a million. If we switched to
>> requiring wiring every p
On 26 Jan 2011, at 18:29, m...@freebsd.org wrote:
>> I suppose an important question is now often we see this actually failing
>
> I don't believe we've ever seen a memory failure relating to sysctls
> at Isilon and we've been using the equivalent of this code for a few
> years. Our machines ar
On 26 Jan 2011, at 17:12, m...@freebsd.org wrote:
>> Hmm. Is this description missing mention of how wiring failures are
>> handled? (Also, it should probably mention that this call can sleep for
>> potentially quite long periods of time, even if sbuf_printf (and friends)
>> can't).
>
> I'm not
On 13 Dec 2010, at 18:28, Ion-Mihai Tetcu wrote:
> I see. Thanks for the time you took to explain things, I'm very new to
> XEN.
> Do we have any docs somewhere (well, except the sources) about our XEN
> support and various options / optimizations? I only know about
> AdrianChadd's wiki pags and
On 13 Dec 2010, at 14:00, Ion-Mihai Tetcu wrote:
>> Derive the XENHVM kernel from GENERIC, adding only the options
>> required to support PV drivers (such as xenpci), and non-adptive
>> locking (along with a comment about why).
>
> What about the same for i386?
We don't currently support comb
On 27 Oct 2010, at 13:56, David Xu wrote:
>> Yay, it's fd_set all over again :-).
>>
>> It sounds like we might just need to add a sysctl and a few wrapper
>> functions in userspace along the lines of (hand-wave):
>>
>> cpuset_t*cpuset_alloc();
>> void cpuset_free();
>>
>> And per
On 24 Oct 2010, at 14:20, Alexander Best wrote:
> On Sun Oct 24 10, Robert Watson wrote:
>> Author: rwatson
>> Date: Sun Oct 24 09:14:21 2010
>> New Revision: 214261
>> URL: http://svn.freebsd.org/changeset/base/214261
>>
>> Log:
>> Add microbenchmark for create/unlink of a zero-byte file.
>
>
On 4 Jun 2010, at 20:33, Ermal Luçi wrote:
> Interface event are not an issue for pfSense architecture since it
> controls all the underlying data and i think most of the divert
> applications do not care much about interface events apart renaming.
> Keeping both options sounds reasonable too.
A
On 3 Jun 2010, at 14:09, Ermal Luçi wrote:
> Would it make sense to remove even passing the interface name up and
> actually send the
> interface index?
>
> That is what we are doing at pfSense and it works quite ok.
I see one important argument for doing this:
- Looking up an interface by num
On 1 Jun 2010, at 15:23, Nikolay Denev wrote:
>> When close() is called on a connected socket pair, SO_ISCONNECTED might be
>> set but be cleared before the call to sodisconnect(). In this case,
>> ENOTCONN is returned: suppress this error rather than returning it to
>> userspace so that
On Mar 13, 2010, at 1:50 PM, Randall Stewart wrote:
> did not think of that.. we COULD possible do it another way.. a bit harder
> but possible.. i.e. have the delayed sack code actually look into
> the mbufs and see if its ipv4 or ipv6.. I thought about doing it
> that way but it takes more cycl
On Mar 12, 2010, at 6:56 PM, Qing Li wrote:
> Right now I like to implement Robert's suggestion of using if_capabilities
> field. I'd like to create a new flag, IFCAP_LINKSTATE_NOTIFY flag.
> The routing decision will check against the if_link_state if this bit
> is set.
>
> Only a handful of dr
On Mar 12, 2010, at 8:44 AM, Julian Elischer wrote:
> I'm confused about Julian's proposal because it seems to me that we
> already know when a driver hasn't set or is unable to determine the link
> state: it will (should) be set to LINK_STATE_UNKNOWN by default.
>
> the question i
useful is adding a new IFCAP flag that allows
a driver to statically declare that it will someday set the link state. But I
don't think that helps with ECMP, that's just for the benefit of programs like
dhclient that care about future events rather than current state.
Robert
>
> --
If we haven't converted that
>particular driver by then, we will update the driver if it's capable
> at that time.
>
> -- Qing
>
>
> On Fri, Mar 12, 2010 at 12:00 AM, Robert N. M. Watson
> wrote:
>>
>> On Mar 12, 2010, at 7:52 AM, Qing Li wrote
On Mar 12, 2010, at 8:11 AM, Qing Li wrote:
> I like Julian's suggestion because it is simple and very low risk.
> And there isn't a need to check for interface type any more.
> Here is why:
>
> 1. The interfaces that are popular and modern are already supporting
>link_state. So for these dr
On Mar 12, 2010, at 7:52 AM, Qing Li wrote:
>> Is there any way we can pick up via an assertion that an interface driver
>> has failed to implement this functionality? This has never been a historic
>> requirement, so I suspect there are a lot of drivers floating around that
>> fail to meet th
On Mar 12, 2010, at 12:18 AM, Qing Li wrote:
> You definitely have a very good point here. I was a bit surprised
> during debugging that the link state is not consistently initialized
> and by far not enforced across all of the drivers. Admittedly I checked
> the most commonly deployed devic
On Mar 11, 2010, at 11:30 PM, Qing Li wrote:
> What you raised is definitely a possibility and these fixes take the
> similar approach. I am going to try and go through each of these
> drivers in /sys/dev/ and converting them, very soon.
Is there any way we can pick up via an assertion that a
On Mar 10, 2010, at 1:15 PM, John Baldwin wrote:
> On Tuesday 09 March 2010 7:27:06 pm Robert Watson wrote:
>>
>> On Tue, 9 Mar 2010, John Baldwin wrote:
>>
>>> Log:
>>> MFC 183525: Bump MAXCPU to 32 now that 32 CPU x86 systems exist.
>>
>> Hmmm. I'd be a bit surprised if this doesn't cause A
On 14 Dec 2009, at 16:08, Bruce Evans wrote:
> On Mon, 14 Dec 2009, Robert Watson wrote:
>
>> Log:
>> Merge r197808 from head to stable/8:
>>
>> In rtld's map_object(), use pread(..., 0) rather than read() to read the
>> ELF header from the front of the file. As all other I/O on the binary
On 14 Jan 2010, at 20:01, Doug Barton wrote:
> FWIW, I actually think this makes it worse, not better. The
> INCLUDE_CONFIG_FILE option should include everything needed to recreate
> the kernel. If it doesn't, it's worse than worthless, it leads to a
> false sense of security which makes it dange
On 1 Dec 2009, at 11:25, Sean C. Farley wrote:
>>> We've already had two major security issues arising out of getenv.c in the
>>> past year, and I'd like to make sure we don't have a third.
>>
>> I think it's fair to say that the POSIXization of the environment code has
>> been an unmitigated
On 2 Nov 2009, at 18:20, Colin Percival wrote:
I think a more general caution for accept(2) might instead be:
BUGS
The inheritence of socket options from a listen socket to a newly
accepted socket is inconsistent across protocols, and non-
portable.
I was originally going to write it
On 1 Nov 2009, at 15:33, Ed Schouten wrote:
Because d_kind is a pointer, there will be a hole in the structure
of at
least 2 bytes (maybe even 6), which means we can safely extend
d_mode to
32 bits as well. I could have decided to leave it at uint16_t, but
that
would only obfuscate it eve
On 6 Oct 2009, at 20:27, Gabor Kovesdan wrote:
Robert Watson escribió:
+
+char *
+basename(path)
+ const char *path;
+{
+ static char *bname = NULL;
+
Sorry if it's a trivial question but isn't ANSI prototype preferred
over K&R function definition?
For the purposes of this pur
On 2 Aug 2009, at 20:29, Alfred Perlstein wrote:
* Robert Watson [090801 15:15] wrote:
On Sat, 1 Aug 2009, Hans Petter Selasky wrote:
This has slowed down core dumps very significantly. What used
to take
10-15s on my system now takes around 3 minutes. A simple test
is to
break into dd
83 matches
Mail list logo
