Hi,
Those patches add RapidIO support to powerpc archiecture with
memory mapping as below:
[1/3] Copy the arch/ppc RapidIO support to arch/powerpc
[2/3] Make the arch/powerpc RapidIO support workable with of-device
and add memory mapping support.
[3/3] Add the memory mapping support to
On Dec 13, 2007 4:53 PM, Pierre Ossman [EMAIL PROTECTED] wrote:
On Thu, 13 Dec 2007 16:13:11 +0900
Kyungmin Park [EMAIL PROTECTED] wrote:
It already checked the ext_csd_struct is less than 2,
so it doesn't need to check it.
Current code only accepts the revision 1.2.
Signed-off-by:
On Thu, 6 Dec 2007 16:25:57 -0700
Bjorn Helgaas [EMAIL PROTECTED] wrote:
PNP: do not stop/start devices in suspend/resume path
Do not disable PNP devices in the suspend path. We still call
the driver's suspend method, which should prevent further use of
the device, and the protocol suspend
On Thu, 13 Dec 2007 16:13:11 +0900
Kyungmin Park [EMAIL PROTECTED] wrote:
It already checked the ext_csd_struct is less than 2,
so it doesn't need to check it.
Current code only accepts the revision 1.2.
Signed-off-by: Kyungmin Park [EMAIL PROTECTED]
It wasn't wrong the last time you
Signed-off-by: Zhang Wei [EMAIL PROTECTED]
---
drivers/net/Kconfig | 10 ++
drivers/net/rionet.c | 337 +-
2 files changed, 345 insertions(+), 2 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index e8d69b0..b1129cc 100644
Roland Dreier wrote:
I think the right fix for iSER would be to make iSER work even for
devices that don't support FMRs. For example cxgb3 doesn't implement
FMRs so if anyone ever updates iSER to work on iWARP and not just IB,
then this is something that has to be tackled anyway. Then ehca
Signed-off-by: Jan Beulich [EMAIL PROTECTED]
drivers/acpi/numa.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.24-rc5/drivers/acpi/numa.c2007-10-09 22:31:38.0
+0200
+++ 2.6.24-rc5-acpi-init-warning/drivers/acpi/numa.c2007-12-04
Signed-off-by: Zhang Wei [EMAIL PROTECTED]
---
arch/powerpc/sysdev/fsl_rio.c | 932 +
1 files changed, 932 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/sysdev/fsl_rio.c
diff --git a/arch/powerpc/sysdev/fsl_rio.c
On Thu, 13 Dec 2007 17:08:16 +0900
Kyungmin Park [EMAIL PROTECTED] wrote:
In my MMC Spec. (v4.2), there's no problem to read it even though it's
revision 1.1
Well, the spec says that those reserved fields should be zero. Unfortunately,
people seem to have read this in the IETF sense and
Norbert Preining wrote:
Hi all!
On Mo, 10 Dez 2007, Peter Zijlstra wrote:
How reproducable is this? You make it sound like its easy to reproduce,
I tried and re-tried and re-tried to reproduce this, without success.
Sorry.
I guess we can forget that one and assume that it was a
.. since it uses ILL_BADSTK (which is meaningless in the context of
SIGSEGV).
Signed-off-by: Jan Beulich [EMAIL PROTECTED]
arch/x86/kernel/traps_32.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.24-rc5/arch/x86/kernel/traps_32.c 2007-12-12 11:28:18.0
+0100
The way X86_TSC works and the fact that Xen itself won't work on
systems without TSC (really any systems pre-dating i686) makes it
unnecessary for XEN to depend on it.
Similarly, X86_CMPXCHG isn't needed here either as Xen for the above
reason guarantees its availability.
This allows the option
Arnd Bergmann wrote:
On Tuesday 11 December 2007, Avi Kivity wrote:
Heiko Carstens wrote:
On Tue, Dec 11, 2007 at 11:47:39AM +0200, Avi Kivity wrote:
arch/*/kvm/ arch dependent kvm code
Maybe arch/*/virt/ ? No need to add an own directory for each hypervisor.
.. as it it used only during early boot.
Signed-off-by: Jan Beulich [EMAIL PROTECTED]
arch/ia64/kernel/acpi.c |2 +-
arch/x86/kernel/acpi/boot.c |4 ++--
drivers/acpi/osl.c |3 ++-
3 files changed, 5 insertions(+), 4 deletions(-)
---
* Eric W. Biederman [EMAIL PROTECTED] wrote:
/proc/timer_stats currently reports the user of a timer by pid, which
is a reasonable approach. However if you are not in the initial pid
namespace the pid that is reported is nonsense.
Therefore until we can make timer_stats pid namespace
On Wed, Dec 12, 2007 at 10:22:22PM -0600, Robert Hancock wrote:
For the case where you say I want to enable decoding for this MMIO BAR,
but not that one, though, I don't see an obvious way to provide that
guarantee with certainty. Normally, one would expect that if a BAR is
mapped safely
Signed-off-by: Jan Beulich [EMAIL PROTECTED]
arch/x86/kernel/process_32.c |4 ++--
include/asm-x86/processor_32.h |2 --
2 files changed, 2 insertions(+), 4 deletions(-)
--- linux-2.6.24-rc5/arch/x86/kernel/process_32.c 2007-12-12
11:28:18.0 +0100
+++
On Thu, Dec 13, 2007 at 04:26:42PM +1100, Benjamin Herrenschmidt wrote:
I can try to whip up some code tomorrow I suppose, though I'm always
afraid some dodgy x86 setup will blow up...
That scares me too, but something like pci_dangling_bar(dev, idx) with
a default (for now) no-op
This addresses several points:
- CLEAR_RREGS' clearing of R9 became redundant with the recent change
to cstar_tracesys' saving/restoring %r9
- LOAD_ARGS32 has no need for re-loading %r8-%r11, except in the case
of cstar_tracesys, where %r9 must be re-loaded
- the recent change to sysenter
This generally allows better code to be generated, since the zero-
extension during 32-bit operations comes for free (needed when the
result is used as array index or similar), whereas sign extension must
be done explicitly and frequently requires a one byte larger
instruction due to the necessary
When either calling change_page_attr() with the default attributes
pages in the direct mapping have and a page's attributes already were
set to the default or when changing the attributes from one non-default
value to another, the reference counting broke, leading to either
premature restoration
Signed-off-by: Jan Beulich [EMAIL PROTECTED]
arch/x86/Kconfig.cpu |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.24-rc5/arch/x86/Kconfig.cpu 2007-12-12 11:28:17.0
+0100
+++ 2.6.24-rc5-x86-cmov/arch/x86/Kconfig.cpu2007-12-04 16:11:19.0
+0100
@@
Signed-off-by: Jan Beulich [EMAIL PROTECTED]
arch/x86/kernel/smp_32.c |1 -
arch/x86/kernel/smp_64.c |3 ---
2 files changed, 4 deletions(-)
--- linux-2.6.24-rc5/arch/x86/kernel/smp_32.c 2007-12-12 11:28:18.0
+0100
+++ 2.6.24-rc5-x86-flushtlb-exports/arch/x86/kernel/smp_32.c
The array is never written, and on 64-bits it's not even being used
past initial boot.
Signed-off-by: Jan Beulich [EMAIL PROTECTED]
arch/x86/kernel/entry_32.S |2 +-
arch/x86/kernel/i8259_64.c |2 +-
include/asm-x86/hw_irq_32.h |2 +-
3 files changed, 3 insertions(+), 3
With CONFIG_PM, but without CONFIG_PM_SLEEP, the intention of the
conditional in ohci_pci_start() doesn't work since device_may_wakeup()
references pdev only with the latter config option.
Signed-off-by: Jan Beulich [EMAIL PROTECTED]
drivers/usb/host/ohci-pci.c |2 +-
1 files changed, 1
Signed-off-by: Jan Beulich [EMAIL PROTECTED]
arch/x86/kernel/entry_64.S |4
arch/x86/kernel/traps_64.c |3 ---
2 files changed, 7 deletions(-)
--- linux-2.6.24-rc5/arch/x86/kernel/entry_64.S 2007-12-12 16:48:17.0
+0100
+++
This fixes some of the alpha-specific build problems, except a) modpost
warning about COMMON symbol saved_config and b) nasty final link
failure with gcc-4.x, -Os and scsi-disk driver configured built-in
(due to jump table in .rodata referencing discarded .exit.text).
- build failure with
This requires making die() return a value, making its callers honor
this (and be prepared that it may return), and making oops_end() have
two additional parameters.
Signed-off-by: Jan Beulich [EMAIL PROTECTED]
arch/x86/kernel/cpu/mcheck/mce_64.c |8
arch/x86/kernel/traps_64.c
On Thu, 2007-12-13 at 12:14 +0300, Ivan Kokshaysky wrote:
On Thu, Dec 13, 2007 at 04:26:42PM +1100, Benjamin Herrenschmidt wrote:
I can try to whip up some code tomorrow I suppose, though I'm always
afraid some dodgy x86 setup will blow up...
That scares me too, but something like
Neither __cpu_disable() nor __cpu_die() are being referenced without
CONFIG_HOTPLUG_CPU.
Signed-off-by: Jan Beulich [EMAIL PROTECTED]
arch/x86/kernel/smpboot_32.c | 11 ---
arch/x86/kernel/smpboot_64.c | 12
2 files changed, 23 deletions(-)
---
Em Qua, 2007-12-12 às 13:13 -0800, Trent Piepho escreveu:
On Wed, 12 Dec 2007, Adrian Bunk wrote:
I don't see any issue on making both dependent on VIDEO_TUNER for
2.6.24, since they are currently used only by tuner core module
(tuner.ko).
...
If selected code isn't included
.. allowing to remove their declarations from a global include file
(the symbols don't exist for anything but x86).
Likewise for 64-bits' fix_processor_context(), just that that one was
properly declared in an arch-specific header.
Signed-off-by: Jan Beulich [EMAIL PROTECTED]
e1f8b4a49d86746f699919531c17fd154787e308
diff --git a/drivers/media/video/videobuf-core.c
b/drivers/media/video/videobuf-core.c
index 81f77d2..c8a5cb5 100644
--- a/drivers/media/video/videobuf-core.c
+++ b/drivers/media/video/videobuf-core.c
@@ -909,7 +909,7 @@ ssize_t
* Harvey Harrison [EMAIL PROTECTED] wrote:
fastcall is always defined to be empty, remove it from arch/x86
thanks, i've applied this and your other fastcall patches to x86.git.
(except for the non-x86 bits - those will go upstream via the other
trees.)
Ingo
--
To unsubscribe from
Its previous use in a call to on_each_cpu() was pointless, as at the
time that code gets executed only one CPU is online. Further, the
function can be __cpuinit, and for this to work without
CONFIG_HOTPLUG_CPU setup_nmi() must also get an attribute (this one
can even be __init; on 64-bits
According to Greg KH:
So, what should be added to 2.6.23-stable then? And, can I get a real
changelog entry for it?
This is suitable for both 2.6.23.x and 2.6.24-rc5 :
linux-2.6-dpt_i2o-no-dma64.patch
The dpt_i2o driver can't handle 64 bit DMA addresses, so do not
let it set
* Daniel Walker [EMAIL PROTECTED] wrote:
This driver is scheduled for removal, so I'd not touch it anymore to
avoid the possibility to introduce a lastminute regression. The new
drivers (b43 and b43legacy) have this fixed (in a different way by
completely removing it).
When is the
Avi Kivity wrote:
In the case of x86, we'll have 16 arch dependent files (i8259.[ch],
irq.[ch], lapic.c, mmu.c, paging_tmpl.[ch], svm.[ch], vmx.[ch],
x86.[ch], x86_emulate.[ch]) which warrant a kvm/ subdirectory IMO.
I think a subdirectory makes sense too. We'll end up with more than a
single
* Dave Jones [EMAIL PROTECTED] wrote:
It _looks_ like we're leaking a refcount on that lock, but I don't
see where. It's a shame you can't reproduce this easily, as
cpufreq.debug=7 would give us more clues. (And
CONFIG_CPUFREQ_DEBUG=y)
So we're missing some unlocks in some
2007/12/12, Joonwoo Park [EMAIL PROTECTED]:
[NETDEV]: e1000 Fix possible causing oops of net_rx_action
returning work_done == weight as true after calling netif_rx_complete will
cause oops in net_rx_action.
I tried two types of patches for oops and ifconfig down hang for e1000 first.
Just
* Steven Rostedt [EMAIL PROTECTED] wrote:
[This patch *is* for mainline Linux]
In commit 76d2160147f43f982dfe881404cfde9fd0a9da21 lazy irq disabling
was implemented, and the simple irq handler had a masking set to it.
Remy Bohmer discovered that some devices in the ARM architecture
On Wed, Dec 12, 2007 at 03:20:10PM -0500, Steven Rostedt wrote:
[This patch *is* for mainline Linux]
In commit 76d2160147f43f982dfe881404cfde9fd0a9da21 lazy irq disabling
was implemented, and the simple irq handler had a masking set to it.
Remy Bohmer discovered that some devices in the
* Metzger, Markus T [EMAIL PROTECTED] wrote:
Users who want to process that huge amount of data would be better off
using a file-based approach (well, if it cannot be held in physical
memory, they will spend most of their time swapping, anyway). Those
users would typically wait for the
On Sun, 9 Dec 2007 22:40:31 +0100 Marcin Ślusarz [EMAIL PROTECTED] wrote:
logo: move declarations of logos to linux_logo.h
there was a mismatch between externs in logo.c and code generated by pnmtologo
(on old tree, you need to rm drivers/video/logo/logo_*.c before compilation)
This patch
The two files in question are unused without CONFIG_PM_SLEEP.
Signed-off-by: Jan Beulich [EMAIL PROTECTED]
arch/x86/kernel/Makefile_64 |2 +-
arch/x86/power/Makefile |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.24-rc5/arch/x86/kernel/Makefile_64
Em Qua, 2007-12-12 às 23:19 +0100, Jean Delvare escreveu:
Hi Mauro,
On Wed, 12 Dec 2007 12:21:56 -0200, Mauro Carvalho Chehab wrote:
What happened is that changeset 19bc5133dae9562e8824ef101464061f9854c1d8
fixed some bad locks.
After this changeset, videobuf_read_stream() holds
The change to mtrr_ap_init() depends on the previously submitted
Makefile change altering the condition for building of two files from
CONFIG_PM to CONFIG_PM_SLEEP (the latter implies CONFIG_HOTPLUG_CPU).
Signed-off-by: Jan Beulich [EMAIL PROTECTED]
arch/x86/kernel/cpu/mcheck/mce_64.c |6
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc5/2.6.24-rc5-mm1/
- If something goes wrong with a PCI device's probing or initialisation, try
reverting pci-disable-decoding-during-sizing-of-bars.patch.
- git-sched was dropped due to breaking suspend-to-RAM.
-
Hello Steven,
If I compile -rt13 I get some compile warnings on ARM (AT91):
1) This one did not exist in rt1:
In file included from kernel/sched.c:911:
kernel/sched_rt.c: In function 'dec_rt_tasks':
kernel/sched_rt.c:88: warning: unused variable 'highest_prio'
2) This one is there already for a
So disabling memory or IO decode in a command register seems to be
the only safe option. This depends on architecture, though.
You are assuming a degree of sanity that seems unwise (at least for PC
class hardware).
Whether a given BAR is decoded depends not only on the contents of the
BAR but
Hello Steven,
In commit 76d2160147f43f982dfe881404cfde9fd0a9da21 lazy irq disabling
was implemented, and the simple irq handler had a masking set to it.
Remy Bohmer discovered that some devices in the ARM architecture
would trigger the mask, but never unmask it. His patch to do the
On Thursday 13 December 2007 11:13:27 Ingo Molnar wrote:
* Daniel Walker [EMAIL PROTECTED] wrote:
This driver is scheduled for removal, so I'd not touch it anymore to
avoid the possibility to introduce a lastminute regression. The new
drivers (b43 and b43legacy) have this fixed (in
On Thu, 2007-12-13 at 10:24 +, Alan Cox wrote:
The SIL680 for example has an MMIO BAR at BAR5. Control for that BAR is
via MMIO_EN which is a bit in PCI config register 0x8A.
So if we disable the device because of a dangling BAR the users root file
system goes away. If we leave it as
Supporting pci_enable_device_io / pci_enable_device_mmio / pci_iomap_io /
pci_iomap_mmio seems to cover pretty much all the use cases we have.
The users we have right now that are:
- pata_cs5520 (can be dealt with easily)
- old IDE (with the new resource
Can anyone help with this ? This seems to be a true SMP bug - the same
kernel on another UP machine is working fine (although different h/w).
Seems like stress (find for example) can easily trigger this. Does it
look like i have a bad filesystem ? Can anyone help me figure out which
one ?
Hi Vincent,
Could you please see if the following patch removes the oops due to CFS
sysfs files? (There might still be the other oops due to the floppy
sysfs files)
Ingo, could you please add this patch in your CFS backport to 2.6.22 and
older kernels?
Thanks,
--
kdump showed that the owner
At Wed, 12 Dec 2007 20:42:46 -0800,
Randy Dunlap wrote:
On Tue, 30 Oct 2007 12:05:28 +0100 Takashi Iwai wrote:
At Mon, 29 Oct 2007 11:20:10 -0700,
Randy Dunlap wrote:
From: Randy Dunlap [EMAIL PROTECTED]
Fix printk format warning:
sound/isa/ad1848/ad1848_lib.c:216:
Ingo Molnar [EMAIL PROTECTED] writes:
* Eric W. Biederman [EMAIL PROTECTED] wrote:
/proc/timer_stats currently reports the user of a timer by pid, which
is a reasonable approach. However if you are not in the initial pid
namespace the pid that is reported is nonsense.
Therefore until
[Sorry for the late response as I've been on vacation]
At Sat, 8 Dec 2007 21:15:44 -0500,
Theodore Tso wrote:
On Sat, Dec 08, 2007 at 11:30:53PM +0100, Rafael J. Wysocki wrote:
On Saturday, 8 of December 2007, Theodore Tso wrote:
However, as far as I am concerned, Ingo's patch, first
Hi Andrew,
On Thu, Dec 13, 2007 at 02:40:50AM -0800, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc5/2.6.24-rc5-mm1/
- If something goes wrong with a PCI device's probing or initialisation, try
reverting
Hello,
I apologize if this is not the right place to ask, but I wanted to check if
there is a mistake from my side before I open a new report in bugzilla.
The problem I have is that with 2.6.23.[89], the screen turns black
immediately after switching into framebuffer mode. This doesn't happen
Hi,
The kernel build fails with following error message
drivers/char/hvcs.c: In function 'hvcs_open':
drivers/char/hvcs.c:1180: error: wrong type argument to unary exclamation mark
make[2]: *** [drivers/char/hvcs.o] Error 1
make[2]: *** Waiting for unfinished jobs
This driver was broken in
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
---
This addresses a comment of Roland and bumps the version number. If it's not
too late, please apply for 2.6.24. Thanks!
drivers/infiniband/hw/ehca/ehca_classes.h |1 +
drivers/infiniband/hw/ehca/ehca_main.c|2 +-
+static inline void pack_tss(tss_desc *tss, unsigned long addr,
+unsigned size, unsigned entry)
+{
+#ifdef CONFIG_X86_64
+ set_tssldt_descriptor(tss,
+ addr, entry, size);
+#else
+ pack_descriptor(tss, (unsigned
-Original Message-
From: Ingo Molnar [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 13. Dezember 2007 11:30
Users who want to process that huge amount of data would be
better off
using a file-based approach (well, if it cannot be held in physical
memory, they will spend most of their
* Dhaval Giani [EMAIL PROTECTED] wrote:
Could you please see if the following patch removes the oops due to
CFS sysfs files? (There might still be the other oops due to the
floppy sysfs files)
Ingo, could you please add this patch in your CFS backport to 2.6.22
and older kernels?
sure
Hi Greg, Tejun,
The following script causes oomkiller to be invoked on my system here.
while echo; do cat /sys/kernel/kexec_crash_loaded; done
It gets invoked within 10 mins.
[EMAIL PROTECTED] ~]# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model
On Wed, 12 Dec 2007, Paul E. McKenney wrote:
I'm pulling your patch for the above added code. Took me a few hours to
find the culprit, but I was getting scheduling in atomic bugs. Turns out
that this code you put preempt_disable in calls sleeping spinlocks.
Might want to run with
On Thu, 2007-12-13 at 11:11 +0100, Miquel van Smoorenburg wrote:
According to Greg KH:
So, what should be added to 2.6.23-stable then? And, can I get a real
changelog entry for it?
This is suitable for both 2.6.23.x and 2.6.24-rc5 :
linux-2.6-dpt_i2o-no-dma64.patch
Actually, this
* Eric W. Biederman [EMAIL PROTECTED] wrote:
What the heck??? Please solve this properly instead of hiding it.
/proc/timer_stats is damn useful and it's a must-have for powertop
to work.
Hmm. Perhaps the dependency conflict should go in the other direction
then.
My goal is to
* Metzger, Markus T [EMAIL PROTECTED] wrote:
The ptrace API would allow the user to:
- define (and query) the overflow mechanism
(wrap-around or event)
- define (and query) the size of the buffer within certain limits
(we could either give an error or cut off)
- define (and query)
Perhaps what was meant is that ISA-tuned timings make little sense on
devices that are part of the chipset or on the PCI or PCI-X buses?
On the other hand, since we don't know in many cases whether the _p
was supposed to mean the time it takes to execute an out al,80h on
whatever bus
* Dhaval Giani [EMAIL PROTECTED] wrote:
static void user_attr_init(struct subsys_attribute *sa, char *name, int
mode)
{
+ sa-attr.owner = NULL;
sa-attr.name = name;
i'm wondering why doesnt this affect 2.6.23 and later? Does sysfs
initialize the owner field to NULL
On Thu, 13 Dec 2007 08:13:29 -0500
David P. Reed [EMAIL PROTECTED] wrote:
Perhaps what was meant is that ISA-tuned timings make little sense on
devices that are part of the chipset or on the PCI or PCI-X buses?
No.
ISA as LPC bus is alive and well inside and outside chipsets. Welcome to
On Thu, 2007-12-13 at 18:32 +0530, Dhaval Giani wrote:
On Thu, Dec 13, 2007 at 01:55:09PM +0100, Ingo Molnar wrote:
* Dhaval Giani [EMAIL PROTECTED] wrote:
Could you please see if the following patch removes the oops due to
CFS sysfs files? (There might still be the other oops due
On Thu, Dec 13, 2007 at 01:55:09PM +0100, Ingo Molnar wrote:
* Dhaval Giani [EMAIL PROTECTED] wrote:
Could you please see if the following patch removes the oops due to
CFS sysfs files? (There might still be the other oops due to the
floppy sysfs files)
Ingo, could you please add
On Thu, 13 Dec 2007, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
[This patch *is* for mainline Linux]
In commit 76d2160147f43f982dfe881404cfde9fd0a9da21 lazy irq disabling
was implemented, and the simple irq handler had a masking set to it.
thanks, applied. This is
On Thu, Dec 13, 2007 at 06:03:33PM +0530, Dhaval Giani wrote:
Hi Greg, Tejun,
The following script causes oomkiller to be invoked on my system here.
while echo; do cat /sys/kernel/kexec_crash_loaded; done
while echo; do cat /sys/kernel/uevent_seqnum ; done;
causes oomkiller to be
We may be taking a small risk here, but what else do you propose ? The
problem of dangling BARs is real... One option is for me to address it
on powerpc and leave x86 alone as it might be more of an issue with
random crazy embedded firmware for us than it is for x86. As I said, the
workaround
From: Joonwoo Park [EMAIL PROTECTED]
Date: Thu, 13 Dec 2007 19:18:56 +0900
Just blowing netif_running up is not best solution I think, it makes
ifconfig down hang at least for e1000.
It hangs because the packet receive rate is so high that NAPI
poll never exits.
I think we need a cheap
Hi Greg,
On Dec 13, 2007 1:51 AM, Greg KH [EMAIL PROTECTED] wrote:
2.6.23-stable review patch. If anyone has any objections, please let us
know.
--
From: Dmitry Torokhov [EMAIL PROTECTED]
changeset f493018ebc3f94d64e12bc848db0906700bf73a2 in mainline.
Input: ALPS - add
On Thursday 13 December 2007 02:17:16 Ray Lee wrote:
On Dec 12, 2007 4:48 PM, Michael Buesch [EMAIL PROTECTED] wrote:
This driver is scheduled for removal, so I'd not touch it anymore
to avoid the possibility to introduce a lastminute regression.
The new drivers (b43 and b43legacy) have
From: Jarek Poplawski [EMAIL PROTECTED]
Date: Thu, 13 Dec 2007 14:49:53 +0100
As a matter of fact, since it's unlikely() in net_rx_action() anyway,
I wonder what is the main reason or gain of leaving such a tricky
exception, instead of letting drivers to always decide which is the
best moment
On 12-12-2007 19:41, Kok, Auke wrote:
David Miller wrote:
From: Andrew Gallatin [EMAIL PROTECTED]
Date: Wed, 12 Dec 2007 12:29:23 -0500
Is the netif_running() check even required?
No, it is not.
When a device is brought down, one of the first things
that happens is that we wait for all
On Thu, 2007-12-13 at 08:12 -0500, Ingo Molnar wrote:
* Dhaval Giani [EMAIL PROTECTED] wrote:
static void user_attr_init(struct subsys_attribute *sa, char
*name, int mode)
{
+ sa-attr.owner = NULL;
sa-attr.name = name;
i'm wondering why doesnt this affect 2.6.23 and
Hi,
My config does not link any more:
...
CHK include/linux/compile.h
UPD include/linux/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
net/built-in.o: In function `xs_udp_data_ready':
From: Andrew Gallatin [EMAIL PROTECTED]
Date: Thu, 13 Dec 2007 09:13:54 -0500
If the netif_running() check is indeed required to make a device break
out of napi polling and respond to an ifconfig down, then I think the
netif_running() check should be moved up into net_rx_action() to avoid
Joonwoo Park wrote:
2007/12/13, Kok, Auke [EMAIL PROTECTED]:
David Miller wrote:
From: Andrew Gallatin [EMAIL PROTECTED]
Date: Wed, 12 Dec 2007 12:29:23 -0500
Is the netif_running() check even required?
No, it is not.
When a device is brought down, one of the first things
that happens
On Thu, Dec 13, 2007 at 03:16:27PM +0100, Guillaume Chazarain wrote:
On Dec 13, 2007 2:48 PM, Andi Kleen [EMAIL PROTECTED] wrote:
2.6.24-rc5 doesn't seem to create Makefiles in empty obj dirs anymore
Known problem ;-)
See
This fixes a sparse warning about symbol tmout shadowing an earlier one.
Signed-off-by: Andre Haupt [EMAIL PROTECTED]
---
drivers/serial/8250.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index f94109c..284757d 100644
---
On Thu, 2007-12-13 at 13:55 +0100, Ingo Molnar wrote:
* Dhaval Giani [EMAIL PROTECTED] wrote:
Could you please see if the following patch removes the oops due to
CFS sysfs files? (There might still be the other oops due to the
floppy sysfs files)
Ingo, could you please add this
2.6.24-rc5 doesn't seem to create Makefiles in empty obj dirs anymore
With 2.6.24-rc5:
% mkdir obj-test
% cd obj-test/
% make -C ../linux O=$(pwd) allnoconfig /dev/null
grep: /home/lsrc/quilt/obj-test/Makefile: No such file or directory
% make
make: *** No targets specified and no makefile
On Thu, Dec 13, 2007 at 05:50:13AM -0800, David Miller wrote:
From: Jarek Poplawski [EMAIL PROTECTED]
Date: Thu, 13 Dec 2007 14:49:53 +0100
As a matter of fact, since it's unlikely() in net_rx_action() anyway,
I wonder what is the main reason or gain of leaving such a tricky
exception,
On Dec 13, 2007 2:48 PM, Andi Kleen [EMAIL PROTECTED] wrote:
2.6.24-rc5 doesn't seem to create Makefiles in empty obj dirs anymore
Known problem ;-)
See
http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/188cbd12d7c0871b/194fbc7c94314b2c
--
Guillaume
--
To unsubscribe from
Davide, Andrew,
I applied Davide's v3 patchset (sent into LKML on 25 Nov) against
2.4.24-rc3, and did various tests (all on x86). Several tests
were done using the program at the foot of this mail. Various others
were done by cobbling together bits of code that I haven't included
here.
In
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/agk/linux-2.6-dm.git
to get the following device-mapper fixes for 2.6.24:
Alasdair G Kergon (1):
dm: trigger change uevent on rename
Jun'ichi Nomura (1):
dm: table detect io beyond device
Milan Broz (2):
dm
On Sat, 8 Dec 2007 14:07:47 +
Christoph Hellwig [EMAIL PROTECTED] wrote:
+ mutex_lock(nlmsvc_mutex);
+ while (atomic_read(nlmsvc_ref) != 0) {
might be better to do the refcounting outside the thread and use the
kthread api, which is something we still need to do for lockd anyway.
On Thu, Dec 13, 2007 at 01:24:26PM +, Vincent Fortier wrote:
On Thu, 2007-12-13 at 18:32 +0530, Dhaval Giani wrote:
On Thu, Dec 13, 2007 at 01:55:09PM +0100, Ingo Molnar wrote:
* Dhaval Giani [EMAIL PROTECTED] wrote:
Could you please see if the following patch removes the
Ok, new patch attached, taking into account Andi's request for a cleaner method
to implement single application quirks. I've spoken with Ben, who is continuing
to retest, and reports that clean methodical testing results in success with
this patch.
Summary:
Recently a kdump bug was discovered
From: Jun'ichi Nomura [EMAIL PROTECTED]
This patch fixes a panic on shrinking a DM device if there is
outstanding I/O to the part of the device that is being removed.
(Normally this doesn't happen - a filesystem would be resized first,
for example.)
The bug is that __clone_and_map() assumes
1 - 100 of 1064 matches
Mail list logo
