On Thu, Aug 27, 2009 at 04:14:39PM -0400, Linda Messerschmidt wrote:
> On Wed, Aug 26, 2009 at 4:42 PM, John Baldwin wrote:
> > One thing to note is that ktrace only logs voluntary context switches (i.e.
> > call to tsleep or waiting on a condition variable). It specifically does
> > not
> > log
On Wed, Aug 26, 2009 at 4:42 PM, John Baldwin wrote:
> One thing to note is that ktrace only logs voluntary context switches (i.e.
> call to tsleep or waiting on a condition variable). It specifically does not
> log preemptions or blocking on a mutex,
I was not aware, thanks.
> so in theory if y
In <200908271130.18073.er...@apsara.com.sg>, er...@apsara.com.sg wrote:
>Hi,
>
>On 27 August 2009 am 06:53:36 Steve Watt wrote:
>> In <4a954a35.4030...@icyb.net.ua>, a...@icyb.net.ua wrote:
>> >Assuming that ECC data lanes are connected between the two on
>> > motherboard, and given that BIOS doesn
On Wednesday 26 August 2009 5:07:16 pm remodeler wrote:
> I am hoping for input on a patch I want to apply to the MBR of a FreeBSD
> 8-BETA3 AMD64 server. I need a serial console on this server. The ASUS
> motherboard (amibios) has PCI and PCI-e expansion slots, and a Moschip MCS9820
> UART (serial
Joerg Sonnenberger writes:
> Erich Dollansky writes:
> > how should it be done at OS level at all when the OS is loaded
> > into RAM?
> Copy the kernel to the video RAM, jump to it, enable ECC, copy back.
Not just the kernel - you have to copy all the memory that is currently
in use, including
On Thu, Aug 27, 2009 at 11:30:15AM +0800, Erich Dollansky wrote:
> how should it be done at OS level at all when the OS is loaded
> into RAM?
Copy the kernel to the video RAM, jump to it, enable ECC, copy back.
Joerg
___
freebsd-hackers@freebsd.org mai
Hi,
On 27 August 2009 am 06:53:36 Steve Watt wrote:
> In <4a954a35.4030...@icyb.net.ua>, a...@icyb.net.ua wrote:
> >Assuming that ECC data lanes are connected between the two on
> > motherboard, and given that BIOS doesn't perform any ECC
> > setup (nor there is any option to control that) - would
"Matthew D. Fuller" writes:
> FWIW, I'm in favor of at least carefully examining whether the cons
> really disqualify the change.
They do. Breaking scripts is not acceptable under any circumstances.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebs
Dag-Erling Smørgrav napisa:
Actually, ls does pretty much the same thing (use a different layout
when run on a tty), and it's far from the only Unix utility to do so.
Usually, the tty layout is "pretty" while the non-tty layout is easier
to work with in scripts.
Actually ls doesn't work the sa
On Wed, Aug 26, 2009 at 11:40:09PM -0700 I heard the voice of
Brian Somers, and lo! it spake thus:
>
> I think this is a shame as I find the pros more compelling than the
> cons, and I'm sure there are more than a few supporters out there on
> hackers@ that will stay silent.
FWIW, I'm in favor of
Brian Somers writes:
> To clarify, my proposal is to silently ignore the -w switch (any/all of them)
> and to remove the code that reads the terminal width and truncates some
> columns based on the result (or based on "132").
>
> The pros:
>
> - ps's code becomes simpler. It was mentioned that th
Brian Somers wrote:
On Tue, 25 Aug 2009 03:40:54 -0700 Brian Somers wrote:
I recently closed bin/137647 and had second thoughts after Ivan (the
originator) challenged my reason for closing it.
The suggestion is that ps's -w switch is a strange artifact that can
be safely deprecated. ps goes t
On Tue, 25 Aug 2009 03:40:54 -0700 Brian Somers wrote:
> I recently closed bin/137647 and had second thoughts after Ivan (the
> originator) challenged my reason for closing it.
>
> The suggestion is that ps's -w switch is a strange artifact that can
> be safely deprecated. ps goes to great lengt
13 matches
Mail list logo
