On Tue, Nov 17, 2020 at 1:01 AM Heiner Kallweit wrote:
>
> Am 17.11.2020 um 08:43 schrieb Chris Snook:
> > The full text of the preceding comment explains the need:
> >
> > /*
> > * The atl1c chip can DMA to 64-bit addresses, but it uses a single
> > * shar
The full text of the preceding comment explains the need:
/*
* The atl1c chip can DMA to 64-bit addresses, but it uses a single
* shared register for the high 32 bits, so only a single, aligned,
* 4 GB physical address range can be used at a time.
*
* Supporting 64-bit DMA on this hardware is
On Fri, Jun 21, 2019 at 11:33 AM Joe Perches wrote:
>
> On Fri, 2019-06-21 at 13:12 -0500, Bjorn Helgaas wrote:
> > On Fri, Jun 21, 2019 at 12:27 PM Joe Perches wrote:
> []
> > > Subsystem specific local PCI #defines without generic
> > > naming is poor style and makes treewide grep and
> > >
"Qualcomm Atheros Inc., ");
> -MODULE_DESCRIPTION("Qualcom Atheros 100/1000M Ethernet Network Driver");
> +MODULE_DESCRIPTION("Qualcomm Atheros 100/1000M Ethernet Network Driver");
> MODULE_LICENSE("GPL");
> MODULE_VERSION(ATL1C_DRV_VERSION)
., nic-de...@qualcomm.com);
-MODULE_DESCRIPTION(Qualcom Atheros 100/1000M Ethernet Network Driver);
+MODULE_DESCRIPTION(Qualcomm Atheros 100/1000M Ethernet Network Driver);
MODULE_LICENSE(GPL);
MODULE_VERSION(ATL1C_DRV_VERSION);
Acked-by: Chris Snook chris.sn...@gmail.com
--
To unsubscribe from
Andre Noll wrote:
we are experiencing massive performance problems with two of our
Linux servers that contain 3ware controllers on a Tyan mainboard and
a couple of 1T disks.
During the daily cron job that uses rsync to sync a 500G file system
from another machine to the raid on the 3ware
Andre Noll wrote:
we are experiencing massive performance problems with two of our
Linux servers that contain 3ware controllers on a Tyan mainboard and
a couple of 1T disks.
During the daily cron job that uses rsync to sync a 500G file system
from another machine to the raid on the 3ware
From: Chris Snook <[EMAIL PROTECTED]>
Make MARKERS depend on MODULES to prevent build failures with certain configs.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
diff --git a/init/Kconfig b/init/Kconfig
index dcef8b5..933df15 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -
From: Chris Snook <[EMAIL PROTECTED]>
Make LKDTM depend on BLOCK to prevent build failures with certain configs.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index a370fe8..24b327c 100644
--- a/lib/Kconfig.debug
+++ b/lib/K
From: Chris Snook [EMAIL PROTECTED]
Make LKDTM depend on BLOCK to prevent build failures with certain configs.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index a370fe8..24b327c 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -524,6
From: Chris Snook [EMAIL PROTECTED]
Make MARKERS depend on MODULES to prevent build failures with certain configs.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
diff --git a/init/Kconfig b/init/Kconfig
index dcef8b5..933df15 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -729,6 +729,7 @@ config
Tony Breeds wrote:
On Thu, Feb 14, 2008 at 08:24:27PM -0500, Chris Snook wrote:
Stephen Rothwell wrote:
Hi all,
Initial status can be seen here
http://kisskb.ellerman.id.au/kisskb/branch/9/ (I hope to make a better
URL soon). Suggestions for more compiler/config combinations are
welcome
Stephen Rothwell wrote:
Hi all,
Initial status can be seen here
http://kisskb.ellerman.id.au/kisskb/branch/9/ (I hope to make a better
URL soon). Suggestions for more compiler/config combinations are
welcome, but we can't necessarily commit to fulfilling all you
wishes. :-)
i386
Stephen Rothwell wrote:
Hi all,
Initial status can be seen here
http://kisskb.ellerman.id.au/kisskb/branch/9/ (I hope to make a better
URL soon). Suggestions for more compiler/config combinations are
welcome, but we can't necessarily commit to fulfilling all you
wishes. :-)
i386
Tony Breeds wrote:
On Thu, Feb 14, 2008 at 08:24:27PM -0500, Chris Snook wrote:
Stephen Rothwell wrote:
Hi all,
Initial status can be seen here
http://kisskb.ellerman.id.au/kisskb/branch/9/ (I hope to make a better
URL soon). Suggestions for more compiler/config combinations are
welcome
Dhaval Giani wrote:
I am getting the following oops on bootup on 2.6.25-rc1
...
I am booting using kexec with maxcpus=1. It does not have any problems
with maxcpus=2 or higher.
Sounds like another (the same?) kexec cpu numbering bug. Can you
post/link the entire dmesg from both a cold boot
Dhaval Giani wrote:
I am getting the following oops on bootup on 2.6.25-rc1
...
I am booting using kexec with maxcpus=1. It does not have any problems
with maxcpus=2 or higher.
Sounds like another (the same?) kexec cpu numbering bug. Can you
post/link the entire dmesg from both a cold boot
Gene Heskett wrote:
Greetings;
I just rebooted to a new config of 2.6.24, basically trying to strip out the
building of modules I don't use. And I enabled a couple of checks that
weren't checked in the kernel-hacking menu. .config posted on request.
Now the messages log is being spammed
veerasena reddy wrote:
I have a requirement where i need to execute a user process even when
the kernel is utilizing 100% of CPU time.
In the realtime kernel, hardware interrupt handlers are prioritized
threads, so you can give the userspace process a higher realtime priority.
--
veerasena reddy wrote:
I have a requirement where i need to execute a user process even when
the kernel is utilizing 100% of CPU time.
In the realtime kernel, hardware interrupt handlers are prioritized
threads, so you can give the userspace process a higher realtime priority.
--
Gene Heskett wrote:
Greetings;
I just rebooted to a new config of 2.6.24, basically trying to strip out the
building of modules I don't use. And I enabled a couple of checks that
weren't checked in the kernel-hacking menu. .config posted on request.
Now the messages log is being spammed
Lars Noschinski wrote:
Hello!
For an university project, we had to write a toy filesystem (ext2-like),
for which I would like to implement sparse file support. For this, I
digged through the ext2 source code; but I could not find the point,
where ext2 detects holes.
As far as I can see from
Yinghai Lu wrote:
On Jan 31, 2008 12:33 AM, Chris Snook <[EMAIL PROTECTED]> wrote:
Yinghai Lu wrote:
why not rename relocs.c to relocs_32.c?
Because we're trying to get rid of all the _32 and _64 files?
but that file is not need for x86_64
Which means there's no conflict with any
Yinghai Lu wrote:
why not rename relocs.c to relocs_32.c?
Because we're trying to get rid of all the _32 and _64 files?
-- Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Yinghai Lu wrote:
why not rename relocs.c to relocs_32.c?
Because we're trying to get rid of all the _32 and _64 files?
-- Chris
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Yinghai Lu wrote:
On Jan 31, 2008 12:33 AM, Chris Snook [EMAIL PROTECTED] wrote:
Yinghai Lu wrote:
why not rename relocs.c to relocs_32.c?
Because we're trying to get rid of all the _32 and _64 files?
but that file is not need for x86_64
Which means there's no conflict with any 64-bit
Lars Noschinski wrote:
Hello!
For an university project, we had to write a toy filesystem (ext2-like),
for which I would like to implement sparse file support. For this, I
digged through the ext2 source code; but I could not find the point,
where ext2 detects holes.
As far as I can see from
Gene Heskett wrote:
Greetings all;
This line showed up in my log a couple of hours ago, several minutes removed
from anything else I was doing at the time:
rarian-sk-get-c[31855]: segfault at eip 00b7c153 esp bf9ddf0c error 4
The system acts and feels normal.
Does anyone have a
While pondering ways to optimize I/O and swapping on large NUMA machines, I
noticed that the numa_node field in struct device isn't actually used anywhere.
We just have a couple dozen lines of code to conditionally create a sysfs file
that will always return -1. Is anyone even working on code
While pondering ways to optimize I/O and swapping on large NUMA machines, I
noticed that the numa_node field in struct device isn't actually used anywhere.
We just have a couple dozen lines of code to conditionally create a sysfs file
that will always return -1. Is anyone even working on code
Al Boldi wrote:
Greetings!
data=ordered mode has proven reliable over the years, and it does this by
ordering filedata flushes before metadata flushes. But this sometimes
causes contention in the order of a 10x slowdown for certain apps, either
due to the misuse of fsync or due to inherent
this one any better?
This satisfies me.
Acked-by: Chris Snook <[EMAIL PROTECTED]>
From df475e2eea401f9dc18ca23dab538b99fb9e710c Mon Sep 17 00:00:00 2001
From: Jay Cliburn <[EMAIL PROTECTED]>
Date: Wed, 23 Jan 2008 21:36:36 -0600
Subject: [PATCH] atl1: simplify tx packet descriptor
The tr
Al Boldi wrote:
Greetings!
data=ordered mode has proven reliable over the years, and it does this by
ordering filedata flushes before metadata flushes. But this sometimes
causes contention in the order of a 10x slowdown for certain apps, either
due to the misuse of fsync or due to inherent
?
This satisfies me.
Acked-by: Chris Snook [EMAIL PROTECTED]
From df475e2eea401f9dc18ca23dab538b99fb9e710c Mon Sep 17 00:00:00 2001
From: Jay Cliburn [EMAIL PROTECTED]
Date: Wed, 23 Jan 2008 21:36:36 -0600
Subject: [PATCH] atl1: simplify tx packet descriptor
The transmit packet descriptor
Jay Cliburn wrote:
On Tue, 22 Jan 2008 04:56:11 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
From: Jay Cliburn <[EMAIL PROTECTED]>
Update initialization parameters to match the current vendor driver
version 1.2.40.2.
[...]
ACK without any better knowledge... but
Jay Cliburn wrote:
On Tue, 22 Jan 2008 04:56:11 -0500
Jeff Garzik [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
From: Jay Cliburn [EMAIL PROTECTED]
Update initialization parameters to match the current vendor driver
version 1.2.40.2.
[...]
ACK without any better knowledge... but is
Vineet Gupta wrote:
I'm trying to implement atomic ops for a CPU which has no inherent
support for Read-Modify-Write Ops. Instead of using a global spin lock
which protects all the atomic APIs, I want to use a spin lock per
instance of atomic_t.
What operations are you using to implement
Vineet Gupta wrote:
I'm trying to implement atomic ops for a CPU which has no inherent
support for Read-Modify-Write Ops. Instead of using a global spin lock
which protects all the atomic APIs, I want to use a spin lock per
instance of atomic_t.
What operations are you using to implement
Martin Knoblauch wrote:
Hi,
currently I am tracking down an "interesting" effect when writing to a
Solars-10/Sparc based server. The server exports two filesystems. One UFS,
one VXFS. The filesystems are mounted NFS3/TCP, no special options. Linux
kernel in question is 2.6.24-rc6, but it
Martin Knoblauch wrote:
Hi,
currently I am tracking down an interesting effect when writing to a
Solars-10/Sparc based server. The server exports two filesystems. One UFS,
one VXFS. The filesystems are mounted NFS3/TCP, no special options. Linux
kernel in question is 2.6.24-rc6, but it happens
Joe Perches wrote:
drivers/net/atl1/atl1_hw.c |2 +-
drivers/net/atl1/atl1_main.c |2 +-
The atl1 code will be heavily reworked in the 2.6.25 merge window, so this may
cause headaches. Please remove these chunks before merging.
The spelling
Joe Perches wrote:
drivers/net/atl1/atl1_hw.c |2 +-
drivers/net/atl1/atl1_main.c |2 +-
The atl1 code will be heavily reworked in the 2.6.25 merge window, so this may
cause headaches. Please remove these chunks before merging.
The spelling
Muhammad Nowbuth wrote:
Hi all,
Could anyone give some ideas of future pending works which are needed
on the linux kernel?
http://kernelnewbies.org/KernelHacking
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Muhammad Nowbuth wrote:
Hi all,
Could anyone give some ideas of future pending works which are needed
on the linux kernel?
http://kernelnewbies.org/KernelHacking
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
Ben Crowhurst wrote:
Has Objective-C ever been considered for kernel development?
No. Kernel programming requires what is essentially assembly language with a
lot of syntactic sugar, which C provides. Higher-level languages abstract away
too much detail to be suitable for the sort of
Ben Crowhurst wrote:
Has Objective-C ever been considered for kernel development?
No. Kernel programming requires what is essentially assembly language with a
lot of syntactic sugar, which C provides. Higher-level languages abstract away
too much detail to be suitable for the sort of
H. Peter Anvin wrote:
NOTE: This patch uses a bc(1) script to compute the appropriate
constants.
Perhaps dc would be more appropriate? That's included in busybox.
-- Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
H. Peter Anvin wrote:
NOTE: This patch uses a bc(1) script to compute the appropriate
constants.
Perhaps dc would be more appropriate? That's included in busybox.
-- Chris
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
CTED]>
Cc: Chris Snook <[EMAIL PROTECTED]>
Acked-By: Chris Snook <[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
Snook [EMAIL PROTECTED]
Acked-By: Chris Snook [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/
[EMAIL PROTECTED] wrote:
Linux version 2.4.9-e.38smp ([EMAIL PROTECTED]) (gcc
version 2.96 2731 (Red Hat Linux 7.2 2.96-124.7.2)) #1 SMP Wed Feb
11 00:09:01 EST 2004
Ancient vendor kernels are very out of scope for this mailing list. The
following links may be useful:
[EMAIL PROTECTED] wrote:
Linux version 2.4.9-e.38smp ([EMAIL PROTECTED]) (gcc
version 2.96 2731 (Red Hat Linux 7.2 2.96-124.7.2)) #1 SMP Wed Feb
11 00:09:01 EST 2004
Ancient vendor kernels are very out of scope for this mailing list. The
following links may be useful:
Florian Boelstler wrote:
While running that test driver a delay of about 10ms _exactly_ occurs
every 10 minutes.
This is precisely the sort of thing that BIOS/firmware-level SMI handlers do,
particularly those that have monitoring or management features. Try to
determine if the kernel is
Florian Boelstler wrote:
While running that test driver a delay of about 10ms _exactly_ occurs
every 10 minutes.
This is precisely the sort of thing that BIOS/firmware-level SMI handlers do,
particularly those that have monitoring or management features. Try to
determine if the kernel is
Yoav Artzi wrote:
According to my knowledge the PAGE_SIZE on 32bit architectures in 4KB.
Logically, the PAGE_SIZE on 64bit architectures should be 8KB. That's at
least the way I understand it. However, looking at the kernel code of
x86_64, I see the PAGE_SIZE is 4KB.
Can anyone explain to
Yoav Artzi wrote:
According to my knowledge the PAGE_SIZE on 32bit architectures in 4KB.
Logically, the PAGE_SIZE on 64bit architectures should be 8KB. That's at
least the way I understand it. However, looking at the kernel code of
x86_64, I see the PAGE_SIZE is 4KB.
Can anyone explain to
ciol wrote:
Chris Snook wrote:
Why are you asking the developers? We do this for the sake of the users.
The kernel is the software of the developers.
The kernel is a technology. A distribution is a product. When decisions about
technology and decisions about products are made
Benny Halevy wrote:
Greetings,
I would like to hear peoples opinion about the indentation convention
described below that I personally found the most practical with
several different editors.
The gist of it is that tabs should be used for nesting, not for decoration.
Indent your code with as
ciol wrote:
Hi, I'd like to ask you a few questions:
* Do you like the way linux distributions integrate the kernel?
* Wouldn't you prefer they ship with the stable and still maintained
2.6.16.X, while providing optionally the latest kernel for those who
want or just have a new hardware?
*
ciol wrote:
Hi, I'd like to ask you a few questions:
* Do you like the way linux distributions integrate the kernel?
* Wouldn't you prefer they ship with the stable and still maintained
2.6.16.X, while providing optionally the latest kernel for those who
want or just have a new hardware?
*
Benny Halevy wrote:
Greetings,
I would like to hear peoples opinion about the indentation convention
described below that I personally found the most practical with
several different editors.
The gist of it is that tabs should be used for nesting, not for decoration.
Indent your code with as
ciol wrote:
Chris Snook wrote:
Why are you asking the developers? We do this for the sake of the users.
The kernel is the software of the developers.
The kernel is a technology. A distribution is a product. When decisions about
technology and decisions about products are made
Don Porter wrote:
From: Donald E. Porter <[EMAIL PROTECTED]>
In the bulk page allocation/free routines in mm/page_alloc.c, the zone
lock is held across all iterations. For certain parallel workloads, I
have found that releasing and reacquiring the lock for each iteration
yields better
Don Porter wrote:
From: Donald E. Porter [EMAIL PROTECTED]
In the bulk page allocation/free routines in mm/page_alloc.c, the zone
lock is held across all iterations. For certain parallel workloads, I
have found that releasing and reacquiring the lock for each iteration
yields better
Zurk Tech wrote:
dmesg (new) with disabled GART error reporting if anyone wants to
compare to previous dmesg with GART error reporting :
A few unrelated observations about Barcelona support...
Marking TSC unstable due to TSCs unsynchronized
This is probably wrong. The TSC is on the
Zurk Tech wrote:
dmesg (new) with disabled GART error reporting if anyone wants to
compare to previous dmesg with GART error reporting :
A few unrelated observations about Barcelona support...
Marking TSC unstable due to TSCs unsynchronized
This is probably wrong. The TSC is on the
Latchesar Ionkov wrote:
Sample ramfs file server that uses the in-kernel 9P file server support.
This code is for reference only.
Reference code generally goes in Documentation/
-- Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Latchesar Ionkov wrote:
Sample ramfs file server that uses the in-kernel 9P file server support.
This code is for reference only.
Reference code generally goes in Documentation/
-- Chris
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
Zurk Tech wrote:
Hi guys,
I have a tyan s3992 h2000 with single barcelona amd quad core cpu (the
other cpu socket is empty). cat /proc/cpuinfo shows amd quad core
processor
but core : 1ive compiled the kernel from scratch with smp and
amd64 + the numa stuff. i also tried debian etchs amd64
Zurk Tech wrote:
Hi guys,
I have a tyan s3992 h2000 with single barcelona amd quad core cpu (the
other cpu socket is empty). cat /proc/cpuinfo shows amd quad core
processor
but core : 1ive compiled the kernel from scratch with smp and
amd64 + the numa stuff. i also tried debian etchs amd64
From: Chris Snook <[EMAIL PROTECTED]>
Unify x86 div64.h headers.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
diff -Nurp a/include/asm-x86/div64_32.h b/include/asm-x86/div64_32.h
--- a/include/asm-x86/div64_32.h2007-10-20 07:33:53.0 -0400
+++ b/include/asm-x8
From: Chris Snook <[EMAIL PROTECTED]>
Unify x86 a.out_32.h and a.out_64.h
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
diff -Nurp a/include/asm-x86/a.out_32.h b/include/asm-x86/a.out_32.h
--- a/include/asm-x86/a.out_32.h2007-10-20 06:20:01.0 -0400
+++ b/inc
From: Chris Snook <[EMAIL PROTECTED]>
Merge mmu_32.h and mmu_64.h into mmu.h.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
diff -Nurp a/include/asm-x86/mmu_32.h b/include/asm-x86/mmu_32.h
--- a/include/asm-x86/mmu_32.h 2007-10-20 02:42:24.0 -0400
+++ b/include/asm-x86/mm
From: Chris Snook [EMAIL PROTECTED]
Merge mmu_32.h and mmu_64.h into mmu.h.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
diff -Nurp a/include/asm-x86/mmu_32.h b/include/asm-x86/mmu_32.h
--- a/include/asm-x86/mmu_32.h 2007-10-20 02:42:24.0 -0400
+++ b/include/asm-x86/mmu_32.h 1969-12
From: Chris Snook [EMAIL PROTECTED]
Unify x86 a.out_32.h and a.out_64.h
Signed-off-by: Chris Snook [EMAIL PROTECTED]
diff -Nurp a/include/asm-x86/a.out_32.h b/include/asm-x86/a.out_32.h
--- a/include/asm-x86/a.out_32.h2007-10-20 06:20:01.0 -0400
+++ b/include/asm-x86/a.out_32.h
From: Chris Snook [EMAIL PROTECTED]
Unify x86 div64.h headers.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
diff -Nurp a/include/asm-x86/div64_32.h b/include/asm-x86/div64_32.h
--- a/include/asm-x86/div64_32.h2007-10-20 07:33:53.0 -0400
+++ b/include/asm-x86/div64_32.h
From: Chris Snook <[EMAIL PROTECTED]>
Most of types_32.h and types_64.h are the same. Merge the common definitions
into types.h, keeping the differences in their own files. Also #error if
types_{32,64}.h is included directly. Tested with allmodconfig on x86_64.
Signed-off-by: Chris
From: Chris Snook [EMAIL PROTECTED]
Most of types_32.h and types_64.h are the same. Merge the common definitions
into types.h, keeping the differences in their own files. Also #error if
types_{32,64}.h is included directly. Tested with allmodconfig on x86_64.
Signed-off-by: Chris Snook [EMAIL
Konstantin Kalin wrote:
P.S. It's simple to add DEV_HAS_CORRECT_MACADDR to pci_device_tlb for
these types of Ethernet. But I think it's not right decision because it
would break older revisions of these models.
Any reason you can't distinguish based on PCI ID?
-- Chris
-
To
Konstantin Kalin wrote:
P.S. It's simple to add DEV_HAS_CORRECT_MACADDR to pci_device_tlb for
these types of Ethernet. But I think it's not right decision because it
would break older revisions of these models.
Any reason you can't distinguish based on PCI ID?
-- Chris
-
To
Pavel Machek wrote:
Hi!
I've found that gbit vs. 100mbit power consumption difference is about
1W -- pretty significant. (Maybe powertop should include it in the
tips section? :).
Energy Star people insist that machines should switch down to 100mbit
when network is idle, and I guess that makes
Pavel Machek wrote:
Hi!
I've found that gbit vs. 100mbit power consumption difference is about
1W -- pretty significant. (Maybe powertop should include it in the
tips section? :).
Energy Star people insist that machines should switch down to 100mbit
when network is idle, and I guess that makes
Giuliano Gagliardi wrote:
Hello,
I have a server that has to switch to different user ids, but because it does
other complex things, I would rather not have it run as root.
Well, it's probably going to have to *start* as root, or use something like
sudo. It's probably easiest to have it
Giuliano Gagliardi wrote:
Hello,
I have a server that has to switch to different user ids, but because it does
other complex things, I would rather not have it run as root.
Well, it's probably going to have to *start* as root, or use something like
sudo. It's probably easiest to have it
Justin Piszcz wrote:
Kernel: 2.6.23-rc8 (older kernels do this as well)
When running the following command:
/usr/bin/time /usr/sbin/bonnie++ -d /x/test -s 16384 -m p34 -n
16:10:16:64
It hangs unless I increase various parameters md/raid such as the
stripe_cache_size etc..
# ps auxww |
Justin Piszcz wrote:
Kernel: 2.6.23-rc8 (older kernels do this as well)
When running the following command:
/usr/bin/time /usr/sbin/bonnie++ -d /x/test -s 16384 -m p34 -n
16:10:16:64
It hangs unless I increase various parameters md/raid such as the
stripe_cache_size etc..
# ps auxww |
from the
declaration of atomic64_t. The following patch fixes that inconsistency,
without delving into anything more controversial.
From: Chris Snook <[EMAIL PROTECTED]>
The volatile keyword has already been removed from the declaration of atomic_t
on x86_64. For consistency, remove i
from the
declaration of atomic64_t. The following patch fixes that inconsistency,
without delving into anything more controversial.
From: Chris Snook [EMAIL PROTECTED]
The volatile keyword has already been removed from the declaration of atomic_t
on x86_64. For consistency, remove it from
David Madore wrote:
On Mon, Sep 17, 2007 at 11:11:52AM -0700, Jeremy Fitzhardinge wrote:
Boot memtest86 for a little while before booting the kernel? And if you
haven't already run it for a while, then that would be your first step
anyway.
Indeed, that does the trick, thanks for the
David Madore wrote:
On Mon, Sep 17, 2007 at 11:11:52AM -0700, Jeremy Fitzhardinge wrote:
Boot memtest86 for a little while before booting the kernel? And if you
haven't already run it for a while, then that would be your first step
anyway.
Indeed, that does the trick, thanks for the
Lukas Hejtmanek wrote:
Hello,
is it expected that application sending 8900bytes datagram through 10Gbps NIC
utilizes CPU to 100% and similarly the receiver also utilizes CPU to 100%.
Is it something wrong or this is quite OK?
(The box is dual single core Opteron 2.4GHz with Myricom 10GE NIC.)
Lukas Hejtmanek wrote:
Hello,
is it expected that application sending 8900bytes datagram through 10Gbps NIC
utilizes CPU to 100% and similarly the receiver also utilizes CPU to 100%.
Is it something wrong or this is quite OK?
(The box is dual single core Opteron 2.4GHz with Myricom 10GE NIC.)
Venkat Subbiah wrote:
Since most network devices have a single status register for both
receiver and transmit (and errors and the like), which needs a lock to
protect access, you will likely end up with serious thrashing of moving
the lock between cpus.
Any ways to measure the trashing of
From: Chris Snook <[EMAIL PROTECTED]>
The volatile keyword has already been removed from the declaration of atomic_t
on x86_64. For consistency, remove it from atomic64_t as well.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- a/include/asm-x86_64/atomic.h 2007
Jesse Barnes wrote:
I just narrowed down a weird problem where I was losing more than 50% of
my vblank interrupts to what seems to be the hires timers patch. Stock
2.6.23-rc5 works fine, but the latest (171) kernel from rawhide drops
most of my interrupts unless I also have another interrupt
Jesse Barnes wrote:
I just narrowed down a weird problem where I was losing more than 50% of
my vblank interrupts to what seems to be the hires timers patch. Stock
2.6.23-rc5 works fine, but the latest (171) kernel from rawhide drops
most of my interrupts unless I also have another interrupt
From: Chris Snook [EMAIL PROTECTED]
The volatile keyword has already been removed from the declaration of atomic_t
on x86_64. For consistency, remove it from atomic64_t as well.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- a/include/asm-x86_64/atomic.h 2007-07-08 19:32:17.0
Venkat Subbiah wrote:
Since most network devices have a single status register for both
receiver and transmit (and errors and the like), which needs a lock to
protect access, you will likely end up with serious thrashing of moving
the lock between cpus.
Any ways to measure the trashing of
Venkat Subbiah wrote:
Most of the load in my system is triggered by a single ethernet IRQ.
Essentially the IRQ schedules a tasklet and most of the work is done in the
taskelet which is scheduled in the IRQ. From what I read looks like the
tasklet would be executed on the same CPU on which it was
Venkat Subbiah wrote:
Most of the load in my system is triggered by a single ethernet IRQ.
Essentially the IRQ schedules a tasklet and most of the work is done in the
taskelet which is scheduled in the IRQ. From what I read looks like the
tasklet would be executed on the same CPU on which it was
1 - 100 of 488 matches
Mail list logo
