On 12-6-2012 0:51, Garrett Cooper wrote:
> On Mon, Jun 11, 2012 at 3:21 PM, Brandon Falk wrote:
>> Greetings,
>>
>> I was just wondering what it is that FreeBSD does that makes it take so long
>> to boot. Booting into Ubuntu minimal or my own custom Linux distro,
>> literally takes 0.5-2 seconds t
On 13-6-2012 23:16, claudiu vasadi wrote:
>
> If you simplky do "sysctl -d hw.usb.no_boot_wait" you will see the
> explanation ;)
Probably why Eitan asked as that description:
a) means nothing to people unfamiliar with device enumerations
b) does not point to a manual page that explains how USB
On 8-6-2012 22:06, Michael Bushkov wrote:
> I don't know for sure, but it seems that there was no need to support
> anything besides groups and password when nss_compat.c was committed.
> At that time, IIRC, the modules that we had in ports supported only
> these databases.
Right. In the meantime
Hi,
I'm currently implementing support for more NSS databases in
net/nss-pamd-ldapd and I've started to wonder why there's only the group
and password support in lib/libc/net/nss_compat.c?
Is there a specific reason for it or is this a classic case of "patches
welcome"? I wasn't able to determine
On 4-6-2012 9:54, Pegasus Mc Cleaft wrote:
> I forgot to switch back to base gcc before
> compiling the nvidia driver. I installed the driver and rebooted, xorg
> came up but as soon as I logged in, kwin crashed, then the machine
> kernel panicked and rebooted. I rebooted and crashed a few more ti
On 28-5-2012 23:22, Jeremie Le Hen wrote:
> Hi Mel,
>
> On Sun, May 27, 2012 at 08:15:02PM +0200, Mel Flynn wrote:
>> Hi,
>>
>> for a port, I'm seeing:
>> #ifdef _FORTIFY_SOURCE
>> ...
>> #endif
>>
>> I did a bit of reading (http://wik
Hi,
for a port, I'm seeing:
#ifdef _FORTIFY_SOURCE
...
#endif
I did a bit of reading (http://wiki.debian.org/Hardening) for example,
searching through /usr/share/mk/* /usr/include/libssp, /usr/src/gnu/libssp.
However, it's not clear to me, where the magic is that pulls in the
libssp library that
On 19-5-2012 5:54, Tim Kientzle wrote:
>
> On May 18, 2012, at 7:51 AM, Mel Flynn wrote:
>
>> On 17-5-2012 14:53, Mateusz Guzik wrote:
>>> On Wed, May 16, 2012 at 11:37:44PM +0300, tza...@it.teithe.gr wrote:
>>
>>>> Nice. What about curl over the HTT
On 17-5-2012 14:53, Mateusz Guzik wrote:
> On Wed, May 16, 2012 at 11:37:44PM +0300, tza...@it.teithe.gr wrote:
>> Nice. What about curl over the HTTPS protocol?
>>
>
> curl would be ok, except it's not in the base system.
For this reason, it's probably best to use tar(1) to package up multiple
On 4/11/2012 16:47, Konstantin Belousov wrote:
> What happens, as I guess it, the SIGINFO and SIGCHLD are ignored, so
> kernel do not even bother to queue the signals to the master process.
> Register a dummy signal handler for your signals with sigaction
> before creating 'signal_handler' thread.
On 4/11/2012 16:26, Ian Lepore wrote:
> On Wed, 2012-04-11 at 16:11 +0200, Mel Flynn wrote:
>> What happens is that SIGCHLD is never received by the signal thread and
>> the child processes turn to zombies. Signal counters never go up, not
>> even for SIGINFO, which I added s
Hi,
I'm currently stuck on a bug in Zarafa-spooler that creates zombies. and
working around it by claiming that our pthread library isn't "normal"
which uses standard signals rather then a signal thread.
My limited understanding of these facilities is however not enough to
see the actual problem
On 3/16/2012 08:09, kota saikrishna wrote:
> I need to get process data structure using a pid. I found the pfind
> function which returns struct proc * but when i tried to use pfind
> function it is showing ---undefined reference to `pfind'
> Can any one suggest how to use pfind() function?
>Fro
On Wednesday 23 December 2009 01:19:23 Bjoern A. Zeeb wrote:
> On Tue, 22 Dec 2009, Mel Flynn wrote:
>
> Hi,
>
> first of all this would find more people to help on freebsd-jail as it
> has nothing to do with hackers ;-)
Yes, that was pretty braindead of me, especially since
Hi,
I don't see this documented in jail(8) nor rc(8) nor defaults/rc.conf, so is
it possible to have 2 IP's on 2 ethernet interfaces? And if so, is it settable
for rc(8)?
The usage case is to have the same jailed proxy server on two seperate
internal networks. Ideally, the proxy will use one a
On Thursday 26 November 2009 18:11:10 Linda Messerschmidt wrote:
> I did not mean to suggest that we were asking for help solving a
> problem with squid rotation. I provided that information as
> background to discuss what we observed as a potential misbehavior in
> the new VM superpages feature,
On Wednesday 04 November 2009 13:49:54 Mel Flynn wrote:
> Using env MALLOC_OPTIONS= also has no impact at all (just in case defaults
> aren't that). Since fgrep is fast and basically seeds the cache for grep,
> I'm ruling out disks/io reads. In fact, /tmp on this laptop is
On Wednesday 04 November 2009 04:05:44 Eygene Ryabinkin wrote:
> Mel, good day.
>
> Tue, Nov 03, 2009 at 09:22:28PM +0100, Mel Flynn wrote:
> > So on the laptop I modified the testscript as it is attached now and
> > while there is still a significant delay, the wallclock
On Tuesday 03 November 2009 22:19:05 Gabor Kovesdan wrote:
> Mel Flynn escribió:
> > Hi,
> >
> > attached a little test script for grep's -i performance. I tried a few
> > different machines and the 64-bit 7.2 machine I could steal doesn't seem
> &g
Hi,
attached a little test script for grep's -i performance. I tried a few
different machines and the 64-bit 7.2 machine I could steal doesn't seem to be
affected and out performs pcregrep.
On i386 machines, grep -i is significantly slower:
i386, 7.2-STABLE of Sep 8, load averages: 0.00, 0.02, 0
On Friday 09 October 2009 21:27:21 Dag-Erling Smørgrav wrote:
> Mel Flynn writes:
> > Dag-Erling Smørgrav writes:
> > > Yes, just run "gdb /path/to/program" and type "run".
> >
> > Not what I was looking for. The segfaults are random and the on
On Friday 09 October 2009 16:50:04 Mel Flynn wrote:
> On Friday 09 October 2009 11:38:29 Dag-Erling Smørgrav wrote:
> > Mel Flynn writes:
> > > is there a way to have a program run through gdb and gdb only record a
> > > segfault, but otherwise let the program run?
On Friday 09 October 2009 16:50:04 Mel Flynn wrote:
> On Friday 09 October 2009 11:38:29 Dag-Erling Smørgrav wrote:
> > Mel Flynn writes:
> > > [...] sudo *sometimes* segfaults [...] However, it doesn't dump core
> >
> > sudo(1) is setuid root. You need t
On Friday 09 October 2009 11:38:29 Dag-Erling Smørgrav wrote:
> Mel Flynn writes:
> > is there a way to have a program run through gdb and gdb only record a
> > segfault, but otherwise let the program run?
>
> Yes, just run "gdb /path/to/program" and type "ru
On Friday 09 October 2009 00:38:32 Paul B Mahol wrote:
> On 10/9/09, Mel Flynn wrote:
> > Hi,
> >
> > is there a way to have a program run through gdb and gdb only record a
> > segfault, but otherwise let the program run?
> >
> > Why I'd like this is t
Hi,
is there a way to have a program run through gdb and gdb only record a
segfault, but otherwise let the program run?
Why I'd like this is the following:
I've got a i386 jail on an amd64 box, running 7.2-p4. UNAME_p and UNAME_m have
been set to i386 as well as ARCH in /etc/make.conf. Running
On Tuesday 04 August 2009 13:43:24 Dimitry Andric wrote:
> On 2009-08-04 22:45, Mel Flynn wrote:
> > % mount -t msdofs /dev/label/camera ~/camera
> > mount: /dev/label/camera : Operation not supported by device
> >
> > I would expect something along the lines of "u
Hi,
granted it took me less then a minute to figure it out, but the error is kind
of not helping:
% mount -t msdofs /dev/label/camera ~/camera
mount: /dev/label/camera : Operation not supported by device
I would expect something along the lines of "unknown file system type". Is
this fixable?
--
On Sun, 19 Jul 2009 22:13:48 -0800, Mel Flynn
wrote:
> On Mon, 13 Jul 2009 16:39:09 -0400, John Baldwin wrote:
>> On Monday 13 July 2009 3:33:51 pm Tijl Coosemans wrote:
>>> On Monday 13 July 2009 20:28:08 John Baldwin wrote:
>>> > On Sunday 05 July 2009 3
On Mon, 13 Jul 2009 16:39:09 -0400, John Baldwin wrote:
> On Monday 13 July 2009 3:33:51 pm Tijl Coosemans wrote:
>> On Monday 13 July 2009 20:28:08 John Baldwin wrote:
>> > On Sunday 05 July 2009 3:32:25 am Alexander Best wrote:
>> >> so mmap differs from the POSIX recommendation right. the mallo
On Tuesday 30 June 2009 00:24:00 Alan Cox wrote:
> Mel Flynn wrote:
> > On Sunday 28 June 2009 15:41:49 Alan Cox wrote:
> >> Wojciech Puchar wrote:
> >>> how can i check how much (or maybe - what processes) 2MB pages are
> >>> actually allocated?
>
On Sunday 28 June 2009 15:41:49 Alan Cox wrote:
> Wojciech Puchar wrote:
> > how can i check how much (or maybe - what processes) 2MB pages are
> > actually allocated?
>
> I'm afraid that you can't with great precision. For a given program
> execution, on an otherwise idle machine, you can only e
On Wednesday 17 June 2009 13:17:37 John Baldwin wrote:
> On Wednesday 17 June 2009 3:52:54 pm Mel Flynn wrote:
> > On Wednesday 17 June 2009 04:15:26 John Baldwin wrote:
> > > On Tuesday 16 June 2009 7:01:45 pm Mel Flynn wrote:
> > > > On Tuesday 16 June 20
On Wednesday 17 June 2009 04:15:26 John Baldwin wrote:
> On Tuesday 16 June 2009 7:01:45 pm Mel Flynn wrote:
> > On Tuesday 16 June 2009 11:02:42 John Baldwin wrote:
> > > On Tuesday 16 June 2009 1:52:23 pm Mel Flynn wrote:
> > > > Hi John,
> > > >
>
On Tuesday 16 June 2009 11:02:42 John Baldwin wrote:
> On Tuesday 16 June 2009 1:52:23 pm Mel Flynn wrote:
> > Hi John,
> >
> > On Tuesday 16 June 2009 04:19:57 John Baldwin wrote:
> > > On Monday 15 June 2009 5:53:05 pm Mel Flynn wrote:
> > >
Hi John,
On Tuesday 16 June 2009 04:19:57 John Baldwin wrote:
> On Monday 15 June 2009 5:53:05 pm Mel Flynn wrote:
> > PIDTID COMM TDNAME KSTACK
> > 4283 100215 kdeinit4 -mi_switch turnstile_wait
> > _mtx_loc
Hi,
I'm trying to get to the bottom of a bug with getpeername() and certain kde4
applications which is probably as low-level as the libthr and the scheduler.
From browsing various related files in sys/kern it seems KTR is a good bet to
get the information needed, yet it isn't really well suppor
On Tuesday 26 May 2009 23:20:01 Dag-Erling Smørgrav wrote:
> Dag-Erling Smørgrav writes:
> > Like bde@ pointed out, the patch is incorrect. It moves the test for
> > v_type != VDIR up to a point where, in the case of a symlink, v_type is
> > always (by definition) VLNK.
>
> Hmm, actually, symlink
38 matches
Mail list logo
