Jeremy Fitzhardinge wrote:
I can deal with the change going into -git, but it does seem awkward
knowing that it is the wrong change and it will be replaced by something
else almost immediately.
Well, it is not quite wrong - it is appropriate for -git. That it will
be replaced soon is a mi
On Fri, Mar 02, 2007 at 08:48:54PM -0500, Michael Krufky wrote:
>
> The dvbdev patch is pretty important, fixes a horrible problem, although the
> case for
> it to occur is rare. The other two patches are of the "obviously correct -
> minimal change"
> type.
>
> If it isnt too much trouble, t
David Lang a écrit :
I have a fork-heavy workload (a proxy that forks per connection, I know
it's not the most efficiant design) and I discovered a 2x performance
difference between a static and dynamicly linked version of the same
program (2200 connections/sec vs 4700 connections/sec)
I know
Zachary Amsden wrote:
> Yes, but the hook point now happens before the page table mapping.
Did you change that since you posted the patch? Sounds like a larger
change than the one I'm proposing.
> Not that it should cause a problem. But we've been testing things
> the original way for over a
On Fri, 2007-03-02 at 03:00 -0800, Andrew Morton wrote:
I get this with CONFIG_NO_HZ=y, CONFIG_SMP=n
kernel/sched.c: In function ‘trigger_load_balance’:
kernel/sched.c:3384: error: ‘struct rq’ has no member named
‘in_nohz_recently’
kernel/sched.c:3384: error: ‘struct rq’ has no member named
‘idle
Am Samstag, den 03.03.2007, 07:45 +0100 schrieb Oliver Neukum:
> Am Samstag, 3. März 2007 03:37 schrieb Kevin Fenzi:
> > I'm seeing some oddity with the latest fedora development kernel and a
> > usbserial device.
>
> Very interesting. Is this repeatable? Does unplugging have the same effect?
I
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> Note that the control bits do not just magically change during normal
> FPU use. It's a bit like sys_setsid()/iopl/etc., it makes little sense
> to change those per-thread anyway. This is a non-issue anyway - what is
> important is that the big bulk o
* Davide Libenzi wrote:
> [...] Status word and control bits should not be changed from
> underneath userspace AFAIK. [...]
Note that the control bits do not just magically change during normal
FPU use. It's a bit like sys_setsid()/iopl/etc., it makes little sense
to change those per-thread
On Sat, 3 Mar 2007 07:45:19 +0100
[EMAIL PROTECTED] (Oliver Neukum) wrote:
> Am Samstag, 3. März 2007 03:37 schrieb Kevin Fenzi:
> > I'm seeing some oddity with the latest fedora development kernel
> > and a usbserial device.
>
> Very interesting. Is this repeatable?
Yep. Tried a half dozen ti
Jeremy Fitzhardinge wrote:
Those are bugs that can occur, but they don't apply in this case. The
vmi implementation of kmap_atomic_pte() would be:
static void *vmi_kmap_atomic_pte(struct page *page, enum km_type type)
{
void *ptep = kmap_atomic(page, type);
vmi_map_pt_hook(type,
Jeremy Fitzhardinge wrote:
Tim Chen wrote:
I also hope that the performance can be recovered as this option could
enabled in distributions' kernels in future.
Yes, the intent is that running a CONFIG_PARAVIRT kernel on native
hardware will have negligible performance hit compared to ru
On Fri, 2 Mar 2007 14:57:06 +0100, Pavel Machek wrote:
> On Fri 2007-03-02 14:37:20, Jean Delvare wrote:
> > drivers/pci/quirks.c is full of things we do against the BIOS authors
> > intent. You don't plan to remove them all, do you?
>
> Notice how quirks.c is careful to name machines where given
Am Samstag, 3. März 2007 03:37 schrieb Kevin Fenzi:
> I'm seeing some oddity with the latest fedora development kernel and a
> usbserial device.
Very interesting. Is this repeatable? Does unplugging have the same effect?
Regards
Oliver
-
To unsubscribe from this list: sen
> This sounds like something that will always be wrong -- or in other
> words, always be right for only the latest CPUs. Can this be made
> dynamic, based on some timing factor?
In fact I think this has been tweaked twice in the vanilla tree
already.
This is actually just the same tweak you re
On Fri, Mar 02, 2007 at 12:58:33AM -0800, Andrew Morton wrote:
>
> -mm has a debugging patch which warns when atomic_dec_and_test() takes an
> atomic_t negative
> (ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/detect-atomic-counter-underflows.patch).
>
There were a couple more white spaces, instead of tabs, hopefully this is
the last of them:-)
Signed-off-by: Kandan Venkataraman [EMAIL PROTECTED]
diff -uprN linux-2.6.19.2/drivers/block/loop.c
linux-2.6.19.2-new/drivers/block/loop.c
--- linux-2.6.19.2/drivers/block/loop.c 2007-03-03 16:26:03.
Richard Purdie <[EMAIL PROTECTED]> writes:
> I propose the following patch (I was previously waiting on James for
> this). It avoids backing out the problematic Kconfig changes but
> means a user has to explicitly enable the backlight via a kernel or
> module parameter.
>
> Can people with backlig
diff --git a/Makefile b/Makefile
index 5335f17..10a3416 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 19
-EXTRAVERSION = .6
+EXTRAVERSION = .7
NAME=Avast! A bilge rat!
# *DOCUMENTATION*
diff --git a/drivers/media/dvb/dvb-core/dvbdev.c
b/drivers/m
We (the -stable team) are announcing the release of the 2.6.19.7 kernel.
It turns out that I forgot some patches that had already been submitted
to me, hence the new release.
It contains some DVB bugfixes, so anyone who uses that subsystem is
recommended to upgrade, otherwise 2.6.19.6 is fine.
Ba
Hi.
On Sat, 2007-03-03 at 12:20 +0900, Tejun Heo wrote:
> Hello, Nigel.
>
> Nigel Cunningham wrote:
> >> Index: work1/drivers/ata/ahci.c
> >> ===
> >> --- work1.orig/drivers/ata/ahci.c
> >> +++ work1/drivers/ata/ahci.c
> >> @@ -225,1
When a logical cpu 'x' already has more than one process running, then most
likely
the siblings of that cpu 'x' must be busy. Otherwise the idle siblings
would have likely(in most of the scenarios) picked up the extra load making
the load on 'x' atmost one.
Use this logic to eliminate the sibling
On Fri, 2 Mar 2007 16:32:07 +
[EMAIL PROTECTED] (Mel Gorman) wrote:
> The zone-based patches for memory partitioning should be providing what is
> required for memory hot-remove of an entire DIMM or bank of memory (PPC64
> also cares about removing smaller blocks of memory but zones are overki
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Fri, 02 Mar 2007 22:14:39 -0500
> Chris Leech wrote:
> > Every 20 descriptors turns out to be to few append commands with
> > newer/faster CPUs. Pushing every 4 still cuts down on MMIO writes to an
> > acceptable level without letting the DMA engine run
On Fri, 2 Mar 2007, William Lee Irwin III wrote:
>> AIUI that phenomenon is universal to NUMA. Maybe it's time we
>> reexamined our locking algorithms in the light of fairness
>> considerations.
On Fri, Mar 02, 2007 at 07:15:38PM -0800, Christoph Lameter wrote:
> This is a phenomenon that is usual
On Fri, 2 Mar 2007 17:40:04 -0800 William Lee Irwin III <[EMAIL PROTECTED]>
wrote:
>> My gut feeling is to agree, but I get nagging doubts when I try to
>> think of how to boil things like [major benchmarks whose names are
>> trademarked/copyrighted/etc. censored] down to simple testcases. Some
>>
Hello, Nigel.
Nigel Cunningham wrote:
>> Index: work1/drivers/ata/ahci.c
>> ===
>> --- work1.orig/drivers/ata/ahci.c
>> +++ work1/drivers/ata/ahci.c
>> @@ -225,10 +225,12 @@ static void ahci_thaw(struct ata_port *a
>> static void ahc
On Fri, 2 Mar 2007, William Lee Irwin III wrote:
> On Fri, Mar 02, 2007 at 02:22:56PM -0800, Andrew Morton wrote:
> > Opterons seem to be particularly prone to lock starvation where a cacheline
> > gets captured in a single package for ever.
>
> AIUI that phenomenon is universal to NUMA. Maybe it
Chris Leech wrote:
Every 20 descriptors turns out to be to few append commands with
newer/faster CPUs. Pushing every 4 still cuts down on MMIO writes to an
acceptable level without letting the DMA engine run out of work.
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
drivers/dma/ioatdma.c
[cc'ing Pavel and linux-kernel, hello]
Original thread can be read from
http://thread.gmane.org/gmane.linux.ide/16475
Jeff Garzik wrote:
> Tejun Heo wrote:
>> Some LLDs were missing scsi device PM callbacks while having host/port
>> suspend support. Add missing ones.
>>
>> Signed-off-by: Teju
Prior to commit 95492e4646e5de8b43d9a7908d6177fb737b61f0 ([PATCH] x86:
rewrite SMP TSC sync code), the headers in asm-i386 did not really
require anything in include/asm-x86_64. This means that distributions
such as fedora did not include asm-x86_64 in kernel-devel headers for
i386. Ingo's commi
On 12/4/06, Wendy Cheng <[EMAIL PROTECTED]> wrote:
Russell Cattelan wrote:
> Wendy Cheng wrote:
>
>> Linux kernel, particularly the VFS layer, is starting to show signs
>> of inadequacy as the software components built upon it keep growing.
>> I have doubts that it can keep up and handle this com
On Saturday 03 March 2007 12:31, Rik van Riel wrote:
> Andrew Morton wrote:
> > On Fri, 02 Mar 2007 15:31:19 -0500
> >
> > Rik van Riel <[EMAIL PROTECTED]> wrote:
> >> the attached patch frees the swap space of already resident pages
> >> when swap space starts getting tight, instead of only freein
I'm seeing some oddity with the latest fedora development kernel and a
usbserial device.
2.6.20-1.2949.fc7 #1 SMP Mon Feb 26 18:33:03 EST 2007 x86_64 x86_64
x86_64 GNU/Linux
Its a evdo device.
Doing:
modprobe usbserial vendor=0x413c product=0x8128 debug=1
gets:
drivers/usb/serial/usb-seri
During boot with dynticks enabled, we would sometimes get:
[ 35.271900] Switched to high resolution mode on CPU 0
[ 35.304468] BUG: spinlock already unlocked on CPU#0, swapper/1
[ 35.338099] lock: c06428a0, .magic: dead4ead, .owner: /-1,
.owner_cpu:
-1
[ 35.373597] [] _raw_spin_unlock+0
net/ipv4/tcp.c: In function 'tcp_recvmsg':
net/ipv4/tcp.c:: warning: unused variable 'available'
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
net/ipv4/tcp.c | 26 --
1 files changed, 16 insertions(+), 10 deletio
Every 20 descriptors turns out to be to few append commands with
newer/faster CPUs. Pushing every 4 still cuts down on MMIO writes to an
acceptable level without letting the DMA engine run out of work.
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
drivers/dma/ioatdma.c |4 ++--
1 files
From: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
drivers/dma/dmaengine.c | 22 --
1 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dma
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
MAINTAINERS | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1dfba85..2dd5d23 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1156,6 +1156,12 @@ M: [EMAIL PROTECTED]
L:
The performance wins come with having the DMA copy engine doing the copies
in parallel with the context switch. If there is enough data ready on the
socket at recv time just use a regular copy.
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
net/ipv4/tcp.c | 10 +++---
1 files changed,
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
Documentation/networking/ip-sysctl.txt |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt
b/Documentation/networking/ip-sysctl.txt
index d3aae1f..9541691 100644
--- a/Documentatio
Andrew Morton (1):
I/OAT: warning fix
Chris Leech (6):
ioatdma: Push pending transactions to hardware more frequently
ioatdma: Remove the wrappers around read(bwl)/write(bwl) in ioatdma
ioatdma: Remove the use of writeq from the ioatdma driver
I/OAT: Add documentation for
Under kexec, I/OAT initialization breaks over busy resources because the
previous kernel did not release them.
I'm not sure this fix can be considered a complete one but it works for me.
I guess something similar to the *_remove method should occur there..
Signed-off-by: Dan Aloni <[EMAIL PROTEC
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
drivers/dma/ioatdma.c| 60 +++
drivers/dma/ioatdma_io.h | 118 --
2 files changed, 28 insertions(+), 150 deletions(-)
diff --git a/drivers/dma/ioatdma.c b/drivers/dma/ioatdma
There's only one now anyway, and it's not in a performance path,
so make it behave the same on 32-bit and 64-bit CPUs.
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
drivers/dma/ioatdma.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/ioatdma.c
On Fri, 2 Mar 2007, Nicholas Miell wrote:
> On Fri, 2007-03-02 at 16:52 -0800, Davide Libenzi wrote:
> > On Fri, 2 Mar 2007, Nicholas Miell wrote:
> >
> > > The point Ingo was making is that the x86 ABI already requires the FPU
> > > context to be saved before *all* function calls.
> >
> > I've
On 3/2/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
Where is the patch for review?
I'm sending them now.
These have been posted before, and other than one objectionable change
that I dropped the first time around they quietly went nowhere.
- Chris
-
To unsubscribe from this list: send the line
Jan-Bernd Themann <[EMAIL PROTECTED]> writes:
>
> Are there any concerns about this approach?
Yes. You should fix the NAPI code instead of trying to work
around it.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
On Fri, 2 Mar 2007 17:40:04 -0800
William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 02, 2007 at 02:59:06PM -0800, Andrew Morton wrote:
> > Somehow I don't believe that a person or organisation which is incapable of
> > preparing even a simple testcase will be capable of fixing problem
Greg KH wrote:
> On Tue, Feb 27, 2007 at 03:23:05PM -0500, Michael Krufky wrote:
>> Greg KH wrote:
>>> This is the start of the stable review cycle for the 2.6.19.6 release.
>>>
>>> This will probably be the last release of the 2.6.19-stable series, so
>>> if there are patches that you feel should
On Fri, Mar 02, 2007 at 05:36:01PM -0800, Nicholas Miell wrote:
> > as an asynchronous context helps alot: the classic gcc convention for
> > FPU use & function calls should apply: gcc does not call an external
> > function with an in-use FPU stack/register, it always neatly unuses it,
> > as no
Notes:
1) The patches credited to me are really extractions of Alan's patches.
2) In particular, the 'change master/slave IDENTIFY order' has a wide
(but hopefully not negative) impact, as mentioned in the thread. Since
pata_* drivers are Officially(tm) considered more experimental than
drivers/
On Fri, 2007-03-02 at 16:52 -0800, Davide Libenzi wrote:
> On Fri, 2 Mar 2007, Nicholas Miell wrote:
>
> > The point Ingo was making is that the x86 ABI already requires the FPU
> > context to be saved before *all* function calls.
>
> I've not seen that among Ingo's points, but yeah some status i
On Fri, Mar 02, 2007 at 02:59:06PM -0800, Andrew Morton wrote:
> What is it with vendors finding MM problems and either not fixing them or
> kludging around them and not telling the upstream maintainers about *any*
> of it?
I'm not in the business of defending vendors, but a lot of times the
base
On Sat, 03 Mar 2007 02:22:59 +0100
Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> Andrew Morton napisa__(a):
> > On Sat, 3 Mar 2007 00:42:33 +0100
> > "Michal Piotrowski" <[EMAIL PROTECTED]> wrote:
> >
> >> On 02/03/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> >>> Temporarily at
> >>>
> >>> h
This patch adds the Intel ICH9M RAID controller DID for SATA support.
Signed-off-by: Jason Gaston <[EMAIL PROTECTED]>
--- linux-2.6.21-rc2/drivers/ata/ahci.c.orig2007-03-02 17:28:00.0
-0800
+++ linux-2.6.21-rc2/drivers/ata/ahci.c 2007-03-02 17:28:30.0 -0800
@@ -380,6 +380,7
Fixes du jour.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
arch/mips/jmr3927/rbhma3100/setup.c |4 -
arch/mips/momentum/jaguar_atx/platform.c| 20 +---
arch/mi
Stephen Hemminger <[EMAIL PROTECTED]> writes:
> Here is another way to handle the 64 bit divide case.
> It allows full 64 bit divide by adding the support routine
> GCC needs.
Not supplying that was intentional by Linus so that people
think twice (or more often) before they using such expensive
o
Andrew Morton wrote:
On Fri, 02 Mar 2007 15:31:19 -0500
Rik van Riel <[EMAIL PROTECTED]> wrote:
the attached patch frees the swap space of already resident pages
when swap space starts getting tight, instead of only freeing up
the swap space taken up by newly swapped in pages.
This should resu
Chris Leech wrote:
Please pull from git://lost.foo-projects.org/~cleech/linux-2.6#master
A few drivers/dma and related I/OAT fixes, and missing documentation.
These have been posted for review and sitting in MM for a while now.
- Chris
Andrew Morton (1):
I/OAT: warning fix
Chris Leech (6
El Viernes, 2 de Marzo de 2007, Xavier Callejas escribió:
> El Viernes, 2 de Marzo de 2007, Erik Mouw escribió:
> > Try to recreate the problem without the proprietary wlan driver. With
> > that driver loaded it's impossible to debug.
> >
> >
> > Erik
>
> Thank you Erik,
>
> I've deleted madwifi fr
John W. Linville wrote:
From: Johannes Berg <[EMAIL PROTECTED]>
Since wext is being replaced as fast as we can (it'll probably stick
around for legacy drivers though) and the wext/netlink stuff was never
really used, this schedules it for removal.
The removal schedule is tight but there are no
Andrew Morton napisał(a):
> On Sat, 3 Mar 2007 00:42:33 +0100
> "Michal Piotrowski" <[EMAIL PROTECTED]> wrote:
>
>> On 02/03/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
>>> Temporarily at
>>>
>>> http://userweb.kernel.org/~akpm/2.6.21-rc2-mm1/
>>>
>> I have noticed some strange system behavior.
On Tue, Feb 27, 2007 at 03:23:05PM -0500, Michael Krufky wrote:
> Greg KH wrote:
> > This is the start of the stable review cycle for the 2.6.19.6 release.
> >
> > This will probably be the last release of the 2.6.19-stable series, so
> > if there are patches that you feel should be applied to tha
Please pull from git://lost.foo-projects.org/~cleech/linux-2.6#master
A few drivers/dma and related I/OAT fixes, and missing documentation.
These have been posted for review and sitting in MM for a while now.
- Chris
Andrew Morton (1):
I/OAT: warning fix
Chris Leech (6):
ioatdma: Pus
Shan Lu wrote:
Changelog:
Function `phy_mii_ioctl' returns physical device's information based on
user requests. When requested to return the basic mode control register
information (BMCR), the original implementation only returns the
physical device's duplex information and forgets to return spe
On Fri, 02 Mar 2007 15:31:19 -0500
Rik van Riel <[EMAIL PROTECTED]> wrote:
> the attached patch frees the swap space of already resident pages
> when swap space starts getting tight, instead of only freeing up
> the swap space taken up by newly swapped in pages.
>
> This should result in the swap
I have a fork-heavy workload (a proxy that forks per connection, I know it's not
the most efficiant design) and I discovered a 2x performance difference between
a static and dynamicly linked version of the same program (2200 connections/sec
vs 4700 connections/sec)
I know that there is overhea
Dale Farnsworth wrote:
We were using the platform_device.id field to identify which ethernet
port is used for mv643xx_eth device. This is not generally correct.
It will be incorrect, for example, if a hardware platform uses a single
port but not the first port. Here, we add an explicit port_num
Dale Farnsworth wrote:
The information contained within platform_data should be self-contained.
Replace the pointer to a MAC address with the actual MAC address in
struct mv643xx_eth_platform_data.
Signed-off-by: Dale Farnsworth <[EMAIL PROTECTED]>
---
Replaced explicit mac address comparison
Dave Jones wrote:
Commit 908b637fe793165b6aecdc875cdca67c4959a1ad removed ETH_DMA_ALIGN
but missed a usage of it in a macro, which broke the build.
Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
applied
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
diff --git a/Makefile b/Makefile
index cd5b5cf..5335f17 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 19
-EXTRAVERSION = .5
+EXTRAVERSION = .6
NAME=Avast! A bilge rat!
# *DOCUMENTATION*
diff --git a/drivers/input/mouse/psmouse-base.c
b/drivers/in
We (the -stable team) are announcing the release of the 2.6.19.6 kernel.
It contains a number of bugfixes, and all 2.6.19 users are recommended
to upgrade.
Barring anything major, there will not be any more 2.6.19 releases. If
you disagree with this, please let the stable team know about the
patc
On Tuesday 27 February 2007 12:45, Ingo Oeser wrote:
> Hi Inaky,
>
> On Tuesday, 27. February 2007, Inaky Perez-Gonzalez wrote:
> > On Monday 26 February 2007 18:18, Alan wrote:
> > > > Yeah, I need semaphore. This is a hw register that says when the hw
> > > > is ready to accept a new command. Cod
Jan-Bernd Themann wrote:
This patch introduces functionality to dynamically add / remove
ehea ports via an userspace DLPAR tool. It creates a subnode for
each logical port in the sysfs.
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
applied 1-2 to #upstream (2.6.22)
your patches adde
On Saturday, 3 March 2007 00:33, Oleg Nesterov wrote:
> On 03/02, Paul E. McKenney wrote:
> >
> > One way to embed try_to_freeze() into kthread_should_stop() might be
> > as follows:
> >
> > int kthread_should_stop(void)
> > {
> > if (kthread_stop_info.k == current)
> >
On Sat, Mar 03, 2007 at 02:33:37AM +0300, Oleg Nesterov wrote:
> On 03/02, Paul E. McKenney wrote:
> >
> > One way to embed try_to_freeze() into kthread_should_stop() might be
> > as follows:
> >
> > int kthread_should_stop(void)
> > {
> > if (kthread_stop_info.k == current)
>
On Fri, 02 Mar 2007 19:43:34 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Gary Zambrano wrote:
> > Added dma_sync_single_range_for_cpu/device to dma-mapping.h in asm-arm &
> > asm-avr32 to call dma_sync_single_for_cpu/device. This patch enables b44
> > to compile on systems with these cpus.
> >
On Fri, 2 Mar 2007 16:33:19 -0800
William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 02, 2007 at 02:22:56PM -0800, Andrew Morton wrote:
> > Opterons seem to be particularly prone to lock starvation where a cacheline
> > gets captured in a single package for ever.
>
> AIUI that phenome
On Fri, 2 Mar 2007, Nicholas Miell wrote:
> The point Ingo was making is that the x86 ABI already requires the FPU
> context to be saved before *all* function calls.
I've not seen that among Ingo's points, but yeah some status is caller
saved. But, aren't things like status word and control bits
Gary Zambrano wrote:
Added dma_sync_single_range_for_cpu/device to dma-mapping.h in asm-arm &
asm-avr32 to call dma_sync_single_for_cpu/device. This patch enables b44
to compile on systems with these cpus.
This patch was created with the assumption that another method of
dma_sync_single_range_for
On Sat, 3 Mar 2007 00:42:33 +0100
"Michal Piotrowski" <[EMAIL PROTECTED]> wrote:
> On 02/03/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > Temporarily at
> >
> > http://userweb.kernel.org/~akpm/2.6.21-rc2-mm1/
> >
>
> I have noticed some strange system behavior. When i try to build a
> ke
On Fri, Mar 02, 2007 at 02:22:56PM -0800, Andrew Morton wrote:
> Opterons seem to be particularly prone to lock starvation where a cacheline
> gets captured in a single package for ever.
AIUI that phenomenon is universal to NUMA. Maybe it's time we
reexamined our locking algorithms in the light of
On Fri, 02 Mar 2007 15:28:43 -0800
"Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
> >>> 32GB is pretty much the minimum size to reproduce some of these
> >>> problems. Some workloads may need larger systems to easily trigger
> >>> them.
> >>
> >> We can find a 32GB system here pretty easily to test
Hi.
On Fri, 2007-03-02 at 17:46 +0900, Tejun Heo wrote:
> Add missing #ifdef CONFIG_PM conditionals around all PM related parts
> in libata LLDs.
>
> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
> ---
> drivers/ata/ahci.c | 14 ++
> drivers/ata/ata_generic.c |
Tim Chen wrote:
> I also hope that the performance can be recovered as this option could
> enabled in distributions' kernels in future.
Yes, the intent is that running a CONFIG_PARAVIRT kernel on native
hardware will have negligible performance hit compared to running a
non-paravirt kernel.
J
Alan Cox wrote:
it seems broken to manipulate xfer_mask after returning from the
driver's ->mode_filter hook.
this patch is more than just a speed-limited warning printk, afaics
I actually suggested that order because the only way the printk can be
done correctly is for it to be the very last
Alan Cox wrote:
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.21-rc2/drivers/ata/Kconfig
linux-2.6.21-rc2/drivers/ata/Kconfig
--- linux.vanilla-2.6.21-rc2/drivers/ata/Kconfig2007-03-01
13:36:03.0 +0
On Fri, 2007-03-02 at 13:54 -0800, Jeremy Fitzhardinge wrote:
> [ I assume you're talking about running on native hardware. ]
>
That's correct.
> I haven't done any detailed measurements on what effect this will have,
> but it does bring the actual executed instruction stream much closer to
> th
.. and think about a realistic future.
EVERYBODY will do on-die memory controllers. Yes, Intel doesn't do it
today, but in the one- to two-year timeframe even Intel will.
What does that mean? It means that in bigger systems, you will no longer
even *have* 8 or 16 banks where turning off a few
(I've removed the other CC:s for now to avoid annoying them - assuming
removing them from the CC: list doesn't do that).
On 02/03/07 22:32, Eric Dumazet wrote:
Simon Arlott a écrit :
On 02/03/07 16:35, Eric Dumazet wrote:
I believe this patch is too complex/hazardous and may break exp decay
c
> it seems broken to manipulate xfer_mask after returning from the
> driver's ->mode_filter hook.
>
> this patch is more than just a speed-limited warning printk, afaics
I actually suggested that order because the only way the printk can be
done correctly is for it to be the very last test made.
Francesco Pretto wrote:
2007/2/22, Robert Hancock <[EMAIL PROTECTED]>:
I believe it runs on suspend, but we don't run that code on normal
shutdown, do we?
Tejun Heo had a patch for sd that could (optionally) trigger a START
STOP UNIT command to spin the disk down after synchronizing the cache
> > + if (ap->port_no != 0 && adev->devno != timing->last) {
> > + pci_write_config_byte(pdev, DRWTIM23,
> > timing->reg58[adev->devno]);
> > + timing->last = adev->devno;
> > + }
>
> It might be worth looking into whether ->dev_select is a better place
> for this sort of
On Sat, 03 Mar 2007 00:05:23 +0100
Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> Andrew Morton napisał(a):
> > Temporarily at
> >
> > http://userweb.kernel.org/~akpm/2.6.21-rc2-mm1/
> >
>
> Please consider this patch for inclusion in >= 2.6.22.
>
> "drivers/char/epca.c:2741: warning: 'get_t
On 02/03/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.21-rc2-mm1/
I have noticed some strange system behavior. When i try to build a
kernel (medium load) - X, keyboard, mouse and sound hangs.
I can ping machine and I can use magic SysRq k
On Fri, 2007-03-02 at 13:58 -0800, Andrew Morton wrote:
> > @@ -1106,7 +1105,8 @@ config FB_ATY_GX
> >
> > config FB_ATY_BACKLIGHT
> > bool "Support for backlight control"
> > - depends on FB_ATY
> > + depends on FB_ATY && EXPERIMENTAL
> > + select FB_BACKLIGHT
> > default y
>
On Sat, Mar 03, 2007 at 12:02:14AM +0100, Sam Ravnborg wrote:
> >
> > Yes, we allow them to be exported globally, as other init code might
> > need to call them, like these functions.
> >
> > So yes, I think we need to find a way to fix the warning tools, as the
> > code is correct here.
>
> Thi
Chuck Ebbert wrote:
> John Reiser wrote:
>
>>The value of ->sysenter_return is interpreted in user space by the
>>sysexit instruction; nobody else cares what the value is. The kernel
>>is not required to provide a good value when vdso_enabled is zero,
>>because the kernel has not told the process
On 03/02, Paul E. McKenney wrote:
>
> One way to embed try_to_freeze() into kthread_should_stop() might be
> as follows:
>
> int kthread_should_stop(void)
> {
> if (kthread_stop_info.k == current)
> return 1;
> try_to_freeze();
>
On Fri, 2007-03-02 at 12:29 -0800, Andrew Morton wrote:
> On Fri, 02 Mar 2007 09:24:03 -0800
> Alex Romosan <[EMAIL PROTECTED]> wrote:
> > > Unclear. Are you saying that the backlight comes on OK if you use
> > > the IBM acpi module?
> >
> > yes, if i disable the radeon backlight and use the ibm a
1 - 100 of 413 matches
Mail list logo
