This deadlock happens, when dirty pages from one filesystem are
written back through another filesystem. It easiest to demonstrate
with fuse although it could affect looback mounts as well (see
following patches).
Let's call the filesystems A(bove) and B(elow). Process Pr_a is
From: Miklos Szeredi [EMAIL PROTECTED]
This deadlock is similar to the one in balance_dirty_pages, but
instead of waiting in balance_dirty_pages after submitting a write
request, it happens during a memory allocation for filesystem B before
submitting a write request.
It is easy
On Wed, Feb 28, 2007 at 07:36:17AM -0800, Greg KH wrote:
On Tue, Feb 27, 2007 at 05:27:41PM -0800, Jean Tourrilhes wrote:
diff -u -p linux/drivers/base/class.j1.c linux/drivers/base/class.c
--- linux/drivers/base/class.j1.c 2007-02-26 18:38:10.0 -0800
+++
On Wed, Feb 28, 2007 at 10:34:37AM +0100, Jarek Poplawski wrote:
On 28-02-2007 02:27, Jean Tourrilhes wrote:
Hi all,
...
Patch for 2.6.20 is attached. The patch was tested on a system
running the hotplug scripts, and on another system running udev.
Have fun...
On Wed, Feb 28, 2007 at 10:16:05AM +0100, Johannes Berg wrote:
Hi,
Patch for 2.6.20 is attached.
... and in the meantime netdevices aren't class_device any more :) IOW,
your patch isn't going to work any more.
That's why I always specify the kernel version. I'll look into
On Wed, 2007-02-28 at 10:51 -0800, Jean Tourrilhes wrote:
That's why I always specify the kernel version. I'll look into
that, I'm sure it's not the end of the world ;-)
Sure, just wanted to point it out.
In which sense ? Wireless interface are regular netdevices.
Yeah but in
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]
Index: b/drivers/net/mv643xx_eth.c
We had been using the platform_device.id field to identify which ethernet
port is used for mv643xx_eth device. This is not correct in general.
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_number field
to struct
On Wed, 28 Feb 2007 15:40:31 -0700
Dale Farnsworth [EMAIL PROTECTED] 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
On Wed, Feb 28, 2007 at 03:11:03PM -0800, Stephen Hemminger wrote:
On Wed, 28 Feb 2007 15:40:31 -0700
Dale Farnsworth [EMAIL PROTECTED] wrote:
The information contained within platform_data should be self-contained.
Replace the pointer to a MAC address with the actual MAC address in
On Wed, Feb 28, 2007 at 07:36:17AM -0800, Greg KH wrote:
On Tue, Feb 27, 2007 at 05:27:41PM -0800, Jean Tourrilhes wrote:
diff -u -p linux/drivers/base/class.j1.c linux/drivers/base/class.c
--- linux/drivers/base/class.j1.c 2007-02-26 18:38:10.0 -0800
+++
On Wed, 2007-02-28 at 16:26 -0800, Jean Tourrilhes wrote:
+ /* This function is only used for network interface.
+ * Some hotplug package track interfaces by their name and
+ * therefore want to know when the name is changed by the user. */
Right now, that's true, but wireless
On Thu, Mar 01, 2007 at 01:37:46AM +0100, Johannes Berg wrote:
On Wed, 2007-02-28 at 16:26 -0800, Jean Tourrilhes wrote:
+ /* This function is only used for network interface.
+* Some hotplug package track interfaces by their name and
+* therefore want to know when the name is
On Wed, 2007-02-28 at 16:51 -0800, Jean Tourrilhes wrote:
I would prefer to fix the comment when this change actually
happens. I prefer comments to refer to the current reality, rather
than past/future situation.
Uh, no. device_rename is perfectly fine, even other people may use it in
Hi folks,
Here is the blackfin on-chip ethernet MAC controller driver for Linux.
It's name is blackfin-driver-net-stamp537.patch
[PATCH] Blackfin: on-chip ethernet MAC controller driver
This patch implements the driver necessary use the Analog Devices
Blackfin processor's on-chip ethernet MAC
On Wed, 28 Feb 2007 10:12:01 +0100 (CET) Jaroslav Kysela [EMAIL PROTECTED]
wrote:
Hi,
please, review and apply to mm tree for further testing. The patch
is also available at
ftp://ftp.alsa-project.org/pub/kernel-patches/bonding-workqueue.patch .
Please cc netdev@vger.kernel.org on
On Wed, Feb 28, 2007 at 10:45:41AM -0800, Jean Tourrilhes wrote:
On Wed, Feb 28, 2007 at 10:34:37AM +0100, Jarek Poplawski wrote:
On 28-02-2007 02:27, Jean Tourrilhes wrote:
Hi all,
...
Patch for 2.6.20 is attached. The patch was tested on a system
running the hotplug scripts,
so will the 1st acpi_table_init() always fail -- even
on future machines?
-Len
On Wednesday 28 February 2007 18:47, John Keller wrote:
To provide compatibilty with SN kernels that do and do not
have ACPI IO support, the SN PROM must build different
versions of some ACPI tables based on which
On Wednesday 28 February 2007 07:45, Rafael J. Wysocki wrote:
This gives:
(gdb) l *evdev_disconnect+0xb1
0xa81 is in evdev_disconnect (include/asm/processor.h:716).
711However we don't do prefetches for pre XP Athlons currently
712That should be fixed. */
713
With the advent of kdump, the assumption that the boot CPU when running
an UP kernel is always the CPU with a hardware ID of 0 (usually referred
to as BSP on some architectures) does not hold true anymore. The reason
being that the dump capture kernel boots on the crashed CPU (the CPU
that invoked
With the advent of kdump, the assumption that the boot CPU when booting
an UP kernel is always the CPU with a hardware ID of 0 (usually referred
to as BSP on some architectures) is not valid anymore.
Signed-off-by: Fernando Luis Vazquez Cao [EMAIL PROTECTED]
---
diff -urNp
Use the APIC to determine the hardware processor id when APIC support
has been selected, independently of whether CONFIG_SMP is set or not.
Signed-off-by: Fernando Luis Vazquez Cao [EMAIL PROTECTED]
---
diff -urNp linux-2.6.21-rc2/include/asm-i386/smp.h
Use the APIC to determine the hardware processor id in both UP and SMP
kernels.
Signed-off-by: Fernando Luis Vazquez Cao [EMAIL PROTECTED]
---
diff -urNp linux-2.6.21-rc2/include/asm-x86_64/smp.h
linux-2.6.21-rc2-hwcpuid/include/asm-x86_64/smp.h
--- linux-2.6.21-rc2/include/asm-x86_64/smp.h
Always ask the hardware to determine the hardware processor id in both UP and
SMP kernels.
Signed-off-by: Fernando Luis Vazquez Cao [EMAIL PROTECTED]
---
diff -urNp linux-2.6.21-rc2/include/asm-ia64/smp.h
linux-2.6.21-rc2-hwcpuid/include/asm-ia64/smp.h
---
Move definition of hard_smp_processor_id to asm/smp.h on alpha, m32r,
powerpc, s390, sparc, sparc64, and um architectures.
Signed-off-by: Fernando Luis Vazquez Cao [EMAIL PROTECTED]
---
diff -urNp linux-2.6.21-rc2/include/asm-alpha/smp.h
linux-2.6.21-rc2-hwcpuid/include/asm-alpha/smp.h
---
On Thu, Mar 01, 2007 at 04:16:59PM +0900, Fernando Luis Vázquez Cao wrote:
Use the APIC to determine the hardware processor id when APIC support
has been selected, independently of whether CONFIG_SMP is set or not.
Signed-off-by: Fernando Luis Vazquez Cao [EMAIL PROTECTED]
---
diff -urNp
On Wed, Feb 28, 2007 at 01:45:17PM -0600, John Keller wrote:
Add a missing #define for the platform_kernel_launch_event.
Without this fix, a call to platform_kernel_launch_event()
becomes a noop on generic kernels. SN systems require this
fix to successfully kdump/kexec from certain hardware
This patch fixes two issues reported by Roland and Christoph H.:
- Mismatched sync/locking between completion handler and destroy cq
We introduced a counter nr_events per cq to track number of irq
events seen. This counter is incremented when an event queue
entry is seen and decremented
701 - 728 of 728 matches
Mail list logo
