[PATCH] lib: crc-itu-t: Fix typo in comment

[David Mosberger-Tang]

Signed-off-by: David Mosberger-Tang 
---
 lib/crc-itu-t.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/crc-itu-t.c b/lib/crc-itu-t.c
index 1974b355c148..1d26a1647da5 100644
--- a/lib/crc-itu-t.c
+++ b/lib/crc-itu-t.c
@@ -7,7 +7,7 @@
 #include 
 #include 
 
-/** CRC table for the CRC ITU-T V.41 0x1021 (x^16 + x^12 + x^15 + 1) */
+/* CRC table for the CRC ITU-T V.41 0x1021 (x^16 + x^12 + x^5 + 1) */
 const u16 crc_itu_t_table[256] = {
0x, 0x1021, 0x2042, 0x3063, 0x4084, 0x50a5, 0x60c6, 0x70e7,
0x8108, 0x9129, 0xa14a, 0xb16b, 0xc18c, 0xd1ad, 0xe1ce, 0xf1ef,
-- 
2.25.1

[PATCH] lib: crc-itu-t: Fix comment in typo

[David Mosberger-Tang]

Signed-off-by: David Mosberger-Tang 
---
 lib/crc-itu-t.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/crc-itu-t.c b/lib/crc-itu-t.c
index 1974b355c148..56e6e0d63d1e 100644
--- a/lib/crc-itu-t.c
+++ b/lib/crc-itu-t.c
@@ -7,7 +7,7 @@
 #include 
 #include 
 
-/** CRC table for the CRC ITU-T V.41 0x1021 (x^16 + x^12 + x^15 + 1) */
+/** CRC table for the CRC ITU-T V.41 0x1021 (x^16 + x^12 + x^5 + 1) */
 const u16 crc_itu_t_table[256] = {
0x, 0x1021, 0x2042, 0x3063, 0x4084, 0x50a5, 0x60c6, 0x70e7,
0x8108, 0x9129, 0xa14a, 0xb16b, 0xc18c, 0xd1ad, 0xe1ce, 0xf1ef,
-- 
2.25.1

[PATCH] drivers: nvmem: atmel-secumod: New driver for Atmel Secumod nvram

[David Mosberger-Tang]

Signed-off-by: David Mosberger <dav...@egauge.net>
---
 .../devicetree/bindings/nvmem/atmel-secumod.txt|  47 +++
 drivers/nvmem/Kconfig  |   7 +
 drivers/nvmem/Makefile |   2 +
 drivers/nvmem/atmel-secumod.c  | 143 +
 4 files changed, 199 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/atmel-secumod.txt
 create mode 100644 drivers/nvmem/atmel-secumod.c

diff --git a/Documentation/devicetree/bindings/nvmem/atmel-secumod.txt 
b/Documentation/devicetree/bindings/nvmem/atmel-secumod.txt
new file mode 100644
index 000..d65cad5
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/atmel-secumod.txt
@@ -0,0 +1,47 @@
+= Atmel Secumod device tree bindings =
+
+This binding is intended to represent Atmel's Secumod which is found
+in SAMA5D2 and perhaps others.
+
+Required properties:
+- compatible: should be "atmel,sama5d2-secumod"
+- reg: Should contain RAM location and length, followed
+   by register location and length of the Secumod controller.
+
+= Data cells =
+Are child nodes of secumod, bindings of which as described in
+bindings/nvmem/nvmem.txt
+
+Example:
+
+secumod@fc04 {
+compatible = "atmel,sama5d2-secumod";
+reg = <0xf8044000 0x1420>, <0xfc04 0x4000>;
+reg-names = "SECURAM", "SECUMOD";
+status = "okay";
+
+#address-cells = <1>;
+#size-cells = <1>;
+ranges;
+
+secram-auto-erasable@0 {
+reg = <0x 0x1000>;
+};
+secram@1000 {
+reg = <0x1000 0x400>;
+};
+ram@1400 {
+reg = <0x1400 0x20>;
+};
+};
+
+= Data consumers =
+Are device nodes which consume nvmem data cells.
+
+For example:
+
+   ram {
+   ...
+   nvmem-cells = <>;
+   nvmem-cell-names = "RAM";
+   };
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 3041d48..88b21e3 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -101,4 +101,11 @@ config NVMEM_VF610_OCOTP
  This driver can also be build as a module. If so, the module will
  be called nvmem-vf610-ocotp.
 
+config NVMEM_ATMEL_SECUMOD
+   tristate "Atmel Secure Module driver"
+   depends on ARCH_AT91
+   help
+ Select this to get support for the secure module (SECUMOD) built
+into the SAMA5D2 chips.
+
 endif
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 45ab1ae..9cbd950 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -22,3 +22,5 @@ obj-$(CONFIG_NVMEM_SUNXI_SID) += nvmem_sunxi_sid.o
 nvmem_sunxi_sid-y  := sunxi_sid.o
 obj-$(CONFIG_NVMEM_VF610_OCOTP)+= nvmem-vf610-ocotp.o
 nvmem-vf610-ocotp-y:= vf610-ocotp.o
+obj-$(CONFIG_NVMEM_ATMEL_SECUMOD)  += nvmem-atmel-secumod.o
+nvmem-atmel-secumod-y  := atmel-secumod.o
diff --git a/drivers/nvmem/atmel-secumod.c b/drivers/nvmem/atmel-secumod.c
new file mode 100644
index 000..fc5a96b
--- /dev/null
+++ b/drivers/nvmem/atmel-secumod.c
@@ -0,0 +1,143 @@
+/*
+ * Driver for SAMA5D2 secure module (SECUMOD).
+ *
+ * Copyright (C) 2016 eGauge Systems LLC
+ *
+ * David Mosberger <dav...@egauge.net>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int
+secumod_reg_read(void *context, unsigned int reg, void *_val, size_t bytes)
+{
+   void __iomem *base = context;
+   u32 *val = _val;
+   int i = 0, words = bytes / 4;
+
+   while (words--)
+   *val++ = readl(base + reg + (i++ * 4));
+
+   return 0;
+}
+
+static int
+secumod_reg_write(void *context, unsigned int reg, void *_val, size_t bytes)
+{
+   void __iomem *base = context;
+   u32 *val = _val;
+   int i = 0, words = bytes / 4;
+
+   while (words--)
+   writel(*val++, base + reg + (i++ * 4));
+
+   return 0;
+}
+
+static struct nvmem_config econfig = {
+   .name = "secumod",
+   .owner = THIS_MODULE,
+   .stride = 4,
+   .word_size = 1,
+   .reg_read = secumod_reg_read,
+   .reg_write = secumod_reg_write,
+};
+
+/*
+ * Security-module register definitions:
+ */
+#define SECUMOD_RAMRDY 0x0014
+
+/*
+ * Since the secure module may need to automatically erase some of the
+ * RAM, it may take a while for it to be ready.  As far as I know,
+ * it's not documented how long this might take in the worst-case.
+ */
+static void
+secumod_wait_ready (void *regs)
+{
+   unsigned long start, stop;
+

[PATCH] drivers: nvmem: atmel-secumod: New driver for Atmel Secumod nvram

[David Mosberger-Tang]

Signed-off-by: David Mosberger 
---
 .../devicetree/bindings/nvmem/atmel-secumod.txt|  47 +++
 drivers/nvmem/Kconfig  |   7 +
 drivers/nvmem/Makefile |   2 +
 drivers/nvmem/atmel-secumod.c  | 143 +
 4 files changed, 199 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/atmel-secumod.txt
 create mode 100644 drivers/nvmem/atmel-secumod.c

diff --git a/Documentation/devicetree/bindings/nvmem/atmel-secumod.txt 
b/Documentation/devicetree/bindings/nvmem/atmel-secumod.txt
new file mode 100644
index 000..d65cad5
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/atmel-secumod.txt
@@ -0,0 +1,47 @@
+= Atmel Secumod device tree bindings =
+
+This binding is intended to represent Atmel's Secumod which is found
+in SAMA5D2 and perhaps others.
+
+Required properties:
+- compatible: should be "atmel,sama5d2-secumod"
+- reg: Should contain RAM location and length, followed
+   by register location and length of the Secumod controller.
+
+= Data cells =
+Are child nodes of secumod, bindings of which as described in
+bindings/nvmem/nvmem.txt
+
+Example:
+
+secumod@fc04 {
+compatible = "atmel,sama5d2-secumod";
+reg = <0xf8044000 0x1420>, <0xfc04 0x4000>;
+reg-names = "SECURAM", "SECUMOD";
+status = "okay";
+
+#address-cells = <1>;
+#size-cells = <1>;
+ranges;
+
+secram-auto-erasable@0 {
+reg = <0x 0x1000>;
+};
+secram@1000 {
+reg = <0x1000 0x400>;
+};
+ram@1400 {
+reg = <0x1400 0x20>;
+};
+};
+
+= Data consumers =
+Are device nodes which consume nvmem data cells.
+
+For example:
+
+   ram {
+   ...
+   nvmem-cells = <>;
+   nvmem-cell-names = "RAM";
+   };
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 3041d48..88b21e3 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -101,4 +101,11 @@ config NVMEM_VF610_OCOTP
  This driver can also be build as a module. If so, the module will
  be called nvmem-vf610-ocotp.
 
+config NVMEM_ATMEL_SECUMOD
+   tristate "Atmel Secure Module driver"
+   depends on ARCH_AT91
+   help
+ Select this to get support for the secure module (SECUMOD) built
+into the SAMA5D2 chips.
+
 endif
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 45ab1ae..9cbd950 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -22,3 +22,5 @@ obj-$(CONFIG_NVMEM_SUNXI_SID) += nvmem_sunxi_sid.o
 nvmem_sunxi_sid-y  := sunxi_sid.o
 obj-$(CONFIG_NVMEM_VF610_OCOTP)+= nvmem-vf610-ocotp.o
 nvmem-vf610-ocotp-y:= vf610-ocotp.o
+obj-$(CONFIG_NVMEM_ATMEL_SECUMOD)  += nvmem-atmel-secumod.o
+nvmem-atmel-secumod-y  := atmel-secumod.o
diff --git a/drivers/nvmem/atmel-secumod.c b/drivers/nvmem/atmel-secumod.c
new file mode 100644
index 000..fc5a96b
--- /dev/null
+++ b/drivers/nvmem/atmel-secumod.c
@@ -0,0 +1,143 @@
+/*
+ * Driver for SAMA5D2 secure module (SECUMOD).
+ *
+ * Copyright (C) 2016 eGauge Systems LLC
+ *
+ * David Mosberger 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int
+secumod_reg_read(void *context, unsigned int reg, void *_val, size_t bytes)
+{
+   void __iomem *base = context;
+   u32 *val = _val;
+   int i = 0, words = bytes / 4;
+
+   while (words--)
+   *val++ = readl(base + reg + (i++ * 4));
+
+   return 0;
+}
+
+static int
+secumod_reg_write(void *context, unsigned int reg, void *_val, size_t bytes)
+{
+   void __iomem *base = context;
+   u32 *val = _val;
+   int i = 0, words = bytes / 4;
+
+   while (words--)
+   writel(*val++, base + reg + (i++ * 4));
+
+   return 0;
+}
+
+static struct nvmem_config econfig = {
+   .name = "secumod",
+   .owner = THIS_MODULE,
+   .stride = 4,
+   .word_size = 1,
+   .reg_read = secumod_reg_read,
+   .reg_write = secumod_reg_write,
+};
+
+/*
+ * Security-module register definitions:
+ */
+#define SECUMOD_RAMRDY 0x0014
+
+/*
+ * Since the secure module may need to automatically erase some of the
+ * RAM, it may take a while for it to be ready.  As far as I know,
+ * it's not documented how long this might take in the worst-case.
+ */
+static void
+secumod_wait_ready (void *regs)
+{
+   unsigned long start, stop;
+
+   start = jiffies;
+   while 

Re: [PATCH] drivers: nvmem: atmel-secumod: New driver for Atmel Secumod nvram

[David Mosberger]

Thanks for the feedback. Rob!  I'll make the changes and resend the
patch (which has now also been updated to work with linux-next).

Re: [PATCH] drivers: nvmem: atmel-secumod: New driver for Atmel Secumod nvram

[David Mosberger]

Thanks for the feedback. Rob!  I'll make the changes and resend the
patch (which has now also been updated to work with linux-next).

[PATCH] drivers: nvmem: atmel-secumod: New driver for Atmel Secumod nvram

[David Mosberger-Tang]

Signed-off-by: David Mosberger <dav...@egauge.net>
---
 .../devicetree/bindings/nvmem/atmel-secumod.txt|  46 
 drivers/nvmem/atmel-secumod.c  | 125 +
 2 files changed, 171 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/atmel-secumod.txt
 create mode 100644 drivers/nvmem/atmel-secumod.c

diff --git a/Documentation/devicetree/bindings/nvmem/atmel-secumod.txt 
b/Documentation/devicetree/bindings/nvmem/atmel-secumod.txt
new file mode 100644
index 000..85db709
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/atmel-secumod.txt
@@ -0,0 +1,46 @@
+= Atmel Secumod device tree bindings =
+
+This binding is intended to represent Atmel's Secumod which is found
+in SAMA5D2 and perhaps others.
+
+Required properties:
+- compatible: should be "atmel,sama5d2-secumod"
+- reg: Should contain registers location and length of the RAM, followed
+   by register location and length of the Secumod controller.
+
+= Data cells =
+Are child nodes of secumod, bindings of which as described in
+bindings/nvmem/nvmem.txt
+
+Example:
+
+secumod@fc04 {
+compatible = "atmel,sama5d2-secumod";
+reg = <0xf8044000 0x1420
+   0xfc04 0x4000>;
+status = "okay";
+
+#address-cells = <1>;
+#size-cells = <1>;
+
+secram_auto_erasable@ {
+reg = <0x 0x1000>;
+};
+secram@1000 {
+reg = <0x1000 0x400>;
+};
+ram@1400 {
+reg = <0x1400 0x20>;
+};
+};
+
+= Data consumers =
+Are device nodes which consume nvmem data cells.
+
+For example:
+
+   ram {
+   ...
+   nvmem-cells = <>;
+   nvmem-cell-names = "RAM";
+   };
diff --git a/drivers/nvmem/atmel-secumod.c b/drivers/nvmem/atmel-secumod.c
new file mode 100644
index 000..fda83c9
--- /dev/null
+++ b/drivers/nvmem/atmel-secumod.c
@@ -0,0 +1,125 @@
+/*
+ * Driver for SAMA5D2 secure module (SECUMOD).
+ *
+ * Copyright (C) 2016 eGauge Systems LLC
+ *
+ * David Mosberger <dav...@egauge.net>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct regmap_config secumod_regmap_config = {
+   .reg_bits = 32,
+   .val_bits = 32,
+   .reg_stride = 4
+};
+
+static struct nvmem_config econfig = {
+   .name = "secumod",
+   .owner = THIS_MODULE,
+};
+
+/*
+ * Security-module register definitions:
+ */
+#define SECUMOD_RAMRDY 0x0014
+
+/*
+ * Since the secure module may need to automatically erase some of the
+ * RAM, it may take a while for it to be ready.  As far as I know,
+ * it's not documented how long this might take in the worst-case.
+ */
+static void
+secumod_wait_ready (void *regs)
+{
+   unsigned long start, stop;
+
+   start = jiffies;
+   while (!(readl(regs + SECUMOD_RAMRDY) & 1))
+   msleep_interruptible(1);
+   stop = jiffies;
+   if (stop != start)
+   pr_info("nvmem-atmel-secumod: it took %u msec for SECUMOD "
+   "to become ready...\n", jiffies_to_msecs(stop - start));
+   else
+   pr_info("nvmem-atmel-secumod: ready\n");
+}
+
+static int secumod_remove(struct platform_device *pdev)
+{
+   struct nvmem_device *nvmem = platform_get_drvdata(pdev);
+
+   return nvmem_unregister(nvmem);
+}
+
+static int secumod_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct resource *res;
+   struct nvmem_device *nvmem;
+   struct regmap *regmap;
+   void __iomem *base;
+
+   /*
+* Map controller address temporarily so we can ensure that
+* the hardware is ready:
+*/
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+   base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(base))
+   return PTR_ERR(base);
+
+   secumod_wait_ready(base);
+   devm_iounmap(dev, base);
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   base = devm_ioremap_resource(dev, res);
+
+   if (IS_ERR(base))
+   return PTR_ERR(base);
+
+   secumod_regmap_config.max_register = resource_size(res) - 1;
+
+   regmap = devm_regmap_init_mmio(dev, base, _regmap_config);
+   if (IS_ERR(regmap)) {
+   dev_err(dev, "%s: regmap init failed\n", __func__);
+   return PTR_ERR(regmap);
+   }
+   econfig.dev = dev;
+   nvmem = nvmem_register();
+   if (IS_ERR(nvmem))
+   return PTR_ERR(nvmem

[PATCH] drivers: nvmem: atmel-secumod: New driver for Atmel Secumod nvram

[David Mosberger-Tang]

Signed-off-by: David Mosberger 
---
 .../devicetree/bindings/nvmem/atmel-secumod.txt|  46 
 drivers/nvmem/atmel-secumod.c  | 125 +
 2 files changed, 171 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/atmel-secumod.txt
 create mode 100644 drivers/nvmem/atmel-secumod.c

diff --git a/Documentation/devicetree/bindings/nvmem/atmel-secumod.txt 
b/Documentation/devicetree/bindings/nvmem/atmel-secumod.txt
new file mode 100644
index 000..85db709
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/atmel-secumod.txt
@@ -0,0 +1,46 @@
+= Atmel Secumod device tree bindings =
+
+This binding is intended to represent Atmel's Secumod which is found
+in SAMA5D2 and perhaps others.
+
+Required properties:
+- compatible: should be "atmel,sama5d2-secumod"
+- reg: Should contain registers location and length of the RAM, followed
+   by register location and length of the Secumod controller.
+
+= Data cells =
+Are child nodes of secumod, bindings of which as described in
+bindings/nvmem/nvmem.txt
+
+Example:
+
+secumod@fc04 {
+compatible = "atmel,sama5d2-secumod";
+reg = <0xf8044000 0x1420
+   0xfc04 0x4000>;
+status = "okay";
+
+#address-cells = <1>;
+#size-cells = <1>;
+
+secram_auto_erasable@ {
+reg = <0x 0x1000>;
+};
+secram@1000 {
+reg = <0x1000 0x400>;
+};
+ram@1400 {
+reg = <0x1400 0x20>;
+};
+};
+
+= Data consumers =
+Are device nodes which consume nvmem data cells.
+
+For example:
+
+   ram {
+   ...
+   nvmem-cells = <>;
+   nvmem-cell-names = "RAM";
+   };
diff --git a/drivers/nvmem/atmel-secumod.c b/drivers/nvmem/atmel-secumod.c
new file mode 100644
index 000..fda83c9
--- /dev/null
+++ b/drivers/nvmem/atmel-secumod.c
@@ -0,0 +1,125 @@
+/*
+ * Driver for SAMA5D2 secure module (SECUMOD).
+ *
+ * Copyright (C) 2016 eGauge Systems LLC
+ *
+ * David Mosberger 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct regmap_config secumod_regmap_config = {
+   .reg_bits = 32,
+   .val_bits = 32,
+   .reg_stride = 4
+};
+
+static struct nvmem_config econfig = {
+   .name = "secumod",
+   .owner = THIS_MODULE,
+};
+
+/*
+ * Security-module register definitions:
+ */
+#define SECUMOD_RAMRDY 0x0014
+
+/*
+ * Since the secure module may need to automatically erase some of the
+ * RAM, it may take a while for it to be ready.  As far as I know,
+ * it's not documented how long this might take in the worst-case.
+ */
+static void
+secumod_wait_ready (void *regs)
+{
+   unsigned long start, stop;
+
+   start = jiffies;
+   while (!(readl(regs + SECUMOD_RAMRDY) & 1))
+   msleep_interruptible(1);
+   stop = jiffies;
+   if (stop != start)
+   pr_info("nvmem-atmel-secumod: it took %u msec for SECUMOD "
+   "to become ready...\n", jiffies_to_msecs(stop - start));
+   else
+   pr_info("nvmem-atmel-secumod: ready\n");
+}
+
+static int secumod_remove(struct platform_device *pdev)
+{
+   struct nvmem_device *nvmem = platform_get_drvdata(pdev);
+
+   return nvmem_unregister(nvmem);
+}
+
+static int secumod_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct resource *res;
+   struct nvmem_device *nvmem;
+   struct regmap *regmap;
+   void __iomem *base;
+
+   /*
+* Map controller address temporarily so we can ensure that
+* the hardware is ready:
+*/
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+   base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(base))
+   return PTR_ERR(base);
+
+   secumod_wait_ready(base);
+   devm_iounmap(dev, base);
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   base = devm_ioremap_resource(dev, res);
+
+   if (IS_ERR(base))
+   return PTR_ERR(base);
+
+   secumod_regmap_config.max_register = resource_size(res) - 1;
+
+   regmap = devm_regmap_init_mmio(dev, base, _regmap_config);
+   if (IS_ERR(regmap)) {
+   dev_err(dev, "%s: regmap init failed\n", __func__);
+   return PTR_ERR(regmap);
+   }
+   econfig.dev = dev;
+   nvmem = nvmem_register();
+   if (IS_ERR(nvmem))
+   return PTR_ERR(nvmem);
+
+   platform_set_drvdata(pde

Re: [PATCH] usb: host: max3421-hcd: use time_after()

[David Mosberger]

Acked-by: David Mosberger 

On Mon, Dec 15, 2014 at 8:22 AM, Asaf Vertz  wrote:
> To be future-proof and for better readability the time comparisons are
> modified to use time_after() instead of plain, error-prone math.
>
> Signed-off-by: Asaf Vertz 
> ---
>  drivers/usb/host/max3421-hcd.c |3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c
> index 6234c75..aaaff94 100644
> --- a/drivers/usb/host/max3421-hcd.c
> +++ b/drivers/usb/host/max3421-hcd.c
> @@ -55,6 +55,7 @@
>   * single thread (max3421_spi_thread).
>   */
>
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1291,7 +1292,7 @@ max3421_handle_irqs(struct usb_hcd *hcd)
> char sbuf[16 * 16], *dp, *end;
> int i;
>
> -   if (jiffies - last_time > 5*HZ) {
> +   if (time_after(jiffies, last_time + 5*HZ)) {
> dp = sbuf;
> end = sbuf + sizeof(sbuf);
> *dp = '\0';
> --
> 1.7.0.4
>



-- 
eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] usb: host: max3421-hcd: use time_after()

[David Mosberger]

Acked-by: David Mosberger dav...@egauge.net

On Mon, Dec 15, 2014 at 8:22 AM, Asaf Vertz asaf.ve...@tandemg.com wrote:
 To be future-proof and for better readability the time comparisons are
 modified to use time_after() instead of plain, error-prone math.

 Signed-off-by: Asaf Vertz asaf.ve...@tandemg.com
 ---
  drivers/usb/host/max3421-hcd.c |3 ++-
  1 files changed, 2 insertions(+), 1 deletions(-)

 diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c
 index 6234c75..aaaff94 100644
 --- a/drivers/usb/host/max3421-hcd.c
 +++ b/drivers/usb/host/max3421-hcd.c
 @@ -55,6 +55,7 @@
   * single thread (max3421_spi_thread).
   */

 +#include linux/jiffies.h
  #include linux/module.h
  #include linux/spi/spi.h
  #include linux/usb.h
 @@ -1291,7 +1292,7 @@ max3421_handle_irqs(struct usb_hcd *hcd)
 char sbuf[16 * 16], *dp, *end;
 int i;

 -   if (jiffies - last_time  5*HZ) {
 +   if (time_after(jiffies, last_time + 5*HZ)) {
 dp = sbuf;
 end = sbuf + sizeof(sbuf);
 *dp = '\0';
 --
 1.7.0.4




-- 
eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] usb: host: max3421-hcd: unconditionally use GFP_ATOMIC in max3421_urb_enqueue()

[David Mosberger]

On Thu, Jun 19, 2014 at 1:44 PM, Alexey Khoroshilov
 wrote:
> As far as kzalloc() is called with spinlock held,
> we have to pass GFP_ATOMIC regardless of mem_flags argument.

Good catch, thanks!

> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov 

Acked-by: David Mosberger 

> ---
>  drivers/usb/host/max3421-hcd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c
> index 858efcfda50b..ed22424dbec7 100644
> --- a/drivers/usb/host/max3421-hcd.c
> +++ b/drivers/usb/host/max3421-hcd.c
> @@ -1551,7 +1551,7 @@ max3421_urb_enqueue(struct usb_hcd *hcd, struct urb 
> *urb, gfp_t mem_flags)
> max3421_ep = urb->ep->hcpriv;
> if (!max3421_ep) {
> /* gets freed in max3421_endpoint_disable: */
> -   max3421_ep = kzalloc(sizeof(struct max3421_ep), mem_flags);
> +   max3421_ep = kzalloc(sizeof(struct max3421_ep), GFP_ATOMIC);
> if (!max3421_ep) {
> retval = -ENOMEM;
> goto out;
> --
> 1.9.1
>



-- 
eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] usb: host: max3421-hcd: unconditionally use GFP_ATOMIC in max3421_urb_enqueue()

[David Mosberger]

On Thu, Jun 19, 2014 at 1:44 PM, Alexey Khoroshilov
khoroshi...@ispras.ru wrote:
 As far as kzalloc() is called with spinlock held,
 we have to pass GFP_ATOMIC regardless of mem_flags argument.

Good catch, thanks!

 Found by Linux Driver Verification project (linuxtesting.org).

 Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru

Acked-by: David Mosberger dav...@egauge.net

 ---
  drivers/usb/host/max3421-hcd.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c
 index 858efcfda50b..ed22424dbec7 100644
 --- a/drivers/usb/host/max3421-hcd.c
 +++ b/drivers/usb/host/max3421-hcd.c
 @@ -1551,7 +1551,7 @@ max3421_urb_enqueue(struct usb_hcd *hcd, struct urb 
 *urb, gfp_t mem_flags)
 max3421_ep = urb-ep-hcpriv;
 if (!max3421_ep) {
 /* gets freed in max3421_endpoint_disable: */
 -   max3421_ep = kzalloc(sizeof(struct max3421_ep), mem_flags);
 +   max3421_ep = kzalloc(sizeof(struct max3421_ep), GFP_ATOMIC);
 if (!max3421_ep) {
 retval = -ENOMEM;
 goto out;
 --
 1.9.1




-- 
eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: UBIFS recovery taking too long

[David Mosberger-Tang]

Adrian,

On Tue, Dec 10, 2013 at 12:25 AM, Adrian Hunter  wrote:

> Slowness is probably caused by trying to make free space.  Was the file
> system very full?  A smaller journal might help.

That's possible.  We have not been able to reproduce the issue in
house but a customer had it happen on several devices in a row (3 or 4
of them, I believe).  I don't think we are very sensitive to how long
it takes we just need to know an upper bound on the recovery time.

> Probably the only way to determine worst-case recovery time is to test it.
> Worst case conditions are likely to be a full journal and a nearly full file
> system.

I have not found a lot of UBIFS stresstest tools or even tools to
display what state UBIFS is in.  Can you point me to something?  I
assume lots of small writes would fill up the journal?  We'd be very
happy to test this more but as things stands, it's very hard to tell
how full the filesystem even is (due to compression) and I'm not sure
how to check on the state of the journal.

> Ideally you want to capture a file system image that exhibits the slow
> behaviour, then you can enable debug messages and see what it is doing.

OK, the two devices we've seen this initially have been restored so we
can't find out from those.
However, the customer affected by this issue may have another device
or two they haven't sent
back yet.  We might be able to snapshot the root filesystem on one of those.

  --david

>>>
>>> Thanks,
>>>
>>>   --david
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at  http://www.tux.org/lkml/
>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: UBIFS recovery taking too long

[David Mosberger-Tang]

Adrian,

On Tue, Dec 10, 2013 at 12:25 AM, Adrian Hunter adrian.hun...@intel.com wrote:

 Slowness is probably caused by trying to make free space.  Was the file
 system very full?  A smaller journal might help.

That's possible.  We have not been able to reproduce the issue in
house but a customer had it happen on several devices in a row (3 or 4
of them, I believe).  I don't think we are very sensitive to how long
it takes we just need to know an upper bound on the recovery time.

 Probably the only way to determine worst-case recovery time is to test it.
 Worst case conditions are likely to be a full journal and a nearly full file
 system.

I have not found a lot of UBIFS stresstest tools or even tools to
display what state UBIFS is in.  Can you point me to something?  I
assume lots of small writes would fill up the journal?  We'd be very
happy to test this more but as things stands, it's very hard to tell
how full the filesystem even is (due to compression) and I'm not sure
how to check on the state of the journal.

 Ideally you want to capture a file system image that exhibits the slow
 behaviour, then you can enable debug messages and see what it is doing.

OK, the two devices we've seen this initially have been restored so we
can't find out from those.
However, the customer affected by this issue may have another device
or two they haven't sent
back yet.  We might be able to snapshot the root filesystem on one of those.

  --david


 Thanks,

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



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

Fwd: UBIFS recovery taking too long

[David Mosberger-Tang]

I've had no luck getting any response from the linux-mtd mailing list
regarding the issue reported below.
I think it is a very serious issue since it can easily render an
embedded system unusable.

  --david

-- Forwarded message --
From: David Mosberger-Tang 
Date: Thu, Nov 7, 2013 at 11:44 AM
Subject: UBIFS recovery taking too long
To: "linux-...@lists.infradead.org" 


We recently encountered a strange issue where UBIFS recovery is
suddenly taking a lot longer than usual (v3.7-based kernel).  In our
case, recovery took about 30 seconds.  This caused a serious problem
because our watchdog timer was set to 15 seconds, effectively
rendering the devices unbootable.

Does anybody know what triggers this slow recovery mode?  Also, how
can we calculate a worst-case recovery time for a given flash
chip-size.

Thanks,

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

Fwd: UBIFS recovery taking too long

[David Mosberger-Tang]

I've had no luck getting any response from the linux-mtd mailing list
regarding the issue reported below.
I think it is a very serious issue since it can easily render an
embedded system unusable.

  --david

-- Forwarded message --
From: David Mosberger-Tang dmosber...@gmail.com
Date: Thu, Nov 7, 2013 at 11:44 AM
Subject: UBIFS recovery taking too long
To: linux-...@lists.infradead.org linux-...@lists.infradead.org


We recently encountered a strange issue where UBIFS recovery is
suddenly taking a lot longer than usual (v3.7-based kernel).  In our
case, recovery took about 30 seconds.  This caused a serious problem
because our watchdog timer was set to 15 seconds, effectively
rendering the devices unbootable.

Does anybody know what triggers this slow recovery mode?  Also, how
can we calculate a worst-case recovery time for a given flash
chip-size.

Thanks,

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

Re: [patch 04/14] ia64: Remove the __SMALL_ADDR_AREA attribute for per cpu access

[David Mosberger-Tang]

On 11/27/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Tue, 27 Nov 2007, David Mosberger-Tang wrote:
>
> > Uniformity for the sake of uniformity?  The small data addressing is
> > really elegant and I don't think it should be dropped just for the
> > sake of uniformity.
>
> Uniformity for the sake of code size reduction and easier maintenance.

Code-size reduction?  You must be talking *source* code size
reduction.  Surely the small-data access-method decreases object code
size.

  --david
-
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 04/14] ia64: Remove the __SMALL_ADDR_AREA attribute for per cpu access

[David Mosberger-Tang]

On 11/27/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Mon, 26 Nov 2007, David Mosberger-Tang wrote:
>
> > On 11/26/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > > The model(small) attribute is not supported by gcc 4.X. The tests
> > > will always be negative today.
> >
> > What was the rationale for removing this attribute?
>
> The code is then similar across all architectures and can be moved into
> generic code.

Uniformity for the sake of uniformity?  The small data addressing is
really elegant and I don't think it should be dropped just for the
sake of uniformity.

  --david
-
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 04/14] ia64: Remove the __SMALL_ADDR_AREA attribute for per cpu access

[David Mosberger-Tang]

On 11/27/07, Christoph Lameter [EMAIL PROTECTED] wrote:
 On Mon, 26 Nov 2007, David Mosberger-Tang wrote:

  On 11/26/07, Christoph Lameter [EMAIL PROTECTED] wrote:
   The model(small) attribute is not supported by gcc 4.X. The tests
   will always be negative today.
 
  What was the rationale for removing this attribute?

 The code is then similar across all architectures and can be moved into
 generic code.

Uniformity for the sake of uniformity?  The small data addressing is
really elegant and I don't think it should be dropped just for the
sake of uniformity.

  --david
-
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 04/14] ia64: Remove the __SMALL_ADDR_AREA attribute for per cpu access

[David Mosberger-Tang]

On 11/27/07, Christoph Lameter [EMAIL PROTECTED] wrote:
 On Tue, 27 Nov 2007, David Mosberger-Tang wrote:

  Uniformity for the sake of uniformity?  The small data addressing is
  really elegant and I don't think it should be dropped just for the
  sake of uniformity.

 Uniformity for the sake of code size reduction and easier maintenance.

Code-size reduction?  You must be talking *source* code size
reduction.  Surely the small-data access-method decreases object code
size.

  --david
-
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 04/14] ia64: Remove the __SMALL_ADDR_AREA attribute for per cpu access

[David Mosberger-Tang]

On 11/26/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> The model(small) attribute is not supported by gcc 4.X. The tests
> will always be negative today.

What was the rationale for removing this attribute?

  --david
-
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 04/14] ia64: Remove the __SMALL_ADDR_AREA attribute for per cpu access

[David Mosberger-Tang]

On 11/26/07, Christoph Lameter [EMAIL PROTECTED] wrote:
 The model(small) attribute is not supported by gcc 4.X. The tests
 will always be negative today.

What was the rationale for removing this attribute?

  --david
-
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] flush icache before set_pte() on ia64 take9 [2/2] flush icache at set_pte

[David Mosberger-Tang]

On 8/10/07, Luck, Tony <[EMAIL PROTECTED]> wrote:

> +   if (pte_exec(pteval) &&// flush only new executable page.
> +   pte_present(pteval) && // swap out ?
> +   pte_user(pteval) &&// ignore kernel page
> +   (!pte_present(*ptep) ||// do_no_page or swap in, migration,
> +   pte_pfn(*ptep) != pte_pfn(pteval))) // do_wp_page(), page copy
> +   /* load_module() calles flush_icache_range() explicitly*/
> +   __ia64_sync_icache_dcache(pteval);
>

> So now the only remaining task is to convince myself that this
> new version covers all the cases.

What about code-size?

Also, is it OK to call a function from all places where a set_pte() is
being done?  I'd hope so, but it's a really low-level operation...

  --david
-- 
Mosberger Consulting LLC, http://www.mosberger-consulting.com/
-
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] flush icache before set_pte() on ia64 take9 [2/2] flush icache at set_pte

[David Mosberger-Tang]

On 8/10/07, Luck, Tony [EMAIL PROTECTED] wrote:

 +   if (pte_exec(pteval) // flush only new executable page.
 +   pte_present(pteval)  // swap out ?
 +   pte_user(pteval) // ignore kernel page
 +   (!pte_present(*ptep) ||// do_no_page or swap in, migration,
 +   pte_pfn(*ptep) != pte_pfn(pteval))) // do_wp_page(), page copy
 +   /* load_module() calles flush_icache_range() explicitly*/
 +   __ia64_sync_icache_dcache(pteval);


 So now the only remaining task is to convince myself that this
 new version covers all the cases.

What about code-size?

Also, is it OK to call a function from all places where a set_pte() is
being done?  I'd hope so, but it's a really low-level operation...

  --david
-- 
Mosberger Consulting LLC, http://www.mosberger-consulting.com/
-
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] flush icache before set_pte take6. [4/4] optimization for cpus other than montecito

[David Mosberger-Tang]

On 8/1/07, Zoltan Menyhart <[EMAIL PROTECTED]> wrote:

> You do have model specific I cache semantics.
> Not taking it into account will oblige you to flush in vain for the models
> which do not require it. Why do you want to take this option?

Given unlimited resources, your proposal makes perfect sense.  We
could have a Linux version for Merced, one for McKinley, one for
Madison, etc., etc.

(Un)fortunately, resources are limited and with that constraint in
place, rather than spending lots of time optimizing the kernel for
particular idiosyncrasies of a CPU model, it is generally much better
to optimize it for the things the hardware designers promised us would
stay the same across CPU models (i.e., the "architecture").  Sure, it
may mean that on occasion certain things are slightly slower than they
could be but it does have the decided advantage of letting the
maintainers sleep at night... ;-)  Moreover, higher-level
optimizations usually have much higher payoff, so even though you may
do things a bit more slowly at the lowest level, you may end up with a
faster system overall because you were able to spend more time
optimizing at a higher level.

  --david
-
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] flush icache before set_pte take6. [4/4] optimization for cpus other than montecito

[David Mosberger-Tang]

On 8/1/07, Zoltan Menyhart [EMAIL PROTECTED] wrote:

 You do have model specific I cache semantics.
 Not taking it into account will oblige you to flush in vain for the models
 which do not require it. Why do you want to take this option?

Given unlimited resources, your proposal makes perfect sense.  We
could have a Linux version for Merced, one for McKinley, one for
Madison, etc., etc.

(Un)fortunately, resources are limited and with that constraint in
place, rather than spending lots of time optimizing the kernel for
particular idiosyncrasies of a CPU model, it is generally much better
to optimize it for the things the hardware designers promised us would
stay the same across CPU models (i.e., the architecture).  Sure, it
may mean that on occasion certain things are slightly slower than they
could be but it does have the decided advantage of letting the
maintainers sleep at night... ;-)  Moreover, higher-level
optimizations usually have much higher payoff, so even though you may
do things a bit more slowly at the lowest level, you may end up with a
faster system overall because you were able to spend more time
optimizing at a higher level.

  --david
-
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] flush icache before set_pte take6. [4/4] optimization for cpus other than montecito

[David Mosberger-Tang]

This seems crazy to me.  Flushing should occur according to the
*architecture*, not model-by-model.  Even if we happen to get "lucky"
on pre-Montecito CPUs, that doesn't justify such ugly hacks.  Or you
really want to debug this *again* come next CPU?

  --david

On 7/30/07, KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
>
> Add "L2 cache is separated? check flag" as read_mostly global variable.
>
> This add one memory reference to global variable to page faults of 
> "executable"
> map in do_wp_page(page copy case), file-mapped page fault and some system 
> calls
> which does memory map changes. But not so bad as calling sync_icache_dcache in
> architectures which doesn't need it.
>
> Signed-off-by: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
>
>
> ---
>  arch/ia64/kernel/setup.c   |7 +++
>  include/asm-ia64/pgtable.h |3 ++-
>  2 files changed, 9 insertions(+), 1 deletion(-)
>
> Index: linux-2.6.23-rc1.test/arch/ia64/kernel/setup.c
> ===
> --- linux-2.6.23-rc1.test.orig/arch/ia64/kernel/setup.c
> +++ linux-2.6.23-rc1.test/arch/ia64/kernel/setup.c
> @@ -106,6 +106,8 @@ struct io_space io_space[MAX_IO_SPACES];
>  EXPORT_SYMBOL(io_space);
>  unsigned int num_io_spaces;
>
> +int separated_l2_icache_dcache __read_mostly;
> +
>  /*
>   * "flush_icache_range()" needs to know what processor dependent stride size 
> to use
>   * when it makes i-cache(s) coherent with d-caches.
> @@ -718,6 +720,11 @@ get_model_name(__u8 family, __u8 model)
> printk(KERN_ERR
>"%s: Table overflow. Some processor model information 
> will be missing\n",
>__FUNCTION__);
> +   /* Montecito has separated L2 Icache and Dcache. This requires
> +  synchronize Icache and Dcache before set_pte() */
> +   if (family == 0x20)
> +   separated_l2_icache_dcache = 1;
> +
> return "Unknown";
>  }
>
> Index: linux-2.6.23-rc1.test/include/asm-ia64/pgtable.h
> ===
> --- linux-2.6.23-rc1.test.orig/include/asm-ia64/pgtable.h
> +++ linux-2.6.23-rc1.test/include/asm-ia64/pgtable.h
> @@ -489,9 +489,10 @@ extern struct page *zero_page_memmap_ptr
>   * as an executable pte.
>   */
>  extern void __sync_icache_dcache(pte_t pte);
> +extern int separated_l2_icache_dcache;
>  static inline void sync_icache_dcache(pte_t pte)
>  {
> -   if (pte_exec(pte))
> +   if (pte_exec(pte) && separated_l2_icache_dcache)
> __sync_icache_dcache(pte);
>  }
>  #define __HAVE_ARCH_SYNC_ICACHE_DCACHE
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Mosberger Consulting LLC, http://www.mosberger-consulting.com/
-
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] flush icache before set_pte take6. [4/4] optimization for cpus other than montecito

[David Mosberger-Tang]

This seems crazy to me.  Flushing should occur according to the
*architecture*, not model-by-model.  Even if we happen to get lucky
on pre-Montecito CPUs, that doesn't justify such ugly hacks.  Or you
really want to debug this *again* come next CPU?

  --david

On 7/30/07, KAMEZAWA Hiroyuki [EMAIL PROTECTED] wrote:

 Add L2 cache is separated? check flag as read_mostly global variable.

 This add one memory reference to global variable to page faults of 
 executable
 map in do_wp_page(page copy case), file-mapped page fault and some system 
 calls
 which does memory map changes. But not so bad as calling sync_icache_dcache in
 architectures which doesn't need it.

 Signed-off-by: KAMEZAWA Hiroyuki [EMAIL PROTECTED]


 ---
  arch/ia64/kernel/setup.c   |7 +++
  include/asm-ia64/pgtable.h |3 ++-
  2 files changed, 9 insertions(+), 1 deletion(-)

 Index: linux-2.6.23-rc1.test/arch/ia64/kernel/setup.c
 ===
 --- linux-2.6.23-rc1.test.orig/arch/ia64/kernel/setup.c
 +++ linux-2.6.23-rc1.test/arch/ia64/kernel/setup.c
 @@ -106,6 +106,8 @@ struct io_space io_space[MAX_IO_SPACES];
  EXPORT_SYMBOL(io_space);
  unsigned int num_io_spaces;

 +int separated_l2_icache_dcache __read_mostly;
 +
  /*
   * flush_icache_range() needs to know what processor dependent stride size 
 to use
   * when it makes i-cache(s) coherent with d-caches.
 @@ -718,6 +720,11 @@ get_model_name(__u8 family, __u8 model)
 printk(KERN_ERR
%s: Table overflow. Some processor model information 
 will be missing\n,
__FUNCTION__);
 +   /* Montecito has separated L2 Icache and Dcache. This requires
 +  synchronize Icache and Dcache before set_pte() */
 +   if (family == 0x20)
 +   separated_l2_icache_dcache = 1;
 +
 return Unknown;
  }

 Index: linux-2.6.23-rc1.test/include/asm-ia64/pgtable.h
 ===
 --- linux-2.6.23-rc1.test.orig/include/asm-ia64/pgtable.h
 +++ linux-2.6.23-rc1.test/include/asm-ia64/pgtable.h
 @@ -489,9 +489,10 @@ extern struct page *zero_page_memmap_ptr
   * as an executable pte.
   */
  extern void __sync_icache_dcache(pte_t pte);
 +extern int separated_l2_icache_dcache;
  static inline void sync_icache_dcache(pte_t pte)
  {
 -   if (pte_exec(pte))
 +   if (pte_exec(pte)  separated_l2_icache_dcache)
 __sync_icache_dcache(pte);
  }
  #define __HAVE_ARCH_SYNC_ICACHE_DCACHE

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



-- 
Mosberger Consulting LLC, http://www.mosberger-consulting.com/
-
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: [PATCH] ia64: race flushing icache in do_no_page path

[David Mosberger-Tang]

My book has a fairly detailed discussion of how these operations were
supposed to work and what the reasoning behind them was.
Unfortunately, I don't have time to really participate this discussion
at the moment, but I hope somebody else has access to the book and
would (re-)read it for some background (not to claim that it got
everything right 100% but to ensure that earlier mistakes are not
repeated...).

 --david

On 4/27/07, Hugh Dickins <[EMAIL PROTECTED]> wrote:

On Fri, 27 Apr 2007, Nick Piggin wrote:
>
> But that's because of ia64's cache coherency implementation. I don't really
> follow the documentation to know whether it should be one way or the other,
> but surely it should be done either before or after the set_pte_at, not both.
>
> Anyway, how about fremap or mprotect, for example?
> ...
>
> OK, I'm still not sure that I understand why lazy_mmu_prot_update should be
> used rather than flush_icache_page (in concept, not ia64 implementation).
> Sure, flush_icache_page isn't given the pte, but let's assume we can change
> that.

You're asking lots of good questions.  I wish the ia64 people would
know the answers, but from the length of time the "lazy_mmu_prot_update"
stuff took to get into the tree, and the length of time it's taken to be
found defective, I suspect they don't, and we'll have to guess for them.

Some guesses I'm working with...

I presume Mike and Anil are correct, that it needs to be done before
putting pte into page table, not left until after: but as you've
guessed, that needs to be done everywhere, not just in the two
places so far identified.

When it was discussed last year (in connection with Peter's page
cleaning patches) it was thought to be a variant of update_mmu_cache()
(after setting pte), and we added the fremap one to accompany it;
but now it looks to be a variant of flush_icache_page() (before
setting pte).

I believe lazy_mmu_prot_update(pteval) came into existence primarily
for mprotect's change_pte_range() case.  If ia64 filled in its
flush_icache_page(vma, page), that could have been used there
(checking 'vm_flags & VM_EXEC' instead of pte_exec): but that would
involve a relatively expensive(?) pte_page() in a place which doesn't
need to know the struct page for other cases.

Well, not pte_page(), it needs to be vm_normal_page() doesn't it?
and ia64's current lazy_mmu_prot_update is unsafe when !pfn_valid.

Some flush_icache_pages are already in place, others are not: do
we need to add some?  But those architectures which have a non-empty
flush_icache_page seem to have survived without the additional calls
- so they might be unnecessarily slowed down by additional calls.

I believe that was the secondary reason for lazy_mmu_prot_update(),
perhaps better called ia64_flush_icache_page(): to allow calls to
be added where ia64 was (mistakenly) thought to want them, without
needing a protracted audit of how other architectures might be
impacted.

But I'm still trying to make sense of it.

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




--
Mosberger Consulting LLC, http://www.mosberger-consulting.com/
-
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: [PATCH] ia64: race flushing icache in do_no_page path

[David Mosberger-Tang]

My book has a fairly detailed discussion of how these operations were
supposed to work and what the reasoning behind them was.
Unfortunately, I don't have time to really participate this discussion
at the moment, but I hope somebody else has access to the book and
would (re-)read it for some background (not to claim that it got
everything right 100% but to ensure that earlier mistakes are not
repeated...).

 --david

On 4/27/07, Hugh Dickins [EMAIL PROTECTED] wrote:

On Fri, 27 Apr 2007, Nick Piggin wrote:

 But that's because of ia64's cache coherency implementation. I don't really
 follow the documentation to know whether it should be one way or the other,
 but surely it should be done either before or after the set_pte_at, not both.

 Anyway, how about fremap or mprotect, for example?
 ...

 OK, I'm still not sure that I understand why lazy_mmu_prot_update should be
 used rather than flush_icache_page (in concept, not ia64 implementation).
 Sure, flush_icache_page isn't given the pte, but let's assume we can change
 that.

You're asking lots of good questions.  I wish the ia64 people would
know the answers, but from the length of time the lazy_mmu_prot_update
stuff took to get into the tree, and the length of time it's taken to be
found defective, I suspect they don't, and we'll have to guess for them.

Some guesses I'm working with...

I presume Mike and Anil are correct, that it needs to be done before
putting pte into page table, not left until after: but as you've
guessed, that needs to be done everywhere, not just in the two
places so far identified.

When it was discussed last year (in connection with Peter's page
cleaning patches) it was thought to be a variant of update_mmu_cache()
(after setting pte), and we added the fremap one to accompany it;
but now it looks to be a variant of flush_icache_page() (before
setting pte).

I believe lazy_mmu_prot_update(pteval) came into existence primarily
for mprotect's change_pte_range() case.  If ia64 filled in its
flush_icache_page(vma, page), that could have been used there
(checking 'vm_flags  VM_EXEC' instead of pte_exec): but that would
involve a relatively expensive(?) pte_page() in a place which doesn't
need to know the struct page for other cases.

Well, not pte_page(), it needs to be vm_normal_page() doesn't it?
and ia64's current lazy_mmu_prot_update is unsafe when !pfn_valid.

Some flush_icache_pages are already in place, others are not: do
we need to add some?  But those architectures which have a non-empty
flush_icache_page seem to have survived without the additional calls
- so they might be unnecessarily slowed down by additional calls.

I believe that was the secondary reason for lazy_mmu_prot_update(),
perhaps better called ia64_flush_icache_page(): to allow calls to
be added where ia64 was (mistakenly) thought to want them, without
needing a protracted audit of how other architectures might be
impacted.

But I'm still trying to make sense of it.

Hugh
-
To unsubscribe from this list: send the line unsubscribe linux-ia64 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html




--
Mosberger Consulting LLC, http://www.mosberger-consulting.com/
-
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: [BUGFIX][PATCH] fixing placement of register stack under ulimit -s

[David Mosberger-Tang]

But aren't you going to be limited to less than a page worth of
register-backing store even with your patch applied because the
backing store will end up overflowing the memory stack?

 --david

On 3/15/07, KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:

This patch fixes ia64's bug in ulimit -s handling. against 2.6.21-rc3.

At first,the address of register stack is defined by this
== ia64_set_rbs_bot()
unsigned long stack_size = current->signal->rlim[RLIMIT_STACK].rlim_max & -16;

if (stack_size > MAX_USER_STACK_SIZE)
stack_size = MAX_USER_STACK_SIZE;
current->thread.rbs_bot = STACK_TOP - stack_size;
}
==
default rlim[RLIMIT_STACK].rlim_max is very big.

If ulimit -s is used, rlim_max can be small. As a result, rbs_bot can be
very high address. Because of stack-address-randomize, there is a case that
"regiter stack" is placed in the higher address than "memory stack".
== example...
[EMAIL PROTECTED] linux-2.6.21-rc2]$ ulimit -s
8192
[EMAIL PROTECTED] linux-2.6.21-rc2]$ cat /proc/self/maps
-4000 r--p  00:00 0
2000-20038000 r-xp  08:02 5991525
/lib/ld-2.5.so
20044000-2005 rw-p 00034000 08:02 5991525
/lib/ld-2.5.so
20064000-202c8000 r-xp  08:02 5990699
/lib/libc-2.5.so
202c8000-202d4000 ---p 00264000 08:02 5990699
/lib/libc-2.5.so
202d4000-202e rw-p 0026 08:02 5990699
/lib/libc-2.5.so
202e-202ec000 rw-p 202e 00:00 0
202ec000-23a24000 r--p  08:02 9472842
/usr/lib/locale/locale-archive
4000-40008000 r-xp  08:02 4157490
/bin/cat
60004000-6000c000 rw-p 4000 08:02 4157490
/bin/cat
6000c000-6003 rw-p 6000c000 00:00 0  [heap]
6f5f4000-6f648000 rw-p 6f5f4000 00:00 0  [stack]
6f7fc000-6f80 rw-p 6f7fc000 00:00 0  (*)
a000-a002 ---p  00:00 0  [vdso]
(*) is register stack.
==
This register-stack/memory-stack upside down is not expected.
Current ia64 page fault handler doesn't handle this case. In this case,
register stack expansion causes SEGV.
This means that the user program can use only 1 page for its register stack.

This patch fixes the above case by moving register stack to suitable place.
Note) fixing page fault handler seems to be another way...but a bit complicated.

Signed-off-by: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
---
Index: linux-2.6.21-rc3/arch/ia64/mm/init.c
===
--- linux-2.6.21-rc3.orig/arch/ia64/mm/init.c
+++ linux-2.6.21-rc3/arch/ia64/mm/init.c
@@ -155,7 +155,7 @@ ia64_set_rbs_bot (void)

if (stack_size > MAX_USER_STACK_SIZE)
stack_size = MAX_USER_STACK_SIZE;
-   current->thread.rbs_bot = STACK_TOP - stack_size;
+   current->thread.rbs_bot = PAGE_ALIGN(current->mm->start_stack - 
stack_size);
 }

 /*

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




--
Mosberger Consulting LLC, http://www.mosberger-consulting.com/
-
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: [BUGFIX][PATCH] fixing placement of register stack under ulimit -s

[David Mosberger-Tang]

But aren't you going to be limited to less than a page worth of
register-backing store even with your patch applied because the
backing store will end up overflowing the memory stack?

 --david

On 3/15/07, KAMEZAWA Hiroyuki [EMAIL PROTECTED] wrote:

This patch fixes ia64's bug in ulimit -s handling. against 2.6.21-rc3.

At first,the address of register stack is defined by this
== ia64_set_rbs_bot()
unsigned long stack_size = current-signal-rlim[RLIMIT_STACK].rlim_max  -16;

if (stack_size  MAX_USER_STACK_SIZE)
stack_size = MAX_USER_STACK_SIZE;
current-thread.rbs_bot = STACK_TOP - stack_size;
}
==
default rlim[RLIMIT_STACK].rlim_max is very big.

If ulimit -s is used, rlim_max can be small. As a result, rbs_bot can be
very high address. Because of stack-address-randomize, there is a case that
regiter stack is placed in the higher address than memory stack.
== example...
[EMAIL PROTECTED] linux-2.6.21-rc2]$ ulimit -s
8192
[EMAIL PROTECTED] linux-2.6.21-rc2]$ cat /proc/self/maps
-4000 r--p  00:00 0
2000-20038000 r-xp  08:02 5991525
/lib/ld-2.5.so
20044000-2005 rw-p 00034000 08:02 5991525
/lib/ld-2.5.so
20064000-202c8000 r-xp  08:02 5990699
/lib/libc-2.5.so
202c8000-202d4000 ---p 00264000 08:02 5990699
/lib/libc-2.5.so
202d4000-202e rw-p 0026 08:02 5990699
/lib/libc-2.5.so
202e-202ec000 rw-p 202e 00:00 0
202ec000-23a24000 r--p  08:02 9472842
/usr/lib/locale/locale-archive
4000-40008000 r-xp  08:02 4157490
/bin/cat
60004000-6000c000 rw-p 4000 08:02 4157490
/bin/cat
6000c000-6003 rw-p 6000c000 00:00 0  [heap]
6f5f4000-6f648000 rw-p 6f5f4000 00:00 0  [stack]
6f7fc000-6f80 rw-p 6f7fc000 00:00 0  (*)
a000-a002 ---p  00:00 0  [vdso]
(*) is register stack.
==
This register-stack/memory-stack upside down is not expected.
Current ia64 page fault handler doesn't handle this case. In this case,
register stack expansion causes SEGV.
This means that the user program can use only 1 page for its register stack.

This patch fixes the above case by moving register stack to suitable place.
Note) fixing page fault handler seems to be another way...but a bit complicated.

Signed-off-by: KAMEZAWA Hiroyuki [EMAIL PROTECTED]
---
Index: linux-2.6.21-rc3/arch/ia64/mm/init.c
===
--- linux-2.6.21-rc3.orig/arch/ia64/mm/init.c
+++ linux-2.6.21-rc3/arch/ia64/mm/init.c
@@ -155,7 +155,7 @@ ia64_set_rbs_bot (void)

if (stack_size  MAX_USER_STACK_SIZE)
stack_size = MAX_USER_STACK_SIZE;
-   current-thread.rbs_bot = STACK_TOP - stack_size;
+   current-thread.rbs_bot = PAGE_ALIGN(current-mm-start_stack - 
stack_size);
 }

 /*

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




--
Mosberger Consulting LLC, http://www.mosberger-consulting.com/
-
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 2.6.13] IOCHK interface for I/O error handling/detecting (for ia64)

[david mosberger]

On 9/2/05, Grant Grundler <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 01, 2005 at 05:45:54PM -0500, Brent Casavant wrote:
> ...
> > The first is serialization of all I/O reads and writes.  This will
> > be a severe problem on systems with large numbers of PCI buses, the
> > very type of system that stands the most to gain in reliability from
> > these efforts.  At a minimum any locking should be done on a per-bus
> > basis.
> 
> The lock could be per "error domain" - that would require some
> arch specific support though to define the scope of the "error domain".

I do not think the basic inX/outX and readX/writeX operations should
involve spinlocks.  That would be really nasty if an MCA/INIT handler
had to call them, for example...

> > The second is the raw performance penalty from acquiring and dropping
> > a lock with every read and write.  This will be a substantial amount
> > of activity for any I/O-intensive system, heck even for moderate I/O
> > levels.
> 
> Sorry - I think this is BS.
> 
> Please run mmio_test on your box and share the results.
> mmio_test is available here:
> svn co http://svn.gnumonks.org/trunk/mmio_test/

Reads are slow, sure, but writes are not (or should not).

  --david
-- 
Mosberger Consulting LLC, voice/fax: 510-744-9372,
http://www.mosberger-consulting.com/
35706 Runckel Lane, Fremont, CA 94536
-
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 2.6.13] IOCHK interface for I/O error handling/detecting (for ia64)

[david mosberger]

On 9/2/05, Grant Grundler [EMAIL PROTECTED] wrote:
 On Thu, Sep 01, 2005 at 05:45:54PM -0500, Brent Casavant wrote:
 ...
  The first is serialization of all I/O reads and writes.  This will
  be a severe problem on systems with large numbers of PCI buses, the
  very type of system that stands the most to gain in reliability from
  these efforts.  At a minimum any locking should be done on a per-bus
  basis.
 
 The lock could be per error domain - that would require some
 arch specific support though to define the scope of the error domain.

I do not think the basic inX/outX and readX/writeX operations should
involve spinlocks.  That would be really nasty if an MCA/INIT handler
had to call them, for example...

  The second is the raw performance penalty from acquiring and dropping
  a lock with every read and write.  This will be a substantial amount
  of activity for any I/O-intensive system, heck even for moderate I/O
  levels.
 
 Sorry - I think this is BS.
 
 Please run mmio_test on your box and share the results.
 mmio_test is available here:
 svn co http://svn.gnumonks.org/trunk/mmio_test/

Reads are slow, sure, but writes are not (or should not).

  --david
-- 
Mosberger Consulting LLC, voice/fax: 510-744-9372,
http://www.mosberger-consulting.com/
35706 Runckel Lane, Fremont, CA 94536
-
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: Add prefetch switch stack hook in scheduler function

[david mosberger]

Also, should this be called prefetch_stack() or perhaps even just
prefetch_task()?  Not every architecture defines a switch_stack
structure.

  --david

-- 
Mosberger Consulting LLC, voice/fax: 510-744-9372,
http://www.mosberger-consulting.com/
35706 Runckel Lane, Fremont, CA 94536

On 7/27/05, Andrew Morton <[EMAIL PROTECTED]> wrote:
> "Chen, Kenneth W" <[EMAIL PROTECTED]> wrote:
> >
> > +#ifdef ARCH_HAS_PREFETCH_SWITCH_STACK
> >  +extern void prefetch_switch_stack(struct task_struct*);
> >  +#else
> >  +#define prefetch_switch_stack(task) do { } while (0)
> >  +#endif
> 
> It is better to use
> 
> static inline void prefetch_switch_stack(struct task_struct *t) { }
> 
> in the second case, rather than a macro.  It provides typechecking.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" 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: Add prefetch switch stack hook in scheduler function

[david mosberger]

Also, should this be called prefetch_stack() or perhaps even just
prefetch_task()?  Not every architecture defines a switch_stack
structure.

  --david

-- 
Mosberger Consulting LLC, voice/fax: 510-744-9372,
http://www.mosberger-consulting.com/
35706 Runckel Lane, Fremont, CA 94536

On 7/27/05, Andrew Morton [EMAIL PROTECTED] wrote:
 Chen, Kenneth W [EMAIL PROTECTED] wrote:
 
  +#ifdef ARCH_HAS_PREFETCH_SWITCH_STACK
   +extern void prefetch_switch_stack(struct task_struct*);
   +#else
   +#define prefetch_switch_stack(task) do { } while (0)
   +#endif
 
 It is better to use
 
 static inline void prefetch_switch_stack(struct task_struct *t) { }
 
 in the second case, rather than a macro.  It provides typechecking.
 -
 To unsubscribe from this list: send the line unsubscribe linux-ia64 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: [PATCH 2.6.13-rc1 07/10] IOCHK interface for I/O error handling/detecting

[david mosberger]

On 7/5/05, Hidetoshi Seto <[EMAIL PROTECTED]> wrote:

>- could anyone write same barrier for intel compiler?
>  Tony or David, could you help me?

I think it might be best to make ia64_mca_barrier() a proper
subroutine written in assembly code.  Yes, that costs some time, but
we're talking about wasting 1,000+ cycles just to consume the value
read via readX(), so the call-overhead is actually overlapped and
completely trivial.

  --david
-
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 2.6.13-rc1 07/10] IOCHK interface for I/O error handling/detecting

[david mosberger]

On 7/5/05, Hidetoshi Seto [EMAIL PROTECTED] wrote:

- could anyone write same barrier for intel compiler?
  Tony or David, could you help me?

I think it might be best to make ia64_mca_barrier() a proper
subroutine written in assembly code.  Yes, that costs some time, but
we're talking about wasting 1,000+ cycles just to consume the value
read via readX(), so the call-overhead is actually overlapped and
completely trivial.

  --david
-
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: [Gelato-technical] Re: Serious performance degradation on a RAID with kernel 2.6.10-bk7 and later

[David Mosberger]

> On Thu, 21 Apr 2005 10:41:52 -0700, "Luck, Tony" <[EMAIL PROTECTED]> said:

  Tony> Disk space issues?  A complete git repository of the Linux
  Tony> kernel with all changesets back to 2.4.0 takes just over 3G
  Tony> ... which is big compared to BK, but 3G of disk only costs
  Tony> about $1 (for IDE ... if you want 15K rpm SCSI, then you'll
  Tony> pay a lot more).  Network bandwidth is likely to be a bigger
  Tony> problem.

Ever heard that data is a gas?  My disks always fill up in no time at
all, no matter how big they are.  I agree that network bandwidth is an
bigger issue, though.

  Tony> There's a prototype web i/f at http://grmso.net:8090/ that's
  Tony> already looking fairly slick.

Indeed.  Plus it has a cool name, too.  Thanks for the pointer.

--david
-
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: [Gelato-technical] Re: Serious performance degradation on a RAID with kernel 2.6.10-bk7 and later

[David Mosberger]

> On Thu, 21 Apr 2005 10:19:28 -0700, "Luck, Tony" <[EMAIL PROTECTED]> said:

  >> I just checked 2.6.12-rc3 and the fls() fix is indeed missing.
  >> Do you know what happened?

  Tony> If BitKeeper were still in use, I'd have dropped that patch
  Tony> into my "release" tree and asked Linus to "pull" ... but it's
  Tony> not, and I was stalled.  I should have a "git" tree up and
  Tony> running in the next couple of days.  I'll make sure that the
  Tony> fls fix goes in early.

Yeah, I'm facing the same issue.  I started playing with git last
night.  Apart from disk-space usage, it's very nice, though I really
hope someone puts together a web-interface on top of git soon so we
can seek what changed when and by whom.

--david
-
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: [Gelato-technical] Re: Serious performance degradation on a RAID with kernel 2.6.10-bk7 and later

[David Mosberger]

Tony and Andrew,

I just checked 2.6.12-rc3 and the fls() fix is indeed missing.  Do you
know what happened?

--david

> On Thu, 21 Apr 2005 13:30:50 +0200, Andreas Hirstius <[EMAIL PROTECTED]> 
> said:

  Andreas> Hi, The fls() patch from David solves the problem :-))

  Andreas> Do you have an idea, when it will be in the mainline
  Andreas> kernel??

  Andreas> Andreas



  Andreas> Bartlomiej ZOLNIERKIEWICZ wrote:

  >>  Hi!
  >> 
  >>> A small update.
  >>> 
  >>> Patching mm/filemap.c is not necessary in order to get the
  >>> improved performance!  It's sufficient to remove
  >>> roundup_pow_of_two from |get_init_ra_size ...
  >>> 
  >>> So a simple one-liner changes to picture dramatically.  But why
  >>> ?!?!?
  >> 
  >> 
  >> roundup_pow_of_two() uses fls() and ia64 has buggy fls()
  >> implementation [ seems that David fixed it but patch is not in
  >> the mainline yet]:
  >> 
  >> http://www.mail-archive.com/linux-ia64@vger.kernel.org/msg01196.html
  >> 
  >> That would also explain why you couldn't reproduce the problem on
  >> ia32 Xeon machines.
  >> 
  >> Bartlomiej
  >> 

  Andreas> ___
  Andreas> Gelato-technical mailing list
  Andreas> [EMAIL PROTECTED]
  Andreas> https://www.gelato.unsw.edu.au/mailman/listinfo/gelato-technical
-
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: [Gelato-technical] Re: Serious performance degradation on a RAID with kernel 2.6.10-bk7 and later

[David Mosberger]

Tony and Andrew,

I just checked 2.6.12-rc3 and the fls() fix is indeed missing.  Do you
know what happened?

--david

 On Thu, 21 Apr 2005 13:30:50 +0200, Andreas Hirstius [EMAIL PROTECTED] 
 said:

  Andreas Hi, The fls() patch from David solves the problem :-))

  Andreas Do you have an idea, when it will be in the mainline
  Andreas kernel??

  Andreas Andreas



  Andreas Bartlomiej ZOLNIERKIEWICZ wrote:

Hi!
   
   A small update.
   
   Patching mm/filemap.c is not necessary in order to get the
   improved performance!  It's sufficient to remove
   roundup_pow_of_two from |get_init_ra_size ...
   
   So a simple one-liner changes to picture dramatically.  But why
   ?!?!?
   
   
   roundup_pow_of_two() uses fls() and ia64 has buggy fls()
   implementation [ seems that David fixed it but patch is not in
   the mainline yet]:
   
   http://www.mail-archive.com/linux-ia64@vger.kernel.org/msg01196.html
   
   That would also explain why you couldn't reproduce the problem on
   ia32 Xeon machines.
   
   Bartlomiej
   

  Andreas ___
  Andreas Gelato-technical mailing list
  Andreas [EMAIL PROTECTED]
  Andreas https://www.gelato.unsw.edu.au/mailman/listinfo/gelato-technical
-
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: [Gelato-technical] Re: Serious performance degradation on a RAID with kernel 2.6.10-bk7 and later

[David Mosberger]

 On Thu, 21 Apr 2005 10:19:28 -0700, Luck, Tony [EMAIL PROTECTED] said:

   I just checked 2.6.12-rc3 and the fls() fix is indeed missing.
   Do you know what happened?

  Tony If BitKeeper were still in use, I'd have dropped that patch
  Tony into my release tree and asked Linus to pull ... but it's
  Tony not, and I was stalled.  I should have a git tree up and
  Tony running in the next couple of days.  I'll make sure that the
  Tony fls fix goes in early.

Yeah, I'm facing the same issue.  I started playing with git last
night.  Apart from disk-space usage, it's very nice, though I really
hope someone puts together a web-interface on top of git soon so we
can seek what changed when and by whom.

--david
-
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: [Gelato-technical] Re: Serious performance degradation on a RAID with kernel 2.6.10-bk7 and later

[David Mosberger]

 On Thu, 21 Apr 2005 10:41:52 -0700, Luck, Tony [EMAIL PROTECTED] said:

  Tony Disk space issues?  A complete git repository of the Linux
  Tony kernel with all changesets back to 2.4.0 takes just over 3G
  Tony ... which is big compared to BK, but 3G of disk only costs
  Tony about $1 (for IDE ... if you want 15K rpm SCSI, then you'll
  Tony pay a lot more).  Network bandwidth is likely to be a bigger
  Tony problem.

Ever heard that data is a gas?  My disks always fill up in no time at
all, no matter how big they are.  I agree that network bandwidth is an
bigger issue, though.

  Tony There's a prototype web i/f at http://grmso.net:8090/ that's
  Tony already looking fairly slick.

Indeed.  Plus it has a cool name, too.  Thanks for the pointer.

--david
-
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] sched: unlocked context-switches

[David Mosberger]

>>>>> On Tue, 12 Apr 2005 08:42:53 +0200, Ingo Molnar <[EMAIL PROTECTED]> said:

  Ingo> * David Mosberger <[EMAIL PROTECTED]> wrote:

  >> Now, Ingo says that the order is reversed with his patch, i.e.,
  >> switch_mm() happens after switch_to().  That means flush_tlb_mm()
  >> may now see a current->active_mm which hasn't really been
  >> activated yet.  That should be OK since it would just mean that
  >> we'd do an early (and duplicate) activate_context().  While it
  >> does not give me a warm and fuzzy feeling to have this
  >> inconsistent state be observable by interrupt-handlers (and, in
  >> particular, IPI-handlers), I don't see any problem with it off
  >> hand.

  Ingo> thanks for the analysis. I fundamentally dont have any fuzzy
  Ingo> feeling from having _any_ portion of the context-switch path
  Ingo> nonatomic, but with more complex hardware it's just not
  Ingo> possible it seems.

No kidding! ;-)

I _think_ the change is OK.  I'll need testing, of course.
Sure would be nice to have 2.7.xx...

Thanks,

--david
-
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] sched: unlocked context-switches

[David Mosberger]

> On Tue, 12 Apr 2005 12:12:45 +1000, Nick Piggin <[EMAIL PROTECTED]> said:

  >> Now, Ingo says that the order is reversed with his patch, i.e.,
  >> switch_mm() happens after switch_to().  That means flush_tlb_mm()
  >> may now see a current->active_mm which hasn't really been
  >> activated yet.

  Nick> If that did bother you, could you keep track of the actually
  Nick> activated mm in your arch code? Or would that involve more
  Nick> arch hooks and general ugliness in the scheduler?

I'm sorry, but I don't see the point of this.  We are already tracking
care of ownership, just not atomically.  What's the point of putting
another level of (atomic) tracking on top of it.  That seems
exceedingly ugly.

--david
-
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] sched: unlocked context-switches

[David Mosberger]

 On Tue, 12 Apr 2005 12:12:45 +1000, Nick Piggin [EMAIL PROTECTED] said:

   Now, Ingo says that the order is reversed with his patch, i.e.,
   switch_mm() happens after switch_to().  That means flush_tlb_mm()
   may now see a current-active_mm which hasn't really been
   activated yet.

  Nick If that did bother you, could you keep track of the actually
  Nick activated mm in your arch code? Or would that involve more
  Nick arch hooks and general ugliness in the scheduler?

I'm sorry, but I don't see the point of this.  We are already tracking
care of ownership, just not atomically.  What's the point of putting
another level of (atomic) tracking on top of it.  That seems
exceedingly ugly.

--david
-
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] sched: unlocked context-switches

[David Mosberger]

 On Tue, 12 Apr 2005 08:42:53 +0200, Ingo Molnar [EMAIL PROTECTED] said:

  Ingo * David Mosberger [EMAIL PROTECTED] wrote:

   Now, Ingo says that the order is reversed with his patch, i.e.,
   switch_mm() happens after switch_to().  That means flush_tlb_mm()
   may now see a current-active_mm which hasn't really been
   activated yet.  That should be OK since it would just mean that
   we'd do an early (and duplicate) activate_context().  While it
   does not give me a warm and fuzzy feeling to have this
   inconsistent state be observable by interrupt-handlers (and, in
   particular, IPI-handlers), I don't see any problem with it off
   hand.

  Ingo thanks for the analysis. I fundamentally dont have any fuzzy
  Ingo feeling from having _any_ portion of the context-switch path
  Ingo nonatomic, but with more complex hardware it's just not
  Ingo possible it seems.

No kidding! ;-)

I _think_ the change is OK.  I'll need testing, of course.
Sure would be nice to have 2.7.xx...

Thanks,

--david
-
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] sched: unlocked context-switches

[David Mosberger]

> On Sun, 10 Apr 2005 08:43:24 +0200, Ingo Molnar <[EMAIL PROTECTED]> said:

  Ingo> * David S. Miller <[EMAIL PROTECTED]> wrote:

  >> > Yes, of course.  The deadlock was due to context-switching, not
  >> > switch_mm() per se.  Hopefully someone else beats me to
  >> remembering > the details before Monday.

  >> Sparc64 has a deadlock because we hold mm->page_table_lock during
  >> switch_mm().  I bet IA64 did something similar, as I remember it
  >> had a very similar locking issue in this area.

  >> So the deadlock was, we held the runqueue locks over switch_mm(),
  >> switch_mm() spins on mm->page_table_lock, the cpu which does have
  >> mm-> page_table_lock tries to do a wakeup on the first cpu's
  >> mm-> runqueue.
  >> Classic AB-BA deadlock.

  Ingo> yeah, i can see that happening - holding the runqueue lock and
  Ingo> enabling interrupts. (it's basically never safe to enable irqs
  Ingo> with the runqueue lock held.)

  Ingo> the patch drops both the runqueue lock and enables interrupts,
  Ingo> so this particular issue should not trigger.

I had to refresh my memory with a quick Google search that netted [1]
(look for "Disable interrupts during context switch").  Actually, it
wasn't really a deadlock, but rather a livelock, since a CPU got stuck
on an infinite page-not-present loop.

Fundamentally, the issue was that doing the switch_mm() and
switch_to() with interrupts enabled opened a window during which you
could get a call to flush_tlb_mm() (as a result of an IPI).  This, in
turn, could end up activating the wrong MMU-context, since the action
of flush_tlb_mm() depends on the value of current->active_mm.  The
problematic sequence was:

1) schedule() calls switch_mm() which calls activate_context() to
   switch to the new address-space
2) IPI comes in and flush_tlb_mm(mm) gets called
3) "current" still points to old task and if "current->active_mm == mm",
   activate_mm() is called for the old address-space, resetting the
   address-space back to that of the old task

Now, Ingo says that the order is reversed with his patch, i.e.,
switch_mm() happens after switch_to().  That means flush_tlb_mm() may
now see a current->active_mm which hasn't really been activated yet.
That should be OK since it would just mean that we'd do an early (and
duplicate) activate_context().  While it does not give me a warm and
fuzzy feeling to have this inconsistent state be observable by
interrupt-handlers (and, in particular, IPI-handlers), I don't see any
problem with it off hand.

--david

[1] http://www.gelato.unsw.edu.au/linux-ia64/0307/6109.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: [patch] sched: unlocked context-switches

[David Mosberger]

 On Sun, 10 Apr 2005 08:43:24 +0200, Ingo Molnar [EMAIL PROTECTED] said:

  Ingo * David S. Miller [EMAIL PROTECTED] wrote:

Yes, of course.  The deadlock was due to context-switching, not
switch_mm() per se.  Hopefully someone else beats me to
   remembering  the details before Monday.

   Sparc64 has a deadlock because we hold mm-page_table_lock during
   switch_mm().  I bet IA64 did something similar, as I remember it
   had a very similar locking issue in this area.

   So the deadlock was, we held the runqueue locks over switch_mm(),
   switch_mm() spins on mm-page_table_lock, the cpu which does have
   mm- page_table_lock tries to do a wakeup on the first cpu's
   mm- runqueue.
   Classic AB-BA deadlock.

  Ingo yeah, i can see that happening - holding the runqueue lock and
  Ingo enabling interrupts. (it's basically never safe to enable irqs
  Ingo with the runqueue lock held.)

  Ingo the patch drops both the runqueue lock and enables interrupts,
  Ingo so this particular issue should not trigger.

I had to refresh my memory with a quick Google search that netted [1]
(look for Disable interrupts during context switch).  Actually, it
wasn't really a deadlock, but rather a livelock, since a CPU got stuck
on an infinite page-not-present loop.

Fundamentally, the issue was that doing the switch_mm() and
switch_to() with interrupts enabled opened a window during which you
could get a call to flush_tlb_mm() (as a result of an IPI).  This, in
turn, could end up activating the wrong MMU-context, since the action
of flush_tlb_mm() depends on the value of current-active_mm.  The
problematic sequence was:

1) schedule() calls switch_mm() which calls activate_context() to
   switch to the new address-space
2) IPI comes in and flush_tlb_mm(mm) gets called
3) current still points to old task and if current-active_mm == mm,
   activate_mm() is called for the old address-space, resetting the
   address-space back to that of the old task

Now, Ingo says that the order is reversed with his patch, i.e.,
switch_mm() happens after switch_to().  That means flush_tlb_mm() may
now see a current-active_mm which hasn't really been activated yet.
That should be OK since it would just mean that we'd do an early (and
duplicate) activate_context().  While it does not give me a warm and
fuzzy feeling to have this inconsistent state be observable by
interrupt-handlers (and, in particular, IPI-handlers), I don't see any
problem with it off hand.

--david

[1] http://www.gelato.unsw.edu.au/linux-ia64/0307/6109.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: [patch] sched: unlocked context-switches

[David Mosberger]

>>>>> On Sat, 9 Apr 2005 09:07:38 +0200, Ingo Molnar <[EMAIL PROTECTED]> said:

  Ingo> * David Mosberger-Tang <[EMAIL PROTECTED]> wrote:

  >> > The ia64_switch_to() code includes a section that can change a
  >> > pinned MMU mapping (when the stack for the new process is in a
  >> > different granule from the stack for the old process).  The code
  >> > beyond the ".map" label in arch/ia64/kernel/entry.S includes the
  >> > comment:

  >> Also, there was a nasty dead-lock that could trigger if the
  >> context-switch was interrupted by a TLB flush IPI.  I don't
  >> remember the details offhand, but I'm pretty sure it had to do
  >> with switch_mm(), so I suspect it may not be enough to disable
  >> irqs just for ia64_switch_to().  Tread with care!

  Ingo> we'll see. The patch certainly needs more testing. Generally
  Ingo> we do switch_mm()'s outside of the scheduler as well, without
  Ingo> disabling interrupts.

Yes, of course.  The deadlock was due to context-switching, not
switch_mm() per se.  Hopefully someone else beats me to remembering
the details before Monday.

--david
-
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] sched: unlocked context-switches

[David Mosberger-Tang]

 > Tony:

 >> Ingo:

 >> tested on x86, and all other arches should work as well, but if an
 >> architecture has irqs-off assumptions in its switch_to() logic it
 >> might break. (I havent found any but there may such assumptions.)

 > The ia64_switch_to() code includes a section that can change a
 > pinned MMU mapping (when the stack for the new process is in a
 > different granule from the stack for the old process).  The code
 > beyond the ".map" label in arch/ia64/kernel/entry.S includes the
 > comment:

Also, there was a nasty dead-lock that could trigger if the
context-switch was interrupted by a TLB flush IPI.  I don't remember
the details offhand, but I'm pretty sure it had to do with
switch_mm(), so I suspect it may not be enough to disable irqs just
for ia64_switch_to().  Tread with care!

--david
-
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] sched: unlocked context-switches

[David Mosberger-Tang]

  Tony:

  Ingo:

  tested on x86, and all other arches should work as well, but if an
  architecture has irqs-off assumptions in its switch_to() logic it
  might break. (I havent found any but there may such assumptions.)

  The ia64_switch_to() code includes a section that can change a
  pinned MMU mapping (when the stack for the new process is in a
  different granule from the stack for the old process).  The code
  beyond the .map label in arch/ia64/kernel/entry.S includes the
  comment:

Also, there was a nasty dead-lock that could trigger if the
context-switch was interrupted by a TLB flush IPI.  I don't remember
the details offhand, but I'm pretty sure it had to do with
switch_mm(), so I suspect it may not be enough to disable irqs just
for ia64_switch_to().  Tread with care!

--david
-
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] sched: unlocked context-switches

[David Mosberger]

 On Sat, 9 Apr 2005 09:07:38 +0200, Ingo Molnar [EMAIL PROTECTED] said:

  Ingo * David Mosberger-Tang [EMAIL PROTECTED] wrote:

The ia64_switch_to() code includes a section that can change a
pinned MMU mapping (when the stack for the new process is in a
different granule from the stack for the old process).  The code
beyond the .map label in arch/ia64/kernel/entry.S includes the
comment:

   Also, there was a nasty dead-lock that could trigger if the
   context-switch was interrupted by a TLB flush IPI.  I don't
   remember the details offhand, but I'm pretty sure it had to do
   with switch_mm(), so I suspect it may not be enough to disable
   irqs just for ia64_switch_to().  Tread with care!

  Ingo we'll see. The patch certainly needs more testing. Generally
  Ingo we do switch_mm()'s outside of the scheduler as well, without
  Ingo disabling interrupts.

Yes, of course.  The deadlock was due to context-switching, not
switch_mm() per se.  Hopefully someone else beats me to remembering
the details before Monday.

--david
-
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] add a clear_pages function to clear pages of higher order

[David Mosberger]

> On Tue, 5 Apr 2005 17:33:59 -0700 (PDT), Christoph Lameter <[EMAIL 
> PROTECTED]> said:

  Christoph> Which benchmark would you recommend for this?

I don't know about "recommend", but I think SPECweb, SPECjbb,
the-UNIX-multi-user-benchmark-whose-name-I-keep-forgetting, and in
general anything that involves process-activity and/or large working
sets might be interesting (in other words: anything but
microbenchmarks; I'm afraid).

--david
-
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] add a clear_pages function to clear pages of higher order

[David Mosberger]

>>>>> On Tue, 5 Apr 2005 17:15:53 -0700 (PDT), Christoph Lameter <[EMAIL 
>>>>> PROTECTED]> said:

  Christoph> On Thu, 24 Mar 2005, David Mosberger wrote:
  >> That's definitely the case.  See my earlier post on this topic:

  >> http://www.gelato.unsw.edu.au/linux-ia64/0409/11012.html

  >> Unfortunately, nobody reported any results for larger machines
  >> and/or more interesting workloads, so the patch is in limbo at
  >> this time.  Clearly, if the CPU that's clearing the page is
  >> likely to use that same page soon after, it'd be useful to use
  >> temporal stores.

  Christoph> Here are some numbers using lmbench of temporal writes
  Christoph> vs. non temporal writes on ia64 (8p machine but lmbench
  Christoph> run only for one load). There seems to be some benefit
  Christoph> for fork/exec but overall this does not seem to be a
  Christoph> clear win. I suspect that the distinction between
  Christoph> temporal vs. nontemporal writes is be more beneficial on
  Christoph> machines with smaller pagesizes since the likelyhood that
  Christoph> most cachelines of a page are used soon is increased and
  Christoph> therefore hot zeroing is more beneficial.

What LMbench test other than fork/exec would you have expected to be
affected by this?  LMbench is not a good benchmark for this (remember:
it's a _micro_ benchmark).

--david
-
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: [03/08] fix ia64 syscall auditing

[David Mosberger]

> On Tue, 5 Apr 2005 09:46:48 -0700, Greg KH <[EMAIL PROTECTED]> said:

  Greg> -stable review patch.  If anyone has any objections, please
  Greg> let us know.

Nitpick: the patch introduces trailing whitespace.

Why doesn't everybody use emacs and enable show-trailing-whitespace? ;-)

--david
-
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: [03/08] fix ia64 syscall auditing

[David Mosberger]

 On Tue, 5 Apr 2005 09:46:48 -0700, Greg KH [EMAIL PROTECTED] said:

  Greg -stable review patch.  If anyone has any objections, please
  Greg let us know.

Nitpick: the patch introduces trailing whitespace.

Why doesn't everybody use emacs and enable show-trailing-whitespace? ;-)

--david
-
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] add a clear_pages function to clear pages of higher order

[David Mosberger]

 On Tue, 5 Apr 2005 17:15:53 -0700 (PDT), Christoph Lameter [EMAIL 
 PROTECTED] said:

  Christoph On Thu, 24 Mar 2005, David Mosberger wrote:
   That's definitely the case.  See my earlier post on this topic:

   http://www.gelato.unsw.edu.au/linux-ia64/0409/11012.html

   Unfortunately, nobody reported any results for larger machines
   and/or more interesting workloads, so the patch is in limbo at
   this time.  Clearly, if the CPU that's clearing the page is
   likely to use that same page soon after, it'd be useful to use
   temporal stores.

  Christoph Here are some numbers using lmbench of temporal writes
  Christoph vs. non temporal writes on ia64 (8p machine but lmbench
  Christoph run only for one load). There seems to be some benefit
  Christoph for fork/exec but overall this does not seem to be a
  Christoph clear win. I suspect that the distinction between
  Christoph temporal vs. nontemporal writes is be more beneficial on
  Christoph machines with smaller pagesizes since the likelyhood that
  Christoph most cachelines of a page are used soon is increased and
  Christoph therefore hot zeroing is more beneficial.

What LMbench test other than fork/exec would you have expected to be
affected by this?  LMbench is not a good benchmark for this (remember:
it's a _micro_ benchmark).

--david
-
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] add a clear_pages function to clear pages of higher order

[David Mosberger]

 On Tue, 5 Apr 2005 17:33:59 -0700 (PDT), Christoph Lameter [EMAIL 
 PROTECTED] said:

  Christoph Which benchmark would you recommend for this?

I don't know about recommend, but I think SPECweb, SPECjbb,
the-UNIX-multi-user-benchmark-whose-name-I-keep-forgetting, and in
general anything that involves process-activity and/or large working
sets might be interesting (in other words: anything but
microbenchmarks; I'm afraid).

--david
-
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/

fix AGP code to work again with non-PCI AGP bridges

[David Mosberger]

Dave,

As mentioned earlier, the current check_bridge_mode() code assumes
that AGP bridges are PCI devices.  This isn't always true.  Definitely
not for HP zx1 chipset and the same seems to be the case for SGI's AGP
bridge.

The patch below fixes the problem by picking up the AGP_MODE_3_0 bit
from bridge->mode.  I feel like I may be missing something, since I
can't see any reason why check_bridge_mode() wasn't doing that in the
first place.  According to the AGP 3.0 specs, the AGP_MODE_3_0 bit is
determined during the hardware reset and cannot be changed, so it
seems to me it should be safe to pick it up from bridge->mode.

With the patch applied, I can definitely use AGP acceleration both
with AGP 2.0 and AGP 3.0 (one with an Nvidia card, the other with an
ATI FireGL card).

Unless someone spots a problem, please apply this patch so 3d
acceleration can work on zx1 boxes again.

Thanks,

--david

[AGPGART] Replace check_bridge_mode() with (bridge->mode & AGSTAT_MODE_3_0).

This makes AGP work again on machines with an AGP bridge that isn't a
PCI device.

Signed-off-by: David Mosberger-Tang <[EMAIL PROTECTED]>

= drivers/char/agp/generic.c 1.87 vs edited =
--- 1.87/drivers/char/agp/generic.c 2005-03-28 14:21:41 -08:00
+++ edited/drivers/char/agp/generic.c   2005-04-04 13:16:43 -07:00
@@ -295,19 +295,6 @@
 EXPORT_SYMBOL_GPL(agp_num_entries);
 
 
-static int check_bridge_mode(struct pci_dev *dev)
-{
-   u32 agp3;
-   u8 cap_ptr;
-
-   cap_ptr = pci_find_capability(dev, PCI_CAP_ID_AGP);
-   pci_read_config_dword(dev, cap_ptr+AGPSTAT, );
-   if (agp3 & AGPSTAT_MODE_3_0)
-   return 1;
-   return 0;
-}
-
-
 /**
  * agp_copy_info  -  copy bridge state information
  *
@@ -328,7 +315,7 @@
info->version.minor = bridge->version->minor;
info->chipset = SUPPORTED;
info->device = bridge->dev;
-   if (check_bridge_mode(bridge->dev))
+   if (bridge->mode & AGPSTAT_MODE_3_0)
info->mode = bridge->mode & ~AGP3_RESERVED_MASK;
else
info->mode = bridge->mode & ~AGP2_RESERVED_MASK;
@@ -661,7 +648,7 @@
bridge_agpstat &= ~AGPSTAT_FW;
 
/* Check to see if we are operating in 3.0 mode */
-   if (check_bridge_mode(agp_bridge->dev))
+   if (agp_bridge->mode & AGPSTAT_MODE_3_0)
agp_v3_parse_one(_mode, _agpstat, 
_agpstat);
else
agp_v2_parse_one(_mode, _agpstat, 
_agpstat);
@@ -732,7 +719,7 @@
 
/* Do AGP version specific frobbing. */
if (bridge->major_version >= 3) {
-   if (check_bridge_mode(bridge->dev)) {
+   if (bridge->mode & AGPSTAT_MODE_3_0) {
/* If we have 3.5, we can do the isoch stuff. */
if (bridge->minor_version >= 5)
agp_3_5_enable(bridge);
-
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/

fix AGP code to work again with non-PCI AGP bridges

[David Mosberger]

Dave,

As mentioned earlier, the current check_bridge_mode() code assumes
that AGP bridges are PCI devices.  This isn't always true.  Definitely
not for HP zx1 chipset and the same seems to be the case for SGI's AGP
bridge.

The patch below fixes the problem by picking up the AGP_MODE_3_0 bit
from bridge-mode.  I feel like I may be missing something, since I
can't see any reason why check_bridge_mode() wasn't doing that in the
first place.  According to the AGP 3.0 specs, the AGP_MODE_3_0 bit is
determined during the hardware reset and cannot be changed, so it
seems to me it should be safe to pick it up from bridge-mode.

With the patch applied, I can definitely use AGP acceleration both
with AGP 2.0 and AGP 3.0 (one with an Nvidia card, the other with an
ATI FireGL card).

Unless someone spots a problem, please apply this patch so 3d
acceleration can work on zx1 boxes again.

Thanks,

--david

[AGPGART] Replace check_bridge_mode() with (bridge-mode  AGSTAT_MODE_3_0).

This makes AGP work again on machines with an AGP bridge that isn't a
PCI device.

Signed-off-by: David Mosberger-Tang [EMAIL PROTECTED]

= drivers/char/agp/generic.c 1.87 vs edited =
--- 1.87/drivers/char/agp/generic.c 2005-03-28 14:21:41 -08:00
+++ edited/drivers/char/agp/generic.c   2005-04-04 13:16:43 -07:00
@@ -295,19 +295,6 @@
 EXPORT_SYMBOL_GPL(agp_num_entries);
 
 
-static int check_bridge_mode(struct pci_dev *dev)
-{
-   u32 agp3;
-   u8 cap_ptr;
-
-   cap_ptr = pci_find_capability(dev, PCI_CAP_ID_AGP);
-   pci_read_config_dword(dev, cap_ptr+AGPSTAT, agp3);
-   if (agp3  AGPSTAT_MODE_3_0)
-   return 1;
-   return 0;
-}
-
-
 /**
  * agp_copy_info  -  copy bridge state information
  *
@@ -328,7 +315,7 @@
info-version.minor = bridge-version-minor;
info-chipset = SUPPORTED;
info-device = bridge-dev;
-   if (check_bridge_mode(bridge-dev))
+   if (bridge-mode  AGPSTAT_MODE_3_0)
info-mode = bridge-mode  ~AGP3_RESERVED_MASK;
else
info-mode = bridge-mode  ~AGP2_RESERVED_MASK;
@@ -661,7 +648,7 @@
bridge_agpstat = ~AGPSTAT_FW;
 
/* Check to see if we are operating in 3.0 mode */
-   if (check_bridge_mode(agp_bridge-dev))
+   if (agp_bridge-mode  AGPSTAT_MODE_3_0)
agp_v3_parse_one(requested_mode, bridge_agpstat, 
vga_agpstat);
else
agp_v2_parse_one(requested_mode, bridge_agpstat, 
vga_agpstat);
@@ -732,7 +719,7 @@
 
/* Do AGP version specific frobbing. */
if (bridge-major_version = 3) {
-   if (check_bridge_mode(bridge-dev)) {
+   if (bridge-mode  AGPSTAT_MODE_3_0) {
/* If we have 3.5, we can do the isoch stuff. */
if (bridge-minor_version = 5)
agp_3_5_enable(bridge);
-
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] add a clear_pages function to clear pages of higher order

[David Mosberger]

> On Fri, 18 Mar 2005 20:28:08 +0100, Andi Kleen <[EMAIL PROTECTED]> said:

  >> stores in general for clearing pages? I checked and Itanium has
  >> always used non-temporal stores. So there will be no benefit for
  >> us from this

  Andi> That is weird. I would actually try to switch to temporal
  Andi> stores, maybe it will improve some benchmarks.

That's definitely the case.  See my earlier post on this topic:

  http://www.gelato.unsw.edu.au/linux-ia64/0409/11012.html

Unfortunately, nobody reported any results for larger machines and/or
more interesting workloads, so the patch is in limbo at this time.
Clearly, if the CPU that's clearing the page is likely to use that
same page soon after, it'd be useful to use temporal stores.

--david
-
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] add a clear_pages function to clear pages of higher order

[David Mosberger]

 On Fri, 18 Mar 2005 20:28:08 +0100, Andi Kleen [EMAIL PROTECTED] said:

   stores in general for clearing pages? I checked and Itanium has
   always used non-temporal stores. So there will be no benefit for
   us from this

  Andi That is weird. I would actually try to switch to temporal
  Andi stores, maybe it will improve some benchmarks.

That's definitely the case.  See my earlier post on this topic:

  http://www.gelato.unsw.edu.au/linux-ia64/0409/11012.html

Unfortunately, nobody reported any results for larger machines and/or
more interesting workloads, so the patch is in limbo at this time.
Clearly, if the CPU that's clearing the page is likely to use that
same page soon after, it'd be useful to use temporal stores.

--david
-
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] arch hook for notifying changes in PTE protections bits

[David Mosberger]

> On Sat, 19 Mar 2005 12:22:20 -0800, "Seth, Rohit" <[EMAIL PROTECTED]> 
> said:

  Rohit> David S. Miller  wrote on Friday,
  Rohit> March 18, 2005 8:06 PM:

  >>  Take a look at set_pte_at().  You get the "mm", the virtual
  >> address, the pte pointer, and the new pte value.


  Rohit> Thanks for pointing out the updated interface in 2.6.12-*
  Rohit> kernel.  I think I can overload the arch specific part of
  Rohit> set_pte_at(or for that matter set_pte, as what I need is only
  Rohit> pte_t) to always check if we need to do lazy I/D coherency
  Rohit> for IA-64.but this incurs extra cost for making a check
  Rohit> every time set_pte_at is called.  This new hook,
  Rohit> lazy_mmu_prot_update, though needs to be used only when the
  Rohit> permissions on a valid PTE is changing. For example, at the
  Rohit> time of remap or swap, this API is not called.

Careful though: not every PTE has an associated page_map entry.

I agree about your concern about cost.  Accessing the page_map is
expensive (integer division + memory access) and we have to do that in
order to find out if the page is i-cache clean.

--david
-
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] arch hook for notifying changes in PTE protections bits

[David Mosberger]

 On Sat, 19 Mar 2005 12:22:20 -0800, Seth, Rohit [EMAIL PROTECTED] 
 said:

  Rohit David S. Miller mailto:[EMAIL PROTECTED] wrote on Friday,
  Rohit March 18, 2005 8:06 PM:

Take a look at set_pte_at().  You get the mm, the virtual
   address, the pte pointer, and the new pte value.


  Rohit Thanks for pointing out the updated interface in 2.6.12-*
  Rohit kernel.  I think I can overload the arch specific part of
  Rohit set_pte_at(or for that matter set_pte, as what I need is only
  Rohit pte_t) to always check if we need to do lazy I/D coherency
  Rohit for IA-64.but this incurs extra cost for making a check
  Rohit every time set_pte_at is called.  This new hook,
  Rohit lazy_mmu_prot_update, though needs to be used only when the
  Rohit permissions on a valid PTE is changing. For example, at the
  Rohit time of remap or swap, this API is not called.

Careful though: not every PTE has an associated page_map entry.

I agree about your concern about cost.  Accessing the page_map is
expensive (integer division + memory access) and we have to do that in
order to find out if the page is i-cache clean.

--david
-
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: Mprotect needs arch hook for updated PTE settings

[David Mosberger]

> On Wed, 16 Mar 2005 13:58:04 +0100, Zoltan Menyhart <[EMAIL PROTECTED]> 
> said:

  Zoltan> An application should not change the protection of its _own_
  Zoltan> text region without knowing well the requirements of the
  Zoltan> given architecture.

And the rationale being?

  Zoltan> I did see /lib/ld-linux-ia64.so.* changing the protection of
  Zoltan> the text segment of the _victim_ application, when it linked
  Zoltan> the library references.  ld-linux-ia64.so.* changes the
  Zoltan> protection for the whole text segment (otherwise, as the
  Zoltan> protection is per VMA, it would result in a VMA
  Zoltan> fragmentation).  The text segment can be huge. There is no
  Zoltan> reason to flush all the text segment every time when
  Zoltan> ld-linux-ia64.so.* patches an instruction and changes the
  Zoltan> protection.

You're missing the point:

 - ld.so does NOT patch any instructions; it only patches constant
   data which normally is write-protected

 - if the text segment is brought into memory via DMA (which it
   usually is), the only pages that need to be flushed from the cache
   are the ones that were being written to by ld.so; that's usually a
   tiny portion of the text segment

  Zoltan> I think the solution should consist of these two measures:

  Zoltan> 1. Let's say that if an VMA is "executable", then it remains
  Zoltan> "executable" for ever, i.e. the mprotect() keeps the
  Zoltan> PROT_EXEC bit.  As a result, if a page is faulted in for
  Zoltan> this VMA in the mean time, the old good mechanism makes sure
  Zoltan> that the I-caches are flushed.

  Zoltan> 2. Let's modify ld-linux-.so.*: having patched an
  Zoltan> instruction, it should take the appropriate, architecture
  Zoltan> dependent measure, e.g. for ia64, it should issue an "fc"
  Zoltan> instruction.

Again, ld.so never patches any instructions.

  Zoltan> (Who cares for a debugger ? It should know what it does ;-).)

  Zoltan> I think there is no need for any extra flushes.

There won't be any "extra" flushing, just the flushing that is really
needed (i.e., for pages that were dirtied via CPU stores).

--david
-
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: Mprotect needs arch hook for updated PTE settings

[David Mosberger]

 On Wed, 16 Mar 2005 13:58:04 +0100, Zoltan Menyhart [EMAIL PROTECTED] 
 said:

  Zoltan An application should not change the protection of its _own_
  Zoltan text region without knowing well the requirements of the
  Zoltan given architecture.

And the rationale being?

  Zoltan I did see /lib/ld-linux-ia64.so.* changing the protection of
  Zoltan the text segment of the _victim_ application, when it linked
  Zoltan the library references.  ld-linux-ia64.so.* changes the
  Zoltan protection for the whole text segment (otherwise, as the
  Zoltan protection is per VMA, it would result in a VMA
  Zoltan fragmentation).  The text segment can be huge. There is no
  Zoltan reason to flush all the text segment every time when
  Zoltan ld-linux-ia64.so.* patches an instruction and changes the
  Zoltan protection.

You're missing the point:

 - ld.so does NOT patch any instructions; it only patches constant
   data which normally is write-protected

 - if the text segment is brought into memory via DMA (which it
   usually is), the only pages that need to be flushed from the cache
   are the ones that were being written to by ld.so; that's usually a
   tiny portion of the text segment

  Zoltan I think the solution should consist of these two measures:

  Zoltan 1. Let's say that if an VMA is executable, then it remains
  Zoltan executable for ever, i.e. the mprotect() keeps the
  Zoltan PROT_EXEC bit.  As a result, if a page is faulted in for
  Zoltan this VMA in the mean time, the old good mechanism makes sure
  Zoltan that the I-caches are flushed.

  Zoltan 2. Let's modify ld-linux-arch.so.*: having patched an
  Zoltan instruction, it should take the appropriate, architecture
  Zoltan dependent measure, e.g. for ia64, it should issue an fc
  Zoltan instruction.

Again, ld.so never patches any instructions.

  Zoltan (Who cares for a debugger ? It should know what it does ;-).)

  Zoltan I think there is no need for any extra flushes.

There won't be any extra flushing, just the flushing that is really
needed (i.e., for pages that were dirtied via CPU stores).

--david
-
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 - 2.6.11-rc5-mm1] genalloc - general purpose allocator

[David Mosberger]

> On 03 Mar 2005 03:21:56 -0500, Jes Sorensen <[EMAIL PROTECTED]> said:

  Jes> mempool on the other hand will first try and call the user
  Jes> provided allocation function and only if that fails try and
  Jes> take memory from the pool, this will force us to convert pages
  Jes> from cached to uncached if we don't have to.

Ah, that's a good point.

  Jes> [snip...]

  Jes> One could probably do this via mempool, but it would basically
  Jes> require one to put another object allocator below mempool which
  Jes> really makes the whole exercise pointless as this could just as
  Jes> well be done standalone ... ie. genalloc.

It does sound that way, yes.

Thanks,

--david
-
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 - 2.6.11-rc5-mm1] genalloc - general purpose allocator

[David Mosberger]

 On 03 Mar 2005 03:21:56 -0500, Jes Sorensen [EMAIL PROTECTED] said:

  Jes mempool on the other hand will first try and call the user
  Jes provided allocation function and only if that fails try and
  Jes take memory from the pool, this will force us to convert pages
  Jes from cached to uncached if we don't have to.

Ah, that's a good point.

  Jes [snip...]

  Jes One could probably do this via mempool, but it would basically
  Jes require one to put another object allocator below mempool which
  Jes really makes the whole exercise pointless as this could just as
  Jes well be done standalone ... ie. genalloc.

It does sound that way, yes.

Thanks,

--david
-
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 - 2.6.11-rc5-mm1] genalloc - general purpose allocator

[David Mosberger]

At the risk of asking the obvious: what's preventing genalloc to be
implemented in terms of mempool?

--david
-
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 - 2.6.11-rc5-mm1] genalloc - general purpose allocator

[David Mosberger]

At the risk of asking the obvious: what's preventing genalloc to be
implemented in terms of mempool?

--david
-
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 2.4.21 hangs up

[David Mosberger]

> On Tue, 01 Feb 2005 18:54:59 +0100, Markus Trippelsdorf <[EMAIL 
> PROTECTED]> said:

  Markus> They posted it to the LKML so time ago
  Markus> (2004-03-12). (message):
  Markus> http://marc.theaimsgroup.com/?l=linux-kernel=107913092300497
  Markus> (script):
  Markus> http://marc.theaimsgroup.com/?l=linux-kernel=107913092300497=p3

That script is for the x86-version of icc only.
It doesn't work for ia64, which is the context of this discussion.

--david
-
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 2.4.21 hangs up

[David Mosberger]

[I trimmed the cc-list...]

> On Tue, 1 Feb 2005 00:20:01 -0800 (PST), baswaraj kasture <[EMAIL 
> PROTECTED]> said:

  Baswaraj> Hi, I compiled kernel 2.4.21 with intel compiler .

That's curious.  Last time I checked, the changes needed to use the
Intel-compiler have not been backported to 2.4.  What kernel sources
are you working off of?

Also, even with 2.6 you need a script from Intel which does some
"magic" GCC->ICC option translations to build the kernel with the
Intel compiler.  AFAIK, this script has not been released by Intel
(hint, hint...).

  Baswaraj> While booting it hangs-up . further i found that it
  Baswaraj> hangsup due to call to "calibrate_delay" routine in
  Baswaraj> "init/main.c". Also found that loop in the
  Baswaraj> callibrate_delay" routine goes infinite.

I suspect your kernel was just miscompiled.  We have used the
Intel-compiler internally on a 2.6 kernel and it worked fine at the
time, though I haven't tried recently.

--david
-
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 2.4.21 hangs up

[David Mosberger]

[I trimmed the cc-list...]

 On Tue, 1 Feb 2005 00:20:01 -0800 (PST), baswaraj kasture [EMAIL 
 PROTECTED] said:

  Baswaraj Hi, I compiled kernel 2.4.21 with intel compiler .

That's curious.  Last time I checked, the changes needed to use the
Intel-compiler have not been backported to 2.4.  What kernel sources
are you working off of?

Also, even with 2.6 you need a script from Intel which does some
magic GCC-ICC option translations to build the kernel with the
Intel compiler.  AFAIK, this script has not been released by Intel
(hint, hint...).

  Baswaraj While booting it hangs-up . further i found that it
  Baswaraj hangsup due to call to calibrate_delay routine in
  Baswaraj init/main.c. Also found that loop in the
  Baswaraj callibrate_delay routine goes infinite.

I suspect your kernel was just miscompiled.  We have used the
Intel-compiler internally on a 2.6 kernel and it worked fine at the
time, though I haven't tried recently.

--david
-
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 2.4.21 hangs up

[David Mosberger]

 On Tue, 01 Feb 2005 18:54:59 +0100, Markus Trippelsdorf [EMAIL 
 PROTECTED] said:

  Markus They posted it to the LKML so time ago
  Markus (2004-03-12). (message):
  Markus http://marc.theaimsgroup.com/?l=linux-kernelm=107913092300497
  Markus (script):
  Markus http://marc.theaimsgroup.com/?l=linux-kernelm=107913092300497q=p3

That script is for the x86-version of icc only.
It doesn't work for ia64, which is the context of this discussion.

--david
-
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: [RFC][PATCH] new timeofday arch specific hooks (v. A2)

[David Mosberger]

> On Wed, 26 Jan 2005 08:52:12 -0800 (PST), Christoph Lameter <[EMAIL 
> PROTECTED]> said:

  Christoph> On Wed, 26 Jan 2005, Martin Schwidefsky wrote:
  >> Why not add an if at the start of gettimeofday to check when the
  >> last ntp updates has been done and if it has been too long since
  >> the last time then call ntp_scale ? That way the update isn't
  >> done on every call to gettimeofday and we don't depend on the
  >> regular timer tick.

  Christoph> Because ia64 does not support calling arbitrary C
  Christoph> functions in fastcalls.

However, it can fall back on a heavy-weight syscall easily.  We
already do that on a number of occasions, e.g., if we find a spinlock
already taken.  I think it would be OK to have gettimeofday
occasionally fall back on the heavy-weight version to do NTP magic.

--david
-
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: [RFC][PATCH] new timeofday arch specific hooks (v. A2)

[David Mosberger]

 On Wed, 26 Jan 2005 08:52:12 -0800 (PST), Christoph Lameter [EMAIL 
 PROTECTED] said:

  Christoph On Wed, 26 Jan 2005, Martin Schwidefsky wrote:
   Why not add an if at the start of gettimeofday to check when the
   last ntp updates has been done and if it has been too long since
   the last time then call ntp_scale ? That way the update isn't
   done on every call to gettimeofday and we don't depend on the
   regular timer tick.

  Christoph Because ia64 does not support calling arbitrary C
  Christoph functions in fastcalls.

However, it can fall back on a heavy-weight syscall easily.  We
already do that on a number of occasions, e.g., if we find a spinlock
already taken.  I think it would be OK to have gettimeofday
occasionally fall back on the heavy-weight version to do NTP magic.

--david
-
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 to enable Nvidia v5336 on v2.6.11 kernel (was Re: inter_module_get and __symbol_get)

[David Mosberger]

> On Tue, 25 Jan 2005 10:03:01 +1100, Keith Owens  said:

  Keith> I have always hated the dynamic resolution model used by
  Keith> DRM/AGP and (originally) MTD.

Well, the attached patch does the trick for me for Nvidia driver v5336
on ia64.  It compiles with a minimum amount of fuss with gcc v3.4
(just a handful of warnings about deprecated pm_{un,}register() and
inter_module_put()).

I have only tried it against 2.6.11-rc2 (really: Linus' bk tree as of
today) but I hope I didn't screw up backwards compatibility for older
kernels too badly.

Note: I removed the super-user sanity check---I hate that one since it
prevents me from building the module on an NFS-mounted file-system.
If you don't care for that bit, just omit the patch to conftest.sh.

--david

diff -urN -x nv_compiler.h -x '*.mod.c' -x '*.ko' -x '*.d' -x '*.o' -x '*~' -x 
build -x Makefile -x '.*' 
NVIDIA-Linux-ia64-1.0-5336-pkg1/usr/src/nv/Makefile.kbuild 
NVIDIA-Linux-ia64-1.0-5336-pkg1-davidm/usr/src/nv/Makefile.kbuild
--- NVIDIA-Linux-ia64-1.0-5336-pkg1/usr/src/nv/Makefile.kbuild  2004-01-16 
12:46:59.0 -0800
+++ NVIDIA-Linux-ia64-1.0-5336-pkg1-davidm/usr/src/nv/Makefile.kbuild   
2005-01-24 15:49:37.0 -0800
@@ -73,7 +73,7 @@
 #
 
 EXTRA_CFLAGS += -I$(src)
-EXTRA_CFLAGS += -Wall -Wimplicit -Wreturn-type -Wswitch -Wformat 
-Wchar-subscripts -Wparentheses -Wpointer-arith  -Wno-multichar  -Werror -O -MD 
$(DEFINES) $(INCLUDES) -Wno-cast-qual -Wno-error
+EXTRA_CFLAGS += -Wall -Wimplicit -Wreturn-type -Wswitch -Wformat 
-Wchar-subscripts -Wparentheses -Wno-multichar  -Werror -O2 -MD $(DEFINES) 
$(INCLUDES) -Wno-cast-qual -Wno-error
 
 #
 # We rely on these two definitions below; if they aren't set, we set them to
@@ -199,7 +199,7 @@
 #
 
 module: gcc-sanity-check
-   @make CC=$(CC) $(KBUILD_PARAMS) modules; \
+   @make CC=$(CC) CROSS_COMPILE=$(CROSS_COMPILE) $(KBUILD_PARAMS) modules; 
\
if ! [ -f $(MODULE_OBJECT) ]; then \
  echo "$(MODULE_OBJECT) failed to build!"; \
  exit 1; \
diff -urN -x nv_compiler.h -x '*.mod.c' -x '*.ko' -x '*.d' -x '*.o' -x '*~' -x 
build -x Makefile -x '.*' 
NVIDIA-Linux-ia64-1.0-5336-pkg1/usr/src/nv/conftest.sh 
NVIDIA-Linux-ia64-1.0-5336-pkg1-davidm/usr/src/nv/conftest.sh
--- NVIDIA-Linux-ia64-1.0-5336-pkg1/usr/src/nv/conftest.sh  2004-01-16 
12:46:59.0 -0800
+++ NVIDIA-Linux-ia64-1.0-5336-pkg1-davidm/usr/src/nv/conftest.sh   
2005-01-24 15:49:33.0 -0800
@@ -129,7 +129,7 @@
 echo -en "\033[1;31m";
 echo -e  "*** Failed super-user sanity check. Bailing out! ***";
 echo -en "\033[0m";
-exit 1
+exit 0
 else
 exit 0
 fi
diff -urN -x nv_compiler.h -x '*.mod.c' -x '*.ko' -x '*.d' -x '*.o' -x '*~' -x 
build -x Makefile -x '.*' NVIDIA-Linux-ia64-1.0-5336-pkg1/usr/src/nv/nv-linux.h 
NVIDIA-Linux-ia64-1.0-5336-pkg1-davidm/usr/src/nv/nv-linux.h
--- NVIDIA-Linux-ia64-1.0-5336-pkg1/usr/src/nv/nv-linux.h   2004-01-16 
12:46:59.0 -0800
+++ NVIDIA-Linux-ia64-1.0-5336-pkg1-davidm/usr/src/nv/nv-linux.h
2005-01-24 16:09:14.0 -0800
@@ -24,7 +24,7 @@
 #  define KERNEL_2_4
 #elif LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 0)
 #  error This driver does not support 2.5 kernels!
-#elif LINUX_VERSION_CODE < KERNEL_VERSION(2, 7, 0) && defined(NVCPU_X86)
+#elif LINUX_VERSION_CODE < KERNEL_VERSION(2, 7, 0)
 #  define KERNEL_2_6
 #else
 #  error This driver does not support development kernels!
@@ -293,13 +293,13 @@
 #if defined(NVCPU_IA64)
 #define NV_VMALLOC(ptr, size) \
 { \
-(void *) (ptr) = vmalloc_dma(size); \
+(ptr) = __vmalloc(size, GFP_KERNEL|GFP_DMA, PAGE_KERNEL); \
 VM_ALLOC_RECORD(ptr, size, "vm_alloc"); \
 }
 #else
 #define NV_VMALLOC(ptr, size) \
 { \
-(void *) (ptr) = vmalloc_32(size); \
+(ptr) = vmalloc_32(size); \
 VM_ALLOC_RECORD(ptr, size, "vm_alloc"); \
 }
 #endif
@@ -333,13 +333,13 @@
  */
 #define NV_KMALLOC(ptr, size) \
 { \
-(void *) (ptr) = kmalloc(size, GFP_KERNEL); \
+(ptr) = kmalloc(size, GFP_KERNEL); \
 KM_ALLOC_RECORD(ptr, size, "km_alloc"); \
 }
 
 #define NV_KMALLOC_ATOMIC(ptr, size) \
 { \
-(void *) (ptr) = kmalloc(size, GFP_ATOMIC); \
+(ptr) = kmalloc(size, GFP_ATOMIC); \
 KM_ALLOC_RECORD(ptr, size, "km_alloc_atomic"); \
 }  
 
@@ -352,7 +352,7 @@
 
 #define NV_GET_FREE_PAGES(ptr, order) \
 { \
-(void *) (ptr) = __get_free_pages(NV_GFP_HW, order); \
+(ptr) = __get_free_pages(NV_GFP_HW, order); \
 }
 
 #define NV_FREE_PAGES(ptr, order) \
@@ -454,14 +454,22 @@
  * relevant releases to date use it. This version was backported to 2.4 
  * without means to identify the change, hence this hack.
  */
-#if defined(REMAP_PAGE_RANGE_5)
-#define NV_REMAP_PAGE_RANGE(a, b...)remap_page_range(vma, a, ## b)
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 11)
+#define 

Re: inter_module_get and __symbol_get

[David Mosberger]

> On Tue, 25 Jan 2005 09:54:36 +1100, Keith Owens  said:

  Keith> Does DRM support this model?

  Keith> * Start DRM without AGP.
  Keith> * AGP is loaded.
  Keith> * DRM continues but now using AGP.

  Keith> If yes then it needs dynamic symbol resolution.

I think it does, but I don't see any advantages to it (not on the
machines I'm using, at least).  In fact, I'd rather have an explicit
dependency on AGP.

--david
-
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: inter_module_get and __symbol_get

[David Mosberger]

>>>>> On Mon, 24 Jan 2005 18:19:05 -0500, Jon Smirl <[EMAIL PROTECTED]> said:

  Jon> On Mon, 24 Jan 2005 14:52:06 -0800, David Mosberger
  Jon> <[EMAIL PROTECTED]> wrote:
  >> Well, the only place that I know of where I (have to) care about
  >> inter_module*() is because of the DRM/AGP dependency.  I can't
  >> imagine

  Jon> The DRM inter_module_XX dependency has been removed in
  Jon> 2.6.10. AGP still exports inter_module_XX so that things like
  Jon> Nvidia/ATI drivers will continue to work.

Not anymore:

  http://linux.bkbits.net:8080/linux-2.5/[EMAIL PROTECTED]

--david
-
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: inter_module_get and __symbol_get

[David Mosberger]

> On Tue, 25 Jan 2005 09:44:18 +1100, Keith Owens  said:

  Keith> Does the kernel code really need optional dynamic references
  Keith> between modules or kernel -> modules?  That depends on how
  Keith> people code their modules.  If the rest of the kernel no
  Keith> longer needs dynamic symbol reference then drop
  Keith> inter_module_* and __symbol_*.

Well, the only place that I know of where I (have to) care about
inter_module*() is because of the DRM/AGP dependency.  I can't imagine
DRM being overly happy if an AGP device suddenly disappeared, so I
think static is fine (in fact, probably preferable).

Of course, the trick is how to pull the backwards compatibility off
giving that for the time being we're more or less stuck with Nvidia's
5336 release on ia64... ;-(

--david
-
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: inter_module_get and __symbol_get

[David Mosberger]

Keith,

I didn't see any followup to your message.  My apologies if I missed
something.

You wrote:

 Keith> inter_module_* and __symbol_* solve these class of problems:

 Keith> Module A can use module B if B is loaded, but A does not
 Keith> require module B to do its work.  B is optional.

 Keith> The kernel can use code in module C is C is loaded, but the
 Keith> base kernel does not require module C.  C is optional.

Why isn't this handled via weak references?  If the reference comes
out as 0, you know the underlying module/facility isn't there and
proceed accordingly.

--david
-
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: inter_module_get and __symbol_get

[David Mosberger]

Keith,

I didn't see any followup to your message.  My apologies if I missed
something.

You wrote:

 Keith inter_module_* and __symbol_* solve these class of problems:

 Keith Module A can use module B if B is loaded, but A does not
 Keith require module B to do its work.  B is optional.

 Keith The kernel can use code in module C is C is loaded, but the
 Keith base kernel does not require module C.  C is optional.

Why isn't this handled via weak references?  If the reference comes
out as 0, you know the underlying module/facility isn't there and
proceed accordingly.

--david
-
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: inter_module_get and __symbol_get

[David Mosberger]

 On Tue, 25 Jan 2005 09:44:18 +1100, Keith Owens kaos@ocs.com.au said:

  Keith Does the kernel code really need optional dynamic references
  Keith between modules or kernel - modules?  That depends on how
  Keith people code their modules.  If the rest of the kernel no
  Keith longer needs dynamic symbol reference then drop
  Keith inter_module_* and __symbol_*.

Well, the only place that I know of where I (have to) care about
inter_module*() is because of the DRM/AGP dependency.  I can't imagine
DRM being overly happy if an AGP device suddenly disappeared, so I
think static is fine (in fact, probably preferable).

Of course, the trick is how to pull the backwards compatibility off
giving that for the time being we're more or less stuck with Nvidia's
5336 release on ia64... ;-(

--david
-
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: inter_module_get and __symbol_get

[David Mosberger]

 On Mon, 24 Jan 2005 18:19:05 -0500, Jon Smirl [EMAIL PROTECTED] said:

  Jon On Mon, 24 Jan 2005 14:52:06 -0800, David Mosberger
  Jon [EMAIL PROTECTED] wrote:
   Well, the only place that I know of where I (have to) care about
   inter_module*() is because of the DRM/AGP dependency.  I can't
   imagine

  Jon The DRM inter_module_XX dependency has been removed in
  Jon 2.6.10. AGP still exports inter_module_XX so that things like
  Jon Nvidia/ATI drivers will continue to work.

Not anymore:

  http://linux.bkbits.net:8080/linux-2.5/[EMAIL PROTECTED]

--david
-
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: inter_module_get and __symbol_get

[David Mosberger]

 On Tue, 25 Jan 2005 09:54:36 +1100, Keith Owens kaos@ocs.com.au said:

  Keith Does DRM support this model?

  Keith * Start DRM without AGP.
  Keith * AGP is loaded.
  Keith * DRM continues but now using AGP.

  Keith If yes then it needs dynamic symbol resolution.

I think it does, but I don't see any advantages to it (not on the
machines I'm using, at least).  In fact, I'd rather have an explicit
dependency on AGP.

--david
-
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 to enable Nvidia v5336 on v2.6.11 kernel (was Re: inter_module_get and __symbol_get)

[David Mosberger]

 On Tue, 25 Jan 2005 10:03:01 +1100, Keith Owens kaos@ocs.com.au said:

  Keith I have always hated the dynamic resolution model used by
  Keith DRM/AGP and (originally) MTD.

Well, the attached patch does the trick for me for Nvidia driver v5336
on ia64.  It compiles with a minimum amount of fuss with gcc v3.4
(just a handful of warnings about deprecated pm_{un,}register() and
inter_module_put()).

I have only tried it against 2.6.11-rc2 (really: Linus' bk tree as of
today) but I hope I didn't screw up backwards compatibility for older
kernels too badly.

Note: I removed the super-user sanity check---I hate that one since it
prevents me from building the module on an NFS-mounted file-system.
If you don't care for that bit, just omit the patch to conftest.sh.

--david

diff -urN -x nv_compiler.h -x '*.mod.c' -x '*.ko' -x '*.d' -x '*.o' -x '*~' -x 
build -x Makefile -x '.*' 
NVIDIA-Linux-ia64-1.0-5336-pkg1/usr/src/nv/Makefile.kbuild 
NVIDIA-Linux-ia64-1.0-5336-pkg1-davidm/usr/src/nv/Makefile.kbuild
--- NVIDIA-Linux-ia64-1.0-5336-pkg1/usr/src/nv/Makefile.kbuild  2004-01-16 
12:46:59.0 -0800
+++ NVIDIA-Linux-ia64-1.0-5336-pkg1-davidm/usr/src/nv/Makefile.kbuild   
2005-01-24 15:49:37.0 -0800
@@ -73,7 +73,7 @@
 #
 
 EXTRA_CFLAGS += -I$(src)
-EXTRA_CFLAGS += -Wall -Wimplicit -Wreturn-type -Wswitch -Wformat 
-Wchar-subscripts -Wparentheses -Wpointer-arith  -Wno-multichar  -Werror -O -MD 
$(DEFINES) $(INCLUDES) -Wno-cast-qual -Wno-error
+EXTRA_CFLAGS += -Wall -Wimplicit -Wreturn-type -Wswitch -Wformat 
-Wchar-subscripts -Wparentheses -Wno-multichar  -Werror -O2 -MD $(DEFINES) 
$(INCLUDES) -Wno-cast-qual -Wno-error
 
 #
 # We rely on these two definitions below; if they aren't set, we set them to
@@ -199,7 +199,7 @@
 #
 
 module: gcc-sanity-check
-   @make CC=$(CC) $(KBUILD_PARAMS) modules; \
+   @make CC=$(CC) CROSS_COMPILE=$(CROSS_COMPILE) $(KBUILD_PARAMS) modules; 
\
if ! [ -f $(MODULE_OBJECT) ]; then \
  echo $(MODULE_OBJECT) failed to build!; \
  exit 1; \
diff -urN -x nv_compiler.h -x '*.mod.c' -x '*.ko' -x '*.d' -x '*.o' -x '*~' -x 
build -x Makefile -x '.*' 
NVIDIA-Linux-ia64-1.0-5336-pkg1/usr/src/nv/conftest.sh 
NVIDIA-Linux-ia64-1.0-5336-pkg1-davidm/usr/src/nv/conftest.sh
--- NVIDIA-Linux-ia64-1.0-5336-pkg1/usr/src/nv/conftest.sh  2004-01-16 
12:46:59.0 -0800
+++ NVIDIA-Linux-ia64-1.0-5336-pkg1-davidm/usr/src/nv/conftest.sh   
2005-01-24 15:49:33.0 -0800
@@ -129,7 +129,7 @@
 echo -en \033[1;31m;
 echo -e  *** Failed super-user sanity check. Bailing out! ***;
 echo -en \033[0m;
-exit 1
+exit 0
 else
 exit 0
 fi
diff -urN -x nv_compiler.h -x '*.mod.c' -x '*.ko' -x '*.d' -x '*.o' -x '*~' -x 
build -x Makefile -x '.*' NVIDIA-Linux-ia64-1.0-5336-pkg1/usr/src/nv/nv-linux.h 
NVIDIA-Linux-ia64-1.0-5336-pkg1-davidm/usr/src/nv/nv-linux.h
--- NVIDIA-Linux-ia64-1.0-5336-pkg1/usr/src/nv/nv-linux.h   2004-01-16 
12:46:59.0 -0800
+++ NVIDIA-Linux-ia64-1.0-5336-pkg1-davidm/usr/src/nv/nv-linux.h
2005-01-24 16:09:14.0 -0800
@@ -24,7 +24,7 @@
 #  define KERNEL_2_4
 #elif LINUX_VERSION_CODE  KERNEL_VERSION(2, 6, 0)
 #  error This driver does not support 2.5 kernels!
-#elif LINUX_VERSION_CODE  KERNEL_VERSION(2, 7, 0)  defined(NVCPU_X86)
+#elif LINUX_VERSION_CODE  KERNEL_VERSION(2, 7, 0)
 #  define KERNEL_2_6
 #else
 #  error This driver does not support development kernels!
@@ -293,13 +293,13 @@
 #if defined(NVCPU_IA64)
 #define NV_VMALLOC(ptr, size) \
 { \
-(void *) (ptr) = vmalloc_dma(size); \
+(ptr) = __vmalloc(size, GFP_KERNEL|GFP_DMA, PAGE_KERNEL); \
 VM_ALLOC_RECORD(ptr, size, vm_alloc); \
 }
 #else
 #define NV_VMALLOC(ptr, size) \
 { \
-(void *) (ptr) = vmalloc_32(size); \
+(ptr) = vmalloc_32(size); \
 VM_ALLOC_RECORD(ptr, size, vm_alloc); \
 }
 #endif
@@ -333,13 +333,13 @@
  */
 #define NV_KMALLOC(ptr, size) \
 { \
-(void *) (ptr) = kmalloc(size, GFP_KERNEL); \
+(ptr) = kmalloc(size, GFP_KERNEL); \
 KM_ALLOC_RECORD(ptr, size, km_alloc); \
 }
 
 #define NV_KMALLOC_ATOMIC(ptr, size) \
 { \
-(void *) (ptr) = kmalloc(size, GFP_ATOMIC); \
+(ptr) = kmalloc(size, GFP_ATOMIC); \
 KM_ALLOC_RECORD(ptr, size, km_alloc_atomic); \
 }  
 
@@ -352,7 +352,7 @@
 
 #define NV_GET_FREE_PAGES(ptr, order) \
 { \
-(void *) (ptr) = __get_free_pages(NV_GFP_HW, order); \
+(ptr) = __get_free_pages(NV_GFP_HW, order); \
 }
 
 #define NV_FREE_PAGES(ptr, order) \
@@ -454,14 +454,22 @@
  * relevant releases to date use it. This version was backported to 2.4 
  * without means to identify the change, hence this hack.
  */
-#if defined(REMAP_PAGE_RANGE_5)
-#define NV_REMAP_PAGE_RANGE(a, b...)remap_page_range(vma, a, ## b)
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 11)
+#define 

Re: sparse warning, or why does jifies_to_msecs() return an int?

[David Mosberger]

> On Sat, 15 Jan 2005 10:05:37 -0800 (PST), Linus Torvalds <[EMAIL 
> PROTECTED]> said:

  Linus> Hmm.. I don't think your patch is wrong per se, but I do
  Linus> think it's a bit too subtle. I'd almost rather make
  Linus> "jiffies_to_msecs()" just test for overflow instead, and that
  Linus> should also fix it.

You sure about that?

Actually, I think my patch was broken anyhow for HZ < 1000 because you
can potentially get integer-overflows in temporary results which could
make things come out wrong again.

I _think_ the attached patch works for all reasonable cases reasonably
uniformly, but if you thought the previous patch was subtle, I'm sure
you going to like this one even less.

Note that with the patch, platforms where HZ is not a power of two and
doesn't fit any of the other special cases (namely (HZ % 1000) != 0 &&
(1000 % HZ) != 0) would suffer a penalty.  AFAICS, this is true only
for Alpha/Rawhide (HZ=1200).  In such a case, rather than:

(j * 1000)/HZ

the new code would compute:

(j/HZ)*1000 + ((j%HZ)*1000)/HZ

It looks to me like we could get rid of all the ugly & complex
intermediate overflow-checks if we defined MAX_JIFFY_OFFSET
as:
(~0UL / 1000)

However, on a 32-bit platform that runs at 1000 Hz, this would limit
us to 4294 seconds.  That may be cutting it a bit close.

--david

= include/linux/jiffies.h 1.11 vs edited =
--- 1.11/include/linux/jiffies.h2005-01-04 18:48:02 -08:00
+++ edited/include/linux/jiffies.h  2005-01-20 15:21:14 -08:00
@@ -254,13 +254,32 @@
  */
 static inline unsigned int jiffies_to_msecs(const unsigned long j)
 {
+   unsigned long res;
+
 #if HZ <= 1000 && !(1000 % HZ)
-   return (1000 / HZ) * j;
+   unsigned long max = ~0UL / (1000 / HZ);
+
+   if (j > max)
+   max = j;
+   res = (1000 / HZ) * j;
 #elif HZ > 1000 && !(HZ % 1000)
-   return (j + (HZ / 1000) - 1)/(HZ / 1000);
+   res = (j + (HZ / 1000) - 1) / (HZ / 1000);
 #else
-   return (j * 1000) / HZ;
+   /*
+* HZ better be a power of two; otherwise this gets real
+* expensive.  Better expensive than wrong, though.
+*/
+# if HZ < 1000
+   unsigned long max = (~0UL / 1000) * HZ;
+
+   if (j > max)
+   j = max;
+# endif
+   res = (j / HZ) * 1000 + ((j % HZ) * 1000) / HZ;
 #endif
+   if (res > ~0U)
+   return ~0U;
+   return res;
 }
 
 static inline unsigned int jiffies_to_usecs(const unsigned long j)
-
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: sparse warning, or why does jifies_to_msecs() return an int?

[David Mosberger]

 On Sat, 15 Jan 2005 10:05:37 -0800 (PST), Linus Torvalds [EMAIL 
 PROTECTED] said:

  Linus Hmm.. I don't think your patch is wrong per se, but I do
  Linus think it's a bit too subtle. I'd almost rather make
  Linus jiffies_to_msecs() just test for overflow instead, and that
  Linus should also fix it.

You sure about that?

Actually, I think my patch was broken anyhow for HZ  1000 because you
can potentially get integer-overflows in temporary results which could
make things come out wrong again.

I _think_ the attached patch works for all reasonable cases reasonably
uniformly, but if you thought the previous patch was subtle, I'm sure
you going to like this one even less.

Note that with the patch, platforms where HZ is not a power of two and
doesn't fit any of the other special cases (namely (HZ % 1000) != 0 
(1000 % HZ) != 0) would suffer a penalty.  AFAICS, this is true only
for Alpha/Rawhide (HZ=1200).  In such a case, rather than:

(j * 1000)/HZ

the new code would compute:

(j/HZ)*1000 + ((j%HZ)*1000)/HZ

It looks to me like we could get rid of all the ugly  complex
intermediate overflow-checks if we defined MAX_JIFFY_OFFSET
as:
(~0UL / 1000)

However, on a 32-bit platform that runs at 1000 Hz, this would limit
us to 4294 seconds.  That may be cutting it a bit close.

--david

= include/linux/jiffies.h 1.11 vs edited =
--- 1.11/include/linux/jiffies.h2005-01-04 18:48:02 -08:00
+++ edited/include/linux/jiffies.h  2005-01-20 15:21:14 -08:00
@@ -254,13 +254,32 @@
  */
 static inline unsigned int jiffies_to_msecs(const unsigned long j)
 {
+   unsigned long res;
+
 #if HZ = 1000  !(1000 % HZ)
-   return (1000 / HZ) * j;
+   unsigned long max = ~0UL / (1000 / HZ);
+
+   if (j  max)
+   max = j;
+   res = (1000 / HZ) * j;
 #elif HZ  1000  !(HZ % 1000)
-   return (j + (HZ / 1000) - 1)/(HZ / 1000);
+   res = (j + (HZ / 1000) - 1) / (HZ / 1000);
 #else
-   return (j * 1000) / HZ;
+   /*
+* HZ better be a power of two; otherwise this gets real
+* expensive.  Better expensive than wrong, though.
+*/
+# if HZ  1000
+   unsigned long max = (~0UL / 1000) * HZ;
+
+   if (j  max)
+   j = max;
+# endif
+   res = (j / HZ) * 1000 + ((j % HZ) * 1000) / HZ;
 #endif
+   if (res  ~0U)
+   return ~0U;
+   return res;
 }
 
 static inline unsigned int jiffies_to_usecs(const unsigned long j)
-
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: pipe performance regression on ia64

[David Mosberger]

> On Wed, 19 Jan 2005 23:43:45 +1100, Nick Piggin <[EMAIL PROTECTED]> said:

  Nick> Oh that's quite true. A bad score on SMP on the pipe benchmark
  Nick> does not mean anything is broken.

  Nick> And IMO, probably many (most?) lmbench tests should be run
  Nick> with all processes bound to the same CPU on SMP systems to get
  Nick> the best repeatability and an indication of the basic serial
  Nick> speed of the operation (which AFAIK is what they aim to
  Nick> measure).

We need to keep an eye on both the intra- and the inter-cpu
pipe-bandwidth and should measure them explicitly.  The problem is
that at the moment, we get one, the other, or a mixture of the two,
subject to the vagaries of the scheduler.  If we could reliably
measure both intra and inter-cpu cases, we may well find new
optimization opportunities (I'm almost certain that's the case for the
cross-cpu case; which is probably the more important case, actually).

--david
-
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: pipe performance regression on ia64

[David Mosberger]

 On Wed, 19 Jan 2005 23:43:45 +1100, Nick Piggin [EMAIL PROTECTED] said:

  Nick Oh that's quite true. A bad score on SMP on the pipe benchmark
  Nick does not mean anything is broken.

  Nick And IMO, probably many (most?) lmbench tests should be run
  Nick with all processes bound to the same CPU on SMP systems to get
  Nick the best repeatability and an indication of the basic serial
  Nick speed of the operation (which AFAIK is what they aim to
  Nick measure).

We need to keep an eye on both the intra- and the inter-cpu
pipe-bandwidth and should measure them explicitly.  The problem is
that at the moment, we get one, the other, or a mixture of the two,
subject to the vagaries of the scheduler.  If we could reliably
measure both intra and inter-cpu cases, we may well find new
optimization opportunities (I'm almost certain that's the case for the
cross-cpu case; which is probably the more important case, actually).

--david
-
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: pipe performance regression on ia64

[David Mosberger]

> On Wed, 19 Jan 2005 10:34:30 +1100, Nick Piggin <[EMAIL PROTECTED]> said:

  Nick> David I remember you reporting a pipe bandwidth regression,
  Nick> and I had a patch for it, but that hurt other workloads, so I
  Nick> don't think we ever really got anywhere. I've recently begun
  Nick> having another look at the multiprocessor balancer, so
  Nick> hopefully I can get a bit further with it this time.

While it may be worthwhile to improve the scheduler, it's clear that
there isn't going to be a trivial "fix" for this issue, especially
since it's not even clear that anything is really broken.  Independent
of the scheduler work, it would be very useful to have a pipe
benchmark which at least made the dependencies on the scheduler
obvious.  So I think improving the scheduler and improving the LMbench
pipe benchmark are entirely complementary.

--david

-
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: pipe performance regression on ia64

[David Mosberger]

> On Tue, 18 Jan 2005 10:11:26 -0800 (PST), Linus Torvalds <[EMAIL 
> PROTECTED]> said:

  Linus> I don't know how to make the benchmark look repeatable and
  Linus> good, though.  The CPU affinity thing may be the right thing.

Perhaps it should be split up into three cases:

- producer/consumer pinned to the same CPU
- producer/consumer pinned to different CPUs
- producer/consumer lefter under control of the scheduler

The first two would let us observe any changes in the actual pipe
code, whereas the 3rd case would tell us which case the scheduler is
leaning towards (or if it starts doing something real crazy, like
reschedule the tasks on different CPUs each time, we'd see a bandwith
lower than case 2 and that should ring alarm bells).

--david
-
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: pipe performance regression on ia64

[David Mosberger]

 On Tue, 18 Jan 2005 10:11:26 -0800 (PST), Linus Torvalds [EMAIL 
 PROTECTED] said:

  Linus I don't know how to make the benchmark look repeatable and
  Linus good, though.  The CPU affinity thing may be the right thing.

Perhaps it should be split up into three cases:

- producer/consumer pinned to the same CPU
- producer/consumer pinned to different CPUs
- producer/consumer lefter under control of the scheduler

The first two would let us observe any changes in the actual pipe
code, whereas the 3rd case would tell us which case the scheduler is
leaning towards (or if it starts doing something real crazy, like
reschedule the tasks on different CPUs each time, we'd see a bandwith
lower than case 2 and that should ring alarm bells).

--david
-
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: pipe performance regression on ia64

[David Mosberger]

 On Wed, 19 Jan 2005 10:34:30 +1100, Nick Piggin [EMAIL PROTECTED] said:

  Nick David I remember you reporting a pipe bandwidth regression,
  Nick and I had a patch for it, but that hurt other workloads, so I
  Nick don't think we ever really got anywhere. I've recently begun
  Nick having another look at the multiprocessor balancer, so
  Nick hopefully I can get a bit further with it this time.

While it may be worthwhile to improve the scheduler, it's clear that
there isn't going to be a trivial fix for this issue, especially
since it's not even clear that anything is really broken.  Independent
of the scheduler work, it would be very useful to have a pipe
benchmark which at least made the dependencies on the scheduler
obvious.  So I think improving the scheduler and improving the LMbench
pipe benchmark are entirely complementary.

--david

-
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] clean up pt_regs accesses

[David Mosberger]

This patch replaces the idiom:

func (args..., long stack) {
struct pt_regs *regs = (struct pt_regs *) 

with the more commonly used:

func (args..., struct pt_regs regs) {

The latter didn't used to work with the very earliest kernels and
compilers (anybody remember egcs?) but gcc-3.3 and probably even
gcc-2.96 don't have a problem with it anymore.

The change also makes sparse happier, since it doesn't like it when
you access memory past the end of the declared size of that variable...

With this patch, the ia64-specific sparse warnings are now down to:

 arch/ia64/ia32/../../../fs/binfmt_elf.c:1073:33: warning: incorrect type in 
argument 2 (different address spaces)
 arch/ia64/kernel/mca_drv.c:430:4: warning: invalid access past the end of 
'mca_handler_bhhook' (8 8)
 arch/ia64/kernel/mca_drv.c:430:4: warning: invalid access past the end of 
'mca_handler_bhhook' (8 8)
 arch/ia64/kernel/mca_drv.c:430:4: warning: invalid access past the end of 
'mca_handler_bhhook' (8 8)
 arch/ia64/hp/common/sba_iommu.c:240:40: warning: marked inline, but without a 
definition
 arch/ia64/hp/common/sba_iommu.c:241:38: warning: marked inline, but without a 
definition
 drivers/pci/pci-sysfs.c:204:16: warning: undefined identifier 
'ia64_pci_legacy_read'
 drivers/pci/pci-sysfs.c:227:16: warning: undefined identifier 
'ia64_pci_legacy_write'

Somebody else will have to look into these.

--david

Signed-off-by: David Mosberger-Tang <[EMAIL PROTECTED]>

= arch/ia64/ia32/ia32_signal.c 1.34 vs edited =
--- 1.34/arch/ia64/ia32/ia32_signal.c   2005-01-04 18:48:19 -08:00
+++ edited/arch/ia64/ia32/ia32_signal.c 2005-01-14 22:49:30 -08:00
@@ -1,7 +1,7 @@
 /*
  * IA32 Architecture-specific signal handling support.
  *
- * Copyright (C) 1999, 2001-2002 Hewlett-Packard Co
+ * Copyright (C) 1999, 2001-2002, 2005 Hewlett-Packard Co
  * David Mosberger-Tang <[EMAIL PROTECTED]>
  * Copyright (C) 1999 Arun Sharma <[EMAIL PROTECTED]>
  * Copyright (C) 2000 VA Linux Co
@@ -970,11 +970,10 @@
 }
 
 asmlinkage long
-sys32_sigreturn (int arg0, int arg1, int arg2, int arg3, int arg4, int arg5, 
int arg6, int arg7,
-unsigned long stack)
+sys32_sigreturn (int arg0, int arg1, int arg2, int arg3, int arg4, int arg5,
+int arg6, int arg7, struct pt_regs regs)
 {
-   struct pt_regs *regs = (struct pt_regs *) 
-   unsigned long esp = (unsigned int) regs->r12;
+   unsigned long esp = (unsigned int) regs.r12;
struct sigframe_ia32 __user *frame = (struct sigframe_ia32 __user 
*)(esp - 8);
sigset_t set;
int eax;
@@ -993,7 +992,7 @@
recalc_sigpending();
spin_unlock_irq(>sighand->siglock);
 
-   if (restore_sigcontext_ia32(regs, >sc, ))
+   if (restore_sigcontext_ia32(, >sc, ))
goto badframe;
return eax;
 
@@ -1003,11 +1002,10 @@
 }
 
 asmlinkage long
-sys32_rt_sigreturn (int arg0, int arg1, int arg2, int arg3, int arg4, int 
arg5, int arg6, int arg7,
-   unsigned long stack)
+sys32_rt_sigreturn (int arg0, int arg1, int arg2, int arg3, int arg4,
+   int arg5, int arg6, int arg7, struct pt_regs regs)
 {
-   struct pt_regs *regs = (struct pt_regs *) 
-   unsigned long esp = (unsigned int) regs->r12;
+   unsigned long esp = (unsigned int) regs.r12;
struct rt_sigframe_ia32 __user *frame = (struct rt_sigframe_ia32 __user 
*)(esp - 4);
sigset_t set;
int eax;
@@ -1023,7 +1021,7 @@
recalc_sigpending();
spin_unlock_irq(>sighand->siglock);
 
-   if (restore_sigcontext_ia32(regs, >uc.uc_mcontext, ))
+   if (restore_sigcontext_ia32(, >uc.uc_mcontext, ))
goto badframe;
 
/* It is more difficult to avoid calling this function than to
= arch/ia64/ia32/sys_ia32.c 1.111 vs edited =
--- 1.111/arch/ia64/ia32/sys_ia32.c 2005-01-11 15:58:41 -08:00
+++ edited/arch/ia64/ia32/sys_ia32.c2005-01-14 23:26:05 -08:00
@@ -6,7 +6,7 @@
  * Copyright (C) 1999  Arun Sharma <[EMAIL PROTECTED]>
  * Copyright (C) 1997,1998 Jakub Jelinek ([EMAIL PROTECTED])
  * Copyright (C) 1997  David S. Miller ([EMAIL PROTECTED])
- * Copyright (C) 2000-2003 Hewlett-Packard Co
+ * Copyright (C) 2000-2003, 2005 Hewlett-Packard Co
  * David Mosberger-Tang <[EMAIL PROTECTED]>
  * Copyright (C) 2004  Gordon Jin <[EMAIL PROTECTED]>
  *
@@ -1436,7 +1436,7 @@
 }
 
 static unsigned int
-ia32_peek (struct pt_regs *regs, struct task_struct *child, unsigned long 
addr, unsigned int *val)
+ia32_peek (struct task_struct *child, unsigned long addr, unsigned int *val)
 {
size_t copied;
unsigned int ret;
@@ -1446,7 +1446,7 @@
 }
 
 static unsigned int
-ia32_poke (struct pt_regs *regs, struct task_struct *child, unsigned long 
addr, unsigned int val)
+ia32_poke (struct task_struct *child, unsigned long addr, unsigned int

[patch] clean up pt_regs accesses

[David Mosberger]

This patch replaces the idiom:

func (args..., long stack) {
struct pt_regs *regs = (struct pt_regs *) stack;

with the more commonly used:

func (args..., struct pt_regs regs) {

The latter didn't used to work with the very earliest kernels and
compilers (anybody remember egcs?) but gcc-3.3 and probably even
gcc-2.96 don't have a problem with it anymore.

The change also makes sparse happier, since it doesn't like it when
you access memory past the end of the declared size of that variable...

With this patch, the ia64-specific sparse warnings are now down to:

 arch/ia64/ia32/../../../fs/binfmt_elf.c:1073:33: warning: incorrect type in 
argument 2 (different address spaces)
 arch/ia64/kernel/mca_drv.c:430:4: warning: invalid access past the end of 
'mca_handler_bhhook' (8 8)
 arch/ia64/kernel/mca_drv.c:430:4: warning: invalid access past the end of 
'mca_handler_bhhook' (8 8)
 arch/ia64/kernel/mca_drv.c:430:4: warning: invalid access past the end of 
'mca_handler_bhhook' (8 8)
 arch/ia64/hp/common/sba_iommu.c:240:40: warning: marked inline, but without a 
definition
 arch/ia64/hp/common/sba_iommu.c:241:38: warning: marked inline, but without a 
definition
 drivers/pci/pci-sysfs.c:204:16: warning: undefined identifier 
'ia64_pci_legacy_read'
 drivers/pci/pci-sysfs.c:227:16: warning: undefined identifier 
'ia64_pci_legacy_write'

Somebody else will have to look into these.

--david

Signed-off-by: David Mosberger-Tang [EMAIL PROTECTED]

= arch/ia64/ia32/ia32_signal.c 1.34 vs edited =
--- 1.34/arch/ia64/ia32/ia32_signal.c   2005-01-04 18:48:19 -08:00
+++ edited/arch/ia64/ia32/ia32_signal.c 2005-01-14 22:49:30 -08:00
@@ -1,7 +1,7 @@
 /*
  * IA32 Architecture-specific signal handling support.
  *
- * Copyright (C) 1999, 2001-2002 Hewlett-Packard Co
+ * Copyright (C) 1999, 2001-2002, 2005 Hewlett-Packard Co
  * David Mosberger-Tang [EMAIL PROTECTED]
  * Copyright (C) 1999 Arun Sharma [EMAIL PROTECTED]
  * Copyright (C) 2000 VA Linux Co
@@ -970,11 +970,10 @@
 }
 
 asmlinkage long
-sys32_sigreturn (int arg0, int arg1, int arg2, int arg3, int arg4, int arg5, 
int arg6, int arg7,
-unsigned long stack)
+sys32_sigreturn (int arg0, int arg1, int arg2, int arg3, int arg4, int arg5,
+int arg6, int arg7, struct pt_regs regs)
 {
-   struct pt_regs *regs = (struct pt_regs *) stack;
-   unsigned long esp = (unsigned int) regs-r12;
+   unsigned long esp = (unsigned int) regs.r12;
struct sigframe_ia32 __user *frame = (struct sigframe_ia32 __user 
*)(esp - 8);
sigset_t set;
int eax;
@@ -993,7 +992,7 @@
recalc_sigpending();
spin_unlock_irq(current-sighand-siglock);
 
-   if (restore_sigcontext_ia32(regs, frame-sc, eax))
+   if (restore_sigcontext_ia32(regs, frame-sc, eax))
goto badframe;
return eax;
 
@@ -1003,11 +1002,10 @@
 }
 
 asmlinkage long
-sys32_rt_sigreturn (int arg0, int arg1, int arg2, int arg3, int arg4, int 
arg5, int arg6, int arg7,
-   unsigned long stack)
+sys32_rt_sigreturn (int arg0, int arg1, int arg2, int arg3, int arg4,
+   int arg5, int arg6, int arg7, struct pt_regs regs)
 {
-   struct pt_regs *regs = (struct pt_regs *) stack;
-   unsigned long esp = (unsigned int) regs-r12;
+   unsigned long esp = (unsigned int) regs.r12;
struct rt_sigframe_ia32 __user *frame = (struct rt_sigframe_ia32 __user 
*)(esp - 4);
sigset_t set;
int eax;
@@ -1023,7 +1021,7 @@
recalc_sigpending();
spin_unlock_irq(current-sighand-siglock);
 
-   if (restore_sigcontext_ia32(regs, frame-uc.uc_mcontext, eax))
+   if (restore_sigcontext_ia32(regs, frame-uc.uc_mcontext, eax))
goto badframe;
 
/* It is more difficult to avoid calling this function than to
= arch/ia64/ia32/sys_ia32.c 1.111 vs edited =
--- 1.111/arch/ia64/ia32/sys_ia32.c 2005-01-11 15:58:41 -08:00
+++ edited/arch/ia64/ia32/sys_ia32.c2005-01-14 23:26:05 -08:00
@@ -6,7 +6,7 @@
  * Copyright (C) 1999  Arun Sharma [EMAIL PROTECTED]
  * Copyright (C) 1997,1998 Jakub Jelinek ([EMAIL PROTECTED])
  * Copyright (C) 1997  David S. Miller ([EMAIL PROTECTED])
- * Copyright (C) 2000-2003 Hewlett-Packard Co
+ * Copyright (C) 2000-2003, 2005 Hewlett-Packard Co
  * David Mosberger-Tang [EMAIL PROTECTED]
  * Copyright (C) 2004  Gordon Jin [EMAIL PROTECTED]
  *
@@ -1436,7 +1436,7 @@
 }
 
 static unsigned int
-ia32_peek (struct pt_regs *regs, struct task_struct *child, unsigned long 
addr, unsigned int *val)
+ia32_peek (struct task_struct *child, unsigned long addr, unsigned int *val)
 {
size_t copied;
unsigned int ret;
@@ -1446,7 +1446,7 @@
 }
 
 static unsigned int
-ia32_poke (struct pt_regs *regs, struct task_struct *child, unsigned long 
addr, unsigned int val)
+ia32_poke (struct task_struct *child, unsigned long addr, unsigned int val

[patch] avoid sparse warning due to time-interpolator

[David Mosberger]

The "addr" member in the time-interpolator is sometimes used as a
function-pointer and sometimes as an I/O-memory pointer.  The attached
patch tells sparse that this is OK.

Signed-off-by: David Mosberger-Tang <[EMAIL PROTECTED]>

= kernel/timer.c 1.109 vs edited =
--- 1.109/kernel/timer.c2005-01-11 16:42:35 -08:00
+++ edited/kernel/timer.c   2005-01-14 22:05:53 -08:00
@@ -1411,10 +1411,10 @@
return x();
 
case TIME_SOURCE_MMIO64 :
-   return readq(time_interpolator->addr);
+   return readq((void __iomem *) time_interpolator->addr);
 
case TIME_SOURCE_MMIO32 :
-   return readl(time_interpolator->addr);
+   return readl((void __iomem *) time_interpolator->addr);
 
default: return get_cycles();
}
-
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] avoid sparse warning due to time-interpolator

[David Mosberger]

The addr member in the time-interpolator is sometimes used as a
function-pointer and sometimes as an I/O-memory pointer.  The attached
patch tells sparse that this is OK.

Signed-off-by: David Mosberger-Tang [EMAIL PROTECTED]

= kernel/timer.c 1.109 vs edited =
--- 1.109/kernel/timer.c2005-01-11 16:42:35 -08:00
+++ edited/kernel/timer.c   2005-01-14 22:05:53 -08:00
@@ -1411,10 +1411,10 @@
return x();
 
case TIME_SOURCE_MMIO64 :
-   return readq(time_interpolator-addr);
+   return readq((void __iomem *) time_interpolator-addr);
 
case TIME_SOURCE_MMIO32 :
-   return readl(time_interpolator-addr);
+   return readl((void __iomem *) time_interpolator-addr);
 
default: return get_cycles();
}
-
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/