Re: In-tree version of new FireWire drivers available

[Andrew Morton]

On Tue, 23 Jan 2007 22:48:15 -0500
"Kristian Høgsberg" <[EMAIL PROTECTED]> wrote:

> I've moved the new FireWire stack to an in-tree git repository and
> moved over the missing patches from my out-of-tree version.

arm:

drivers/firewire/fw-device.c: In function `fw_device_init':
drivers/firewire/fw-device.c:495: warning: implicit declaration of function 
`cmpxchg'   


We can't use cmpxchg in generic code.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] Altix: Add ACPI SSDT PCI device support (hotplug)

[Len Brown]

From: John Keller <[EMAIL PROTECTED]>

Support for dynamic loading and unloading of ACPI SSDT tables upon slot
hotplugs and unplugs.

On SN platforms, we now represent every populated root bus slot with a single
ACPI SSDT table containing info for every device and PPB attached to the slot.
 These SSDTs are generated by the prom at initial boot and hotplug time.  The
info in these SSDT tables is used by the SN kernel IO "fixup" code (which is
called at boot and hotplug time).

On hotplugs (i.e.  enable_slot()), if running with an ACPI capable prom,
attempt to obtain a new ACPI SSDT table for the slot being hotplugged.  If
successful, add the table to the ACPI namespace (acpi_load_table()) and then
walk the new devices and add them to the ACPI infrastructure (acpi_bus_add()).

On hot unplugs (i.e.  disable_slot()), if running with an ACPI capable prom,
attempt to remove the SSDT table associated with the slot from the ACPI
namespace (acpi_unload_table_id()) and infastructure (acpi_bus_trim()).

From: John Keller <[EMAIL PROTECTED]>

 A bug was fixed where the sgi hotplug driver was removing
 the slot's SSDT table from the ACPI namespace a bit too early in
 disable_slot(). Also, we now call acpi_bus_start() subsequent
 to acpi_bus_add().

Signed-off-by: Aaron Young <[EMAIL PROTECTED]>
Cc: Greg KH <[EMAIL PROTECTED]>
Cc: "Luck, Tony" <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Len Brown<[EMAIL PROTECTED]>
---

 drivers/pci/hotplug/sgi_hotplug.c |  155 ++--
 1 files changed, 148 insertions(+), 7 deletions(-)

Index: acpi/drivers/pci/hotplug/sgi_hotplug.c
===
--- acpi.orig/drivers/pci/hotplug/sgi_hotplug.c
+++ acpi/drivers/pci/hotplug/sgi_hotplug.c
@@ -28,6 +28,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "../pci.h"
 
@@ -35,14 +37,17 @@ MODULE_LICENSE("GPL");
 MODULE_AUTHOR("SGI ([EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED])");
 MODULE_DESCRIPTION("SGI Altix Hot Plug PCI Controller Driver");
 
-#define PCIIO_ASIC_TYPE_TIOCA  4
+
+/* SAL call error codes. Keep in sync with prom header io/include/pcibr.h */
 #define PCI_SLOT_ALREADY_UP2   /* slot already up */
 #define PCI_SLOT_ALREADY_DOWN  3   /* slot already down */
 #define PCI_L1_ERR 7   /* L1 console command error */
 #define PCI_EMPTY_33MHZ15  /* empty 33 MHz bus */
+
+
+#define PCIIO_ASIC_TYPE_TIOCA  4
 #define PCI_L1_QSIZE   128 /* our L1 message buffer size */
 #define SN_MAX_HP_SLOTS32  /* max hotplug slots */
-#define SGI_HOTPLUG_PROM_REV   0x0430  /* Min. required PROM version */
 #define SN_SLOT_NAME_SIZE  33  /* size of name string */
 
 /* internal list head */
@@ -227,7 +232,7 @@ static void sn_bus_free_data(struct pci_
 }
 
 static int sn_slot_enable(struct hotplug_slot *bss_hotplug_slot,
- int device_num)
+ int device_num, char **ssdt)
 {
struct slot *slot = bss_hotplug_slot->private;
struct pcibus_info *pcibus_info;
@@ -240,7 +245,8 @@ static int sn_slot_enable(struct hotplug
 * Power-on and initialize the slot in the SN
 * PCI infrastructure.
 */
-   rc = sal_pcibr_slot_enable(pcibus_info, device_num, );
+   rc = sal_pcibr_slot_enable(pcibus_info, device_num, , ssdt);
+
 
if (rc == PCI_SLOT_ALREADY_UP) {
dev_dbg(slot->pci_bus->self, "is already active\n");
@@ -335,6 +341,7 @@ static int enable_slot(struct hotplug_sl
int func, num_funcs;
int new_ppb = 0;
int rc;
+   char *ssdt = NULL;
void pcibios_fixup_device_resources(struct pci_dev *);
 
/* Serialize the Linux PCI infrastructure */
@@ -342,14 +349,29 @@ static int enable_slot(struct hotplug_sl
 
/*
 * Power-on and initialize the slot in the SN
-* PCI infrastructure.
+* PCI infrastructure. Also, retrieve the ACPI SSDT
+* table for the slot (if ACPI capable PROM).
 */
-   rc = sn_slot_enable(bss_hotplug_slot, slot->device_num);
+   rc = sn_slot_enable(bss_hotplug_slot, slot->device_num, );
if (rc) {
mutex_unlock(_hotplug_mutex);
return rc;
}
 
+   if (ssdt)
+   ssdt = __va(ssdt);
+   /* Add the new SSDT for the slot to the ACPI namespace */
+   if (SN_ACPI_BASE_SUPPORT() && ssdt) {
+   acpi_status ret;
+
+   ret = acpi_load_table((struct acpi_table_header *)ssdt);
+   if (ACPI_FAILURE(ret)) {
+   printk(KERN_ERR "%s: acpi_load_table failed (0x%x)\n",
+  __FUNCTION__, ret);
+   /* try to continue on */
+   }
+   }
+
num_funcs = 

[PATCH 2/3] Altix: ACPI SSDT PCI device support

[Len Brown]

From: John Keller <[EMAIL PROTECTED]>

Add SN platform support for running with an ACPI
capable PROM that defines PCI devices in SSDT
tables. There is a SSDT table for every occupied
slot on a root bus, containing info for every
PPB and/or device on the bus. The SSDTs will be
dynamically loaded/unloaded at hotplug enable/disable.

Platform specific information that is currently
passed via a SAL call, will now be passed via the
Vendor resource in the ACPI Device object(s) defined
in each SSDT.

Signed-off-by: John Keller <[EMAIL PROTECTED]>
Cc: Greg KH <[EMAIL PROTECTED]>
Cc: "Luck, Tony" <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---

 arch/ia64/sn/kernel/io_acpi_init.c  |  314 +---
 arch/ia64/sn/kernel/io_common.c |   83 +---
 arch/ia64/sn/kernel/io_init.c   |   54 -
 arch/ia64/sn/pci/pcibr/pcibr_provider.c |6
 include/asm-ia64/sn/acpi.h  |5
 include/asm-ia64/sn/pcibr_provider.h|2
 include/asm-ia64/sn/pcidev.h|8
 7 files changed, 368 insertions(+), 104 deletions(-)

Index: acpi/arch/ia64/sn/kernel/io_acpi_init.c
===
--- acpi.orig/arch/ia64/sn/kernel/io_acpi_init.c
+++ acpi/arch/ia64/sn/kernel/io_acpi_init.c
@@ -13,6 +13,7 @@
 #include 
 #include "xtalk/hubdev.h"
 #include 
+#include 
 
 
 /*
@@ -31,6 +32,12 @@ struct acpi_vendor_uuid sn_uuid = {
0xa2, 0x7c, 0x08, 0x00, 0x69, 0x13, 0xea, 0x51 },
 };
 
+struct sn_pcidev_match {
+   u8 bus;
+   unsigned int devfn;
+   acpi_handle handle;
+};
+
 /*
  * Perform the early IO init in PROM.
  */
@@ -119,9 +126,11 @@ sn_get_bussoft_ptr(struct pci_bus *bus)
status = acpi_get_vendor_resource(handle, METHOD_NAME__CRS,
  _uuid, );
if (ACPI_FAILURE(status)) {
-   printk(KERN_ERR "get_acpi_pcibus_ptr: "
-  "get_acpi_bussoft_info() failed: %d\n",
-  status);
+   printk(KERN_ERR "%s: "
+  "acpi_get_vendor_resource() failed (0x%x) for: ",
+  __FUNCTION__, status);
+   acpi_ns_print_node_pathname(handle, NULL);
+   printk("\n");
return NULL;
}
resource = buffer.pointer;
@@ -130,8 +139,8 @@ sn_get_bussoft_ptr(struct pci_bus *bus)
if ((vendor->byte_length - sizeof(struct acpi_vendor_uuid)) !=
 sizeof(struct pcibus_bussoft *)) {
printk(KERN_ERR
-  "get_acpi_bussoft_ptr: Invalid vendor data "
-  "length %d\n", vendor->byte_length);
+  "%s: Invalid vendor data length %d\n",
+   __FUNCTION__, vendor->byte_length);
kfree(buffer.pointer);
return NULL;
}
@@ -143,34 +152,254 @@ sn_get_bussoft_ptr(struct pci_bus *bus)
 }
 
 /*
- * sn_acpi_bus_fixup
+ * sn_extract_device_info - Extract the pcidev_info and the sn_irq_info
+ * pointers from the vendor resource using the
+ * provided acpi handle, and copy the structures
+ * into the argument buffers.
  */
-void
-sn_acpi_bus_fixup(struct pci_bus *bus)
+static int
+sn_extract_device_info(acpi_handle handle, struct pcidev_info **pcidev_info,
+   struct sn_irq_info **sn_irq_info)
 {
-   struct pci_dev *pci_dev = NULL;
-   struct pcibus_bussoft *prom_bussoft_ptr;
-   extern void sn_common_bus_fixup(struct pci_bus *,
-   struct pcibus_bussoft *);
+   u64 addr;
+   struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+   struct sn_irq_info *irq_info, *irq_info_prom;
+   struct pcidev_info *pcidev_ptr, *pcidev_prom_ptr;
+   struct acpi_resource *resource;
+   int ret = 0;
+   acpi_status status;
+   struct acpi_resource_vendor_typed *vendor;
 
-   if (!bus->parent) { /* If root bus */
-   prom_bussoft_ptr = sn_get_bussoft_ptr(bus);
-   if (prom_bussoft_ptr == NULL) {
+   /*
+* The pointer to this device's pcidev_info structure in
+* the PROM, is in the vendor resource.
+*/
+   status = acpi_get_vendor_resource(handle, METHOD_NAME__CRS,
+ _uuid, );
+   if (ACPI_FAILURE(status)) {
+   printk(KERN_ERR
+  "%s: acpi_get_vendor_resource() failed (0x%x) for: ",
+   __FUNCTION__, status);
+   acpi_ns_print_node_pathname(handle, NULL);
+   printk("\n");
+   return 1;
+   }
+
+   resource = buffer.pointer;
+   vendor = >data.vendor_typed;
+   if ((vendor->byte_length - sizeof(struct acpi_vendor_uuid)) !=
+   sizeof(struct pci_devdev_info *)) 

[PATCH] ACPI: Correct apparent typo "CONFIG_ACPI_DEBUG_OUTPUT".

[Robert P. J. Day]

  Replace the apparent typo CONFIG_ACPI_DEBUG_OUTPUT with
the non-Kconfig conditional ACPI_DEBUG_OUTPUT, which is what every
other file uses.

Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>

---

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 698a154..d65142a 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -891,7 +891,7 @@ static int acpi_device_set_context(struct acpi_device 
*device, int type)
 static void acpi_device_get_debug_info(struct acpi_device *device,
   acpi_handle handle, int type)
 {
-#ifdef CONFIG_ACPI_DEBUG_OUTPUT
+#ifdef ACPI_DEBUG_OUTPUT
char *type_string = NULL;
char name[80] = { '?', '\0' };
struct acpi_buffer buffer = { sizeof(name), name };
@@ -928,7 +928,7 @@ static void acpi_device_get_debug_info(struct acpi_device 
*device,
}

printk(KERN_DEBUG "Found %s %s [%p]\n", type_string, name, handle);
-#endif /*CONFIG_ACPI_DEBUG_OUTPUT */
+#endif /* ACPI_DEBUG_OUTPUT */
 }

 static int acpi_bus_remove(struct acpi_device *dev, int rmdevice)

-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://www.fsdev.dreamhosters.com/wiki/index.php?title=Main_Page

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] - ACPICA: reduce conflicts with Altix patch series

[Len Brown]

Syntax only -- no functional changes.

Signed-off-by: Len Brown <[EMAIL PROTECTED]
---
 arch/ia64/sn/kernel/io_common.c |   10 ++
 arch/ia64/sn/kernel/iomv.c  |5 ++---
 include/asm-ia64/sn/acpi.h  |   18 ++
 3 files changed, 26 insertions(+), 7 deletions(-)

Index: acpi/arch/ia64/sn/kernel/io_common.c
===
--- acpi.orig/arch/ia64/sn/kernel/io_common.c
+++ acpi/arch/ia64/sn/kernel/io_common.c
@@ -25,6 +25,7 @@
 #include "xtalk/xwidgetdev.h"
 #include 
 #include 
+#include 
 
 extern void sn_init_cpei_timer(void);
 extern void register_sn_procfs(void);
@@ -36,6 +37,7 @@ extern void sn_legacy_pci_window_fixup(s
 extern void sn_io_acpi_init(void);
 extern void sn_io_init(void);
 
+
 static struct list_head sn_sysdata_list;
 
 /* sysdata list struct */
@@ -48,7 +50,7 @@ int sn_ioif_inited;   /* SN I/O infrastru
 
 struct sn_pcibus_provider *sn_pci_provider[PCIIO_ASIC_MAX_TYPES];  /* 
indexed by asic type */
 
-int sn_acpi_base_support()
+int sn_acpi_base_support(void)
 {
struct acpi_table_header *header;
(void)acpi_get_table_by_index(ACPI_TABLE_INDEX_DSDT, );
@@ -293,7 +295,7 @@ void sn_pci_fixup_slot(struct pci_dev *d
list_add_tail(_info->pdi_list,
  &(SN_PLATFORM_DATA(dev->bus)->pcidev_info));
 
-   if (sn_acpi_base_support())
+   if (SN_ACPI_BASE_SUPPORT())
sn_acpi_slot_fixup(dev, pcidev_info);
else
sn_more_slot_fixup(dev, pcidev_info);
@@ -505,7 +507,7 @@ void __devinit
 sn_pci_fixup_bus(struct pci_bus *bus)
 {
 
-   if (sn_acpi_base_support())
+   if (SN_ACPI_BASE_SUPPORT())
sn_acpi_bus_fixup(bus);
else
sn_bus_fixup(bus);
@@ -557,7 +559,7 @@ sn_io_early_init(void)
printk(KERN_INFO "ACPI  DSDT OEM Rev 0x%x\n",
header->oem_revision);
}
-   if (sn_acpi_base_support())
+   if (SN_ACPI_BASE_SUPPORT())
sn_io_acpi_init();
else
sn_io_init();
Index: acpi/arch/ia64/sn/kernel/iomv.c
===
--- acpi.orig/arch/ia64/sn/kernel/iomv.c
+++ acpi/arch/ia64/sn/kernel/iomv.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define IS_LEGACY_VGA_IOPORT(p) \
(((p) >= 0x3b0 && (p) <= 0x3bb) || ((p) >= 0x3c0 && (p) <= 0x3df))
@@ -29,8 +30,6 @@
  * SN i/o address.  Used by sn_in*() and sn_out*().
  */
 
-extern int sn_acpi_base_support();
-
 void *sn_io_addr(unsigned long port)
 {
if (!IS_RUNNING_ON_SIMULATOR()) {
@@ -39,7 +38,7 @@ void *sn_io_addr(unsigned long port)
/* On sn2, legacy I/O ports don't point at anything */
if (port < (64 * 1024))
return NULL;
-   if (sn_acpi_base_support())
+   if (SN_ACPI_BASE_SUPPORT())
return (__ia64_mk_io_addr(port));
else
return ((void *)(port | __IA64_UNCACHED_OFFSET));
Index: acpi/include/asm-ia64/sn/acpi.h
===
--- /dev/null
+++ acpi/include/asm-ia64/sn/acpi.h
@@ -0,0 +1,18 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 2006 Silicon Graphics, Inc. All rights reserved.
+ */
+
+#ifndef _ASM_IA64_SN_ACPI_H
+#define _ASM_IA64_SN_ACPI_H
+
+#include "acpi/acglobal.h"
+
+#define SN_ACPI_BASE_SUPPORT()   sn_acpi_base_support()
+
+extern int sn_acpi_base_support(void);
+
+#endif /* _ASM_IA64_SN_ACPI_H */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] - Altix: ACPI SSDT PCI device support

[Len Brown]

On Friday 26 January 2007 20:10, Andrew Morton wrote:
> On Wed, 15 Nov 2006 09:24:54 -0600
> John Keller <[EMAIL PROTECTED]> wrote:
> 
> > Add SN platform support for running with an ACPI
> > capable PROM that defines PCI devices in SSDT
> > tables. There is a SSDT table for every occupied
> > slot on a root bus, containing info for every
> > PPB and/or device on the bus. The SSDTs will be
> > dynamically loaded/unloaded at hotplug enable/disable.
> 
> An additional 600kb of diff has just popped up in the ACPI tree, so none of
> this patch applies any more.  I'll need to drop it again, sorry.
> 
> It's been over two months - I'm not sure why things are so difficult for
> this patchset.

it is because
1. this didn't make it into 2.6.20 before -rc1, and Linus prohibits adding 
features thereafter
2. these patches simultaneously depend on ACPI, hotplug, and IA64 platform 
dependent code,
so it isn't always clear who owns them.  However, if Greg and Tony Ack them,
I'll be happy to carry them upstream with the ACPI tree.

I'll reply to this note with a shim patch to help these apply, and a  pair of 
refreshed SGI patches
that apply on top of the ACPI tree.  Build tested vs sn2_defconfig , but SGI 
will have to test it on hardware.

thanks,
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: git.kernel.org move (finally)... estimated week of Feb 5

[Oleg Verych]

27-01-2007, H. Peter Anvin:
> Just for everyone's information...
>
> The git performance issues (especially) on kernel.org has been very 
> frustrating, obviously.  We're putting a dedicated git server in place 
> hopefully the week of February 5.

Thanks.

Hope it will have fast git-web face also.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

scripts/makelst: bc -> shell Re: sed _s_gnu_alternatives_ (Re: [rft] (g)awk substitution)

[Oleg Verych]

Hallo.

On Sat, Jan 27, 2007 at 01:18:30AM +0100, Tim Schmielau wrote:
> On Fri, 26 Jan 2007, Oleg Verych wrote:
> 
> > In Debian's version it has no `bc', while native `bc' is producing
> > crap like that:
> > ,-*- bash -*-
> > |[EMAIL PROTECTED]:~$ printf "%u" $(( -1 )) ; echo
> > |18446744073709551615
> > |[EMAIL PROTECTED]:~$ echo -1 | bc
> > |-1
> > |[EMAIL PROTECTED]:~$ printf "%u" $(( 0xFF )) ; echo
> > |255
> > |[EMAIL PROTECTED]:~$ echo FF | bc
> > |99
> > |[EMAIL PROTECTED]:~$ echo F | bc
> > |15
> > |[EMAIL PROTECTED]:~$
> > `-*-
> > 
> > i can't understand the result... I think linux/scripts/makelst may be
> > updated to have sh's version of address calculation ;)
> 
> No, IMHO that should not be a reason to change anything in the kernel.
> Just set ibase=16 or read the fine manual:

Thank you very much ;) Maybe i must use XSLT with 0.99 kernel, or
what?

I'm talking about patch posted here:
Message-ID: <[EMAIL PROTECTED]>
Archived-At: 

,-*- diff snip -*-
|-t4=`echo $t3 | gawk '{ print $1 }'`
|-t5=`echo $t1 | gawk '{ print $1 }'`
|+t4=`pos_param 1 $t3`
|+t5=`pos_param 1 $t1`
5 t6=`echo $t4 - $t5 | tr a-f A-F`
6 t7=`( echo  ibase=16 ; echo $t6 ) | bc`
`-*-

I've just noticed, that things on lines 5 and 6 may be optimized.

t7=`printf "%lu" $(( 0x$t4 - 0x$t5 ))`

No tr, no bc, no pipes -- magic!
Better know and use our *fine shell*.

And if you jouined us, Tim, maybe can share your experience and test
patch above and this one, please?
Message-ID: <[EMAIL PROTECTED]>
Archived-At: 

It's just my optimization hint. I have no bc, and i'm sure
things, like that will cause silent misinformation.

Anyway, what is so bad in `sh'?

Thanks.

-*- OT -*-
>   info '(bc)About Expressions and Special Variables'
GFDL. Enough of that bull, even Documentation/ is *free* from it.

Good bye.
--
-o--=O`C  info emacs : not found  /. .\ ( is there any reason to live? )
 #oo'L O  info make  : not found  o (yes --- R.I.P. FSF+RMS)
<___=E M  man gcc: not found`-- ( viva Debian Operating System )
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Hidden SSID's

[Larry Finger]

Is there a convention regarding the information that a wireless MAC layer 
should provide when
reporting scan data from an AP with a hidden SSID?

In ieee80211, the software inserts the string "" for such an AP, which 
seems to give
wpa_supplicant fits because it rejects the SSID before even looking at the 
encryption data. Is this
the normal convention?

Thanks,

Larry


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ahci: Marvell 6145 SATA support (preliminary)

[Jeff Garzik]

The bulk of this patch is largely paranoia-based changes, that turn off
various PATA-related bits.

The SATA portion of this patch is verified working... if I disable
CONFIG_PCI_MSI and CONFIG_PCI_MMCONFIG.  If those are not disabled, then
my ICH9 test box dies in an interrupt storm.  Booting with acpi=off does
not prevent this interrupt storm.

Were it not for the PATA and interrupt storm bits, I would say that
Marvell 6145 works with a simple PCI ID addition.

 drivers/ata/ahci.c |   53 -
 1 files changed, 52 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index e3c7b31..abe6ea4 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -81,6 +81,7 @@ enum {
board_ahci_pi   = 1,
board_ahci_vt8251   = 2,
board_ahci_ign_iferr= 3,
+   board_ahci_mv   = 4,
 
/* global controller registers */
HOST_CAP= 0x00, /* host capabilities */
@@ -172,6 +173,7 @@ enum {
AHCI_FLAG_NO_NCQ= (1 << 24),
AHCI_FLAG_IGN_IRQ_IF_ERR= (1 << 25), /* ignore IRQ_IF_ERR */
AHCI_FLAG_HONOR_PI  = (1 << 26), /* honor PORTS_IMPL */
+   AHCI_FLAG_MV_PATA   = (1 << 27), /* port 4 == PATA */
 };
 
 struct ahci_cmd_hdr {
@@ -352,6 +354,17 @@ static const struct ata_port_info ahci_port_info[] = {
.udma_mask  = 0x7f, /* udma0-6 ; FIXME */
.port_ops   = _ops,
},
+   /* board_ahci_mv */
+   {
+   .sht= _sht,
+   .flags  = ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
+ ATA_FLAG_MMIO | ATA_FLAG_PIO_DMA |
+ ATA_FLAG_SKIP_D2H_BSY | AHCI_FLAG_HONOR_PI |
+ AHCI_FLAG_MV_PATA,
+   .pio_mask   = 0x1f, /* pio0-4 */
+   .udma_mask  = 0x7f, /* udma0-6 ; FIXME */
+   .port_ops   = _ops,
+   },
 };
 
 static const struct pci_device_id ahci_pci_tbl[] = {
@@ -424,6 +437,9 @@ static const struct pci_device_id ahci_pci_tbl[] = {
{ PCI_VDEVICE(SI, 0x1185), board_ahci }, /* SiS 966 */
{ PCI_VDEVICE(SI, 0x0186), board_ahci }, /* SiS 968 */
 
+   /* Marvell */
+   { PCI_VDEVICE(MARVELL, 0x6145), board_ahci_mv },/* 6145 */
+
/* Generic, PCI class code for AHCI */
{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
  0x010601, 0xff, board_ahci },
@@ -690,13 +706,27 @@ static void ahci_init_controller(void __iomem *mmio, 
struct pci_dev *pdev,
 int n_ports, unsigned int port_flags,
 struct ahci_host_priv *hpriv)
 {
+   void __iomem *port_mmio;
int i, rc;
u32 tmp;
 
+   if (port_flags & AHCI_FLAG_MV_PATA) {
+   port_mmio = ahci_port_base(mmio, 4);
+
+   writel(0, port_mmio + PORT_IRQ_MASK);
+
+   /* clear port IRQ */
+   tmp = readl(port_mmio + PORT_IRQ_STAT);
+   VPRINTK("PORT_IRQ_STAT 0x%x\n", tmp);
+   if (tmp)
+   writel(tmp, port_mmio + PORT_IRQ_STAT);
+   }
+
for (i = 0; i < n_ports; i++) {
-   void __iomem *port_mmio = ahci_port_base(mmio, i);
const char *emsg = NULL;
 
+   port_mmio = ahci_port_base(mmio, i);
+
if ((port_flags & AHCI_FLAG_HONOR_PI) &&
!(hpriv->port_map & (1 << i)))
continue;
@@ -712,6 +742,9 @@ static void ahci_init_controller(void __iomem *mmio, struct 
pci_dev *pdev,
VPRINTK("PORT_SCR_ERR 0x%x\n", tmp);
writel(tmp, port_mmio + PORT_SCR_ERR);
 
+   /* select the IRQ events we're interested in */
+   writel(DEF_PORT_IRQ, port_mmio + PORT_IRQ_MASK);
+
/* clear port IRQ */
tmp = readl(port_mmio + PORT_IRQ_STAT);
VPRINTK("PORT_IRQ_STAT 0x%x\n", tmp);
@@ -1489,6 +1522,24 @@ static int ahci_host_init(struct ata_probe_ent 
*probe_ent)
hpriv->port_map = readl(mmio + HOST_PORTS_IMPL);
cap_n_ports = ahci_nr_ports(hpriv->cap);
 
+   /*
+* Temporary Marvell 6145 hack: PATA port presence
+* is asserted through the standard AHCI port
+* presence register, as bit 4 (counting from 0)
+*/
+   if (probe_ent->port_flags & AHCI_FLAG_MV_PATA) {
+   dev_printk(KERN_ERR, >dev,
+  "MV_AHCI HACK: port_map %x -> %x, cap_n %u -> %u\n",
+  hpriv->port_map,
+  hpriv->port_map & 0xf,
+  cap_n_ports,
+  (cap_n_ports > 4) ? 4 : cap_n_ports);
+
+   hpriv->port_map &= 0xf;
+   if (cap_n_ports > 4)
+   cap_n_ports = 4;
+ 

Re: + oops-in-drivers-net-shaperc.patch added to -mm tree

[David Miller]

From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sat, 27 Jan 2007 12:01:46 +1100

> In fact, the shaper device doesn't even seem to take a ref count of
> the device it has attached to.  So that device can go away at any time.
> What's more, there are drivers that can change hard_header at run-time
> (s390).

Indeed, it needs to do refcounting or something here, at a minimum,
this driver is so buggy and full of problems :-/

Thankfully it's marked OBSOLETE so we'll get rid of it eventually :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: + oops-in-drivers-net-shaperc.patch added to -mm tree

[David Miller]

From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sat, 27 Jan 2007 11:45:05 +1100

> David Miller <[EMAIL PROTECTED]> wrote:
> > 
> > Shaper is actually OK.  None of these hardware header callbacks
> > should be invoked if the device is down.  Yet, this is what is
> > accidently being allowed in the AF_PACKET socket layer.
> 
> Hmm, what if the device goes down after the check?

For the shaper case it's OK, because once a shaper is
associated it's ->dev never goes back to NULL.

In general, yes it's a problem :-/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Fix /sys/device/.../power/state regression

[David Brownell]

On Friday 26 January 2007 5:19 pm, Matthew Garrett wrote:
> On Fri, Jan 26, 2007 at 04:42:56PM -0800, David Brownell wrote:
> > On Friday 26 January 2007 3:15 pm, Matthew Garrett wrote:
> > > It's certainly the case that fixing those drivers would result in a 
> > > better long-term situation - however, nobody currently seems to have any 
> > > interest in doing so...
> > 
> > And the way these things work, unfortunately, is that merging your patch
> > would ensure nobody ever gets such interest.  Removing that "state" file
> > (and its bogus infrastructure) has already taken a few years too long.
> 
> I'd argue that the onus is on those who wish to remove the interface to 
> ensure that equivalent functionality exists first.

Are you now arguing that "rmmod $DRIVER" doesn't suffice for what you
were wanting to do?  If so, why?  What's the delta in power usage?


> Now this is what throws me somewhat. Last May, you argued strongly in 
> favour of keeping the interface:
> 
> "Which IMO makes removing this a Bad Thing.  It needs to have some
> kind of replacement in place before the "magic numbers" go away."
> 
> (http://lists.osdl.org/pipermail/linux-pm/2006-May/002376.html)

Specifically to support driver testing.  Recall that such testing was
at that time the only known quasi-viable use of that interface.  (And
despite your pushback, it still seems that way to me...)

I've changed my mind about that; it's just as easy to whip up custom test
logic, and in any case the stuff that I most needed to test (wakeup
events) can't be tested like that.  Bad testing infrastructure doesn't
really do anyone favors, anyway; too much time spent with workarounds,
many of which cover up the bugs you're trying to uncover by testing.

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Fix /sys/device/.../power/state regression

[David Brownell]

> > > It's certainly the case that fixing those drivers would result in a 
> > > better long-term situation - however, nobody currently seems to have any 
> > > interest in doing so...
> > 
> > And the way these things work, unfortunately, is that merging your patch
> > would ensure nobody ever gets such interest.  Removing that "state" file
> > (and its bogus infrastructure) has already taken a few years too long.
> 
> No, we shouldn't just break stuff for our users in the hope that said
> breakage will force some other developer to come in and fix things later.

That's not what happened though.  From my perspective, what I see is some
software which chose to START using an interface that's been on its way
out for a few years now.  (And deservedly so; nobody has been able to
demonstrate that it's not been broken-as-designed since day one.)  That
broke the process which had been working to finally get rid of that broken
interface.

Don't the people writing such software have responsibilities too?  Like,
to not start using undocumented and unstable interfaces that have been
acknowledged as broken and on-the-way-out?  Joining some of the Linux PM
mailing list discussions over the past few years would have been good too,
especially ones where userspace-driven PM was the topic.  (I kept asking
for real world examples, and nobody had any.  Which, among other things,
suggests that tool Matthew is concerned with isn't at all well known...)

(Plus, keep in mind that this is not "breakage" in any conventional
sense of something not working.  There's no oopsing or slowdown.)


> We should revert the breakage-causing patch, with the expectation that its
> submitter will ensure that all prerequisites are in place before it is
> reapplied.

Well, Linus is the one who submitted the original patch to add the
late_suspend()/early_resume() mechanism ... and there have been a few
other patches fixing issues turned up by that patch.  Matthew objected
to one side effect of that.  The "bypass layers" part of his patch is
as clean a workaround as can be had, I suppose.


> > > As I've said before, I think it's unreasonable to cripple interfaces for 
> > > (mostly) aesthetic reasons without ensuring that equivalent 
> > > functionality already exists.
> > 
> > I don't recall anyone raising aesthetic concerns.  And bug-equivalence
> > has never been a goal of Linux.
> > 
> 
> Not breaking things for end-users is a goal.  Prime directive, indeed.

With limitations.  Any time a bug gets fixed, it will break software
that relies on that bug.  Like, hmm, this case...

We **STILL** haven't gotten solid information on the software that
broke.  From what I've heard on this list it would seem to be used
on certain Ubuntu systems, but even the _name_ of the utility has
never been mentioned.  When we asked for more details, what came
back was the information that the problem was really a handful of
wireless drivers.


> > > This patch restores useful functionality  
> > > without breaking the extra sanity checks that you've added. I appreciate 
> > > that it's not an interface that you want to support in the long term 
> > > (well, even the short term...),
> > 
> > You imply that it _was_ once supported, which is not true.  Like any
> > other bug (in this case "design bug"), it was there and could be abused.
> > And like some other bugs, fixing it can trigger complaints from (ab)users.
> 
> Could someone please explain in easy-to-understand terms what the
> real-world impact of this bug is upon our users?  How many are affected,
> and under what circumstances, and with what effects?

>From what I can see, a small subset of Ubuntu users will notice that
battery life on some laptops isn't as long as it might be.  Most of
that issue can be resolved by "rmmod $WLAN_DRIVER", a workaround with
a long and successful history in Linux.

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] drivers/isdn/hisax/: Convert to generic boolean-values

[Richard Knutsson]

Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Compile-tested with "allyes", "allmod" & "allno" on i386

 hfc_usb.c |   40 
 hfc_usb.h |3 ---
 2 files changed, 20 insertions(+), 23 deletions(-)


diff --git a/drivers/isdn/hisax/hfc_usb.c b/drivers/isdn/hisax/hfc_usb.c
index 5a6989f..aaa6b88 100644
--- a/drivers/isdn/hisax/hfc_usb.c
+++ b/drivers/isdn/hisax/hfc_usb.c
@@ -183,7 +183,7 @@ typedef struct hfcusb_data {
int vend_idx;   /* vendor found */
int b_mode[2];  /* B-channel mode */
int l1_activated;   /* layer 1 activated */
-   int disc_flag;  /* TRUE if device was disonnected to avoid some 
USB actions */
+   int disc_flag;  /* 'true' if device was disonnected to avoid 
some USB actions */
int packet_size, iso_packet_size;
 
/* control pipe background handling */
@@ -392,7 +392,7 @@ l1_timer_expire_t3(hfcusb_data * hfc)
DBG(ISDN_DBG,
"HFC-S USB: PH_DEACTIVATE | INDICATION sent (T3 expire)");
 #endif
-   hfc->l1_activated = FALSE;
+   hfc->l1_activated = false;
handle_led(hfc, LED_S0_OFF);
/* deactivate : */
queue_control_request(hfc, HFCUSB_STATES, 0x10, 1);
@@ -411,7 +411,7 @@ l1_timer_expire_t4(hfcusb_data * hfc)
DBG(ISDN_DBG,
"HFC-S USB: PH_DEACTIVATE | INDICATION sent (T4 expire)");
 #endif
-   hfc->l1_activated = FALSE;
+   hfc->l1_activated = false;
handle_led(hfc, LED_S0_OFF);
 }
 
@@ -452,7 +452,7 @@ state_handler(hfcusb_data * hfc, __u8 state)
 #ifdef CONFIG_HISAX_DEBUG
DBG(ISDN_DBG, "HFC-S USB: PH_ACTIVATE | INDICATION sent");
 #endif
-   hfc->l1_activated = TRUE;
+   hfc->l1_activated = true;
handle_led(hfc, LED_S0_ON);
} else if (state <= 3 /* && activated */ ) {
if (old_state == 7 || old_state == 8) {
@@ -472,7 +472,7 @@ state_handler(hfcusb_data * hfc, __u8 state)
DBG(ISDN_DBG,
"HFC-S USB: PH_DEACTIVATE | INDICATION sent");
 #endif
-   hfc->l1_activated = FALSE;
+   hfc->l1_activated = false;
handle_led(hfc, LED_S0_OFF);
}
}
@@ -622,7 +622,7 @@ tx_iso_complete(struct urb *urb)
if (fifo->active && !status) {
transp_mode = 0;
if (fifon < 4 && hfc->b_mode[fifon / 2] == L1_MODE_TRANS)
-   transp_mode = TRUE;
+   transp_mode = true;
 
/* is FifoFull-threshold set for our channel? */
threshbit = threshtable[fifon] & hfc->threshold_mask;
@@ -640,7 +640,7 @@ tx_iso_complete(struct urb *urb)
  tx_iso_complete, urb->context);
memset(context_iso_urb->buffer, 0,
   sizeof(context_iso_urb->buffer));
-   frame_complete = FALSE;
+   frame_complete = false;
/* Generate next Iso Packets */
for (k = 0; k < num_isoc_packets; ++k) {
if (fifo->skbuff) {
@@ -666,7 +666,7 @@ tx_iso_complete(struct urb *urb)
/* add 2 byte flags and 16bit 
CRC at end of ISDN frame */
fifo->bit_line += 32;
}
-   frame_complete = TRUE;
+   frame_complete = true;
}
 
memcpy(context_iso_urb->buffer +
@@ -693,7 +693,7 @@ tx_iso_complete(struct urb *urb)
}
 
if (frame_complete) {
-   fifo->delete_flg = TRUE;
+   fifo->delete_flg = true;
fifo->hif->l1l2(fifo->hif,
PH_DATA | CONFIRM,
(void *) (unsigned long) 
fifo->skbuff->
@@ -701,9 +701,9 @@ tx_iso_complete(struct urb *urb)
if (fifo->skbuff && fifo->delete_flg) {
dev_kfree_skb_any(fifo->skbuff);
fifo->skbuff = NULL;
-   fifo->delete_flg = FALSE;
+   fifo->delete_flg = false;
}
-   frame_complete = FALSE;
+   frame_complete = false;
}
}
errcode = usb_submit_urb(urb, GFP_ATOMIC);
@@ -837,7 +837,7 @@ collect_rx_frame(usb_fifo * fifo, __u8 * data, int len, int 
finish)
fifon = fifo->fifonum;
transp_mode = 0;
if (fifon < 4 && hfc->b_mode[fifon / 2] == 

[PATCH] drivers/isdn/hardware/eicon/: Convert to generic boolean-values

[Richard Knutsson]

Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Compile-tested with "allyes", "allmod" & "allno" on i386

 capifunc.c |4
 di.c   |   16 +-
 message.c  |  360 ++---
 os_pri.c   |4
 platform.h |8 -
 5 files changed, 192 insertions(+), 200 deletions(-)


diff --git a/drivers/isdn/hardware/eicon/capifunc.c 
b/drivers/isdn/hardware/eicon/capifunc.c
index 0afd763..ff284ae 100644
--- a/drivers/isdn/hardware/eicon/capifunc.c
+++ b/drivers/isdn/hardware/eicon/capifunc.c
@@ -187,7 +187,7 @@ static diva_card *find_card_by_ctrl(word controller)
  */
 void *TransmitBufferSet(APPL * appl, dword ref)
 {
-   appl->xbuffer_used[ref] = TRUE;
+   appl->xbuffer_used[ref] = true;
DBG_PRV1(("%d:xbuf_used(%d)", appl->Id, ref + 1))
return (void *) ref;
 }
@@ -202,7 +202,7 @@ void *TransmitBufferGet(APPL * appl, void *p)
 
 void TransmitBufferFree(APPL * appl, void *p)
 {
-   appl->xbuffer_used[(dword) p] = FALSE;
+   appl->xbuffer_used[(dword) p] = false;
DBG_PRV1(("%d:xbuf_free(%d)", appl->Id, ((dword) p) + 1))
 }
 
diff --git a/drivers/isdn/hardware/eicon/di.c b/drivers/isdn/hardware/eicon/di.c
index e1df8d9..ce8df38 100644
--- a/drivers/isdn/hardware/eicon/di.c
+++ b/drivers/isdn/hardware/eicon/di.c
@@ -173,16 +173,16 @@ void pr_out(ADAPTER * a)
 xdi_xlog_request (XDI_A_NR(a), this->Id, this->ReqCh, this->MInd,
   a->IdTypeTable[this->No]);
 a->ram_out(a, >Req, this->MInd);
-more = TRUE;
+more = true;
   }
   else {
 xdi_xlog_request (XDI_A_NR(a), this->Id, this->ReqCh, this->Req,
   a->IdTypeTable[this->No]);
 this->More |=XMOREF;
 a->ram_out(a, >Req, this->Req);
-more = FALSE;
+more = false;
 if (a->FlowControlIdTable[this->ReqCh] == this->Id)
-  a->FlowControlSkipTable[this->ReqCh] = TRUE;
+  a->FlowControlSkipTable[this->ReqCh] = true;
 /*
Note that remove request was sent to the card
*/
@@ -311,7 +311,7 @@ byte pr_dpc(ADAPTER * a)
 /* are marked RNR   */
   if(RNRId && RNRId==a->ram_in(a, >IndId)) {
 a->ram_out(a, >Ind, 0);
-a->ram_out(a, >RNR, TRUE);
+a->ram_out(a, >RNR, true);
   }
   else {
 Ind = a->ram_in(a, >Ind);
@@ -331,7 +331,7 @@ byte pr_dpc(ADAPTER * a)
 dtrc(dprintf("RNR"));
 a->ram_out(a, >Ind, 0);
 RNRId = a->ram_in(a, >IndId);
-a->ram_out(a, >RNR, TRUE);
+a->ram_out(a, >RNR, true);
   }
 }
   }
@@ -340,7 +340,7 @@ byte pr_dpc(ADAPTER * a)
 }
 a->ram_out(a, _RAM->IndOutput, 0);
   }
-  return FALSE;
+  return false;
 }
 byte scom_test_int(ADAPTER * a)
 {
@@ -399,7 +399,7 @@ byte isdn_rc(ADAPTER * a,
   return (0);
 }
 if (extended_info_type == DIVA_RC_TYPE_REMOVE_COMPLETE)
-  a->RcExtensionSupported = TRUE;
+  a->RcExtensionSupported = true;
   }
   a->misc_flags_table[e_no] &= ~DIVA_MISC_FLAGS_REMOVE_PENDING;
   a->misc_flags_table[e_no] &= ~DIVA_MISC_FLAGS_NO_RC_CANCELLING;
@@ -428,7 +428,7 @@ byte isdn_rc(ADAPTER * a,
 }
 if (Rc==OK_FC) {
   a->FlowControlIdTable[Ch] = Id;
-  a->FlowControlSkipTable[Ch] = FALSE;
+  a->FlowControlSkipTable[Ch] = false;
   this->Rc = Rc;
   this->More &= ~(XBUSY | XMOREC);
   this->complete=0xff;
diff --git a/drivers/isdn/hardware/eicon/message.c 
b/drivers/isdn/hardware/eicon/message.c
index f9b00f1..ab1c112 100644
--- a/drivers/isdn/hardware/eicon/message.c
+++ b/drivers/isdn/hardware/eicon/message.c
@@ -253,7 +253,7 @@ extern APPL   * application;
 
 
 
-static byte remove_started = FALSE;
+static byte remove_started = false;
 static PLCI dummy_plci;
 
 
@@ -456,12 +456,12 @@ word api_put(APPL   * appl, CAPI_MSG   * msg)
 
 return _QUEUE_FULL;
   }
-  c = FALSE;
+  c = false;
   if byte   *) msg) < ((byte   *)(plci->msg_in_queue)))
|| (((byte   *) msg) >= ((byte   *)(plci->msg_in_queue)) + 
sizeof(plci->msg_in_queue)))
   {
 if (plci->msg_in_write_pos != plci->msg_in_read_pos)
-  c = TRUE;
+  c = true;
   }
   if (msg->header.command == _DATA_B3_R)
   {
@@ -506,13 +506,13 @@ word api_put(APPL   * appl, CAPI_MSG   * msg)
 
 return _QUEUE_FULL;
   }
-  c = TRUE;
+  c = true;
 }
   }
   else
   {
 if (plci->req_in || plci->internal_command)
-  c = TRUE;
+  c = true;
 else
 {
   plci->command = msg->header.command;
@@ -626,10 +626,10 @@ word api_parse(byte   * msg, word length, byte * format, 
API_PARSE * parms)
   break;
 }
 
-if(p>length) return TRUE;
+if(p>length) return true;
   }
   if(parms) parms[i].info = NULL;
- 

Re: Kernel 2.6.19.2: Belkin UPS on Serial vs. USB

[Greg KH]

On Fri, Jan 26, 2007 at 12:54:02PM -0500, Justin Piszcz wrote:
> When I disconnect my UPS from the wall, I have to wait 15-30 seconds 
> before the USB drier 'polls' this information and tells me that the UPS is 
> on battery power (via knutclient or syslog via nut):
> 
> [EMAIL PROTECTED] POWER ALERT on Fri Jan 26 12:49:29 EST 2007
> 
> With a serial connection, I would get the alerts IMMEDIATELY (0.5-1 
> seconds) after disconnecting the UPS.  My new machine does not have a 
> serial port built-in, only a serial header, and of course does not come 
> with an included cable, so I chose to use USB.
> 
> My question is, how do I change the polling time for the USB subsystem to 
> match that of the serial port, or would I not want to do that for other 
> reasons?
> 
> The reason I'd like to is I am not going to see any power alerts for 
> unless there is a power outage for longer than 15-30 seconds.

I think this is a userspace issue, as it's a userspace program that is
doing the polling, right?  Try asking the developers of it about this.

I think you will find it is a FAQ...

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Fix /sys/device/.../power/state regression

[Matthew Garrett]

On Fri, Jan 26, 2007 at 12:42:26PM -0800, Greg KH wrote:

> No, it's not stable material, as drivers would have to be modified to
> support it, and that is adding new stuff.  See my other comment about
> why this was changed because it was broken...

Which drivers? The current code simply bails if the bus (not the device) 
supports the late_suspend method. In the PCI core, that function simply 
calls the device's late_suspend method and does nothing else. My patch 
simply alters the check so that the bus can veto the request if the 
driver has such a method, and allow it to pass if it doesn't. To 
summarise:

2.6.18 situation:

/sys/devices/.../power/state call will succeed for all PCI devices, even 
if the device suspend method must be called with interrupts disabled

2.6.19 situation:

/sys/devices/.../power/state call will fail for all PCI devices, even if 
the PCI bus's suspend_late function is effectively a noop for that 
device

2.6.19+my patch situation:

/sys/devices/.../power/state call will fail for PCI devices that 
implement a suspend_late method, and succeed for other PCI devices

Surely the latter of these is the closest to the expected behaviour?
-- 
Matthew Garrett | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Fix /sys/device/.../power/state regression

[Matthew Garrett]

On Fri, Jan 26, 2007 at 04:42:56PM -0800, David Brownell wrote:
> On Friday 26 January 2007 3:15 pm, Matthew Garrett wrote:
> > It's certainly the case that fixing those drivers would result in a 
> > better long-term situation - however, nobody currently seems to have any 
> > interest in doing so...
> 
> And the way these things work, unfortunately, is that merging your patch
> would ensure nobody ever gets such interest.  Removing that "state" file
> (and its bogus infrastructure) has already taken a few years too long.

I'd argue that the onus is on those who wish to remove the interface to 
ensure that equivalent functionality exists first. It's not as if it's 
especially /hard/, just tedious and requires access to a large quantity 
of hardware.

> > This patch restores useful functionality  
> > without breaking the extra sanity checks that you've added. I appreciate 
> > that it's not an interface that you want to support in the long term 
> > (well, even the short term...),
> 
> You imply that it _was_ once supported, which is not true.  Like any
> other bug (in this case "design bug"), it was there and could be abused.
> And like some other bugs, fixing it can trigger complaints from (ab)users.
> 
> It's been several years now that this interface has been well recognized as
> trouble.  Years in which all _other_ users went and did the Right Thing:
> they stopped using it, or never started.

Now this is what throws me somewhat. Last May, you argued strongly in 
favour of keeping the interface:

"Which IMO makes removing this a Bad Thing.  It needs to have some
kind of replacement in place before the "magic numbers" go away."

(http://lists.osdl.org/pipermail/linux-pm/2006-May/002376.html)

"How could we schedule the removal before we have even had a couple
releases to fine-tune its replacement, and verify that the main issues
with the current thing are fully resolved?"

(http://lists.osdl.org/pipermail/linux-pm/2006-May/002382.html)

"> Maybe date will need to be shifted...

How about "one year after its replacement is ready"?"

(http://lists.osdl.org/pipermail/linux-pm/2006-May/002384.html)

I don't think there /has/ been any strong indication from the PM 
community that this interface was going to go away in the near future - 
the last time somebody tried to remove it (rather than incidentally 
breaking it), there were complaints and the matter seemed to drop.

Now, the current situation is that the interface is scheduled for 
removal in July (not something I especially agree with, and something 
you seemed to disagree with less than a year ago). However, the changes 
in 2.6.19 effectively crippled it. The current situation is that the 
only widely-used bus where this interface still works is USB, so to a 
large extent the interface has already been removed. If the interface is 
that broken, then it should just be removed now - if it's going to be 
carried around until July, it should be fixed so that it works as well 
as it did in 2.6.18 and below. The patch does that. 

-- 
Matthew Garrett | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

git.kernel.org move (finally)... estimated week of Feb 5

[H. Peter Anvin]

Just for everyone's information...

The git performance issues (especially) on kernel.org has been very 
frustrating, obviously.  We're putting a dedicated git server in place 
hopefully the week of February 5.


-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] - Altix: ACPI SSDT PCI device support

[Andrew Morton]

On Wed, 15 Nov 2006 09:24:54 -0600
John Keller <[EMAIL PROTECTED]> wrote:

> Add SN platform support for running with an ACPI
> capable PROM that defines PCI devices in SSDT
> tables. There is a SSDT table for every occupied
> slot on a root bus, containing info for every
> PPB and/or device on the bus. The SSDTs will be
> dynamically loaded/unloaded at hotplug enable/disable.

An additional 600kb of diff has just popped up in the ACPI tree, so none of
this patch applies any more.  I'll need to drop it again, sorry.

It's been over two months - I'm not sure why things are so difficult for
this patchset.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: + oops-in-drivers-net-shaperc.patch added to -mm tree

[Herbert Xu]

On Sat, Jan 27, 2007 at 11:45:05AM +1100, Herbert Xu wrote:
> David Miller <[EMAIL PROTECTED]> wrote:
> > 
> > Shaper is actually OK.  None of these hardware header callbacks
> > should be invoked if the device is down.  Yet, this is what is
> > accidently being allowed in the AF_PACKET socket layer.
> 
> Hmm, what if the device goes down after the check?

In fact, the shaper device doesn't even seem to take a ref count of
the device it has attached to.  So that device can go away at any time.
What's more, there are drivers that can change hard_header at run-time
(s390).

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Fix /sys/device/.../power/state regression

[Andrew Morton]

On Fri, 26 Jan 2007 16:42:56 -0800
David Brownell <[EMAIL PROTECTED]> wrote:

> On Friday 26 January 2007 3:15 pm, Matthew Garrett wrote:
> > On Fri, Jan 26, 2007 at 01:56:41PM -0800, David Brownell wrote:
> > 
> > > I thought the resolution was that fixing a few of those drivers
> > > should solve the problem Matthew needed resolved, and that in
> > > the meanwhile "rmmod drivername" should suffice.  There also seemed
> > > to be agreement that power management for wireless devices needed
> > > more work; there might need to be a state between "down/off" and
> > > "configured and able to talk IP".
> > 
> > It's certainly the case that fixing those drivers would result in a 
> > better long-term situation - however, nobody currently seems to have any 
> > interest in doing so...
> 
> And the way these things work, unfortunately, is that merging your patch
> would ensure nobody ever gets such interest.  Removing that "state" file
> (and its bogus infrastructure) has already taken a few years too long.
> 

No, we shouldn't just break stuff for our users in the hope that said
breakage will force some other developer to come in and fix things later.

We should revert the breakage-causing patch, with the expectation that its
submitter will ensure that all prerequisites are in place before it is
reapplied.

> 
> > As I've said before, I think it's unreasonable to cripple interfaces for 
> > (mostly) aesthetic reasons without ensuring that equivalent 
> > functionality already exists.
> 
> I don't recall anyone raising aesthetic concerns.  And bug-equivalence
> has never been a goal of Linux.
> 

Not breaking things for end-users is a goal.  Prime directive, indeed.

> 
> > This patch restores useful functionality  
> > without breaking the extra sanity checks that you've added. I appreciate 
> > that it's not an interface that you want to support in the long term 
> > (well, even the short term...),
> 
> You imply that it _was_ once supported, which is not true.  Like any
> other bug (in this case "design bug"), it was there and could be abused.
> And like some other bugs, fixing it can trigger complaints from (ab)users.

Could someone please explain in easy-to-understand terms what the
real-world impact of this bug is upon our users?  How many are affected,
and under what circumstances, and with what effects?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: + oops-in-drivers-net-shaperc.patch added to -mm tree

[Herbert Xu]

David Miller <[EMAIL PROTECTED]> wrote:
> 
> Shaper is actually OK.  None of these hardware header callbacks
> should be invoked if the device is down.  Yet, this is what is
> accidently being allowed in the AF_PACKET socket layer.

Hmm, what if the device goes down after the check?

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] 4/5: Updates to SPI and mmc_spi: mmc_spi updated, kernel 2.6.19

[David Brownell]

On Friday 26 January 2007 8:49 am, Pierre Ossman wrote:
> Hans-Peter Nilsson wrote:
> > 
> > Future improvements:
> > A rewrite.  Not only for the new MMC framework (I haven't looked
> > at it so I don't know what's involved) but also because this
> > code seems a little too, um, experimental to fit my taste.
> > Functions go behind each other's back and look at and change
> > data; they seem to "fix up" the result of each others work.

(Like the MMC layer's retry mechanism ...)


> > It doesn't help maintenance.
> 
> Right, this isn't getting merged anywhere near its current state. It
> should be implemented as a host driver and we'll modify the mmc core
> where needed to cover the differences when doing spi.
> 
> As for my "new framework", it's mostly reorganising the stuff already
> there. But any patches will have to be reworked after that change. So
> I'd suggest holding off on this for a while.

That goes without saying, since this driver currently needs some
updates to the SPI framework (grabbing the whole bus, locking out
other devices) that aren't yet mergeable.

However I'm glad to see that, courtesy of Hans-Peter, we now seem
to have enough of the MMC-over-SPI behaving that we can start to
fill in those missing pieces ... and explore just what changes
would be needed in the MMC/SD core!

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2/5: Updates to SPI and mmc_spi: clock with cs inactive, kernel 2.6.19

[David Brownell]

On Friday 26 January 2007 7:21 am, Hans-Peter Nilsson wrote:
> > From: David Brownell <[EMAIL PROTECTED]>

> > Just so we don't lose count here:  this is the *third* example of
> > an SPI protocol tweaking option that seems to be needed just to
> > support an MMC-over-SPI stack:
> > 
> >  - Claiming the SPI bus so that chipselect can stay high even
> >between spi_message interactions (although you seemed not to
> >run into that one);
> 
> You mentioned this is the reason for the spi_get_exclusive-patch
> you sent privately (thanks).  I hadn't seen that, and from my
> reading of the standard I read "bus transaction" (their wording
> for what's between cs deactivation) as a single byte or at least
> send and reply part of a command as separate "bus transactions".
> Yeah, there's only one SPI device on my bus.  To simulate other
> devices on the bus, chatting along when the SD/MMC SPI device
> has chip-select inactive, I experimented with sending "random"
> stuff while in the chip-select function like so:
> 
> ...
> 
> ... and *now* I see it. ;-) No card works.  Hm.  Modulo bugs in
> the above, I agree you need that claim-stuff if there's more
> than one device.  Still, I guess that's actually a rare
> configuration.

The issue is generic.  It shows up with JTAG (which you can
view as an application of SPI) as well as various other tools
I've seen.  As for rare ... hard to say.  I don't design boards,
and the ones where I look at SPI support have real MMC hardware
so they don't need mmc-over-spi.


> >  - Efficiency in the routine "poll for status" operation, where
> >data must be read over MISO (CS high) until 0xff bytes stop;
> 
> That's for read.  For write, it's until the 0x0 bytes stop.  But
> this is a performance feature, not critical for basic function.

Right.

 
> >  - This issue, where a deselected device must be clocked.
> 
> I retract this patch and suggestion, given your later
> suggestion.  (Not worthwhile as a feature.)

OK, fine.  Temporary toggling of chipselect polarity ... that
doesn't _quite_ feel like a hack!

 
> > There's no "chip select" feature in the API.  It's only part of
> > the protocol described by messages delivered to the controller
> > driver.  Don't confuse the "bitbang" framework (which works with
> > more than just bitbanged hardware, of course) with the API; it's
> > just an implementation aid, and not one that all implementors
> > would choose to use.
> 
> Let me rephrase: some controllers (yes, they are using the
> bitbang framework but that's beside the point) do not deactivate
> chip-select; they may not have that signal programmable.

I think those controllers are best viewed as not talking SPI.

Or alternatively, as being so bare-bones that they expect to
have chipselects managed outside the controller.  (Which is not
a bad approach after all.)

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Fix /sys/device/.../power/state regression

[David Brownell]

On Friday 26 January 2007 3:15 pm, Matthew Garrett wrote:
> On Fri, Jan 26, 2007 at 01:56:41PM -0800, David Brownell wrote:
> 
> > I thought the resolution was that fixing a few of those drivers
> > should solve the problem Matthew needed resolved, and that in
> > the meanwhile "rmmod drivername" should suffice.  There also seemed
> > to be agreement that power management for wireless devices needed
> > more work; there might need to be a state between "down/off" and
> > "configured and able to talk IP".
> 
> It's certainly the case that fixing those drivers would result in a 
> better long-term situation - however, nobody currently seems to have any 
> interest in doing so...

And the way these things work, unfortunately, is that merging your patch
would ensure nobody ever gets such interest.  Removing that "state" file
(and its bogus infrastructure) has already taken a few years too long.


> I'm not sure what you mean by using rmmod instead. Most drivers don't 
> explicitly set the power state when unbinding, and I can't see anywhere 
> in the generic PCI code that will do it.

There are broadly two things happening in a driver suspend()
method:

 -  One of them *always* happens on rmmod:  stopping all driver
activity.  That eliminates the dynamic power usage, which as
a rule is what consumes most of the power.

 -  And issuing a pci_set_power_state() call.  That eliminates
some more power usage, but as a rule it's not as much.

Plus some drivers will also enable the device as system wakeup
source.  That behaves poorly on PC Linux (ACPI doesn't handle it
well yet), but on more power-aware Linux systems it's important
as a way to let the system stay in low power states most of the
time, without sacrificing system response to external actions.

If you measure and find that setting the power state matters,
making those drivers do that on rmmod should be easy.  (And IMO
it would be worth trying to make PCI use those states by default
for driverless devices.  Different issue though.)


> As I've said before, I think it's unreasonable to cripple interfaces for 
> (mostly) aesthetic reasons without ensuring that equivalent 
> functionality already exists.

I don't recall anyone raising aesthetic concerns.  And bug-equivalence
has never been a goal of Linux.


> This patch restores useful functionality  
> without breaking the extra sanity checks that you've added. I appreciate 
> that it's not an interface that you want to support in the long term 
> (well, even the short term...),

You imply that it _was_ once supported, which is not true.  Like any
other bug (in this case "design bug"), it was there and could be abused.
And like some other bugs, fixing it can trigger complaints from (ab)users.

It's been several years now that this interface has been well recognized as
trouble.  Years in which all _other_ users went and did the Right Thing:
they stopped using it, or never started.

If you want sympathy for an application that took the time during which
that mechanism was getting phased out, and then decided to phase *IN* a
new use ... sorry, I'm not constitutionally able to give sympathy.  I can
maybe offer sympathy that you didn't know it was being phased out (since
the decision to do that ISTR predated the "feature removal" schedule, with
its additional publicity), but not much more than that.

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 5 patches: updates to SPI and mmc_spi, kernel 2.6.19

[David Brownell]

On Friday 26 January 2007 6:31 am, Hans-Peter Nilsson wrote:
> > From: David Brownell <[EMAIL PROTECTED]>
> > Date: Thu, 25 Jan 2007 04:59:37 -0800
> 
> > So to summarize ... you now have MMC-over-SPI working on CRIS
> > hardware, with these patches?
> 
> Yes.  FWIW, we'll ship with our ETRAX FS developer boards, soon
> enough (in a week or so, knock-on-wood).

Cool!  It's getting more real then.


> >   Can you yet run filesystem
> > stress tests with ext3 on such an MMC card,
> 
> I'd have to configure it in, but I guess I could, if you're not
> happy with just vfat.  I just copied (tarred both to file, and
> separately copied the tree through tar) 174 MeB from a USB stick
> to separately a 512 MeB SDcard and a 2 GiB MMC card and they
> both read out correctly from an (USB) SDcard reader connected to
> my PC.  Is there a specific test you have in mind?

No, I just wanted to get a feel for how solid you thought this was.

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] take 2: (was-kind-of: 3/5 SPI tx_default) 2.6.20-rc6

[David Brownell]

On Friday 26 January 2007 2:46 am, Hans-Peter Nilsson wrote:
> > From: David Brownell <[EMAIL PROTECTED]>
> > Date: Thu, 25 Jan 2007 05:02:56 -0800
> 
> > On Wednesday 24 January 2007 8:52 pm, Hans-Peter Nilsson wrote:
> > > (Please CC me on replies, I'm not subscribed to LKML or the SPI list.  
> > > Thanks.)
> > > 
> > > The SD/MMC SPI-based protocol isn't really duplex.  In the
> > > normal case there's either information transmitted or received,
> > > not both simultaneously.  The unused data is always 0xff; ones.
> > > Unfortunately, the SPI framework leaves outgoing data for a
> > > left-out tx_buf just as "undefined"
> > 
> > In current kernels that's actually changed.  The value to be shifted
> > out is now specified ... as all-zeroes, which is what various chips
> > need to receive, and various (half-duplex/Microwire) controllers seem
> > to be doing in any case.
> > 
> > If that's an issue -- and MMC-over-SPI needs to specify some other
> > value --
> 
> Well, it *is* specified as ones (0xff). 

Fair enough; I don't recall that I actually saw a spec saying that.


> > I think a better way to package this would be to define a new
> > flag for spi->mode, since controller drivers are already supposed
> > to be checking that to make sure they handle all the options which
> > have been specified.
> 
> But it's unspecified what the controller drivers should do with
> flags don't recognize (should they refuse? warn? ignore? - I see
> they all ignore)

They should refuse.


>   if (spi->mode & ~(SPI_CPHA | SPI_CPOL | SPI_CS_HIGH | SPI_LSB_FIRST))
>   return -EINVAL;
> 
> (I think I'll do exactly that with the drivers I wrote.)

Something like that, yes.  It might be nice to have a KERN_DEBUG message
saying which flags were troublesome; production systems will of course
never trigger those failures, so there's no point in having a message
that's not automagically compiled-out.

 
> >  That flag could work in conjunction with a byte
> 
> Or why not a 32-bit word!

If a driver wants a repeating 32-bit pattern, they should just
provide a properly initialized tx buffer.


> FWIW, I defined it as a single bit in that patch, because that's
> what my HW can do when the transmitter is disabled - and because
> MOSI *is* a single-valued signal. ;-) 

I wouldn't mind a single bit flag either, saying whether to shift
out all ones or all zeroes.  The controller driver would morph it
to something appropriate ... 0xff, 0x, etc.


> While I was looking, I noticed that the memory-layout of
> non-8-bit words for SPI is a bit unclear. 

The SPI_LSB_FIRST flag describes bit order on the wire.

In-memory bit ordering should be native/CPU bit order
(which may be slightly unclear).  So the confusion is
not for 8, 16, or 32 bit words ... but 9, 12, 20, and
other sample sizes.


> The endianness of 
> data shifted out doesn't really define endianness in memory or
> whether 24-bit words bytes are in order {hi, med, low, pad} or
> indeed {pad, low, med, hi or whatever combination.  For a LE
> architecture, storing data as LE in memory makes sense, and both
> with and without padding makes sense too.  Perhaps best to just
> document that it's undefined?

No, the point is to alow portable drivers.  So that must be
specified.  What I'm writing up is that it must be right
justified, so its the MSBs that are undefined (for RX) or
ignored (TX).


> > then please re-issue this patch against 2.6.20, including
> > the update to the bitbang driver ("reference implementation").
> 
> I used patch-2.6.20-rc6; I see not too many SPI things changed
> besides defining the previously undefined as 0.  I didn't find a
> reason to introduce a mode-flag; it should always be enough to
> look at the word.  A flag is redundant with default_tx_word != 0
> (in 2.6.20 semantics).  So, I just added that word and adjusted
> the bitbang-driver.  As a courtesy, I also added simple bail-out
> code for the other drivers (not compiled and submitted
> separately).

OK.

 
> Here's an updated patch for 2.6.20-rc6. 

Thanks, I'll eyeball it and merge some version.

- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mm snapshot broken-out-2007-01-26-00-36.tar.gz uploaded

[Michal Piotrowski]

Andrew Morton napisał(a):
> On Sat, 27 Jan 2007 00:23:47 +0100
> "Michal Piotrowski" <[EMAIL PROTECTED]> wrote:
> 
>> On 26/01/07, Michal Piotrowski <[EMAIL PROTECTED]> wrote:
>>> [EMAIL PROTECTED] napisał(a):
 The mm snapshot broken-out-2007-01-26-00-36.tar.gz has been uploaded to


 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-01-26-00-36.tar.gz
>>> security/selinux/hooks.c: In function 'selinux_sysctl':
>>> security/selinux/hooks.c:1440: error: 'ctl_table' has no member named 'de'
>>> make[2]: *** [security/selinux/hooks.o] Error 1
>>> make[1]: *** [security/selinux] Error 2
>>> make: *** [security] Error 2
>>>
>>> Sysctl patches?
>> Thanks Eric, it builds fine.
>>
> 
> It doesn't for me.  What did you change?  Did you receive some unseen-by-me 
> patch
> from Eric?
> 

Subject: sysctl-remove-the-proc_dir_entry-member-for-the-sysctl-tables-hack
From: Andrew Morton <[EMAIL PROTECTED]>

Cc: "Eric W. Biederman" <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>

Upss. It's your patch, thanks.

Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] sound/isa/gus/gus_main.c: Use abs() instead of x < 0 ? -x : x.

[Peter Eriksen]

Signed-off-by: Peter Eriksen <[EMAIL PROTECTED]>
---
There are only a few places using the conditional operator in the
meaning of the absolute value, and this is is one such place.

Compile tested only.

 sound/isa/gus/gus_main.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/sound/isa/gus/gus_main.c b/sound/isa/gus/gus_main.c
index b680fdd..8ced5e8 100644
--- a/sound/isa/gus/gus_main.c
+++ b/sound/isa/gus/gus_main.c
@@ -294,10 +294,10 @@ static int snd_gus_init_dma_irq(struct snd_gus_card * 
gus, int latches)
gus->mix_cntrl_reg |= 4;/* enable MIC */
}
dma1 = gus->gf1.dma1;
-   dma1 = dma1 < 0 ? -dma1 : dma1;
+   dma1 = abs(dma1);
dma1 = dmas[dma1 & 7];
dma2 = gus->gf1.dma2;
-   dma2 = dma2 < 0 ? -dma2 : dma2;
+   dma2 = abs(dma2);
dma2 = dmas[dma2 & 7];
dma1 |= gus->equal_dma ? 0x40 : (dma2 << 3);
 
@@ -306,7 +306,7 @@ static int snd_gus_init_dma_irq(struct snd_gus_card * gus, 
int latches)
return -EINVAL;
}
irq = gus->gf1.irq;
-   irq = irq < 0 ? -irq : irq;
+   irq = abs(irq);
irq = irqs[irq & 0x0f];
if (irq == 0) {
snd_printk(KERN_ERR "Error! IRQ isn't defined.\n");
-- 
1.5.0.rc2.g19605-dirty

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mm snapshot broken-out-2007-01-26-00-36.tar.gz uploaded

[Andrew Morton]

On Sat, 27 Jan 2007 00:23:47 +0100
"Michal Piotrowski" <[EMAIL PROTECTED]> wrote:

> On 26/01/07, Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] napisał(a):
> > > The mm snapshot broken-out-2007-01-26-00-36.tar.gz has been uploaded to
> > >
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-01-26-00-36.tar.gz
> >
> > security/selinux/hooks.c: In function 'selinux_sysctl':
> > security/selinux/hooks.c:1440: error: 'ctl_table' has no member named 'de'
> > make[2]: *** [security/selinux/hooks.o] Error 1
> > make[1]: *** [security/selinux] Error 2
> > make: *** [security] Error 2
> >
> > Sysctl patches?
> 
> Thanks Eric, it builds fine.
> 

It doesn't for me.  What did you change?  Did you receive some unseen-by-me 
patch
from Eric?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: prioritize PCI traffic ?

[Lee Revell]

On 1/17/07, Hans-Peter Jansen <[EMAIL PROTECTED]> wrote:

Am Montag, 15. Januar 2007 15:53 schrieb Vaidyanathan Srinivasan:
>
> 33Mhz 32-bit PCI bus on typical PC can do around 100MB/sec...

Substract roughly n * 5MB for VIA chipsets, where n is the age (1 <= n <=
4), and even more for SIS, ATI..


While developing the latency tracer in the -rt kernel, Ingo and others
discovered that some SATA controllers can produce very bad DMA
starvation at higher speeds.  A latency trace of such an event looks
like the entire system is going in slow motion.  Presumably, vendors
do this to improve benchmark scores.

Try forcing your drives to a lower speed.

Lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mm snapshot broken-out-2007-01-26-00-36.tar.gz uploaded

[Michal Piotrowski]

On 26/01/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

The mm snapshot broken-out-2007-01-26-00-36.tar.gz has been uploaded to

   
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-01-26-00-36.tar.gz


It almost work :)

I'm getting a lot of

BUG: sleeping function called from invalid context at mm/slab.c:3038
in_atomic():0, irqs_disabled():1
no locks held by swapper/1.
irq event stamp: 537144
hardirqs last  enabled at (537143): [] mod_zone_page_state+0x55/0x67
hardirqs last disabled at (537144): [] cache_alloc_refill+0x361/0x640
softirqs last  enabled at (536600): [] __do_softirq+0xd9/0xde
softirqs last disabled at (536595): [] do_softirq+0x4a/0x7a
[] show_trace_log_lvl+0x1a/0x2f
[] show_trace+0x12/0x14
[] dump_stack+0x16/0x18
[] __might_sleep+0xe5/0xeb
[] kmem_cache_alloc+0x28/0xe4
[] cache_alloc_refill+0x3f9/0x640
[] kmem_cache_alloc+0x98/0xe4
[] pgd_alloc+0x12/0x14
[] mm_init+0xa3/0xf5
[] mm_alloc+0x2b/0x2e
[] do_execve+0x81/0x210
[] sys_execve+0x3f/0x8a
[] syscall_call+0x7/0xb
===

http://www.stardust.webpages.pl/files/tbf/euridica/mm-snapshot-2007-01-26/mm-dmesg
http://www.stardust.webpages.pl/files/tbf/euridica/mm-snapshot-2007-01-26/mm-config

Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] serial driver PMC MSP71xx, kernel linux-mips.git mast er

[Marc St-Jean]

Sergei Shtylyov wrote:
> Hello.
> 
> Marc St-Jean wrote:
> 
>  >> > Index: linux_2_6/drivers/serial/8250.c
>  >> > ===
>  >> > RCS file: linux_2_6/drivers/serial/8250.c,v
>  >> > retrieving revision 1.1.1.7
>  >> > diff -u -r1.1.1.7 8250.c
>  >> > --- linux_2_6/drivers/serial/8250.c   19 Oct 2006 21:00:58 - 
>  >>1.1.1.7
>  >> > +++ linux_2_6/drivers/serial/8250.c   24 Jan 2007 23:55:27 -
>  >>[...]
>  >> > @@ -333,6 +334,8 @@
>  >> >   static void
>  >> >   serial_out(struct uart_8250_port *up, int offset, int value)
> 
>  >>   Your patch is clearly garbled again, something added an extra space
>  >>to all
>  >>lines stating with space... :-/
> 
>  > I see that but was under the impression cvs diff did that so all lines
>  > lineup correctly whether they have a +, -, or neither.
> 
> Yes. And your mailer has probably added another space to lines already
> begginign with space. Some mailers tend to do it, don't know sure why... 
> :-/

I'll look into it for the next patch.


>  > It doesn't affect applying the patches for me, did you try?
> 
> I hadn't but I had no doubts it'll fail... just tried, not a single 
> hunk
> applied. :-]
> 
>  >> >   {
>  >> > + /* Save the offset before it's remapped */
>  >> > + int save_offset = offset;
> 
>  >>Is there real need to save this? What regshift equals for this UART?
> 
>  > Yes, we have a regshift of 2 on this SoC and it could be different on 
> other
>  > SoCs which reuse the UART IP.
> 
> Agreed then (though still seems avoidable).
> 
>  >> >   offset = map_8250_out_reg(up, offset) << up->port.regshift;
> 
>  >> >   switch (up->port.iotype) {
>  >> > @@ -359,6 +362,19 @@
>  >> >   writeb(value, up->port.membase + offset);
>  >> >   break;
>  >> >
>  >> > + case UPIO_DWAPB:
>  >> > + /* Save the LCR value so it can be re-written when a
>  >> > +  * Busy Detect interrupt occurs. */
>  >> > + if (save_offset == UART_LCR)
>  >> > + up->lcr = value;
>  >> > + writeb(value, up->port.membase + offset);
>  >> > + /* Read the IER to ensure any interrupt is cleared 
> before
>  >> > +  * returning from ISR. */
>  >> > + if ((save_offset == UART_TX || save_offset == 
> UART_IER) &&
> 
>  >>Not sure how an IER read ensures that...
> 
>  > It's just a dummy read to ensure that any writes which clear 
> interrupts have
>  > reached the device before returning from the IRQ.
> 
> Hm, isn't it CPU write buffer flush? Shouldn't this be handled more
> generically?

No because this peripheral is across an internal SoC bus. Only a read
accessing it will ensure the write is complete. We must insure the
interrupt source is cleared to avoid spurious interrupts.


> [...]
>  >> > Index: linux_2_6/drivers/serial/8250_early.c
>  >> > ===
>  >> > RCS file: linux_2_6/drivers/serial/8250_early.c,v
>  >> > retrieving revision 1.1.1.3
>  >> > diff -u -r1.1.1.3 8250_early.c
>  >> > --- linux_2_6/drivers/serial/8250_early.c 19 Oct 2006 20:08:20
>  >>-  1.1.1.3
>  >> > +++ linux_2_6/drivers/serial/8250_early.c 24 Jan 2007 23:55:27 
> -
>  >> > @@ -46,7 +46,7 @@
>  >> >
>  >> >   static unsigned int __init serial_in(struct uart_port *port, int
>  >>offset)
>  >> >   {
>  >> > - if (port->iotype == UPIO_MEM)
>  >> > + if (port->iotype == UPIO_MEM || port->iotype == UPIO_DWAPB)
>  >> >   return readb(port->membase + offset);
>  >> >   else
>  >> >   return inb(port->iobase + offset);
>  >> > @@ -54,7 +54,7 @@
>  >> >
>  >> >   static void __init serial_out(struct uart_port *port, int offset,
>  >>int value)
>  >> >   {
>  >> > - if (port->iotype == UPIO_MEM)
>  >> > + if (port->iotype == UPIO_MEM || port->iotype == UPIO_DWAPB)
>  >> >   writeb(value, port->membase + offset);
>  >> >   else
>  >> >   outb(value, port->iobase + offset);
>  >> > @@ -233,7 +233,7 @@
>  >> >   return 0;
>  >> >
>  >> >   /* Try to start the normal driver on a matching line.  */
>  >> > - mmio = (port->iotype == UPIO_MEM);
>  >> > + mmio = (port->iotype == UPIO_MEM || port->iotype == 
> UPIO_DWAPB);
>  >> >   line = serial8250_start_console(port, device->options);
>  >> >   if (line < 0)
>  >> >   printk("No ttyS device at %s 0x%lx for console\n",
> 
>  >>From your 8250_eraly.c changes I can conclude regshift == 1 (it 
> doesn't
>  >>currently support other cases). So, serial_pot() doesn't need
>  >>save_offset. :-)
> 
>  > Our regshift is definitely 2 on this SoC and we don't have any 
> problems with
>  > console output before the serial driver opens. So assuming it's using
>  > 8250_early.c for initial console output I can only conclude that it 
> works
> 
> 

Re: sed _s_gnu_alternatives_ (Re: [rft] (g)awk substitution)

[Tim Schmielau]

On Fri, 26 Jan 2007, Oleg Verych wrote:

> In Debian's version it has no `bc', while native `bc' is producing
> crap like that:
> ,-*- bash -*-
> |[EMAIL PROTECTED]:~$ printf "%u" $(( -1 )) ; echo
> |18446744073709551615
> |[EMAIL PROTECTED]:~$ echo -1 | bc
> |-1
> |[EMAIL PROTECTED]:~$ printf "%u" $(( 0xFF )) ; echo
> |255
> |[EMAIL PROTECTED]:~$ echo FF | bc
> |99
> |[EMAIL PROTECTED]:~$ echo F | bc
> |15
> |[EMAIL PROTECTED]:~$
> `-*-
> 
> i can't understand the result... I think linux/scripts/makelst may be
> updated to have sh's version of address calculation ;)

No, IMHO that should not be a reason to change anything in the kernel.
Just set ibase=16 or read the fine manual:
  info '(bc)About Expressions and Special Variables'

Tim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] - increase acpi owner_id max

[Aaron Young]

> 
> The OwnerId field within a namespace node is 8 bits, and this is the
> main constraint on the maximum OwnerId. You can't simply bump up the
> number of owner ids without changing this field.

  Isn't this accomplished with the mod to aclocal.h below - i.e.
  by making a acpi_owner_id a u16 instead of a u8?: 

 -typedef u8 acpi_owner_id;
 -#define ACPI_OWNER_ID_MAX   0xFF
 +typedef u16 acpi_owner_id;
 +#define ACPI_OWNER_ID_MAX   0x3FF

> 
> If we need more than 255 owner Ids, the width of this field will have to
> be increased, or we will need to use a pointer for the field in order to
> maintain a linked list of all nodes owned by a particular owner.
> 
> Bob
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:linux-acpi-
> > [EMAIL PROTECTED] On Behalf Of John Keller
> > Sent: Friday, January 26, 2007 2:40 PM
> > To: linux-acpi@vger.kernel.org
> > Cc: [EMAIL PROTECTED]; linux-ia64@vger.kernel.org; linux-
> > [EMAIL PROTECTED]; John Keller
> > Subject: [PATCH 1/1] - increase acpi owner_id max
> > 
> > To support systems with large IO configurations,
> > this patch increases the number of available ACPI
> > owner ids to 1023.
> > 
> > On SN platforms, we represent every populated root
> > bus slot with an ACPI SSDT table containing info
> > for every device and PPB attached to the slot.
> > Each SSDT requires a unique ACPI owner id.
> > 
> > Signed-off-by: John Keller <[EMAIL PROTECTED]>
> > ---
> > 
> >  drivers/acpi/utilities/utmisc.c |6 +++---
> >  include/acpi/acconfig.h |4 ++--
> >  include/acpi/aclocal.h  |4 ++--
> >  3 files changed, 7 insertions(+), 7 deletions(-)
> > 
> > 
> > Index: linux/drivers/acpi/utilities/utmisc.c
> > ===
> > --- linux.orig/drivers/acpi/utilities/utmisc.c  2007-01-25
> > 11:27:25.509259412 -0600
> > +++ linux/drivers/acpi/utilities/utmisc.c   2007-01-26
> 13:16:09.551081284 -
> > 0600
> > @@ -147,7 +147,7 @@ acpi_status acpi_ut_allocate_owner_id(ac
> > /*
> >  * Construct encoded ID from the index
> and bit
> > position
> >  *
> > -* Note: Last [j].k (bit 255) is never
> used and is
> > marked
> > +* Note: Last [j].k (bit 1023) is never
> used and
> > is marked
> >  * permanently allocated (prevents +1
> overflow)
> >  */
> > *owner_id =
> > @@ -175,7 +175,7 @@ acpi_status acpi_ut_allocate_owner_id(ac
> >  */
> > status = AE_OWNER_ID_LIMIT;
> > ACPI_ERROR((AE_INFO,
> > -   "Could not allocate new OwnerId (255 max),
> > AE_OWNER_ID_LIMIT"));
> > +   "Could not allocate new OwnerId (1023 max),
> > AE_OWNER_ID_LIMIT"));
> > 
> >exit:
> > (void)acpi_ut_release_mutex(ACPI_MTX_CACHES);
> > @@ -192,7 +192,7 @@ acpi_status acpi_ut_allocate_owner_id(ac
> >   *  control method or unloading a table. Either way, we
> would
> >   *  ignore any error anyway.
> >   *
> > - * DESCRIPTION: Release a table or method owner ID.  Valid IDs are 1
> -
> > 255
> > + * DESCRIPTION: Release a table or method owner ID.  Valid IDs are 1
> -
> > 1023
> >   *
> > 
> >
> 
> **
> > /
> > 
> > Index: linux/include/acpi/acconfig.h
> > ===
> > --- linux.orig/include/acpi/acconfig.h  2007-01-25
> 11:27:25.577267818 -
> > 0600
> > +++ linux/include/acpi/acconfig.h   2007-01-26 13:17:14.111002597
> -0600
> > @@ -111,9 +111,9 @@
> > 
> >  #define ACPI_SYSMEM_REGION_WINDOW_SIZE  4096
> > 
> > -/* owner_id tracking. 8 entries allows for 255 owner_ids */
> > +/* owner_id tracking. 32 entries allow for 1023 owner_ids */
> > 
> > -#define ACPI_NUM_OWNERID_MASKS  8
> > +#define ACPI_NUM_OWNERID_MASKS 32
> > 
> > 
> >
> /***
> **
> > *
> >   *
> > Index: linux/include/acpi/aclocal.h
> > ===
> > --- linux.orig/include/acpi/aclocal.h   2007-01-25 11:27:25.585268807 -
> > 0600
> > +++ linux/include/acpi/aclocal.h2007-01-26 13:20:06.148115848
> -0600
> > @@ -122,8 +122,8 @@ static char *acpi_gbl_mutex_names[ACPI_N
> > 
> >  /* Owner IDs are used to track namespace nodes for selective deletion
> */
> > 
> > -typedef u8 acpi_owner_id;
> > -#define ACPI_OWNER_ID_MAX   0xFF
> > +typedef u16 acpi_owner_id;
> > +#define ACPI_OWNER_ID_MAX   0x3FF
> > 
> >  /* This Thread ID means that the mutex is not in use (unlocked) */
> > 
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-acpi"
> in
> > the body of a message to [EMAIL PROTECTED]
> > More 

Re: O_DIRECT question

[Denis Vlasenko]

On Friday 26 January 2007 19:23, Bill Davidsen wrote:
> Denis Vlasenko wrote:
> > On Thursday 25 January 2007 21:45, Michael Tokarev wrote:
> >> Phillip Susi wrote:
> >>> Denis Vlasenko wrote:
>  You mean "You can use aio_write" ?
> >>> Exactly.  You generally don't use O_DIRECT without aio.  Combining the
> >>> two is what gives the big win.
> >> Well, it's not only aio.  Multithreaded I/O also helps alot -- all this,
> >> say, to utilize a raid array with many spindles.
> >>
> >> But even single-threaded I/O but in large quantities benefits from O_DIRECT
> >> significantly, and I pointed this out before.
> > 
> > Which shouldn't be true. There is no fundamental reason why
> > ordinary writes should be slower than O_DIRECT.
> > 
> Other than the copy to buffer taking CPU and memory resources.

It is not required by any standard that I know. Kernel can be smarter
and avoid that if it can.
--
vda
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] lutimesat: simplify utime(2)

[Arnd Bergmann]

On Friday 26 January 2007 21:41, Andrew Morton wrote:
> I'm somewhat surprised that this wasn't done earlier.  I wonder if there's
> some subtle reason why this won't work.   How well tested is this?

http://www.opengroup.org/onlinepubs/95399/functions/utimes.html
lists a slight difference between utime and utimes in the handling
of EPERM/EACCESS:

> The utimes() function shall fail if:
> [EACCES] Search permission is denied by a component of the path prefix;
>  or the times argument is a null pointer and the effective user ID of the
>  process does not match the owner of the file and write access is denied.
> [EPERM] The times argument is not a null pointer and the calling process'
>  effective user ID has write access to the file but does not match the
>  owner of the file and the calling process does not have the appropriate
>  privileges.
>
> The utime() function shall fail if:
> [EACCES]  Search permission is denied by a component of the path prefix;
>  or the times argument is a null pointer and the effective user ID of the
>  process does not match the owner of the file, the process does not have
>  write permission for the file, and the process does not have appropriate
>  privileges.
> [EPERM] The times argument is not a null pointer and the calling process'
>  effective user ID does not match the owner of the file and the calling
>  process does not have the appropriate privileges.

I don't really understand how that should be implemented in different
ways, but it might be the reason that we have separate functions.

Arnd <><
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 1/1] - increase acpi owner_id max

[Moore, Robert]

The OwnerId field within a namespace node is 8 bits, and this is the
main constraint on the maximum OwnerId. You can't simply bump up the
number of owner ids without changing this field.

If we need more than 255 owner Ids, the width of this field will have to
be increased, or we will need to use a pointer for the field in order to
maintain a linked list of all nodes owned by a particular owner.

Bob

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:linux-acpi-
> [EMAIL PROTECTED] On Behalf Of John Keller
> Sent: Friday, January 26, 2007 2:40 PM
> To: linux-acpi@vger.kernel.org
> Cc: [EMAIL PROTECTED]; linux-ia64@vger.kernel.org; linux-
> [EMAIL PROTECTED]; John Keller
> Subject: [PATCH 1/1] - increase acpi owner_id max
> 
> To support systems with large IO configurations,
> this patch increases the number of available ACPI
> owner ids to 1023.
> 
> On SN platforms, we represent every populated root
> bus slot with an ACPI SSDT table containing info
> for every device and PPB attached to the slot.
> Each SSDT requires a unique ACPI owner id.
> 
> Signed-off-by: John Keller <[EMAIL PROTECTED]>
> ---
> 
>  drivers/acpi/utilities/utmisc.c |6 +++---
>  include/acpi/acconfig.h |4 ++--
>  include/acpi/aclocal.h  |4 ++--
>  3 files changed, 7 insertions(+), 7 deletions(-)
> 
> 
> Index: linux/drivers/acpi/utilities/utmisc.c
> ===
> --- linux.orig/drivers/acpi/utilities/utmisc.c2007-01-25
> 11:27:25.509259412 -0600
> +++ linux/drivers/acpi/utilities/utmisc.c 2007-01-26
13:16:09.551081284 -
> 0600
> @@ -147,7 +147,7 @@ acpi_status acpi_ut_allocate_owner_id(ac
>   /*
>* Construct encoded ID from the index
and bit
> position
>*
> -  * Note: Last [j].k (bit 255) is never
used and is
> marked
> +  * Note: Last [j].k (bit 1023) is never
used and
> is marked
>* permanently allocated (prevents +1
overflow)
>*/
>   *owner_id =
> @@ -175,7 +175,7 @@ acpi_status acpi_ut_allocate_owner_id(ac
>*/
>   status = AE_OWNER_ID_LIMIT;
>   ACPI_ERROR((AE_INFO,
> - "Could not allocate new OwnerId (255 max),
> AE_OWNER_ID_LIMIT"));
> + "Could not allocate new OwnerId (1023 max),
> AE_OWNER_ID_LIMIT"));
> 
>exit:
>   (void)acpi_ut_release_mutex(ACPI_MTX_CACHES);
> @@ -192,7 +192,7 @@ acpi_status acpi_ut_allocate_owner_id(ac
>   *  control method or unloading a table. Either way, we
would
>   *  ignore any error anyway.
>   *
> - * DESCRIPTION: Release a table or method owner ID.  Valid IDs are 1
-
> 255
> + * DESCRIPTION: Release a table or method owner ID.  Valid IDs are 1
-
> 1023
>   *
> 
>

**
> /
> 
> Index: linux/include/acpi/acconfig.h
> ===
> --- linux.orig/include/acpi/acconfig.h2007-01-25
11:27:25.577267818 -
> 0600
> +++ linux/include/acpi/acconfig.h 2007-01-26 13:17:14.111002597
-0600
> @@ -111,9 +111,9 @@
> 
>  #define ACPI_SYSMEM_REGION_WINDOW_SIZE  4096
> 
> -/* owner_id tracking. 8 entries allows for 255 owner_ids */
> +/* owner_id tracking. 32 entries allow for 1023 owner_ids */
> 
> -#define ACPI_NUM_OWNERID_MASKS  8
> +#define ACPI_NUM_OWNERID_MASKS   32
> 
> 
>
/***
**
> *
>   *
> Index: linux/include/acpi/aclocal.h
> ===
> --- linux.orig/include/acpi/aclocal.h 2007-01-25 11:27:25.585268807 -
> 0600
> +++ linux/include/acpi/aclocal.h  2007-01-26 13:20:06.148115848
-0600
> @@ -122,8 +122,8 @@ static char *acpi_gbl_mutex_names[ACPI_N
> 
>  /* Owner IDs are used to track namespace nodes for selective deletion
*/
> 
> -typedef u8 acpi_owner_id;
> -#define ACPI_OWNER_ID_MAX   0xFF
> +typedef u16 acpi_owner_id;
> +#define ACPI_OWNER_ID_MAX   0x3FF
> 
>  /* This Thread ID means that the mutex is not in use (unlocked) */
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: O_DIRECT question

[Denis Vlasenko]

On Friday 26 January 2007 18:05, Phillip Susi wrote:
> Denis Vlasenko wrote:
> > Which shouldn't be true. There is no fundamental reason why
> > ordinary writes should be slower than O_DIRECT.
> 
> Again, there IS a reason:  O_DIRECT eliminates the cpu overhead of the 
> kernel-user copy,

You assume that ordinary read()/write() is *required* to do the copying.
It doesn't. Kernel is allowed to do direct DMAing in this case too.

> and when coupled with multithreading or aio, allows  
> the IO queues to be kept full with useful transfers at all times.

Again, ordinary I/O is no different. Especially on fds opened with O_SYNC,
write() will behave very similarly to O_DIRECT one - data is guaranteed
to hit the disk before write() returns.

> Normal read/write requires the kernel to buffer and guess access

No it doesn't *require* that.

> patterns correctly to perform read ahead and write behind perfectly to 
> keep the queues full.  In practice, this does not happen perfectly all 
> of the time, or even most of the time, so it slows things down.

So lets fix the kernel for everyone's benefit intead of "give us
an API specifically for our needs".
--
vda
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [Ksummit-2006-discuss] 2007 Linux Kernel Summit

[Luck, Tony]

> Long term it may make sense for us to give ourselves plenty of
> planning slop of more like 24 months, so if one location doesn't work
> out we have time to work out another one.

That looks way too conservative.  If kernel summit had 500+ attendees, I
can see why you'd need a such long lead time.  But at around 80 people we
fit into a middle sized meeting room at any hotel with conference facilities.
Booking something that size doesn't need two years notice (unless you
happen to conflict with some other huge event in the same city).
Plus if a local team is going to flake on you, chances are high that you
won't find out until <6 months before the event ... so the 2 year plan
wouldn't help at all.

-Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Fix /sys/device/.../power/state regression

[Matthew Garrett]

On Fri, Jan 26, 2007 at 01:56:41PM -0800, David Brownell wrote:

> I thought the resolution was that fixing a few of those drivers
> should solve the problem Matthew needed resolved, and that in
> the meanwhile "rmmod drivername" should suffice.  There also seemed
> to be agreement that power management for wireless devices needed
> more work; there might need to be a state between "down/off" and
> "configured and able to talk IP".

It's certainly the case that fixing those drivers would result in a 
better long-term situation - however, nobody currently seems to have any 
interest in doing so, and I've only got access to a subset of the 
hardware and approximately none of the documentation. It's likely that 
I'll end up spending time on that, but right now I'm afraid that other 
things are taking a higher priority.

I'm not sure what you mean by using rmmod instead. Most drivers don't 
explicitly set the power state when unbinding, and I can't see anywhere 
in the generic PCI code that will do it.

As I've said before, I think it's unreasonable to cripple interfaces for 
(mostly) aesthetic reasons without ensuring that equivalent 
functionality already exists. This patch restores useful functionality 
without breaking the extra sanity checks that you've added. I appreciate 
that it's not an interface that you want to support in the long term 
(well, even the short term...), and that suggesting its removal provides 
a useful incentive to fix things properly in the long term. But it would 
be nice if we didn't make it impossible to do this until the right thing 
is implemented.

-- 
Matthew Garrett | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Bugme-new] [Bug 7891] New: vdso page is no longer mapped for a.out binaries in kernel 2.6.18

[Andrew Morton]

(Please respond via reply-to-all, not via the bugzilla web interface)

On Fri, 26 Jan 2007 14:40:09 -0800
[EMAIL PROTECTED] wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=7891
> 
>Summary: vdso page is no longer mapped for a.out binaries in
> kernel 2.6.18
> Kernel Version: 2.6.18 and later
> Status: NEW
>   Severity: normal
>  Owner: [EMAIL PROTECTED]
>  Submitter: [EMAIL PROTECTED]
> 
> 
> Most recent kernel where this bug did *NOT* occur: 2.6.17.14
> Distribution: vanilla kernel
> Hardware Environment: x86-32
> Software Environment: gentoo
> Problem Description: this is a 2.6.18 regression bug.
> 
> In kernel 2.6.18 the vdso page is no longer mapped for a.out binaries.
> For instance a program using sleep will sigsegv on delivery of SIGALRM (to be
> precise: on return from signal handling). I tested this using a static a.out
> binary. This program does work in 2.6.17 . 
> 
> cat /proc/pid/smaps does show that vdso is not mapped in 2.6.18 for an a.out
> binary. I had a look at fs/binfmt_elf.c and found that the vdso pages is 
> mapped
> using arch_setup_additional_pages from arch/i386/kernel/sysenter.c for elf.
> 
> I did a test calling arch_setup_additional_pages from fs/binfmt_aout.c with
> positive result. 
> 
> As arch_setup_additional_pages is defined in arch/i368-asm/elf.h only, I see 
> no
> clean way to provide a patch for fs/binfmt_aout.c. 
> 
> Steps to reproduce:
> Compile a simple program using sleep() to a.out binary and execute it. It will
> sigsegv on delivery of SIGALRM.
> 

OK, who was it this time?  Andi?

If a.out indeed needs to call arch_setup_additional_pages() then the
correct way to fix this is to rip the festering dungpile which we have now
and:

- Give i386, x86_64, powerpc and sh a new
  CONFIG_ARCH_HAS_SETUP_ADDITIONAL_PAGES

- Create a new include/linux/interp.h which has:

struct linux_binprm;
#ifdef CONFIG_ARCH_HAS_SETUP_ADDITIONAL_PAGES
extern int arch_setup_additional_pages(struct linux_binprm *bprm,
   int executable_stack);
#else
static inline int arch_setup_additional_pages(struct linux_binprm *bprm,
   int executable_stack)
{
return 0;
}
#endif

- include  from binfmt_elf.c and binfmt_aout.c and from
  all the files which implement arch_setup_additional_pages().  

- Remove the #ifdef ARCH_HAS_SETUP_ADDITIONAL_PAGES from binfmt_elf.c

- Add the call to arch_setup_additional_pages() in binfmt_aout.h.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20-rc6-rt2: kernel oops when ejecting cardbus firewire card

[Stefan Richter]

Pieter Palmers wrote:
> cc'ing linux1394-devel because it seems to be a problem in the ieee1394 
> stack.

Yes, this bug is in stock Linux 2.6 too. Ever has been.
http://bugzilla.kernel.org/show_bug.cgi?id=7121
-- 
Stefan Richter
-=-=-=== ---= ==-=-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Possible regression: MSI vector leakage since 2.6.18-rc5ish (Unable to repeatedly allocate/free MSI interrupt)

[Auke Kok]

Auke Kok wrote:

Hi,

I've established a regression in the MSI vector/irq allocation routine for both 
i386 and x86_64. Our test labs repeatedly modprobe/rmmod the e1000 driver for 
serveral minutes which allocates msi vectors and frees them. These tests have 
been running fine until 2.6.19.


git-bisecting I've established that in between commit 
04b9267b15206fc902a18de1f78de6c82ca47716 "Eric W. Biederman -- genirq: x86_64 
irq: Remove the msi assumption that irq == vector" and commit 
f29bd1ba68c8c6a0f50bd678bbd5a26674018f7c "Ingo Molnar -- genirq: convert the 
x86_64 architecture to irq-chips" the behaviour broke.


The revisions in between seem to be dependent and give all sorts of other 
issues, so it's rather hard for me to bisect that and give trustworthy results.


the e1000 driver hits the 256-mark cycle (I think - it consistently refuses to 
do 500 msi irq/vector allocations which is my test case) and throws:


e1000: eth4: e1000_request_irq: Unable to allocate MSI interrupt Error: -16

which is caused by a `if ((err = pci_enable_msi(adapter->pdev))) {` call from 
the e1000 driver. It's rather easy to hit this mark with the new 4-port e1000 
adapters :).


as for the e1000 code, I can say that even our oldest msi-enabled e1000 driver 
works fine with 2.6.18 and under. All kernels from 2.6.19 fail consistently.


I mostly suspect commit 7bd007e480672c99d8656c7b7b12ef0549432c37 at the moment. 
Perhaps Eric Biederman can help?


PS PS

The exact same problem exists when doing "for n in `seq 1 300` ; do modprobe 
snd_hda_intel enable_msi ; rmmod snd_hda_intel ; done".


I'm sure it will show up for other msi enabled devices.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Don't allow the stack to grow into hugetlb reserved regions

[Ken Chen]

On 1/26/07, Hugh Dickins <[EMAIL PROTECTED]> wrote:

Less trivial (and I wonder whether you've come to this from an ia64
or a powerpc direction): I notice that ia64 has more stringent REGION
checks in its ia64_do_page_fault, before calling expand_stack or
expand_upwards.  So on that path, the usual path, I think your
new check in acct_stack_growth is unnecessary on ia64;


I think you are correct. This appears to affect powerpc only. On ia64,
hugetlb lives in a completely different region and they can never step
into normal stack address space. And for x86, there isn't a thing called
"reserved address space" for hugetlb mapping.

   - Ken
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[git patches, 90% resend] libata fixes

[Jeff Garzik]

90% resend from yesterday.  Added a few more fixes.

If you pulled the previous submission, that's ok, git history will still
be correct (it's appended, not rebased).

Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git 
upstream-linus

to receive the following updates:

 arch/powerpc/Kconfig |1 +
 drivers/ata/Kconfig  |4 ++
 drivers/ata/ahci.c   |   60 -
 drivers/ata/ata_generic.c|6 ++-
 drivers/ata/libata-core.c|   14 +---
 drivers/ata/libata-sff.c |   21 +++
 drivers/ata/pata_cmd64x.c|   23 +
 drivers/ata/pata_hpt3x2n.c   |6 ++--
 drivers/ata/pata_it821x.c|4 ++-
 drivers/ata/pata_ixp4xx_cf.c |5 ++-
 drivers/ata/pata_legacy.c|4 ++-
 drivers/ata/pata_rz1000.c|6 ++-
 drivers/ata/sata_uli.c   |3 +-
 drivers/ata/sata_via.c   |   12 ++-
 include/asm-generic/libata-portmap.h |4 +-
 include/asm-powerpc/libata-portmap.h |   12 +++
 include/linux/libata.h   |5 ++-
 17 files changed, 137 insertions(+), 53 deletions(-)
 create mode 100644 include/asm-powerpc/libata-portmap.h

Alan (4):
  libata cmd64x: whack into a shape that looks like the documentation
  libata hpt3xn: Hopefully sort out the DPLL logic versus the vendor code
  libata: set_mode, Fix the FIXME
  libata-sff: Don't call bmdma_stop on non DMA capable controllers

David Woodhouse (1):
  Fix Maple PATA IRQ assignment.

Tejun Heo (6):
  sata_via: don't diddle with ATA_NIEN in ->freeze
  ahci: improve and limit spurious interrupt messages, take#3
  libata: implement ATA_FLAG_IGN_SIMPLEX and use it in sata_uli
  ahci: fix endianness in spurious interrupt message
  sata_via: style clean up, no indirect method call in LLD
  ahci: use 0x80 as wait stat value instead of 0xff

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 0855d55..b268c41 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -484,6 +484,7 @@ config PPC_MAPLE
select PPC_970_NAP
select PPC_NATIVE
select PPC_RTAS
+   select ATA_NONSTANDARD if ATA
default n
help
   This option enables support for the Maple 970FX Evaluation Board.
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index da21552..1c94b43 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -19,6 +19,10 @@ config ATA
 
 if ATA
 
+config ATA_NONSTANDARD
+   bool
+   default n
+
 config SATA_AHCI
tristate "AHCI SATA support"
depends on PCI
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index e3c7b31..28a82e3 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -75,6 +75,7 @@ enum {
AHCI_CMD_CLR_BUSY   = (1 << 10),
 
RX_FIS_D2H_REG  = 0x40, /* offset of D2H Register FIS data */
+   RX_FIS_SDB  = 0x58, /* offset of SDB FIS data */
RX_FIS_UNK  = 0x60, /* offset of Unknown FIS data */
 
board_ahci  = 0,
@@ -202,6 +203,10 @@ struct ahci_port_priv {
dma_addr_t  cmd_tbl_dma;
void*rx_fis;
dma_addr_t  rx_fis_dma;
+   /* for NCQ spurious interrupt analysis */
+   int ncq_saw_spurious_sdb_cnt;
+   unsigned intncq_saw_d2h:1;
+   unsigned intncq_saw_dmas:1;
 };
 
 static u32 ahci_scr_read (struct ata_port *ap, unsigned int sc_reg);
@@ -898,7 +903,7 @@ static int ahci_hardreset(struct ata_port *ap, unsigned int 
*class)
 
/* clear D2H reception area to properly wait for D2H FIS */
ata_tf_init(ap->device, );
-   tf.command = 0xff;
+   tf.command = 0x80;
ata_tf_to_fis(, d2h_fis, 0);
 
rc = sata_std_hardreset(ap, class);
@@ -1109,8 +1114,9 @@ static void ahci_host_intr(struct ata_port *ap)
void __iomem *mmio = ap->host->mmio_base;
void __iomem *port_mmio = ahci_port_base(mmio, ap->port_no);
struct ata_eh_info *ehi = >eh_info;
+   struct ahci_port_priv *pp = ap->private_data;
u32 status, qc_active;
-   int rc;
+   int rc, known_irq = 0;
 
status = readl(port_mmio + PORT_IRQ_STAT);
writel(status, port_mmio + PORT_IRQ_STAT);
@@ -1137,17 +1143,53 @@ static void ahci_host_intr(struct ata_port *ap)
 
/* hmmm... a spurious interupt */
 
-   /* some devices send D2H reg with I bit set during NCQ command phase */
-   if (ap->sactive && (status & PORT_IRQ_D2H_REG_FIS))
+   /* if !NCQ, ignore.  No modern ATA device has broken HSM
+* implementation for non-NCQ commands.
+*/
+   if (!ap->sactive)
return;
 
-   /* ignore interim PIO setup fis interrupts */
-   if 

[PATCH 1/1] - increase acpi owner_id max

[John Keller]

To support systems with large IO configurations,
this patch increases the number of available ACPI
owner ids to 1023.

On SN platforms, we represent every populated root
bus slot with an ACPI SSDT table containing info
for every device and PPB attached to the slot.
Each SSDT requires a unique ACPI owner id.

Signed-off-by: John Keller <[EMAIL PROTECTED]>
---

 drivers/acpi/utilities/utmisc.c |6 +++---
 include/acpi/acconfig.h |4 ++--
 include/acpi/aclocal.h  |4 ++--
 3 files changed, 7 insertions(+), 7 deletions(-)


Index: linux/drivers/acpi/utilities/utmisc.c
===
--- linux.orig/drivers/acpi/utilities/utmisc.c  2007-01-25 11:27:25.509259412 
-0600
+++ linux/drivers/acpi/utilities/utmisc.c   2007-01-26 13:16:09.551081284 
-0600
@@ -147,7 +147,7 @@ acpi_status acpi_ut_allocate_owner_id(ac
/*
 * Construct encoded ID from the index and bit 
position
 *
-* Note: Last [j].k (bit 255) is never used and 
is marked
+* Note: Last [j].k (bit 1023) is never used 
and is marked
 * permanently allocated (prevents +1 overflow)
 */
*owner_id =
@@ -175,7 +175,7 @@ acpi_status acpi_ut_allocate_owner_id(ac
 */
status = AE_OWNER_ID_LIMIT;
ACPI_ERROR((AE_INFO,
-   "Could not allocate new OwnerId (255 max), 
AE_OWNER_ID_LIMIT"));
+   "Could not allocate new OwnerId (1023 max), 
AE_OWNER_ID_LIMIT"));
 
   exit:
(void)acpi_ut_release_mutex(ACPI_MTX_CACHES);
@@ -192,7 +192,7 @@ acpi_status acpi_ut_allocate_owner_id(ac
  *  control method or unloading a table. Either way, we would
  *  ignore any error anyway.
  *
- * DESCRIPTION: Release a table or method owner ID.  Valid IDs are 1 - 255
+ * DESCRIPTION: Release a table or method owner ID.  Valid IDs are 1 - 1023
  *
  
**/
 
Index: linux/include/acpi/acconfig.h
===
--- linux.orig/include/acpi/acconfig.h  2007-01-25 11:27:25.577267818 -0600
+++ linux/include/acpi/acconfig.h   2007-01-26 13:17:14.111002597 -0600
@@ -111,9 +111,9 @@
 
 #define ACPI_SYSMEM_REGION_WINDOW_SIZE  4096
 
-/* owner_id tracking. 8 entries allows for 255 owner_ids */
+/* owner_id tracking. 32 entries allow for 1023 owner_ids */
 
-#define ACPI_NUM_OWNERID_MASKS  8
+#define ACPI_NUM_OWNERID_MASKS 32
 
 /**
  *
Index: linux/include/acpi/aclocal.h
===
--- linux.orig/include/acpi/aclocal.h   2007-01-25 11:27:25.585268807 -0600
+++ linux/include/acpi/aclocal.h2007-01-26 13:20:06.148115848 -0600
@@ -122,8 +122,8 @@ static char *acpi_gbl_mutex_names[ACPI_N
 
 /* Owner IDs are used to track namespace nodes for selective deletion */
 
-typedef u8 acpi_owner_id;
-#define ACPI_OWNER_ID_MAX   0xFF
+typedef u16 acpi_owner_id;
+#define ACPI_OWNER_ID_MAX   0x3FF
 
 /* This Thread ID means that the mutex is not in use (unlocked) */
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Cbe-oss-dev] [PATCH] Cell SPU task notification - repost of patch with updates

[Maynard Johnson]

This patch makes all the changes suggested by Christopher, with the 
exception of the suggestion to use the sched_flags field versus a new 
member to the spu_context struct to signal the need to "notify already 
active".  I don't have the sched_flags change in my 2.6.20-rc1 tree.  I 
can send another patch later if/when the sched_flags changes appears in 
the kernel version we end up picking for final oprofile-spu development.


Comments welcome.  Thanks.

-Maynard
Subject: Enable SPU switch notification to detect currently active SPU tasks.

From: Maynard Johnson <[EMAIL PROTECTED]>

This patch adds to the capability of spu_switch_event_register so that the
caller is also notified of currently active SPU tasks.  It also exports
spu_switch_event_register and spu_switch_event_unregister.

Signed-off-by: Maynard Johnson <[EMAIL PROTECTED]>


Index: linux-2.6.20-rc1/arch/powerpc/platforms/cell/spufs/sched.c
===
--- linux-2.6.20-rc1.orig/arch/powerpc/platforms/cell/spufs/sched.c	2007-01-18 16:43:14.324526032 -0600
+++ linux-2.6.20-rc1/arch/powerpc/platforms/cell/spufs/sched.c	2007-01-26 16:16:35.219668640 -0600
@@ -78,21 +78,46 @@
 
 static BLOCKING_NOTIFIER_HEAD(spu_switch_notifier);
 
-static void spu_switch_notify(struct spu *spu, struct spu_context *ctx)
+void spu_switch_notify(struct spu *spu, struct spu_context *ctx)
 {
 	blocking_notifier_call_chain(_switch_notifier,
 			ctx ? ctx->object_id : 0, spu);
 }
 
+static void notify_spus_active(void)
+{
+   int node;
+	/* Wake up the active spu_contexts. When the awakened processes 
+	 * sees their notify_active flag is set, they will call
+	 * spu_switch_notify();
+	 */
+	for (node = 0; node < MAX_NUMNODES; node++) {
+		struct spu *spu;
+		mutex_lock(_prio->active_mutex[node]);
+list_for_each_entry(spu, _prio->active_list[node], list) {
+			struct spu_context *ctx = spu->ctx;
+			spu->notify_active = 1;
+			wake_up_all(>stop_wq);
+		}
+mutex_unlock(_prio->active_mutex[node]);
+	}
+}
+
 int spu_switch_event_register(struct notifier_block * n)
 {
-	return blocking_notifier_chain_register(_switch_notifier, n);
+	int ret;
+	ret = blocking_notifier_chain_register(_switch_notifier, n);
+	if (!ret)
+		notify_spus_active();
+	return ret;
 }
+EXPORT_SYMBOL_GPL(spu_switch_event_register);
 
 int spu_switch_event_unregister(struct notifier_block * n)
 {
 	return blocking_notifier_chain_unregister(_switch_notifier, n);
 }
+EXPORT_SYMBOL_GPL(spu_switch_event_unregister);
 
 
 static inline void bind_context(struct spu *spu, struct spu_context *ctx)
Index: linux-2.6.20-rc1/arch/powerpc/platforms/cell/spufs/spufs.h
===
--- linux-2.6.20-rc1.orig/arch/powerpc/platforms/cell/spufs/spufs.h	2007-01-18 16:43:14.340523600 -0600
+++ linux-2.6.20-rc1/arch/powerpc/platforms/cell/spufs/spufs.h	2007-01-26 16:26:49.733703448 -0600
@@ -180,6 +180,7 @@
 int spu_activate(struct spu_context *ctx, u64 flags);
 void spu_deactivate(struct spu_context *ctx);
 void spu_yield(struct spu_context *ctx);
+void spu_switch_notify(struct spu *spu, struct spu_context *ctx);
 int __init spu_sched_init(void);
 void __exit spu_sched_exit(void);
 
Index: linux-2.6.20-rc1/arch/powerpc/platforms/cell/spufs/run.c
===
--- linux-2.6.20-rc1.orig/arch/powerpc/platforms/cell/spufs/run.c	2007-01-18 16:43:14.340523600 -0600
+++ linux-2.6.20-rc1/arch/powerpc/platforms/cell/spufs/run.c	2007-01-26 16:24:38.979744856 -0600
@@ -45,9 +45,10 @@
 	u64 pte_fault;
 
 	*stat = ctx->ops->status_read(ctx);
-	if (ctx->state != SPU_STATE_RUNNABLE)
-		return 1;
+
 	spu = ctx->spu;
+	if (ctx->state != SPU_STATE_RUNNABLE || spu->notify_active)
+		return 1;
 	pte_fault = spu->dsisr &
 	(MFC_DSISR_PTE_NOT_FOUND | MFC_DSISR_ACCESS_DENIED);
 	return (!(*stat & 0x1) || pte_fault || spu->class_0_pending) ? 1 : 0;
@@ -305,6 +306,7 @@
 		   u32 *npc, u32 *event)
 {
 	int ret;
+	struct spu * spu;
 	u32 status;
 
 	if (down_interruptible(>run_sema))
@@ -318,8 +320,16 @@
 
 	do {
 		ret = spufs_wait(ctx->stop_wq, spu_stopped(ctx, ));
+		spu = ctx->spu;
 		if (unlikely(ret))
 			break;
+		if (unlikely(spu->notify_active)) {
+			spu->notify_active = 0;
+			if (!(status & SPU_STATUS_STOPPED_BY_STOP)) {
+spu_switch_notify(spu, ctx);
+continue;
+			}
+		}
 		if ((status & SPU_STATUS_STOPPED_BY_STOP) &&
 		(status >> SPU_STOP_STATUS_SHIFT == 0x2104)) {
 			ret = spu_process_callback(ctx);
Index: linux-2.6.20-rc1/include/asm-powerpc/spu.h
===
--- linux-2.6.20-rc1.orig/include/asm-powerpc/spu.h	2007-01-18 16:43:19.932605072 -0600
+++ linux-2.6.20-rc1/include/asm-powerpc/spu.h	2007-01-24 12:17:30.209676992 -0600
@@ -144,6 +144,7 @@
 
 	void* pdata; /* platform private data */
 	struct sys_device sysdev;
+	int notify_active;
 };
 
 struct spu 

Possible regression: MSI vector leakage since 2.6.18-rc5ish (Unable to repeatedly allocate/free MSI interrupt)

[Auke Kok]

Hi,

I've established a regression in the MSI vector/irq allocation routine for both 
i386 and x86_64. Our test labs repeatedly modprobe/rmmod the e1000 driver for 
serveral minutes which allocates msi vectors and frees them. These tests have 
been running fine until 2.6.19.


git-bisecting I've established that in between commit 
04b9267b15206fc902a18de1f78de6c82ca47716 "Eric W. Biederman -- genirq: x86_64 
irq: Remove the msi assumption that irq == vector" and commit 
f29bd1ba68c8c6a0f50bd678bbd5a26674018f7c "Ingo Molnar -- genirq: convert the 
x86_64 architecture to irq-chips" the behaviour broke.


The revisions in between seem to be dependent and give all sorts of other 
issues, so it's rather hard for me to bisect that and give trustworthy results.


the e1000 driver hits the 256-mark cycle (I think - it consistently refuses to 
do 500 msi irq/vector allocations which is my test case) and throws:


e1000: eth4: e1000_request_irq: Unable to allocate MSI interrupt Error: -16

which is caused by a `if ((err = pci_enable_msi(adapter->pdev))) {` call from 
the e1000 driver. It's rather easy to hit this mark with the new 4-port e1000 
adapters :).


as for the e1000 code, I can say that even our oldest msi-enabled e1000 driver 
works fine with 2.6.18 and under. All kernels from 2.6.19 fail consistently.


I mostly suspect commit 7bd007e480672c99d8656c7b7b12ef0549432c37 at the moment. 
Perhaps Eric Biederman can help?


Cheers,

Auke


---
PS After the msi enable fails, things go horribly wrong (of course...) if we 
still try to disable+enable more new msi interrupts, but this may just be the 
e1000 driver cleanup missing something. perhaps it's relevant:


e1000: :04:00.1: e1000_probe: (PCI Express:2.5Gb/s:32-bit) 00:15:17:0c:0c:7f
e1000: eth5: e1000_probe: Intel(R) PRO/1000 Network Connection
ADDRCONF(NETDEV_UP): eth1: link is not ready
ADDRCONF(NETDEV_UP): eth2: link is not ready
ADDRCONF(NETDEV_UP): eth3: link is not ready
e1000: eth4: e1000_request_irq: Unable to allocate MSI interrupt Error: -16
ADDRCONF(NETDEV_UP): eth4: link is not ready
ADDRCONF(NETDEV_UP): eth5: link is not ready
ACPI: PCI interrupt for device :04:00.1 disabled
ACPI: PCI interrupt for device :04:00.0 disabled
ACPI: PCI interrupt for device :03:00.1 disabled
ACPI: PCI interrupt for device :03:00.0 disabled
ACPI: PCI interrupt for device :00:19.0 disabled
Intel(R) PRO/1000 Network Driver - version 7.2.9-k4-NAPI
Copyright (c) 1999-2006 Intel Corporation.
ACPI: PCI Interrupt :00:19.0[A] -> GSI 20 (level, low) -> IRQ 23
PCI: Setting latency timer of device :00:19.0 to 64
e1000: :00:19.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 88:88:88:88:87: 
 88

e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection
ACPI: PCI Interrupt :03:00.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device :03:00.0 to 64
e1000: :03:00.0: e1000_probe: (PCI Express:2.5Gb/s:32-bit) 00:15:17:0c:0c:7c
e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection
ACPI: PCI Interrupt :03:00.1[B] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device :03:00.1 to 64
e1000: :03:00.1: e1000_probe: (PCI Express:2.5Gb/s:32-bit) 00:15:17:0c:0c:7d
e1000: eth3: e1000_probe: Intel(R) PRO/1000 Network Connection
ACPI: PCI Interrupt :04:00.0[A] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device :04:00.0 to 64
e1000: :04:00.0: e1000_probe: (PCI Express:2.5Gb/s:32-bit) 00:15:17:0c:0c:7e
e1000: eth4: e1000_probe: Intel(R) PRO/1000 Network Connection
ACPI: PCI Interrupt :04:00.1[B] -> GSI 18 (level, low) -> IRQ 18
PCI: Setting latency timer of device :04:00.1 to 64
e1000: :04:00.1: e1000_probe: (PCI Express:2.5Gb/s:32-bit) 00:15:17:0c:0c:7f
e1000: eth5: e1000_probe: Intel(R) PRO/1000 Network Connection
ADDRCONF(NETDEV_UP): eth1: link is not ready
ADDRCONF(NETDEV_UP): eth2: link is not ready
ADDRCONF(NETDEV_UP): eth3: link is not ready
ADDRCONF(NETDEV_UP): eth4: link is not ready
ADDRCONF(NETDEV_UP): eth5: link is not ready
irq 214: nobody cared (try booting with the "irqpoll" option)
 [] __report_bad_irq+0x2a/0x90
 [] note_interrupt+0xaf/0xe0
 [] handle_edge_irq+0xd3/0x160
 [] do_IRQ+0x68/0xd0
 [] common_interrupt+0x1a/0x20
 [] snapshot_write_next+0x5b/0x220
 [] __do_softirq+0x62/0x100
 [] do_softirq+0x35/0x40
 [] irq_exit+0x45/0x50
 [] do_IRQ+0x6d/0xd0
 [] common_interrupt+0x1a/0x20
 ===
handlers:
[] (e1000_intr+0x0/0x110 [e1000])
Disabling IRQ #214
ACPI: PCI interrupt for device :04:00.1 disabled
ACPI: PCI interrupt for device :04:00.0 disabled
ACPI: PCI interrupt for device :03:00.1 disabled
irq 214, desc: c05cc120, depth: 1, count: 0, unhandled: 0
->handle_irq():  c015a050, handle_bad_irq+0x0/0x380
->chip(): c05453c0, 0xc05453c0
->action(): 
  IRQ_DISABLED set
   IRQ_PENDING set
IRQ_MASKED set
unexpected IRQ trap at vector d6
irq 214, desc: c05cc120, 

Re: [PATCH] Fix /sys/device/.../power/state regression

[Greg KH]

On Fri, Jan 26, 2007 at 01:56:41PM -0800, David Brownell wrote:
> > Or am I misstating that long thread?  David, your thoughts?
> 
> My recollection of that thread was that *NOBODY* claimed that a
> replacement of that (broken-by-design) mechanism would ever exist.
> 
> However, there was some interesting discussion of just how to fix
> the wireless adapters.  There appeared to be consensus that the
> right solution involved "ifdown wlan0" (or whatever) ought to power
> down that adapter, in the way Matthew wanted.
> 
> I thought the resolution was that fixing a few of those drivers
> should solve the problem Matthew needed resolved, and that in
> the meanwhile "rmmod drivername" should suffice.  There also seemed
> to be agreement that power management for wireless devices needed
> more work; there might need to be a state between "down/off" and
> "configured and able to talk IP".

Ok, that sounds like what I thought the thread resolved too.

Andrew, please drop this patch from your queue, and I'll make sure the
stable tree doesn't get it either.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel + gcc 4.1 = several problems

[Michael K. Edwards]

ALSA + GCC 4.1.1 + -Os is known to be a bad combination on some
arches; see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27363 .  (I
tripped over it on an ARM target, but my limited understanding of GCC
internals does not allow me to conclude that it is ARM-specific.)  A
patch claiming to fix the bug was integrated into the 4.1 branch, but
my tests with a recent (20070115) gcc-4.1 snapshot indicate that it
has regressed again.

You might also check /proc/cpu/alignment; we have seen the alignment
fixup code trigger for alignment errors in both kernel and userspace.
The default appears to be to IGNORE alignment traps from userspace,
which results in bogus data and potentially a wacky series of system
calls, which could conceivably trigger an oops.  I am told that echo 2

/proc/cpu/alignment activates the kernel alignment fixup code, and

that 3 turns on some sort of logging in addition to the fixup (haven't
pursued this myself).  No idea whether this is relevant to your CPU.

Cheers,
- Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] bonding: ARP monitoring broken on x86_64

[Jay Vosburgh]

Andy Gospodarek <[EMAIL PROTECTED]> wrote:

>While working with the latest bonding code I noticed a nasty problem
>that will prevent arp monitoring from always functioning correctly on
>x86_64 systems. Comparing ints to longs and expecting reliable results
>on x86_64 is a bad idea. With this patch, arp monitoring works correctly
>again.  
>
>This also needs to make its way into the 2.6.19 stable series.
>
>Signed-off-by: Andy Gospodarek <[EMAIL PROTECTED]>

Acked-by: Jay Vosburgh <[EMAIL PROTECTED]>

-J

---
-Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Alsa-devel] [PATCH] alsa: correct nonsensical sysfs device symlinks

[xiphmont]

On 1/26/07, Greg KH <[EMAIL PROTECTED]> wrote:


Ok, I'll do it through my trees, but I'll wait for Monty to finish
building and testing.

/me hands Monty a copy of distcc and ccache :)


More like a disk that isn't strangely crippled.
(This kernel isn't getting anywhere near the studly machines :-)

The new-sysfs /sys/class/sound looks correct (I don't have any
userspace that can use it yet, simply compared it to pre-patch) and
the compatability (CONFIG_SYSFS_DEPRECATED) modes look and work 100%
properly here now.  Current hal works properly with
CONFIG_SYSFS_DEPRECATED and audio now.

Monty
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20rc5 k8/acpi regression ( 2.6.17.13 works fine ).

[Paweł Sikora]

for more details see PR 7889 at kernel bugzilla.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Fix /sys/device/.../power/state regression

[David Brownell]

On Friday 26 January 2007 12:41 pm, Greg KH wrote:
> On Thu, Jan 25, 2007 at 05:00:09AM +, Matthew Garrett wrote:

> > This patch allows the bus driver to check whether a specific driver 
> > requires the split. If not, the 2.6.18 functionality is restored. It 
> > also alters feature-removals.txt to note that the deprecated 
> > functionality should not be removed until a replacement actually exists.
> 
> Ick, no.

Especially changing the feature-removal.txt file ...


> As stated before, it was broken in the past, and no userspace tools use
> it because of that.  So it was disabled.

Matthew's problem seems to be that he (?) wrote such a tool to
power down certain wireless adapters.  We did ask around, a while
back, to see if anyone was attempting to use that broken mechanism.

The only real user was pcmcia (which no longer does so), although
it was sometimes used for developer testing (with extreme caution).

Evidently that tool was written after we asked, but before anyone
got around to listing that mechanism as "gonna go"; or maybe it just
never turned up when we looked for users.


It's certainly NOT been news in the PM community, for the past
several years, that the /sys/devices/.../power/state files are
conceptually broken, so userspace tools should NOT use them.

And since the semantics of that file have never been stable even
for PCI devices (much less other busses) or even documented, I
can't have much sympathy towards software using it.

Anyone depending on unspecified behavior (a.k.a. "bugs") is
walking on thin ice.  Anyone trying to use behavior that's been
discussed (among the relevant maintainers) as broken is actively
jumping up and down on that ice.  Even though there was a gap
(sorry!) between the recognition of that mechanism as broken,
and it actually getting scheduled for removal.


> Or am I misstating that long thread?  David, your thoughts?

My recollection of that thread was that *NOBODY* claimed that a
replacement of that (broken-by-design) mechanism would ever exist.

However, there was some interesting discussion of just how to fix
the wireless adapters.  There appeared to be consensus that the
right solution involved "ifdown wlan0" (or whatever) ought to power
down that adapter, in the way Matthew wanted.

I thought the resolution was that fixing a few of those drivers
should solve the problem Matthew needed resolved, and that in
the meanwhile "rmmod drivername" should suffice.  There also seemed
to be agreement that power management for wireless devices needed
more work; there might need to be a state between "down/off" and
"configured and able to talk IP".

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ncpfs and TCP vs UDP

[vandrove]

Quoting Pierre Ossman <[EMAIL PROTECTED]>:

> Hi Petr,

Hello,

> I was hoping you could give me some input on another concern I have.
> Which of TCP and UDP is the preferred transport for NCP? The client for
> Windows seems to use TCP, which would suggest that that is the most
> tested dialect. I also did a quick test with bonnie++:

TCP is definitely preferred.  There are couple of reasons why you should prefer 
TCP:

(1) There is server configuration option to disable NCP/UDP.  You cannot disable
NCP/TCP that easily.

(2) TCP (NCP over TCP) retransmits only missing data, and it can ask for
retransmit much sooner as it knows what link latency is.  NCP/UDP can only ask
for complete packet retransmission, and it has no good idea what's link latency
because there is no ACK from server when it receives request - you can only
resend after usual link latency + time for process request, so you'll wait
longer for retransmit, and on retransmit you need to send again complete request
(which can be 64KB of data if you use 64KB buffer size...)

(3) To avoid problems with retransmits ncpfs uses default buffer size 60KB for
TCP (SOCK_STREAM), while 1KB for UDP/IPX (it must be multiple of sector size, so
using 1.4KB is not an option).  So if you read 1 page, you get 1 request/reply
when using TCP, but 4 requests/replies in UDP/IPX.  And as all this is fully
synchronous, and for today's link latency is dominating factor, it will take 4
times longer...

(4) Theoretically with TCP you should never need retransmits as TCP takes care
of that.  Unfortunately due to server implementation you still cannot have more
than one request in flight (at least with NW5 - I never tried it with NW6 as
spec says I should not do that, and NW5 implementation agreed with spec).

> Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
> 500M  1569  19  1714  10   826   9  1414  18  1569   9  65.2   3
>  --Sequential Create-- Random Create
>  -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
>files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
>   16   460  14   897  16   556  15   491  15  1131  13   320   6

What was 'Block' size ?  For 1KB block size you should get more or less same
speed for TCP and UDP.  If you have link with big latency and big throughput,
then for 2KB block TCP should be 2 times faster, for 60KB block 60 times faster,
and above 60KB block difference should stay on 1:60.

You can try bumping NCP/UDP block size to 60KB as well, but my exprience with
switches and NetWare is that in such cases you can get into situation with
deterministic packet loss - like that from 40 UDP packets sent back to back to
server every 12th gets lost - and if you resend, again 12th packet gets lost,
again and again until you have some luck, or until client decides that server is
dead.
  Petr

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit

[H. Peter Anvin]

Alan Cox wrote:

On Wed, Jan 24, 2007 at 01:47:45PM -0600, Scott Preece wrote:

Hmm - Sounds like it needs to go to Halifax! [I was going to suggest
Reykjavik, but was surprised to see it was in the same time zone as
the UK.]


Reykjavik is a fantastic place with some truely wonderful Linux folks. As to
the timezone, well winter is mostly dark, summer is mostly light so time 
zones don't matter 8)


Reykjavik is also quite easy to travel to from USA and Europe.  From 
elsewhere, it generally means going through one of those locales.


One major benny is that Icelandair lets you treat up to a week in 
Iceland as a "stopover" of a longer trip.


-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [mm PATCH 4/6] RCU: preemptible RCU

[Andrew Morton]

On Sat, 27 Jan 2007 02:30:17 +0530
Dipankar Sarma <[EMAIL PROTECTED]> wrote:

> > > As a consequence of keeping track of RCU readers, the readers
> > > have a slight overhead (optimizations in the paper).
> > > This implementation co-exists with the "classic" RCU
> > > implementations and can be switched to at compiler.
> > 
> > That's yet another question we need to ask people when their kernel dies,
> > and yet another deviation between the kernels which we all test, causing
> > more dilution of testing efforts.  It would be much better if we could
> > remove classic RCU.  You say this would incur extra cost, but the magnitude
> > of that cost is not clear.  Please help us make that decision.
> 
> See the Table 2, page 10 of the paper mentioned above.

argh.

Seems I have to wade through half the paper to understand Table 2.

> There is a
> ~100ns cost per read-side critical section involved in the preemptible
> version of RCU at the moment. Until, we are sure that we don't have
> an impact on common workloads, we need to keep the "classic" 
> implementation around.

Ratios, please..  that 100ns appears to be a 100% increase.  ie 100ns -> 200ns.

There are a couple of ways of working out how much that really matters: a)
run a workload or b) instrument a kernel, work out how many times/sec the
kernel runs rcu_read_lock().  I suspect b) would be more useful and
informative.

Either way, please always prepare such info up-front and summarise in the
changelog?  It's kinda important...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] drivers/media/video: Convert to generic boolean-values

[Richard Knutsson]

Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Compile-tested with "allyes", "allmod" & "allno" on i386.

 saa5246a.c|   10 +-
 saa5246a.h|9 ++---
 saa5249.c |   41 ++---
 saa7134/saa7134-i2c.c |   24 
 saa7134/saa7134.h |6 --
 5 files changed, 37 insertions(+), 53 deletions(-)


diff --git a/drivers/media/video/saa5246a.c b/drivers/media/video/saa5246a.c
index 77bb940..28802c3 100644
--- a/drivers/media/video/saa5246a.c
+++ b/drivers/media/video/saa5246a.c
@@ -112,7 +112,7 @@ static int saa5246a_attach(struct i2c_adapter *adap, int 
addr, int kind)
for (pgbuf = 0; pgbuf < NUM_DAUS; pgbuf++)
{
memset(t->pgbuf[pgbuf], ' ', sizeof(t->pgbuf[0]));
-   t->is_searching[pgbuf] = FALSE;
+   t->is_searching[pgbuf] = false;
}
vd->priv=t;
 
@@ -199,7 +199,7 @@ static int i2c_senddata(struct saa5246a_device *t, ...)
 
 /* Get count number of bytes from I²C-device at address adr, store them in buf.
  * Start & stop handshaking is done by this routine, ack will be sent after the
- * last byte to inhibit further sending of data. If uaccess is TRUE, data is
+ * last byte to inhibit further sending of data. If uaccess is 'true', data is
  * written to user-space with put_user. Returns -1 if I²C-device didn't send
  * acknowledge, 0 otherwise
  */
@@ -339,7 +339,7 @@ static int saa5246a_request_page(struct saa5246a_device *t,
return -EIO;
}
 
-   t->is_searching[req->pgbuf] = TRUE;
+   t->is_searching[req->pgbuf] = true;
return 0;
 }
 
@@ -453,7 +453,7 @@ static inline int saa5246a_get_status(struct 
saa5246a_device *t,
}
}
if (!info->hamming && !info->notfound)
-   t->is_searching[dau_no] = FALSE;
+   t->is_searching[dau_no] = false;
return 0;
 }
 
@@ -565,7 +565,7 @@ static inline int saa5246a_stop_dau(struct saa5246a_device 
*t,
{
return -EIO;
}
-   t->is_searching[dau_no] = FALSE;
+   t->is_searching[dau_no] = false;
return 0;
 }
 
diff --git a/drivers/media/video/saa5246a.h b/drivers/media/video/saa5246a.h
index 7b91112..64394c0 100644
--- a/drivers/media/video/saa5246a.h
+++ b/drivers/media/video/saa5246a.h
@@ -41,23 +41,18 @@
 #define POS_HEADER_START 7
 #define POS_HEADER_END 31
 
-/* Returns TRUE if the part of the videotext page described with req contains
+/* Returns 'true' if the part of the videotext page described with req contains
(at least parts of) the time field */
 #define REQ_CONTAINS_TIME(p_req) \
((p_req)->start <= POS_TIME_END && \
 (p_req)->end   >= POS_TIME_START)
 
-/* Returns TRUE if the part of the videotext page described with req contains
+/* Returns 'true' if the part of the videotext page described with req contains
(at least parts of) the page header */
 #define REQ_CONTAINS_HEADER(p_req) \
((p_req)->start <= POS_HEADER_END && \
 (p_req)->end   >= POS_HEADER_START)
 
-#ifndef FALSE
-#define FALSE 0
-#define TRUE 1
-#endif
-
 /*/
 /* Mode register numbers of the SAA5246A*/
 /*/
diff --git a/drivers/media/video/saa5249.c b/drivers/media/video/saa5249.c
index bb3fb43..19f4503 100644
--- a/drivers/media/video/saa5249.c
+++ b/drivers/media/video/saa5249.c
@@ -124,11 +124,6 @@ struct saa5249_device
 
 /* General defines and debugging support */
 
-#ifndef FALSE
-#define FALSE 0
-#define TRUE 1
-#endif
-
 #define RESCHED do { cond_resched(); } while(0)
 
 static struct video_device saa_template;   /* Declared near bottom */
@@ -183,9 +178,9 @@ static int saa5249_attach(struct i2c_adapter *adap, int 
addr, int kind)
memset(t->vdau[pgbuf].sregs, 0, sizeof(t->vdau[0].sregs));
memset(t->vdau[pgbuf].laststat, 0, sizeof(t->vdau[0].laststat));
t->vdau[pgbuf].expire = 0;
-   t->vdau[pgbuf].clrfound = TRUE;
-   t->vdau[pgbuf].stopped = TRUE;
-   t->is_searching[pgbuf] = FALSE;
+   t->vdau[pgbuf].clrfound = true;
+   t->vdau[pgbuf].stopped = true;
+   t->is_searching[pgbuf] = false;
}
vd->priv=t;
 
@@ -298,7 +293,7 @@ static int i2c_senddata(struct saa5249_device *t, ...)
 
 /* Get count number of bytes from I²C-device at address adr, store them in 
buf. Start & stop
  * handshaking is done by this routine, ack will be sent after the last byte 
to inhibit further
- * sending of data. If uaccess is TRUE, data is written to user-space with 
put_user.
+ * sending of data. If uaccess is 'true', data is written to user-space with 
put_user.
  * Returns -1 if I²C-device didn't send acknowledge, 0 

2.6.20-rc6-rt2: kernel oops when ejecting cardbus firewire card

[Pieter Palmers]

I get the following Oops when ejecting a firewire cardbus controller.
The kernel is a 2.6.20-rc6 (git pull from a few hours ago), patched with 
Ingo's -rt2 patch.


cc'ing linux1394-devel because it seems to be a problem in the ieee1394 
stack.


Pieter

Jan 26 22:29:37 localhost kernel: pccard: card ejected from slot 0
Jan 26 22:29:37 localhost kernel: BUG: unable to handle kernel NULL 
pointer dereference at virtual address 

Jan 26 22:29:37 localhost kernel:  printing eip:
Jan 26 22:29:37 localhost kernel: f91c8a6d
Jan 26 22:29:37 localhost kernel: *pde = 05c64067
Jan 26 22:29:37 localhost kernel: stopped custom tracer.
Jan 26 22:29:37 localhost kernel: Oops:  [#1]
Jan 26 22:29:37 localhost kernel: PREEMPT
Jan 26 22:29:37 localhost kernel: Modules linked in: raw1394 dv1394 
ohci1394 ieee1394 nfsd exportfs lockd nfs_acl autofs4 hidp rfcomm l2cap 
bluetooth sunrp
c vfat fat radeon drm nvram snd_intel8x0m snd_intel8x0 snd_ac97_codec 
ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq 
snd_seq_device snd_pcm_
oss snd_mixer_oss snd_pcm joydev snd_timer snd uhci_hcd i2c_i801 
soundcore ipw2200 ieee80211 ieee80211_crypt 8139too mii i2c_core pcspkr 
snd_page_alloc rng

_core ext3 jbd
Jan 26 22:29:37 localhost kernel: CPU:0
Jan 26 22:29:37 localhost kernel: EIP:0060:[]Not 
tainted VLI

Jan 26 22:29:37 localhost kernel: EFLAGS: 00010286   (2.6.20-rc6-rt2 #9)
Jan 26 22:29:37 localhost kernel: EIP is at dv1394_remove_host+0x17/0xc0 
[dv1394]
Jan 26 22:29:37 localhost kernel: eax: f88fd140   ebx: 0001   ecx: 
   edx: f91c8a56
Jan 26 22:29:37 localhost kernel: esi:    edi: f91c9910   ebp: 
   esp: f7e49ebc
Jan 26 22:29:37 localhost kernel: ds: 007b   es: 007b   ss: 0068 
preempt: 0001
Jan 26 22:29:37 localhost kernel: Process pccardd (pid: 284, ti=f7e48000 
task=f7f68ab0 task.ti=f7e48000)
Jan 26 22:29:37 localhost kernel: Stack: f91cb540 ee588000 f91cb540 
f88ea50f d4142180 ee588000  f91cb540
Jan 26 22:29:37 localhost kernel:ee588000  ee589a84 
f88ea759 ee588000 f8950e94 f88ea18a f7e71400
Jan 26 22:29:37 localhost kernel:f894a213 f8950f14 ee5880bc 
f7e71400 f8950e94  f7eae048 c01c0caf

Jan 26 22:29:37 localhost kernel: Call Trace:
Jan 26 22:29:37 localhost kernel:  [] 
__unregister_host+0x18/0x8f [ieee1394]
Jan 26 22:29:38 localhost kernel:  [] 
highlevel_remove_host+0x21/0x42 [ieee1394]
Jan 26 22:29:38 localhost kernel:  [] 
hpsb_remove_host+0x37/0x55 [ieee1394]
Jan 26 22:29:38 localhost kernel:  [] 
ohci1394_pci_remove+0x47/0x1e4 [ohci1394]

Jan 26 22:29:38 localhost kernel:  [] pci_device_remove+0x16/0x35
Jan 26 22:29:38 localhost kernel:  [] 
__device_release_driver+0x71/0x87
Jan 26 22:29:38 localhost kernel:  [] 
device_release_driver+0x18/0x21

Jan 26 22:29:38 localhost kernel:  [] bus_remove_device+0x70/0x80
Jan 26 22:29:38 localhost kernel:  [] device_del+0x13a/0x197
Jan 26 22:29:38 localhost kernel:  [] device_unregister+0x8/0x10
Jan 26 22:29:38 localhost kernel:  [] pci_stop_dev+0x20/0x4e
Jan 26 22:29:38 localhost kernel:  [] 
pci_remove_bus_device+0x28/0x8c
Jan 26 22:29:38 localhost kernel:  [] 
pci_remove_behind_bridge+0x1a/0x2d

Jan 26 22:29:38 localhost kernel:  [] socket_shutdown+0x6d/0xb3
Jan 26 22:29:38 localhost kernel:  [] socket_remove+0x1c/0x26
Jan 26 22:29:38 localhost kernel:  [] pccardd+0x129/0x1ea
Jan 26 22:29:38 localhost kernel:  [] 
default_wake_function+0x0/0x16

Jan 26 22:29:38 localhost kernel:  [] pccardd+0x0/0x1ea
Jan 26 22:29:38 localhost kernel:  [] kthread+0xa0/0xca
Jan 26 22:29:38 localhost kernel:  [] kthread+0x0/0xca
Jan 26 22:29:38 localhost kernel:  [] 
kernel_thread_helper+0x7/0x10

Jan 26 22:29:38 localhost kernel:  ===
Jan 26 22:29:38 localhost kernel: Code: 1c f9 e8 7f 6c 0e c7 89 da 89 9e 
a8 00 00 00 eb d9 5b 5e c3 57 bf 10 99 1c f9 56 53 8b 98 b0 00 00 00 8b 
80 b4 00 0
0 00 8b 70 04  ae 75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 0f 
85 8d
Jan 26 22:29:38 localhost kernel: EIP: [] 
dv1394_remove_host+0x17/0xc0 [dv1394] SS:ESP 0068:f7e49ebc

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE

[Chris Friesen]

Mel Gorman wrote:

On Fri, 26 Jan 2007, Chris Friesen wrote:


We currently see this issue on our systems, as we have older e1000 
hardware with 9KB jumbo frames.  After a while we just fail to 
allocate buffers and the system goes belly-up.


Can you describe a reliable way of triggering this problem? At best, I 
hear "on our undescribed workload, we sometimes see this problem" but 
not much in the way of details.


I work on embedded server applications.  One of our blades is a 
dual-Xeon with 8GB of RAM and 6 e1000 cards.  The hardware is 32-bit 
only, so we're using the i386 kernel with HIGHMEM64G enabled.


This blade acts essentially as storage for other blades in the shelf. 
Basically all disk and network I/O.  After being up for a month or two 
it starts getting e1000 allocation failures.  In some of the cases at 
least it appears that the page cache has hundreds of megs of freeable 
memory, but it can't get at that memory to fulfill an atomic allocation.


I should point out that we haven't yet tried tuning 
/proc/sys/vm/min_free_kbytes.  The default value on this system is 3831.


Chris

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fw: Re: [mm PATCH 4/6] RCU: (now) CPU hotplug

[Andrew Morton]

On Sat, 27 Jan 2007 02:14:06 +0530
Dipankar Sarma <[EMAIL PROTECTED]> wrote:

> On Fri, Jan 26, 2007 at 12:17:39PM -0800, Andrew Morton wrote:
> > On Sat, 27 Jan 2007 01:16:22 +0530
> > Dipankar Sarma <[EMAIL PROTECTED]> wrote:
> > > > The plan is, I hope, to rip it all out and do freeze_processes() on the
> > > > hotplug side, so nobody else needs to worry about cpu hotplug any more. 
> > > > But at present everyone seems to be in hiding.
> > > 
> > > This would be ideal. However, we don't seem to have any momentum
> > > on this.
> > 
> > There's no point in expending effort on a fancy new lock until this option
> > has been eliminated, so yeah, things are stuck.
> 
> The new lock (scalable refcount) is almost already there. 
> This http://lkml.org/lkml/2006/10/26/65 can be used to implement
> get_cpu_hotplug()/put_cpu_hotplug(). The unfairness issue
> can be fixed. I am going to play with these patches and
> see if I can come up with something useful quickly.

You're forgetting the large, unknown number of places in the kernel which
are presently buggy in the presence of CPU hotplug.  With your proposal, we
still need to hunt them all down and put magic locks around them, and we need to
continue to do that as the kernel evolves.

If we use the process freezer, these bugs all get automatically fixed, and we 
get
to remove the existing locking, and we don't need to think about it any
more.

> > > The other thing we would need to do in this case is to
> > > check if all the users of cpu hotplug can tolerate a very slow
> > > hotplug step if there are 10s of thousands of processes and threads.
> > 
> > Yes, that needs evaluation.  If it's a problem then we might need to
> 
> I will check with the dynamic LPAR people to see if they
> have any requirements in this regard. I have also heard
> about some people wanting to disable additional threads
> in processors (running 1 h/w thread per core) using cpu hotplug 
> for some type of applications. I will check with those
> folks as well.

OK.

> > introduce a more sophisticated user interface which enables userspace to
> > take multiple CPUs online and offline in a single step, rather than
> > one-at-a-time.  I expect that'd be fairly straightforward.
> 
> The worry I have is that all of this is a complete rewrite of
> existing CPU hotplug and it took us 1+ years to get a decent
> CPU hotplug implementation. Rusty and Vatsa can probably vouch
> for how difficult it was to get it right. I don't think
> it is a good idea to keep CPU hotplug broken until this
> rewrite happens. Can't we just go with something that is
> already there and works correctly for us without waiting
> for the perfect solution ?

Who said it's complete rewrite?  Nobody's even started to look at it afaik.
It might be quite simple.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How to create a fixed length character/block device/file ?

[Alan]

On Fri, 26 Jan 2007 12:10:00 -0800
Khai Doan <[EMAIL PROTECTED]> wrote:

> Sorry if this is the wrong list.  I've search google, but have not found 
> solution to my problem.
> 
> I have a long running application which split out lots of debugging 
> information.  I can't redirect the output to a regular file because that 
> file would grow and eat up all the diskspace.  I can't redirect to 
> /dev/null.  What I want is the last 1MB of the output before my 
> application terminated.  

Just pipe the output into a program or perl script which does this. You
don't need a device file.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Oops on serial access on kernel 2.6.16.38

[Frederik Deweerdt]

On Fri, Jan 26, 2007 at 06:17:03PM +, Jose Goncalves wrote:
> Frederik Deweerdt wrote:
> > On Fri, Jan 26, 2007 at 03:50:25PM +, Jose Goncalves wrote:
> >   
> >> I'm having a problem with the latest 2.6.16 kernel (I've found the
> >> problem on 2.6.16.37 and 2.6.16.38). I have a application that retreives
> >> data from a GPS connected on a serial port. From time to time a get a
> >> kernel Oops, like this:
> >>
> >> 
> > Could you send your .config?
> >   
> Here it goes...
> 
Thanks. It looks like something is wrong with port->ops->startup() in
uart_startup(), could you apply the following patch and report the
results? And btw, you're using a plain 8250 serial port, isn't it?

Regards,
Frederik


diff --git a/drivers/serial/serial_core.c b/drivers/serial/serial_core.c
index cc1faa3..08772dc 100644
--- a/drivers/serial/serial_core.c
+++ b/drivers/serial/serial_core.c
@@ -171,6 +171,10 @@ static int uart_startup(struct uart_state *state, int 
init_hw)
uart_circ_clear(>xmit);
}
 
+   printk("type is %d\n", port->type);
+   printk("ops is %p\n", port->ops);
+   printk("ops->startup is %p\n", port->ops->startup);
+
retval = port->ops->startup(port);
if (retval == 0) {
if (init_hw) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Can a kobject have both bus- and class-specific uevent handlers?

[Michael Tokarev]

Looking at drivers/base/core.c:dev_uevent() I wonder whenever
a device can have both bus-specific uevent function AND
class-specific one.  If yes, the code in that routine is umm..
wrong.  Because in this case, bus-specific attributes will
be owerwritten by class-specific ones.

I mean this code (debugging omitted for simplicity):

if (dev->bus && dev->bus->uevent) {
/* have the bus specific function add its stuff */
retval = dev->bus->uevent(dev, envp, num_envp, buffer, buffer_size);
}

if (dev->class && dev->class->dev_uevent) {
/* have the class specific function add its stuff */
retval = dev->class->dev_uevent(dev, envp, num_envp, buffer, 
buffer_size);
}

return retval;

Thanks.

/mjt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How to create a fixed length character/block device/file ?

[Jiri Slaby]

Phillip Susi napsal(a):

Khai Doan wrote:
Sorry if this is the wrong list.  I've search google, but have not 
found solution to my problem.


I have a long running application which split out lots of debugging 
information.  I can't redirect the output to a regular file because 
that file would grow and eat up all the diskspace.  I can't redirect 
to /dev/null.  What I want is the last 1MB of the output before my 
application terminated.  So I need to create a special file / device 
on the system.  Please tell me if  there is an existing device that I 
can use, or point me in the right direction so that I can role my own 
device.


myapp | tail -c1048576 > logfile


AFAIK this will output the file after the app termination. He wants to know the 
log before that.


Just write your own reader which will output last meg in some intervals...

regards,
--
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Don't allow the stack to grow into hugetlb reserved regions

[Hugh Dickins]

On Thu, 25 Jan 2007, Adam Litke wrote:

> When expanding the stack, we don't currently check if the VMA will cross into
> an area of the address space that is reserved for hugetlb pages.  Subsequent
> faults on the expanded portion of such a VMA will confuse the low-level MMU
> code, resulting in an OOPS.  Check for this.

Good point, and your patch looks good; but a couple of reservations.

Trivial: I'd have preferred your error return to be -ENOMEM like all
the rest there, I can't see a good reason for this one to say -EFAULT.
Though apparently nothing cares just so long as it's non-zero.

Less trivial (and I wonder whether you've come to this from an ia64
or a powerpc direction): I notice that ia64 has more stringent REGION
checks in its ia64_do_page_fault, before calling expand_stack or
expand_upwards.  So on that path, the usual path, I think your
new check in acct_stack_growth is unnecessary on ia64; whereas
coming from the get_user_pages find_extend_vma direction,
your check is inadequate?

I'd dearly like to believe that get_user_pages shouldn't be needing
find_extend_vma (it ends up using the wrong task's rlimits); but last
time I researched that, it looked very deliberate, that ptrace be
allowed to expand the stack - I think there's something out there
which would break if that weren't allowed, but I don't know what.

Hugh

> 
> Signed-off-by: Adam Litke <[EMAIL PROTECTED]>
> ---
> 
>  mm/mmap.c |7 +++
>  1 files changed, 7 insertions(+), 0 deletions(-)
> 
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 9717337..2c6b163 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -1477,6 +1477,7 @@ static int acct_stack_growth(struct vm_area_struct * 
> vma, unsigned long size, un
>  {
>   struct mm_struct *mm = vma->vm_mm;
>   struct rlimit *rlim = current->signal->rlim;
> + unsigned long new_start;
>  
>   /* address space limit tests */
>   if (!may_expand_vm(mm, grow))
> @@ -1496,6 +1497,12 @@ static int acct_stack_growth(struct vm_area_struct * 
> vma, unsigned long size, un
>   return -ENOMEM;
>   }
>  
> + /* Check to make the stack will not grow into a hugetlb-only region. */
> + new_start = (vma->vm_flags & VM_GROWSUP) ? vma->vm_start :
> + vma->vm_end - size;
> + if (is_hugepage_only_range(vma->vm_mm, new_start, size))
> + return -EFAULT;
> +
>   /*
>* Overcommit..  This must be the final test, as it will
>* update security statistics.
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to [EMAIL PROTECTED]  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"[EMAIL PROTECTED]"> [EMAIL PROTECTED] 
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [mm PATCH 4/6] RCU: preemptible RCU

[Dipankar Sarma]

On Tue, Jan 23, 2007 at 04:32:59PM -0800, Andrew Morton wrote:
> On Tue, 16 Jan 2007 00:58:58 +0530
> Dipankar Sarma <[EMAIL PROTECTED]> wrote:
> 
> > This patch implements a new version of RCU which allows its read-side
> > critical sections to be preempted.
> 
> Why is it selectable if CONFIG_PREEMPT=n?

It would probably make sense to make CONFIG_RCU_PREEMPT dependent
on CONFIG_PREEMPT. I kept it independent because I wanted to
test rcupreempt as an equivalent RCU implementation not just
for its "preemptibility".

> > It uses a set of counter pairs
> > to keep track of the read-side critical sections and flips them
> > when all tasks exit read-side critical section. The details
> > of this implementation can be found in this paper -
> >
> > http://www.rdrop.com/users/paulmck/RCU/OLSrtRCU.2006.08.11a.pdf
> >
> > This patch was developed as a part of the -rt kernel
> > development and meant to provide better latencies when
> > read-side critical sections of RCU don't disable preemption.
> 
> Does it succeed in that attempt?  Thus far you've given no reason for
> merging this code..
> 
> This is a pile of tricky new core kernel code for us to test, maintain,
> understand, debug, etc.  It needs to provide a substantial benefit.  Does
> it?

I am working to compare some latency numbers between different
implementations. I will have them out soon.


> > As a consequence of keeping track of RCU readers, the readers
> > have a slight overhead (optimizations in the paper).
> > This implementation co-exists with the "classic" RCU
> > implementations and can be switched to at compiler.
> 
> That's yet another question we need to ask people when their kernel dies,
> and yet another deviation between the kernels which we all test, causing
> more dilution of testing efforts.  It would be much better if we could
> remove classic RCU.  You say this would incur extra cost, but the magnitude
> of that cost is not clear.  Please help us make that decision.

See the Table 2, page 10 of the paper mentioned above. There is a
~100ns cost per read-side critical section involved in the preemptible
version of RCU at the moment. Until, we are sure that we don't have
an impact on common workloads, we need to keep the "classic" 
implementation around.

Thanks
Dipankar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[x86-64, CMOS/RTC] Re: 2.6.19.2: bad reads/writes from/to CMOS clock

[Oleg Verych]

26-01-2007:
> I am running 2.6.19.2 kernel from kernel.org.

2.6.18 debian, didn't see before, but maybe it was just big uptime ;)

> This is my first SMP kernel. 
>
> The problem I describe below has not happend with non-SMP kernels ever...
>
> I have installed my new AMD64 x2 4800 CPU just a few days ago. My mobo is 
> Asus A8N SLI
> (Nvidia chipset).

UP ASUS A4K x86-64 CPU Mobile Athlon 64 3200+

> My problem with this new setup is that my CMOS clock is thrown off by varying 
> amounts of time. I have seen system times as long as ten months into future, 
> and as
> long as 25 days in the past. At the moment my system clock has correct 
> hh:mm:ss, but it shows the date Jan 1st, instead of correct 25th.

I saw bad CMOS read, but CMOS itself was OK, after checking it with
hwclock or reboot by magic IRQ.

[]
> I would appreciate any ideas on how to follow-up on this problem. 
>
> I am eager to try things, collect data as needed. Just tell me what to do.
>
> Thanks in advance.

> Yavuz Onder

I don't know, because it was month or so ago. And i'm usual for bugs
(or curved hands ;).


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How to create a fixed length character/block device/file ?

[H. Peter Anvin]

Come to think of it, you can just use "tail" as the application that 
reads the FIFO.


-hpa

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How to create a fixed length character/block device/file ?

[Phillip Susi]

Khai Doan wrote:
Sorry if this is the wrong list.  I've search google, but have not found 
solution to my problem.


I have a long running application which split out lots of debugging 
information.  I can't redirect the output to a regular file because that 
file would grow and eat up all the diskspace.  I can't redirect to 
/dev/null.  What I want is the last 1MB of the output before my 
application terminated.  So I need to create a special file / device on 
the system.  Please tell me if  there is an existing device that I can 
use, or point me in the right direction so that I can role my own device.


myapp | tail -c1048576 > logfile

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How to create a fixed length character/block device/file ?

[H. Peter Anvin]

Khai Doan wrote:
Sorry if this is the wrong list.  I've search google, but have not found 
solution to my problem.


I have a long running application which split out lots of debugging 
information.  I can't redirect the output to a regular file because that 
file would grow and eat up all the diskspace.  I can't redirect to 
/dev/null.  What I want is the last 1MB of the output before my 
application terminated.  So I need to create a special file / device on 
the system.  Please tell me if  there is an existing device that I can 
use, or point me in the right direction so that I can role my own device.




Create a FIFO (see "man mkfifo"), and write a program that reads the 
FIFO and retains the information you're interested in.


-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] lutimesat: actual syscall and wire-up on i386

[Ulrich Drepper]

Andrew Morton wrote:
> OK, but I don't recall having seeing a demand for lutimes().  Opinions
> are sought?

It's an interface which has been available on other platforms forever
(lutimes, not lutimesat).  If it can be implemented correctly on the
interesting file systems I'd say "go ahead", it can only be useful and
have more benefits than the probably small cost of implementing it.

If on the other hand important filesystems cannot support lutimes then
I'd wait with introducing the syscall at least until the support is
added.  It much easier to cope with unavailable syscalls then it is with
partially working ones.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖



signature.asc
Description: OpenPGP digital signature

Re: Fw: Re: [mm PATCH 4/6] RCU: (now) CPU hotplug

[Dipankar Sarma]

On Fri, Jan 26, 2007 at 12:17:39PM -0800, Andrew Morton wrote:
> On Sat, 27 Jan 2007 01:16:22 +0530
> Dipankar Sarma <[EMAIL PROTECTED]> wrote:
> > > The plan is, I hope, to rip it all out and do freeze_processes() on the
> > > hotplug side, so nobody else needs to worry about cpu hotplug any more. 
> > > But at present everyone seems to be in hiding.
> > 
> > This would be ideal. However, we don't seem to have any momentum
> > on this.
> 
> There's no point in expending effort on a fancy new lock until this option
> has been eliminated, so yeah, things are stuck.

The new lock (scalable refcount) is almost already there. 
This http://lkml.org/lkml/2006/10/26/65 can be used to implement
get_cpu_hotplug()/put_cpu_hotplug(). The unfairness issue
can be fixed. I am going to play with these patches and
see if I can come up with something useful quickly.

> > The other thing we would need to do in this case is to
> > check if all the users of cpu hotplug can tolerate a very slow
> > hotplug step if there are 10s of thousands of processes and threads.
> 
> Yes, that needs evaluation.  If it's a problem then we might need to

I will check with the dynamic LPAR people to see if they
have any requirements in this regard. I have also heard
about some people wanting to disable additional threads
in processors (running 1 h/w thread per core) using cpu hotplug 
for some type of applications. I will check with those
folks as well.

> introduce a more sophisticated user interface which enables userspace to
> take multiple CPUs online and offline in a single step, rather than
> one-at-a-time.  I expect that'd be fairly straightforward.

The worry I have is that all of this is a complete rewrite of
existing CPU hotplug and it took us 1+ years to get a decent
CPU hotplug implementation. Rusty and Vatsa can probably vouch
for how difficult it was to get it right. I don't think
it is a good idea to keep CPU hotplug broken until this
rewrite happens. Can't we just go with something that is
already there and works correctly for us without waiting
for the perfect solution ?

Thanks
Dipankar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Fix /sys/device/.../power/state regression

[Greg KH]

On Fri, Jan 26, 2007 at 11:59:05AM -0800, Andrew Morton wrote:
> On Thu, 25 Jan 2007 05:00:09 +
> Matthew Garrett <[EMAIL PROTECTED]> wrote:
> 
> > In 2.6.19, support for splitting driver suspend and resume callbacks 
> > into interrupt and non-interrupt contexts was added. Unfortunately, this 
> > broke /sys/device/.../power/state support for all devices. In the long 
> > run, this should be obsoleted by power management support in the 
> > individual drivers - however, in the case of network drivers (for 
> > example), currently only three drivers implement any sort of useful 
> > run-time power management.
> > 
> > This patch allows the bus driver to check whether a specific driver 
> > requires the split. If not, the 2.6.18 functionality is restored. It 
> > also alters feature-removals.txt to note that the deprecated 
> > functionality should not be removed until a replacement actually exists.
> 
> That sounds like material for 2.6.20 as well as for 2.6.19.x.

No, it's not stable material, as drivers would have to be modified to
support it, and that is adding new stuff.  See my other comment about
why this was changed because it was broken...

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE

[Mel Gorman]

On Fri, 26 Jan 2007, Chris Friesen wrote:


Mel Gorman wrote:

Worse, the problem is to have high order contiguous blocks free at the time 
of allocation without reclaim or migration. If the allocations were not 
atomic, anti-fragmentation as it is today would be enough.


Has anyone looked at marking the buffers as "needs refilling" then kick off a 
kernel thread or something to do the allocations under GFP_KERNEL?


I haven't seen it being discussed although it's probably doable as an 
addition to the existing mempool mechanism. Anti-fragmentation would mean 
that the non-atomic GFP_KERNEL allocation had a chance of succeeding.



That way we avoid having to allocate the buffers with GFP_ATOMIC.



Unless the load was so high that the pool was getting depleted and memory 
under so much pressure that reclaim could not keep up. But yes, it's 
possible that GFP_ATOMIC allocations could be avoided the majority of 
times.


I seem to recall that the tulip driver used to do this.  Is it just too 
complicated from a race condition standpoint?




It shouldn't be that complicated.

We currently see this issue on our systems, as we have older e1000 hardware 
with 9KB jumbo frames.  After a while we just fail to allocate buffers and 
the system goes belly-up.




Can you describe a reliable way of triggering this problem? At best, I 
hear "on our undescribed workload, we sometimes see this problem" but not 
much in the way of details.


--
Mel Gorman
Part-time Phd Student  Linux Technology Center
University of Limerick IBM Dublin Software Lab
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Fix /sys/device/.../power/state regression

[Greg KH]

On Thu, Jan 25, 2007 at 05:00:09AM +, Matthew Garrett wrote:
> In 2.6.19, support for splitting driver suspend and resume callbacks 
> into interrupt and non-interrupt contexts was added. Unfortunately, this 
> broke /sys/device/.../power/state support for all devices. In the long 
> run, this should be obsoleted by power management support in the 
> individual drivers - however, in the case of network drivers (for 
> example), currently only three drivers implement any sort of useful 
> run-time power management.
> 
> This patch allows the bus driver to check whether a specific driver 
> requires the split. If not, the 2.6.18 functionality is restored. It 
> also alters feature-removals.txt to note that the deprecated 
> functionality should not be removed until a replacement actually exists.

Ick, no.

As stated before, it was broken in the past, and no userspace tools use
it because of that.  So it was disabled.

Or am I misstating that long thread?  David, your thoughts?

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fw: Re: [mm PATCH 4/6] RCU: (now) CPU hotplug

[Andrew Morton]

On Sat, 27 Jan 2007 01:16:22 +0530
Dipankar Sarma <[EMAIL PROTECTED]> wrote:

> > The plan is, I hope, to rip it all out and do freeze_processes() on the
> > hotplug side, so nobody else needs to worry about cpu hotplug any more. 
> > But at present everyone seems to be in hiding.
> 
> This would be ideal. However, we don't seem to have any momentum
> on this.

There's no point in expending effort on a fancy new lock until this option
has been eliminated, so yeah, things are stuck.

> The other thing we would need to do in this case is to
> check if all the users of cpu hotplug can tolerate a very slow
> hotplug step if there are 10s of thousands of processes and threads.

Yes, that needs evaluation.  If it's a problem then we might need to
introduce a more sophisticated user interface which enables userspace to
take multiple CPUs online and offline in a single step, rather than
one-at-a-time.  I expect that'd be fairly straightforward.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] lutimesat: simplify utime(2)

[Andrew Morton]

On Fri, 26 Jan 2007 14:21:42 +0300
Alexey Dobriyan <[EMAIL PROTECTED]> wrote:

> Rewrite via do_utimes() like compat_sys_utime().
> 
> Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
> ---
> 
>  fs/utimes.c |   50 +++---
>  1 file changed, 7 insertions(+), 43 deletions(-)
> 
> --- a/fs/utimes.c
> +++ b/fs/utimes.c
> @@ -22,52 +22,16 @@ #ifdef __ARCH_WANT_SYS_UTIME
>   */
>  asmlinkage long sys_utime(char __user * filename, struct utimbuf __user * 
> times)
>  {
> - int error;
> - struct nameidata nd;
> - struct inode * inode;
> - struct iattr newattrs;
> + struct timeval tv[2];
>  
> - error = user_path_walk(filename, );
> - if (error)
> - goto out;
> - inode = nd.dentry->d_inode;
> -
> - error = -EROFS;
> - if (IS_RDONLY(inode))
> - goto dput_and_out;
> -
> - /* Don't worry, the checks are done in inode_change_ok() */
> - newattrs.ia_valid = ATTR_CTIME | ATTR_MTIME | ATTR_ATIME;
>   if (times) {
> - error = -EPERM;
> - if (IS_APPEND(inode) || IS_IMMUTABLE(inode))
> - goto dput_and_out;
> -
> - error = get_user(newattrs.ia_atime.tv_sec, >actime);
> - newattrs.ia_atime.tv_nsec = 0;
> - if (!error)
> - error = get_user(newattrs.ia_mtime.tv_sec, 
> >modtime);
> - newattrs.ia_mtime.tv_nsec = 0;
> - if (error)
> - goto dput_and_out;
> -
> - newattrs.ia_valid |= ATTR_ATIME_SET | ATTR_MTIME_SET;
> - } else {
> -error = -EACCES;
> -if (IS_IMMUTABLE(inode))
> -goto dput_and_out;
> -
> - if (current->fsuid != inode->i_uid &&
> - (error = vfs_permission(, MAY_WRITE)) != 0)
> - goto dput_and_out;
> + if (get_user(tv[0].tv_sec, >actime) ||
> + get_user(tv[1].tv_sec, >modtime))
> + return -EFAULT;
> + tv[0].tv_usec = 0;
> + tv[1].tv_usec = 0;
>   }
> - mutex_lock(>i_mutex);
> - error = notify_change(nd.dentry, );
> - mutex_unlock(>i_mutex);
> -dput_and_out:
> - path_release();
> -out:
> - return error;
> + return do_utimes(AT_FDCWD, filename, times ? tv : NULL);
>  }
>  
>  #endif

I'm somewhat surprised that this wasn't done earlier.  I wonder if there's
some subtle reason why this won't work.   How well tested is this?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] lutimesat: actual syscall and wire-up on i386

[Andrew Morton]

On Fri, 26 Jan 2007 14:23:45 +0300
Alexey Dobriyan <[EMAIL PROTECTED]> wrote:

> lutimesat(2) does everything futimesat(2) does except it doesn't follow
> symlinks.
> 
> It could be used by tar(1) and cp(1).
> 
> FreeBSD and NetBSD have lutimes(2) which can be emulated by C library:
> 
>   lutimesat(AT_FDCWD, filename, utimes)
> 
> Closes http://bugme.osdl.org/show_bug.cgi?id=4433
> 
efine __ARCH_WANT_IPC_PARSE_VERSION
>  #define __ARCH_WANT_OLD_READDIR

OK, but I don't recall having seeing a demand for lutimes().  Opinions
are sought?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE

[Mel Gorman]

On Fri, 26 Jan 2007, Christoph Lameter wrote:


On Fri, 26 Jan 2007, Mel Gorman wrote:


The zone-based approach does nothing to help jumbo frame allocations. It only
helps hugepage allocations at runtime and potentially memory hot-remove.


Sounds like the max order based approach is better in many ways.


I agree but too many people are not pleased with the main allocator path 
being affected and wanted to see zones, so here we are :)



Also avoids modifications to vmstat.c/.h ;-)



--
Mel Gorman
Part-time Phd Student  Linux Technology Center
University of Limerick IBM Dublin Software Lab
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/8] Create ZONE_MOVABLE to partition memory between movable and non-movable pages

[Andrew Morton]

On Fri, 26 Jan 2007 11:58:18 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:

> > If the only demonstrable benefit is a saving of a few k of text on a small
> > number of machines then things are looking very grim, IMO.
> 
> The main benefit is a significant simplification of the VM, leading to 
> robust and reliable operations and a reduction of the maintenance 
> headaches coming with the additional zones.
> 
> If we would introduce the ability of allocating from a range of 
> physical addresses then the need for DMA zones would go away allowing 
> flexibility for device driver DMA allocations and at the same time we get 
> rid of special casing in the VM.

None of this is valid.  The great majority of machines out there will
continue to have the same number of zones.  Nothing changes.

What will happen is that a small number of machines will have different
runtime behaviour.  So they don't benefit from the majority's testing and
they don't contrinute to it and they potentially have unique-to-them
problems which we need to worry about.

That's all a real cost, so we need to see *good* benefits to outweigh that
cost.  Thus far I don't think we've seen that.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

How to create a fixed length character/block device/file ?

[Khai Doan]

Sorry if this is the wrong list.  I've search google, but have not found 
solution to my problem.


I have a long running application which split out lots of debugging 
information.  I can't redirect the output to a regular file because that 
file would grow and eat up all the diskspace.  I can't redirect to 
/dev/null.  What I want is the last 1MB of the output before my 
application terminated.  So I need to create a special file / device on 
the system.  Please tell me if  there is an existing device that I can 
use, or point me in the right direction so that I can role my own device.


Thanks
Khai Doan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: sed _s_gnu_alternatives_ (Re: [rft] (g)awk substitution)

[Oleg Verych]

On Fri, Jan 26, 2007 at 12:47:20PM -0500, Rob Landley wrote:
> On Thursday 25 January 2007 4:18 pm, Oleg Verych wrote:
> 
> > > As I said, I'm not particularly interested in a more intrusive solution 
> > > solving a problem I haven't actually seen.  I don't see any obvious 
> > > reason 
> > > why it wouldn't work, and yes it would probably also solve my problem, but
> > > I still don't see why you think it's "better" than the three byte fix.
> > 
> > Ehhh. "I'm not guilty" issue. Well, fine ;)
> 
> "guilty"?
> 
> You attempted to hijack my simple observation ("awk is the standard name, 
> gawk 
> is not") into an attempt to replace susv3 standard utilities with extra shell 
> script.  This is a separate agenda, and I have _no_ idea why you think I'm 
> obligated to pursue it for you.
> 
> The motivation for my patch is taht circa 2.6.12 I didn't need gawk on my 
> system to build; the need for it cropped up fairly recently.  This is A) an 
> artificial requirement, B) a regression, C) trivial to fix.
> 
> I could also teach busybox awk to be called as "gawk", but awk is the 
> standard 
> name and gawk is not, and gawk can already be called as awk.  The _clean_ 
> thing to do is send a patch to get Linux to use the standard name, which I 
> did.  This is the minimally intrusive change, and since gawk's install 
> creates an awk symlink it shouldn't affect any existing systems.
> 
> That's what I did.  I am simply not interested in your attempts to do 
> something else, in hopes of fixing a problem I haven't seen and which I'm not 
> convinced actually exists.

IMHO every embedded developer besides size cares about speed and
reducing complexity of simple things. Yes, this is orthogonal to that,
you want to say to me.

Only thing i wanted to have as reasult is ack or nack on my patch.
Everything else is outside LKML.

> > If your current system is IA-32, or you have access to one, would you
> > like to test scripts/makelst for me, as i'm seeing `bc' there. But my 
> > system have not one, i would like to replace it with shell or awk or
> > whatever. TIA.
> 
> According to Posix and SUSv3, a development environment can be expected to 
> have bc:
> http://www.opengroup.org/onlinepubs/009695399/utilities/bc.html
> 
> Would you like to try the one in busybox?

In Debian's version it has no `bc', while native `bc' is producing
crap like that:
,-*- bash -*-
|[EMAIL PROTECTED]:~$ printf "%u" $(( -1 )) ; echo
|18446744073709551615
|[EMAIL PROTECTED]:~$ echo -1 | bc
|-1
|[EMAIL PROTECTED]:~$ printf "%u" $(( 0xFF )) ; echo
|255
|[EMAIL PROTECTED]:~$ echo FF | bc
|99
|[EMAIL PROTECTED]:~$ echo F | bc
|15
|[EMAIL PROTECTED]:~$
`-*-

i can't understand the result... I think linux/scripts/makelst may be
updated to have sh's version of address calculation ;)

> The minimal development environment I can build a working system in is 7 
> packages: linux, gcc, binutils, make, busybox, uClibc, bash.  This is not 
> theoretical: I have actually done this, and I was building systems under this 
> as far back as 2003.  (I became busybox maintainer after spending 2 years 
> upgrading busybox to make this _work_.  I started by rewriting sed.  I didn't 
> _know_ sed at the time, but binutils ./configure used some rather advanced 
> sed scripts to build, so I fixed it.  It works now.)

I'm glad. All i can say in this context: do you know `dash' shell.
It's pretty much OK for not interactive use, small, fast, POSIX
compliant (or should be ;).

> I'm using this to get a minimal native environment on non-x86 target 
> platforms, to minimize the amount of cross compiling I have to do when 
> bootstrapping a new platform.  (I submitted an OLS tutorial proposal on this, 
> although I dunno if they're interested.)

Goodluck!


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Don't allow the stack to grow into hugetlb reserved regions

[Andrew Morton]

On Thu, 25 Jan 2007 13:40:52 -0800
Adam Litke <[EMAIL PROTECTED]> wrote:

> When expanding the stack, we don't currently check if the VMA will cross into
> an area of the address space that is reserved for hugetlb pages.  Subsequent
> faults on the expanded portion of such a VMA will confuse the low-level MMU
> code, resulting in an OOPS.  Check for this.

We prefer not to oops.  Is there any reason why this isn't a serious fix, needed
in 2.6.20 and 2.6.19?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Fix /sys/device/.../power/state regression

[Andrew Morton]

On Thu, 25 Jan 2007 05:00:09 +
Matthew Garrett <[EMAIL PROTECTED]> wrote:

> In 2.6.19, support for splitting driver suspend and resume callbacks 
> into interrupt and non-interrupt contexts was added. Unfortunately, this 
> broke /sys/device/.../power/state support for all devices. In the long 
> run, this should be obsoleted by power management support in the 
> individual drivers - however, in the case of network drivers (for 
> example), currently only three drivers implement any sort of useful 
> run-time power management.
> 
> This patch allows the bus driver to check whether a specific driver 
> requires the split. If not, the 2.6.18 functionality is restored. It 
> also alters feature-removals.txt to note that the deprecated 
> functionality should not be removed until a replacement actually exists.

That sounds like material for 2.6.20 as well as for 2.6.19.x.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/8] Create ZONE_MOVABLE to partition memory between movable and non-movable pages

[Christoph Lameter]

On Fri, 26 Jan 2007, Andrew Morton wrote:

> As Mel points out, distros will ship with CONFIG_ZONE_DMA=y, so the number
> of machines which will actually benefit from this change is really small. 
> And the benefit to those few machines will also, I suspect, be small.
> 
> > > - We kicked around some quite different ways of implementing the same
> > >   things, but nothing came of it.  iirc, one was to remove the hard-coded
> > >   zones altogether and rework all the MM to operate in terms of
> > > 
> > >   for (idx = 0; idx < NUMBER_OF_ZONES; idx++)
> > >   ...
> > 
> > Hmmm.. How would that be simpler?
> 
> Replace a sprinkle of open-coded ifdefs with a regular code sequence which
> everyone uses.  Pretty obvious, I'd thought.

We do use such loops in many places. However, stuff like array 
initialization and special casing cannot use a loop. I am not sure what we 
could change there. The hard coding is necessary because each zone 
currently has these invariant characteristics that we need to consider. 
Reducing the number of zones reduces the amount of special casing in the 
VM that needs to be considered at run time and that is a potential issue
for trouble.

> Plus it becoems straightforward to extend this from the present four zones
> to a complete 12 zones, which gives use the full set of
> ZONE_DMA20,ZONE_DMA21,...,ZONE_DMA32 for those funny devices.

I just hope we can handle the VM complexity of load balancing etc etc that 
this will introduce. Also each zone has management overhead and will cause 
the touching of additional cachelines on many VM operations. Much of that 
management overhead becomes unnecessary if we reduce zones.

> If the only demonstrable benefit is a saving of a few k of text on a small
> number of machines then things are looking very grim, IMO.

The main benefit is a significant simplification of the VM, leading to 
robust and reliable operations and a reduction of the maintenance 
headaches coming with the additional zones.

If we would introduce the ability of allocating from a range of 
physical addresses then the need for DMA zones would go away allowing 
flexibility for device driver DMA allocations and at the same time we get 
rid of special casing in the VM.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Juju

[Kristian Høgsberg]

Greg KH wrote:

On Thu, Jan 25, 2007 at 03:38:24PM -0800, Pete Zaitcev wrote:

On Thu, 25 Jan 2007 16:18:35 -0500, Kristian H??gsberg <[EMAIL PROTECTED]> 
wrote:


I see that ORBs are always allocated with a call (like SKB) and not
embedded into drivers (like URBs). It's great, keep it up. Also,
never allow drivers to pass DMA-mapped buffers into fw_send_request
and friends. We made both of these mistakes in USB, and it hurts.
Oh, the ORBs are SBP-2 specific data structures, struct fw_transaction is 
probably what corresponds to USB URBs.  This struct is defined in 
fw-transaction.h and is available for embedding into other structs, such as 
struct sbp2_orb in fw-sbp2.  Is that what you're suggesting against, and what 
are the problems with this approach?

Fortunately we do not care about out-of-tree drivers, which are most
affected, you may even call it a feature ^_^. My main problem is,
we can't refcount URBs, so usbmon can't tap them and must copy.


urbs are reference counted, it's just that not all drivers who create
them use them that way :(

Perhaps you can inforce this in the new codebase...


It's a small change to make the fw_transaction struct opaque and ref-counted, 
and it's definitely still doable.  But the nice thing about embedding the 
struct is that you have one memory allocation failure path less to worry 
about.  And I haven't yet, and don't expect to see a use case that will need 
ref-counted struct fw_transaction, the ownership is always clearly defined. 
But I can go either way on this and if there is a good reason to ref count 
them it's a pretty small change.


cheers,
Kristian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] fix OCFS2 compile error

[Adrian Bunk]

On Fri, Jan 26, 2007 at 11:47:13AM -0800, Mark Fasheh wrote:
> On Fri, Jan 26, 2007 at 07:49:42PM +0100, Adrian Bunk wrote:
> > I don't know why gcc 3.3 generates this now since ocfs2_backup_super_blkno()
> > seems to be unused, but there is a bug for 32 bit systems that should be 
> > fixed:
> > 
> > Commit 50af94b14c98f5769860a282a397c6f3b135c8a8 adds:
> >   offset /= sb->s_blocksize;
> > 
> > That is:
> >   u64 = u64 / long
> > 
> > Not a problem on 64bit architectures, but obviously a problem on 32 bit 
> > architectures.
> > 
> > This patch fixes it by using sb->s_blocksize_bits instead of 
> > sb->s_blocksize.
> 
> Thanks Adrian... I think we both hit upon this at about the same time :) My
> patch made it into ocfs2.git first (for obvious reasons)...

That's unfair.  ;-)

>   --Mark

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fw: Re: [mm PATCH 4/6] RCU: (now) CPU hotplug

[Andrew Morton]

On Sat, 27 Jan 2007 00:41:13 +0530
Dipankar Sarma <[EMAIL PROTECTED]> wrote:

> On Thu, Jan 25, 2007 at 02:36:45AM +0530, Dipankar Sarma wrote:
> > On Wed, Jan 24, 2007 at 08:15:59AM -0800, Paul E. McKenney wrote:
> > 
> > It should be relatively easy. Setting the offlined cpu's flags
> > to neutral state should do the trick in most cases.
> > I will send out the patches tomorrow after reviewing the code
> > some more.
> 
> Famous last words. 
> 
> It turns out that I have been bitten by the ugly cpu hotplug
> locking mess while trying to get preemptible RCU code working
> with CPU hotplug. The per-subsystem locking thing isn't really
> user-friendly. Here is the dependency -
> 
> In cpu hotplug path (after CPU_LOCK_ACQUIRE) -
> 
> CPU_DOWN_PREPARE:sched domains -> detach_destroy_domains() ->
>   synchronize_sched() -> sched_setaffinity()
> 
> sched_setaffinity() tries to acquire the scheduler cpu hotplug
> mutex and deadlocks.
> 
> I see no easy way of getting around this - doing "cpu hotplug locked"
> version of all those APIs would add lots of code which is bad.
> We could try Gautham's idea of letting  each subsystem maintain
> its own online cpu mask, but I bet implementing sched_setaffinity()
> would not be very easy despite this.

Suggest you just ignore cpu hotplug locking, if that helps.

> What is the status on this now ?

Stalled, apparently.

> Is this a good example to
> show why per-subsystem locks might be unmaintainable ?

Maybe.  It might also be a good example of confused design.

> Can we go back

"back" assumes it was once present.  It wasn't.

> to a simple

"simple" hasn't been demonstrated.  New lock types and their use are never
simple, especially magic ones.

> scalable refcount model
> for CPU hotplug now ?

The plan is, I hope, to rip it all out and do freeze_processes() on the
hotplug side, so nobody else needs to worry about cpu hotplug any more. 
But at present everyone seems to be in hiding.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] fix OCFS2 compile error

[Mark Fasheh]

On Fri, Jan 26, 2007 at 07:49:42PM +0100, Adrian Bunk wrote:
> I don't know why gcc 3.3 generates this now since ocfs2_backup_super_blkno()
> seems to be unused, but there is a bug for 32 bit systems that should be 
> fixed:
> 
> Commit 50af94b14c98f5769860a282a397c6f3b135c8a8 adds:
>   offset /= sb->s_blocksize;
> 
> That is:
>   u64 = u64 / long
> 
> Not a problem on 64bit architectures, but obviously a problem on 32 bit 
> architectures.
> 
> This patch fixes it by using sb->s_blocksize_bits instead of sb->s_blocksize.

Thanks Adrian... I think we both hit upon this at about the same time :) My
patch made it into ocfs2.git first (for obvious reasons)...
--Mark

--
Mark Fasheh
Senior Software Developer, Oracle
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: fsync occasionally very slow

[Andrew Morton]

On Fri, 26 Jan 2007 14:33:36 -0500
"Matthew Kirk" <[EMAIL PROTECTED]> wrote:

> Sorry, this will show my ignorance...  my system is lacking
> /proc/sysrq-trigger.  I can find how to build a kernel with the magic sysrq
> key (CONFIG_MAGIC_SYSRQ=y), and have done so, but I still don't have
> /proc/sysrq-* and cannot seem to find how to build in sysrq functionality
> itself - assuming that's what's missing.  Presumably it's something in
> .config I'm just not seeing?
> 

I think you're running a prehistoric kernel which might predate
/proc/sysrq-trigger?

You can get the same effect by typing alt-sysrq-t at the right time (or
whatever the combination is on that machine).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fw: Re: [mm PATCH 4/6] RCU: (now) CPU hotplug

[Dipankar Sarma]

On Fri, Jan 26, 2007 at 11:28:37AM -0800, Andrew Morton wrote:
> On Sat, 27 Jan 2007 00:41:13 +0530
> Dipankar Sarma <[EMAIL PROTECTED]> wrote:
> 
> > Is this a good example to
> > show why per-subsystem locks might be unmaintainable ?
> 
> Maybe.  It might also be a good example of confused design.

Not this one. The point is that this forces us to determine
which APIs are usable in cpu hotplug path and which aren't.
It isn't unreasonable to expect that some one may need
to use sched_setaffinity() in hotplug path. This now forces
us to have two versions of sched_setaffinity() - one with
the hotplug per-subsystem lock, the other one without.

> > Can we go back
> 
> "back" assumes it was once present.  It wasn't.

IIRC, there was one get_cpu_hotplug()/put_cpu_hotplug() implementation
based on Arjan's suggestion and implemented in a scalable way by Gautham.

> 
> > to a simple
> 
> "simple" hasn't been demonstrated.  New lock types and their use are never
> simple, especially magic ones.

get_cpu_hotplug()/put_cpu_hotplug() hides all the refcount complexities
underneath and most kernel programmers are familiar with the
get()/put() model. This seems like the most simple thing we
could do in the short term without making too many changes in all over the
kernel for CPU hotplug.

> 
> > scalable refcount model
> > for CPU hotplug now ?
> 
> The plan is, I hope, to rip it all out and do freeze_processes() on the
> hotplug side, so nobody else needs to worry about cpu hotplug any more. 
> But at present everyone seems to be in hiding.

This would be ideal. However, we don't seem to have any momentum
on this. The other thing we would need to do in this case is to
check if all the users of cpu hotplug can tolerate a very slow
hotplug step if there are 10s of thousands of processes and threads.

Thanks
Dipankar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/8] Create ZONE_MOVABLE to partition memory between movable and non-movable pages

[Andrew Morton]

On Fri, 26 Jan 2007 07:56:09 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:

> On Fri, 26 Jan 2007, Andrew Morton wrote:
> 
> > - They add zillions of ifdefs
> 
> They just add a few for ZONE_DMA where we alreaday have similar ifdefs for 
> ZONE_DMA32 and ZONE_HIGHMEM.

I refreshed my memory.  It remains awful.

> > - They make the VM's behaviour diverge between different platforms and
> >   between differen configs on the same platforms, and hence degrade
> >   maintainability and increase complexity.
> 
> They avoid unecessary complexity on platforms. They could be made to work 
> on more platforms with measures to deal with what ZONE_DMA 
> provides in different ways. There are 6 or so platforms that do not need 
> ZONE_DMA at all.

As Mel points out, distros will ship with CONFIG_ZONE_DMA=y, so the number
of machines which will actually benefit from this change is really small. 
And the benefit to those few machines will also, I suspect, be small.

> > - We kicked around some quite different ways of implementing the same
> >   things, but nothing came of it.  iirc, one was to remove the hard-coded
> >   zones altogether and rework all the MM to operate in terms of
> > 
> > for (idx = 0; idx < NUMBER_OF_ZONES; idx++)
> > ...
> 
> Hmmm.. How would that be simpler?

Replace a sprinkle of open-coded ifdefs with a regular code sequence which
everyone uses.  Pretty obvious, I'd thought.

Plus it becoems straightforward to extend this from the present four zones
to a complete 12 zones, which gives use the full set of
ZONE_DMA20,ZONE_DMA21,...,ZONE_DMA32 for those funny devices.

> > - I haven't seen any hard numbers to justify the change.
> 
> I have send you numbers showing significant reductions in code size.

If it isn't in the changelog it doesn't exist.  I guess I didn't copy it
into the changelog.

If the only demonstrable benefit is a saving of a few k of text on a small
number of machines then things are looking very grim, IMO.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mm snapshot broken-out-2007-01-26-00-36.tar.gz uploaded

[Michal Piotrowski]

[EMAIL PROTECTED] napisał(a):
> The mm snapshot broken-out-2007-01-26-00-36.tar.gz has been uploaded to
> 
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-01-26-00-36.tar.gz

security/selinux/hooks.c: In function 'selinux_sysctl':
security/selinux/hooks.c:1440: error: 'ctl_table' has no member named 'de'
make[2]: *** [security/selinux/hooks.o] Error 1
make[1]: *** [security/selinux] Error 2
make: *** [security] Error 2

Sysctl patches?

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[LOCKDEP] Possible recursive locking detected

[Sean Young]

.config: http://www.msxnet.org/config-2.6.20-rc5

=
[ INFO: possible recursive locking detected ]
2.6.20-rc5 #1
-
swapper/0 is trying to acquire lock:
 (>lock){++..}, at: [] __wake_up+0x18/0x43

but task is already holding lock:
 (>lock){++..}, at: [] __wake_up+0x18/0x43

other info that might help us debug this:
3 locks held by swapper/0:
 #0:  (slock-AF_INET/1){-+..}, at: [] tcp_v4_rcv+0x673/0x85b
 #1:  (af_callback_keys + sk->sk_family#2){-.-?}, at: [] 
sock_def_readable+0x15/0x6e
 #2:  (>lock){++..}, at: [] __wake_up+0x18/0x43

stack backtrace:
 [] __lock_acquire+0xab7/0xd7b
 [] add_lock_to_list+0x36/0x8f
 [] lock_acquire+0x57/0x6f
 [] __wake_up+0x18/0x43
 [] _spin_lock_irqsave+0x32/0x41
 [] __wake_up+0x18/0x43
 [] __wake_up+0x18/0x43
 [] ep_poll_safewake+0x9b/0xd4
 [] ep_poll_callback+0x83/0xb4
 [] __wake_up_common+0x39/0x59
 [] __wake_up+0x32/0x43
 [] sock_def_readable+0x6c/0x6e
 [] tcp_data_queue+0x421/0xbd1
 [] tcp_v4_rcv+0x673/0x85b
 [] tcp_rcv_established+0x360/0x68b
 [] tcp_v4_do_rcv+0x95/0x2d9
 [] tcp_v4_rcv+0x673/0x85b
 [] _spin_lock_nested+0x27/0x32
 [] tcp_v4_rcv+0x849/0x85b
 [] ip_local_deliver+0x100/0x268
 [] _spin_lock+0x29/0x34
 [] ip_rcv+0x263/0x467
 [] enable_8259A_irq+0xd/0x4b
 [] enable_8259A_irq+0xd/0x4b
 [] netif_receive_skb+0x1f3/0x2e7
 [] trace_hardirqs_on+0x76/0x14a
 [] process_backlog+0x79/0xf3
 [] net_rx_action+0x97/0x167
 [] __do_softirq+0x4b/0x9c
 [] do_softirq+0x3f/0x41
 [] do_IRQ+0x52/0x8a
 [] common_interrupt+0x24/0x34
 [] common_interrupt+0x2e/0x34
 [] acpi_processor_idle+0x1bc/0x356 [processor]
 [] acpi_processor_idle+0x1bf/0x356 [processor]
 [] cpu_idle+0x39/0x4e
 [] start_kernel+0x28f/0x32a
 [] unknown_bootoption+0x0/0x259
 ===
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH updated] arm: i.MX/MX1 clock event source

[Pavel Pisa]

On Wednesday 24 January 2007 12:37, Thomas Gleixner wrote:
> On Wed, 2007-01-24 at 03:00 +0100, Pavel Pisa wrote:
> > stays NULL after clock event registration. Interrupts
> > runs, but my code doesnot call any function. The notification
> > chain and clock events list seems to be filled correctly.
> > I have added
> >
> > clockevent_imx.cpumask = cpumask_of_cpu(0);
>
> Correct. I probably should disable the check for UP.

I have made mistake last time on 2.6.20-rc5-rt8.
I have returned to testing today with 2.6.20-rc6-rt2.
I have added checking outputs to the tickregistration
routines, but all works correctly after right cpumask correction.
I have rechecked even without additional printks
and I have observed no problems. The clock events enabled kernels
requires next minor changes to compile on ARM still




 arch/arm/kernel/process.c |5 +++--
 kernel/time/tick-sched.c  |1 +
 2 files changed, 4 insertions(+), 2 deletions(-)

Index: linux-2.6.20-rc6/kernel/time/tick-sched.c
===
--- linux-2.6.20-rc6.orig/kernel/time/tick-sched.c
+++ linux-2.6.20-rc6/kernel/time/tick-sched.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "tick-internal.h"
 
Index: linux-2.6.20-rc6/arch/arm/kernel/process.c
===
--- linux-2.6.20-rc6.orig/arch/arm/kernel/process.c
+++ linux-2.6.20-rc6/arch/arm/kernel/process.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -154,11 +155,11 @@ void cpu_idle(void)
if (!idle)
idle = default_idle;
leds_event(led_idle_start);
-   hrtimer_stop_sched_tick();
+   tick_nohz_stop_sched_tick();
while (!need_resched() && !need_resched_delayed())
idle();
leds_event(led_idle_end);
-   hrtimer_restart_sched_tick();
+   tick_nohz_restart_sched_tick();
local_irq_disable();
__preempt_enable_no_resched();
__schedule();




Updated version of i.MX patch follows. If somebody wants it,
I can send patch to revert code of previous version from
full 2.6.20-rc6-rt2 patch.

Ingo, please, can you replace i.MX1 patch in your series?

Thanks

  Pavel



Subject: arm: i.MX/MX1 clock event source

Support clock event source based on i.MX general purpose
timer in free running timer mode.

Signed-off-by: Pavel Pisa <[EMAIL PROTECTED]>

 arch/arm/mach-imx/time.c |  130 +--
 1 file changed, 125 insertions(+), 5 deletions(-)

Index: linux-2.6.20-rc6/arch/arm/mach-imx/time.c
===
--- linux-2.6.20-rc6.orig/arch/arm/mach-imx/time.c
+++ linux-2.6.20-rc6/arch/arm/mach-imx/time.c
@@ -15,6 +15,9 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+#include 
+#endif
 
 #include 
 #include 
@@ -25,6 +28,11 @@
 /* Use timer 1 as system timer */
 #define TIMER_BASE IMX_TIM1_BASE
 
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+static struct clock_event_device clockevent_imx;
+static enum clock_event_mode clockevent_mode = CLOCK_EVT_MODE_PERIODIC;
+#endif
+
 static unsigned long evt_diff;
 
 /*
@@ -33,6 +41,7 @@ static unsigned long evt_diff;
 static irqreturn_t
 imx_timer_interrupt(int irq, void *dev_id)
 {
+   unsigned long tcmp;
uint32_t tstat;
 
/* clear the interrupt */
@@ -42,13 +51,20 @@ imx_timer_interrupt(int irq, void *dev_i
if (tstat & TSTAT_COMP) {
do {
 
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+   if (clockevent_imx.event_handler)
+   clockevent_imx.event_handler(_imx);
+   if (likely(clockevent_mode != CLOCK_EVT_MODE_PERIODIC))
+   break;
+#else
write_seqlock(_lock);
timer_tick();
write_sequnlock(_lock);
-   IMX_TCMP(TIMER_BASE) += evt_diff;
+#endif
+   tcmp = IMX_TCMP(TIMER_BASE) + evt_diff;
+   IMX_TCMP(TIMER_BASE) = tcmp;
 
-   } while (unlikely((int32_t)(IMX_TCMP(TIMER_BASE)
-   - IMX_TCN(TIMER_BASE)) < 0));
+   } while (unlikely((int32_t)(tcmp - IMX_TCN(TIMER_BASE)) < 0));
}
 
return 

RE: fsync occasionally very slow

[Matthew Kirk]

Sorry, this will show my ignorance...  my system is lacking
/proc/sysrq-trigger.  I can find how to build a kernel with the magic sysrq
key (CONFIG_MAGIC_SYSRQ=y), and have done so, but I still don't have
/proc/sysrq-* and cannot seem to find how to build in sysrq functionality
itself - assuming that's what's missing.  Presumably it's something in
.config I'm just not seeing?

Thanks again!

Matt

-Original Message-
From: Andrew Morton [mailto:[EMAIL PROTECTED] 
Sent: Friday, January 26, 2007 6:17 AM
To: Matthew Kirk
Cc: linux-kernel@vger.kernel.org
Subject: Re: fsync occasionally very slow

On Fri, 26 Jan 2007 05:37:38 -0500
"Matthew Kirk" <[EMAIL PROTECTED]> wrote:

> I am working on an application that fsync(2) files and directories as
> needed.I’m seeing intermittent stalls on fsync that can last many
> seconds.

Please generate an all-task backtrace during the stall via:

dmesg -n 8

echo t > /prov/sysrq-trigger
dmesg -s 100 > foo

and send foo.

-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.410 / Virus Database: 268.17.11/652 - Release Date: 1/25/2007
 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.410 / Virus Database: 268.17.12/653 - Release Date: 1/26/2007
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/