On Fri, Jun 03, 2011 at 02:48:59PM +, Ruslan Ermilov wrote:
> On a freshly installed -CURRENT, to view a colorized manpage in color
> and in full terminal width, try this:
>
> env MANCOLOR=yes MANWIDTH=tty man grotty
>
SGR presence can be easily autodetected analyzing termcap capibilit
On Fri, Jun 03, 2011 at 09:16:58PM -0400, Aryeh Friedman wrote:
> No will do even though I don't think I have a complete enough list of
> ports to make a proper report (if in fact it is a per port solution
> vs. fixing base)
I don't see any related commits to 8-STABLE, which commit are you
refferi
No will do even though I don't think I have a complete enough list of
ports to make a proper report (if in fact it is a per port solution
vs. fixing base)
On Fri, Jun 3, 2011 at 9:09 PM, Garrett Cooper wrote:
> On Fri, Jun 3, 2011 at 5:02 PM, Aryeh Friedman
> wrote:
>> Some time in the last 2 w
On Fri, Jun 3, 2011 at 5:02 PM, Aryeh Friedman wrote:
> Some time in the last 2 weeks (I am sure when) a commit caused many
> ports that assume a "standard" utmp/utmp.x to break for example
> x11-toolkits/vte produces:
>
> gnome-pty-helper.c:497: warning: passing argument 4 of 'pty_add'
> discards
Some time in the last 2 weeks (I am sure when) a commit caused many
ports that assume a "standard" utmp/utmp.x to break for example
x11-toolkits/vte produces:
gnome-pty-helper.c:497: warning: passing argument 4 of 'pty_add'
discards qualifiers from pointer target type
mv -f .deps/gnome-pty-helper.
* Doug Barton , 20110603 23:10:
> On 06/03/2011 14:07, Ed Schouten wrote:
> >the reason why I picked the current
> >approach, is because I don't want to cause people to get confused when
> >they upgrade to 9.0, to discover that their lastlog database is
> >`miss
On 06/03/2011 14:07, Ed Schouten wrote:
the reason why I picked the current
approach, is because I don't want to cause people to get confused when
they upgrade to 9.0, to discover that their lastlog database is
`missing'.
Understood, but in my mind that's a release notes issue.
--
No
Hi Doug,
* Doug Barton , 20110603 22:57:
> FWIW I'm not enthusiastic about either option. I definitely don't
> think an rc.d script is desirable, since it would be run at every
> boot for what (if I understand it correctly) is a one-time thing.
> More or less the same argu
On 06/03/2011 13:47, Garrett Cooper wrote:
On Fri, Jun 3, 2011 at 1:43 PM, Ed Schouten wrote:
Hi all,
I think not long after I replaced utmp with utmpx, I got requests to add
utilities to convert the old utmp databases to the new formats. I added
wtmpcvt(1) for /var/log/wtmp*, but I didn't add
Hi Garrett,
* Garrett Cooper , 20110603 22:47:
> Is this a one time change? If so, wouldn't it make more sense to
> put this into mergemaster(8) instead of rc(5)?
Good point. I hadn't thought about that. I'll take a look.
--
Ed Schouten
WWW: http://80386.nl
On Fri, Jun 3, 2011 at 1:43 PM, Ed Schouten wrote:
> Hi all,
>
> I think not long after I replaced utmp with utmpx, I got requests to add
> utilities to convert the old utmp databases to the new formats. I added
> wtmpcvt(1) for /var/log/wtmp*, but I didn't add any tools for the other
> databases.
Hi all,
I think not long after I replaced utmp with utmpx, I got requests to add
utilities to convert the old utmp databases to the new formats. I added
wtmpcvt(1) for /var/log/wtmp*, but I didn't add any tools for the other
databases. Even though it's a bit overdue (more than one year later?), I
BTW,
I've been pounding on the new NFS server with a few test VM's from my ESX
cluster for the last 2 weeks, 24/7. Everything looks solid, no panics, no
errors, no corruption. Memory usage is staying stable, so I haven't found any
leaks. I'm using IOMETER to move a few TB of randomized data a
On 3 Jun 2011, at 16:13, Andriy Gapon wrote:
> I wonder if anybody uses kdb_stop_cpus with non-default value.
> If, yes, I am very interested to learn about your usecase for it.
The issue that prompted the sysctl was non-NMI IPIs being used to enter the
debugger or reboot following a core hangi
In the year 2008, there were some discussions about efforts going on in
developing a 64Bit compliant Linuxulator64 for FreeBSD/amd64. What is
the status of this project?
Oliver
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mail
on 03/06/2011 18:28 Nathan Whitehorn said the following:
> On 06/03/11 10:13, Andriy Gapon wrote:
>>
>> I wonder if anybody uses kdb_stop_cpus with non-default value.
>> If, yes, I am very interested to learn about your usecase for it.
>>
>> I think that the default kdb behavior is the correct one,
On Tue, 2011-05-31 at 19:38 +0200, Michael Reifenberger wrote:
> Hi,
>
> On Tue, 31 May 2011, Michael Reifenberger wrote:
> ...
> > (fs)(root) gpart show ada0
> > =>34 5860533101 ada0 GPT (2.7T)
> > 34 990 1 freebsd-boot (495k)
> >1024 2098176 2
On 03.06.11 11:26, Maxim Sobolev wrote:
On 5/29/2011 4:11 AM, Mikolaj Golub wrote:
This might be MSG_WAITALL issue I described on net@ (look for the thread
"recv() with MSG_WAITALL might stuck when receiving more than
rcvbuf", and
also kern/154504).
Could you please try the patch?
http://p
On 06/03/11 10:13, Andriy Gapon wrote:
I wonder if anybody uses kdb_stop_cpus with non-default value.
If, yes, I am very interested to learn about your usecase for it.
I think that the default kdb behavior is the correct one, so it doesn't make
sense
to have a knob to turn on incorrect behavio
I wonder if anybody uses kdb_stop_cpus with non-default value.
If, yes, I am very interested to learn about your usecase for it.
I think that the default kdb behavior is the correct one, so it doesn't make
sense
to have a knob to turn on incorrect behavior.
But I may be missing something obvious
Hi there,
On a freshly installed -CURRENT, to view a colorized manpage in color
and in full terminal width, try this:
env MANCOLOR=yes MANWIDTH=tty man grotty
Both features are disabled by default for POLA reasons. Bikeshedding
will be redirected to /dev/null.
Cheers,
--
Ruslan Ermil
Em 02/06/2011, às 19:31, Luigi Rizzo escreveu:
> Hi,
> we have recently worked on a project, called netmap, which lets
> FreeBSD send/receive packets at line rate even at 10 Gbit/s with
> very low CPU overhead: one core at 1.33 GHz does 14.88 Mpps with a
> modified ixgbe driver, which gives plent
On Fri, Jun 03, 2011 at 10:20:50AM -0300, Patrick Tracanelli wrote:
>
> Em 02/06/2011, ?s 19:31, Luigi Rizzo escreveu:
>
> > Hi,
> > we have recently worked on a project, called netmap, which lets
> > FreeBSD send/receive packets at line rate even at 10 Gbit/s with
> > very low CPU overhead: one
I just got this on another machine, no heavy workload needed, just booting
and starting some jails. Of interest, perhaps, both this and the machine
triggering the below panic are SMP V240s with 1.5GHz CPUs (though I will
confess that the machine in the original report may have had bad RAM). I
hav
On 5/29/2011 4:11 AM, Mikolaj Golub wrote:
This might be MSG_WAITALL issue I described on net@ (look for the thread
"recv() with MSG_WAITALL might stuck when receiving more than rcvbuf", and
also kern/154504).
Could you please try the patch?
http://people.freebsd.org/~trociny/uipc_socket.c.patc
On Fri, Jun 3, 2011 at 12:31 AM, Luigi Rizzo wrote:
> Hi,
> we have recently worked on a project, called netmap, which lets
> FreeBSD send/receive packets at line rate even at 10 Gbit/s with
> very low CPU overhead: one core at 1.33 GHz does 14.88 Mpps with a
> modified ixgbe driver, which gives
26 matches
Mail list logo
