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 of=file.ou
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_secto
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
patch
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 unsub
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 inf
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 fi
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
pa
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
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 w
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 m
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 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,
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
Short Description of Problem:
Linux 2.6.21.3 does not run properly with 8GB of ram on the Intel 965WH
motherboard.
Long Description of Problem:
When I use 8GB of memory on my x86_64 system, CPU-bound processes are VERY
slow, up to 36x slower than usual. My temporary fix is force Linux to only
On Tue, 29 May 2007, Robert Hancock wrote:
Justin Piszcz wrote:
Short Description of Problem:
Linux 2.6.21.3 does not run properly with 8GB of ram on the Intel 965WH
motherboard.
Long Description of Problem:
When I use 8GB of memory on my x86_64 system, CPU-bound processes are VERY
slow
On Wed, 30 May 2007, Justin Piszcz wrote:
On Tue, 29 May 2007, Robert Hancock wrote:
Justin Piszcz wrote:
Short Description of Problem:
Linux 2.6.21.3 does not run properly with 8GB of ram on the Intel 965WH
motherboard.
I found it interesting in make menuconfig on x86_64 there is no
On Wed, 30 May 2007, Zoltan Boszormenyi wrote:
Hi,
Look at how slow the raid benchmarks are in dmesg with 8GB of memory!
[ 59.592560] raid6: using algorithm sse2x4 (476 MB/s)
[ 59.597558] raid5: using function: generic_sse (56.000 MB/sec)
Yikes!
With mem=4096M:
[ 60.336352] raid6: u
On Wed, 30 May 2007, Justin Piszcz wrote:
On Wed, 30 May 2007, Zoltan Boszormenyi wrote:
Hi,
Look at how slow the raid benchmarks are in dmesg with 8GB of memory!
[ 59.592560] raid6: using algorithm sse2x4 (476 MB/s)
[ 59.597558] raid5: using function: generic_sse (56.000 MB/sec
Yes, you are correct, the netconsole output from another machine is shown
below. If we can access the memory directly, why is it so slow? :( Am I
the first person to try using 8 gigabytes of RAM on the 965 chipset?
On Wed, 30 May 2007, Robert Hancock wrote:
Justin Piszcz wrote:
Kernel
On Wed, 30 May 2007, Robert Hancock wrote:
Parag Warudkar wrote:
Robert Hancock wrote:
0-3319MB
4096-8832MB
leaving 64MB of memory at the top of RAM uncached. What do you want to
bet that something important (kernel code?) is getting loaded there..
So essentially it's a BIOS problem, it'
On Thu, 31 May 2007, Parag Warudkar wrote:
Robert Hancock wrote:
I think that mem=8832M would work as well, to make the kernel use only the
memory that is marked cacheable. (It looks like this parameter takes the
highest memory address we want the kernel to use, not the highest memory
amoun
On Thu, 31 May 2007, Robert Hancock wrote:
Justin Piszcz wrote:
On Thu, 31 May 2007, Parag Warudkar wrote:
Robert Hancock wrote:
I think that mem=8832M would work as well, to make the kernel use only
the memory that is marked cacheable. (It looks like this parameter takes
the highest
On Wed, 30 May 2007, Robert Hancock wrote:
Parag Warudkar wrote:
Robert Hancock wrote:
0-3319MB
4096-8832MB
leaving 64MB of memory at the top of RAM uncached. What do you want to
bet that something important (kernel code?) is getting loaded there..
So essentially it's a BIOS problem, it'
On Fri, 1 Jun 2007, Justin Piszcz wrote:
On Wed, 30 May 2007, Robert Hancock wrote:
Parag Warudkar wrote:
Robert Hancock wrote:
0-3319MB
4096-8832MB
leaving 64MB of memory at the top of RAM uncached. What do you want to
bet that something important (kernel code?) is getting loaded
On Fri, 1 Jun 2007, Justin Piszcz wrote:
On Fri, 1 Jun 2007, Justin Piszcz wrote:
On Wed, 30 May 2007, Robert Hancock wrote:
Parag Warudkar wrote:
Robert Hancock wrote:
0-3319MB
4096-8832MB
leaving 64MB of memory at the top of RAM uncached. What do you want to
bet that something
n syslog/dmesg: Only using 7.7GB because your BIOS is
using 64MB for other purposes, re-mapping kernel into higher memory..
Any comments?
Per Robert below:
Justin Piszcz wrote:
That output looked nasty, attaching entries from syslog.
Justin.
Here's your E820 memory map, from dmesg:
B
On Fri, 1 Jun 2007, Jesse Barnes wrote:
and the MTRRs (from /proc/mtrr, from private email):
reg00: base=0x ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x8000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc000 (3072MB), size= 256MB: write-back, count=1
re
It works ok on
my machine (correctly detects the condition, adjusts end_pfn, and keeps
the machine fast), aside from the fact that X won't start.
But X won't start? :\
On Fri, 1 Jun 2007, Jesse Barnes wrote:
and the MTRRs (from /proc/mtrr, from private email):
reg00: base=0x ( 0MB),
On Fri, 1 Jun 2007, Andi Kleen wrote:
Jesse Barnes <[EMAIL PROTECTED]> writes:
(or we get proper PAT support, which I think would make this problem
go away as well).
No it won't. If the basic MTRRs for memory are wrong just having PAT support
in drivers (which already exist in a limited fo
On Fri, 1 Jun 2007, Andi Kleen wrote:
1. The MCH/ICH8 hub 'requires' a minimum of 512MB to run, the board manual
states it needs at least 512MB of memort.
2. The DVT/IGP graphics uses either 128MB or 256MB, I have it set to
128MB.
How can the Linux kernel find this out/poll this information s
On Fri, 1 Jun 2007, Jesse Barnes wrote:
On Friday, June 1, 2007 6:05:39 Venki Pallipadi wrote:
On Fri, Jun 01, 2007 at 02:41:57PM -0700, Jesse Barnes wrote:
On Friday, June 1, 2007 2:19:43 Andi Kleen wrote:
And normally the MTRRs win, don't they (if I remember the table
correctly) So if the
On Sat, 2 Jun 2007, Andi Kleen wrote:
I feel, having a silent/transparent workaround is not a good idea. With that
If enough RAM is chopped off users will notice. They tend to complain
when they miss RAM. I don't like panic very much because for many
users it will be a show stopper (even wh
Wondering as their were a lot of XFS related issues early on in
development..? The 2.6.22-rc3 kernel has the core 2 duo coretemp patch by
ruik which I want be running as long as 2.6.22-rc3 does not have any
severe XFS issues?
Justin.
-
To unsubscribe from this list: send the line "unsubscribe
On Sat, 2 Jun 2007, Christian Kujau wrote:
On Sat, 2 Jun 2007, Justin Piszcz wrote:
Wondering as their were a lot of XFS related issues early on in
development..? The 2.6.22-rc3 kernel has the core 2 duo coretemp patch by
ruik which I want be running as long as 2.6.22-rc3 does not have any
Kujau wrote:
On Sat, 2 Jun 2007, Justin Piszcz wrote:
Wondering as their were a lot of XFS related issues early on in
development..? The 2.6.22-rc3 kernel has the core 2 duo coretemp patch by
ruik which I want be running as long as 2.6.22-rc3 does not have any severe
XFS issues?
Tracking -r
I use nut-2.0.4-4 with a UPS attached via USB and from 2.6.21.3 ->
2.6.22-rc3 it stops working, see below. My .config is attached.
2.6.21.3:
p34:~# /lib/nut/newhidups -u nut -DD auto
Checking device (050D/0912) (005/002)
- VendorID: 050d
- ProductID: 0912
- Manufacturer:
- Product: UPS
- S
On Sat, 2 Jun 2007, Jeremy Fitzhardinge wrote:
Justin Piszcz wrote:
Wondering as their were a lot of XFS related issues early on in
development..? The 2.6.22-rc3 kernel has the core 2 duo coretemp patch
by ruik which I want be running as long as 2.6.22-rc3 does not have
any severe XFS issues
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] -> GS
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 the
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&l2=39&l3=299&l4=0&model=1210&modelmenu=2
)
Hard Drives: 3x Sea
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, 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 Sun, 3 Jun 2007, Christian Kujau wrote:
On Sat, 2 Jun 2007, Justin Piszcz wrote:
On Sat, 2 Jun 2007, Jeremy Fitzhardinge wrote:
XFS currently has a data-corrupting bug, where files which were appended
by small amounts may lose their updates on umount - I see this
corrupting hg repos
On Sun, 3 Jun 2007, Jeremy Fitzhardinge wrote:
Michal Piotrowski wrote:
It's already merged into mainline
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=df3c7244264f1d12562413aa32d56be802486516
Oh, good. I hadn't read through the last couple of days of commit
On Sun, 3 Jun 2007, Jiri Kosina wrote:
On Sat, 2 Jun 2007, Justin Piszcz wrote:
p34:~# /lib/nut/newhidups -u nut -DD auto
Checking device (050D/0912) (005/002)
- VendorID: 050d
- ProductID: 0912
- Manufacturer: unknown
- Product: unknown
- Serial Number: unknown
- Bus: 005
Trying to
On Sun, 3 Jun 2007, Jiri Kosina wrote:
On Sun, 3 Jun 2007, Justin Piszcz wrote:
Sure, they are attached:
$ du -sh nut*
4.0Knut-bad.txt.bz2 (2.6.22-rc3)
12K nut-good.txt.bz2 (2.6.21.3)
Let me know if they are of any use.
Thanks. Does by any chance reverting
the commit
On Sun, 3 Jun 2007, Jiri Kosina wrote:
On Sun, 3 Jun 2007, Justin Piszcz wrote:
Thanks. Does by any chance reverting the commit
9f8b17e643fe6aa505629658445849397bda4e4f improve the situation?
I have not played around with git/etc enough to back it out, if you have a
patch that applies on
On Sun, 3 Jun 2007, Oliver Neukum wrote:
Am Sonntag, 3. Juni 2007 12:36 schrieb Justin Piszcz:
On Sun, 3 Jun 2007, Jiri Kosina wrote:
On Sat, 2 Jun 2007, Justin Piszcz wrote:
failed to claim USB device, trying 2 more time(s)...
detaching kernel driver from USB device...
Could you
On Sun, 3 Jun 2007, Kay Sievers wrote:
On 6/3/07, Justin Piszcz <[EMAIL PROTECTED]> wrote:
On Sun, 3 Jun 2007, Jiri Kosina wrote:
> On Sun, 3 Jun 2007, Justin Piszcz wrote:
>
>>> Thanks. Does by any chance reverting the commit
>>> 9f8b17e643fe6aa5056296
On Sun, 3 Jun 2007, Justin Piszcz wrote:
On Sun, 3 Jun 2007, Kay Sievers wrote:
On 6/3/07, Justin Piszcz <[EMAIL PROTECTED]> wrote:
On Sun, 3 Jun 2007, Jiri Kosina wrote:
> On Sun, 3 Jun 2007, Justin Piszcz wrote:
>
>>> Thanks. Does by any chance
On Mon, 4 Jun 2007, Ray Lee wrote:
On 6/4/07, Jesse Barnes <[EMAIL PROTECTED]> wrote:
On Sunday, June 3, 2007 2:15:06 Matt Keenan wrote:
> Justin Piszcz wrote:
> > On Sat, 2 Jun 2007, Andi Kleen wrote:
> >>> I feel, having a silent/transparent workaround is not a
On Mon, 4 Jun 2007, Eric W. Biederman wrote:
Jesse Barnes <[EMAIL PROTECTED]> writes:
On Friday, June 1, 2007 2:19:43 Andi Kleen wrote:
And normally the MTRRs win, don't they (if I remember the table correctly)
So if the MTRR says UC and PAT disagrees it might not actually help
I just che
On Mon, 4 Jun 2007, Justin Piszcz wrote:
On Mon, 4 Jun 2007, Eric W. Biederman wrote:
Jesse Barnes <[EMAIL PROTECTED]> writes:
On Friday, June 1, 2007 2:19:43 Andi Kleen wrote:
And normally the MTRRs win, don't they (if I remember the table
correctly)
So if the MTRR says
On Tue, 5 Jun 2007, Andi Kleen wrote:
So the only safe thing we can do is not use memory that is not
write-back cached. That we can positively detect and is a
conservative action so if anything will work that will.
Jesse wrote such a patch (or rather it limitted end_pfn), but it broke
the X
I am using stock cooling in a well ventilated case, I was wondering if
these temps are normal, e.g. I see this in dmesg:
[ 60.505648] coretemp coretemp.0: Using undocumented features, absolute
temperature might be wrong!
[ 60.505792] coretemp coretemp.1: Using undocumented features, absolut
2.6.22-rc4.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
USB
Subject: Unable to get HID descriptor (error sending control message:
Operation not permitted)
References : http://lkml.org/lkml/2007/6/2/153
Submitter : Justin Piszcz <[EM
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 appl
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 as of
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
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 "
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 "
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 "
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 be
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 the
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 le
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 memor
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 memory
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 f
t using the 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/
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 chunk
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
w
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 arch/i386
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 ch
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 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 ma
DISCLAIMER: This patch is still experimental.
AUTHOR: Rudolf Marek has written the coretemp module for Intel Core Duo/Solo
processors.
Without this patch, you cannot monitor your CPU temperature, at least not
on a DG965 motherboard.
From the readme (second patch):
+Kernel driver coretemp
+==
http://kerneltrap.org/node/8176
I am a mdadm/disk/hard drive fanatic, I was curious:
On i386, we can at most fit 256 scatterlist elements into a page,
and on x86-64 we are stuck with 128. So that puts us somewhere
between 512kb and 1024kb for a single IO.
How come 32bit is 256 and 64 is only
Without NCQ, performance is MUCH better on almost every operation, with
the exception of 2-3 items.
/usr/sbin/bonnie++ -d /x/bonnie -s 7952 -m p34 -n 16:10:16:64 > run.txt;
# Average of 3 runs with NCQ on for Quad Raptor ADFD 150 RAID 5 Software RAID:
p34-ncq-on,7952M,43916.3,96.6667,151943
Had a quick question, this is the first time I have seen this happen, and
it was not even under during heavy I/O, hardly anything was going on with
the box at the time.
Any idea what could have caused this? I am running a badblocks test right
now, but so far the disk looks OK.
[369143.91609
On Thu, 5 Apr 2007, Justin Piszcz wrote:
Had a quick question, this is the first time I have seen this happen, and it
was not even under during heavy I/O, hardly anything was going on with the
box at the time.
.. snip ..
# /usr/bin/time badblocks -b 512 -s -v -w /dev/sdl
Checking for bad
http://www.ussg.iu.edu/hypermail/linux/kernel/0701.3/0315.html
I have similar issues as this poster-- I was wondering (if anyone) had an
idea to the root cause of this issue; is it a problem with the chipset,
the BIOS revision?
Mobo: Intel DG965WHMKR
BIOS: 1666
Is it only Intel Chipsets that
On Thu, 5 Apr 2007, Justin Piszcz wrote:
http://www.ussg.iu.edu/hypermail/linux/kernel/0701.3/0315.html
I have similar issues as this poster-- I was wondering (if anyone) had an
idea to the root cause of this issue; is it a problem with the chipset, the
BIOS revision?
Mobo: Intel
On Thu, 5 Apr 2007, Justin Piszcz wrote:
On Thu, 5 Apr 2007, Justin Piszcz wrote:
http://www.ussg.iu.edu/hypermail/linux/kernel/0701.3/0315.html
I have similar issues as this poster-- I was wondering (if anyone) had an
idea to the root cause of this issue; is it a problem with the
On Thu, 5 Apr 2007, Justin Piszcz wrote:
http://www.ussg.iu.edu/hypermail/linux/kernel/0701.3/0315.html
Here is the badblocks output:
p34:~# /usr/bin/time badblocks -b 512 -s -v -w /dev/sdl
Checking for bad blocks in read-write mode
From block 0 to 293046768
Testing with pattern 0xaa
My .config is attached.. I cannot reproduce this problem, it only happened
once, but I want to find out how to make sure it does not happen again.
On Thu, 5 Apr 2007, Justin Piszcz wrote:
On Thu, 5 Apr 2007, Justin Piszcz wrote:
http://www.ussg.iu.edu/hypermail/linux/kernel/0701.3/0315
On Mon, 5 Feb 2007, Justin Piszcz wrote:
On Mon, 5 Feb 2007, Arjan van de Ven wrote:
On Sun, 2007-02-04 at 10:57 -0500, Justin Piszcz wrote:
Hi,
Anyone from Intel that reads LKML, could you provide an update as to what
is happening with support for your HECI Controller/QPS chip, which
On Sat, 24 Mar 2007, Alan Cox wrote:
On Sat, 24 Mar 2007 12:38:02 -0400 (EDT)
Justin Piszcz <[EMAIL PROTECTED]> wrote:
Without NCQ, performance is MUCH better on almost every operation, with
the exception of 2-3 items.
It depends on the drive. Generally NCQ is better but some
I ran a check on my SW RAID devices this morning. However, when I did so,
I had a few lftp sessions open pulling files. After I executed the check,
the lftp processes entered 'D' state and I could do 'nothing' in the
process until the check finished. Is this normal? Should a check block
all
On Tue, 27 Mar 2007, Tejun Heo wrote:
Justin Piszcz wrote:
Checking the benchmarks on various hardware websites, anandtech,
hothardware and others, they generally all come to the same conclusion if
there is only 1 thread using I/O (single user system) then NCQ off is the
best.
Are they
201 - 300 of 353 matches
Mail list logo
