I have a multi-core Q6600 CPU on a 10-disk Raptor RAID 5 running XFS.
I just pulled down the Debian Etch 4.0 DVD ISO's, one for x86 and one for
x86_64, when I ran md5sum -c MD5SUMS, I see ~280-320MB/s. When I ran the
second one I see upwards of what I should be seeing 500-520MB/s.
NOTE::
On Fri, 20 Jul 2007, Lennart Sorensen wrote:
On Fri, Jul 20, 2007 at 09:58:50AM -0400, Justin Piszcz wrote:
I have a multi-core Q6600 CPU on a 10-disk Raptor RAID 5 running XFS.
I just pulled down the Debian Etch 4.0 DVD ISO's, one for x86 and one for
x86_64, when I ran md5sum -c MD5SUMS, I
On Wed, 18 Jul 2007, Al Boldi wrote:
Justin Piszcz wrote:
UltraDense-AS-3ware-R5-9-disks,16G,50676,89,96019,34,46379,9,60267,99,5010
98,56,248.5,0,16:10:16/64,240,3,21959,84,1109,10,286,4,22923,91,544,6
UltraDense-AS-3ware-R5-9-disks,16G,49983,88,96902,37,47951,10,59002,99,529
Correcting address:
-- Forwarded message --
Date: Wed, 18 Jul 2007 06:23:25 -0400 (EDT)
From: Justin Piszcz <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Software RAID5 Horrible Write Speed On 3ware Controlle
On Wed, 18 Jul 2007, Rui Santos wrote:
Hi,
I'm getting a strange slow performance behavior on a recently installed
Server. Here are the details:
Server: Asus AS-TS500-E4A
Board: Asus DSBV-D (
http://uk.asus.com/products.aspx?l1=9=39=299=0=1210=2
)
Hard Drives: 3x Seagate ST3400620AS (
On Wed, 18 Jul 2007, Rui Santos wrote:
Hi,
I'm getting a strange slow performance behavior on a recently installed
Server. Here are the details:
Server: Asus AS-TS500-E4A
Board: Asus DSBV-D (
http://uk.asus.com/products.aspx?l1=9l2=39l3=299l4=0model=1210modelmenu=2
)
Hard Drives: 3x Seagate
Correcting address:
-- Forwarded message --
Date: Wed, 18 Jul 2007 06:23:25 -0400 (EDT)
From: Justin Piszcz [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Software RAID5 Horrible Write Speed On 3ware Controller!!
I
On Wed, 18 Jul 2007, Al Boldi wrote:
Justin Piszcz wrote:
UltraDense-AS-3ware-R5-9-disks,16G,50676,89,96019,34,46379,9,60267,99,5010
98,56,248.5,0,16:10:16/64,240,3,21959,84,1109,10,286,4,22923,91,544,6
UltraDense-AS-3ware-R5-9-disks,16G,49983,88,96902,37,47951,10,59002,99,529
On Sat, 14 Jul 2007, Mr. James W. Laferriere wrote:
Hello All , I was under the impression that a 'machine check' would
be caused by some near to the CPU hardware failure , Not a bad disk ?
I was also under the impression that software raid s/b a little more
resilient than this .
But
I have an older MSI motherboard and when I enable the following option:
From lshw:
description: Motherboard
product: MS-6730
[*] IO-APIC support on uniprocessors
I get the following errors in dmesg:
[ 247.177372] APIC error on CPU0: 00(40)
[ 247.556741] APIC error on CPU0:
Hi all,
I use an A-BIT AW9D-MAX motherboard and while the audio works fine using
the Intel HDA driver; however, I see this in dmesg:
[ 29.188561] Advanced Linux Sound Architecture Driver Version 1.0.14
(Thu May 31 09:03:25 2007 UTC).
[ 29.188728] ACPI: PCI Interrupt :00:1b.0[A] ->
Hi all,
I use an A-BIT AW9D-MAX motherboard and while the audio works fine using
the Intel HDA driver; however, I see this in dmesg:
[ 29.188561] Advanced Linux Sound Architecture Driver Version 1.0.14
(Thu May 31 09:03:25 2007 UTC).
[ 29.188728] ACPI: PCI Interrupt :00:1b.0[A] -
I have an older MSI motherboard and when I enable the following option:
From lshw:
description: Motherboard
product: MS-6730
[*] IO-APIC support on uniprocessors
I get the following errors in dmesg:
[ 247.177372] APIC error on CPU0: 00(40)
[ 247.556741] APIC error on CPU0:
On Sat, 14 Jul 2007, Mr. James W. Laferriere wrote:
Hello All , I was under the impression that a 'machine check' would
be caused by some near to the CPU hardware failure , Not a bad disk ?
I was also under the impression that software raid s/b a little more
resilient than this .
But
On Thu, 5 Jul 2007, Bill Davidsen wrote:
Justin Piszcz wrote:
On Wed, 4 Jul 2007, Justin Piszcz wrote:
On Wed, 4 Jul 2007, Michael Tokarev wrote:
> Tejun Heo wrote:
>> Hello,
>>
>> Michael Tokarev wrote:
>>> Well. It looks like the results does
On Thu, 5 Jul 2007, Bill Davidsen wrote:
Justin Piszcz wrote:
On Wed, 4 Jul 2007, Justin Piszcz wrote:
On Wed, 4 Jul 2007, Michael Tokarev wrote:
Tejun Heo wrote:
Hello,
Michael Tokarev wrote:
Well. It looks like the results does not depend on the
elevator. Originally I tried
On Thu, 5 Jul 2007, Pavel Machek wrote:
Hi!
On some machines, buggy BIOSes don't properly setup WB MTRRs to
cover all available RAM, meaning the last few megs (or even gigs)
of memory will be marked uncached. Since Linux tends to allocate
from high memory addresses first, this causes the
On Thu, 5 Jul 2007, Pavel Machek wrote:
Hi!
On some machines, buggy BIOSes don't properly setup WB MTRRs to
cover all available RAM, meaning the last few megs (or even gigs)
of memory will be marked uncached. Since Linux tends to allocate
from high memory addresses first, this causes the
On Wed, 4 Jul 2007, Justin Piszcz wrote:
On Wed, 4 Jul 2007, Michael Tokarev wrote:
> Tejun Heo wrote:
>> Hello,
>>
>> Michael Tokarev wrote:
>>> Well. It looks like the results does not depend on the
>>> elevator. Originally I tried with deadline,
On Wed, 4 Jul 2007, Michael Tokarev wrote:
Tejun Heo wrote:
Hello,
Michael Tokarev wrote:
Well. It looks like the results does not depend on the
elevator. Originally I tried with deadline, and just
re-ran the test with noop (hence the long delay with
the answer) - changing linux elevator
On Wed, 4 Jul 2007, Michael Tokarev wrote:
Tejun Heo wrote:
Hello,
Michael Tokarev wrote:
Well. It looks like the results does not depend on the
elevator. Originally I tried with deadline, and just
re-ran the test with noop (hence the long delay with
the answer) - changing linux elevator
On Wed, 4 Jul 2007, Justin Piszcz wrote:
On Wed, 4 Jul 2007, Michael Tokarev wrote:
Tejun Heo wrote:
Hello,
Michael Tokarev wrote:
Well. It looks like the results does not depend on the
elevator. Originally I tried with deadline, and just
re-ran the test with noop (hence the long
Incase anyone is interested:
p34:/usr/src/linux-2.6.22-rc7# patch -p1 < ../mtrr-v3.patch
patching file Documentation/kernel-parameters.txt
Hunk #1 succeeded at 548 (offset -5 lines).
patching file arch/i386/kernel/cpu/mtrr/generic.c
Hunk #2 succeeded at 85 (offset 1 line).
patching file
Incase anyone is interested:
p34:/usr/src/linux-2.6.22-rc7# patch -p1 ../mtrr-v3.patch
patching file Documentation/kernel-parameters.txt
Hunk #1 succeeded at 548 (offset -5 lines).
patching file arch/i386/kernel/cpu/mtrr/generic.c
Hunk #2 succeeded at 85 (offset 1 line).
patching file
On Wed, 27 Jun 2007, Pim Zandbergen wrote:
Andi Kleen wrote:
That's impossible. Either it limited your RAM or it didn't change anything.
OK, maybe it's cosmetic, but I would not expect a negative number
With old BIOS it printed
MTRRs don't cover all of memory, trimmed 196608 pages
On Wed, 27 Jun 2007, Pim Zandbergen wrote:
Andi Kleen wrote:
That's impossible. Either it limited your RAM or it didn't change anything.
OK, maybe it's cosmetic, but I would not expect a negative number
With old BIOS it printed
MTRRs don't cover all of memory, trimmed 196608 pages
I am running one with 64,128,256,512,1024,2048,4096,8192,16384,32768,65536
it it accepts up that high.. With XFS and _ALL_ default mount and
filesystem settings to target this specific tunable.
p34:~# /usr/bin/time ./benchraid.sh
Tue Jun 26 10:25:21 EDT 2007: Creating RAID5 array with 64
I am running one with 64,128,256,512,1024,2048,4096,8192,16384,32768,65536
it it accepts up that high.. With XFS and _ALL_ default mount and
filesystem settings to target this specific tunable.
p34:~# /usr/bin/time ./benchraid.sh
Tue Jun 26 10:25:21 EDT 2007: Creating RAID5 array with 64
On Mon, 25 Jun 2007, Jesse Barnes wrote:
On Monday, June 25, 2007 3:01:27 Andrew Morton wrote:
On Mon, 25 Jun 2007 14:34:42 -0700
Jesse Barnes <[EMAIL PROTECTED]> wrote:
akpm -- this one should replace all the mtrr patches currently
in your tree.
fear, uncertainty, doubt.
Will try this patch shortly w/ 2.6.22-rc6.
p34:/usr/src/linux-2.6.22-rc6# patch -p1 < ../mtrr-v3.patch
patching file Documentation/kernel-parameters.txt
patching file arch/i386/kernel/cpu/mtrr/generic.c
patching file arch/i386/kernel/cpu/mtrr/if.c
patching file arch/i386/kernel/cpu/mtrr/main.c
Impressive.
Jesse, can you touch base with Intel's BIOS department? Also, what are
the chances of that patch making it into 2.6.22-rc6/7 if it hasn't
already?
On Mon, 25 Jun 2007, Pim Zandbergen wrote:
Pim Zandbergen wrote
I reported this to GigaByte, and lo and behold, they sent me a
Impressive.
Jesse, can you touch base with Intel's BIOS department? Also, what are
the chances of that patch making it into 2.6.22-rc6/7 if it hasn't
already?
On Mon, 25 Jun 2007, Pim Zandbergen wrote:
Pim Zandbergen wrote
I reported this to GigaByte, and lo and behold, they sent me a
Will try this patch shortly w/ 2.6.22-rc6.
p34:/usr/src/linux-2.6.22-rc6# patch -p1 ../mtrr-v3.patch
patching file Documentation/kernel-parameters.txt
patching file arch/i386/kernel/cpu/mtrr/generic.c
patching file arch/i386/kernel/cpu/mtrr/if.c
patching file arch/i386/kernel/cpu/mtrr/main.c
On Mon, 25 Jun 2007, Jesse Barnes wrote:
On Monday, June 25, 2007 3:01:27 Andrew Morton wrote:
On Mon, 25 Jun 2007 14:34:42 -0700
Jesse Barnes [EMAIL PROTECTED] wrote:
akpm -- this one should replace all the mtrr patches currently
in your tree.
fear, uncertainty, doubt.
box:/usr/src/25
Is there any XFS filesystem performance benefit using the new SLUB
allocator? What types of workloads would using the SLUB allocator be
beneficial?
Justin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
Question regarding the IRQ balance daemon and the 2.6.x kernel.
For a single-processor but dual or quad core CPU, should one be running
the IRQ balancing daemon, will it result in increased performance?
Or is IRQ balance mainly targeted at physical multi-processor systems?
Justin.
-
To
Still patches clean against 2.6.22-rc5 incase anyone wanted to know:
# patch -p1 < ../mtrr-v2.patch
patching file Documentation/kernel-parameters.txt
patching file arch/i386/kernel/cpu/mtrr/generic.c
patching file arch/i386/kernel/cpu/mtrr/if.c
patching file arch/i386/kernel/cpu/mtrr/main.c
On Sun, 24 Jun 2007, Michael Tokarev wrote:
Justin Piszcz wrote:
Don't forget about max_sectors_kb either (for all drives in the SW RAID5
array)
max_sectors_kb = 8
$ dd if=/dev/zero of=file.out6 bs=1M count=10240
10737418240 bytes (11 GB) copied, 55.4848 seconds, 194 MB/s
max_sectors_kb
Don't forget about max_sectors_kb either (for all drives in the SW RAID5
array)
max_sectors_kb = 8
$ dd if=/dev/zero of=file.out6 bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 55.4848 seconds, 194 MB/s
max_sectors_kb = 16
$ dd if=/dev/zero
Don't forget about max_sectors_kb either (for all drives in the SW RAID5
array)
max_sectors_kb = 8
$ dd if=/dev/zero of=file.out6 bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 55.4848 seconds, 194 MB/s
max_sectors_kb = 16
$ dd if=/dev/zero
On Sun, 24 Jun 2007, Michael Tokarev wrote:
Justin Piszcz wrote:
Don't forget about max_sectors_kb either (for all drives in the SW RAID5
array)
max_sectors_kb = 8
$ dd if=/dev/zero of=file.out6 bs=1M count=10240
10737418240 bytes (11 GB) copied, 55.4848 seconds, 194 MB/s
max_sectors_kb
Still patches clean against 2.6.22-rc5 incase anyone wanted to know:
# patch -p1 ../mtrr-v2.patch
patching file Documentation/kernel-parameters.txt
patching file arch/i386/kernel/cpu/mtrr/generic.c
patching file arch/i386/kernel/cpu/mtrr/if.c
patching file arch/i386/kernel/cpu/mtrr/main.c
Question regarding the IRQ balance daemon and the 2.6.x kernel.
For a single-processor but dual or quad core CPU, should one be running
the IRQ balancing daemon, will it result in increased performance?
Or is IRQ balance mainly targeted at physical multi-processor systems?
Justin.
-
To
Is there any XFS filesystem performance benefit using the new SLUB
allocator? What types of workloads would using the SLUB allocator be
beneficial?
Justin.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
On Thu, 21 Jun 2007, Mattias Wadenstein wrote:
On Thu, 21 Jun 2007, Neil Brown wrote:
I have that - apparently naive - idea that drives use strong checksum,
and will never return bad data, only good data or an error. If this
isn't right, then it would really help to understand what the
On Thu, 21 Jun 2007, Pim Zandbergen wrote:
Jesse Barnes wrote:
What, are you going to report this to GigaByte?
No, but you should if you haven't already. I think GigaByte probably gets
its BIOS from another BIOS vendor (maybe Intel), so when that vendor
provides them with an update,
On Thu, 21 Jun 2007, Pim Zandbergen wrote:
Jesse Barnes wrote:
What, are you going to report this to GigaByte?
No, but you should if you haven't already. I think GigaByte probably gets
its BIOS from another BIOS vendor (maybe Intel), so when that vendor
provides them with an update,
On Thu, 21 Jun 2007, Mattias Wadenstein wrote:
On Thu, 21 Jun 2007, Neil Brown wrote:
I have that - apparently naive - idea that drives use strong checksum,
and will never return bad data, only good data or an error. If this
isn't right, then it would really help to understand what the
On Fri, 15 Jun 2007, Pim Zandbergen wrote:
Justin Piszcz wrote:
That's strange, I guess different chipsets 'chew' up different amounts of
memory OR you have your DVT(?) (video-card memory/aperature) set to 256MB?
I have mine set to 128MB, in top:
Mem: 8039576k total, 6187304k used
On Fri, 15 Jun 2007, Pim Zandbergen wrote:
Justin Piszcz wrote:
That's strange, I guess different chipsets 'chew' up different amounts of
memory OR you have your DVT(?) (video-card memory/aperature) set to 256MB?
I have mine set to 128MB, in top:
Mem: 8039576k total, 6187304k used
On Thu, 14 Jun 2007, Jesse Barnes wrote:
On Thursday, June 14, 2007 1:26:07 Justin Piszcz wrote:
On Thu, 14 Jun 2007, Pim Zandbergen wrote:
Thanks for this patch. I was having the exact same symptoms as
Justin Piszcz, on a different, but similar motherboard:
Motherboard: GigaByte GA-G33
On Thu, 14 Jun 2007, Pim Zandbergen wrote:
Thanks for this patch. I was having the exact same symptoms as Justin Piszcz,
on a different, but similar motherboard:
Motherboard: GigaByte GA-G33-DS3R
BIOS rev: F2
Chipset: Intel G33
Memory: 8GB
Distro: Fedora 7 x86_64
Kernel: kernel-2.6.21
On Thu, 14 Jun 2007, Pim Zandbergen wrote:
Thanks for this patch. I was having the exact same symptoms as Justin Piszcz,
on a different, but similar motherboard:
Motherboard: GigaByte GA-G33-DS3R
BIOS rev: F2
Chipset: Intel G33
Memory: 8GB
Distro: Fedora 7 x86_64
Kernel: kernel-2.6.21
On Thu, 14 Jun 2007, Jesse Barnes wrote:
On Thursday, June 14, 2007 1:26:07 Justin Piszcz wrote:
On Thu, 14 Jun 2007, Pim Zandbergen wrote:
Thanks for this patch. I was having the exact same symptoms as
Justin Piszcz, on a different, but similar motherboard:
Motherboard: GigaByte GA-G33
On Tue, 12 Jun 2007, Pavel Machek wrote:
Hi!
On some machines, buggy BIOSes don't properly setup WB MTRRs to
cover all available RAM, meaning the last few megs (or even gigs)
of memory will be marked uncached. Since Linux tends to allocate
from high memory addresses first, this causes the
On Tue, 12 Jun 2007, Pavel Machek wrote:
Hi!
On some machines, buggy BIOSes don't properly setup WB MTRRs to
cover all available RAM, meaning the last few megs (or even gigs)
of memory will be marked uncached. Since Linux tends to allocate
from high memory addresses first, this causes the
On Sun, 10 Jun 2007, Mark Lord wrote:
Kai Makisara wrote:
The command 'smartctl -a /dev/sdb' fails with 2.6.22-rc4 kernel. The disk
/dev/sdb is a SATA disk. The command does work still with a real SCSI disk.
Last time I checked, one must supply the "-d ata" parameter to smartctl
for it to
On Sun, 10 Jun 2007, Mark Lord wrote:
Kai Makisara wrote:
The command 'smartctl -a /dev/sdb' fails with 2.6.22-rc4 kernel. The disk
/dev/sdb is a SATA disk. The command does work still with a real SCSI disk.
Last time I checked, one must supply the -d ata parameter to smartctl
for it to
965WH motherboard with 8GB of memory.
Signed-off-by: Justin Piszcz <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
.
Signed-off-by: Justin Piszcz [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
p34:/usr/src/linux# patch -p1 < ../mtrr-v2.patch
patching file Documentation/kernel-parameters.txt
patching file arch/i386/kernel/cpu/mtrr/generic.c
patching file arch/i386/kernel/cpu/mtrr/if.c
patching file arch/i386/kernel/cpu/mtrr/main.c
patching file arch/i386/kernel/cpu/mtrr/mtrr.h
patching
Will see if it still patches against -rc4.
On Thu, 7 Jun 2007, Jesse Barnes wrote:
On some machines, buggy BIOSes don't properly setup WB MTRRs to
cover all available RAM, meaning the last few megs (or even gigs)
of memory will be marked uncached. Since Linux tends to allocate
from high
On Thu, 7 Jun 2007, Jesse Barnes wrote:
On Thursday, June 7, 2007 1:16 am Andi Kleen wrote:
On Wed, Jun 06, 2007 at 12:29:23PM -0700, Jesse Barnes wrote:
On some machines, buggy BIOSes don't properly setup WB MTRRs to
cover all available RAM, meaning the last few megs (or even gigs)
of
On Thu, 7 Jun 2007, Andi Kleen wrote:
On Wed, Jun 06, 2007 at 04:27:46PM -0700, Jesse Barnes wrote:
On Wednesday, June 6, 2007 4:24 pm Justin Piszcz wrote:
The mem= approach though looks slightly off, but I haven't looked
at x86_64's mem= handling to see why. From a high level though
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On Wednesday, June 6, 2007 4:15 pm Justin Piszcz wrote:
On Wed, 6 Jun 2007, Randy Dunlap wrote:
On Wed, 6 Jun 2007 18:54:37 -0400 (EDT) Justin Piszcz wrote:
Hm, not sure if it was from the patch or what but I ran this:
1. swapoff -a
2. ./eatmem
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On Wednesday, June 6, 2007 4:15 pm Justin Piszcz wrote:
On Wed, 6 Jun 2007, Randy Dunlap wrote:
On Wed, 6 Jun 2007 18:54:37 -0400 (EDT) Justin Piszcz wrote:
Hm, not sure if it was from the patch or what but I ran this:
1. swapoff -a
2. ./eatmem
On Thu, 7 Jun 2007, Andi Kleen wrote:
On Wed, Jun 06, 2007 at 04:27:46PM -0700, Jesse Barnes wrote:
On Wednesday, June 6, 2007 4:24 pm Justin Piszcz wrote:
The mem= approach though looks slightly off, but I haven't looked
at x86_64's mem= handling to see why. From a high level though
On Thu, 7 Jun 2007, Jesse Barnes wrote:
On Thursday, June 7, 2007 1:16 am Andi Kleen wrote:
On Wed, Jun 06, 2007 at 12:29:23PM -0700, Jesse Barnes wrote:
On some machines, buggy BIOSes don't properly setup WB MTRRs to
cover all available RAM, meaning the last few megs (or even gigs)
of
Will see if it still patches against -rc4.
On Thu, 7 Jun 2007, Jesse Barnes wrote:
On some machines, buggy BIOSes don't properly setup WB MTRRs to
cover all available RAM, meaning the last few megs (or even gigs)
of memory will be marked uncached. Since Linux tends to allocate
from high
p34:/usr/src/linux# patch -p1 ../mtrr-v2.patch
patching file Documentation/kernel-parameters.txt
patching file arch/i386/kernel/cpu/mtrr/generic.c
patching file arch/i386/kernel/cpu/mtrr/if.c
patching file arch/i386/kernel/cpu/mtrr/main.c
patching file arch/i386/kernel/cpu/mtrr/mtrr.h
patching
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On Wednesday, June 6, 2007 3:57 pm Justin Piszcz wrote:
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On Wednesday, June 6, 2007 3:26 pm Justin Piszcz wrote:
Nope, I booted with only netconsole= options. I have a lot of HW
in the box and I guess
On Wed, 6 Jun 2007, Randy Dunlap wrote:
On Wed, 6 Jun 2007 18:54:37 -0400 (EDT) Justin Piszcz wrote:
Hm, not sure if it was from the patch or what but I ran this:
1. swapoff -a
2. ./eatmem
You usually have to access the allocated memory, like:
*d = 1.0;
for it to actually
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On Wednesday, June 6, 2007 3:26 pm Justin Piszcz wrote:
Nope, I booted with only netconsole= options. I have a lot of HW in
the box and I guess the buffer is too small. Not sure where to
change it in the kernel. Looking..
It's called "kerne
On Wed, 6 Jun 2007, Randy Dunlap wrote:
On Wed, 6 Jun 2007 15:28:43 -0700 Jesse Barnes wrote:
On Wednesday, June 6, 2007 3:26 pm Justin Piszcz wrote:
Nope, I booted with only netconsole= options. I have a lot of HW in
the box and I guess the buffer is too small. Not sure where to
change
On Wed, 6 Jun 2007, Randy Dunlap wrote:
On Wed, 6 Jun 2007 15:28:43 -0700 Jesse Barnes wrote:
On Wednesday, June 6, 2007 3:26 pm Justin Piszcz wrote:
Nope, I booted with only netconsole= options. I have a lot of HW in
the box and I guess the buffer is too small. Not sure where to
change
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On Wednesday, June 6, 2007 3:26 pm Justin Piszcz wrote:
Nope, I booted with only netconsole= options. I have a lot of HW in
the box and I guess the buffer is too small. Not sure where to
change it in the kernel. Looking..
It's called "kerne
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On Wednesday, June 6, 2007 3:26 pm Justin Piszcz wrote:
Nope, I booted with only netconsole= options. I have a lot of HW in
the box and I guess the buffer is too small. Not sure where to
change it in the kernel. Looking..
It's called "kerne
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On Wednesday, June 6, 2007 3:13 pm Justin Piszcz wrote:
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On Wednesday, June 6, 2007 3:03 pm Justin Piszcz wrote:
Mem: 8039620k total, 7936472k used, 103148k free, 708k
buffers Mem: 8039608k total
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On Wednesday, June 6, 2007 3:03 pm Justin Piszcz wrote:
Mem: 8039620k total, 7936472k used, 103148k free, 708k
buffers Mem: 8039608k total, 969380k used, 7070228k free,
1232k buffers
I am curious, why does the patch != the mem=8832M
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On Wednesday, June 6, 2007 3:03 pm Justin Piszcz wrote:
Mem: 8039620k total, 7936472k used, 103148k free, 708k
buffers Mem: 8039608k total, 969380k used, 7070228k free,
1232k buffers
I am curious, why does the patch != the mem=8832M
Mem: 8039620k total, 7936472k used, 103148k free, 708k buffers
Mem: 8039608k total, 969380k used, 7070228k free, 1232k buffers
I am curious, why does the patch != the mem=8832M?
Justin.
On Wed, 6 Jun 2007, Justin Piszcz wrote:
On Wed, 6 Jun 2007, Jesse Barnes wrote
1. I use netconsole on almost all of my machines.
2. When I reboot one of them, it sends the kernel messages to the console
logging server.
3. However, whenever I reboot it spams the console and every xterm open
with the following:
Message from [EMAIL PROTECTED] at Wed Jun 6 17:43:10 2007
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On some machines, buggy BIOSes don't properly setup WB MTRRs to
cover all available RAM, meaning the last few megs (or even gigs)
of memory will be marked uncached. Since Linux tends to allocate
from high memory addresses first, this causes the machine
Will give it a shot.
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On Wednesday, June 6, 2007 1:37 pm Justin Piszcz wrote:
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On Wednesday, June 6, 2007 1:28 pm Jesse Barnes wrote:
Against what kernel version does this patch apply?
Um... git
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On Wednesday, June 6, 2007 1:28 pm Jesse Barnes wrote:
Against what kernel version does this patch apply?
Um... git as of b4946ffb1860597b187d78d61ac6504177eb0ff8. Sorry I
should have updated before spinning the patch (will do now).
Appears to
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On some machines, buggy BIOSes don't properly setup WB MTRRs to
cover all available RAM, meaning the last few megs (or even gigs)
of memory will be marked uncached. Since Linux tends to allocate
from high memory addresses first, this causes the machine
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On some machines, buggy BIOSes don't properly setup WB MTRRs to
cover all available RAM, meaning the last few megs (or even gigs)
of memory will be marked uncached. Since Linux tends to allocate
from high memory addresses first, this causes the machine
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On Wednesday, June 6, 2007 1:28 pm Jesse Barnes wrote:
Against what kernel version does this patch apply?
Um... git as of b4946ffb1860597b187d78d61ac6504177eb0ff8. Sorry I
should have updated before spinning the patch (will do now).
Appears to
Will give it a shot.
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On Wednesday, June 6, 2007 1:37 pm Justin Piszcz wrote:
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On Wednesday, June 6, 2007 1:28 pm Jesse Barnes wrote:
Against what kernel version does this patch apply?
Um... git
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On some machines, buggy BIOSes don't properly setup WB MTRRs to
cover all available RAM, meaning the last few megs (or even gigs)
of memory will be marked uncached. Since Linux tends to allocate
from high memory addresses first, this causes the machine
1. I use netconsole on almost all of my machines.
2. When I reboot one of them, it sends the kernel messages to the console
logging server.
3. However, whenever I reboot it spams the console and every xterm open
with the following:
Message from [EMAIL PROTECTED] at Wed Jun 6 17:43:10 2007
Mem: 8039620k total, 7936472k used, 103148k free, 708k buffers
Mem: 8039608k total, 969380k used, 7070228k free, 1232k buffers
I am curious, why does the patch != the mem=8832M?
Justin.
On Wed, 6 Jun 2007, Justin Piszcz wrote:
On Wed, 6 Jun 2007, Jesse Barnes wrote
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On Wednesday, June 6, 2007 3:03 pm Justin Piszcz wrote:
Mem: 8039620k total, 7936472k used, 103148k free, 708k
buffers Mem: 8039608k total, 969380k used, 7070228k free,
1232k buffers
I am curious, why does the patch != the mem=8832M
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On Wednesday, June 6, 2007 3:03 pm Justin Piszcz wrote:
Mem: 8039620k total, 7936472k used, 103148k free, 708k
buffers Mem: 8039608k total, 969380k used, 7070228k free,
1232k buffers
I am curious, why does the patch != the mem=8832M
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On Wednesday, June 6, 2007 3:13 pm Justin Piszcz wrote:
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On Wednesday, June 6, 2007 3:03 pm Justin Piszcz wrote:
Mem: 8039620k total, 7936472k used, 103148k free, 708k
buffers Mem: 8039608k total
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On Wednesday, June 6, 2007 3:26 pm Justin Piszcz wrote:
Nope, I booted with only netconsole= options. I have a lot of HW in
the box and I guess the buffer is too small. Not sure where to
change it in the kernel. Looking..
It's called kernel log
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On Wednesday, June 6, 2007 3:26 pm Justin Piszcz wrote:
Nope, I booted with only netconsole= options. I have a lot of HW in
the box and I guess the buffer is too small. Not sure where to
change it in the kernel. Looking..
It's called kernel log
On Wed, 6 Jun 2007, Randy Dunlap wrote:
On Wed, 6 Jun 2007 15:28:43 -0700 Jesse Barnes wrote:
On Wednesday, June 6, 2007 3:26 pm Justin Piszcz wrote:
Nope, I booted with only netconsole= options. I have a lot of HW in
the box and I guess the buffer is too small. Not sure where to
change
On Wed, 6 Jun 2007, Randy Dunlap wrote:
On Wed, 6 Jun 2007 15:28:43 -0700 Jesse Barnes wrote:
On Wednesday, June 6, 2007 3:26 pm Justin Piszcz wrote:
Nope, I booted with only netconsole= options. I have a lot of HW in
the box and I guess the buffer is too small. Not sure where to
change
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On Wednesday, June 6, 2007 3:26 pm Justin Piszcz wrote:
Nope, I booted with only netconsole= options. I have a lot of HW in
the box and I guess the buffer is too small. Not sure where to
change it in the kernel. Looking..
It's called kernel log
301 - 400 of 692 matches
Mail list logo
