[PATCH v5 08/11] arm/dts: Add twl4030-usb data
Add twl4030-usb data node in twl4030 device tree file.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/twl4030.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index 22f4d13..761a5a5 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -37,6 +37,18 @@
regulator-max-microvolt = <315>;
};
+ vusb1v5: regulator-vusb1v5 {
+ compatible = "ti,twl4030-vusb1v5";
+ };
+
+ vusb1v8: regulator-vusb1v8 {
+ compatible = "ti,twl4030-vusb1v8";
+ };
+
+ vusb3v1: regulator-vusb3v1 {
+ compatible = "ti,twl4030-vusb3v1";
+ };
+
twl_gpio: gpio {
compatible = "ti,twl4030-gpio";
gpio-controller;
@@ -44,4 +56,13 @@
interrupt-controller;
#interrupt-cells = <1>;
};
+
+ twl4030-usb {
+ compatible = "ti,twl4030-usb";
+ interrupts = < 10 4 >;
+ usb1v5-supply = <>;
+ usb1v8-supply = <>;
+ usb3v1-supply = <>;
+ usb_mode = <1>;
+ };
};
--
1.7.9.5
--
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/
[PATCH v5 10/11] arm/dts: omap: Add usb_otg and glue data
Add usb otg data node in omap4/omap3 device tree file. Also update
the node with board specific setting in omapx-.dts file.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap3-beagle.dts |6 ++
arch/arm/boot/dts/omap3-evm.dts|6 ++
arch/arm/boot/dts/omap3.dtsi |8
arch/arm/boot/dts/omap4-panda.dts |6 ++
arch/arm/boot/dts/omap4-sdp.dts|6 ++
arch/arm/boot/dts/omap4.dtsi |8
6 files changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 5b4506c..f3d7076 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -67,3 +67,9 @@
{
status = "disable";
};
+
+_otg_hs {
+ interface_type = <0>;
+ mode = <3>;
+ power = <50>;
+};
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index 2eee16e..8963b3d 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -18,3 +18,9 @@
reg = <0x8000 0x1000>; /* 256 MB */
};
};
+
+_otg_hs {
+ interface_type = <0>;
+ mode = <3>;
+ power = <50>;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 99474fa..4b8c142 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -215,5 +215,13 @@
compatible = "ti,omap3-hsmmc";
ti,hwmods = "mmc3";
};
+
+ usb_otg_hs: usb_otg_hs {
+ compatible = "ti,omap3-musb";
+ ti,hwmods = "usb_otg_hs";
+ multipoint = <1>;
+ num_eps = <16>;
+ ram_bits = <12>;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 7052422..dd19370 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -93,3 +93,9 @@
{
usb-supply = <>;
};
+
+_otg_hs {
+ interface_type = <1>;
+ mode = <3>;
+ power = <50>;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 6326d7c..0fc10d4 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -162,3 +162,9 @@
{
usb-supply = <>;
};
+
+_otg_hs {
+ interface_type = <1>;
+ mode = <3>;
+ power = <50>;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 15f1890..7886518 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -285,5 +285,13 @@
<0x4a002300 0x1>;
};
};
+
+ usb_otg_hs: usb_otg_hs {
+ compatible = "ti,omap4-musb";
+ ti,hwmods = "usb_otg_hs";
+ multipoint = <1>;
+ num_eps = <16>;
+ ram_bits = <12>;
+ };
};
};
--
1.7.9.5
--
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/
[PATCH v5 04/11] arm: omap: hwmod: add a new addr space in otg for writing to control module
The mailbox register for usb otg in omap is present in control module.
On detection of any events VBUS or ID, this register should be written
to send the notification to musb core.
Till we have a separate control module driver to write to control module,
omap2430 will handle the register writes to control module by itself. So
a new address space to represent this control module register is added
to usb_otg_hs.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index ba24d15..c50d828 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5922,6 +5922,11 @@ static struct omap_hwmod_addr_space
omap44xx_usb_otg_hs_addrs[] = {
.pa_end = 0x4a0ab7ff,
.flags = ADDR_TYPE_RT
},
+ {
+ .pa_start = 0x4a00233c,
+ .pa_end = 0x4a00233f,
+ .flags = ADDR_TYPE_RT
+ },
{ }
};
--
1.7.9.5
--
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/
[PATCH v5 01/11] drivers: usb: otg: add a new driver for omap usb2 phy
All phy related programming like enabling/disabling the clocks, powering
on/off the phy is taken care of by this driver. It is also used for OTG
related functionality like srp.
This also includes device tree support for usb2 phy driver and
the documentation with device tree binding information is updated.
Currently writing to control module register is taken care in this
driver which will be removed once the control module driver is in place.
Cc: Felipe Balbi
Signed-off-by: Kishon Vijay Abraham I
---
.../devicetree/bindings/bus/omap-ocp2scp.txt |3 +
Documentation/devicetree/bindings/usb/omap-usb.txt | 16 ++
drivers/usb/otg/Kconfig| 10 +
drivers/usb/otg/Makefile |1 +
drivers/usb/otg/omap-usb2.c| 271
include/linux/usb/omap_usb.h | 45
include/linux/usb/phy_companion.h | 34 +++
7 files changed, 380 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt
create mode 100644 drivers/usb/otg/omap-usb2.c
create mode 100644 include/linux/usb/omap_usb.h
create mode 100644 include/linux/usb/phy_companion.h
diff --git a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
index d2fe064..bb0c7f4 100644
--- a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
+++ b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
@@ -8,3 +8,6 @@ properties:
Sub-nodes:
All the devices connected to ocp2scp are described using sub-node to ocp2scp
+- usb2phy :
+ The binding details of usb2phy can be found in:
+ Documentation/devicetree/bindings/usb/omap-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
new file mode 100644
index 000..80a28c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -0,0 +1,16 @@
+OMAP USB PHY
+
+OMAP USB2 PHY
+
+Required properties:
+ - compatible: Should be "ti,omap-usb2"
+ - reg : Address and length of the register set for the device. Also
+add the address of control module dev conf register until a driver for
+control module is added
+
+This is usually a subnode of ocp2scp to which it is connected.
+
+usb2phy@0x4a0ad080 {
+ compatible = "ti,omap-usb2";
+ reg = <0x4a0ad080 0x58>;
+};
diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig
index 5c87db0..c751db7 100644
--- a/drivers/usb/otg/Kconfig
+++ b/drivers/usb/otg/Kconfig
@@ -78,6 +78,16 @@ config TWL6030_USB
are hooked to this driver through platform_data structure.
The definition of internal PHY APIs are in the mach-omap2 layer.
+config OMAP_USB2
+ tristate "OMAP USB2 PHY Driver"
+ depends on OMAP_OCP2SCP
+ select USB_OTG_UTILS
+ help
+ Enable this to support the transceiver that is part of SOC. This
+ driver takes care of all the PHY functionality apart from comparator.
+ The USB OTG controller communicates with the comparator using this
+ driver.
+
config NOP_USB_XCEIV
tristate "NOP USB Transceiver Driver"
select USB_OTG_UTILS
diff --git a/drivers/usb/otg/Makefile b/drivers/usb/otg/Makefile
index 41aa509..2c2a3ca 100644
--- a/drivers/usb/otg/Makefile
+++ b/drivers/usb/otg/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_USB_GPIO_VBUS) += gpio_vbus.o
obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o
obj-$(CONFIG_TWL4030_USB) += twl4030-usb.o
obj-$(CONFIG_TWL6030_USB) += twl6030-usb.o
+obj-$(CONFIG_OMAP_USB2)+= omap-usb2.o
obj-$(CONFIG_NOP_USB_XCEIV)+= nop-usb-xceiv.o
obj-$(CONFIG_USB_ULPI) += ulpi.o
obj-$(CONFIG_USB_ULPI_VIEWPORT)+= ulpi_viewport.o
diff --git a/drivers/usb/otg/omap-usb2.c b/drivers/usb/otg/omap-usb2.c
new file mode 100644
index 000..2f9e257
--- /dev/null
+++ b/drivers/usb/otg/omap-usb2.c
@@ -0,0 +1,271 @@
+/*
+ * omap-usb2.c - USB PHY, talking to musb controller in OMAP.
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * omap_usb2_set_comparator - links the comparator present in the sytem with
+ * this phy
+ * @comparator - the companion phy(comparator) for this phy
+ *
+ * The phy
[PATCH v5 02/11] arm/dts: omap: Add omap-usb2 dt data
Add omap-usb2 data node in omap4 device tree file.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap4.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 29c6243..15f1890 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -279,6 +279,11 @@
#size-cells = <1>;
ranges;
ti,hwmods = "ocp2scp_usb_phy";
+ usb2phy@4a0ad080 {
+ compatible = "ti,omap-usb2";
+ reg = <0x4a0ad080 0x58>,
+ <0x4a002300 0x1>;
+ };
};
};
};
--
1.7.9.5
--
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/
[PATCH v5 03/11] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
All the PHY configuration other than VBUS, ID GND and OTG SRP are removed
from twl6030. The phy configurations are taken care by the dedicated
usb2 phy driver. So twl6030 is made as comparator driver for VBUS and
ID detection.
Writing to control module which is now handled in omap2430.c should be
removed once a driver for control module is in place.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/musb/omap2430.c | 52 ---
drivers/usb/musb/omap2430.h |9
drivers/usb/otg/twl6030-usb.c | 114 +
3 files changed, 67 insertions(+), 108 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 5fdb9da..addbebf 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -44,6 +44,7 @@ struct omap2430_glue {
struct platform_device *musb;
enum omap_musb_vbus_id_status status;
struct work_struct omap_musb_mailbox_work;
+ u32 __iomem *control_otghs;
};
#define glue_to_musb(g)platform_get_drvdata(g->musb)
@@ -51,6 +52,26 @@ struct omap2430_glue *_glue;
static struct timer_list musb_idle_timer;
+/**
+ * omap4_usb_phy_mailbox - write to usb otg mailbox
+ * @glue: struct omap2430_glue *
+ * @val: the value to be written to the mailbox
+ *
+ * On detection of a device (ID pin is grounded), this API should be called
+ * to set AVALID, VBUSVALID and ID pin is grounded.
+ *
+ * When OMAP is connected to a host (OMAP in device mode), this API
+ * is called to set AVALID, VBUSVALID and ID pin in high impedance.
+ *
+ * XXX: This function will be removed once we have a seperate driver for
+ * control module
+ */
+static void omap4_usb_phy_mailbox(struct omap2430_glue *glue, u32 val)
+{
+ if (glue->control_otghs)
+ writel(val, glue->control_otghs);
+}
+
static void musb_do_idle(unsigned long _musb)
{
struct musb *musb = (void *)_musb;
@@ -245,6 +266,7 @@ EXPORT_SYMBOL_GPL(omap_musb_mailbox);
static void omap_musb_set_mailbox(struct omap2430_glue *glue)
{
+ u32 val;
struct musb *musb = glue_to_musb(glue);
struct device *dev = musb->controller;
struct musb_hdrc_platform_data *pdata = dev->platform_data;
@@ -260,7 +282,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
musb->xceiv->last_event = USB_EVENT_ID;
if (!is_otg_enabled(musb) || musb->gadget_driver) {
pm_runtime_get_sync(dev);
- usb_phy_init(musb->xceiv);
+ val = AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
omap2430_musb_set_vbus(musb, 1);
}
break;
@@ -273,7 +296,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
musb->xceiv->last_event = USB_EVENT_VBUS;
if (musb->gadget_driver)
pm_runtime_get_sync(dev);
- usb_phy_init(musb->xceiv);
+ val = IDDIG | AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
break;
case OMAP_MUSB_ID_FLOAT:
@@ -291,7 +315,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
if (musb->xceiv->otg->set_vbus)
otg_set_vbus(musb->xceiv->otg, 0);
}
- usb_phy_shutdown(musb->xceiv);
+ val = SESSEND | IDDIG;
+ omap4_usb_phy_mailbox(glue, val);
break;
default:
dev_dbg(dev, "ID float\n");
@@ -366,6 +391,7 @@ err1:
static void omap2430_musb_enable(struct musb *musb)
{
u8 devctl;
+ u32 val;
unsigned long timeout = jiffies + msecs_to_jiffies(1000);
struct device *dev = musb->controller;
struct omap2430_glue *glue = dev_get_drvdata(dev->parent);
@@ -375,7 +401,8 @@ static void omap2430_musb_enable(struct musb *musb)
switch (glue->status) {
case OMAP_MUSB_ID_GROUND:
- usb_phy_init(musb->xceiv);
+ val = AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
if (data->interface_type != MUSB_INTERFACE_UTMI)
break;
devctl = musb_readb(musb->mregs, MUSB_DEVCTL);
@@ -394,7 +421,8 @@ static void omap2430_musb_enable(struct musb *musb)
break;
case OMAP_MUSB_VBUS_VALID:
- usb_phy_init(musb->xceiv);
+ val = IDDIG | AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
break;
default:
@@ -404,11 +432,14 @@ static void omap2430_musb_enable(struct musb *musb)
static void omap2430_musb_disable(struct musb *musb)
{
+ u32 val;
struct device *dev = musb->controller;
struct omap2430_glue *glue =
[PATCH v5 00/11] omap: musb: Add device tree support
This patch series adds device tree support for MUSB and device tree support for all the related modules to get MUSB working in OMAP platform. A new omap-usb2 phy driver has been added (with only dt suppport) to perform phy configurations. Previously this configuration was performed by twl6030, using pdata function pointers. With the addition of omap-usb2 to perform phy configurations, twl6030 is made as a comparator driver to detect VBUS and ID events and notify it to the glue layer. musb core is _NOT_ yet converted to support device tree support as it would need lot of driver re-design because of its enormous use of function pointers. That will be in _TO DO_ list. Changes from v4: duplicate getting of 'mode' property is removed in omap-musb glue. Changes from v3: remove the address in the node name of usb_otg_hs since the usb_otg_hs node doesn't have a reg property. Thanks Ajay Gupta for finding this. Changes from v2: Fixed Sergei's comment to remove *0x* prefix in usb2phy@0x4a0ad080 Changes from v1: * Fixed Rajendra Nayak comments (regulator naming, compatible naming of musb and other minor cleanups.) * It's agreed to have ocp2scp in drivers/bus and usb2 phy is a child of ocp2scp, the documentation is updated accordingly. Changes from RFC: Removed the dependency on [RFC PATCH 00/11] OMAP System Control Module. Writing to control module register is now handled in otg driver itself. Once the system control module driver get upstreamed, I'll send a patch to make use of API's in control module driver to write to control module register. This series was developed on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv This patch series depends on [PATCH 0/2] omap: add ocp2scp as a bus driver Performed MUSB device mode testing on OMAP4 panda, OMAP4 SDP and OMAP3 beagle. Kishon Vijay Abraham I (11): drivers: usb: otg: add a new driver for omap usb2 phy arm/dts: omap: Add omap-usb2 dt data drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2 arm: omap: hwmod: add a new addr space in otg for writing to control module drivers: usb: twl6030: Add dt support for twl6030 usb arm/dts: Add twl6030-usb data drivers: usb: twl4030: Add device tree support for twl4030 usb arm/dts: Add twl4030-usb data drivers: usb: musb: Add device tree support for omap musb glue arm/dts: omap: Add usb_otg and glue data arm: omap: phy: remove unused functions from omap-phy-internal.c .../devicetree/bindings/bus/omap-ocp2scp.txt |3 + Documentation/devicetree/bindings/usb/omap-usb.txt | 48 .../devicetree/bindings/usb/twl-usb.txt| 41 +++ arch/arm/boot/dts/omap3-beagle.dts |6 + arch/arm/boot/dts/omap3-evm.dts|6 + arch/arm/boot/dts/omap3.dtsi |8 + arch/arm/boot/dts/omap4-panda.dts | 10 + arch/arm/boot/dts/omap4-sdp.dts| 10 + arch/arm/boot/dts/omap4.dtsi | 13 + arch/arm/boot/dts/twl4030.dtsi | 21 ++ arch/arm/boot/dts/twl6030.dtsi |6 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 + arch/arm/mach-omap2/omap_phy_internal.c| 138 -- arch/arm/mach-omap2/twl-common.c |5 - arch/arm/mach-omap2/usb-musb.c |3 - drivers/usb/musb/omap2430.c| 106 +++- drivers/usb/musb/omap2430.h|9 + drivers/usb/otg/Kconfig| 10 + drivers/usb/otg/Makefile |1 + drivers/usb/otg/omap-usb2.c| 271 drivers/usb/otg/twl4030-usb.c | 26 +- drivers/usb/otg/twl6030-usb.c | 153 +++ include/linux/usb/omap_usb.h | 45 include/linux/usb/phy_companion.h | 34 +++ 24 files changed, 705 insertions(+), 273 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt create mode 100644 Documentation/devicetree/bindings/usb/twl-usb.txt create mode 100644 drivers/usb/otg/omap-usb2.c create mode 100644 include/linux/usb/omap_usb.h create mode 100644 include/linux/usb/phy_companion.h -- 1.7.9.5 -- 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/
[PATCH v5 11/11] arm: omap: phy: remove unused functions from omap-phy-internal.c
All the unnessary functions in omap-phy-internal is removed.
These functionality are now handled by omap-usb2 phy driver.
Cc: Felipe Balbi
Signed-off-by: Kishon Vijay Abraham I
Acked-by: Tony Lindgren
---
arch/arm/mach-omap2/omap_phy_internal.c | 138 ---
arch/arm/mach-omap2/twl-common.c|5 --
arch/arm/mach-omap2/usb-musb.c |3 -
3 files changed, 146 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index d52651a..874aecc 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -31,144 +31,6 @@
#include
#include "control.h"
-/* OMAP control module register for UTMI PHY */
-#define CONTROL_DEV_CONF 0x300
-#define PHY_PD 0x1
-
-#define USBOTGHS_CONTROL 0x33c
-#defineAVALID BIT(0)
-#defineBVALID BIT(1)
-#defineVBUSVALID BIT(2)
-#defineSESSEND BIT(3)
-#defineIDDIG BIT(4)
-
-static struct clk *phyclk, *clk48m, *clk32k;
-static void __iomem *ctrl_base;
-static int usbotghs_control;
-
-int omap4430_phy_init(struct device *dev)
-{
- ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K);
- if (!ctrl_base) {
- pr_err("control module ioremap failed\n");
- return -ENOMEM;
- }
- /* Power down the phy */
- __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
-
- if (!dev) {
- iounmap(ctrl_base);
- return 0;
- }
-
- phyclk = clk_get(dev, "ocp2scp_usb_phy_ick");
- if (IS_ERR(phyclk)) {
- dev_err(dev, "cannot clk_get ocp2scp_usb_phy_ick\n");
- iounmap(ctrl_base);
- return PTR_ERR(phyclk);
- }
-
- clk48m = clk_get(dev, "ocp2scp_usb_phy_phy_48m");
- if (IS_ERR(clk48m)) {
- dev_err(dev, "cannot clk_get ocp2scp_usb_phy_phy_48m\n");
- clk_put(phyclk);
- iounmap(ctrl_base);
- return PTR_ERR(clk48m);
- }
-
- clk32k = clk_get(dev, "usb_phy_cm_clk32k");
- if (IS_ERR(clk32k)) {
- dev_err(dev, "cannot clk_get usb_phy_cm_clk32k\n");
- clk_put(phyclk);
- clk_put(clk48m);
- iounmap(ctrl_base);
- return PTR_ERR(clk32k);
- }
- return 0;
-}
-
-int omap4430_phy_set_clk(struct device *dev, int on)
-{
- static int state;
-
- if (on && !state) {
- /* Enable the phy clocks */
- clk_enable(phyclk);
- clk_enable(clk48m);
- clk_enable(clk32k);
- state = 1;
- } else if (state) {
- /* Disable the phy clocks */
- clk_disable(phyclk);
- clk_disable(clk48m);
- clk_disable(clk32k);
- state = 0;
- }
- return 0;
-}
-
-int omap4430_phy_power(struct device *dev, int ID, int on)
-{
- if (on) {
- if (ID)
- /* enable VBUS valid, IDDIG groung */
- __raw_writel(AVALID | VBUSVALID, ctrl_base +
- USBOTGHS_CONTROL);
- else
- /*
-* Enable VBUS Valid, AValid and IDDIG
-* high impedance
-*/
- __raw_writel(IDDIG | AVALID | VBUSVALID,
- ctrl_base + USBOTGHS_CONTROL);
- } else {
- /* Enable session END and IDIG to high impedance. */
- __raw_writel(SESSEND | IDDIG, ctrl_base +
- USBOTGHS_CONTROL);
- }
- return 0;
-}
-
-int omap4430_phy_suspend(struct device *dev, int suspend)
-{
- if (suspend) {
- /* Disable the clocks */
- omap4430_phy_set_clk(dev, 0);
- /* Power down the phy */
- __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
-
- /* save the context */
- usbotghs_control = __raw_readl(ctrl_base + USBOTGHS_CONTROL);
- } else {
- /* Enable the internel phy clcoks */
- omap4430_phy_set_clk(dev, 1);
- /* power on the phy */
- if (__raw_readl(ctrl_base + CONTROL_DEV_CONF) & PHY_PD) {
- __raw_writel(~PHY_PD, ctrl_base + CONTROL_DEV_CONF);
- mdelay(200);
- }
-
- /* restore the context */
- __raw_writel(usbotghs_control, ctrl_base + USBOTGHS_CONTROL);
- }
-
- return 0;
-}
-
-int omap4430_phy_exit(struct device *dev)
-{
- if (ctrl_base)
- iounmap(ctrl_base);
- if (phyclk)
-
Re: [PATCH 3/4] powerpc/crypto: add 842 hardware compression driver
On Thu, 2012-07-19 at 09:42 -0500, Seth Jennings wrote:
> This patch adds the driver for interacting with the 842
> compression accelerator on IBM Power7+ systems.
...
> +struct nx842_slentry {
> + unsigned long ptr; /* Absolute address (use virt_to_abs()) */
> /+unsigned long len;
> +};
These days virt_to_abs() is just __pa() - ie. convert to a real address.
So you should just use __pa().
And you also need to be certain that you only call it on addresses where
that makes sense, ie. not vmalloc etc.
cheers
--
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: [RFC PATCH -tip ] tracing: make a snapshot feature available from userspace.
Hello, Steven,
(Sorry for the late reply.)
Tnank you for your comments.
(2012/07/12 8:26), Steven Rostedt wrote:
+Snapshot
+
+If CONFIG_TRACER_MAX_TRACE is set, the (generic) snapshot
+feature is available in all tracers except for the special
+tracers which use a snapshot inside themselves(such as "irqsoff"
+or "wakeup").
I find this kind of ironic, that it is only defined when one of the
tracers that can't use it defines it.
Ah, I missed that.
Maybe we should make it a prompt config for this feature.
Yes, I'll make the new config like "CONFIG_TRACER_SNAPSHOT".
+ snapshot_enabled:
+
+ This is used to set or display whether the snapshot is
+ enabled. Echo 1 into this file to prepare a spare buffer
+ or 0 to shrink it. So, the memory for the spare buffer
+ will be consumed only when this knob is set.
+
+ snapshot_pipe:
+
+ This is used to take a snapshot and to read the output
+ of the snapshot. Echo 1 into this file to take a
+ snapshot. Reads from this file is the same as the
+ "trace_pipe" file (described above "The File System"
+ section), so that both reads from the snapshot and
+ tracing are executable in parallel.
I don't really like the name snapshot_pipe. What about just calling it
snapshot, and just document that it works like trace_pipe?
Agreed. I'll change the name to snapshot and modify document.
Also, rename snapshot_enabled, to snapshot_allocate. If someone echos 1
into snapshot, it would automatically allocate the buffer (and set
snapshot_allocate to 1). If you don't want the delay (for allocation),
then you can do the echo 1 into snapshot_allocate first, and it would
behave as it does here.
I'll change them to that way.
+
+Here is an example of using the snapshot feature.
+
+ # echo nop > current_tracer
+ # echo 1 > snapshot_enabled
+ # echo 1 > events/sched/enable
+ [...]
+ # echo 1 > snapshot_pipe
+ # cat snapshot_pipe
+bash-3352 [001] dN.. 18440.883932: sched_wakeup: comm=migration/6
pid=28 prio=0 success=1 target_cpu=006
+bash-3352 [001] dN.. 18440.883933: sched_wakeup: comm=migration/7
pid=32 prio=0 success=1 target_cpu=007
+bash-3352 [001] d... 18440.883935: sched_switch: prev_comm=bash
prev_pid=3352 prev_prio=120 prev_state=R ==> next_comm=migration/1 next_pid=8
next_prio=0
+[...]
BTW, why make it a pipe action anyway? As a snapshot doesn't have a
writer to it, doing just an iterate over the snapshot would make sense,
wouldn't it?
I thought I should reuse existing code as much as possible. So I'd like
to reuse the "trace" code at first. But opening "trace" stops tracing
until it is closed. Therefore, I reused "trace_pipe" code instead of
"trace".
However, it seems that I should have made new iteration code as you
pointed out. I will make it the "trace"-like action.
If you reply with a good rational for keeping the snapshot_pipe, then we
should have both snapshot and snapshot_pipe, where snapshot works like
trace and snapshot_pipe works like trace_pipe.
I think only "snapshot" file is enough for the present.
+static ssize_t
+tracing_write_snapshot_pipe(struct file *filp, const char __user *ubuf,
+ size_t cnt, loff_t *ppos)
+{
+ unsigned long val = 0;
+ int ret;
+
+ ret = kstrtoul_from_user(ubuf, cnt, 10, );
+ if (ret)
+ return ret;
+
+ mutex_lock(_types_lock);
+
+ /* If current tracer's use_max_tr == 0, we prevent taking a snapshot */
Here we should just allocate it first.
OK. I'll add that.
+ if (!current_trace->use_max_tr) {
I also have issues with the use of 'use_max_tr' here, but I'll explain
that below.
+ ret = -EBUSY;
+ goto out;
+ }
+ if (val) {
+ unsigned long flags;
+ local_irq_save(flags);
Interrupts will never be disabled here. Just use
'local_irq_disable/enable()', and remove flags.
Yes. I'll fix it.
+ update_max_tr(_trace, current, raw_smp_processor_id());
Also, get rid of the 'raw_' that's for critical paths that can be broken
by the debug version of the normal user (like in function tracing and
callbacks from disabling interrupts).
I'll fix it.
+static ssize_t
+tracing_snapshot_ctrl_write(struct file *filp, const char __user *ubuf,
+ size_t cnt, loff_t *ppos)
+{
+ unsigned long val;
+ int ret;
+
+ ret = kstrtoul_from_user(ubuf, cnt, 10, );
+ if (ret)
+ return ret;
+
+ val = !!val;
+
+ mutex_lock(_types_lock);
+ tracing_stop();
+ arch_spin_lock(_max_lock);
+
+ /* When always_use_max_tr == 1, we can't toggle use_max_tr. */
+ if (current_trace->always_use_max_tr) {
I'll state my issue here. Don't rename use_max_tr to always_use_max_tr,
keep it as is and its use as is. Your other value should be
"allocated_snapshot", which can be set
linux-next: Tree for July 20
Hi all, Changes since 20120719: The scsi tree gained a conflict against Linus' tree and a build failure for which I reverted a commit. The net-next tree lost a conflict. The tty tree lost its build failure but gained 3 more for which I disabled 2 staging drivers and applied a patch. The staging tree lost its build failure. I have still reverted 3 commits from the signal tree at the request of the arm maintainer. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 197 trees (counting Linus' and 26 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (3e4b945 Merge tag 'md-3.5-fixes' of git://neil.brown.name/md) Merging fixes/master (9023a40 Merge tag 'mmc-fixes-for-3.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc) Merging kbuild-current/rc-fixes (f8f5701 Linux 3.5-rc1) Merging arm-current/fixes (ff081e0 ARM: 7457/1: smp: Fix suspicious RCU originating from cpu_die()) Merging m68k-current/for-linus (d8ce726 m68k: Use generic strncpy_from_user(), strlen_user(), and strnlen_user()) Merging powerpc-merge/merge (50fb31c tty/hvc_opal: Fix debug function name) Merging sparc/master (d55de60 sparc64: remove unused function straddles_64bit_va_hole()) Merging net/master (3e4b945 Merge tag 'md-3.5-fixes' of git://neil.brown.name/md) Merging sound-current/for-linus (68e67f4 ALSA: snd-usb: move calls to usb_set_interface) Merging pci-current/for-linus (314489b Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc) Merging wireless/master (8a70e7f NFC: NCI module license 'unspecified' taints kernel) Merging driver-core.current/driver-core-linus (84a1caf Linux 3.5-rc7) Merging tty.current/tty-linus (84a1caf Linux 3.5-rc7) Merging usb.current/usb-linus (84a1caf Linux 3.5-rc7) Merging staging.current/staging-linus (6887a41 Linux 3.5-rc5) Merging char-misc.current/char-misc-linus (84a1caf Linux 3.5-rc7) Merging input-current/for-linus (e76b8ee Input: xpad - add Andamiro Pump It Up pad) Merging md-current/for-linus (58e94ae md/raid1: close some possible races on write errors during resync) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (c475c06 hwrng: atmel-rng - fix data valid check) Merging ide/master (39a50b4 Merge branch 'hfsplus') Merging dwmw2/master (244dc4e Merge git://git.infradead.org/users/dwmw2/random-2.6) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (15e06bf irqdomain: Fix debugfs formatting) Merging devicetree-current/devicetree/merge (4e8383b of: release node fix for of_parse_phandle_with_args) Merging spi-current/spi/merge (d1c185b of/spi: Fix SPI module loading by using proper "spi:" modalias prefixes.) Merging gpio-current/gpio/merge (96b7064 gpio/tca6424: merge I2C transactions, remove cast) Merging arm/for-next (dea2ea3 Merge branches 'audit', 'delay', 'dmaengine', 'fixes', 'misc' and 'sta2x11' into for-next) Merging arm-perf/for-next/perf (dee8c1b ARM: perf: remove arm_perf_pmu_ids global enumeration) Merging davinci/davinci-next (fe0d422
linux-next: build failure after merge of the final tree (tty tree related)
Hi all,
After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:
drivers/usb/serial/console.c: In function 'usb_console_setup':
drivers/usb/serial/console.c:168:16: error: invalid type argument of '->' (have
'struct ktermios')
drivers/usb/serial/console.c:169:4: error: incompatible type for argument 1 of
'tty_termios_encode_baud_rate'
include/linux/tty.h:449:13: note: expected 'struct ktermios *' but argument is
of type 'struct ktermios'
Caused by commit adc8d746caa6 ("tty: move the termios object into the
tty"). Hopefully this is the last of them.
I have added the following fix patch for today:
From: Stephen Rothwell
Date: Fri, 20 Jul 2012 14:58:31 +1000
Subject: [PATCH] tty: fix up usb serial console for termios change.
fixes these errors:
drivers/usb/serial/console.c: In function 'usb_console_setup':
drivers/usb/serial/console.c:168:16: error: invalid type argument of '->' (have
'struct ktermios')
drivers/usb/serial/console.c:169:4: error: incompatible type for argument 1 of
'tty_termios_encode_baud_rate'
include/linux/tty.h:449:13: note: expected 'struct ktermios *' but argument is
of type 'struct ktermios'
Signed-off-by: Stephen Rothwell
---
drivers/usb/serial/console.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/serial/console.c b/drivers/usb/serial/console.c
index b9cca6d..9a56428 100644
--- a/drivers/usb/serial/console.c
+++ b/drivers/usb/serial/console.c
@@ -165,8 +165,8 @@ static int usb_console_setup(struct console *co, char
*options)
}
if (serial->type->set_termios) {
- tty->termios->c_cflag = cflag;
- tty_termios_encode_baud_rate(tty->termios, baud, baud);
+ tty->termios.c_cflag = cflag;
+ tty_termios_encode_baud_rate(>termios, baud, baud);
memset(, 0, sizeof(struct ktermios));
serial->type->set_termios(tty, port, );
--
1.7.10.280.gaa39
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp7rxKoYMliR.pgp
Description: PGP signature
Re: [PATCH] kdump: Append newline to the last lien of vmcoreinfo note
Hello Vivek,
On Thu, 19 Jul 2012 09:49:21 -0400
Vivek Goyal wrote:
> On Wed, Jul 18, 2012 at 03:04:39PM -0700, Andrew Morton wrote:
> > On Tue, 17 Jul 2012 13:36:55 -0400
> > Vivek Goyal wrote:
> >
> > > Last line of vmcoreinfo note does not end with \n. Parsing all the lines
> > > in note becomes easier if all lines end with \n instead of trying to
> > > special
> > > case the last line.
> > >
> > > I know atleast one tool, vmcore-dmesg in kexec-tools tree which made the
> > > assumption that all lines end with \n. I think it is a good idea to
> > > fix it.
> > >
> > > Signed-off-by: Vivek Goyal
> > > ---
> > > kernel/kexec.c |2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > Index: linux-2.6/kernel/kexec.c
> > > ===
> > > --- linux-2.6.orig/kernel/kexec.c 2012-07-17 19:26:38.844033784 -0400
> > > +++ linux-2.6/kernel/kexec.c 2012-07-17 23:51:33.311701781 -0400
> > > @@ -1424,7 +1424,7 @@ static void update_vmcoreinfo_note(void)
> > >
> > > void crash_save_vmcoreinfo(void)
> > > {
> > > - vmcoreinfo_append_str("CRASHTIME=%ld", get_seconds());
> > > + vmcoreinfo_append_str("CRASHTIME=%ld\n", get_seconds());
> > > update_vmcoreinfo_note();
> > > }
> >
> > huh, that was a screwup. And now we have to make what must be
> > viewed as a non-back-compatible ABI change.
> >
> > Ho hum, presumably there isn't a lot of code out there which is
> > dependent upon a non-newline-terminated CRASHTIME record.
>
> I think so. AFAIK, makedumpfile (vmcore filtering utility) is only
> user of CRASHTIME=.
>
> >
> > Why did this work at all, anyway? Is CRASHTIME always the last-emitted
> > record?
>
> Yes, CRASHTIME= is always the last emitted line in vmcoreinfo note.
>
> I had a quick look at makedumpfile code and looks like they read the whole
> note, dump it to a file and then do fgets() on the file in a loop. As it is
> last line in the file, fgets encounters EOF and reads the CRASHTIME= line
> successfully. So even after this change makedumpfile should remain
> unaffected.
>
> CCing makedumpfile maintainer, Atsushi Kumagai.
As you said, makedumpfile reads VMCOREINFO line by line with fgets().
So, it's OK that the end of the last line is whether \n or EOF.
Therefore, this change doesn't affect makedumpfile.
Thanks
Atsushi Kumagai
--
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: commit 91013923c712e1c: "irqdomain: Replace LEGACY mapping with LINEAR" breaks console on ARM i.mx23
On Thu, Jul 19, 2012 at 11:28 AM, Attila Kinali wrote: > Hi, > > I'm working on an embedded system based on a Freescale ARM9 processor i.mx23. > > While trying linux-next i stumpled over my login prompt getting broken. > What exactly happens is that the kernel boots normally, but when my > login prompt should appear it suddenly stops. I bisected it back to > the commit 91013923c712e1c4b9b343f0ee4a86ce72b1b630 > irqdomain: Replace LEGACY mapping with LINEAR > > Reverting this and the three commits that directly depend on it (see below) > everything seems to work fine again Hi Attila, Can you please send me your boot log /after/ removing these three patches? Thanks, g. -- 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/
Andre Hedrick (anhedric) has died
Dear Linux hackers, Sorry for the intrusion on this technical list. I wanted to let Andre's fellow Linux developers know that he died this past weekend. For those that don't know him, Andre was an active developer for the ATA driver a while back. I have known Andre for about 9 years, although I haven't seen much of him in the past year. He and I attended several retreats together in 2002 and 2003. I'd like to share a story from the first time I met him. I was a FreeBSD developer at the time and had done some work in the SCSI (CAM) subsystem. I met Andre at a retreat center in the Marin woods. As we ate dinner, he mentioned that he was a software developer. "So am I", I said. "I work on code for handling disk drives," he continued. "So do I, at least in my spare time," I replied. "I work on Linux," he said. "FreeBSD is better," I joked. He took the insult in fine fashion. "To work on disk drivers, you have to be a special kind of bastard," he said, his eyes sparkling. "Are you something of a jerk? All the good storage programmers are." We both laughed, and began recounting arguments on various mailing lists about error recovery, queuing, etc. I saw him a few times in Berkeley after that. His wife and kids were often with him. He, like all of us, was a real person, not just a personality on a mailing list. I've always thought kindly of Andre, and like many of us, he had high standards and an impatience to make things better. I have a lot of respect for people like that. I'm sorry to bring this news to you, and I'll miss him. Sincerely, Nate -- 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/
[PATCH] regulator: mc13xxx: Remove extern function declaration for mc13xxx_sw_regulator
This function does not exist, remove the extern function declaration.
Signed-off-by: Axel Lin
---
drivers/regulator/mc13xxx.h |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/regulator/mc13xxx.h b/drivers/regulator/mc13xxx.h
index 8343a25..eaff551 100644
--- a/drivers/regulator/mc13xxx.h
+++ b/drivers/regulator/mc13xxx.h
@@ -32,7 +32,6 @@ struct mc13xxx_regulator_priv {
struct regulator_dev *regulators[];
};
-extern int mc13xxx_sw_regulator(struct regulator_dev *rdev);
extern int mc13xxx_fixed_regulator_set_voltage(struct regulator_dev *rdev,
int min_uV, int max_uV, unsigned *selector);
extern int mc13xxx_fixed_regulator_get_voltage(struct regulator_dev *rdev);
--
1.7.9.5
--
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: Boot breaks in -next from LEGACY to LINEAR conversion
On Wed, Jul 18, 2012 at 10:10 AM, Mark Brown wrote: > On Tue, Jul 17, 2012 at 07:57:49PM +0100, Mark Brown wrote: >> -next fails to boot for me today on my s3c64xx based systems. Walking >> back to the last time I tried and bisecting likely branches I find that >> commit 910139 (irqdomain: Replace LEGACY mapping with LINEAR) is the one >> that introduces the build break. Unfortunately the boot fails before I >> get a console which makes diagnosis somewhat more tricky than would be >> ideal. Any ideas? > > Further data: the irq_domain_associate_many() calls that we're now doing > are also causing WARN_ON()s to go off during boot after commit 98aa46 > (irqdomain: Support for static IRQ mapping and association) causing > breakage for my interrupt using MFDs. Okay, I've got a theory about what the issue is now. The .map() callback is failing (returning non-zero) for one of the hwirqs. The new code is stricter about associations, and actually unwinds the associations if one of them fails. The old legacy code simply called all the .map() hooks blindly without any error checking. Can you send me the kernel log after backing out those changes. The other possibility is that irqs aren't being reserved correctly. Seeing the backtrace will tell me which issue it is. In the mean time I've backed out the top three commits from irqdomain/next. g. -- 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] Cgroup: Fix memory accounting scalability in shrink_page_list
On Fri, Jul 20, 2012 at 12:19:20PM +0900, Kamezawa Hiroyuki wrote: > (2012/07/20 8:34), Tim Chen wrote: > >Hi, > > > >I noticed in a multi-process parallel files reading benchmark I ran on a > >8 socket machine, throughput slowed down by a factor of 8 when I ran > >the benchmark within a cgroup container. I traced the problem to the > >following code path (see below) when we are trying to reclaim memory > >from file cache. The res_counter_uncharge function is called on every > >page that's reclaimed and created heavy lock contention. The patch > >below allows the reclaimed pages to be uncharged from the resource > >counter in batch and recovered the regression. > > > >Tim > > > > 40.67% usemem [kernel.kallsyms] [k] > > _raw_spin_lock > > | > > --- _raw_spin_lock > > | > > |--92.61%-- res_counter_uncharge > > | | > > | |--100.00%-- > > __mem_cgroup_uncharge_common > > | | | > > | | |--100.00%-- > > mem_cgroup_uncharge_cache_page > > | | | __remove_mapping > > | | | shrink_page_list > > | | | > > shrink_inactive_list > > | | | > > shrink_mem_cgroup_zone > > | | | shrink_zone > > | | | > > do_try_to_free_pages > > | | | try_to_free_pages > > | | | > > __alloc_pages_nodemask > > | | | > > alloc_pages_current > > > > > > Thank you very much !! > > When I added batching, I didn't touch page-reclaim path because it delays > res_counter_uncharge() and make more threads run into page reclaim. Isn't it really problem? It's same as global reclaim. In the short term, you might be right but batch free might prevent entering more into reclaim path in the long term because we get lots of free pages than nenessary one. And we can reduce lock overhead. If it is proved as real problem, maybe we need global reclaim, too. > But, from above score, bactching seems required. > > And because of current design of per-zone-per-memcg-LRU, batching > works very very wellall lru pages shrink_page_list() scans are on > the same memcg. Yes. It's more effective point! -- Kind regards, Minchan Kim -- 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: A question on printascii
Hi Shashidhar,
On Wed, Jul 18 2012, Shashidhar Hiremath wrote:
> I want to use printascii to debug my serial driver. How do I enable
> it and use the feature.
> Currently I have enabled in menuconfig and done an extern on the
> printascii api, this doesn't seem to work, So any hints for debugging
> serial drivers ?
Sounds like you want this patch, against linux-next:
diff --git a/kernel/printk.c b/kernel/printk.c
index 3991862..36abce8 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -45,6 +45,8 @@
#include
+extern void printascii(char *);
+
#define CREATE_TRACE_POINTS
#include
@@ -1542,6 +1544,8 @@ asmlinkage int vprintk_emit(int facility, int level,
*/
text_len = vscnprintf(text, sizeof(textbuf), fmt, args);
+ printascii(text);
+
/* mark and strip a trailing newline */
if (text_len && text[text_len-1] == '\n') {
text_len--;
--
Chris Ball
Re: [PATCH RT 00/12] [ANNOUNCE] 3.0.36-rt58-rc1 stable review
On Thu, 2012-07-19 at 10:02 -0400, Steven Rostedt wrote: > On Thu, 2012-07-19 at 15:51 +0200, Mike Galbraith wrote: > > > Every kernel I've fed you script to has died sooner or later, so I wish > > him fair sailing. Here there be sea monsters ;-) > > I'm curious. Can my script bring down a non-rt kernel? Yeah, it took a couple non-rt (and virgin) kernels down on my 64 core box. -Mike -- 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 5/9] KVM: MMU: fask check write-protect for direct mmu
BTW, they are some bug fix patches on -master branch, but it is not existed on -next branch: commit: f411930442e01f9cf1bf4df41ff7e89476575c4d commit: 85b7059169e128c57a3a8a3e588fb89cb2031da1 It causes code conflict if we do the development on -next. On 07/20/2012 08:39 AM, Marcelo Tosatti wrote:can > On Tue, Jul 17, 2012 at 09:53:29PM +0800, Xiao Guangrong wrote: >> If it have no indirect shadow pages we need not protect any gfn, >> this is always true for direct mmu without nested >> >> Signed-off-by: Xiao Guangrong > > Xiao, > > What is the motivation? Numbers please. > > In fact, what case was the original indirect_shadow_pages conditional in > kvm_mmu_pte_write optimizing again? > > > -- 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: linux-next: build failure after merge of the net-next tree
[Sent again due to problems with email client]
Hi,
On 07/20/2012 04:01 AM, Stephen Rothwell wrote:
Hi all,
After merging the net-next tree, today's linux-next build (powerpc
pmac32_defconfig) failed like this:
ERROR: "phy_disconnect" [drivers/net/usb/asix.ko] undefined!
ERROR: "phy_stop" [drivers/net/usb/asix.ko] undefined!
ERROR: "phy_ethtool_gset" [drivers/net/usb/asix.ko] undefined!
ERROR: "mdiobus_unregister" [drivers/net/usb/asix.ko] undefined!
ERROR: "phy_start_aneg" [drivers/net/usb/asix.ko] undefined!
ERROR: "phy_print_status" [drivers/net/usb/asix.ko] undefined!
ERROR: "phy_start" [drivers/net/usb/asix.ko] undefined!
ERROR: "mdiobus_free" [drivers/net/usb/asix.ko] undefined!
ERROR: "mdiobus_register" [drivers/net/usb/asix.ko] undefined!
ERROR: "genphy_resume" [drivers/net/usb/asix.ko] undefined!
ERROR: "phy_connect" [drivers/net/usb/asix.ko] undefined!
ERROR: "phy_mii_ioctl" [drivers/net/usb/asix.ko] undefined!
ERROR: "phy_ethtool_sset" [drivers/net/usb/asix.ko] undefined!
ERROR: "mdiobus_alloc_size" [drivers/net/usb/asix.ko] undefined!
Caused by commit 16626b0cc3d5 ("asix: Add a new driver for the AX88172A")
and reverting that commit fixes the build.
Sorry about that. I missed the dependency of the new driver on phylib. A
fix for this problem is already in net-next, see commit 215029375c83.
Thanks, Christian
Thanks to Mikey for reporting this porblem.
--
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: A question on printascii
I am working on ARM architecture. On Wed, Jul 18, 2012 at 9:33 PM, Randy Dunlap wrote: > On 07/18/2012 06:03 AM, Shashidhar Hiremath wrote: > >> HI, >> I want to use printascii to debug my serial driver. How do I enable >> it and use the feature. >> Currently I have enabled in menuconfig and done an extern on the >> printascii api, this doesn't seem to work, So any hints for debugging >> serial drivers ? >> > > > Enabled what/where in menuconfig? > > It looks like only a few CPU architecures or platforms > implement "printascii". What architecture/platform are you trying > to use it on? > > -- > ~Randy -- regards, Shashidhar Hiremath -- 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/
linux-next: build failure after merge of the tty tree
Hi Greg,
After merging the tty tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/staging/serqt_usb2/serqt_usb2.c: In function 'qt_set_termios':
drivers/staging/serqt_usb2/serqt_usb2.c:1198:29: error: incompatible types when
initializing type 'struct ktermios *' using type 'struct ktermios'
drivers/staging/serqt_usb2/serqt_usb2.c:1304:14: error: invalid type argument
of '->' (have 'struct ktermios')
Presumably caused by commit adc8d746caa6 ("tty: move the termios object
into the tty").
Under previous instructions about staging drivers, I have added the
following patch for today:
From: Stephen Rothwell
Date: Fri, 20 Jul 2012 13:31:39 +1000
Subject: [PATCH] disable USB_SERIAL_QUATECH2 broken by tty update
Signed-off-by: Stephen Rothwell
---
drivers/staging/serqt_usb2/Kconfig |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/serqt_usb2/Kconfig
b/drivers/staging/serqt_usb2/Kconfig
index f4fed40..dc624a4 100644
--- a/drivers/staging/serqt_usb2/Kconfig
+++ b/drivers/staging/serqt_usb2/Kconfig
@@ -1,6 +1,7 @@
config USB_SERIAL_QUATECH2
tristate "USB Quatech ESU-100 8 Port Serial Driver"
depends on USB_SERIAL
+ depends on BROKEN
help
Say Y here if you want to use the Quatech ESU-100 8 port usb to
serial adapter.
--
1.7.10.280.gaa39
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp3hVZJRzjmm.pgp
Description: PGP signature
linux-next: build failure after merge of the tty tree
Hi Greg,
After merging the tty tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/staging/ipack/devices/ipoctal.c: In function 'ipoctal_set_termios':
drivers/staging/ipack/devices/ipoctal.c:614:22: error: invalid type argument of
'->' (have 'struct ktermios')
drivers/staging/ipack/devices/ipoctal.c:640:15: error: invalid type argument of
'->' (have 'struct ktermios')
drivers/staging/ipack/devices/ipoctal.c:654:14: error: invalid type argument of
'->' (have 'struct ktermios')
drivers/staging/ipack/devices/ipoctal.c:691:2: error: incompatible type for
argument 1 of 'tty_termios_encode_baud_rate'
include/linux/tty.h:449:13: note: expected 'struct ktermios *' but argument is
of type 'struct ktermios'
drivers/staging/ipack/devices/ipoctal.c:694:22: error: invalid type argument of
'->' (have 'struct ktermios')
drivers/staging/ipack/devices/ipoctal.c:735:3: error: incompatible type for
argument 1 of 'tty_termios_encode_baud_rate'
include/linux/tty.h:449:13: note: expected 'struct ktermios *' but argument is
of type 'struct ktermios'
Presumably caused by commit adc8d746caa6 ("tty: move the termios object
into the tty").
Under previous instructions about staging drivers, I have added the
following patch for today:
From c4bc70a8fc9cc687690aaf51865561ffcd6190f9 Mon Sep 17 00:00:00 2001
From: Stephen Rothwell
Date: Fri, 20 Jul 2012 13:25:12 +1000
Subject: [PATCH] disable SERIAL_IPOCTAL broken by tty updates
Signed-off-by: Stephen Rothwell
---
drivers/staging/ipack/devices/Kconfig |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/ipack/devices/Kconfig
b/drivers/staging/ipack/devices/Kconfig
index 39f7188..8d69ce3 100644
--- a/drivers/staging/ipack/devices/Kconfig
+++ b/drivers/staging/ipack/devices/Kconfig
@@ -1,6 +1,7 @@
config SERIAL_IPOCTAL
tristate "IndustryPack IP-OCTAL uart support"
depends on IPACK_BUS
+ depends on BROKEN
help
This driver supports the IPOCTAL serial port device for the
IndustryPack bus.
default n
--
1.7.10.280.gaa39
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpT6B2nAiKul.pgp
Description: PGP signature
Re: [PATCH] Cgroup: Fix memory accounting scalability in shrink_page_list
(2012/07/20 8:34), Tim Chen wrote:
Hi,
I noticed in a multi-process parallel files reading benchmark I ran on a
8 socket machine, throughput slowed down by a factor of 8 when I ran
the benchmark within a cgroup container. I traced the problem to the
following code path (see below) when we are trying to reclaim memory
from file cache. The res_counter_uncharge function is called on every
page that's reclaimed and created heavy lock contention. The patch
below allows the reclaimed pages to be uncharged from the resource
counter in batch and recovered the regression.
Tim
40.67% usemem [kernel.kallsyms] [k]
_raw_spin_lock
|
--- _raw_spin_lock
|
|--92.61%-- res_counter_uncharge
| |
| |--100.00%-- __mem_cgroup_uncharge_common
| | |
| | |--100.00%--
mem_cgroup_uncharge_cache_page
| | | __remove_mapping
| | | shrink_page_list
| | | shrink_inactive_list
| | |
shrink_mem_cgroup_zone
| | | shrink_zone
| | | do_try_to_free_pages
| | | try_to_free_pages
| | |
__alloc_pages_nodemask
| | | alloc_pages_current
Thank you very much !!
When I added batching, I didn't touch page-reclaim path because it delays
res_counter_uncharge() and make more threads run into page reclaim.
But, from above score, bactching seems required.
And because of current design of per-zone-per-memcg-LRU, batching
works very very wellall lru pages shrink_page_list() scans are on
the same memcg.
BTW, it's better to show 'how much improved' in patch description..
---
Signed-off-by: Tim Chen
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 33dc256..aac5672 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -779,6 +779,7 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
cond_resched();
+ mem_cgroup_uncharge_start();
while (!list_empty(page_list)) {
enum page_references references;
struct address_space *mapping;
@@ -1026,6 +1027,7 @@ keep_lumpy:
list_splice(_pages, page_list);
count_vm_events(PGACTIVATE, pgactivate);
+ mem_cgroup_uncharge_end();
I guess placing mem_cgroup_uncharge_end() just after the loop may be better
looking.
Anyway,
Acked-by: KAMEZAWA Hiroyuki
But please show 'how much improved' in patch description.
Thanks,
-Kame
--
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/
[PATCH v3] perf: prevent overflow in size calculation
A large enough symbol size causes an overflow in the size parameter to the
histogram allocation, leading to a segfault in symbol__inc_addr_samples later
on when this histogram is accessed.
In the case of being called via perf-report, this returns back and
gracefully ignores the sample, eventually ignoring the chained return
value of perf_session_deliver_event in flush_sample_queue.
Signed-off-by: Cody Schafer
---
tools/perf/util/annotate.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 8069dfb..d88693e 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -426,7 +426,18 @@ int symbol__alloc_hist(struct symbol *sym)
{
struct annotation *notes = symbol__annotation(sym);
const size_t size = symbol__size(sym);
- size_t sizeof_sym_hist = (sizeof(struct sym_hist) + size * sizeof(u64));
+ size_t sizeof_sym_hist;
+
+ /* Check for overflow when calculating sizeof_sym_hist */
+ if (size > (SIZE_MAX - sizeof(struct sym_hist)) / sizeof(u64))
+ return -1;
+
+ sizeof_sym_hist = (sizeof(struct sym_hist) + size * sizeof(u64));
+
+ /* Check for overflow in zalloc argument */
+ if (sizeof_sym_hist > (SIZE_MAX - sizeof(*notes->src))
+ / symbol_conf.nr_events)
+ return -1;
notes->src = zalloc(sizeof(*notes->src) + symbol_conf.nr_events *
sizeof_sym_hist);
if (notes->src == NULL)
--
1.7.9.5
--
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: [RFC][PATCH v2 2/3] Hold multiple logs
On Fri, Jul 20, 2012 at 12:39:24AM +, Seiji Aguchi wrote: > > Thank you for describing this in detail. > > > Yes - if the OOPs is instrumental in the path leading to the hang/panic - > > then the OOPS is the first place to look for the root cause of > > the problem. But it will be a case by case analysis. > > Sometimes the OOPS might be unconnected. If possible we'd like to log more > > information to allow detective work to decide whether > > there is a connection. But as I mentioned above there are severe limits to > > how much better things are by storing more information. > > I understand the reason why you think 3 or 4 logs are reasonable. > There are some cases 2nd or 3rd oops is critical > > I have some enterprise customers who are sensitive for a software failure > and specify panic_on_oops=1. > In this case, they don't need 3,4 logs. 2 logs are enough. > > So, kernel parameter should be as follows. > > Log_num =1 > - For users who want to hold just one log. > > Log_num=2 > - For users who can handle multiple logs and 1st oops is concerned. (by > specifying panic_on_oops=1) > > Log_num=3,4 > - for users who care about 2nd or 3rd oops. > > Log_num=5 or more > Invalid value. What is the harm of not using this and just letting the number be infinite (or until EFI runs out of space)? Is it a big deal if extra failures are logged? The hope would be a daemon would clear the old logs out and you never run out of space. Cheers, Don -- 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/
[PATCH] atl1c: fix issue of io access mode for AR8152 v2.1
When io access mode is enabled by BOOTROM or BIOS for AR8152 v2.1,
the register can't be read/write by memory access mode.
Clearing Bit 8 of Register 0x21c could fixed the issue.
Signed-off-by: Cloud Ren
Cc: stable
Signed-off-by: xiong
---
drivers/net/ethernet/atheros/atl1c/atl1c_hw.h |5 +
drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 16 +++-
2 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_hw.h
b/drivers/net/ethernet/atheros/atl1c/atl1c_hw.h
index 17d935b..21d8c4d 100644
--- a/drivers/net/ethernet/atheros/atl1c/atl1c_hw.h
+++ b/drivers/net/ethernet/atheros/atl1c/atl1c_hw.h
@@ -74,6 +74,8 @@ void atl1c_post_phy_linkchg(struct atl1c_hw *hw, u16
link_speed);
#define PCI_DEVICE_ID_ATHEROS_L1D_2_0 0x1083 /* AR8151 v2.0 Gigabit 1000 */
#define L2CB_V10 0xc0
#define L2CB_V11 0xc1
+#define L2CB_V20 0xc0
+#define L2CB_V21 0xc1
/* register definition */
#define REG_DEVICE_CAP 0x5C
@@ -87,6 +89,9 @@ void atl1c_post_phy_linkchg(struct atl1c_hw *hw, u16
link_speed);
#define LINK_CTRL_L1_EN0x02
#define LINK_CTRL_EXT_SYNC 0x80
+#define REG_PCIE_IND_ACC_ADDR 0x80
+#define REG_PCIE_IND_ACC_DATA 0x84
+
#define REG_DEV_SERIALNUM_CTRL 0x200
#define REG_DEV_MAC_SEL_MASK 0x0 /* 0:EUI; 1:MAC */
#define REG_DEV_MAC_SEL_SHIFT 0
diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
index 36d3783..1bf5bbf 100644
--- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
+++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
@@ -727,6 +727,8 @@ static const struct atl1c_platform_patch plats[]
__devinitdata = {
static void __devinit atl1c_patch_assign(struct atl1c_hw *hw)
{
+ struct pci_dev *pdev = hw->adapter->pdev;
+ u32 misc_ctrl;
int i = 0;
hw->msi_lnkpatch = false;
@@ -741,6 +743,18 @@ static void __devinit atl1c_patch_assign(struct atl1c_hw
*hw)
}
i++;
}
+
+ if (hw->device_id == PCI_DEVICE_ID_ATHEROS_L2C_B2 &&
+ hw->revision_id == L2CB_V21) {
+ /* config acess mode */
+ pci_write_config_dword(pdev, REG_PCIE_IND_ACC_ADDR,
+ REG_PCIE_DEV_MISC_CTRL);
+ pci_read_config_dword(pdev, REG_PCIE_IND_ACC_DATA, _ctrl);
+ misc_ctrl &= ~0x100;
+ pci_write_config_dword(pdev, REG_PCIE_IND_ACC_ADDR,
+ REG_PCIE_DEV_MISC_CTRL);
+ pci_write_config_dword(pdev, REG_PCIE_IND_ACC_DATA, misc_ctrl);
+ }
}
/**
* atl1c_sw_init - Initialize general software structures (struct
atl1c_adapter)
@@ -768,7 +782,7 @@ static int __devinit atl1c_sw_init(struct atl1c_adapter
*adapter)
hw->device_id = pdev->device;
hw->subsystem_vendor_id = pdev->subsystem_vendor;
hw->subsystem_id = pdev->subsystem_device;
- AT_READ_REG(hw, PCI_CLASS_REVISION, );
+ pci_read_config_dword(pdev, PCI_CLASS_REVISION, );
hw->revision_id = revision & 0xFF;
/* before link up, we assume hibernate is true */
hw->hibernate = true;
--
1.5.4.5
--
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 08/10] KVM: introduce readonly_bad_hva
On 07/19/2012 06:16 PM, Avi Kivity wrote:
> On 07/17/2012 05:45 PM, Xiao Guangrong wrote:
>> In the later patch, it indicates failure when we try to get a writable
>> hva from the readonly slot
>>
>> Signed-off-by: Xiao Guangrong
>> ---
>> virt/kvm/kvm_main.c | 12 +++-
>> 1 files changed, 11 insertions(+), 1 deletions(-)
>>
>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>> index b70f1a4..c056736 100644
>> --- a/virt/kvm/kvm_main.c
>> +++ b/virt/kvm/kvm_main.c
>> @@ -994,9 +994,19 @@ static inline unsigned long bad_hva(void)
>> return PAGE_OFFSET;
>> }
>>
>> +static inline unsigned long readonly_bad_hva(void)
>> +{
>> +return PAGE_OFFSET + PAGE_SIZE;
>> +}
>> +
>> +static int kvm_is_readonly_bad_hva(unsigned long addr)
>> +{
>> +return addr == readonly_bad_hva();
>> +}
>> +
>> int kvm_is_error_hva(unsigned long addr)
>> {
>> -return addr == bad_hva();
>> +return addr == bad_hva() || kvm_is_readonly_bad_hva(addr);
>> }
>
> addr >= PAGE_OFFSET. Or change it to use -E*.
I prefer to the first one, addr >= PAGE_OFFSET, all virtual addresses
between 0 and (~0ULL) are valid, Using PAGE_OFFSET is more readable.
[ is_error_pfn is suitable to use -err because the the range of physical
address is always limited, for example, 0 ~ 64G on x86.]
--
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 v2] perf: prevent overflow in size calculation
struct annotation *notes = symbol__annotation(sym); const size_t size = symbol__size(sym); - size_t sizeof_sym_hist = (sizeof(struct sym_hist) + size * sizeof(u64)); + size_t sizeof_sym_hist; + + /* Check for overflow when calculating sizeof_sym_hist */ + if (size > (SIZE_MAX / sizeof(u64) - sizeof(struct sym_hist))) + return -1; + + sizeof_sym_hist = (sizeof(struct sym_hist) + size * sizeof(u64)); + + /* Check for overflow in zalloc argument */ + if (sizeof_sym_hist > (SIZE_MAX / symbol_conf.nr_events + - sizeof(*notes->src))) + return -1; notes->src = zalloc(sizeof(*notes->src) + symbol_conf.nr_events * sizeof_sym_hist); if (notes->src == NULL) Actually, I don't think this is correct either (subtraction seems to occur in the wrong spot). -- 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 07/10] KVM: introduce readonly_fault_pfn
On 07/19/2012 06:15 PM, Avi Kivity wrote:
> On 07/17/2012 05:44 PM, Xiao Guangrong wrote:
>> Introduce readonly_fault_pfn, in the later patch, it indicates failure
>> when we try to get a writable pfn from the readonly memslot
>>
>> +
>> inline int kvm_is_mmio_pfn(pfn_t pfn)
>> {
>> if (pfn_valid(pfn)) {
>> @@ -949,13 +952,15 @@ EXPORT_SYMBOL_GPL(kvm_disable_largepages);
>>
>> int is_error_page(struct page *page)
>> {
>> -return page == bad_page || page == hwpoison_page || page == fault_page;
>> +return page == bad_page || page == hwpoison_page || page == fault_page
>> +|| page == readonly_fault_page;
>
> All those checks are slow, and get_page(fault_page) etc. isn't very
> scalable.
>
> We should move to ERR_PTR() etc. We could use ENOENT, EHWPOISON,
> EFAULT, and EROFS for the above, or maybe there are better matches.
>
Good point. I will do it in the next version, thank you, Avi!
--
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/
[RESEND PATCH] [CPUFREQ] EXYNOS: bugfix on retrieving old_index from freqs.old
From: Jonghwa Lee
The policy might have been changed since last call of target().
Thus, using cpufreq_frequency_table_target(), which depends on
policy to find the corresponding index from a frequency, may return
inconsistent index for freqs.old. Thus, old_index should be
calculated not based on the current policy.
We have been observing such issue when scaling_min/max_freq were
updated and sometimes cuased system lockups deu to incorrectly
configured voltages.
Signed-off-by: MyungJoo Ham
---
drivers/cpufreq/exynos-cpufreq.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index b243a7e..af2d81e 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -62,8 +62,18 @@ static int exynos_target(struct cpufreq_policy *policy,
goto out;
}
- if (cpufreq_frequency_table_target(policy, freq_table,
- freqs.old, relation, _index)) {
+ /*
+* The policy max have been changed so that we cannot get proper
+* old_index with cpufreq_frequency_table_target(). Thus, ignore
+* policy and get the index from the raw freqeuncy table.
+*/
+ for (old_index = 0;
+ freq_table[old_index].frequency != CPUFREQ_TABLE_END;
+ old_index++)
+ if (freq_table[old_index].frequency == freqs.old)
+ break;
+
+ if (freq_table[old_index].frequency == CPUFREQ_TABLE_END) {
ret = -EINVAL;
goto out;
}
--
1.7.4.1
--
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] perf: prevent overflow in size calculation
+ /* Check for overflow when calculating sizeof_sym_hist */ + if (size > (SIZE_MAX / sizeof(u64))) + return -1; How does it guarantee that the end result which used in zalloc below would not overflow? + + sizeof_sym_hist = (sizeof(struct sym_hist) + size * sizeof(u64)); notes->src = zalloc(sizeof(*notes->src) + symbol_conf.nr_events * sizeof_sym_hist); if (notes->src == NULL) return -1; Whoops. Thanks for pointing that out. I've sent a fixed up patch (the check for sizeof_sym_hist wasn't even complete) -- Cody -- 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/
[PATCH v2] perf: prevent overflow in size calculation
A large enough symbol size causes an overflow in the size parameter to the
histogram allocation, leading to a segfault in symbol__inc_addr_samples later
on when this histogram is accessed.
In the case of being called via perf-report, this returns back and
gracefully ignores the sample, eventually ignoring the chained return
value of perf_session_deliver_event in flush_sample_queue.
Signed-off-by: Cody Schafer
---
tools/perf/util/annotate.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 8069dfb..73a1919 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -426,7 +426,18 @@ int symbol__alloc_hist(struct symbol *sym)
{
struct annotation *notes = symbol__annotation(sym);
const size_t size = symbol__size(sym);
- size_t sizeof_sym_hist = (sizeof(struct sym_hist) + size * sizeof(u64));
+ size_t sizeof_sym_hist;
+
+ /* Check for overflow when calculating sizeof_sym_hist */
+ if (size > (SIZE_MAX / sizeof(u64) - sizeof(struct sym_hist)))
+ return -1;
+
+ sizeof_sym_hist = (sizeof(struct sym_hist) + size * sizeof(u64));
+
+ /* Check for overflow in zalloc argument */
+ if (sizeof_sym_hist > (SIZE_MAX / symbol_conf.nr_events
+ - sizeof(*notes->src)))
+ return -1;
notes->src = zalloc(sizeof(*notes->src) + symbol_conf.nr_events *
sizeof_sym_hist);
if (notes->src == NULL)
--
1.7.9.5
--
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: linux-next: build failure after merge of the net-next tree
On Fri, 20 Jul 2012 12:01:18 +1000 Stephen Rothwell
wrote:
>
> After merging the net-next tree, today's linux-next build (powerpc
> pmac32_defconfig) failed like this:
This was actually yesterday's linux-next - I guess it is fixed by commit
215029375c83 ("asix: AX88172A driver depends on phylib") in today's tree.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpZvcImO0oyn.pgp
Description: PGP signature
Re: [RFC] Simplifying kernel configuration for distro issues
On Thu, 19 Jul 2012, Ben Hutchings wrote: On Thu, Jul 19, 2012 at 06:30:47PM +0100, Alan Cox wrote: For the end user case you need the distro to plonk the right file in the right place and be done with it, once they do that the rest is bikeshedding a ten line Makefile rule. This might work well for future releases; is there not a need to make this work for past releases too? This approach can work for any 3.x kernel version with any distro. The distro provides the file, with a new kernel version you do "make distconfig', with something prior to when this is added you do 'cp /etc/kconfig/filename .config ; make oldconfig' instead. the make oldconfig papers over a LOT of differences between the kernel that the distro built with and the kernel the user is trying to compile. David Lang -- 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 5/9] KVM: MMU: fask check write-protect for direct mmu
On 07/20/2012 08:39 AM, Marcelo Tosatti wrote: > On Tue, Jul 17, 2012 at 09:53:29PM +0800, Xiao Guangrong wrote: >> If it have no indirect shadow pages we need not protect any gfn, >> this is always true for direct mmu without nested >> >> Signed-off-by: Xiao Guangrong > > Xiao, > > What is the motivation? Numbers please. > mmu_need_write_protect is the common path for both soft-mmu and hard-mmu, checking indirect_shadow_pages can skip hash-table walking for the case which is tdp is enabled without nested guest. I will post the Number after I do the performance test. > In fact, what case was the original indirect_shadow_pages conditional in > kvm_mmu_pte_write optimizing again? > They are the different paths, mmu_need_write_protect is the real page fault path, and kvm_mmu_pte_write is caused by mmio emulation. -- 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/
Stack overrun in 3.5.0-rc7 w/ cfq
I got this oops & stack overrun warning while running mkfs.ext4 on a sparse 4T file hosted on xfs. Should CFQ be issuing IO here? -Eric [10821.639839] BUG: unable to handle kernel paging request at fffb900148a0 [10821.640820] IP: [] cpuacct_charge+0xb4/0x210 [10821.640820] PGD 1c0d067 PUD 0 [10821.640820] Thread overran stack, or stack corrupted [10821.640820] Oops: [#1] SMP [10821.640820] CPU 1 [10821.640820] Modules linked in:[10821.640820] xfs sunrpc ip6table_filter ip6_tables binfmt_misc vhost_net macvtap macvlan tun iTCO_wdt iTCO_vendor_support dcdbas microcode i2c_i801 lpc_ich mfd_core tg3 shpchp i3000_edac edac_core ext3 jbd mbcache ata_generic pata_acpi pata_sil680 radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan] [10821.640820] Pid: 2914, comm: flush-8:16 Not tainted 3.5.0-rc7+ #65 Dell Computer Corporation PowerEdge 860/0RH817 [10821.640820] RIP: 0010:[] [] cpuacct_charge+0xb4/0x210 [10821.640820] RSP: 0018:88007d003d58 EFLAGS: 00010082 [10821.640820] RAX: 001d6fe8 RBX: 000b67c5 RCX: 0003 [10821.640820] RDX: 0001 RSI: 81c2fae0 RDI: 0046 [10821.640820] RBP: 88007d003d88 R08: 0003 R09: 0001 [10821.640820] R10: 0001 R11: 0004 R12: 88007b8d [10821.640820] R13: 81c60ee0 R14: 820f7d40 R15: 0153b050614b [10821.640820] FS: () GS:88007d00() knlGS: [10821.640820] CS: 0010 DS: ES: CR0: 8005003b [10821.640820] CR2: fffb900148a0 CR3: 7a3ab000 CR4: 07e0 [10821.640820] DR0: DR1: DR2: [10821.640820] DR3: DR6: 0ff0 DR7: 0400 [10821.640820] Process flush-8:16 (pid: 2914, threadinfo 88007981a000, task 88007b8d) [10821.640820] Stack: [10821.640820] 810a0978 1dcd6500 88007d1d42b8 000b67c5 [10821.640820] 88007b8d0048 88007b8d 88007d003dc8 810a82ef [10821.640820] 81810920 88007d1d42b8 88007b8d0048 [10821.640820] Call Trace: [10821.640820] [10821.640820] [] ? cpuacct_charge+0x28/0x210 [10821.640820] [] update_curr+0x13f/0x220 [10821.640820] [] task_tick_fair+0xbd/0x140 [10821.640820] [] scheduler_tick+0xde/0x150 [10821.640820] [] update_process_times+0x6e/0x90 [10821.640820] [] tick_sched_timer+0x66/0xc0 [10821.640820] [] __run_hrtimer+0x83/0x320 [10821.640820] [] ? tick_nohz_handler+0x100/0x100 [10821.640820] [] hrtimer_interrupt+0x106/0x280 [10821.640820] [] ? sched_clock_local+0x25/0x90 [10821.640820] [] smp_apic_timer_interrupt+0x69/0x99 [10821.640820] [] apic_timer_interrupt+0x6f/0x80 [10821.640820] [10821.640820] [] ? _raw_spin_unlock_irq+0x34/0x50 [10821.640820] [] scsi_request_fn+0xc8/0x5b0 [10821.640820] [] __blk_run_queue+0x1e/0x20 [10821.640820] [] cfq_insert_request+0x398/0x720 [10821.640820] [] ? cfq_insert_request+0x4c/0x720 [10821.640820] [] ? attempt_merge+0x21/0x520 [10821.640820] [] ? ftrace_call+0x5/0x2b [10821.640820] [] __elv_add_request+0x220/0x2e0 [10821.640820] [] blk_flush_plug_list+0x1a4/0x260 [10821.640820] [] schedule+0x50/0x70 [10821.640820] [] schedule_timeout+0x315/0x410 [10821.640820] [] ? mark_held_locks+0x8d/0x140 [10821.640820] [] ? _raw_spin_unlock_irq+0x30/0x50 [10821.640820] [] ? trace_hardirqs_on_caller+0x105/0x190 [10821.640820] [] wait_for_common+0x12b/0x180 [10821.640820] [] ? try_to_wake_up+0x2e0/0x2e0 [10821.640820] [] ? ftrace_call+0x5/0x2b [10821.640820] [] ? _xfs_buf_read+0x41/0x50 [xfs] [10821.640820] [] ? xfs_trans_read_buf+0x325/0x610 [xfs] [10821.640820] [] wait_for_completion+0x1d/0x20 [10821.640820] [] xfs_buf_iowait+0xc5/0x1b0 [xfs] [10821.640820] [] _xfs_buf_read+0x41/0x50 [xfs] [10821.640820] [] xfs_buf_read+0x113/0x170 [xfs] [10821.640820] [] xfs_trans_read_buf+0x325/0x610 [xfs] [10821.640820] [] xfs_btree_read_buf_block+0x5e/0xd0 [xfs] [10821.640820] [] ? ftrace_call+0x5/0x2b [10821.640820] [] xfs_btree_lookup_get_block+0x81/0xf0 [xfs] [10821.640820] [] ? xfs_btree_ptr_offset+0x4c/0x90 [xfs] [10821.640820] [] xfs_btree_lookup+0xbf/0x470 [xfs] [10821.640820] [] ? ftrace_call+0x5/0x2b [10821.640820] [] xfs_alloc_lookup_eq+0x19/0x20 [xfs] [10821.640820] [] xfs_alloc_fixup_trees+0x269/0x340 [xfs] [10821.640820] [] xfs_alloc_ag_vextent_near+0x852/0xe10 [xfs] [10821.640820] [] xfs_alloc_ag_vextent+0xd5/0x100 [xfs] [10821.640820] [] __xfs_alloc_vextent+0x57a/0x7b0 [xfs] [10821.640820] [] ? lockdep_init_map+0x59/0x150 [10821.640820] [] xfs_alloc_vextent+0x198/0x1a0 [xfs] [10821.640820] [] xfs_bmbt_alloc_block+0xdb/0x210 [xfs] [10821.640820] [] xfs_btree_split+0xbd/0x710 [xfs] [10821.640820] [] ? ftrace_call+0x5/0x2b [10821.640820] [] xfs_btree_make_block_unfull+0x12d/0x190 [xfs] [10821.640820] [] xfs_btree_insrec+0x3ef/0x5a0
Re: [PATCH 3/9] KVM: x86: introduce set_mmio_exit_info
On 07/20/2012 08:03 AM, Marcelo Tosatti wrote: > On Tue, Jul 17, 2012 at 09:52:13PM +0800, Xiao Guangrong wrote: >> Introduce set_mmio_exit_info to cleanup the common code >> >> Signed-off-by: Xiao Guangrong >> --- >> arch/x86/kvm/x86.c | 33 + >> 1 files changed, 17 insertions(+), 16 deletions(-) > > This makes the code less readable IMO. The fragments are small enough > already. > I think the function name set_mmio_exit_info has the better explanation - it generates a mmio-exit from the specified fragment. Actually, the later patchset, readonly memeslot will set a new member in the mmio-exit-info: run->mmio.write_readonly_mem = frag->write_readonly_mem; If we wrap this operation up, i think the code should be neater. :) -- 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 6/8] vfs: Make sys_sync writeout also block device inodes
Hi Al,
Would you please fold the below fix to commit 5c781a65fff ("vfs:
Create function for iterating over block devices")?
Thanks,
Fengguang
---
Subject: [PATCH] sync: fix build error on iterate_bdevs()
fs/sync.c:110:2: error: implicit declaration of function 'iterate_bdevs'
---
include/linux/fs.h |4
1 file changed, 4 insertions(+)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index ef839a7..b62af06 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2124,6 +2124,10 @@ static inline int thaw_bdev(struct block_device *bdev,
struct super_block *sb)
{
return 0;
}
+
+static inline void iterate_bdevs(void (*func)(struct block_device *, void *),
void *arg)
+{
+}
#endif
extern int sync_filesystem(struct super_block *);
extern const struct file_operations def_blk_fops;
--
1.7.10
--
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 2/9] KVM: x86: simplify read_emulated
On 07/20/2012 07:58 AM, Marcelo Tosatti wrote:
>> -}
>> +rc = ctxt->ops->read_emulated(ctxt, addr, mc->data + mc->end, size,
>> + >exception);
>> +if (rc != X86EMUL_CONTINUE)
>> +return rc;
>> +
>> +mc->end += size;
>> +
>> +read_cached:
>> +memcpy(dest, mc->data + mc->pos, size);
>
> What prevents read_emulated(size > 8) call, with
> mc->pos == (mc->end - 8) now?
Marcelo,
The splitting has been done in emulator_read_write_onepage:
while (bytes) {
unsigned now = min(bytes, 8U);
frag = >mmio_fragments[vcpu->mmio_nr_fragments++];
frag->gpa = gpa;
frag->data = val;
frag->len = now;
frag->write_readonly_mem = (ret == -EPERM);
gpa += now;
val += now;
bytes -= now;
}
So i think it is safe to remove the splitting in read_emulated.
--
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/
linux-next: build failure after merge of the net-next tree
Hi all,
After merging the net-next tree, today's linux-next build (powerpc
pmac32_defconfig) failed like this:
ERROR: "phy_disconnect" [drivers/net/usb/asix.ko] undefined!
ERROR: "phy_stop" [drivers/net/usb/asix.ko] undefined!
ERROR: "phy_ethtool_gset" [drivers/net/usb/asix.ko] undefined!
ERROR: "mdiobus_unregister" [drivers/net/usb/asix.ko] undefined!
ERROR: "phy_start_aneg" [drivers/net/usb/asix.ko] undefined!
ERROR: "phy_print_status" [drivers/net/usb/asix.ko] undefined!
ERROR: "phy_start" [drivers/net/usb/asix.ko] undefined!
ERROR: "mdiobus_free" [drivers/net/usb/asix.ko] undefined!
ERROR: "mdiobus_register" [drivers/net/usb/asix.ko] undefined!
ERROR: "genphy_resume" [drivers/net/usb/asix.ko] undefined!
ERROR: "phy_connect" [drivers/net/usb/asix.ko] undefined!
ERROR: "phy_mii_ioctl" [drivers/net/usb/asix.ko] undefined!
ERROR: "phy_ethtool_sset" [drivers/net/usb/asix.ko] undefined!
ERROR: "mdiobus_alloc_size" [drivers/net/usb/asix.ko] undefined!
Caused by commit 16626b0cc3d5 ("asix: Add a new driver for the AX88172A")
and reverting that commit fixes the build.
Thanks to Mikey for reporting this porblem.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpe2ps9Bw9pP.pgp
Description: PGP signature
[PATCH] cpufreq: Fix sysfs deadlock with concurrent hotplug/frequency switch
Running one program that continuously hotplugs and replugs a cpu
concurrently with another program that continuously writes to the
scaling_setspeed node eventually deadlocks with:
=
[ INFO: possible recursive locking detected ]
3.4.0 #37 Tainted: GW
-
filemonkey/122 is trying to acquire lock:
(s_active#13){.+}, at: [] sysfs_remove_dir+0x9c/0xb4
but task is already holding lock:
(s_active#13){.+}, at: [] sysfs_write_file+0xe8/0x140
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(s_active#13);
lock(s_active#13);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by filemonkey/122:
#0: (>mutex){+.+.+.}, at: [] sysfs_write_file+0x28/0x140
#1: (s_active#13){.+}, at: [] sysfs_write_file+0xe8/0x140
stack backtrace:
[] (unwind_backtrace+0x0/0x120) from []
(validate_chain+0x6f8/0x1054)
[] (validate_chain+0x6f8/0x1054) from []
(__lock_acquire+0x81c/0x8d8)
[] (__lock_acquire+0x81c/0x8d8) from []
(lock_acquire+0x18c/0x1e8)
[] (lock_acquire+0x18c/0x1e8) from []
(sysfs_addrm_finish+0xd0/0x180)
[] (sysfs_addrm_finish+0xd0/0x180) from []
(sysfs_remove_dir+0x9c/0xb4)
[] (sysfs_remove_dir+0x9c/0xb4) from []
(kobject_del+0x10/0x38)
[] (kobject_del+0x10/0x38) from []
(kobject_release+0xf0/0x194)
[] (kobject_release+0xf0/0x194) from []
(cpufreq_cpu_put+0xc/0x24)
[] (cpufreq_cpu_put+0xc/0x24) from [] (store+0x6c/0x74)
[] (store+0x6c/0x74) from [] (sysfs_write_file+0x10c/0x140)
[] (sysfs_write_file+0x10c/0x140) from []
(vfs_write+0xb0/0x128)
[] (vfs_write+0xb0/0x128) from [] (sys_write+0x3c/0x68)
[] (sys_write+0x3c/0x68) from [] (ret_fast_syscall+0x0/0x3c)
This is because store() in cpufreq.c indirectly calls
kobject_get() via cpufreq_cpu_get() and is the last one to call
kobject_put() via cpufreq_cpu_put(). Sysfs code should not call
kobject_get() or kobject_put() directly (see the comment around
sysfs_schedule_callback() for more information).
Fix this deadlock by introducing two new functions:
struct cpufreq_policy *cpufreq_cpu_get_sysfs(unsigned int cpu)
void cpufreq_cpu_put_sysfs(struct cpufreq_policy *data)
which do the same thing as cpufreq_cpu_{get,put}() but don't call
kobject functions.
To easily trigger this deadlock you can apply a one line patch to
the store() function in cpufreq.c
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index a290771..62af12d 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -675,6 +675,7 @@ static ssize_t store(struct kobject *kobj
unlock_policy_rwsem_write(policy->cpu);
fail:
+ msleep(1);
cpufreq_cpu_put_sysfs(policy);
no_policy:
return ret;
and then write scaling_setspeed in one task and offline the cpu
in another. The first task will hang and be detected by the hung
task detector.
Signed-off-by: Stephen Boyd
---
Before you ask, I've seen the comment above cpufreq_add_dev() about
concurrent hotplug/cpufreq.
drivers/cpufreq/cpufreq.c | 35 +++
1 file changed, 27 insertions(+), 8 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 7f2f149..a290771 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -138,7 +138,7 @@ void disable_cpufreq(void)
static LIST_HEAD(cpufreq_governor_list);
static DEFINE_MUTEX(cpufreq_governor_mutex);
-struct cpufreq_policy *cpufreq_cpu_get(unsigned int cpu)
+static struct cpufreq_policy *__cpufreq_cpu_get(unsigned int cpu, int sysfs)
{
struct cpufreq_policy *data;
unsigned long flags;
@@ -162,7 +162,7 @@ struct cpufreq_policy *cpufreq_cpu_get(unsigned int cpu)
if (!data)
goto err_out_put_module;
- if (!kobject_get(>kobj))
+ if (!sysfs && !kobject_get(>kobj))
goto err_out_put_module;
spin_unlock_irqrestore(_driver_lock, flags);
@@ -175,16 +175,35 @@ err_out_unlock:
err_out:
return NULL;
}
+
+struct cpufreq_policy *cpufreq_cpu_get(unsigned int cpu)
+{
+ return __cpufreq_cpu_get(cpu, 0);
+}
EXPORT_SYMBOL_GPL(cpufreq_cpu_get);
+static struct cpufreq_policy *cpufreq_cpu_get_sysfs(unsigned int cpu)
+{
+ return __cpufreq_cpu_get(cpu, 1);
+}
-void cpufreq_cpu_put(struct cpufreq_policy *data)
+static void __cpufreq_cpu_put(struct cpufreq_policy *data, int sysfs)
{
- kobject_put(>kobj);
+ if (!sysfs)
+ kobject_put(>kobj);
module_put(cpufreq_driver->owner);
}
+
+void cpufreq_cpu_put(struct cpufreq_policy *data)
+{
+ __cpufreq_cpu_put(data, 0);
+}
EXPORT_SYMBOL_GPL(cpufreq_cpu_put);
+static void cpufreq_cpu_put_sysfs(struct cpufreq_policy *data)
+{
+ __cpufreq_cpu_put(data, 1);
+}
/*
*EXTERNALLY AFFECTING
Re: [PATCH 2/2] cpumask: cpumask_scnprintf() comments correction
On 07/16/2012 04:29 PM, Alex Shi wrote: > On 07/16/2012 03:40 PM, Rusty Russell wrote: > >> On Mon, 16 Jul 2012 10:35:54 +0800, Alex Shi wrote: >>> The function has no parameter @len now, so need to remove it from >>> comments to avoid kernel-doc warning: >> >> But it still does in my tree. >> >> Please push this patch via whoever changed it? >> >> Acked-by: Rusty Russell >> > > Sorry, my fault, the commit log used a wrong function name, it is > cpulist_parse() > not cpumask_scnprntf. and find a new error in the comments: used a incorrect > function name: cpulist_parse_user(), the correct one is cpulist_parse(). > Fix it in updated patch. > > Both errors appear in Rusty's commit 29c0177e6a4. Rusty. The error still exist on upstream tree. Would you like to pick this fix? > > === > > From db20433a0b321f7b4edfc57f66e816d7bec81b14 Mon Sep 17 00:00:00 2001 > From: Alex Shi > Date: Mon, 16 Jul 2012 10:25:06 +0800 > Subject: [PATCH] cpumask: cpulist_parse() comments correction > > The function has no parameter @len, so need to remove it from > comments to avoid kernel-doc warning: > > alexs@debian:~/linux-next$ scripts/kernel-doc -man > include/linux/cpumask.h | split-man.pl /tmp/man > > Warning(include/linux/cpumask.h:602): Excess function parameter 'len' > description in 'cpulist_parse' > > and correct the function name in comments to cpulist_parse. > > Signed-off-by: Alex Shi > --- > include/linux/cpumask.h |3 +-- > 1 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h > index 8bf1c27..0325602 100644 > --- a/include/linux/cpumask.h > +++ b/include/linux/cpumask.h > @@ -591,9 +591,8 @@ static inline int cpulist_scnprintf(char *buf, int len, > } > > /** > - * cpulist_parse_user - extract a cpumask from a user string of ranges > + * cpulist_parse - extract a cpumask from a user string of ranges > * @buf: the buffer to extract from > - * @len: the length of the buffer > * @dstp: the cpumask to set. > * > * Returns -errno, or 0 for success. -- 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] xfs: fix comment typo of struct xfs_da_blkinfo.
On Tue, Jul 17, 2012 at 10:40:21PM -0300, Paulo Alcantara wrote: > From: Christoph Hellwig > Date: Tue, 17 Jul 2012 03:06:43 -0400 > > > Btw, if you need more reviers for the syslinus support feel free to pass > > it by me (or the list). > > This is the branch I'm maintaing for the XFS readonly driver: > > git://zytor.com/users/pcacjr/syslinux.git (branch: xfs) > > The current status is: > > - We are able to find the root inode by reading rootino field from > superblock (xfs_iget_root() function). > - We are able to find inodes that have core's format set to "local" only > at > the moment, which is by reading leaf entries from inode btrees. The > function that looks up for an inode is the xfs_iget() one. We're looking > forward to implement the handling of keys in inode btrees (extents) > also. > > Baoszi is currently working on the inode btree's key part (extents), and I'm > working on the data part of the file inode, which is the xfs_next_extent() > function. > > The xfs_next_extent() function must be able to read the inode (cast to the > data > fork) and populate a structure that stores physical starting number sector and > number of consecutive sectors that contain the inode's data so that Syslinux > will know where to read from. As we discussed on #xfs, I'm still not convinced that parsing the filesystem metadata in the bootloader is the way to go. Far better, IMO, is simply to supply the bootloader with a list of extents for the blocks it needs to read to get the files it needs. You can get them via fiemap(), and it'll work for XFS, btrfs, ext3, ext4, etc without needing to write code to parse the on-disk format of every filesystem. Especially as we are in the process of making major changes to the XFS on-disk format, which means you'll have to make significant changes to support a second XFS disk format in the not-to-distant future... > Thanks for the interest in helping us! We want it to work! ;) Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- 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 3/3] drivers/mmc/host: Add realtek sdmmc interface driver
Hi Oliver:
I will fix it. Should I resend all three patches, or just this one?
BR,
Wei WANG
于 2012年07月19日 20:26, Oliver Neukum 写道:
> On Thursday 19 July 2012 17:55:18 wei_w...@realsil.com.cn wrote:
>
>> +static void sd_normal_rw(struct realtek_sdmmc *host, struct mmc_request
>> *mrq)
>> +{
>> +struct mmc_command *cmd = mrq->cmd;
>> +struct mmc_data *data = mrq->data;
>> +u8 _cmd[5], *buf;
>> +
>> +_cmd[0] = 0x40 | (u8)cmd->opcode;
>> +_cmd[1] = (u8)(cmd->arg >> 24);
>> +_cmd[2] = (u8)(cmd->arg >> 16);
>> +_cmd[3] = (u8)(cmd->arg >> 8);
>> +_cmd[4] = (u8)cmd->arg;
> Please use the predefined macro for endianness conversion.
>
>> +buf = kzalloc(data->blksz, GFP_KERNEL);
> 1. You must handle a failure to allocate a buffer
> 2. You must use GFP_NOIO as you are in a block driver
>
> Regards
> Oliver
>
--
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: [RFC][PATCH 2/4 v4] ftrace/x86: Add save_regs for i386 function calls
On Thu, 2012-07-19 at 16:07 -0700, H. Peter Anvin wrote: > On 07/19/2012 04:04 PM, Steven Rostedt wrote: > > > Basically, all we want to do is add 8 to the stack pointer. And this is > > for the x86_32 version of whatever hardware is in use. > > > > What I'm telling you is that it depends on the context. It doesn't really matter anyway. My questions are more academic than practical, as I'm just sticking with addl. Quibbling over addl or lea is pointless, as addl at least shows us what we want to actually do: add 8 to the stack pointer. -- Steve -- 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/
[PATCH] x86/tlb: fix allnoconfig building warning
The incompatible parameter of flush_tlb_mm_range cause build warning.
Fix it by correct parameter.
Reported-by: Tetsuo Handa
Signed-off-by: Alex Shi
---
arch/x86/include/asm/tlbflush.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index 621b959..4fc8faf 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -105,10 +105,10 @@ static inline void flush_tlb_range(struct vm_area_struct
*vma,
__flush_tlb();
}
-static inline void flush_tlb_mm_range(struct vm_area_struct *vma,
+static inline void flush_tlb_mm_range(struct mm_struct *mm,
unsigned long start, unsigned long end, unsigned long vmflag)
{
- if (vma->vm_mm == current->active_mm)
+ if (mm == current->active_mm)
__flush_tlb();
}
--
1.7.5.4
--
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/
[PATCH 5/7] x86/boot: Removed unused debug flag and set code
As we're no longer using the flag we don't need to extract the value from the
command line and store it. This is a step towards removing command line
parameter code.
Signed-off-by: Joe Millenbach
Signed-off-by: Gokul Caushik
Reviewed-by: Josh Triplett
---
arch/x86/boot/compressed/misc.c |4
1 file changed, 4 deletions(-)
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index 8c29f82..88f7ff6 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -108,7 +108,6 @@ static void error(char *m);
* This is set up by the setup-routine at boot-time
*/
struct boot_params *real_mode; /* Pointer to real-mode data */
-static int debug;
void *memset(void *s, int c, size_t n);
void *memcpy(void *dest, const void *src, size_t n);
@@ -326,9 +325,6 @@ asmlinkage void decompress_kernel(void *rmode, memptr heap,
{
real_mode = rmode;
- if (cmdline_find_option_bool("debug"))
- debug = 1;
-
if (real_mode->screen_info.orig_video_mode == 7) {
vidmem = (char *) 0xb;
vidport = 0x3b4;
--
1.7.9.5
--
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/
[PATCH 2/7] x86/boot: Wrap debug printing in a new debug_putstr function
Change all instances of if (debug) putstr(...) to a new debug_putstr(...).
This allows a future change to conditionally stub out debug_putstr to save
space.
Signed-off-by: Joe Millenbach
Signed-off-by: Gokul Caushik
Reviewed-by: Josh Triplett
---
arch/x86/boot/compressed/misc.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index 8f2355d..49c6d56 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -223,6 +223,12 @@ void __putstr(int error, const char *s)
outb(0xff & (pos >> 1), vidport+1);
}
+static void debug_putstr(const char *s)
+{
+ if (debug)
+ putstr(s);
+}
+
void *memset(void *s, int c, size_t n)
{
int i;
@@ -293,8 +299,7 @@ static void parse_elf(void *output)
return;
}
- if (debug)
- putstr("Parsing ELF... ");
+ debug_putstr("Parsing ELF... ");
phdrs = malloc(sizeof(*phdrs) * ehdr.e_phnum);
if (!phdrs)
@@ -346,8 +351,7 @@ asmlinkage void decompress_kernel(void *rmode, memptr heap,
cols = real_mode->screen_info.orig_video_cols;
console_init();
- if (debug)
- putstr("early console in decompress_kernel\n");
+ debug_putstr("early console in decompress_kernel\n");
free_mem_ptr = heap;/* Heap */
free_mem_end_ptr = heap + BOOT_HEAP_SIZE;
@@ -366,11 +370,9 @@ asmlinkage void decompress_kernel(void *rmode, memptr heap,
error("Wrong destination address");
#endif
- if (debug)
- putstr("\nDecompressing Linux... ");
+ debug_putstr("\nDecompressing Linux... ");
decompress(input_data, input_len, NULL, NULL, output, NULL, error);
parse_elf(output);
- if (debug)
- putstr("done.\nBooting the kernel.\n");
+ debug_putstr("done.\nBooting the kernel.\n");
return;
}
--
1.7.9.5
--
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/
[PATCH 7/7] x86/boot: Exclude cmdline.c if you can't use it
From: Gokul Caushik
CONFIG_EARLY_PRINTK is the only feature that might use command line
parsing in the decompression stage. If it is disabled then we can
exclude the related code to save space. This can result in an estimated
space savings of 2240 bytes from the compressed kernel image.
Signed-off-by: Joe Millenbach
Signed-off-by: Gokul Caushik
Reviewed-by: Josh Triplett
---
arch/x86/boot/compressed/cmdline.c |4
arch/x86/boot/compressed/misc.h|5 +++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/x86/boot/compressed/cmdline.c
b/arch/x86/boot/compressed/cmdline.c
index cb62f78..10f6b11 100644
--- a/arch/x86/boot/compressed/cmdline.c
+++ b/arch/x86/boot/compressed/cmdline.c
@@ -1,5 +1,7 @@
#include "misc.h"
+#ifdef CONFIG_EARLY_PRINTK
+
static unsigned long fs;
static inline void set_fs(unsigned long seg)
{
@@ -19,3 +21,5 @@ int cmdline_find_option_bool(const char *option)
{
return __cmdline_find_option_bool(real_mode->hdr.cmd_line_ptr, option);
}
+
+#endif
diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/misc.h
index 3ffee6e..0e6dc0e 100644
--- a/arch/x86/boot/compressed/misc.h
+++ b/arch/x86/boot/compressed/misc.h
@@ -38,18 +38,19 @@ static inline void debug_putstr(const char *s)
#endif
+#ifdef CONFIG_EARLY_PRINTK
+
/* cmdline.c */
int cmdline_find_option(const char *option, char *buffer, int bufsize);
int cmdline_find_option_bool(const char *option);
/* early_serial_console.c */
-#ifdef CONFIG_EARLY_PRINTK
-
extern int early_serial_base;
void console_init(void);
#else
+/* early_serial_console.c */
static const int early_serial_base;
static inline void console_init(void)
{ }
--
1.7.9.5
--
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/
[PATCH 6/7] x86/boot: Exclude early_serial_console.c if can't use it.
Removes early_serial_console.c code if we don't have the config option that
enables it (EARLY_PRINTK). When disabling this code, make early_serial_base a
constant 0 to allow the compiler to optimize away the code that checks for
early_serial_base.
Signed-off-by: Joe Millenbach
Signed-off-by: Gokul Caushik
Reviewed-by: Josh Triplett
---
arch/x86/boot/compressed/early_serial_console.c |4
arch/x86/boot/compressed/misc.h | 10 ++
2 files changed, 14 insertions(+)
diff --git a/arch/x86/boot/compressed/early_serial_console.c
b/arch/x86/boot/compressed/early_serial_console.c
index 261e81f..d3d003c 100644
--- a/arch/x86/boot/compressed/early_serial_console.c
+++ b/arch/x86/boot/compressed/early_serial_console.c
@@ -1,5 +1,9 @@
#include "misc.h"
+#ifdef CONFIG_EARLY_PRINTK
+
int early_serial_base;
#include "../early_serial_console.c"
+
+#endif
diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/misc.h
index 618e5c8..3ffee6e 100644
--- a/arch/x86/boot/compressed/misc.h
+++ b/arch/x86/boot/compressed/misc.h
@@ -43,7 +43,17 @@ int cmdline_find_option(const char *option, char *buffer,
int bufsize);
int cmdline_find_option_bool(const char *option);
/* early_serial_console.c */
+#ifdef CONFIG_EARLY_PRINTK
+
extern int early_serial_base;
void console_init(void);
+#else
+
+static const int early_serial_base;
+static inline void console_init(void)
+{ }
+
+#endif
+
#endif
--
1.7.9.5
--
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/
[PATCH 3/7] x86/boot: Changed error putstr path to match new debug_putstr format
For consistency we changed the error output path to match the new debug path.
Signed-off-by: Joe Millenbach
Signed-off-by: Gokul Caushik
Reviewed-by: Josh Triplett
---
arch/x86/boot/compressed/misc.c |6 +++---
arch/x86/boot/compressed/misc.h |1 +
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index 49c6d56..de1d54d 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -270,9 +270,9 @@ void *memcpy(void *dest, const void *src, size_t n)
static void error(char *x)
{
- __putstr(1, "\n\n");
- __putstr(1, x);
- __putstr(1, "\n\n -- System halted");
+ error_putstr("\n\n");
+ error_putstr(x);
+ error_putstr("\n\n -- System halted");
while (1)
asm("hlt");
diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/misc.h
index 3f19c81..4c1bfb6 100644
--- a/arch/x86/boot/compressed/misc.h
+++ b/arch/x86/boot/compressed/misc.h
@@ -26,6 +26,7 @@
extern struct boot_params *real_mode; /* Pointer to real-mode data */
void __putstr(int error, const char *s);
#define putstr(__x) __putstr(0, __x)
+#define error_putstr(__x) __putstr(1, __x)
#define puts(__x) __putstr(0, __x)
/* cmdline.c */
--
1.7.9.5
--
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/
[PATCH 1/7] x86/boot: Removed quiet flag and switched quiet output to debug flag
There are only 3 uses of the quiet flag and they all protect output that
is only useful for debugging the stub, therefore we switched to using the
debug flag for all extra output.
Signed-off-by: Joe Millenbach
Signed-off-by: Gokul Caushik
Reviewed-by: Josh Triplett
---
arch/x86/boot/compressed/misc.c |9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index 7116dcb..8f2355d 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -108,7 +108,6 @@ static void error(char *m);
* This is set up by the setup-routine at boot-time
*/
struct boot_params *real_mode; /* Pointer to real-mode data */
-static int quiet;
static int debug;
void *memset(void *s, int c, size_t n);
@@ -294,7 +293,7 @@ static void parse_elf(void *output)
return;
}
- if (!quiet)
+ if (debug)
putstr("Parsing ELF... ");
phdrs = malloc(sizeof(*phdrs) * ehdr.e_phnum);
@@ -332,8 +331,6 @@ asmlinkage void decompress_kernel(void *rmode, memptr heap,
{
real_mode = rmode;
- if (cmdline_find_option_bool("quiet"))
- quiet = 1;
if (cmdline_find_option_bool("debug"))
debug = 1;
@@ -369,11 +366,11 @@ asmlinkage void decompress_kernel(void *rmode, memptr
heap,
error("Wrong destination address");
#endif
- if (!quiet)
+ if (debug)
putstr("\nDecompressing Linux... ");
decompress(input_data, input_len, NULL, NULL, output, NULL, error);
parse_elf(output);
- if (!quiet)
+ if (debug)
putstr("done.\nBooting the kernel.\n");
return;
}
--
1.7.9.5
--
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] PM / Sleep: Print name of wakeup source that aborts suspend
On Wed, Jul 18, 2012 at 09:47:34PM +0200, Rafael J. Wysocki wrote:
> On Wednesday, July 18, 2012, Todd Poynor wrote:
...
> > +{
> > + struct wakeup_source *ws;
> > + int active = 0;
> > + struct wakeup_source *last_activity_ws = NULL;
> > +
> > + rcu_read_lock();
> > + list_for_each_entry_rcu(ws, _sources, entry) {
> > + if (ws->active) {
> > + pr_info("active wakeup source: %s\n", ws->name);
> > + active = 1;
>
> Can we do a break here? Or do we want to get all of them?
I haven't seen more than 3 activated during suspend entry at a time, but
could just list one. I haven't made that change yet but will if it's
preferred.
>
> > + } else if (!active &&
> > + (!last_activity_ws ||
> > + ws->last_time.tv64 >
> > + last_activity_ws->last_time.tv64)) {
>
> ktime_to_ns() anyone?
Sure, I avoided it because some configs do math on each of these, but
perhaps most implementations implement it as a NOP.
>
> > + last_activity_ws = ws;
> > + }
> > + }
> > +
> > + if (!active && last_activity_ws)
> > + pr_info("last active wakeup source: %s\n",
> > + last_activity_ws->name);
> > + rcu_read_unlock();
> > +}
> > +
> > /**
> > * pm_wakeup_pending - Check if power transition in progress should be
> > aborted.
> > *
> > @@ -671,6 +696,10 @@ bool pm_wakeup_pending(void)
> > events_check_enabled = !ret;
> > }
> > spin_unlock_irqrestore(_lock, flags);
> > +
> > + if (ret)
> > + print_active_wakeup_sources();
> > +
> > return ret;
> > }
>
> There is no way this or equivalent can go into v3.6. It may go into v3.7,
> but there's a plenty of time for that.
Sounds fine, thanks.
>
> Thanks,
> Rafael
Todd
--
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] perf: prevent overflow in size calculation
Hi, Cody
On Thu, 19 Jul 2012 17:13:35 -0700, Cody Schafer wrote:
> A large enough symbol size causes an overflow in the size parameter to the
> histogram allocation, leading to a segfault in symbol__inc_addr_samples later
> on when this histogram is accessed.
>
> In the case of being called via perf-report, this returns back and
> gracefully ignores the sample, eventually ignoring the chained return
> value of perf_session_deliver_event in flush_sample_queue.
>
> Signed-off-by: Cody Schafer
> ---
> tools/perf/util/annotate.c |7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
> index 8069dfb..6f78f20 100644
> --- a/tools/perf/util/annotate.c
> +++ b/tools/perf/util/annotate.c
> @@ -426,8 +426,13 @@ int symbol__alloc_hist(struct symbol *sym)
> {
> struct annotation *notes = symbol__annotation(sym);
> const size_t size = symbol__size(sym);
> - size_t sizeof_sym_hist = (sizeof(struct sym_hist) + size * sizeof(u64));
> + size_t sizeof_sym_hist;
>
> + /* Check for overflow when calculating sizeof_sym_hist */
> + if (size > (SIZE_MAX / sizeof(u64)))
> + return -1;
How does it guarantee that the end result which used in zalloc below
would not overflow?
Thanks,
Namhyung
> +
> + sizeof_sym_hist = (sizeof(struct sym_hist) + size * sizeof(u64));
> notes->src = zalloc(sizeof(*notes->src) + symbol_conf.nr_events *
> sizeof_sym_hist);
> if (notes->src == NULL)
> return -1;
--
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 v10 7/9] x86/tlb: enable tlb flush range support for x86
Separate is better. When I say clean patch I mean in a separate email so git
am can process it.
Alex Shi wrote:
>On 07/20/2012 07:56 AM, H. Peter Anvin wrote:
>
>> On 07/19/2012 04:52 PM, Alex Shi wrote:
>>>
>>> Sure, it is a bug, the fix had sent:
>>> https://lkml.org/lkml/2012/7/6/350
>>>
>>
>> Could you please re-send that as a clean patch?
>>
>> -hpa
>>
>
>
>
>
>Since, it has not impact for the serial left patches, and linux-next
>has not merge this patchset. I folded this patch into original.
>Is that ok, or need a separated one?
>
>===
>From 2e6117dfda5b323261e959bb5faf778cbe4b3c64 Mon Sep 17 00:00:00 2001
>From: Alex Shi
>Date: Mon, 25 Jun 2012 11:06:46 +0800
>Subject: [PATCH 7/9] x86/tlb: enable tlb flush range support for x86
>
>Not every tlb_flush execution moment is really need to evacuate all
>TLB entries, like in munmap, just few 'invlpg' is better for whole
>process performance, since it leaves most of TLB entries for later
>accessing.
>
>This patch also rewrite flush_tlb_range for 2 purposes:
>1, split it out to get flush_blt_mm_range function.
>2, clean up to reduce line breaking, thanks for Borislav's input.
>
>My micro benchmark 'mummap' http://lkml.org/lkml/2012/5/17/59
>show that the random memory access on other CPU has 0~50% speed up
>on a 2P * 4cores * HT NHM EP while do 'munmap'.
>
>Thanks Yongjie's testing on this patch:
>-
>I used Linux 3.4-RC6 w/ and w/o his patches as Xen dom0 and guest
>kernel.
>After running two benchmarks in Xen HVM guest, I found his patches
>brought about 1%~3% performance gain in 'kernel build' and 'netperf'
>testing, though the performance gain was not very stable in 'kernel
>build' testing.
>
>Some detailed testing results are below.
>
>Testing Environment:
> Hardware: Romley-EP platform
> Xen version: latest upstream
> Linux kernel: 3.4-RC6
> Guest vCPU number: 8
> NIC: Intel 82599 (10GB bandwidth)
>
>In 'kernel build' testing in guest:
> Command line | performance gain
>make -j 4 |3.81%
>make -j 8 |0.37%
>make -j 16 |-0.52%
>
>In 'netperf' testing, we tested TCP_STREAM with default socket size
>16384 byte as large packet and 64 byte as small packet.
>I used several clients to add networking pressure, then 'netperf'
>server
>automatically generated several threads to response them.
>I also used large-size packet and small-size packet in the testing.
> Packet size | Thread number | performance gain
> 16384 bytes | 4 | 0.02%
> 16384 bytes | 8 | 2.21%
> 16384 bytes | 16 | 2.04%
> 64 bytes | 4 | 1.07%
> 64 bytes | 8 | 3.31%
> 64 bytes | 16 | 0.71%
>
>This patch also fold a flush_tlb_mm_range() fixing in 'make
>allnoconfig'
>, that reported by Tetsuo Handa. Thanks!
>
>Signed-off-by: Alex Shi
>Tested-by: Ren, Yongjie
>---
> arch/x86/include/asm/tlb.h |9 +++-
> arch/x86/include/asm/tlbflush.h | 17 +-
>arch/x86/mm/tlb.c | 112
>---
> 3 files changed, 68 insertions(+), 70 deletions(-)
>
>diff --git a/arch/x86/include/asm/tlb.h b/arch/x86/include/asm/tlb.h
>index 829215f..4fef207 100644
>--- a/arch/x86/include/asm/tlb.h
>+++ b/arch/x86/include/asm/tlb.h
>@@ -4,7 +4,14 @@
> #define tlb_start_vma(tlb, vma) do { } while (0)
> #define tlb_end_vma(tlb, vma) do { } while (0)
> #define __tlb_remove_tlb_entry(tlb, ptep, address) do { } while (0)
>-#define tlb_flush(tlb) flush_tlb_mm((tlb)->mm)
>+
>+#define tlb_flush(tlb)
>\
>+{ \
>+ if (tlb->fullmm == 0) \
>+ flush_tlb_mm_range(tlb->mm, tlb->start, tlb->end, 0UL); \
>+ else\
>+ flush_tlb_mm_range(tlb->mm, 0UL, TLB_FLUSH_ALL, 0UL); \
>+}
>
> #include
>
>diff --git a/arch/x86/include/asm/tlbflush.h
>b/arch/x86/include/asm/tlbflush.h
>index 33608d9..4fc8faf 100644
>--- a/arch/x86/include/asm/tlbflush.h
>+++ b/arch/x86/include/asm/tlbflush.h
>@@ -105,6 +105,13 @@ static inline void flush_tlb_range(struct
>vm_area_struct *vma,
> __flush_tlb();
> }
>
>+static inline void flush_tlb_mm_range(struct mm_struct *mm,
>+ unsigned long start, unsigned long end, unsigned long vmflag)
>+{
>+ if (mm == current->active_mm)
>+ __flush_tlb();
>+}
>+
>static inline void native_flush_tlb_others(const struct cpumask
>*cpumask,
> struct mm_struct *mm,
> unsigned long start,
>@@ -122,12 +129,16 @@ static inline void reset_lazy_tlbstate(void)
>
> #define local_flush_tlb() __flush_tlb()
>
>+#define flush_tlb_mm(mm) flush_tlb_mm_range(mm, 0UL, TLB_FLUSH_ALL,
Re: [PATCH 4/9] KVM: MMU: track the refcount when unmap the page
On Tue, Jul 17, 2012 at 09:52:52PM +0800, Xiao Guangrong wrote: > It will trigger a WARN_ON if the page has been freed but it is still > used in mmu, it can help us to detect mm bug early > > Signed-off-by: Xiao Guangrong > --- > arch/x86/kvm/mmu.c |8 > 1 files changed, 8 insertions(+), 0 deletions(-) Applied, thanks. -- 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 2/9] KVM: x86: simplify read_emulated
On Tue, Jul 17, 2012 at 09:51:34PM +0800, Xiao Guangrong wrote:
> No need split mmio read region into 8-bits pieces since we do it in
> emulator_read_write_onepage
>
> Signed-off-by: Xiao Guangrong
> ---
> arch/x86/kvm/emulate.c | 29 -
> 1 files changed, 12 insertions(+), 17 deletions(-)
>
> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
> index 97d9a99..2d1916b 100644
> --- a/arch/x86/kvm/emulate.c
> +++ b/arch/x86/kvm/emulate.c
> @@ -1166,24 +1166,19 @@ static int read_emulated(struct x86_emulate_ctxt
> *ctxt,
> int rc;
> struct read_cache *mc = >mem_read;
>
> - while (size) {
> - int n = min(size, 8u);
> - size -= n;
> - if (mc->pos < mc->end)
> - goto read_cached;
> -
> - rc = ctxt->ops->read_emulated(ctxt, addr, mc->data + mc->end, n,
> - >exception);
> - if (rc != X86EMUL_CONTINUE)
> - return rc;
> - mc->end += n;
> + if (mc->pos < mc->end)
> + goto read_cached;
>
> - read_cached:
> - memcpy(dest, mc->data + mc->pos, n);
> - mc->pos += n;
> - dest += n;
> - addr += n;
> - }
> + rc = ctxt->ops->read_emulated(ctxt, addr, mc->data + mc->end, size,
> + >exception);
> + if (rc != X86EMUL_CONTINUE)
> + return rc;
> +
> + mc->end += size;
> +
> +read_cached:
> + memcpy(dest, mc->data + mc->pos, size);
What prevents read_emulated(size > 8) call, with
mc->pos == (mc->end - 8) now?
> + mc->pos += size;
> return X86EMUL_CONTINUE;
> }
--
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 1/9] KVM: x86: remvoe unnecessary mark_page_dirty
Applied all patches except 2, 3 and 5, thanks. -- 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 5/9] KVM: MMU: fask check write-protect for direct mmu
On Tue, Jul 17, 2012 at 09:53:29PM +0800, Xiao Guangrong wrote: > If it have no indirect shadow pages we need not protect any gfn, > this is always true for direct mmu without nested > > Signed-off-by: Xiao Guangrong Xiao, What is the motivation? Numbers please. In fact, what case was the original indirect_shadow_pages conditional in kvm_mmu_pte_write optimizing again? -- 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 3/9] KVM: x86: introduce set_mmio_exit_info
On Tue, Jul 17, 2012 at 09:52:13PM +0800, Xiao Guangrong wrote: > Introduce set_mmio_exit_info to cleanup the common code > > Signed-off-by: Xiao Guangrong > --- > arch/x86/kvm/x86.c | 33 + > 1 files changed, 17 insertions(+), 16 deletions(-) This makes the code less readable IMO. The fragments are small enough already. -- 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: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory)
> -Original Message- > From: Greg KH (gre...@linuxfoundation.org) > [mailto:gre...@linuxfoundation.org] > Sent: Thursday, July 19, 2012 7:29 PM > To: KY Srinivasan > Cc: Paolo Bonzini; de...@linuxdriverproject.org; linux-kernel@vger.kernel.org; > virtualizat...@lists.osdl.org > Subject: Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the > drivers/staging/ directory) > > On Thu, Jul 19, 2012 at 10:30:38PM +, KY Srinivasan wrote: > > > > As you know, this ID has been in use for a long time now. While the > hypervisor > > > > does not interpret the guest ID that is registered, I am not sure what > > > dependencies > > > > there might be on this value. > > > > > > Could you please go find out the answer to this? > > > > That is easier said than done. I have sent emails out asking this very > > question > and I have > > not received a definitive answer yet. Not knowing if and when I can get a > definitive > > answer here, I chose the least risky approach in my patch. > > What happens if you test with different values? Nothing and that is not the issue. Current MSFT hypervisors don't interpret this ID value while future versions might. However, this ID can be retrieved by the parent partition and can be used by the management stack today (that is what I am told). > > > > If, as you originally stated, there is a range of values we can use, > > > then we should probably use another one, right? > > > > On the Windows side this ID namespace is managed well. > > It is? How is this managed? What does this tell the hypervisor? What > changes with the different values? > > > However on the Linux side, we have really had this current ID in use > > for almost five years now. I am not aware of any pool of IDs available > > for Linux usage except that Linux IDs be distinct from the guest IDs > > in use by MSFT operating systems. If I were to change the guest ID, I > > would probably want to comply with the MSFT guidance on constructing > > these IDs (although not all fields may be relevant for Linux). > > What are those rules? Here is the link that describes how the guest ID should be composed: http://msdn.microsoft.com/en-us/library/windows/hardware/ff542653%28v=vs.85%29.aspx Regards, K. Y -- 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/
linux-next: build failure after merge of the scsi tree
Hi James,
After merging the scsi tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/base/dd.c:27:28: fatal error: scsi/scsi_scan.h: No such file or
directory
Caused by commit eea03c20ae38 ("Make wait_for_device_probe() also do
scsi_complete_async_scans()") from Linus' tree interacting with commit
758da9dc2be8 ("[SCSI] cleanup usages of scsi_complete_async_scans") from
the scsi tree.
I have reverted commit 758da9dc2be8 for today (which may not be the best
thing to do).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpWOECPjb1na.pgp
Description: PGP signature
RE: [RFC][PATCH v2 2/3] Hold multiple logs
Thank you for describing this in detail. > Yes - if the OOPs is instrumental in the path leading to the hang/panic - > then the OOPS is the first place to look for the root cause of > the problem. But it will be a case by case analysis. > Sometimes the OOPS might be unconnected. If possible we'd like to log more > information to allow detective work to decide whether > there is a connection. But as I mentioned above there are severe limits to > how much better things are by storing more information. I understand the reason why you think 3 or 4 logs are reasonable. There are some cases 2nd or 3rd oops is critical I have some enterprise customers who are sensitive for a software failure and specify panic_on_oops=1. In this case, they don't need 3,4 logs. 2 logs are enough. So, kernel parameter should be as follows. Log_num =1 - For users who want to hold just one log. Log_num=2 - For users who can handle multiple logs and 1st oops is concerned. (by specifying panic_on_oops=1) Log_num=3,4 - for users who care about 2nd or 3rd oops. Log_num=5 or more Invalid value. If there is misunderstanding, please let me know. Seiji > -Original Message- > From: Luck, Tony [mailto:tony.l...@intel.com] > Sent: Thursday, July 19, 2012 7:42 PM > To: Seiji Aguchi; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; > mi...@google.com; dzic...@redhat.com; Matthew > Garrett (m...@redhat.com) > Cc: dle-deve...@lists.sourceforge.net; Satoru Moriya > Subject: RE: [RFC][PATCH v2 2/3] Hold multiple logs > > > If you are concerned about multiple OOPS case, I think an user app which > > logs from /dev/pstore to /var/log should be developed. > > Agreed - we need an app/daemon to do this. > > > Once it is developed, we don't need to care about multiple oops case and > > the appropriate number is two. > > Only if you can guarantee that the app/daemon will run and save the first > OOPS before the next occurs. Even if the system were > running normally this might be difficult to achieve.. but in this case we > know the system isn't running normally (it just OOPSed twice!). > > However - there is progressively less value in collecting additional > consecutive OOPS. Perhaps one is enough 90% or even 99% of the > time. I'm naturally paranoid so having two or three would make me feel happy > that most of the remaining 10% or 1% of the cases > were covered. > > > - In case where system is workable after oops. > > The user app will erase an entry in NVRAM. > > And we can get the message via /var/log. > > Yes - the system can keep running after many types of OOPs - so the OOPS will > be logged in /var/log (or by the app/daemon copying > from pstore, or both). > > > - In case where system hangs up or panics due to the oops. > > Oops is the critical message and we don't need care about subsequent events. > > Yes - if the OOPs is instrumental in the path leading to the hang/panic - > then the OOPS is the first place to look for the root cause of > the problem. But it will be a case by case analysis. > Sometimes the OOPS might be unconnected. If possible we'd like to log more > information to allow detective work to decide whether > there is a connection. But as I mentioned above there are severe limits to > how much better things are by storing more information. > > -Tony -- 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: 3.5-rc6 futex_wait_requeue_pi oops.
On 07/19/2012 04:22 PM, Darren Hart wrote: > > > On 07/13/2012 11:54 AM, Dave Jones wrote: >> On Fri, Jul 13, 2012 at 08:47:38PM +0200, Thomas Gleixner wrote: >> > On Fri, 13 Jul 2012, Dave Jones wrote: >> > >> > > Looks like calling futex() with garbage makes things unhappy. >> > >> > WARN_ON(!_state); >> > pi_mutex = _state->pi_mutex; >> > ret = rt_mutex_finish_proxy_lock(pi_mutex, to, >> _waiter, 1); >> > debug_rt_mutex_free_waiter(_waiter); >> > >> > So there is some weird way which causes q.pi_state = NULL. Dave, did >> > you see the warning before the oops happened ? >> >> No, that didn't seem to trigger. > > Well I don't have a fix yet, but I can explain this not triggering. > > q is on the stack, so the ADDRESS for q.pi_state is never going to be > NULL. However, properly instrumented, we do see this: > > [ 23.621501] ---[ end trace 20bdfb44db182a17 ]--- > [ 23.622425] q.pi_state @ (null) > [ 23.623272] _state @ 880185e2dca8 > [ 23.624119] [ cut here ] > > Duh. > > I'll add a fix to that WARN_ON in my futex-fixes branch along with the > fix for the bug Dan found. > I think I have root cause. futex_wait_requeue_pi() doesn't like having uaddr == uaddr2. The handle_early_wakeup() doesn't detect a problem because key2 IS the same as key1, I think. I've just discovered this and quickly hacked in a "if (uaddr==uaddr2) return -EINVAL" fix and the test continues to run (with just ops 0, 11, 12) for several minutes now (typically fails in a few seconds). I'll let it run for a few hours and contemplate the proper fix. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel -- 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: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory)
> -Original Message- > From: Anthony Liguori [mailto:anth...@codemonkey.ws] > Sent: Thursday, July 19, 2012 7:18 PM > To: KY Srinivasan > Cc: Greg KH (gre...@linuxfoundation.org); Paolo Bonzini; > de...@linuxdriverproject.org; linux-kernel@vger.kernel.org; > virtualizat...@lists.osdl.org > Subject: Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the > drivers/staging/ directory) > > On 07/19/2012 05:30 PM, KY Srinivasan wrote: > > > > > >> -Original Message- > >> From: Greg KH (gre...@linuxfoundation.org) > >> [mailto:gre...@linuxfoundation.org] > >> Sent: Thursday, July 19, 2012 6:02 PM > >> To: KY Srinivasan > >> Cc: Paolo Bonzini; de...@linuxdriverproject.org; linux- > ker...@vger.kernel.org; > >> virtualizat...@lists.osdl.org > >> Subject: Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the > >> drivers/staging/ directory) > >> > >> On Thu, Jul 19, 2012 at 09:22:53PM +, KY Srinivasan wrote: > >>> > >>> > -Original Message- > From: Greg KH (gre...@linuxfoundation.org) > [mailto:gre...@linuxfoundation.org] > Sent: Thursday, July 19, 2012 5:07 PM > To: KY Srinivasan > Cc: Paolo Bonzini; de...@linuxdriverproject.org; linux- > >> ker...@vger.kernel.org; > virtualizat...@lists.osdl.org > Subject: Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the > drivers/staging/ directory) > > On Thu, Jul 19, 2012 at 02:11:47AM +, KY Srinivasan wrote: > > > > > >> -Original Message- > >> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of > Paolo > >> Bonzini > >> Sent: Friday, July 13, 2012 6:23 AM > >> To: KY Srinivasan > >> Cc: Greg KH; de...@linuxdriverproject.org; linux- > ker...@vger.kernel.org; > >> virtualizat...@lists.osdl.org > >> Subject: 0xB16B00B5? Really? (was Re: Move hyperv out of the > drivers/staging/ > >> directory) > >> > >> Il 04/10/2011 21:34, Greg KH ha scritto: > >>> diff --git a/drivers/staging/hv/hyperv_vmbus.h > b/drivers/hv/hyperv_vmbus.h > >>> similarity index 99% > >>> rename from drivers/staging/hv/hyperv_vmbus.h > >>> rename to drivers/hv/hyperv_vmbus.h > >>> index 3d2d836..8261cb6 100644 > >>> --- a/drivers/staging/hv/hyperv_vmbus.h > >>> +++ b/drivers/hv/hyperv_vmbus.h > >>> @@ -28,8 +28,7 @@ > >>> #include > >>> #include > >>> #include > >>> - > >>> -#include "hyperv.h" > >>> +#include > >>> > >>> /* > >>>* The below CPUID leaves are present if > >> VersionAndFeatures.HypervisorPresent > >> > >> git's rename detection snips away this gem: > >> > >> +#define HV_LINUX_GUEST_ID_LO 0x > >> +#define HV_LINUX_GUEST_ID_HI 0xB16B00B5 > >> +#define HV_LINUX_GUEST_ID > (((u64)HV_LINUX_GUEST_ID_HI > >> << 32) | \ > >> + HV_LINUX_GUEST_ID_LO) > >> > >> Somone was trying to be funny, I guess. > >> > >> KY, I suppose you have access to Hyper-V code or can ask someone who > does. > >> Is this signature actually used in the Hyper-V host code? > > > > Paolo, > > > > As I noted earlier, this is just a guest ID that needs to be registered > > with > the > > hypervisor. Thanks for reporting this issue and on behalf of > > Microsoft, I > >> would > > like to apologize for this offensive string. I have submitted a patch > > to fix > this > issue. > > You only changed it to be in decimal, you did not change the id at all. > Is there some reason why you can not change it? You said there was a > reserved range of ids that could be used, perhaps just pick another one? > What is the valid range that can be used here? > >>> > >>> Greg, > >>> > >>> As you know, this ID has been in use for a long time now. While the > hypervisor > >>> does not interpret the guest ID that is registered, I am not sure what > >> dependencies > >>> there might be on this value. > >> > >> Could you please go find out the answer to this? > > > > That is easier said than done. I have sent emails out asking this very > > question > and I have > > not received a definitive answer yet. Not knowing if and when I can get a > definitive > > answer here, I chose the least risky approach in my patch. > >> > >> If, as you originally stated, there is a range of values we can use, > >> then we should probably use another one, right? > > > > On the Windows side this ID namespace is managed well. However on the Linux > > side, we have really had this current ID in use for almost five years now. > > I am > not > > aware of any pool of IDs available for Linux usage except that Linux IDs be > distinct from > > the guest IDs in use by MSFT operating systems. If I were to change the > > guest > ID, I would > > probably want to comply with the MSFT guidance on constructing these IDs >
linux-next: manual merge of the scsi tree with Linus' tree
Hi James,
Today's linux-next merge of the scsi tree got a conflict in
drivers/scsi/scsi_wait_scan.c between commit eea03c20ae38 ("Make
wait_for_device_probe() also do scsi_complete_async_scans()") from Linus'
tree and commit 01444e1106cb ("[SCSI] Remove scsi_wait_scan module") from
the scsi tree.
I just removed the file.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpW15sOt7ks9.pgp
Description: PGP signature
Re: [PATCH 15/90] staging: comedi: adv_pci1723: move comedi_pci_enable() into the attach
On Thu, Jul 19, 2012 at 06:58:38PM -0500, H Hartley Sweeten wrote: > On Thursday, July 19, 2012 4:35 PM, gregkh wrote: > > On Thu, Jul 19, 2012 at 06:31:23PM -0500, H Hartley Sweeten wrote: > >> If the comedi pci drivers have the "attach_pci" callback defined, the > >> PCI api does correctly probe the driver. The comedi_pci_auto_config() > >> then passes the pci_dev directly to the driver and the search of the > >> PCI space for the device is not required. > >> > >> If the "attach_pci" callback is not defined, the comedi_pci_auto_config() > >> then falls back to passing the bus/slot information to the driver and uses > >> the "attach" callback. In this case we could probably fast-track the search > >> by using pci_get_slot() instead of doing the for_each_pci_dev() loop. > >> > >> I think the problem is the COMEDI_DEVCONFIG ioctl. The userspace > >> utility 'comedi_config' uses that ioctl to link a device node to a > >> comedi driver. That utility allows passing the bus/slot information > >> but it's not required. This means we have to search the PCI space > >> for the pci_dev that matches the driver. > > > > The ioctl shouldn't be needed anymore for PCI or USB devices, as the > > kernel handles the matching of the driver to the device. Even if it > > didn't, there are other more "standard" ways that you can bind devices > > to drivers (through sysfs.) > > I think it's still needed for some of the devices that require external > firmware. The comedi_config utility allows the user to remove the > driver binding and then reattach to it while passing the firmware blob > into the driver. Why would the driver need to be unbound from the device to do this? > Not saying any of this is valid... And yes, there probably is a more > "standard" way to do this. I just need a hint of what that is... ;-) The "bind" and "unbind" files in sysfs are for that. thanks, greg k-h -- 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/
[PATCH] perf: prevent overflow in size calculation
A large enough symbol size causes an overflow in the size parameter to the
histogram allocation, leading to a segfault in symbol__inc_addr_samples later
on when this histogram is accessed.
In the case of being called via perf-report, this returns back and
gracefully ignores the sample, eventually ignoring the chained return
value of perf_session_deliver_event in flush_sample_queue.
Signed-off-by: Cody Schafer
---
tools/perf/util/annotate.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 8069dfb..6f78f20 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -426,8 +426,13 @@ int symbol__alloc_hist(struct symbol *sym)
{
struct annotation *notes = symbol__annotation(sym);
const size_t size = symbol__size(sym);
- size_t sizeof_sym_hist = (sizeof(struct sym_hist) + size * sizeof(u64));
+ size_t sizeof_sym_hist;
+ /* Check for overflow when calculating sizeof_sym_hist */
+ if (size > (SIZE_MAX / sizeof(u64)))
+ return -1;
+
+ sizeof_sym_hist = (sizeof(struct sym_hist) + size * sizeof(u64));
notes->src = zalloc(sizeof(*notes->src) + symbol_conf.nr_events *
sizeof_sym_hist);
if (notes->src == NULL)
return -1;
--
1.7.9.5
--
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 6/6] leds: add new lp8788 led driver
On Wed, Jul 18, 2012 at 10:34 PM, Kim, Milo wrote:
> TI LP8788 PMU has the current sink as the keyboard led driver.
> The brightness is controlled by the i2c commands.
> Configurable parameters can be defined in the platform side.
>
> Signed-off-by: Milo(Woogyom) Kim
> ---
> drivers/leds/Kconfig |7 ++
> drivers/leds/Makefile |1 +
> drivers/leds/leds-lp8788.c | 178
>
> 3 files changed, 186 insertions(+), 0 deletions(-)
> create mode 100644 drivers/leds/leds-lp8788.c
>
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index f028f03..a498deb 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -200,6 +200,13 @@ config LEDS_LP5523
> Driver provides direct control via LED class and interface for
> programming the engines.
>
> +config LEDS_LP8788
> + tristate "LED support for the TI LP8788 PMIC"
> + depends on LEDS_CLASS
> + depends on MFD_LP8788
> + help
> + This option enables support for the Keyboard LEDs on the LP8788
> PMIC.
> +
> config LEDS_CLEVO_MAIL
> tristate "Mail LED on Clevo notebook"
> depends on LEDS_CLASS
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index 5eebd7b..f156193 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -24,6 +24,7 @@ obj-$(CONFIG_LEDS_GPIO) += leds-gpio.o
> obj-$(CONFIG_LEDS_LP3944) += leds-lp3944.o
> obj-$(CONFIG_LEDS_LP5521) += leds-lp5521.o
> obj-$(CONFIG_LEDS_LP5523) += leds-lp5523.o
> +obj-$(CONFIG_LEDS_LP8788) += leds-lp8788.o
> obj-$(CONFIG_LEDS_TCA6507) += leds-tca6507.o
> obj-$(CONFIG_LEDS_CLEVO_MAIL) += leds-clevo-mail.o
> obj-$(CONFIG_LEDS_HP6XX) += leds-hp6xx.o
> diff --git a/drivers/leds/leds-lp8788.c b/drivers/leds/leds-lp8788.c
> new file mode 100644
> index 000..d92625e
> --- /dev/null
> +++ b/drivers/leds/leds-lp8788.c
> @@ -0,0 +1,178 @@
> +/*
> + * TI LP8788 MFD - keyled driver
> + *
> + * Copyright 2012 Texas Instruments
> + *
> + * Author: Milo(Woogyom) Kim
> + *
> + * 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
> +
> +#define MAX_BRIGHTNESS LP8788_ISINK_MAX_PWM
> +#define DEFAULT_LED_NAME "keyboard-backlight"
> +#define DEFAULT_ISINK_SCALELP8788_ISINK_SCALE_100mA
> +#define DEFAULT_ISINK_NUM LP8788_ISINK_3
> +#define DEFAULT_ISINK_OUT 0
> +
> +struct lp8788_led {
> + struct lp8788 *lp;
> + struct led_classdev led_dev;
> + enum lp8788_isink_number isink_num;
> + int on;
> +};
> +
> +static int lp8788_led_init_device(struct lp8788_led *led,
> + struct lp8788_led_platform_data *pdata)
> +{
> + enum lp8788_isink_scale scale = DEFAULT_ISINK_SCALE;
> + enum lp8788_isink_number num = DEFAULT_ISINK_NUM;
> + int ret, iout = DEFAULT_ISINK_OUT;
> + u8 addr, mask, val;
> +
> + if (pdata) {
> + scale = pdata->scale;
> + num = pdata->num;
> + iout = pdata->iout_code;
> + }
> +
> + led->isink_num = num;
> +
> + /* scale configuration */
> + addr = LP8788_ISINK_CTRL;
> + mask = 1 << (num + LP8788_ISINK_SCALE_OFFSET);
> + val = scale << num;
> + ret = lp8788_update_bits(led->lp, addr, mask, val);
> + if (ret)
> + return ret;
> +
> + /* current configuration */
> + addr = lp8788_iout_addr[num];
> + mask = lp8788_iout_mask[num];
> + val = iout;
> +
> + return lp8788_update_bits(led->lp, addr, mask, val);
> +}
> +
> +static void lp8788_led_enable(struct lp8788_led *led,
> + enum lp8788_isink_number num, int on)
> +{
> + u8 mask = 1 << num;
> + u8 val = on << num;
> +
> + if (lp8788_update_bits(led->lp, LP8788_ISINK_CTRL, mask, val))
> + return;
> +
> + led->on = on;
> +}
> +
> +static void lp8788_brightness_set(struct led_classdev *led_cdev,
> + enum led_brightness brt_val)
/* Must not sleep, use a workqueue if needed */
void(*brightness_set)(struct led_classdev *led_cdev,
enum led_brightness brightness);
so you need to use workqueue here I believe, since this function will
call some i2c operations which might be sleep.
> +{
> + struct lp8788_led *led =
> + container_of(led_cdev, struct lp8788_led, led_dev);
> + enum lp8788_isink_number num = led->isink_num;
> + int enable;
> +
> + switch (num) {
> + case
Re: [PATCH v10 7/9] x86/tlb: enable tlb flush range support for x86
On 07/20/2012 07:56 AM, H. Peter Anvin wrote:
> On 07/19/2012 04:52 PM, Alex Shi wrote:
>>
>> Sure, it is a bug, the fix had sent:
>> https://lkml.org/lkml/2012/7/6/350
>>
>
> Could you please re-send that as a clean patch?
>
> -hpa
>
Since, it has not impact for the serial left patches, and linux-next has not
merge this patchset. I folded this patch into original.
Is that ok, or need a separated one?
===
>From 2e6117dfda5b323261e959bb5faf778cbe4b3c64 Mon Sep 17 00:00:00 2001
From: Alex Shi
Date: Mon, 25 Jun 2012 11:06:46 +0800
Subject: [PATCH 7/9] x86/tlb: enable tlb flush range support for x86
Not every tlb_flush execution moment is really need to evacuate all
TLB entries, like in munmap, just few 'invlpg' is better for whole
process performance, since it leaves most of TLB entries for later
accessing.
This patch also rewrite flush_tlb_range for 2 purposes:
1, split it out to get flush_blt_mm_range function.
2, clean up to reduce line breaking, thanks for Borislav's input.
My micro benchmark 'mummap' http://lkml.org/lkml/2012/5/17/59
show that the random memory access on other CPU has 0~50% speed up
on a 2P * 4cores * HT NHM EP while do 'munmap'.
Thanks Yongjie's testing on this patch:
-
I used Linux 3.4-RC6 w/ and w/o his patches as Xen dom0 and guest
kernel.
After running two benchmarks in Xen HVM guest, I found his patches
brought about 1%~3% performance gain in 'kernel build' and 'netperf'
testing, though the performance gain was not very stable in 'kernel
build' testing.
Some detailed testing results are below.
Testing Environment:
Hardware: Romley-EP platform
Xen version: latest upstream
Linux kernel: 3.4-RC6
Guest vCPU number: 8
NIC: Intel 82599 (10GB bandwidth)
In 'kernel build' testing in guest:
Command line | performance gain
make -j 4 |3.81%
make -j 8 |0.37%
make -j 16 |-0.52%
In 'netperf' testing, we tested TCP_STREAM with default socket size
16384 byte as large packet and 64 byte as small packet.
I used several clients to add networking pressure, then 'netperf' server
automatically generated several threads to response them.
I also used large-size packet and small-size packet in the testing.
Packet size | Thread number | performance gain
16384 bytes | 4 | 0.02%
16384 bytes | 8 | 2.21%
16384 bytes | 16 | 2.04%
64 bytes | 4 | 1.07%
64 bytes | 8 | 3.31%
64 bytes | 16 | 0.71%
This patch also fold a flush_tlb_mm_range() fixing in 'make allnoconfig'
, that reported by Tetsuo Handa. Thanks!
Signed-off-by: Alex Shi
Tested-by: Ren, Yongjie
---
arch/x86/include/asm/tlb.h |9 +++-
arch/x86/include/asm/tlbflush.h | 17 +-
arch/x86/mm/tlb.c | 112 ---
3 files changed, 68 insertions(+), 70 deletions(-)
diff --git a/arch/x86/include/asm/tlb.h b/arch/x86/include/asm/tlb.h
index 829215f..4fef207 100644
--- a/arch/x86/include/asm/tlb.h
+++ b/arch/x86/include/asm/tlb.h
@@ -4,7 +4,14 @@
#define tlb_start_vma(tlb, vma) do { } while (0)
#define tlb_end_vma(tlb, vma) do { } while (0)
#define __tlb_remove_tlb_entry(tlb, ptep, address) do { } while (0)
-#define tlb_flush(tlb) flush_tlb_mm((tlb)->mm)
+
+#define tlb_flush(tlb) \
+{ \
+ if (tlb->fullmm == 0) \
+ flush_tlb_mm_range(tlb->mm, tlb->start, tlb->end, 0UL); \
+ else\
+ flush_tlb_mm_range(tlb->mm, 0UL, TLB_FLUSH_ALL, 0UL); \
+}
#include
diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index 33608d9..4fc8faf 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -105,6 +105,13 @@ static inline void flush_tlb_range(struct vm_area_struct
*vma,
__flush_tlb();
}
+static inline void flush_tlb_mm_range(struct mm_struct *mm,
+ unsigned long start, unsigned long end, unsigned long vmflag)
+{
+ if (mm == current->active_mm)
+ __flush_tlb();
+}
+
static inline void native_flush_tlb_others(const struct cpumask *cpumask,
struct mm_struct *mm,
unsigned long start,
@@ -122,12 +129,16 @@ static inline void reset_lazy_tlbstate(void)
#define local_flush_tlb() __flush_tlb()
+#define flush_tlb_mm(mm) flush_tlb_mm_range(mm, 0UL, TLB_FLUSH_ALL, 0UL)
+
+#define flush_tlb_range(vma, start, end) \
+ flush_tlb_mm_range(vma->vm_mm, start, end, vma->vm_flags)
+
extern void flush_tlb_all(void);
extern void flush_tlb_current_task(void);
-extern void
Re: [PATCH v10 7/9] x86/tlb: enable tlb flush range support for x86
On 07/19/2012 04:52 PM, Alex Shi wrote: > > Sure, it is a bug, the fix had sent: > https://lkml.org/lkml/2012/7/6/350 > Could you please re-send that as a clean patch? -hpa -- 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 00/90] staging: comedi: cleanup the pci_dev usage
On Thursday, July 19, 2012 4:53 PM, Greg KH wrote: > On Wed, Jul 18, 2012 at 06:23:20PM -0700, H Hartley Sweeten wrote: >> All the comedi pci drivers currently store a pointer to the pci_dev >> in their private data. We can use the 'struct device *hw_dev' variable >> in the comedi_device struct instead and introduce a wrapper for >> to_pci_dev() to allow the drivers to easily get the pci_dev. >> >> This patchset does just that. It also removes the private data from >> the drivers that no longer needed it. >> >> Some of the drivers required a bit of cleanup to their "find pci device" >> code or the private data in order to make the conversion cleaner. >> >> There are still a couple drivers, specifically the ni and addi ones, >> that need additional work before they can be converted cleanly. > > I've applied all of these (with the updated 01/90 patch). Can you > please send follow-on patches to resolve the issues that Ian pointed > out? Thanks! I was a bit worried about having to repost the whole set again. ;-) I'm working on the issues now. You should see it tomorrow. Regards, Hartley -- 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 15/90] staging: comedi: adv_pci1723: move comedi_pci_enable() into the attach
On Thursday, July 19, 2012 4:35 PM, gregkh wrote: > On Thu, Jul 19, 2012 at 06:31:23PM -0500, H Hartley Sweeten wrote: >> If the comedi pci drivers have the "attach_pci" callback defined, the >> PCI api does correctly probe the driver. The comedi_pci_auto_config() >> then passes the pci_dev directly to the driver and the search of the >> PCI space for the device is not required. >> >> If the "attach_pci" callback is not defined, the comedi_pci_auto_config() >> then falls back to passing the bus/slot information to the driver and uses >> the "attach" callback. In this case we could probably fast-track the search >> by using pci_get_slot() instead of doing the for_each_pci_dev() loop. >> >> I think the problem is the COMEDI_DEVCONFIG ioctl. The userspace >> utility 'comedi_config' uses that ioctl to link a device node to a >> comedi driver. That utility allows passing the bus/slot information >> but it's not required. This means we have to search the PCI space >> for the pci_dev that matches the driver. > > The ioctl shouldn't be needed anymore for PCI or USB devices, as the > kernel handles the matching of the driver to the device. Even if it > didn't, there are other more "standard" ways that you can bind devices > to drivers (through sysfs.) I think it's still needed for some of the devices that require external firmware. The comedi_config utility allows the user to remove the driver binding and then reattach to it while passing the firmware blob into the driver. Not saying any of this is valid... And yes, there probably is a more "standard" way to do this. I just need a hint of what that is... ;-) > So, I'd really recommend ripping all of this logic out for PCI drivers > as odds are, it's not used, and probably doesn't really work. Ian Abbott is probably the best source to answer that. > For old ISA cards, it makes sense, but the odds that anyone uses any ISA > devices is pretty slim. I lot of the ISA drivers actually work for PC/104 variations of the boards. I think they are still used somewhat. But yes, the pure ISA cards probably are not very common. It's almost impossible to actually find a PC that has ISA slots. Regards, Hartley -- 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: linux-next: manual merge of the staging tree with the target-merge tree
On Thu, Jul 19, 2012 at 02:53:01PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/Kconfig between commit d0146d396bfa ("tcm_vhost: Initial
> merge for vhost level target fabric driver") from the target-merge tree
> and commit 15a4bc17b7f4 ("Staging: add CSR Wifi "os helper" module") from
> the staging tree.
>
> Just context changes. I fixed it up (see below) and can carry the fix as
> necessary.
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
> diff --cc drivers/staging/Kconfig
> index 67ec9fe,e3402d5..000
> --- a/drivers/staging/Kconfig
> +++ b/drivers/staging/Kconfig
> @@@ -132,6 -132,8 +132,10 @@@ source "drivers/staging/ipack/Kconfig
>
> source "drivers/staging/gdm72xx/Kconfig"
>
> + source "drivers/staging/csr/Kconfig"
> +
> + source "drivers/staging/omap-thermal/Kconfig"
> +
> +source "drivers/vhost/Kconfig.tcm"
Why is someone putting a non drivers/staging/ Kconfig file here in
drivers/staging/Kconfig? That's not ok at all.
Target people, please just depend on CONFIG_STAGING if you want to do
that, but don't mess with files in the drivers/staging/ directory for no
good reason at all.
thanks,
greg k-h
--
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 00/90] staging: comedi: cleanup the pci_dev usage
On Wed, Jul 18, 2012 at 06:23:20PM -0700, H Hartley Sweeten wrote: > All the comedi pci drivers currently store a pointer to the pci_dev > in their private data. We can use the 'struct device *hw_dev' variable > in the comedi_device struct instead and introduce a wrapper for > to_pci_dev() to allow the drivers to easily get the pci_dev. > > This patchset does just that. It also removes the private data from > the drivers that no longer needed it. > > Some of the drivers required a bit of cleanup to their "find pci device" > code or the private data in order to make the conversion cleaner. > > There are still a couple drivers, specifically the ni and addi ones, > that need additional work before they can be converted cleanly. I've applied all of these (with the updated 01/90 patch). Can you please send follow-on patches to resolve the issues that Ian pointed out? thanks, greg k-h -- 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 v10 7/9] x86/tlb: enable tlb flush range support for x86
>> +static inline void flush_tlb_mm_range(struct vm_area_struct *vma,
>> + unsigned long start, unsigned long end, unsigned long vmflag)
>> +{
>> +if (vma->vm_mm == current->active_mm)
>> +__flush_tlb();
>> +}
>
> There's a problem with this in one of my randconfig tests. It has
> !CONFIG_SMP and the warning is:
>
> mm/memory.c: In function ‘tlb_flush_mmu’:
> mm/memory.c:230:2: warning: passing argument 1 of ‘flush_tlb_mm_range’ from
> incompatible pointer type
> /usr/src/linux-2.6/arch/x86/include/asm/tlbflush.h:108:20: note: expected
> ‘struct vm_area_struct *’ but argument is of type ‘struct mm_struct *’
> mm/memory.c:230:2: warning: passing argument 1 of ‘flush_tlb_mm_range’ from
> incompatible pointer type
> /usr/src/linux-2.6/arch/x86/include/asm/tlbflush.h:108:20: note: expected
> ‘struct vm_area_struct *’ but argument is of type ‘struct mm_struct *’
>
>
> Due to the fact that the macro flush_tlb actually resolves to
> flush_tlb_mm_range and this function has a different signature based on
> CONFIG_SMP. On !SMP expects struct vm_area_struct * as a first argument
> but on SMP its first argument is struct mm_struct *.
>
> So two different function signatures based on a config option? Now
> that's a first. What is going on?
Sure, it is a bug, the fix had sent:
https://lkml.org/lkml/2012/7/6/350
>
--
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 1/4] ACPI: Add acpi_pr_() interfaces
On Thu, 2012-07-19 at 16:32 -0600, Shuah Khan wrote: > On Thu, 2012-07-19 at 14:51 -0600, Toshi Kani wrote: > > > If your concern is actually a performance bottleneck in acpi_get_name() > > you found in the code, you should report it to the ACPI CA team. > > I have tried my best to get you to understand the problems in bigger > picture your patch set can exacerbate. Looking to somebody else to fix > the problems doesn't help. It doesn't look like we can come to an > agreement here, we just have to agree to disagree. I am not asking someone to fix it. I tried my best to explain that acpi_get_name() does not lead any performance issue when it is called in the error paths of ACPI drivers, and why we have to call it to obtain an object path info for error analysis. If you still believe there is a performance issue in calling acpi_get_name() under this context, please help us understand where the performance bottleneck is in the code. (I hope you just concerned it because it has "acpi_" prefix...) I will then work on the issue with the ACPI CA team. Thanks, -Toshi > caio, > -- Shuah > -- 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/
[PATCH] pstore/ram: Fix possible NULL dereference
We can dereference 'cxt->cprz' if console and dump logging are disabled
(which is unlikely, but still possible to do). This patch fixes the issue
by changing the code so that we don't dereference przs at all, we can
just calculate bufsize from console_size and record_size values.
Plus, while at it, the patch improves the buffer size calculation.
After Kay's printk rework, we know the optimal buffer size for console
logging -- it is LOG_LINE_MAX (defined privately in printk.c). Previously,
if only console logging was enabled, we would allocate unnecessary large
buffer in pstore, while we only need LOG_LINE_MAX. (Pstore console logging
is still capable of handling buffers > LOG_LINE_MAX, it will just do
multiple calls to psinfo->write).
Note that I don't export the constant, since we will do even a better
thing soon: we will switch console logging to a new write_buf API, which
will eliminate the need for the additional buffer; and so we won't need
the constant.
Reported-by: Dan Carpenter
Signed-off-by: Anton Vorontsov
---
fs/pstore/ram.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index b86b2b7..c34fccf 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -414,13 +414,14 @@ static int __devinit ramoops_probe(struct platform_device
*pdev)
cxt->pstore.data = cxt;
/*
-* Console can handle any buffer size, so prefer dumps buffer
-* size since usually it is smaller.
+* Console can handle any buffer size, so prefer LOG_LINE_MAX. If we
+* have to handle dumps, we must have at least record_size buffer. And
+* for ftrace, bufsize is irrelevant (if bufsize is 0, buf will be
+* ZERO_SIZE_PTR).
*/
- if (cxt->przs)
- cxt->pstore.bufsize = cxt->przs[0]->buffer_size;
- else
- cxt->pstore.bufsize = cxt->cprz->buffer_size;
+ if (cxt->console_size)
+ cxt->pstore.bufsize = 1024; /* LOG_LINE_MAX */
+ cxt->pstore.bufsize = max(cxt->record_size, cxt->pstore.bufsize);
cxt->pstore.buf = kmalloc(cxt->pstore.bufsize, GFP_KERNEL);
spin_lock_init(>pstore.buf_lock);
if (!cxt->pstore.buf) {
--
1.7.10.4
--
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: [RFC][PATCH v2 2/3] Hold multiple logs
> If you are concerned about multiple OOPS case, I think an user app which logs > from /dev/pstore to /var/log should be developed. Agreed - we need an app/daemon to do this. > Once it is developed, we don't need to care about multiple oops case and the > appropriate number is two. Only if you can guarantee that the app/daemon will run and save the first OOPS before the next occurs. Even if the system were running normally this might be difficult to achieve ... but in this case we know the system isn't running normally (it just OOPSed twice!). However - there is progressively less value in collecting additional consecutive OOPS. Perhaps one is enough 90% or even 99% of the time. I'm naturally paranoid so having two or three would make me feel happy that most of the remaining 10% or 1% of the cases were covered. > - In case where system is workable after oops. > The user app will erase an entry in NVRAM. > And we can get the message via /var/log. Yes - the system can keep running after many types of OOPs - so the OOPS will be logged in /var/log (or by the app/daemon copying from pstore, or both). > - In case where system hangs up or panics due to the oops. > Oops is the critical message and we don't need care about subsequent events. Yes - if the OOPs is instrumental in the path leading to the hang/panic - then the OOPS is the first place to look for the root cause of the problem. But it will be a case by case analysis. Sometimes the OOPS might be unconnected. If possible we'd like to log more information to allow detective work to decide whether there is a connection. But as I mentioned above there are severe limits to how much better things are by storing more information. -Tony -- 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 WIP 6/6] xen/arm: enable evtchn irqs
> > OK, please include those questions/answers in the git commit and
> > repost.
I seem to be missing the rest of the patches. I see the drivers/xen/events also
has the xen_init_IRQ_arm... is there a git tree with the base patches?
>
> ---
>
> xen/arm: enable evtchn irqs
>
> On ARM Linux irqs are not enabled by default:
>
> - call enable_percpu_irq for IRQ_EVTCHN_CALLBACK (drivers are supposed
> to call enable_irq after request_irq);
>
> - set the IRQF_VALID flag for the other irqs bound to evtchns. It causes
> IRQ_NOAUTOEN to be set and as a consequence irq_unmask is going to be
> called when a xenbus driver calls request_irq.
> This is needed because IRQ_NOAUTOEN is set by set_irq_flags on ARM.
> If IRQ_NOAUTOEN is set __setup_irq doesn't call irq_startup that is
> responsible for calling irq_unmask at startup time.
>
> Signed-off-by: Stefano Stabellini
>
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index eae0d0b..ca92755 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -53,6 +53,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * This lock protects updates to the following mapping and reference-count
> @@ -824,6 +828,7 @@ int bind_evtchn_to_irq(unsigned int evtchn)
>
> xen_irq_info_evtchn_init(irq, evtchn);
> }
> + set_irq_flags(irq, IRQF_VALID);
>
> out:
> mutex_unlock(_mapping_update_lock);
> @@ -1748,6 +1753,7 @@ int __init xen_init_IRQ_arm(void)
> if (rc) {
> printk(KERN_ERR "Error requesting IRQ %d\n",
> IRQ_EVTCHN_CALLBACK);
> }
> + enable_percpu_irq(IRQ_EVTCHN_CALLBACK, 0);
> return rc;
> }
> core_initcall(xen_init_IRQ_arm);
--
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 15/90] staging: comedi: adv_pci1723: move comedi_pci_enable() into the attach
On Thu, Jul 19, 2012 at 06:31:23PM -0500, H Hartley Sweeten wrote:
> On Thursday, July 19, 2012 4:17 PM, gregkh wrote:
> > On Thu, Jul 19, 2012 at 12:12:02PM -0500, H Hartley Sweeten wrote:
> >> I was planning on making a comedi_find_pci_dev() function that the
> >> drivers could call with a "match" callback. This would allow a common
> >> function for most of the boilerplate code and just require the drivers
> >> to check the the match against the boardinfo dev/id, etc. as required.
> >> Something like:
> >>
> >> struct pci_dev *comedi_find_pci_dev(struct comedi_device *dev,
> >>struct comedi_devconfig *it,
> >>const void *(*match)(struct comedi_device *,
> >>struct pci_dev *))
> >> {
> >>struct pci_dev *pcidev = NULL;
> >>int bus = it->options[0];
> >>int slot = it->options[1];
> >>
> >>for_each_pci_dev(pcidev) {
> >>/* pci_is_enabled() test? */
> >>if ((bus && bus != pcidev->bus->number) ||
> >>(slot && slot != PCI_SLOT(pcidev->devfn)))
> >>continue;
> >>dev->board_ptr = match(dev, pcidev);
> >>if (dev->board_ptr) {
> >>comedi_set_hw_dev(dev, >dev);
> >>return pcidev;
> >>}
> >>}
> >>return NULL;
> >> }
> >>
> >> The "match" function for a driver would then just be something like:
> >>
> >> const void *match_pci(struct comedi_device *dev, struct pci_dev *pcidev)
> >> {
> >>const struct boardinfo *board;
> >>int i;
> >>
> >>for (i = 0; i < ARRAY_SIZE(boardinfo); i++) {
> >>board = [i];
> >>if (pcidev->vendor != board->ven_id ||
> >>pcidev->device != board->dev_id)
> >>continue;
> >>return board;
> >>}
> >>return NULL;
> >> }
> >>
> >> This would require adding a dummy boardinfo to some of the drivers but
> >> I think it's cleaner.
> >>
> >> Comments?
> >
> > Ick. What ever happened to converting these drivers to use the PCI api
> > correctly and not to search the PCI space for the device, but have the
> > PCI core call them if the device is found?
> >
> > It looks like most of these drivers have already been converted to that
> > style, so these checks for "do we find a device" can all be removed
> > entirely now, right? There's no way the functions would be called if
> > the device wasn't found in the first place.
> >
> > Or am I missing something here?
>
> If the comedi pci drivers have the "attach_pci" callback defined, the
> PCI api does correctly probe the driver. The comedi_pci_auto_config()
> then passes the pci_dev directly to the driver and the search of the
> PCI space for the device is not required.
>
> If the "attach_pci" callback is not defined, the comedi_pci_auto_config()
> then falls back to passing the bus/slot information to the driver and uses
> the "attach" callback. In this case we could probably fast-track the search
> by using pci_get_slot() instead of doing the for_each_pci_dev() loop.
>
> I think the problem is the COMEDI_DEVCONFIG ioctl. The userspace
> utility 'comedi_config' uses that ioctl to link a device node to a
> comedi driver. That utility allows passing the bus/slot information
> but it's not required. This means we have to search the PCI space
> for the pci_dev that matches the driver.
The ioctl shouldn't be needed anymore for PCI or USB devices, as the
kernel handles the matching of the driver to the device. Even if it
didn't, there are other more "standard" ways that you can bind devices
to drivers (through sysfs.)
So, I'd really recommend ripping all of this logic out for PCI drivers
as odds are, it's not used, and probably doesn't really work.
For old ISA cards, it makes sense, but the odds that anyone uses any ISA
devices is pretty slim.
thanks,
greg k-h
--
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/
[PATCH] Cgroup: Fix memory accounting scalability in shrink_page_list
Hi,
I noticed in a multi-process parallel files reading benchmark I ran on a
8 socket machine, throughput slowed down by a factor of 8 when I ran
the benchmark within a cgroup container. I traced the problem to the
following code path (see below) when we are trying to reclaim memory
from file cache. The res_counter_uncharge function is called on every
page that's reclaimed and created heavy lock contention. The patch
below allows the reclaimed pages to be uncharged from the resource
counter in batch and recovered the regression.
Tim
40.67% usemem [kernel.kallsyms] [k]
_raw_spin_lock
|
--- _raw_spin_lock
|
|--92.61%-- res_counter_uncharge
| |
| |--100.00%-- __mem_cgroup_uncharge_common
| | |
| | |--100.00%--
mem_cgroup_uncharge_cache_page
| | | __remove_mapping
| | | shrink_page_list
| | | shrink_inactive_list
| | | shrink_mem_cgroup_zone
| | | shrink_zone
| | | do_try_to_free_pages
| | | try_to_free_pages
| | | __alloc_pages_nodemask
| | | alloc_pages_current
---
Signed-off-by: Tim Chen
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 33dc256..aac5672 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -779,6 +779,7 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
cond_resched();
+ mem_cgroup_uncharge_start();
while (!list_empty(page_list)) {
enum page_references references;
struct address_space *mapping;
@@ -1026,6 +1027,7 @@ keep_lumpy:
list_splice(_pages, page_list);
count_vm_events(PGACTIVATE, pgactivate);
+ mem_cgroup_uncharge_end();
*ret_nr_dirty += nr_dirty;
*ret_nr_writeback += nr_writeback;
return nr_reclaimed;
--
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 15/90] staging: comedi: adv_pci1723: move comedi_pci_enable() into the attach
On Thursday, July 19, 2012 4:17 PM, gregkh wrote:
> On Thu, Jul 19, 2012 at 12:12:02PM -0500, H Hartley Sweeten wrote:
>> I was planning on making a comedi_find_pci_dev() function that the
>> drivers could call with a "match" callback. This would allow a common
>> function for most of the boilerplate code and just require the drivers
>> to check the the match against the boardinfo dev/id, etc. as required.
>> Something like:
>>
>> struct pci_dev *comedi_find_pci_dev(struct comedi_device *dev,
>> struct comedi_devconfig *it,
>> const void *(*match)(struct comedi_device *,
>> struct pci_dev *))
>> {
>> struct pci_dev *pcidev = NULL;
>> int bus = it->options[0];
>> int slot = it->options[1];
>>
>> for_each_pci_dev(pcidev) {
>> /* pci_is_enabled() test? */
>> if ((bus && bus != pcidev->bus->number) ||
>> (slot && slot != PCI_SLOT(pcidev->devfn)))
>> continue;
>> dev->board_ptr = match(dev, pcidev);
>> if (dev->board_ptr) {
>> comedi_set_hw_dev(dev, >dev);
>> return pcidev;
>> }
>> }
>> return NULL;
>> }
>>
>> The "match" function for a driver would then just be something like:
>>
>> const void *match_pci(struct comedi_device *dev, struct pci_dev *pcidev)
>> {
>> const struct boardinfo *board;
>> int i;
>>
>> for (i = 0; i < ARRAY_SIZE(boardinfo); i++) {
>> board = [i];
>> if (pcidev->vendor != board->ven_id ||
>> pcidev->device != board->dev_id)
>> continue;
>> return board;
>> }
>> return NULL;
>> }
>>
>> This would require adding a dummy boardinfo to some of the drivers but
>> I think it's cleaner.
>>
>> Comments?
>
> Ick. What ever happened to converting these drivers to use the PCI api
> correctly and not to search the PCI space for the device, but have the
> PCI core call them if the device is found?
>
> It looks like most of these drivers have already been converted to that
> style, so these checks for "do we find a device" can all be removed
> entirely now, right? There's no way the functions would be called if
> the device wasn't found in the first place.
>
> Or am I missing something here?
If the comedi pci drivers have the "attach_pci" callback defined, the
PCI api does correctly probe the driver. The comedi_pci_auto_config()
then passes the pci_dev directly to the driver and the search of the
PCI space for the device is not required.
If the "attach_pci" callback is not defined, the comedi_pci_auto_config()
then falls back to passing the bus/slot information to the driver and uses
the "attach" callback. In this case we could probably fast-track the search
by using pci_get_slot() instead of doing the for_each_pci_dev() loop.
I think the problem is the COMEDI_DEVCONFIG ioctl. The userspace
utility 'comedi_config' uses that ioctl to link a device node to a
comedi driver. That utility allows passing the bus/slot information
but it's not required. This means we have to search the PCI space
for the pci_dev that matches the driver.
Not sure what to do here...
Regards,
Hartley
--
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: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory)
On Thu, Jul 19, 2012 at 10:30:38PM +, KY Srinivasan wrote: > > > As you know, this ID has been in use for a long time now. While the > > > hypervisor > > > does not interpret the guest ID that is registered, I am not sure what > > dependencies > > > there might be on this value. > > > > Could you please go find out the answer to this? > > That is easier said than done. I have sent emails out asking this very > question and I have > not received a definitive answer yet. Not knowing if and when I can get a > definitive > answer here, I chose the least risky approach in my patch. What happens if you test with different values? > > If, as you originally stated, there is a range of values we can use, > > then we should probably use another one, right? > > On the Windows side this ID namespace is managed well. It is? How is this managed? What does this tell the hypervisor? What changes with the different values? > However on the Linux side, we have really had this current ID in use > for almost five years now. I am not aware of any pool of IDs available > for Linux usage except that Linux IDs be distinct from the guest IDs > in use by MSFT operating systems. If I were to change the guest ID, I > would probably want to comply with the MSFT guidance on constructing > these IDs (although not all fields may be relevant for Linux). What are those rules? thanks, greg k-h -- 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: 3.5-rc6 futex_wait_requeue_pi oops.
On 07/13/2012 11:54 AM, Dave Jones wrote: > On Fri, Jul 13, 2012 at 08:47:38PM +0200, Thomas Gleixner wrote: > > On Fri, 13 Jul 2012, Dave Jones wrote: > > > > > Looks like calling futex() with garbage makes things unhappy. > > > > WARN_ON(!_state); > > pi_mutex = _state->pi_mutex; > > ret = rt_mutex_finish_proxy_lock(pi_mutex, to, _waiter, > 1); > > debug_rt_mutex_free_waiter(_waiter); > > > > So there is some weird way which causes q.pi_state = NULL. Dave, did > > you see the warning before the oops happened ? > > No, that didn't seem to trigger. Well I don't have a fix yet, but I can explain this not triggering. q is on the stack, so the ADDRESS for q.pi_state is never going to be NULL. However, properly instrumented, we do see this: [ 23.621501] ---[ end trace 20bdfb44db182a17 ]--- [ 23.622425] q.pi_state @ (null) [ 23.623272] _state @ 880185e2dca8 [ 23.624119] [ cut here ] Duh. I'll add a fix to that WARN_ON in my futex-fixes branch along with the fix for the bug Dan found. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel -- 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: pstore/ram: Add ftrace messages handling
Hi Dan, On Thu, Jul 19, 2012 at 05:28:56PM +0300, Dan Carpenter wrote: > The patch a694d1b5916a: "pstore/ram: Add ftrace messages handling" > from Jul 9, 2012, leads to the following Smatch complaint: A nice tool. The homepage of Smatch doesn't explicitly say that, so I have to ask: is it a complete superset of sparse (i.e. does it produce all the warnings that the pure sparse can produce)? If so, I'll probably switch to it from the vanilla sparse. Thanks, -- Anton Vorontsov Email: cbouatmai...@gmail.com -- 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: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory)
On 07/19/2012 05:30 PM, KY Srinivasan wrote: -Original Message- From: Greg KH (gre...@linuxfoundation.org) [mailto:gre...@linuxfoundation.org] Sent: Thursday, July 19, 2012 6:02 PM To: KY Srinivasan Cc: Paolo Bonzini; de...@linuxdriverproject.org; linux-kernel@vger.kernel.org; virtualizat...@lists.osdl.org Subject: Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory) On Thu, Jul 19, 2012 at 09:22:53PM +, KY Srinivasan wrote: -Original Message- From: Greg KH (gre...@linuxfoundation.org) [mailto:gre...@linuxfoundation.org] Sent: Thursday, July 19, 2012 5:07 PM To: KY Srinivasan Cc: Paolo Bonzini; de...@linuxdriverproject.org; linux- ker...@vger.kernel.org; virtualizat...@lists.osdl.org Subject: Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory) On Thu, Jul 19, 2012 at 02:11:47AM +, KY Srinivasan wrote: -Original Message- From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo Bonzini Sent: Friday, July 13, 2012 6:23 AM To: KY Srinivasan Cc: Greg KH; de...@linuxdriverproject.org; linux-kernel@vger.kernel.org; virtualizat...@lists.osdl.org Subject: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory) Il 04/10/2011 21:34, Greg KH ha scritto: diff --git a/drivers/staging/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h similarity index 99% rename from drivers/staging/hv/hyperv_vmbus.h rename to drivers/hv/hyperv_vmbus.h index 3d2d836..8261cb6 100644 --- a/drivers/staging/hv/hyperv_vmbus.h +++ b/drivers/hv/hyperv_vmbus.h @@ -28,8 +28,7 @@ #include #include #include - -#include "hyperv.h" +#include /* * The below CPUID leaves are present if VersionAndFeatures.HypervisorPresent git's rename detection snips away this gem: +#define HV_LINUX_GUEST_ID_LO 0x +#define HV_LINUX_GUEST_ID_HI 0xB16B00B5 +#define HV_LINUX_GUEST_ID (((u64)HV_LINUX_GUEST_ID_HI << 32) | \ + HV_LINUX_GUEST_ID_LO) Somone was trying to be funny, I guess. KY, I suppose you have access to Hyper-V code or can ask someone who does. Is this signature actually used in the Hyper-V host code? Paolo, As I noted earlier, this is just a guest ID that needs to be registered with the hypervisor. Thanks for reporting this issue and on behalf of Microsoft, I would like to apologize for this offensive string. I have submitted a patch to fix this issue. You only changed it to be in decimal, you did not change the id at all. Is there some reason why you can not change it? You said there was a reserved range of ids that could be used, perhaps just pick another one? What is the valid range that can be used here? Greg, As you know, this ID has been in use for a long time now. While the hypervisor does not interpret the guest ID that is registered, I am not sure what dependencies there might be on this value. Could you please go find out the answer to this? That is easier said than done. I have sent emails out asking this very question and I have not received a definitive answer yet. Not knowing if and when I can get a definitive answer here, I chose the least risky approach in my patch. If, as you originally stated, there is a range of values we can use, then we should probably use another one, right? On the Windows side this ID namespace is managed well. However on the Linux side, we have really had this current ID in use for almost five years now. I am not aware of any pool of IDs available for Linux usage except that Linux IDs be distinct from the guest IDs in use by MSFT operating systems. If I were to change the guest ID, I would probably want to comply with the MSFT guidance on constructing these IDs (although not all fields may be relevant for Linux). Presumably, Hyper-V can deal with unexpected values here, no? Otherwise, it wouldn't be future proof against new types of guests. So worst case scenario, Hyper-V disables optimizations on Linux guests that report then new ID until they patch Hyper-V to know about the new ID. That seems like a reasonable trade off to me. I'm sure there's sufficient incentive to patch Hyper-V for this at Microsoft... Regards, Anthony Liguori Regards, K. Y -- 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 15/90] staging: comedi: adv_pci1723: move comedi_pci_enable() into the attach
On Thu, Jul 19, 2012 at 12:12:02PM -0500, H Hartley Sweeten wrote:
> On Thursday, July 19, 2012 2:38 AM, Ian Abbott wrote:
> > On 2012-07-19 02:30, H Hartley Sweeten wrote:
> >> Use pci_is_enabled() in the "find pci device" function to determine if
> >> the found pci device is not in use and move the comedi_pci_enable() call
> >> into the attach.
> >>
> >> Signed-off-by: H Hartley Sweeten
> >> Cc: Ian Abbott
> >> Cc: Greg Kroah-Hartman
> >> ---
> >> drivers/staging/comedi/drivers/adv_pci1723.c | 10 +-
> >> 1 file changed, 5 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/staging/comedi/drivers/adv_pci1723.c
> >> b/drivers/staging/comedi/drivers/adv_pci1723.c
> >> index f561a2a..e971fa6 100644
> >> --- a/drivers/staging/comedi/drivers/adv_pci1723.c
> >> +++ b/drivers/staging/comedi/drivers/adv_pci1723.c
> >> @@ -302,11 +302,7 @@ static struct pci_dev *pci1723_find_pci_dev(struct
> >> comedi_device *dev,
> >>}
> >>if (pcidev->vendor != PCI_VENDOR_ID_ADVANTECH)
> >>continue;
> >> - /*
> >> - * Look for device that isn't in use.
> >> - * Enable PCI device and request regions.
> >> - */
> >> - if (comedi_pci_enable(pcidev, "adv_pci1723"))
> >> + if (pci_is_enabled(pcidev))
> >>continue;
> >>return pcidev;
> >>}
> >
> > Just because the device is enabled doesn't mean that it is in use, so
> > this change could skip over a perfectly good unused device.
>
> Are you sure? According to Documentation/PCI/pci.txt, the first thing
> a driver "should" do when taking ownership of a PCI device is enable
> the device. The last thing it "should" do when being unloaded is
> disable the device.
>
> It would seem that checking pci_is_enabled() would let us know that
> the pci_dev in question is being used.
>
> > If you want to move the comedi_pci_enable() call, this is a change in
> > behaviour for this particular driver, but is consistent with most of the
> > other Comedi PCI drivers (and the bus/slot options can be used to select
> > a particular device). This is probably a good thing, but you should
> > take out the pci_is_enabled test.
>
> I was curious about this.
>
> In the original driver, doing an 'attach' with bus/slot both = 0 would result
> in the pci bus being walked to find the first device that could be enabled
> (i.e. a "free" device) and using that device. This allows doing the 'attach'
> with more than one card installed and being able to attach to each one
> by simply:
>
> comedi_config /dev/comedi0 adv_pci1723
> comedi_config /dev/comedi1 adv_pci1723
> etc.
>
> The "normal" operation for the comedi pci drivers appears to require
> the bus/slot information when multiple devices are used. Or implement
> the 'attach_pci' callback in the comedi_driver and allow the core to
> simply pass the pci_dev directly to the driver.
>
> What would you prefer?
>
> I was planning on making a comedi_find_pci_dev() function that the
> drivers could call with a "match" callback. This would allow a common
> function for most of the boilerplate code and just require the drivers
> to check the the match against the boardinfo dev/id, etc. as required.
> Something like:
>
> struct pci_dev *comedi_find_pci_dev(struct comedi_device *dev,
> struct comedi_devconfig *it,
> const void *(*match)(struct comedi_device *,
> struct pci_dev *))
> {
> struct pci_dev *pcidev = NULL;
> int bus = it->options[0];
> int slot = it->options[1];
>
> for_each_pci_dev(pcidev) {
> /* pci_is_enabled() test? */
> if ((bus && bus != pcidev->bus->number) ||
> (slot && slot != PCI_SLOT(pcidev->devfn)))
> continue;
> dev->board_ptr = match(dev, pcidev);
> if (dev->board_ptr) {
> comedi_set_hw_dev(dev, >dev);
> return pcidev;
> }
> }
> return NULL;
> }
>
> The "match" function for a driver would then just be something like:
>
> const void *match_pci(struct comedi_device *dev, struct pci_dev *pcidev)
> {
> const struct boardinfo *board;
> int i;
>
> for (i = 0; i < ARRAY_SIZE(boardinfo); i++) {
> board = [i];
> if (pcidev->vendor != board->ven_id ||
> pcidev->device != board->dev_id)
> continue;
> return board;
> }
> return NULL;
> }
>
> This would require adding a dummy boardinfo to some of the drivers but
> I think it's cleaner.
>
> Comments?
Ick. What ever happened to converting these drivers to use the PCI api
correctly and not to search the PCI space for the device, but have the
PCI core call them if the device is found?
It looks like most of these drivers have already been converted to that
style, so these checks for "do we find a
RE: [RFC][PATCH v2 2/3] Hold multiple logs
> > I think that 3 or 4 logs should be plenty to cover almost all situations. E.g. > with 3 logs you could capture 2 OOPS (and perhaps miss some other OOPS) and > then get the final panic that kills the system. Messier > crashes are of course possible ... but that would give lots of clues on where > the problems lie. > Thank you for letting my know your idea. Let me explain my opinion. If you are concerned about multiple OOPS case, I think an user app which logs from /dev/pstore to /var/log should be developed. Once it is developed, we don't need to care about multiple oops case and the appropriate number is two. - In case where system is workable after oops. The user app will erase an entry in NVRAM. And we can get the message via /var/log. - In case where system hangs up or panics due to the oops. Oops is the critical message and we don't need care about subsequent events. What do you think? > If you don't know what is the appropriate number ... then how will users > decide? We should really give them some guidance ... > especially if there are odd problems[1] if they pick a number that is too big. You are right. There is no user app above right now. So, I was in stuck... But I understand I shouldn't have introduce efi_pstore_log_num. Seiji -- 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: [RFC][PATCH 2/4 v4] ftrace/x86: Add save_regs for i386 function calls
On 07/19/2012 04:04 PM, Steven Rostedt wrote: > On Thu, 2012-07-19 at 15:53 -0700, H. Peter Anvin wrote: > >> lea is not typically faster than add, but in the case of Atom, it is >> done in an earlier pipeline stage (AGU instead of ALU) which means lea >> is faster if its inputs are already available as address expressions and >> is consumed by address expressions; the goal is to avoid the ALU->AGU >> forwarding latency. > > Well, the question is, which is faster: > > lea 8(%esp), %esp > addl $8, %esp > > Basically, all we want to do is add 8 to the stack pointer. And this is > for the x86_32 version of whatever hardware is in use. > What I'm telling you is that it depends on the context. An address expression needs to be ready in the AGU; a piece of data comes from the ALU. Whenever something moves from the ALU to the AGU, there is a penalty. There is no penalty to move from the AGU to the ALU, since the ALU is in a later stage. I *believe* the stack adjustments push/pop are done in the AGU, but I have to double-check. -hpa -- 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: [RFC][PATCH 2/4 v4] ftrace/x86: Add save_regs for i386 function calls
On Thu, 2012-07-19 at 15:53 -0700, H. Peter Anvin wrote: > lea is not typically faster than add, but in the case of Atom, it is > done in an earlier pipeline stage (AGU instead of ALU) which means lea > is faster if its inputs are already available as address expressions and > is consumed by address expressions; the goal is to avoid the ALU->AGU > forwarding latency. Well, the question is, which is faster: lea 8(%esp), %esp addl $8, %esp Basically, all we want to do is add 8 to the stack pointer. And this is for the x86_32 version of whatever hardware is in use. -- Steve -- 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] isp1362-hcd.c: usb message always saved in case of underrun
On Wed, Jul 18, 2012 at 10:53:09AM +0200, Claudio Scordino wrote:
> Il 06/07/2012 19:41, Greg KH ha scritto:
> >On Wed, Jun 27, 2012 at 06:01:39PM +0200, Claudio Scordino wrote:
> >>Hi Olav,
> >>
> >>please find below a patch for the isp1362-hcd.c driver to always
> >>save the message in case of underrun. More information is provided
> >>inside the patch comment. Let us know if you need any further
> >>information.
> >>
> >>Best regards,
> >>
> >>Claudio
> >>
> >>
> >>Subject: isp1362-hcd.c: usb message always saved in case of underrun
> >>From: Bruno Morelli
> >>
> >>The usb message must be saved also in case the USB endpoint is not a
> >>control endpoint (i.e., "endpoint 0"), otherwise in some circumstances
> >>we don't have a payload in case of error.
> >>
> >>The patch has been created by tracing with usbmon the different error
> >>messages generated by this driver with respect to the ehci-hcd driver.
> >>
> >>Signed-off-by: Bruno Morelli
> >>Signed-off-by: Claudio Scordino
> >>Tested-by: Bruno Morelli
> >>---
> >> drivers/usb/host/isp1362-hcd.c | 11 ++-
> >> 1 files changed, 6 insertions(+), 5 deletions(-)
> >>
> >>diff --git a/drivers/usb/host/isp1362-hcd.c b/drivers/usb/host/isp1362-hcd.c
> >>index 2ed112d..61bf1b2 100644
> >>--- a/drivers/usb/host/isp1362-hcd.c
> >>+++ b/drivers/usb/host/isp1362-hcd.c
> >>@@ -543,13 +543,14 @@ static void postproc_ep(struct isp1362_hcd
> >>*isp1362_hcd, struct isp1362_ep *ep)
> >>usb_pipein(urb->pipe) ? "IN" : "OUT", ep->nextpid,
> >>short_ok ? "" : "not_",
> >>PTD_GET_COUNT(ptd), ep->maxpacket, len);
> >>+ /* save the data underrun error code for later and
> >>+* proceed with the status stage
> >>+*/
> >>+ urb->actual_length += PTD_GET_COUNT(ptd);
> >>+ BUG_ON(urb->actual_length>
> >>+ urb->transfer_buffer_length);
> >
> >Please NEVER crash the machine in a driver like this, it's bad and can
> >cause problems. Yes, I know you are just moving it from the lines
> >below:
> >
> >>if (usb_pipecontrol(urb->pipe)) {
> >>ep->nextpid = USB_PID_ACK;
> >>- /* save the data underrun error code for later
> >>and
> >>-* proceed with the status stage
> >>-*/
> >>- urb->actual_length += PTD_GET_COUNT(ptd);
> >>- BUG_ON(urb->actual_length>
> >>urb->transfer_buffer_length);
> >
> >But really, it should not be in the driver at all. Please remove it, at
> >the most, do a WARN_ON() so that someone can see the problem and at
> >least report it.
> >
> >Actually, what is this checking? How can someone recover from it? Who
> >is this check for? The developer of this driver? Another driver?
> >Hardware developer? End user? Who would be able to fix the problem if
> >this happens?
> >
> >As it is, I can't take it, sorry.
>
>
> Hi Greg.
>
> I understand. As you have already said, this driver is full of BUG_ON
> statements.
>
> So, we can shift just the assignment as in the patch below, to have a
> correct behavior, leaving the BUG_ON where it already is. Then, we may
> propose a different patch to change BUG_ONs to WARN_ONs.
Your updated patch is much better, thanks.
But it doesn't apply to my tree right now. Can you please refresh it
against the usb-next tree and resend it?
thanks,
greg k-h
--
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] kernel: acct.c: spaces required around that '<'
On Thu, Jul 19, 2012 at 10:10:27PM +0100, jan.bannis...@gmail.com wrote: > From: Jan Bannister > > Fixed a coding style issue NAK, because I'm sick and tired of the pompous commit messages. I'm fine with adding those spaces. However, I _do_ have a lot against the commit messages like that. "Required"? By whom? Holy checkpatch.pl? "Coding style issue" - completely uninformative; there all kinds of those. FWIW, my prefernce would be something along the lines of "whitespace tidy-up in ". At least that says what happens in commit and where is it happening... -- 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: [RFC][PATCH 2/4 v4] ftrace/x86: Add save_regs for i386 function calls
On 07/19/2012 05:58 AM, Steven Rostedt wrote: >> >> also, because lea is faster than add (and doesn't even modify flags), I >> changed the last part to use lea instead of addl. > > Now I'm told that this is not always the case (at least not for Atom), > so I reverted this part and put back the addl. But can you still give > you reviewed by for the first part? > lea is not typically faster than add, but in the case of Atom, it is done in an earlier pipeline stage (AGU instead of ALU) which means lea is faster if its inputs are already available as address expressions and is consumed by address expressions; the goal is to avoid the ALU->AGU forwarding latency. -hpa -- 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: [RFC] Simplifying kernel configuration for distro issues
On Thu, 2012-07-19 at 18:35 -0400, Josh Boyer wrote: > > >2... yeah. I don't really know if that is going to pan out, but I am > > >ever hopeful. I'd be mostly concerned with people that are coding > > >userspace applications using every whiz-bang kernel feature. Or not > > >paying attention at all to the kernel after the initial file creation > > >and the options going stale (don't follow renames, etc). > > > > it would be determined by the distro maintainers who maintain the > > kernel config for that distro. > > Erm... not in Steven's scheme. At least I don't think distro kernel > maintainers are going to willingly crawl through every application > package that might depend on a kernel feature being enabled and maintain > those files across X number of packages. Correct. If we keep the selects in the kernel proper, then it would be the kernel maintainer to make sure it works for the necessary applications. If we have a directory called /usr/share/Linux/Kconfig.d/ then the individual packages could add their needed selects. Now this wouldn't be for the average package. We don't need emacs developers adding any configs here. It's just for those packages that are already tightly coupled with the kernel (systemd, iptables, SELinux tools, etc). -- Steve -- 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 v3 0/6] mmc: dw_mmc: add support for device tree based instantiation
Thomas Abraham wrote: > > On 19 July 2012 20:58, Jaehoon Chung wrote: > > Hi Thomas, > > > > I think not good that added the samsung specific code into dw_mmc- > pltfm.c > > How about separating to dw-mmc-exynos.c? > > I am not sure of this. The only samsung specific code in > dw_mmc-pltfm.c file is the data for of_device_id instances. The clock > lookup added into this file in the 3rd patch does not cause any harm > on non-samsung SoC's which might not define those clocks (on clock > lookup failure, there are only warning printed, the driver's probe > does not fail. > I agree with Thomas' opinion, in addition, the dw_mmc-pltfm.c file can support that, so adding dw-mmc-exynos.c is not needed now. > I would prefer not to add separate file for Exynos SoC's for now. > Splitting into different files will need to defined new callbacks > which I fell is not really required. > Yes. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- 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 1/1 v3] Honor state disabling in the cpuidle ladder governor
On 07/19/2012 11:48 PM, Rafael J. Wysocki wrote: On Thursday, July 19, 2012, Carsten Emde wrote: There are two cpuidle governors ladder and menu. While the ladder governor is always available, if CONFIG_CPU_IDLE is selected, the menu governor additionally requires CONFIG_NO_HZ. A particular C state can be disabled by writing to the sysfs file /sys/devices/system/cpu/cpuN/cpuidle/stateN/disable, but this mechanism is only implemented in the menu governor. Thus, in a system where CONFIG_NO_HZ is not selected, the ladder governor becomes default and always will walk through all sleep states - irrespective of whether the C state was disabled via sysfs or not. The only way to select a specific C state was to write the related latency to /dev/cpu_dma_latency and keep the file open as long as this setting was required - not very practical and not suitable for setting a single core in an SMP system. With this patch, the ladder governor only will promote to the next C state, if it has not been disabled, and it will demote, if the current C state was disabled. Note that the patch does not make the setting of the sysfs variable "disable" coherent, i.e. if one is disabling a light state, then all deeper states are disabled as well, but the "disable" variable does not reflect it. Likewise, if one enables a deep state but a lighter state still is disabled, then this has no effect. A related section has been added to the documentation. Signed-off-by: Carsten Emde This looks fine to me, but it's too late for v3.6. I can queue it up for v3.7, though. Yes, please. Thanks, -Carsten. -- 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/
