On Mon, 2008-01-21 at 13:29 -0800, Arjan van de Ven wrote:
> On Mon, 21 Jan 2008 13:20:46 -0800
> Harvey Harrison <[EMAIL PROTECTED]> wrote:
>
> > Introduce printk_address to X86_32 in a simplified form for
> > now. Reformat X86_64 printk_address to avoid two declarations.
> >
> > Change the
On Mon, 21 Jan 2008 13:20:46 -0800
Harvey Harrison <[EMAIL PROTECTED]> wrote:
> Introduce printk_address to X86_32 in a simplified form for
> now. Reformat X86_64 printk_address to avoid two declarations.
>
> Change the printk formats on X86_32 and 64 to be similar.
I'm not entirely convinced
This will help when unifying the oops dumping code on 32/64
bit. No functional changes.
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
arch/x86/mm/fault_32.c | 54 ++-
arch/x86/mm/fault_64.c | 21 --
2 files changed, 44
> You have removed the code that checked if the peer or
> master mount was in the same namespace before reporting their
> corresponding mount-ids. One downside of that approach is the
> user will see an mount_id in the output with no corresponding
> line to explain
The struct module taints member is supposed to store per-module taint
data. The kernel knows about certain specific external modules that will
taint the kernel, such as ndiswrapper. Use of ndiswrapper possibly
should set the per-module taint in addition to the global kernel
taint flag, unless
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> On mount propagation, let the owner of the clone be inherited from the
> parent into which it has been propagated.
>
> If the parent has the "nosuid" flag, set this flag for the child as
> well. This is
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Add the following:
>
> /proc/sys/fs/types/${FS_TYPE}/usermount_safe
>
> Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
> ---
>
> Index: linux/fs/filesystems.c
>
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Don't require the "user_id=" and "group_id=" options for unprivileged mounts,
> but if they are present, verify them for sanity.
>
> Disallow the "allow_other" option for unprivileged mounts.
>
> FUSE was
On Sun, 2008-01-20 at 20:30 +0200, Mika Penttilä wrote:
> > + * This is how much memory *in addition to the memory covered up to
> > + * and including _end* we need mapped initially. We need one bit for
> > + * each possible page, but only in low memory, which means
> > + * 2^32/4096/8 = 128K
On 01/21/2008 03:47 PM, Chuck Ebbert wrote:
> Looking at the oops report from this bug:
>
> [bugzilla] https://bugzilla.redhat.com/show_bug.cgi?id=429412
> [oops] https://bugzilla.redhat.com/attachment.cgi?id=292260
>
> It was an unhandled page fault (protection violation.)
>
> I tracked
Introduce printk_address to X86_32 in a simplified form for
now. Reformat X86_64 printk_address to avoid two declarations.
Change the printk formats on X86_32 and 64 to be similar.
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
Ingo, this changes oops printing format, consider this just
Eduardo Pereira Habkost wrote:
+ .pud_clear = native_pud_clear,
On the patches I will send, pud_clear() and pgd_clear() aren't present
on pv_mmu_ops and are implemented using set_pud() and set_pgd().
Actually, I changed my mind on that. pud_clear needs special handling
with
Change the size of node ids for X86_64 from u8 to s16 to
accomodate more than 32k nodes and allow for NUMA_NO_NODE
(-1) to be sign extended to int.
Based on 2.6.24-rc8-mm1 + latest (08/1/21) git-x86
Cc: David Rientjes <[EMAIL PROTECTED]>
Cc: Yinghai Lu <[EMAIL PROTECTED]>
Cc: Eric Dumazet
Change the following static arrays sized by NR_CPUS to
per_cpu data variables:
char cpu_to_node_map[NR_CPUS];
Based on 2.6.24-rc8-mm1 + latest (08/1/21) git-x86
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
Reviewed-by: Christoph Lameter <[EMAIL PROTECTED]>
---
fixup:
- Split
Provide a means to trap usages of per_cpu map variables before
they are setup. Define CONFIG_DEBUG_PER_CPU_MAPS to activate.
Based on 2.6.24-rc8-mm1 + latest (08/1/21) git-x86
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
include/asm-x86/topology.h | 13 ++---
1 file changed, 2
Provide a means to discover usages of per_cpu map variables before
they are setup. Define CONFIG_DEBUG_PER_CPU_MAPS to activate.
Based on 2.6.24-rc8-mm1
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
Fixup:
- for cpu_to_node() instead of panic'ing with BUG() use
dump_stack and
Fixup change NR_CPUS patchset by rebasing on 2.6.24-rc8-mm1
from 2.6.24-rc6-mm1) and adding changes suggested by reviews.
Based on 2.6.24-rc8-mm1 + latest (08/1/21) git-x86
Note there are two versions of this patchset:
- 2.6.24-rc8-mm1
- 2.6.24-rc8-mm1 + latest (08/1/21) git-x86
Change the size of node ids for X86_64 from u8 to s16 to
accomodate more than 32k nodes and allow for NUMA_NO_NODE
(-1) to be sign extended to int.
Based on 2.6.24-rc8-mm1
Cc: David Rientjes <[EMAIL PROTECTED]>
Cc: Yinghai Lu <[EMAIL PROTECTED]>
Cc: Eric Dumazet <[EMAIL PROTECTED]>
Change the following static arrays sized by NR_CPUS to
per_cpu data variables:
char cpu_to_node_map[NR_CPUS];
Based on 2.6.24-rc8-mm1
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
Reviewed-by: Christoph Lameter <[EMAIL PROTECTED]>
---
fixup:
- Split cpu_to_node function into "early"
Change static bios_cpu_apicid array to a per_cpu data variable.
This includes using a static array used during initialization
similar to the way x86_cpu_to_apicid[] is handled.
There is one early use of bios_cpu_apicid in apic_is_clustered_box().
The other reference in cpu_present_to_apicid() is
Fixup change NR_CPUS patchset by rebasing on 2.6.24-rc8-mm1
(from 2.6.24-rc6-mm1) and adding changes suggested by reviews.
Based on 2.6.24-rc8-mm1
Note there are two versions of this patchset:
- 2.6.24-rc8-mm1
- 2.6.24-rc8-mm1 + latest (08/1/21) git-x86
Signed-off-by: Mike
On Mon, 21 Jan 2008, Dave Young wrote:
> Please see the kernel messages following,(trigged while using some qemu
> session)
> BTW, seems there's some e100 error message as well.
>
> PCI: Setting latency timer of device :00:1b.0 to 64
> e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
>
Dave Young wrote, On 01/21/2008 09:44 AM:
...
> I applied it in my kernel, built and run without warnings, but it need
> more testing.
> I will be very glad to see the test result about this if you could, thanks.
Bad news. (Alas I won't be able to check this today.)
Chris Friesen wrote:
Is there anything else we can do to minimize the latency of network
packet processing and avoid having to crank the rx ring size up so high?
Why is it such a big deal to crank up the rx queue length? Seems like
a perfectly normal way to handle bursts like this...
With Linux 2.6.24-rc8 I often have the problem that the pan usenet
reader starts using 100% of CPU time after some time. When this happens,
kill -9 does not work, and strace just hangs when trying to attach to
the process. The same with gdb. ps shows the process as being in the R
state.
I
On Mon, Jan 21, 2008 at 09:31:17PM +0100, Sam Ravnborg wrote:
> On Mon, Jan 21, 2008 at 12:27:54AM +0200, Adrian Bunk wrote:
> > On Sun, Jan 20, 2008 at 09:05:27PM +0100, Sam Ravnborg wrote:
> > >...
> > > Adrian reminded us that KCFLAGS=-fno-inline told
> > > another story with more than 100
Hello,
I'm interested in making a driver for the Kinesis Savant Elite Programable
USB Foot Switches[1]. Is there any way for me to check that such driver
doesn't exists already? I've searched a bit on the internet and I couldn't
find anything, but if there's somewhere else to look at before
On Sat, Jan 19, 2008 at 04:19:09PM -0200, Marcelo Tosatti wrote:
> On Fri, Jan 18, 2008 at 03:20:15PM -0200, Glauber de Oliveira Costa wrote:
> > Hi,
> >
> > This small series provides some more fixes towards the goal
> > to have the PARAVIRT selectable for x86_64. After that, just
> > some more
Looking at the oops report from this bug:
[bugzilla] https://bugzilla.redhat.com/show_bug.cgi?id=429412
[oops] https://bugzilla.redhat.com/attachment.cgi?id=292260
It was an unhandled page fault (protection violation.)
I tracked it down to the cmpxchg in this code:
RDMA/cxgb3: Mark qp as privileged based on user capabilities.
This is needed for zero-stag support.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/cxio_wr.h |3 ++-
drivers/infiniband/hw/cxgb3/iwch_qp.c |1 +
2 files changed, 3 insertions(+), 1
RDMA/cxgb3: Flush the RQ when closing.
- for kernel mode cqs, call event notification handler when flushing
- flush qp when moving from RTS -> CLOSING
- fixed logic to identify a kernel mode qp
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/iwch_qp.c |7
RDMA/cxgb3: fix page shift calculation in build_phys_page_list()
The existing logic incorrectly maps this buffer list:
0: addr 0x10001000, size 0x1000
1: addr 0x10002000, size 0x1000
To this bogus page list:
0: 0x1000
1: 0x10002000
The shift calculation must also take into account the
Hey Roland,
Please include these three iw_cxgb3 fixes for 2.6.25. The first two fix
bugs found doing Lustre testing, and the last patch correctly marks
privileged qps.
Shortlog:
RDMA/cxgb3: Flush the RQ when closing.
RDMA/cxgb3: fix page shift calculation in build_phys_page_list()
RDMA/cxgb3: Flush the RQ when closing.
- for kernel mode cqs, call event notification handler when flushing
- flush qp when moving from RTS -> CLOSING
- fixed logic to identify a kernel mode qp
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/iwch_qp.c |7
RDMA/cxgb3: fix page shift calculation in build_phys_page_list()
The existing logic incorrectly maps this buffer list:
0: addr 0x10001000, size 0x1000
1: addr 0x10002000, size 0x1000
To this bogus page list:
0: 0x1000
1: 0x10002000
The shift calculation must also take into account the
RDMA/cxgb3: Mark qp as privileged based on user capabilities.
This is needed for zero-stag support.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/cxio_wr.h |3 ++-
drivers/infiniband/hw/cxgb3/iwch_qp.c |1 +
2 files changed, 3 insertions(+), 1
On Mon, Jan 21, 2008 at 12:27:54AM +0200, Adrian Bunk wrote:
> On Sun, Jan 20, 2008 at 09:05:27PM +0100, Sam Ravnborg wrote:
> >...
> > Adrian reminded us that KCFLAGS=-fno-inline told
> > another story with more than 100 Section mismatch
> > warnings on 64 bit x86 with an allyesconfig build.
>
Powerpc has a way to determine the address of the per cpu area of the
currently executing processor via the paca and the array of per cpu
offsets is avoided by looking up the per cpu area from the remote
paca's (copying x86_64).
Based on 2.6.24-rc8-mm1 + latest (08/1/21) git-x86
Cc: Paul
Provide a means to trap usages of per_cpu variables before
the per_cpu_areas are setup. Define CONFIG_DEBUG_PER_CPU to activate.
Based on 2.6.24-rc8-mm1 + latest (08/1/21) git-x86
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
include/asm-generic/percpu.h | 11 ++-
ia64 has a special processor specific mapping that can be used to locate the
offset for the current per cpu area.
Based on 2.6.24-rc8-mm1 + latest (08/1/21) git-x86
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL
Change s390 percpu.h to use asm-generic/percpu.h
Based on 2.6.24-rc8-mm1 + latest (08/1/21) git-x86
Cc: [EMAIL PROTECTED]
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
rc8-mm1-fixup:
- rebased from 2.6.24-rc6-mm1 to 2.6.24-rc8-mm1
percpu_modcopy() is defined multiple times in arch files. However, the only
user is module.c. Put a static definition into module.c and remove
the definitions from the arch files.
Based on 2.6.24-rc8-mm1 + latest (08/1/21) git-x86
Cc: David Miller <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL
Sparc64 has a way of providing the base address for the per cpu area of the
currently executing processor in a global register.
Sparc64 also provides a way to calculate the address of a per cpu area
from a base address instead of performing an array lookup.
Based on 2.6.24-rc8-mm1 + latest
Change the Kconfig variable used to indicate that x86 has it's
own per_cpu area setup routine.
Based on 2.6.24-rc8-mm1 + latest (08/1/21) git-x86
Cc: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
Fixup:
Change s390 percpu.h to use asm-generic/percpu.h
Based on: 2.6.24-rc8-mm1
Cc: [EMAIL PROTECTED]
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
rc8-mm1-fixup:
- rebased from 2.6.24-rc6-mm1 to 2.6.24-rc8-mm1
(removed changes that are
This patchset simplifies the code that arches need to maintain to support
per cpu functionality. Most of the code is moved into arch independent
code. Only a minimal set of definitions is kept for each arch.
The patch also unifies the x86 arch so that there is only a single
asm-x86/percpu.h
Sparc64 has a way of providing the base address for the per cpu area of the
currently executing processor in a global register.
Sparc64 also provides a way to calculate the address of a per cpu area
from a base address instead of performing an array lookup.
Based on: 2.6.24-rc8-mm1
Cc: David
Change "config ARCH_SETS_UP_PER_CPU_AREA" to "select
HAVE_SETUP_PER_CPU_AREA" as suggested by Sam.
Based on: 2.6.24-rc8-mm1
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: Sam Ravnborg <[EMAIL PROTECTED]>
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
This patchset simplifies the code that arches need to maintain to support
per cpu functionality. Most of the code is moved into arch independent
code. Only a minimal set of definitions is kept for each arch.
The patch also unifies the x86 arch so that there is only a single
asm-x86/percpu.h
percpu_modcopy() is defined multiple times in arch files. However, the only
user is module.c. Put a static definition into module.c and remove
the definitions from the arch files.
Based on: 2.6.24-rc8-mm1
Cc: David Miller <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Andi Kleen
Powerpc has a way to determine the address of the per cpu area of the
currently executing processor via the paca and the array of per cpu
offsets is avoided by looking up the per cpu area from the remote
paca's (copying x86_64).
Based on: 2.6.24-rc8-mm1
Cc: Paul Mackerras <[EMAIL PROTECTED]>
ia64 has a special processor specific mapping that can be used to locate the
offset for the current per cpu area.
Based on: 2.6.24-rc8-mm1
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
Provide a means to trap usages of per_cpu variables before
the per_cpu_areas are setup. Define CONFIG_DEBUG_PER_CPU to activate.
Based on: 2.6.24-rc8-mm1
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
rc8-mm1-fixup:
- rebased from 2.6.24-rc6-mm1 to 2.6.24-rc8-mm1
(removed changes that
Define the size of the generic percpu pointers array to be NR_CPUS
Based on: 2.6.24-rc8-mm1
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
include/linux/percpu.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
What's up for v2.6.25 for the x86 architecture code.
There are 763 commits in x86.git so far, from more than 90 contributors,
so it would be difficult to mention and credit every contribution in
this mail. See the shortlog attached further below for more details.
Here's an (incomplete) list
On Monday 21 January 2008 11:14:02 am Justin Piszcz wrote:
>
> On Mon, 21 Jan 2008, Jesse Barnes wrote:
>
> > On Sunday, January 20, 2008 10:56 pm Yinghai Lu wrote:
> >> [PATCH] x86_32: trim memory by updating e820 v2
> >>
> >> when mtrr is not covering all e820 table, need to trim the ram, need
I've done some further digging, and it appears that one of the problems
we may be facing is very high instantaneous traffic rates.
Instrumentation showed up to 222K packets/sec for short periods (at
least 1.1 ms, possibly longer), although the long-term average is down
around 14-16K
On Monday 21 January 2008, Peter Zijlstra wrote:
>
> On Fri, 2008-01-18 at 14:29 -0800, David Brownell wrote:
> > EXPERIMENTAL and incomplete patch to make LOCKDEP behave better in
> > the face of irq chaining, by annotating irqs with a lock_class which
> > can reflect that hierarchy.
>
> This
Miklos,
You have removed the code that checked if the peer or
master mount was in the same namespace before reporting their
corresponding mount-ids. One downside of that approach is the
user will see an mount_id in the output with no corresponding
line to
On Mon, 21 Jan 2008, Jesse Barnes wrote:
On Sunday, January 20, 2008 10:56 pm Yinghai Lu wrote:
[PATCH] x86_32: trim memory by updating e820 v2
when mtrr is not covering all e820 table, need to trim the ram, need to
update e820
reuse some code for x86_64
here need to add
On 01/09/2008 11:11 AM, Jiri Kosina wrote:
On Wed, 9 Jan 2008, Jiri Slaby wrote:
BUG: soft lockup - CPU#1 stuck for 11s! [X:2887]
[ ... ]
Call Trace:
[] __mutex_lock_slowpath+0x38/0xd0
[] mutex_lock+0x1e/0x30
[] input_release_device+0x27/0x50
[] evdev_ungrab+0x3a/0x50
[]
From: Arjan van de Ven <[EMAIL PROTECTED]>
Subject: sched: Keep total / count stats in addition to the max for wait time
Right now, the linux kernel (with scheduler statistics enabled) keeps track
of the maximum time a process is waiting to be scheduled. While the maximum
is a very useful metric,
On Mon, Jan 21, 2008 at 11:38:38AM +1100, Rusty Russell wrote:
> On Sunday 20 January 2008 08:25:49 Sam Ravnborg wrote:
> > On Sat, Jan 19, 2008 at 11:56:43AM -0800, Randy Dunlap wrote:
> > > rcu_online_cpu() should be __cpuinit instead of __devinit.
> >
> > So if we have:
> > CONFIG_HOTPLUG=n
> >
Andi Kleen wrote:
This patch changes all flushes in init_64.c to be __flush_tlb_all()
and fixes the problem here.
Hmm, I see new early crashes with that patch here in some cases unfortunately:
PANIC: early exception 06 rip 10:8082df2d error 0 cr2 0
Pid: 0, comm: swapper Not
On Mon, Jan 21, 2008 at 12:43:25PM -0600, Matt Mackall wrote:
> This conflicts just about everywhere with my latest code, but I'll fix
> that up.
Great, thanks.
Jeff
--
Work email - jdike at linux dot intel dot com
--
To unsubscribe from this list: send the line "unsubscribe
(Gerd Knorr cc'ed because 'git blame' says he last touched the line of code
I ended up touching - if this needs other cc:'s, will somebody who knows who
should review please add them?)
On Thu, 17 Jan 2008 02:35:14 PST, Andrew Morton said:
>
>
> Actually, I think it depends on the specific MSR - some use the halves
> for different data, whereas others treat it as a large 64-bit object.
Even if there are different fields in there it is still much cleaner
and simpler if there is only a single number to manipulate.
> Ironically
On Mon, 2008-01-21 at 13:18 -0500, Jeff Dike wrote:
> Add async notification support to /dev/random.
This conflicts just about everywhere with my latest code, but I'll fix
that up.
--
Mathematics is the supreme nostalgia of our time.
--
To unsubscribe from this list: send the line
Jordan Crouse schrieb:
> On 20/01/08 14:22 +0100, Arnd Hannemann wrote:
>> Hi,
>>
>> Jordan Crouse wrote:
>>> On 17/01/08 23:52 +0100, Arnd Hannemann wrote:
>> Watchdog for the new API would be great :-)
> Coming soon.
>>> As promised, a watchdog driver for the Geode GX/LX processors is
On Jan 21, 2008 7:15 PM, Jean Delvare <[EMAIL PROTECTED]> wrote:
> Hi Felipe,
>
> On Thu, 3 Jan 2008 11:59:56 -0500, Felipe Balbi wrote:
> > Based on David Brownell's patch for tps65010, this patch
> > starts converting isp1301_omap.c to new-style i2c driver.
> >
> > Signed-off-by: Felipe Balbi
...avec le mini agenda maxi pratique My Small Notes c'est gratuit !
Découvrez le sur le site http://www.mysmallnotes.com et vive le logiciel libre.
Le webmaster.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
On Thu, 17 Jan 2008 02:35:14 PST, Andrew Morton said:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc8/2.6.24-rc8-mm1/
>
> - selinux is busted on one of my two selinux-enabled test machines.
This problem is fixed in Paul Moore's latest spin of the networking patches -
On Thu, 17 Jan 2008, Patrick J. LoPresti wrote:
> I need to copy large (> 100GB) files between machines on a fast
> network. Both machines have reasonably fast disk subsystems, with
> read/write performance benchmarked at > 800 MB/sec. Using 10GigE cards
> and the usual tweaks to tcp_rmem etc.,
Add async notification support to /dev/random.
A little test case is below. Without this patch, you get:
$ ./async-random
Drained the pool
Found more randomness
With it, you get:
$ ./async-random
Drained the pool
SIGIO
Found more randomness
#include
#include
#include
#include
#include
On Sun, Jan 20, 2008 at 05:10:01PM +0100, Linus Nilsson wrote:
> From: Linus Nilsson <[EMAIL PROTECTED]>
>
> Change two occurances of "behavour" to "behaviour".
Thanks, applied.
Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Cyrill Gorcunov wrote:
[Andi Kleen - Mon, Jan 21, 2008 at 07:03:27PM +0100]
|
| > is it possible to change 'l' and 'h' to 'low' and 'high'?
| > 'cause 'l' does look like '1' (one) number...
|
| It would be fine for me for someone to implement safe_rdtscll() and get rid
| of l and h
[Andi Kleen - Mon, Jan 21, 2008 at 07:03:27PM +0100]
|
| > is it possible to change 'l' and 'h' to 'low' and 'high'?
| > 'cause 'l' does look like '1' (one) number...
|
| It would be fine for me for someone to implement safe_rdtscll() and get rid
| of l and h everywhere. IMHO all the l and h
...avec le mini agenda maxi pratique My Small Notes c'est gratuit !
Découvrez le sur le site http://www.mysmallnotes.com et vive le logiciel libre.
Le webmaster.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
...avec le mini agenda maxi pratique My Small Notes cest gratuit !
Découvrez le sur le site http://www.mysmallnotes.com et vive le logiciel libre.
Le webmaster.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
> is it possible to change 'l' and 'h' to 'low' and 'high'?
> 'cause 'l' does look like '1' (one) number...
It would be fine for me for someone to implement safe_rdtscll() and get rid
of l and h everywhere. IMHO all the l and h accesses of MSRs are just harder
to read and error prone over the ll
Hi all!
commit in mainline 10a0a8d4e3f6bf2d077f9431909abe670f5a is go in
the satble 2.6.22
the grund for this question is http://hup.hu/node/49773 .
--
Thanks,
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
On 20/01/08 14:22 +0100, Arnd Hannemann wrote:
> Hi,
>
> Jordan Crouse wrote:
> > On 17/01/08 23:52 +0100, Arnd Hannemann wrote:
> Watchdog for the new API would be great :-)
> >>> Coming soon.
> >
> > As promised, a watchdog driver for the Geode GX/LX processors is attached.
> > I
[H. Peter Anvin - Mon, Jan 21, 2008 at 09:39:16AM -0800]
> Cyrill Gorcunov wrote:
>> is it possible to change 'l' and 'h' to 'low' and 'high'?
>> 'cause 'l' does look like '1' (one) number...
>
> I think you should use a different font. Otherwise we're soon in a
> position where we can't
Cyrill Gorcunov wrote:
is it possible to change 'l' and 'h' to 'low' and 'high'?
'cause 'l' does look like '1' (one) number...
I think you should use a different font. Otherwise we're soon in a
position where we can't abbreviate anything that starts with L and keep
using lower case
> I still don't think it's worth the trouble. There's currently only one
> reported device which forgets to raise IRQ on media error. The behavior
Most people wouldn't realise what is going on.
> > Old IDE says it works for PATA. For SATA I can see it might need more
> > care and you might
[Andrew Morton - Fri, Jan 18, 2008 at 02:00:55PM -0800]
| On Fri, 14 Dec 2007 13:54:59 -0800 (PST)
| [EMAIL PROTECTED] wrote:
|
| > http://bugzilla.kernel.org/show_bug.cgi?id=9564
| >
| >Summary: Uninitialzed variable fields cvt.h_margin and
| > cvt.v_margin
| >
[Yinghai Lu - Sun, Jan 20, 2008 at 10:57:46PM -0800]
| [PATCH] x86_64: check if Tom2 is enabled
|
| need to applied after andi's amd special tom2 wb check patch
|
| in amd_special_default_mtrr need to check if TOM2 is enabled
|
| Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
|
| diff --git
Hi Felipe,
On Thu, 3 Jan 2008 11:59:56 -0500, Felipe Balbi wrote:
> Based on David Brownell's patch for tps65010, this patch
> starts converting isp1301_omap.c to new-style i2c driver.
>
> Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
> ---
> drivers/i2c/chips/isp1301_omap.c | 60
On Mon, 2008-01-21 at 08:26 -0800, Linda Walsh wrote:
> Peter Zijlstra wrote:
> > On Fri, 2008-01-18 at 17:17 -0800, Linda Walsh wrote:
> >
> >> On my x86_64 machine, I got the following message
> >> in log (kern = 2.6.23.14)
> >>
> >> Jan 16 04:08:38 Astara kernel: BUG: MAX_LOCK_DEPTH too
> It's a first shot so it might not yet be perfect - although so far it
> looks good in testing on 4-5 testsystems here, on mixed 64-bit and
> 32-bit boxes. Doing it this way was a pretty straightforward process, it
> took less than an hour - and the end result feels much better in terms
> of
On Sun, Jan 20, 2008 at 09:03:38AM +0530, Dhaval Giani wrote:
> > btw: writing 1 into "cpu_share" totally locks up the computer!
> >
>
> Can you please provide some more details. Can you go into another
> console (try ctrl-alt-f1) and try to reproduce the issue there. Could
> you take a photo of
Alan Cox wrote:
>> Can you elaborate a bit? I don't really think completing a command
>> after 30sec timeout contributes a lot to driver stability.
>
> Timeout, timeout, timeout, reset, timeout.. (repeat), failed I/O
>
> This gives the end user no information about the fault, nor does it let
>
The http://www.kerneloops.org website collects kernel oops and
warning reports from various mailing lists and bugzillas as well as
with a client users can install to auto-submit oopses.
Below is a top 9 list of the oopses collected in the last 7 days.
(Reports prior to 2.6.23 have been omitted in
> Can you elaborate a bit? I don't really think completing a command
> after 30sec timeout contributes a lot to driver stability.
Timeout, timeout, timeout, reset, timeout.. (repeat), failed I/O
This gives the end user no information about the fault, nor does it let
the upper layers of SCSI and
> Just a data point, even ICHs lock up after PHY event if the wrong TF
> register is accessed. I just don't think tempting with TF regs after
> timeout is worth the cost.
For SATA maybe, for PATA I don't have any controllers with your bug so
its wrong for libata to cripple the PATA support or
Matthias Wolle gmx.de> writes:
>
> Hi,
>
> my company is running several servers with kernel 2.6.23.12. This are Dual
> Quad Core servers (CPU Intel) with 16GB RAM using a 32Bit kernel.
This is a common problem with running 32-bit kernels with more than 8Gb RAM.
(Search the archives and you
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > i pointed it out how to port a larger series ontop of a whitespace
> > cleanup patch:
> >
> > http://lkml.org/lkml/2008/1/18/281
> >
> > the "there's an easy technique" bit.
>
> But it will be even easier to just redo the cleanup stuff at the end.
On Sunday, January 20, 2008 10:56 pm Yinghai Lu wrote:
> [PATCH] x86_32: trim memory by updating e820 v2
>
> when mtrr is not covering all e820 table, need to trim the ram, need to
> update e820
>
> reuse some code for x86_64
>
> here need to add early_identify_cpu for x86_32, and move
Peter Zijlstra wrote:
On Fri, 2008-01-18 at 17:17 -0800, Linda Walsh wrote:
On my x86_64 machine, I got the following message
in log (kern = 2.6.23.14)
Jan 16 04:08:38 Astara kernel: BUG: MAX_LOCK_DEPTH too low!
Jan 16 04:08:38 Astara kernel: turning off the locking correctness
validator.
On (21/01/08 15:49), Ingo Molnar didst pronounce:
>
> * Mel Gorman <[EMAIL PROTECTED]> wrote:
>
> > > I think this patch become easy to the porting of fakenuma.
> >
> > It would be great if that was available, particularly if it could fake
> > memoryless nodes as that is a place where we've
201 - 300 of 876 matches
Mail list logo