[PATCH 5/6] arm: pxa27x.dtsi: add pwri2c definition
This adds the pwri2c definition to the pxa27x device tree. This is
already called out in pxa3xx.dtsi.
Signed-off-by: Andrew Ruder
---
arch/arm/boot/dts/pxa27x.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/pxa27x.dtsi b/arch/arm/boot/dts/pxa27x.dtsi
index 931e1d5..2d05aa9 100644
--- a/arch/arm/boot/dts/pxa27x.dtsi
+++ b/arch/arm/boot/dts/pxa27x.dtsi
@@ -34,5 +34,14 @@
reg = <0x40c00010 0x10>;
#pwm-cells = <1>;
};
+
+ pwri2c: i2c@40f00180 {
+ compatible = "mrvl,pxa-i2c";
+ reg = <0x40f00180 0x30>;
+ interrupts = <6>;
+ #address-cells = <0x1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
};
};
--
1.9.0.rc3.12.gbc97e2d
--
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/6] arm: pxa2xx.dtsi: compatible tags for usb, mmc
This changes pxa2xx.dtsi's compatible tags for MMC and USB to match both
the documentation and the code.
Signed-off-by: Andrew Ruder
---
arch/arm/boot/dts/pxa2xx.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/pxa2xx.dtsi b/arch/arm/boot/dts/pxa2xx.dtsi
index a5e90f0..c08f846 100644
--- a/arch/arm/boot/dts/pxa2xx.dtsi
+++ b/arch/arm/boot/dts/pxa2xx.dtsi
@@ -113,14 +113,14 @@
};
usb0: ohci@4c00 {
- compatible = "mrvl,pxa-ohci";
+ compatible = "marvell,pxa-ohci";
reg = <0x4c00 0x1>;
interrupts = <3>;
status = "disabled";
};
mmc0: mmc@4110 {
- compatible = "mrvl,pxa-mmc";
+ compatible = "marvell,pxa-mmc";
reg = <0x4110 0x1000>;
interrupts = <23>;
status = "disabled";
--
1.9.0.rc3.12.gbc97e2d
--
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/6] arm: pxa{27x,3xx}.dtsi: gpio cleanups
* Define gpio0, gpio1 interrupts in pxa2xx since they are also used by
the pxa27x, pxa25x and pxa3xx.
* Remove several redundant tags from pxa3xx's gpio since they are the
same as the included pxa2xx.dtsi
* Correctly override the compatible tag in the pxa27x for the gpio
module.
Signed-off-by: Andrew Ruder
---
arch/arm/boot/dts/pxa27x.dtsi | 3 +++
arch/arm/boot/dts/pxa2xx.dtsi | 4 ++--
arch/arm/boot/dts/pxa3xx.dtsi | 7 ---
3 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/pxa27x.dtsi b/arch/arm/boot/dts/pxa27x.dtsi
index 2d05aa9..26841d8 100644
--- a/arch/arm/boot/dts/pxa27x.dtsi
+++ b/arch/arm/boot/dts/pxa27x.dtsi
@@ -43,5 +43,8 @@
#size-cells = <0>;
status = "disabled";
};
+ gpio: gpio@40e0 {
+ compatible = "intel,pxa27x-gpio";
+ };
};
};
diff --git a/arch/arm/boot/dts/pxa2xx.dtsi b/arch/arm/boot/dts/pxa2xx.dtsi
index d233088..c21e80f 100644
--- a/arch/arm/boot/dts/pxa2xx.dtsi
+++ b/arch/arm/boot/dts/pxa2xx.dtsi
@@ -53,8 +53,8 @@
reg = <0x40e0 0x1>;
gpio-controller;
#gpio-cells = <0x2>;
- interrupts = <10>;
- interrupt-names = "gpio_mux";
+ interrupts = <8 9 10>;
+ interrupt-names = "gpio0", "gpio1", "gpio_mux";
interrupt-controller;
#interrupt-cells = <0x2>;
ranges;
diff --git a/arch/arm/boot/dts/pxa3xx.dtsi b/arch/arm/boot/dts/pxa3xx.dtsi
index 83bb0ef..e689b99 100644
--- a/arch/arm/boot/dts/pxa3xx.dtsi
+++ b/arch/arm/boot/dts/pxa3xx.dtsi
@@ -31,13 +31,6 @@
gpio: gpio@40e0 {
compatible = "intel,pxa3xx-gpio";
- reg = <0x40e0 0x1>;
- interrupt-names = "gpio0", "gpio1", "gpio_mux";
- interrupts = <8 9 10>;
- gpio-controller;
- #gpio-cells = <0x2>;
- interrupt-controller;
- #interrupt-cells = <0x2>;
};
};
};
--
1.9.0.rc3.12.gbc97e2d
--
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/6] arm: pxa27x.dtsi: header typo - wrong file
Fixing a copy-paste error calling this file the pxa3xx skeleton when it
is actually the pxa27x skeleton.
Signed-off-by: Andrew Ruder
---
arch/arm/boot/dts/pxa27x.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/pxa27x.dtsi b/arch/arm/boot/dts/pxa27x.dtsi
index a705469..931e1d5 100644
--- a/arch/arm/boot/dts/pxa27x.dtsi
+++ b/arch/arm/boot/dts/pxa27x.dtsi
@@ -1,4 +1,4 @@
-/* The pxa3xx skeleton simply augments the 2xx version */
+/* The pxa27x skeleton simply augments the 2xx version */
/include/ "pxa2xx.dtsi"
/ {
--
1.9.0.rc3.12.gbc97e2d
--
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/6] pxa-usb: devicetree bindings docs update
A few tags documented in pxa-usb.txt don't match the code and one isn't documented at all. Updating documentation to match the code. marvell,power-sense-low -> marvell,port-sense-low marvell,power_on_delay -> marvell,power-on-delay marvell,power-budget (new to documentation) Signed-off-by: Andrew Ruder --- Documentation/devicetree/bindings/usb/pxa-usb.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/pxa-usb.txt b/Documentation/devicetree/bindings/usb/pxa-usb.txt index 79729a9..13ab5b0 100644 --- a/Documentation/devicetree/bindings/usb/pxa-usb.txt +++ b/Documentation/devicetree/bindings/usb/pxa-usb.txt @@ -13,11 +13,12 @@ Optional properties: 1 = PMM_NPS_MODE 2 = PMM_GLOBAL_MODE 3 = PMM_PERPORT_MODE - - "marvell,power-sense-low" - power sense pin is low-active. + - "marvell,port-sense-low" - power sense pin is low-active. - "marvell,power-control-low" - power control pin is low-active. - "marvell,no-oc-protection" - disable over-current protection. - "marvell,oc-mode-perport" - enable per-port over-current protection. - - "marvell,power_on_delay" Power On to Power Good time - in ms. + - "marvell,power-on-delay" - Power On to Power Good time - in ms. + - "marvell,power-budget" - Power budget in mA (0 is no limit) Example: -- 1.9.0.rc3.12.gbc97e2d -- 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 4/6] arm: pxa2xx.dtsi: disable RTC by default
This sets the status="disabled" flag in pxa2xx.dtsi in the same style as the other optional components. This can be overridden on a case-by-case basis by boards that use this functionality. Signed-off-by: Andrew Ruder --- arch/arm/boot/dts/pxa2xx.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/pxa2xx.dtsi b/arch/arm/boot/dts/pxa2xx.dtsi index c08f846..d233088 100644 --- a/arch/arm/boot/dts/pxa2xx.dtsi +++ b/arch/arm/boot/dts/pxa2xx.dtsi @@ -130,6 +130,7 @@ compatible = "marvell,pxa-rtc"; reg = <0x4090 0x3c>; interrupts = <30 31>; + status = "disabled"; }; }; }; -- 1.9.0.rc3.12.gbc97e2d -- 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] gpio-pxa: gpio0 and gpio1 support on dt
pxa_gpio_probe() has some issues supporting the gpio0 and gpio1
interrupts under device-tree - it never actually sets up the chain
handler to get interrupts on edge detect for GPIO0 and GPIO1.
Signed-off-by: Andrew Ruder
---
drivers/gpio/gpio-pxa.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpio/gpio-pxa.c b/drivers/gpio/gpio-pxa.c
index 42e6e64..19f1a95 100644
--- a/drivers/gpio/gpio-pxa.c
+++ b/drivers/gpio/gpio-pxa.c
@@ -649,6 +649,11 @@ static int pxa_gpio_probe(struct platform_device *pdev)
handle_edge_irq);
set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
}
+ } else {
+ if (irq0 > 0)
+ irq_set_chained_handler(irq0, pxa_gpio_demux_handler);
+ if (irq1 > 0)
+ irq_set_chained_handler(irq1, pxa_gpio_demux_handler);
}
irq_set_chained_handler(irq_mux, pxa_gpio_demux_handler);
--
1.9.0.rc3.12.gbc97e2d
--
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 0/6] miscellaneous pxa dt fixes
Andrew Ruder (6):
arm: pxa2xx.dtsi: compatible tags for usb, mmc
pxa-usb: devicetree bindings docs update
arm: pxa27x.dtsi: header typo - wrong file
arm: pxa2xx.dtsi: disable RTC by default
arm: pxa27x.dtsi: add pwri2c definition
arm: pxa{27x,3xx}.dtsi: gpio cleanups
Documentation/devicetree/bindings/usb/pxa-usb.txt | 5 +++--
arch/arm/boot/dts/pxa27x.dtsi | 14 +-
arch/arm/boot/dts/pxa2xx.dtsi | 9 +
arch/arm/boot/dts/pxa3xx.dtsi | 7 ---
4 files changed, 21 insertions(+), 14 deletions(-)
--
1.9.0.rc3.12.gbc97e2d
--
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] arm: pxa: correct errata number for PXA270
Comment incorrectly cites errata 39 E39. SDIO: SDIO Devices Not Working at 19.5 Mbps Should be errata 38 E38. MEMC: Memory Controller hangs when entering Self Refresh Mode. Signed-off-by: Andrew Ruder --- arch/arm/mach-pxa/sleep.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-pxa/sleep.S b/arch/arm/mach-pxa/sleep.S index 1e544be..6c5b3ff 100644 --- a/arch/arm/mach-pxa/sleep.S +++ b/arch/arm/mach-pxa/sleep.S @@ -157,7 +157,7 @@ pxa_cpu_do_suspend: @ Do not reorder... @ Intel PXA270 Specification Update notes problems performing @ external accesses after SDRAM is put in self-refresh mode - @ (see Errata 39 ...hangs when entering self-refresh mode) + @ (see Errata 38 ...hangs when entering self-refresh mode) @ force address lines low by reading at physical address 0 ldr r3, [r2] -- 1.9.0.rc3.12.gbc97e2d -- 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] arm: pxa: call debug_ll_io_init for earlyprintk
This is already done automatically for many other ARM platforms by the
ARM core code, but since pxa is using the .map_io callback, it needs to
call it explicitely for earlyprintk support.
Signed-off-by: Andrew Ruder
---
arch/arm/mach-pxa/generic.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-pxa/generic.c b/arch/arm/mach-pxa/generic.c
index 4225417..94f49c2 100644
--- a/arch/arm/mach-pxa/generic.c
+++ b/arch/arm/mach-pxa/generic.c
@@ -93,5 +93,6 @@ static struct map_desc common_io_desc[] __initdata = {
void __init pxa_map_io(void)
{
+ debug_ll_io_init();
iotable_init(ARRAY_AND_SIZE(common_io_desc));
}
--
1.9.0.rc3.12.gbc97e2d
--
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] arm: pxa: call debug_ll_io_init for earlyprintk
This is already done automatically for many other ARM platforms by the
ARM core code, but since pxa is using the .map_io callback, it needs to
call it explicitely for earlyprintk support.
Signed-off-by: Andrew Ruder andrew.ru...@elecsyscorp.com
---
arch/arm/mach-pxa/generic.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-pxa/generic.c b/arch/arm/mach-pxa/generic.c
index 4225417..94f49c2 100644
--- a/arch/arm/mach-pxa/generic.c
+++ b/arch/arm/mach-pxa/generic.c
@@ -93,5 +93,6 @@ static struct map_desc common_io_desc[] __initdata = {
void __init pxa_map_io(void)
{
+ debug_ll_io_init();
iotable_init(ARRAY_AND_SIZE(common_io_desc));
}
--
1.9.0.rc3.12.gbc97e2d
--
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] arm: pxa: correct errata number for PXA270
Comment incorrectly cites errata 39 E39. SDIO: SDIO Devices Not Working at 19.5 Mbps Should be errata 38 E38. MEMC: Memory Controller hangs when entering Self Refresh Mode. Signed-off-by: Andrew Ruder andrew.ru...@elecsyscorp.com --- arch/arm/mach-pxa/sleep.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-pxa/sleep.S b/arch/arm/mach-pxa/sleep.S index 1e544be..6c5b3ff 100644 --- a/arch/arm/mach-pxa/sleep.S +++ b/arch/arm/mach-pxa/sleep.S @@ -157,7 +157,7 @@ pxa_cpu_do_suspend: @ Do not reorder... @ Intel PXA270 Specification Update notes problems performing @ external accesses after SDRAM is put in self-refresh mode - @ (see Errata 39 ...hangs when entering self-refresh mode) + @ (see Errata 38 ...hangs when entering self-refresh mode) @ force address lines low by reading at physical address 0 ldr r3, [r2] -- 1.9.0.rc3.12.gbc97e2d -- 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 0/6] miscellaneous pxa dt fixes
Andrew Ruder (6):
arm: pxa2xx.dtsi: compatible tags for usb, mmc
pxa-usb: devicetree bindings docs update
arm: pxa27x.dtsi: header typo - wrong file
arm: pxa2xx.dtsi: disable RTC by default
arm: pxa27x.dtsi: add pwri2c definition
arm: pxa{27x,3xx}.dtsi: gpio cleanups
Documentation/devicetree/bindings/usb/pxa-usb.txt | 5 +++--
arch/arm/boot/dts/pxa27x.dtsi | 14 +-
arch/arm/boot/dts/pxa2xx.dtsi | 9 +
arch/arm/boot/dts/pxa3xx.dtsi | 7 ---
4 files changed, 21 insertions(+), 14 deletions(-)
--
1.9.0.rc3.12.gbc97e2d
--
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] gpio-pxa: gpio0 and gpio1 support on dt
pxa_gpio_probe() has some issues supporting the gpio0 and gpio1
interrupts under device-tree - it never actually sets up the chain
handler to get interrupts on edge detect for GPIO0 and GPIO1.
Signed-off-by: Andrew Ruder andrew.ru...@elecsyscorp.com
---
drivers/gpio/gpio-pxa.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpio/gpio-pxa.c b/drivers/gpio/gpio-pxa.c
index 42e6e64..19f1a95 100644
--- a/drivers/gpio/gpio-pxa.c
+++ b/drivers/gpio/gpio-pxa.c
@@ -649,6 +649,11 @@ static int pxa_gpio_probe(struct platform_device *pdev)
handle_edge_irq);
set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
}
+ } else {
+ if (irq0 0)
+ irq_set_chained_handler(irq0, pxa_gpio_demux_handler);
+ if (irq1 0)
+ irq_set_chained_handler(irq1, pxa_gpio_demux_handler);
}
irq_set_chained_handler(irq_mux, pxa_gpio_demux_handler);
--
1.9.0.rc3.12.gbc97e2d
--
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/6] arm: pxa27x.dtsi: header typo - wrong file
Fixing a copy-paste error calling this file the pxa3xx skeleton when it
is actually the pxa27x skeleton.
Signed-off-by: Andrew Ruder andrew.ru...@elecsyscorp.com
---
arch/arm/boot/dts/pxa27x.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/pxa27x.dtsi b/arch/arm/boot/dts/pxa27x.dtsi
index a705469..931e1d5 100644
--- a/arch/arm/boot/dts/pxa27x.dtsi
+++ b/arch/arm/boot/dts/pxa27x.dtsi
@@ -1,4 +1,4 @@
-/* The pxa3xx skeleton simply augments the 2xx version */
+/* The pxa27x skeleton simply augments the 2xx version */
/include/ pxa2xx.dtsi
/ {
--
1.9.0.rc3.12.gbc97e2d
--
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/6] pxa-usb: devicetree bindings docs update
A few tags documented in pxa-usb.txt don't match the code and one isn't documented at all. Updating documentation to match the code. marvell,power-sense-low - marvell,port-sense-low marvell,power_on_delay - marvell,power-on-delay marvell,power-budget (new to documentation) Signed-off-by: Andrew Ruder andrew.ru...@elecsyscorp.com --- Documentation/devicetree/bindings/usb/pxa-usb.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/pxa-usb.txt b/Documentation/devicetree/bindings/usb/pxa-usb.txt index 79729a9..13ab5b0 100644 --- a/Documentation/devicetree/bindings/usb/pxa-usb.txt +++ b/Documentation/devicetree/bindings/usb/pxa-usb.txt @@ -13,11 +13,12 @@ Optional properties: 1 = PMM_NPS_MODE 2 = PMM_GLOBAL_MODE 3 = PMM_PERPORT_MODE - - marvell,power-sense-low - power sense pin is low-active. + - marvell,port-sense-low - power sense pin is low-active. - marvell,power-control-low - power control pin is low-active. - marvell,no-oc-protection - disable over-current protection. - marvell,oc-mode-perport - enable per-port over-current protection. - - marvell,power_on_delay Power On to Power Good time - in ms. + - marvell,power-on-delay - Power On to Power Good time - in ms. + - marvell,power-budget - Power budget in mA (0 is no limit) Example: -- 1.9.0.rc3.12.gbc97e2d -- 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 4/6] arm: pxa2xx.dtsi: disable RTC by default
This sets the status=disabled flag in pxa2xx.dtsi in the same style as the other optional components. This can be overridden on a case-by-case basis by boards that use this functionality. Signed-off-by: Andrew Ruder andrew.ru...@elecsyscorp.com --- arch/arm/boot/dts/pxa2xx.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/pxa2xx.dtsi b/arch/arm/boot/dts/pxa2xx.dtsi index c08f846..d233088 100644 --- a/arch/arm/boot/dts/pxa2xx.dtsi +++ b/arch/arm/boot/dts/pxa2xx.dtsi @@ -130,6 +130,7 @@ compatible = marvell,pxa-rtc; reg = 0x4090 0x3c; interrupts = 30 31; + status = disabled; }; }; }; -- 1.9.0.rc3.12.gbc97e2d -- 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/6] arm: pxa{27x,3xx}.dtsi: gpio cleanups
* Define gpio0, gpio1 interrupts in pxa2xx since they are also used by
the pxa27x, pxa25x and pxa3xx.
* Remove several redundant tags from pxa3xx's gpio since they are the
same as the included pxa2xx.dtsi
* Correctly override the compatible tag in the pxa27x for the gpio
module.
Signed-off-by: Andrew Ruder andrew.ru...@elecsyscorp.com
---
arch/arm/boot/dts/pxa27x.dtsi | 3 +++
arch/arm/boot/dts/pxa2xx.dtsi | 4 ++--
arch/arm/boot/dts/pxa3xx.dtsi | 7 ---
3 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/pxa27x.dtsi b/arch/arm/boot/dts/pxa27x.dtsi
index 2d05aa9..26841d8 100644
--- a/arch/arm/boot/dts/pxa27x.dtsi
+++ b/arch/arm/boot/dts/pxa27x.dtsi
@@ -43,5 +43,8 @@
#size-cells = 0;
status = disabled;
};
+ gpio: gpio@40e0 {
+ compatible = intel,pxa27x-gpio;
+ };
};
};
diff --git a/arch/arm/boot/dts/pxa2xx.dtsi b/arch/arm/boot/dts/pxa2xx.dtsi
index d233088..c21e80f 100644
--- a/arch/arm/boot/dts/pxa2xx.dtsi
+++ b/arch/arm/boot/dts/pxa2xx.dtsi
@@ -53,8 +53,8 @@
reg = 0x40e0 0x1;
gpio-controller;
#gpio-cells = 0x2;
- interrupts = 10;
- interrupt-names = gpio_mux;
+ interrupts = 8 9 10;
+ interrupt-names = gpio0, gpio1, gpio_mux;
interrupt-controller;
#interrupt-cells = 0x2;
ranges;
diff --git a/arch/arm/boot/dts/pxa3xx.dtsi b/arch/arm/boot/dts/pxa3xx.dtsi
index 83bb0ef..e689b99 100644
--- a/arch/arm/boot/dts/pxa3xx.dtsi
+++ b/arch/arm/boot/dts/pxa3xx.dtsi
@@ -31,13 +31,6 @@
gpio: gpio@40e0 {
compatible = intel,pxa3xx-gpio;
- reg = 0x40e0 0x1;
- interrupt-names = gpio0, gpio1, gpio_mux;
- interrupts = 8 9 10;
- gpio-controller;
- #gpio-cells = 0x2;
- interrupt-controller;
- #interrupt-cells = 0x2;
};
};
};
--
1.9.0.rc3.12.gbc97e2d
--
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/6] arm: pxa2xx.dtsi: compatible tags for usb, mmc
This changes pxa2xx.dtsi's compatible tags for MMC and USB to match both
the documentation and the code.
Signed-off-by: Andrew Ruder andrew.ru...@elecsyscorp.com
---
arch/arm/boot/dts/pxa2xx.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/pxa2xx.dtsi b/arch/arm/boot/dts/pxa2xx.dtsi
index a5e90f0..c08f846 100644
--- a/arch/arm/boot/dts/pxa2xx.dtsi
+++ b/arch/arm/boot/dts/pxa2xx.dtsi
@@ -113,14 +113,14 @@
};
usb0: ohci@4c00 {
- compatible = mrvl,pxa-ohci;
+ compatible = marvell,pxa-ohci;
reg = 0x4c00 0x1;
interrupts = 3;
status = disabled;
};
mmc0: mmc@4110 {
- compatible = mrvl,pxa-mmc;
+ compatible = marvell,pxa-mmc;
reg = 0x4110 0x1000;
interrupts = 23;
status = disabled;
--
1.9.0.rc3.12.gbc97e2d
--
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/6] arm: pxa27x.dtsi: add pwri2c definition
This adds the pwri2c definition to the pxa27x device tree. This is
already called out in pxa3xx.dtsi.
Signed-off-by: Andrew Ruder andrew.ru...@elecsyscorp.com
---
arch/arm/boot/dts/pxa27x.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/pxa27x.dtsi b/arch/arm/boot/dts/pxa27x.dtsi
index 931e1d5..2d05aa9 100644
--- a/arch/arm/boot/dts/pxa27x.dtsi
+++ b/arch/arm/boot/dts/pxa27x.dtsi
@@ -34,5 +34,14 @@
reg = 0x40c00010 0x10;
#pwm-cells = 1;
};
+
+ pwri2c: i2c@40f00180 {
+ compatible = mrvl,pxa-i2c;
+ reg = 0x40f00180 0x30;
+ interrupts = 6;
+ #address-cells = 0x1;
+ #size-cells = 0;
+ status = disabled;
+ };
};
};
--
1.9.0.rc3.12.gbc97e2d
--
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: What is wrong?
On Tue, Mar 04, 2014 at 10:54:04AM +0200, Leon Pollak wrote: > I will recheck everything and try. Meanwhile, the news are not good: our > guys say that it appears that the additional sync DOES NOT SOLVE the > issue. Gonna be honest, I have a tough time explaining this. :( Unfortunately I don't have a board here with a hardware write protect which would make things easier to verify. - Andy -- 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: What is wrong?
On Tue, Mar 04, 2014 at 10:54:04AM +0200, Leon Pollak wrote: I will recheck everything and try. Meanwhile, the news are not good: our guys say that it appears that the additional sync DOES NOT SOLVE the issue. Gonna be honest, I have a tough time explaining this. :( Unfortunately I don't have a board here with a hardware write protect which would make things easier to verify. - Andy -- 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: What is wrong?
On Thu, Feb 27, 2014 at 01:22:08PM -0800, Brian Norris wrote: > Perhaps Richard or Andrew can comment on whether this patch should help > you. But I think JFFS2 on NAND uses write-buffered support which can be > affected by this bug. Definitely sounds like the same issue and I'm kind of glad to see it crop up in another filesystem. Also glad you Cc'd me with the URL because I had the painful task of recreating this issue on another filesystem on my TODO list as I didn't think it had ever been committed. Cheers, Andy -- 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: What is wrong?
On Thu, Feb 27, 2014 at 01:22:08PM -0800, Brian Norris wrote: Perhaps Richard or Andrew can comment on whether this patch should help you. But I think JFFS2 on NAND uses write-buffered support which can be affected by this bug. Definitely sounds like the same issue and I'm kind of glad to see it crop up in another filesystem. Also glad you Cc'd me with the URL because I had the painful task of recreating this issue on another filesystem on my TODO list as I didn't think it had ever been committed. Cheers, Andy -- 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: [BUG] reproducable ubifs reboot assert and corruption
On Wed, Jan 29, 2014 at 04:56:04PM +0100, Richard Weinberger wrote:
> Does the issue also happen if you disable preemption?
> i.e. CONFIG_PREEMPT_NONE=y
CONFIG_PREEMPT_NONE=y still breaks. I suspect that sync_filesystem
has some blocking behavior that allows other processes to schedule.
Another log is attached and the patch I used to create this log is
below. I think the most interesting part of this patch is the last hunk
that modifies ubifs_remount_ro. This clearly shows that after the mount
has been marked as read-only we have dirty inodes waiting for the
writeback to come in and hit all the asserts.
Here's some of the important parts of the log:
170 pre sync_filesystem
# Notice that while we were running sync_filesystem
# a inode (0xd75ab658) snuck in with a sys_rename
204 inode: d75ab658
205 [ cut here ]
206 WARNING: CPU: 0 PID: 625 at fs/fs-writeback.c:1213
__mark_inode_dirty+0x2a4/0x2f4()
207 Modules linked in:
208 CPU: 0 PID: 625 Comm: fsstress Tainted: GW
3.12.0-00041-g7f12d39-dirty #250
209 [] (unwind_backtrace+0x0/0x128) from []
(show_stack+0x20/0x24)
210 [] (show_stack+0x20/0x24) from []
(dump_stack+0x20/0x28)
211 [] (dump_stack+0x20/0x28) from []
(warn_slowpath_common+0x78/0x98)
212 [] (warn_slowpath_common+0x78/0x98) from []
(warn_slowpath_null+0x2c/0x34)
213 [] (warn_slowpath_null+0x2c/0x34) from []
(__mark_inode_dirty+0x2a4/0x2f4)
214 [] (__mark_inode_dirty+0x2a4/0x2f4) from []
(ubifs_rename+0x4a4/0x600)
215 [] (ubifs_rename+0x4a4/0x600) from []
(vfs_rename+0x280/0x3f4)
216 [] (vfs_rename+0x280/0x3f4) from []
(SyS_renameat+0x18c/0x218)
217 [] (SyS_renameat+0x18c/0x218) from []
(SyS_rename+0x2c/0x30)
218 [] (SyS_rename+0x2c/0x30) from []
(ret_fast_syscall+0x0/0x2c)
219 ---[ end trace 35ebec8569a53526 ]---
754 post sync_filesystem
755 pre prepare_remount
756 post prepare_remount
757 prepare_remount success
758 UBIFS: background thread "ubifs_bgt0_0" stops
759 we are now a read-only mount
760 bdi.work_list = d7ac4110, .next = d7ac4110
# WE HAVE DIRTY I/O (notice the .next != _dirty)
761 bdi.wb.b_dirty = d7ac40d8, .next = d75accd0
762 bdi.wb.b_io = d7ac40e0, .next = d7ac40e0
763 bdi.wb.b_more_io = d7ac40e8, .next = d7ac40e8
764 do_remount_sb success
# And now our friend (inode 0xd75ab658) comes in with a writeback after
# we are read-only triggering the assert
779 inode: d75ab658
780 UBIFS assert failed in reserve_space at 125 (pid 11)
781 CPU: 0 PID: 11 Comm: kworker/u2:1 Tainted: GW
3.12.0-00041-g7f12d39-dirty #250
782 Workqueue: writeback bdi_writeback_workfn (flush-ubifs_0_0)
783 [] (unwind_backtrace+0x0/0x128) from []
(show_stack+0x20/0x24)
784 [] (show_stack+0x20/0x24) from []
(dump_stack+0x20/0x28)
785 [] (dump_stack+0x20/0x28) from []
(make_reservation+0x8c/0x560)
786 [] (make_reservation+0x8c/0x560) from []
(ubifs_jnl_write_inode+0xbc/0x214)
787 [] (ubifs_jnl_write_inode+0xbc/0x214) from []
(ubifs_write_inode+0xec/0x17c)
788 [] (ubifs_write_inode+0xec/0x17c) from []
(__writeback_single_inode+0x1fc/0x308)
789 [] (__writeback_single_inode+0x1fc/0x308) from []
(writeback_sb_inodes+0x1f8/0x3c4)
790 [] (writeback_sb_inodes+0x1f8/0x3c4) from []
(__writeback_inodes_wb+0x80/0xc0)
791 [] (__writeback_inodes_wb+0x80/0xc0) from []
(wb_writeback+0x198/0x310)
792 [] (wb_writeback+0x198/0x310) from []
(bdi_writeback_workfn+0x15c/0x454)
793 [] (bdi_writeback_workfn+0x15c/0x454) from []
(process_one_work+0x280/0x420)
794 [] (process_one_work+0x280/0x420) from []
(worker_thread+0x240/0x380)
795 [] (worker_thread+0x240/0x380) from []
(kthread+0xbc/0xc8)
796 [] (kthread+0xbc/0xc8) from []
(ret_from_fork+0x14/0x20)
- Andy
--- patch ---
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index 9f4935b..48e4272 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -93,6 +93,10 @@ static void bdi_queue_work(struct backing_dev_info *bdi,
{
trace_writeback_queue(bdi, work);
+ do {
+ extern bool ubifs_enable_debug;
+ WARN_ON(ubifs_enable_debug);
+ } while (0);
spin_lock_bh(>wb_lock);
list_add_tail(>list, >work_list);
spin_unlock_bh(>wb_lock);
@@ -194,6 +198,11 @@ static void redirty_tail(struct inode *inode, struct
bdi_writeback *wb)
if (time_before(inode->dirtied_when, tail->dirtied_when))
inode->dirtied_when = jiffies;
}
+ do {
+ extern bool ubifs_enable_debug;
+ if (ubifs_enable_debug) pr_info("inode: %p\n", inode);
+ WARN_ON(ubifs_enable_debug);
+ } while (0);
list_move(>i_wb_list, >b_dirty);
}
@@ -204,6 +213,11 @@ static void requeue_io(struct inode *inode, struct
bdi_writeback *wb)
{
assert_spin_locked(>list_lock);
list_move(>i_wb_list, >b_more_io);
+ do {
+ extern bool ubifs_enable_debug;
+
Re: [BUG] reproducable ubifs reboot assert and corruption
On Wed, Jan 29, 2014 at 08:30:45AM +0100, Richard Weinberger wrote:
> BTW: Can you please share your .config?
No problem. FYI, this is for a board that is still in development so
not all my changes have been submitted for inclusion yet. I would be
happy to share the changes now if necessary but I've attached the --stat
to show that as far as mtd/ubifs goes, i'm basically running a stock
v3.12:
% git diff --stat v3.12..HEAD
Documentation/devicetree/bindings/usb/pxa-usb.txt |5 +-
arch/arm/boot/dts/Makefile|2 +
arch/arm/boot/dts/pxa270-elecsys_z2.dts | 330 ++
arch/arm/boot/dts/pxa270-elecsys_z4.dts | 434 +++
arch/arm/boot/dts/pxa27x.dtsi | 13 +-
arch/arm/boot/dts/pxa2xx.dtsi | 14 +-
arch/arm/boot/dts/pxa3xx.dtsi |4 +
arch/arm/configs/elecsys_z2_defconfig | 3089 +++
arch/arm/mach-pxa/Kconfig | 18 +
arch/arm/mach-pxa/Makefile|3 +-
arch/arm/mach-pxa/generic.c |3 +-
arch/arm/mach-pxa/include/mach/hardware.h |2 +-
arch/arm/mach-pxa/irq.c |8 +-
arch/arm/mach-pxa/{pxa-dt.c => pxa27x-dt.c} | 44 +-
arch/arm/mach-pxa/pxa27x.c| 25 +-
arch/arm/mach-pxa/{pxa-dt.c => pxa3xx-dt.c} | 11 +-
arch/arm/mach-pxa/sleep.S |2 +-
drivers/irqchip/Kconfig |8 +
drivers/irqchip/Makefile |1 +
drivers/irqchip/irq-zeus.c| 192 +++
drivers/mmc/host/pxamci.c | 33 +-
drivers/net/ethernet/8390/ne.c|4 +-
drivers/net/ethernet/davicom/dm9000.c | 68 +-
drivers/tty/serial/pxa.c |6 +-
24 files changed, 4222 insertions(+), 97 deletions(-)
And the .config I'm using is attached.
Thanks,
Andy
config.gz
Description: application/gunzip
Re: [BUG] reproducable ubifs reboot assert and corruption
On Wed, Jan 29, 2014 at 08:17:35AM +0100, Richard Weinberger wrote: > So you can trigger this by running fsstress on /mnt and then call > mount -o remount,ro /mnt? That's all it takes. I actually run the remount until it succeeds, obviously with fsstress going in the background there is a pretty narrow window where it needs to sneak in with a write between the start of the sync_filesystem and before the remount check for writers (-EBUSY). > Can you also trigger it on nandsim or mtdram? Haven't tried, but I can. I just don't really have that great of a development environment for doing this on a desktop machine. > I did a quick test on my testbed using mtdram and was unable to trigger it. > But I fear my box is too fast. I think there is definitely a speed component of my 416 MHz PXA 270 that makes this pretty easy to hit. What if you did something like (changing the ubiattach and mount lines obviously)? I'll see if I can do this in a qemu, but it might take me a while to get that setup. - Andy -- 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: [BUG] reproducable ubifs reboot assert and corruption
On Wed, Jan 29, 2014 at 08:17:35AM +0100, Richard Weinberger wrote: So you can trigger this by running fsstress on /mnt and then call mount -o remount,ro /mnt? That's all it takes. I actually run the remount until it succeeds, obviously with fsstress going in the background there is a pretty narrow window where it needs to sneak in with a write between the start of the sync_filesystem and before the remount check for writers (-EBUSY). Can you also trigger it on nandsim or mtdram? Haven't tried, but I can. I just don't really have that great of a development environment for doing this on a desktop machine. I did a quick test on my testbed using mtdram and was unable to trigger it. But I fear my box is too fast. I think there is definitely a speed component of my 416 MHz PXA 270 that makes this pretty easy to hit. What if you did something like (changing the ubiattach and mount lines obviously)? I'll see if I can do this in a qemu, but it might take me a while to get that setup. - Andy -- 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: [BUG] reproducable ubifs reboot assert and corruption
On Wed, Jan 29, 2014 at 08:30:45AM +0100, Richard Weinberger wrote:
BTW: Can you please share your .config?
No problem. FYI, this is for a board that is still in development so
not all my changes have been submitted for inclusion yet. I would be
happy to share the changes now if necessary but I've attached the --stat
to show that as far as mtd/ubifs goes, i'm basically running a stock
v3.12:
% git diff --stat v3.12..HEAD
Documentation/devicetree/bindings/usb/pxa-usb.txt |5 +-
arch/arm/boot/dts/Makefile|2 +
arch/arm/boot/dts/pxa270-elecsys_z2.dts | 330 ++
arch/arm/boot/dts/pxa270-elecsys_z4.dts | 434 +++
arch/arm/boot/dts/pxa27x.dtsi | 13 +-
arch/arm/boot/dts/pxa2xx.dtsi | 14 +-
arch/arm/boot/dts/pxa3xx.dtsi |4 +
arch/arm/configs/elecsys_z2_defconfig | 3089 +++
arch/arm/mach-pxa/Kconfig | 18 +
arch/arm/mach-pxa/Makefile|3 +-
arch/arm/mach-pxa/generic.c |3 +-
arch/arm/mach-pxa/include/mach/hardware.h |2 +-
arch/arm/mach-pxa/irq.c |8 +-
arch/arm/mach-pxa/{pxa-dt.c = pxa27x-dt.c} | 44 +-
arch/arm/mach-pxa/pxa27x.c| 25 +-
arch/arm/mach-pxa/{pxa-dt.c = pxa3xx-dt.c} | 11 +-
arch/arm/mach-pxa/sleep.S |2 +-
drivers/irqchip/Kconfig |8 +
drivers/irqchip/Makefile |1 +
drivers/irqchip/irq-zeus.c| 192 +++
drivers/mmc/host/pxamci.c | 33 +-
drivers/net/ethernet/8390/ne.c|4 +-
drivers/net/ethernet/davicom/dm9000.c | 68 +-
drivers/tty/serial/pxa.c |6 +-
24 files changed, 4222 insertions(+), 97 deletions(-)
And the .config I'm using is attached.
Thanks,
Andy
config.gz
Description: application/gunzip
Re: [BUG] reproducable ubifs reboot assert and corruption
On Wed, Jan 29, 2014 at 04:56:04PM +0100, Richard Weinberger wrote:
Does the issue also happen if you disable preemption?
i.e. CONFIG_PREEMPT_NONE=y
CONFIG_PREEMPT_NONE=y still breaks. I suspect that sync_filesystem
has some blocking behavior that allows other processes to schedule.
Another log is attached and the patch I used to create this log is
below. I think the most interesting part of this patch is the last hunk
that modifies ubifs_remount_ro. This clearly shows that after the mount
has been marked as read-only we have dirty inodes waiting for the
writeback to come in and hit all the asserts.
Here's some of the important parts of the log:
170 pre sync_filesystem
# Notice that while we were running sync_filesystem
# a inode (0xd75ab658) snuck in with a sys_rename
204 inode: d75ab658
205 [ cut here ]
206 WARNING: CPU: 0 PID: 625 at fs/fs-writeback.c:1213
__mark_inode_dirty+0x2a4/0x2f4()
207 Modules linked in:
208 CPU: 0 PID: 625 Comm: fsstress Tainted: GW
3.12.0-00041-g7f12d39-dirty #250
209 [c0014f54] (unwind_backtrace+0x0/0x128) from [c001235c]
(show_stack+0x20/0x24)
210 [c001235c] (show_stack+0x20/0x24) from [c0344574]
(dump_stack+0x20/0x28)
211 [c0344574] (dump_stack+0x20/0x28) from [c00206d4]
(warn_slowpath_common+0x78/0x98)
212 [c00206d4] (warn_slowpath_common+0x78/0x98) from [c00207b0]
(warn_slowpath_null+0x2c/0x34)
213 [c00207b0] (warn_slowpath_null+0x2c/0x34) from [c00f0e8c]
(__mark_inode_dirty+0x2a4/0x2f4)
214 [c00f0e8c] (__mark_inode_dirty+0x2a4/0x2f4) from [c0136428]
(ubifs_rename+0x4a4/0x600)
215 [c0136428] (ubifs_rename+0x4a4/0x600) from [c00d9f44]
(vfs_rename+0x280/0x3f4)
216 [c00d9f44] (vfs_rename+0x280/0x3f4) from [c00dabe4]
(SyS_renameat+0x18c/0x218)
217 [c00dabe4] (SyS_renameat+0x18c/0x218) from [c00dac9c]
(SyS_rename+0x2c/0x30)
218 [c00dac9c] (SyS_rename+0x2c/0x30) from [c000e820]
(ret_fast_syscall+0x0/0x2c)
219 ---[ end trace 35ebec8569a53526 ]---
754 post sync_filesystem
755 pre prepare_remount
756 post prepare_remount
757 prepare_remount success
758 UBIFS: background thread ubifs_bgt0_0 stops
759 we are now a read-only mount
760 bdi.work_list = d7ac4110, .next = d7ac4110
# WE HAVE DIRTY I/O (notice the .next != b_dirty)
761 bdi.wb.b_dirty = d7ac40d8, .next = d75accd0
762 bdi.wb.b_io = d7ac40e0, .next = d7ac40e0
763 bdi.wb.b_more_io = d7ac40e8, .next = d7ac40e8
764 do_remount_sb success
# And now our friend (inode 0xd75ab658) comes in with a writeback after
# we are read-only triggering the assert
779 inode: d75ab658
780 UBIFS assert failed in reserve_space at 125 (pid 11)
781 CPU: 0 PID: 11 Comm: kworker/u2:1 Tainted: GW
3.12.0-00041-g7f12d39-dirty #250
782 Workqueue: writeback bdi_writeback_workfn (flush-ubifs_0_0)
783 [c0014f54] (unwind_backtrace+0x0/0x128) from [c001235c]
(show_stack+0x20/0x24)
784 [c001235c] (show_stack+0x20/0x24) from [c0344574]
(dump_stack+0x20/0x28)
785 [c0344574] (dump_stack+0x20/0x28) from [c012f90c]
(make_reservation+0x8c/0x560)
786 [c012f90c] (make_reservation+0x8c/0x560) from [c0130c60]
(ubifs_jnl_write_inode+0xbc/0x214)
787 [c0130c60] (ubifs_jnl_write_inode+0xbc/0x214) from [c0137ce0]
(ubifs_write_inode+0xec/0x17c)
788 [c0137ce0] (ubifs_write_inode+0xec/0x17c) from [c00f0a00]
(__writeback_single_inode+0x1fc/0x308)
789 [c00f0a00] (__writeback_single_inode+0x1fc/0x308) from [c00f1780]
(writeback_sb_inodes+0x1f8/0x3c4)
790 [c00f1780] (writeback_sb_inodes+0x1f8/0x3c4) from [c00f19cc]
(__writeback_inodes_wb+0x80/0xc0)
791 [c00f19cc] (__writeback_inodes_wb+0x80/0xc0) from [c00f1ba4]
(wb_writeback+0x198/0x310)
792 [c00f1ba4] (wb_writeback+0x198/0x310) from [c00f2328]
(bdi_writeback_workfn+0x15c/0x454)
793 [c00f2328] (bdi_writeback_workfn+0x15c/0x454) from [c0038348]
(process_one_work+0x280/0x420)
794 [c0038348] (process_one_work+0x280/0x420) from [c00389e4]
(worker_thread+0x240/0x380)
795 [c00389e4] (worker_thread+0x240/0x380) from [c003dff8]
(kthread+0xbc/0xc8)
796 [c003dff8] (kthread+0xbc/0xc8) from [c000e8b0]
(ret_from_fork+0x14/0x20)
- Andy
--- patch ---
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index 9f4935b..48e4272 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -93,6 +93,10 @@ static void bdi_queue_work(struct backing_dev_info *bdi,
{
trace_writeback_queue(bdi, work);
+ do {
+ extern bool ubifs_enable_debug;
+ WARN_ON(ubifs_enable_debug);
+ } while (0);
spin_lock_bh(bdi-wb_lock);
list_add_tail(work-list, bdi-work_list);
spin_unlock_bh(bdi-wb_lock);
@@ -194,6 +198,11 @@ static void redirty_tail(struct inode *inode, struct
bdi_writeback *wb)
if (time_before(inode-dirtied_when, tail-dirtied_when))
inode-dirtied_when = jiffies;
}
+ do {
+ extern bool ubifs_enable_debug;
+ if (ubifs_enable_debug)
Re: [BUG] reproducable ubifs reboot assert and corruption
Ok, I've got some more useful information. I have been adding a multitude of WARN_ON's and prink's all over the remount code and have come up with the attached log. A little bit of explanation: Line 1: sync_filesystem (from do_remount_sb) Line 188: sync_filesystem ends Line 43, 64, 81, 98, 114, 135, 156, 173: write operations that occur during sync_filesystem. Before each warning I print the inode pointer. Line 197: read-only remount has completely finished (this message is from userspace post remount) Line 199: a sync is called, there are apparently dirty inodes in our now-readonly ubifs filesystem Line 215: failed assert that occurs because the writeback triggers for inode 0xd75b9450 (see line 41, it got in with a sys_write while we were running our sync_filesystem in do_remount_sb) Does this help? It looks like there is a race condition between the writeback code and the remount read-only. Nothing is done to lock out writes during the first half of the do_remount_sb and some stuff makes it into the writeback worker queue while we are busy syncing the filesystem only to trigger later when ubifs has decided it is read-only... Note: I only barely know what I am talking about - filesystems still not my forte :) Thanks, Andy 1: pre sync_filesystem 2: [ cut here ] 3: WARNING: CPU: 0 PID: 645 at fs/fs-writeback.c:98 bdi_queue_work+0xc8/0x130() 4: Modules linked in: 5: CPU: 0 PID: 645 Comm: mount Tainted: GW 3.12.0-00041-g7f12d39-dirty #236 6: [] (unwind_backtrace+0x0/0x128) from [] (show_stack+0x20/0x24) 7: [] (show_stack+0x20/0x24) from [] (dump_stack+0x20/0x28) 8: [] (dump_stack+0x20/0x28) from [] (warn_slowpath_common+0x78/0x98) 9: [] (warn_slowpath_common+0x78/0x98) from [] (warn_slowpath_null+0x2c/0x34) 10: [] (warn_slowpath_null+0x2c/0x34) from [] (bdi_queue_work+0xc8/0x130) 11: [] (bdi_queue_work+0xc8/0x130) from [] (writeback_inodes_sb_nr+0xb4/0xd4) 12: [] (writeback_inodes_sb_nr+0xb4/0xd4) from [] (writeback_inodes_sb+0x30/0x34) 13: [] (writeback_inodes_sb+0x30/0x34) from [] (sync_filesystem+0x50/0xbc) 14: [] (sync_filesystem+0x50/0xbc) from [] (do_remount_sb+0xb8/0x1fc) 15: [] (do_remount_sb+0xb8/0x1fc) from [] (do_mount+0x2e8/0x81c) 16: [] (do_mount+0x2e8/0x81c) from [] (SyS_mount+0x94/0xc8) 17: [] (SyS_mount+0x94/0xc8) from [] (ret_fast_syscall+0x0/0x2c) 18: ---[ end trace c6e04f3813781dc3 ]--- 19: Adding tail 20: writeback_workfn d781c110 d700fe8c 21: inode: d75a2c30 22: inode: d75b8c30 23: [ cut here ] 24: WARNING: CPU: 0 PID: 645 at fs/fs-writeback.c:98 bdi_queue_work+0xc8/0x130() 25: Modules linked in: 26: CPU: 0 PID: 645 Comm: mount Tainted: GW 3.12.0-00041-g7f12d39-dirty #236 27: [] (unwind_backtrace+0x0/0x128) from [] (show_stack+0x20/0x24) 28: [] (show_stack+0x20/0x24) from [] (dump_stack+0x20/0x28) 29: [] (dump_stack+0x20/0x28) from [] (warn_slowpath_common+0x78/0x98) 30: [] (warn_slowpath_common+0x78/0x98) from [] (warn_slowpath_null+0x2c/0x34) 31: [] (warn_slowpath_null+0x2c/0x34) from [] (bdi_queue_work+0xc8/0x130) 32: [] (bdi_queue_work+0xc8/0x130) from [] (sync_inodes_sb+0xbc/0x1bc) 33: [] (sync_inodes_sb+0xbc/0x1bc) from [] (sync_filesystem+0x88/0xbc) 34: [] (sync_filesystem+0x88/0xbc) from [] (do_remount_sb+0xb8/0x1fc) 35: [] (do_remount_sb+0xb8/0x1fc) from [] (do_mount+0x2e8/0x81c) 36: [] (do_mount+0x2e8/0x81c) from [] (SyS_mount+0x94/0xc8) 37: [] (SyS_mount+0x94/0xc8) from [] (ret_fast_syscall+0x0/0x2c) 38: ---[ end trace c6e04f3813781dc4 ]--- 39: Adding tail 40: writeback_workfn d781c110 d700fe9c 41: inode: d75b9450 42: [ cut here ] 43: WARNING: CPU: 0 PID: 651 at fs/fs-writeback.c:1215 __mark_inode_dirty+0x2dc/0x32c() 44: Modules linked in: 45: CPU: 0 PID: 651 Comm: fsstress Tainted: GW 3.12.0-00041-g7f12d39-dirty #236 46: [] (unwind_backtrace+0x0/0x128) from [] (show_stack+0x20/0x24) 47: [] (show_stack+0x20/0x24) from [] (dump_stack+0x20/0x28) 48: [] (dump_stack+0x20/0x28) from [] (warn_slowpath_common+0x78/0x98) 49: [] (warn_slowpath_common+0x78/0x98) from [] (warn_slowpath_null+0x2c/0x34) 50: [] (warn_slowpath_null+0x2c/0x34) from [] (__mark_inode_dirty+0x2dc/0x32c) 51: [] (__mark_inode_dirty+0x2dc/0x32c) from [] (__set_page_dirty_nobuffers+0xf4/0x110) 52: [] (__set_page_dirty_nobuffers+0xf4/0x110) from [] (ubifs_write_end+0x1c8/0x294) 53: [] (ubifs_write_end+0x1c8/0x294) from [] (generic_file_buffered_write+0x17c/0x260) 54: [] (generic_file_buffered_write+0x17c/0x260) from [] (__generic_file_aio_write+0x420/0x448) 55: [] (__generic_file_aio_write+0x420/0x448) from [] (generic_file_aio_write+0x68/0xac) 56: [] (generic_file_aio_write+0x68/0xac) from [] (ubifs_aio_write+0x17c/0x18c) 57: [] (ubifs_aio_write+0x17c/0x18c) from [] (do_sync_write+0x7c/0xa0) 58: [] (do_sync_write+0x7c/0xa0) from [] (vfs_write+0xe4/0x194) 59: [] (vfs_write+0xe4/0x194) from []
Re: [BUG] reproducable ubifs reboot assert and corruption
Ok, I've got some more useful information. I have been adding a multitude of WARN_ON's and prink's all over the remount code and have come up with the attached log. A little bit of explanation: Line 1: sync_filesystem (from do_remount_sb) Line 188: sync_filesystem ends Line 43, 64, 81, 98, 114, 135, 156, 173: write operations that occur during sync_filesystem. Before each warning I print the inode pointer. Line 197: read-only remount has completely finished (this message is from userspace post remount) Line 199: a sync is called, there are apparently dirty inodes in our now-readonly ubifs filesystem Line 215: failed assert that occurs because the writeback triggers for inode 0xd75b9450 (see line 41, it got in with a sys_write while we were running our sync_filesystem in do_remount_sb) Does this help? It looks like there is a race condition between the writeback code and the remount read-only. Nothing is done to lock out writes during the first half of the do_remount_sb and some stuff makes it into the writeback worker queue while we are busy syncing the filesystem only to trigger later when ubifs has decided it is read-only... Note: I only barely know what I am talking about - filesystems still not my forte :) Thanks, Andy 1: pre sync_filesystem 2: [ cut here ] 3: WARNING: CPU: 0 PID: 645 at fs/fs-writeback.c:98 bdi_queue_work+0xc8/0x130() 4: Modules linked in: 5: CPU: 0 PID: 645 Comm: mount Tainted: GW 3.12.0-00041-g7f12d39-dirty #236 6: [c0014fb4] (unwind_backtrace+0x0/0x128) from [c0012394] (show_stack+0x20/0x24) 7: [c0012394] (show_stack+0x20/0x24) from [c0348590] (dump_stack+0x20/0x28) 8: [c0348590] (dump_stack+0x20/0x28) from [c0020874] (warn_slowpath_common+0x78/0x98) 9: [c0020874] (warn_slowpath_common+0x78/0x98) from [c0020950] (warn_slowpath_null+0x2c/0x34) 10: [c0020950] (warn_slowpath_null+0x2c/0x34) from [c00f4f00] (bdi_queue_work+0xc8/0x130) 11: [c00f4f00] (bdi_queue_work+0xc8/0x130) from [c00f58cc] (writeback_inodes_sb_nr+0xb4/0xd4) 12: [c00f58cc] (writeback_inodes_sb_nr+0xb4/0xd4) from [c00f591c] (writeback_inodes_sb+0x30/0x34) 13: [c00f591c] (writeback_inodes_sb+0x30/0x34) from [c00fa3fc] (sync_filesystem+0x50/0xbc) 14: [c00fa3fc] (sync_filesystem+0x50/0xbc) from [c00d3bf4] (do_remount_sb+0xb8/0x1fc) 15: [c00d3bf4] (do_remount_sb+0xb8/0x1fc) from [c00ee3d0] (do_mount+0x2e8/0x81c) 16: [c00ee3d0] (do_mount+0x2e8/0x81c) from [c00ee998] (SyS_mount+0x94/0xc8) 17: [c00ee998] (SyS_mount+0x94/0xc8) from [c000e820] (ret_fast_syscall+0x0/0x2c) 18: ---[ end trace c6e04f3813781dc3 ]--- 19: Adding tail 20: writeback_workfn d781c110 d700fe8c 21: inode: d75a2c30 22: inode: d75b8c30 23: [ cut here ] 24: WARNING: CPU: 0 PID: 645 at fs/fs-writeback.c:98 bdi_queue_work+0xc8/0x130() 25: Modules linked in: 26: CPU: 0 PID: 645 Comm: mount Tainted: GW 3.12.0-00041-g7f12d39-dirty #236 27: [c0014fb4] (unwind_backtrace+0x0/0x128) from [c0012394] (show_stack+0x20/0x24) 28: [c0012394] (show_stack+0x20/0x24) from [c0348590] (dump_stack+0x20/0x28) 29: [c0348590] (dump_stack+0x20/0x28) from [c0020874] (warn_slowpath_common+0x78/0x98) 30: [c0020874] (warn_slowpath_common+0x78/0x98) from [c0020950] (warn_slowpath_null+0x2c/0x34) 31: [c0020950] (warn_slowpath_null+0x2c/0x34) from [c00f4f00] (bdi_queue_work+0xc8/0x130) 32: [c00f4f00] (bdi_queue_work+0xc8/0x130) from [c00f59dc] (sync_inodes_sb+0xbc/0x1bc) 33: [c00f59dc] (sync_inodes_sb+0xbc/0x1bc) from [c00fa434] (sync_filesystem+0x88/0xbc) 34: [c00fa434] (sync_filesystem+0x88/0xbc) from [c00d3bf4] (do_remount_sb+0xb8/0x1fc) 35: [c00d3bf4] (do_remount_sb+0xb8/0x1fc) from [c00ee3d0] (do_mount+0x2e8/0x81c) 36: [c00ee3d0] (do_mount+0x2e8/0x81c) from [c00ee998] (SyS_mount+0x94/0xc8) 37: [c00ee998] (SyS_mount+0x94/0xc8) from [c000e820] (ret_fast_syscall+0x0/0x2c) 38: ---[ end trace c6e04f3813781dc4 ]--- 39: Adding tail 40: writeback_workfn d781c110 d700fe9c 41: inode: d75b9450 42: [ cut here ] 43: WARNING: CPU: 0 PID: 651 at fs/fs-writeback.c:1215 __mark_inode_dirty+0x2dc/0x32c() 44: Modules linked in: 45: CPU: 0 PID: 651 Comm: fsstress Tainted: GW 3.12.0-00041-g7f12d39-dirty #236 46: [c0014fb4] (unwind_backtrace+0x0/0x128) from [c0012394] (show_stack+0x20/0x24) 47: [c0012394] (show_stack+0x20/0x24) from [c0348590] (dump_stack+0x20/0x28) 48: [c0348590] (dump_stack+0x20/0x28) from [c0020874] (warn_slowpath_common+0x78/0x98) 49: [c0020874] (warn_slowpath_common+0x78/0x98) from [c0020950] (warn_slowpath_null+0x2c/0x34) 50: [c0020950] (warn_slowpath_null+0x2c/0x34) from [c00f57c8] (__mark_inode_dirty+0x2dc/0x32c) 51: [c00f57c8] (__mark_inode_dirty+0x2dc/0x32c) from [c009dc70] (__set_page_dirty_nobuffers+0xf4/0x110) 52: [c009dc70] (__set_page_dirty_nobuffers+0xf4/0x110) from [c0138a48] (ubifs_write_end+0x1c8/0x294) 53: [c0138a48] (ubifs_write_end+0x1c8/0x294) from [c009504c]
Re: [BUG] reproducable ubifs reboot assert and corruption
On Sat, Jan 25, 2014 at 04:02:15PM +0100, Richard Weinberger wrote: > So ubifs_bgt0_0 stops and the fun begins. > Can you trigger the issue also by unmounting /mnt? > I.e umount -l /mnt > The background thread should only stop after all io is done... Did some experiments last week to see if I could trigger the bug with full debug messages enabled. Biggest problem is that I don't have non-volatile memory available, serial logging slows it down too much to trigger the bug, and the reboot tends to shut down any attempt to offload the log to capture the relevant messages. That being said, I was able to trigger the bug with the following: [root@buildroot ~]# (sleep 5 ; while ! mount -o remount,ro /mnt ; do true ; done ; echo remount > /dev/kmsg ; sleep 5 ; echo reboot > /dev/kmsg ; reboot ) & [2] 564 [root@buildroot ~]# fsstress -p 10 -n 10 -X -d /mnt/fsstress -l 0 In my log I can see the "remount" message and 100ms later I can see the first ubifs assert. I've attached the relevant portion of the logs below from the first time I see LEB 44 mentioned through the asserts. I've put the logs on the web due to concerns of flooding the mailing list with 100's of kB in attachments. https://gist.github.com/aeruder/8651928 ubi_corruption.txt is the kernel log afterwards.txt is the console log with the ensuing issue with ubifs I also have logs of the recovery process in the Linux kernel later on, (still takes 2 mounts), an image of the MTD device, and would be happy to try anything or enable any additional debug messages. > Can you also please find out whether fssstress is still running when > reboot takes action? Thanks for taking a look. I'm reading everything I can find about ubifs to see if I can make some headway into understanding what is going on but filesytems are definitely not my forte :). Cheers, Andrew Ruder -- 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: [BUG] reproducable ubifs reboot assert and corruption
On Sat, Jan 25, 2014 at 04:02:15PM +0100, Richard Weinberger wrote: So ubifs_bgt0_0 stops and the fun begins. Can you trigger the issue also by unmounting /mnt? I.e umount -l /mnt The background thread should only stop after all io is done... Did some experiments last week to see if I could trigger the bug with full debug messages enabled. Biggest problem is that I don't have non-volatile memory available, serial logging slows it down too much to trigger the bug, and the reboot tends to shut down any attempt to offload the log to capture the relevant messages. That being said, I was able to trigger the bug with the following: [root@buildroot ~]# (sleep 5 ; while ! mount -o remount,ro /mnt ; do true ; done ; echo remount /dev/kmsg ; sleep 5 ; echo reboot /dev/kmsg ; reboot ) [2] 564 [root@buildroot ~]# fsstress -p 10 -n 10 -X -d /mnt/fsstress -l 0 In my log I can see the remount message and 100ms later I can see the first ubifs assert. I've attached the relevant portion of the logs below from the first time I see LEB 44 mentioned through the asserts. I've put the logs on the web due to concerns of flooding the mailing list with 100's of kB in attachments. https://gist.github.com/aeruder/8651928 ubi_corruption.txt is the kernel log afterwards.txt is the console log with the ensuing issue with ubifs I also have logs of the recovery process in the Linux kernel later on, (still takes 2 mounts), an image of the MTD device, and would be happy to try anything or enable any additional debug messages. Can you also please find out whether fssstress is still running when reboot takes action? Thanks for taking a look. I'm reading everything I can find about ubifs to see if I can make some headway into understanding what is going on but filesytems are definitely not my forte :). Cheers, Andrew Ruder -- 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] net: sk == 0xffffffff fix - not for commit
On Fri, Jan 24, 2014 at 07:38:31AM -0600, Andrew Ruder wrote:
> http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg574770.html
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
Just a little further confirmation. This appears in
__inet_lookup_established as the last four instructions before
returning.
<+440>: bl <__rcu_read_unlock>
<+444>: sub sp, r11, #40; 0x28
<+448>: ldr r0, [r11, #-48] ; 0x30
<+452>: ldm sp, {r4, r5, r6, r7, r8, r9, r10, r11, sp, pc}
--
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] net: sk == 0xffffffff fix - not for commit
Actually found what looks to be a fix for this in another thread. http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg574770.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 Cheers, Andy -- 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: [BUG] reproducable ubifs reboot assert and corruption
Just expanding distribution a little bit to see if anyone has any ideas. On Tue, Jan 21, 2014 at 11:15:10PM -0600, Andrew Ruder wrote: > Problem: > ubifs corruption to the point where uboot can no longer deal with it and > it takes multiple mounts to recover filesystem from Linux. > > My hardware: > NOR flash > [3.244397] 0.flash: Found 1 x16 devices at 0x0 in 16-bit bank. > Manufacturer ID 0x01 Chip ID 0x002301 > PXA270 > > My software: > 3.12.0 with some patches (not mtd or ubi or flash related) to support my > board. > > I'm able to reproduce this fairly readily by the following sequence of > commands. I'm not able to trigger it with full debug messages enabled > but possibly I could enable them for certain files within the ubifs > driver if something specific would be helpful. But basically it seems > like if I reboot (or mount -o remount,ro) while ubifs is writing, it > sometimes crashes and leaves the partition in a bad state. Sorry about > some of the strangeness of the commands, I am scripting this with expect > and this is my lame attempt to give me something to pattern recognize > off of. > > I should also point out, I have not had any problems at all when I do an > abrupt shutdown (either via pulling power or letting a hardware watchdog > take care of the reset). > > == > == > == > > Here's the log of ubifs driver crashing. > > [0.00] Booting Linux on physical CPU 0x0 > [0.00] Linux version 3.12.0-00041-g7f12d39-dirty > (andy@andrewruder-hplin) (gcc version 4.8.2 (Buildroot > 2013.11-rc1-00028-gf388663) ) #210 PREEMPT Tue Jan 21 21:36:54 CST 2014 > [0.00] CPU: XScale-PXA270 [69054118] revision 8 (ARMv5TE), cr=397f > ... > [3.211589] 0.flash: Found 1 x16 devices at 0x0 in 16-bit bank. > Manufacturer ID 0x01 Chip ID 0x002301 > [3.322188] Amd/Fujitsu Extended Query Table at 0x0040 > [3.327405] Amd/Fujitsu Extended Query version 1.5. > [3.370661] number of CFI chips: 1 > [3.378822] 5 cmdlinepart partitions found on MTD device 0.flash > [3.385273] Creating 5 MTD partitions on "0.flash": > [3.390212] 0x-0x0008 : "uboot" > [3.423423] 0x0008-0x000a : "env" > [3.503423] 0x000a-0x000c : "env_redund" > [3.603453] 0x000c-0x000e : "env_default" > [3.674772] 0x000e-0x0400 : "data" > ... > Welcome to Buildroot > buildroot login: root > Password: > [root@buildroot ~]# echo 7 > /proc/sys/kernel/printk; a=$?; sleep 2 ; [ x$a = > x0 ] || echo "@@FAIL@@" > [root@buildroot ~]# ubiattach -m 4 -d 0; a=$?; sleep 2 ; [ x$a = x0 ] || echo > "@@FAIL@@" > [ 10.055595] UBI: attaching mtd4 to ubi0 > [ 10.107901] UBI: scanning is finished > [ 10.172362] UBI: attached mtd4 (name "data", size 63 MiB) to ubi0 > [ 10.178509] UBI: PEB size: 131072 bytes (128 KiB), LEB size: 130944 bytes > [ 10.220887] UBI: min./max. I/O unit sizes: 1/512, sub-page size 1 > [ 10.228545] UBI: VID header offset: 64 (aligned 64), data offset: 128 > [ 10.240011] UBI: good PEBs: 505, bad PEBs: 0, corrupted PEBs: 0 > [ 10.247227] UBI: user volume: 1, internal volumes: 1, max. volumes count: > 128 > [ 10.255658] UBI: max/mean erase counter: 42/22, WL threshold: 4096, image > sequence number: 2104545903 > [ 10.266343] UBI: available PEBs: 4, total reserved PEBs: 501, PEBs > reserved for bad PEB handling: 0 > [ 10.276740] UBI: background thread "ubi_bgt0d" started, PID 510 > UBI device number 0, total 505 LEBs (66126720 bytes, 63.1 MiB), available 4 > LEBs (523776 bytes, 511.5 KiB), LEB size 130944 bytes (127.9 KiB) > [root@buildroot ~]# mkdir -p /mnt; a=$?; sleep 2 ; [ x$a = x0 ] || echo > "@@FAIL@@" > [root@buildroot ~]# mount -t ubifs ubi0:rootfs /mnt; a=$?; sleep 2 ; [ x$a = > x0 ] || echo "@@FAIL@@" > [ 14.463104] UBIFS: background thread "ubifs_bgt0_0" started, PID 516 > [ 14.985636] UBIFS: mounted UBI device 0, volume 0, name "rootfs" > [ 14.991670] UBIFS: LEB size: 130944 bytes (127 KiB), min./max. I/O unit > sizes: 8 bytes/512 bytes > [ 15.008984] UBIFS: FS size: 63769728 bytes (60 MiB, 487 LEBs), journal > size 3142656 bytes (2 MiB, 24 LEBs) > [ 15.020052] UBIFS: reserved for root: 3012001 bytes (2941 KiB) > [ 15.027374] UBIFS: media format: w4/r0 (latest is w4/r0), UUID > 567F5BCB-663D-4F84-BF34-3282E100D2D9, small LPT model > [root@bu
Re: [BUG] reproducable ubifs reboot assert and corruption
Just expanding distribution a little bit to see if anyone has any ideas. On Tue, Jan 21, 2014 at 11:15:10PM -0600, Andrew Ruder wrote: Problem: ubifs corruption to the point where uboot can no longer deal with it and it takes multiple mounts to recover filesystem from Linux. My hardware: NOR flash [3.244397] 0.flash: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x01 Chip ID 0x002301 PXA270 My software: 3.12.0 with some patches (not mtd or ubi or flash related) to support my board. I'm able to reproduce this fairly readily by the following sequence of commands. I'm not able to trigger it with full debug messages enabled but possibly I could enable them for certain files within the ubifs driver if something specific would be helpful. But basically it seems like if I reboot (or mount -o remount,ro) while ubifs is writing, it sometimes crashes and leaves the partition in a bad state. Sorry about some of the strangeness of the commands, I am scripting this with expect and this is my lame attempt to give me something to pattern recognize off of. I should also point out, I have not had any problems at all when I do an abrupt shutdown (either via pulling power or letting a hardware watchdog take care of the reset). == == == Here's the log of ubifs driver crashing. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.12.0-00041-g7f12d39-dirty (andy@andrewruder-hplin) (gcc version 4.8.2 (Buildroot 2013.11-rc1-00028-gf388663) ) #210 PREEMPT Tue Jan 21 21:36:54 CST 2014 [0.00] CPU: XScale-PXA270 [69054118] revision 8 (ARMv5TE), cr=397f ... [3.211589] 0.flash: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x01 Chip ID 0x002301 [3.322188] Amd/Fujitsu Extended Query Table at 0x0040 [3.327405] Amd/Fujitsu Extended Query version 1.5. [3.370661] number of CFI chips: 1 [3.378822] 5 cmdlinepart partitions found on MTD device 0.flash [3.385273] Creating 5 MTD partitions on 0.flash: [3.390212] 0x-0x0008 : uboot [3.423423] 0x0008-0x000a : env [3.503423] 0x000a-0x000c : env_redund [3.603453] 0x000c-0x000e : env_default [3.674772] 0x000e-0x0400 : data ... Welcome to Buildroot buildroot login: root Password: [root@buildroot ~]# echo 7 /proc/sys/kernel/printk; a=$?; sleep 2 ; [ x$a = x0 ] || echo @@FAIL@@ [root@buildroot ~]# ubiattach -m 4 -d 0; a=$?; sleep 2 ; [ x$a = x0 ] || echo @@FAIL@@ [ 10.055595] UBI: attaching mtd4 to ubi0 [ 10.107901] UBI: scanning is finished [ 10.172362] UBI: attached mtd4 (name data, size 63 MiB) to ubi0 [ 10.178509] UBI: PEB size: 131072 bytes (128 KiB), LEB size: 130944 bytes [ 10.220887] UBI: min./max. I/O unit sizes: 1/512, sub-page size 1 [ 10.228545] UBI: VID header offset: 64 (aligned 64), data offset: 128 [ 10.240011] UBI: good PEBs: 505, bad PEBs: 0, corrupted PEBs: 0 [ 10.247227] UBI: user volume: 1, internal volumes: 1, max. volumes count: 128 [ 10.255658] UBI: max/mean erase counter: 42/22, WL threshold: 4096, image sequence number: 2104545903 [ 10.266343] UBI: available PEBs: 4, total reserved PEBs: 501, PEBs reserved for bad PEB handling: 0 [ 10.276740] UBI: background thread ubi_bgt0d started, PID 510 UBI device number 0, total 505 LEBs (66126720 bytes, 63.1 MiB), available 4 LEBs (523776 bytes, 511.5 KiB), LEB size 130944 bytes (127.9 KiB) [root@buildroot ~]# mkdir -p /mnt; a=$?; sleep 2 ; [ x$a = x0 ] || echo @@FAIL@@ [root@buildroot ~]# mount -t ubifs ubi0:rootfs /mnt; a=$?; sleep 2 ; [ x$a = x0 ] || echo @@FAIL@@ [ 14.463104] UBIFS: background thread ubifs_bgt0_0 started, PID 516 [ 14.985636] UBIFS: mounted UBI device 0, volume 0, name rootfs [ 14.991670] UBIFS: LEB size: 130944 bytes (127 KiB), min./max. I/O unit sizes: 8 bytes/512 bytes [ 15.008984] UBIFS: FS size: 63769728 bytes (60 MiB, 487 LEBs), journal size 3142656 bytes (2 MiB, 24 LEBs) [ 15.020052] UBIFS: reserved for root: 3012001 bytes (2941 KiB) [ 15.027374] UBIFS: media format: w4/r0 (latest is w4/r0), UUID 567F5BCB-663D-4F84-BF34-3282E100D2D9, small LPT model [root@buildroot ~]# rm -fr /mnt/fsstress; a=$?; sleep 2 ; [ x$a = x0 ] || echo @@FAIL@@ [root@buildroot ~]# mkdir -p /mnt/fsstress; a=$?; sleep 2 ; [ x$a = x0 ] || echo @@FAIL@@ [root@buildroot ~]# (sleep 41 ; reboot) [1] 522 [root@buildroot ~]# fsstress -p 10 -n 10 -X -d /mnt/fsstress -l 0 seed = 653587 [ 64.672770] UBIFS: background thread ubifs_bgt0_0 stops The system is going down NOW! Sent SIGTERM to[ 64.753793] UBIFS assert failed in reserve_space at 125 (pid 14) all processes [ 64.760886] CPU: 0 PID: 14
Re: [PATCH] net: sk == 0xffffffff fix - not for commit
Actually found what looks to be a fix for this in another thread. http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg574770.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 Cheers, Andy -- 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] net: sk == 0xffffffff fix - not for commit
On Fri, Jan 24, 2014 at 07:38:31AM -0600, Andrew Ruder wrote:
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg574770.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
Just a little further confirmation. This appears in
__inet_lookup_established as the last four instructions before
returning.
+440: bl __rcu_read_unlock
+444: sub sp, r11, #40; 0x28
+448: ldr r0, [r11, #-48] ; 0x30
+452: ldm sp, {r4, r5, r6, r7, r8, r9, r10, r11, sp, pc}
--
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] net: sk == 0xffffffff fix - not for commit
On Mon, Dec 09, 2013 at 12:47:52PM +0100, Andrzej Pietrasiewicz wrote: > With g_ether loaded the sk occasionally becomes 0x. > It happens usually after transferring few hundreds of kilobytes to few > tens of megabytes. If sk is 0x then dereferencing it causes > kernel panic. Don't know if this is relevant but I had this very similar stack trace come up a few days ago (below). I am working on a PXA 270/xscale with gcc version 4.8.2 (Buildroot 2013.11-rc1-00028-gf388663). Going to try to see if I can reproduce it a little more readily before I start trying to narrow down what is causing it. === Unable to handle kernel NULL pointer dereference at virtual address 0011 pgd = d18e [0011] *pgd=a6d03831, *pte=, *ppte= Internal error: Oops: 17 [#1] PREEMPT ARM Modules linked in: zeusvirt(O) zeus16550(O) 8390p ipv6 CPU: 0 PID: 2365 Comm: sshd Tainted: G O 3.12.0+ #201 task: d7216f00 ti: d7144000 task.ti: d7144000 PC is at tcp_v4_early_demux+0xe8/0x154 LR is at __inet_lookup_established+0x1bc/0x2e0 pc : []lr : []psr: a013 sp : d7145b20 ip : d7145ae8 fp : d7145b44 r10: c0576c28 r9 : 0008 r8 : d7998800 r7 : d7063800 r6 : c6cf2480 r5 : r4 : c6cf2480 r3 : c02ec018 r2 : d7145ad0 r1 : d7b66a28 r0 : Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 397f Table: b18e DAC: 0015 Process sshd (pid: 2365, stack limit = 0xd71441c8) Stack: (0xd7145b20 to 0xd7146000) 5b20: 17bf3f0a 0016 0003 c0026d90 d71f4634 d71f4600 d7145b6c d7145b48 5b40: c03211b4 c0341c20 05ea d7bb0538 d7063800 0034 d71f4600 c6cf2480 5b60: d7145b9c d7145b70 c03218dc c0321158 1001 c0576c1c 5b80: c0577e84 c0576c14 d7145be4 d7145ba0 c02fae04 c03215d4 5ba0: c0590330 c057fc08 d7145bfc c6cf2480 c02571a0 c0576c28 07e1 c05a3dc0 5bc0: 0001 c05a3d60 c05a3d74 c05a3d60 c05a3d68 d7145bfc d7145be8 5be0: c02fb990 c02fa8f0 c05a3dc0 d7145c24 d7145c00 c02fc46c c02fb968 5c00: c02fc3dc c05a3dc0 c05a3d60 0001 012c 0040 d7145c64 d7145c28 5c20: c02fbcd0 c02fc3e8 d78af3c0 d7145c5c 8d99 0001 5c40: c05a81f0 0003 0100 3fa57e1c d7144028 c05a81ec d7145cb4 d7145c68 5c60: c0026a44 c02fbc10 d7145c8c d7145c78 c00538dc c0056ce4 8d98 5c80: 00400100 000a c0228594 6093 c0590330 d7145d54 0001 5ca0: d7bb0480 05b4 d7145ccc d7145cb8 c0026ca4 c00268f4 d7144010 5cc0: d7145ce4 d7145cd0 c0026f58 c0026c58 00ab 001a d7145d04 d7145ce8 5ce0: c000f7d0 c0026ed0 0014 d7145d20 a013 d7145d1c d7145d08 5d00: c00085bc c000f768 c02f0048 c00ca7d8 d7145d7c d7145d20 c03a7dc0 c0008590 5d20: 000118ed c05a474c c05d41cc d7bb0180 d18ed800 d7801080 06a3 5d40: 0001 d7bb0480 05b4 d7145d7c d7145d80 d7145d68 c02f0048 c00ca7d8 5d60: a013 c05a4738 d7bb0180 d7145dac d7145d80 c02f0048 c00ca7b0 5d80: 0001 00c63fc0 d7b66a00 d7b66a00 4040 05b4 d7b66a00 5da0: d7145dcc d7145db0 c032e340 c02effd0 d7145e98 4040 0008c414 5dc0: d7145e54 d7145dd0 c032f368 c032e310 d7145e24 c02ea81c c03a6040 c03a9c6c 5de0: d7145ee8 05b4 d7b66adc 5e00: d7144000 1854 05b4 27ec 0040 d7116d80 05b4 5e20: d7145e6c d7b66a00 d7145ee8 d7145e98 4040 4040 5e40: 4040 0002 d7145e74 d7145e58 c03526c8 c032eb0c d7145e78 d7116d80 5e60: d7145ee0 d7116d80 d7145ed4 d7145e78 c02e63a4 c0352688 c05a3dc0 d7142000 5e80: 0040 4040 d76701c0 d7145ee0 d7145e98 5ea0: d7145ee0 0001 0040 d7145ee8 c6cf2900 5ec0: d7145f78 d7145f44 d7145ed8 c00d1c64 c02e62e4 5ee0: 00089c28 4040 d7116d80 d7145e78 d7216f00 5f00: 4040 5f20: 00089c28 d7116d80 00089c28 d7145f78 4040 00089c28 d7145f74 d7145f48 5f40: c00d23a0 c00d1bf4 d7116d80 5f60: 00089c28 4040 d7145fa4 d7145f78 c00d2948 c00d22c0 5f80: beed167c 0003 000614dc 0004 c000ea28 d7144000 d7145fa8 5fa0: c000e7e0 c00d2908 beed167c 0003 0003 00089c28 4040 beed167c 5fc0: beed167c 0003 000614dc 0004 00089c28 00060a88 093e beed17a0 5fe0: beed167c beed1648 00029910 b6dc821c 6010 0003 [] (tcp_v4_early_demux+0xe8/0x154) from [] (ip_rcv_finish+0x68/0x2c0) [] (ip_rcv_finish+0x68/0x2c0) from [] (ip_rcv+0x314/0x398) [] (ip_rcv+0x314/0x398) from [] (__netif_receive_skb_core+0x520/0x5d8) [] (__netif_receive_skb_core+0x520/0x5d8) from [] (__netif_receive_skb+0x34/0x88) [] (__netif_receive_skb+0x34/0x88) from [] (process_backlog+0x90/0x148) [] (process_backlog+0x90/0x148) from [] (net_rx_action+0xcc/0x258) []
Re: [PATCH] net: sk == 0xffffffff fix - not for commit
On Mon, Dec 09, 2013 at 12:47:52PM +0100, Andrzej Pietrasiewicz wrote: With g_ether loaded the sk occasionally becomes 0x. It happens usually after transferring few hundreds of kilobytes to few tens of megabytes. If sk is 0x then dereferencing it causes kernel panic. Don't know if this is relevant but I had this very similar stack trace come up a few days ago (below). I am working on a PXA 270/xscale with gcc version 4.8.2 (Buildroot 2013.11-rc1-00028-gf388663). Going to try to see if I can reproduce it a little more readily before I start trying to narrow down what is causing it. === Unable to handle kernel NULL pointer dereference at virtual address 0011 pgd = d18e [0011] *pgd=a6d03831, *pte=, *ppte= Internal error: Oops: 17 [#1] PREEMPT ARM Modules linked in: zeusvirt(O) zeus16550(O) 8390p ipv6 CPU: 0 PID: 2365 Comm: sshd Tainted: G O 3.12.0+ #201 task: d7216f00 ti: d7144000 task.ti: d7144000 PC is at tcp_v4_early_demux+0xe8/0x154 LR is at __inet_lookup_established+0x1bc/0x2e0 pc : [c0341cfc]lr : [c0329bd8]psr: a013 sp : d7145b20 ip : d7145ae8 fp : d7145b44 r10: c0576c28 r9 : 0008 r8 : d7998800 r7 : d7063800 r6 : c6cf2480 r5 : r4 : c6cf2480 r3 : c02ec018 r2 : d7145ad0 r1 : d7b66a28 r0 : Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 397f Table: b18e DAC: 0015 Process sshd (pid: 2365, stack limit = 0xd71441c8) Stack: (0xd7145b20 to 0xd7146000) 5b20: 17bf3f0a 0016 0003 c0026d90 d71f4634 d71f4600 d7145b6c d7145b48 5b40: c03211b4 c0341c20 05ea d7bb0538 d7063800 0034 d71f4600 c6cf2480 5b60: d7145b9c d7145b70 c03218dc c0321158 1001 c0576c1c 5b80: c0577e84 c0576c14 d7145be4 d7145ba0 c02fae04 c03215d4 5ba0: c0590330 c057fc08 d7145bfc c6cf2480 c02571a0 c0576c28 07e1 c05a3dc0 5bc0: 0001 c05a3d60 c05a3d74 c05a3d60 c05a3d68 d7145bfc d7145be8 5be0: c02fb990 c02fa8f0 c05a3dc0 d7145c24 d7145c00 c02fc46c c02fb968 5c00: c02fc3dc c05a3dc0 c05a3d60 0001 012c 0040 d7145c64 d7145c28 5c20: c02fbcd0 c02fc3e8 d78af3c0 d7145c5c 8d99 0001 5c40: c05a81f0 0003 0100 3fa57e1c d7144028 c05a81ec d7145cb4 d7145c68 5c60: c0026a44 c02fbc10 d7145c8c d7145c78 c00538dc c0056ce4 8d98 5c80: 00400100 000a c0228594 6093 c0590330 d7145d54 0001 5ca0: d7bb0480 05b4 d7145ccc d7145cb8 c0026ca4 c00268f4 d7144010 5cc0: d7145ce4 d7145cd0 c0026f58 c0026c58 00ab 001a d7145d04 d7145ce8 5ce0: c000f7d0 c0026ed0 0014 d7145d20 a013 d7145d1c d7145d08 5d00: c00085bc c000f768 c02f0048 c00ca7d8 d7145d7c d7145d20 c03a7dc0 c0008590 5d20: 000118ed c05a474c c05d41cc d7bb0180 d18ed800 d7801080 06a3 5d40: 0001 d7bb0480 05b4 d7145d7c d7145d80 d7145d68 c02f0048 c00ca7d8 5d60: a013 c05a4738 d7bb0180 d7145dac d7145d80 c02f0048 c00ca7b0 5d80: 0001 00c63fc0 d7b66a00 d7b66a00 4040 05b4 d7b66a00 5da0: d7145dcc d7145db0 c032e340 c02effd0 d7145e98 4040 0008c414 5dc0: d7145e54 d7145dd0 c032f368 c032e310 d7145e24 c02ea81c c03a6040 c03a9c6c 5de0: d7145ee8 05b4 d7b66adc 5e00: d7144000 1854 05b4 27ec 0040 d7116d80 05b4 5e20: d7145e6c d7b66a00 d7145ee8 d7145e98 4040 4040 5e40: 4040 0002 d7145e74 d7145e58 c03526c8 c032eb0c d7145e78 d7116d80 5e60: d7145ee0 d7116d80 d7145ed4 d7145e78 c02e63a4 c0352688 c05a3dc0 d7142000 5e80: 0040 4040 d76701c0 d7145ee0 d7145e98 5ea0: d7145ee0 0001 0040 d7145ee8 c6cf2900 5ec0: d7145f78 d7145f44 d7145ed8 c00d1c64 c02e62e4 5ee0: 00089c28 4040 d7116d80 d7145e78 d7216f00 5f00: 4040 5f20: 00089c28 d7116d80 00089c28 d7145f78 4040 00089c28 d7145f74 d7145f48 5f40: c00d23a0 c00d1bf4 d7116d80 5f60: 00089c28 4040 d7145fa4 d7145f78 c00d2948 c00d22c0 5f80: beed167c 0003 000614dc 0004 c000ea28 d7144000 d7145fa8 5fa0: c000e7e0 c00d2908 beed167c 0003 0003 00089c28 4040 beed167c 5fc0: beed167c 0003 000614dc 0004 00089c28 00060a88 093e beed17a0 5fe0: beed167c beed1648 00029910 b6dc821c 6010 0003 [c0341cfc] (tcp_v4_early_demux+0xe8/0x154) from [c03211b4] (ip_rcv_finish+0x68/0x2c0) [c03211b4] (ip_rcv_finish+0x68/0x2c0) from [c03218dc] (ip_rcv+0x314/0x398) [c03218dc] (ip_rcv+0x314/0x398) from [c02fae04] (__netif_receive_skb_core+0x520/0x5d8) [c02fae04] (__netif_receive_skb_core+0x520/0x5d8) from [c02fb990] (__netif_receive_skb+0x34/0x88) [c02fb990] (__netif_receive_skb+0x34/0x88) from [c02fc46c] (process_backlog+0x90/0x148)
Re: [RFC] OMAP: allow GPIO pin to enable/disable external UART driver chip.
Sorry for the late reply, I've been thinking about this for some time and was sad to see it didn't really evoke any sort of discussion :(. On Sat, Aug 10, 2013 at 02:58:08PM +0100, Mark Jackson wrote: > When a UART transmitter is connected to (eg) a RS485 driver, it is > necessary to turn the driver on/off as quickly as possible. This is > best achieved in the serial driver itself (rather than in userspace > where the latency can be quite large). > > This patch allows the GPIO pin to be defined (via DT) that controls > the enabling of the driver at the start of a message, and disables > the driver when the message has been completed. > > Still to do:- > Allow userspace to turn this feature on/off > Do the same for the receiver (useful for 2 wire RS485) I've been wondering about this as well but I have a slightly different situation. On my board the RTS line controls the RS485 transmit/receive direction. I don't know if you've found the Documentation/serial/serial-rs485.txt file but it describes, at the very least, a standard API For controlling several parameters related to RS485 including configurable delay between rts->start of data/end of data->rts. Unfortunately it seems like only one driver really implements the full API (Atmel AT91) and I guess it needs to be bolted onto each serial driver individually (although it seems like a fairly general concept that could be handled at another level). That being said, maybe this patch would better be rethought as a way to specify a GPIO for the RTS line (I don't know enough about OMAP and whether or not it already provides for hardware flow control in its builtin UARTs and you just aren't using it for RS485 flow control?) and then in a separate patch implement this already documented user->kernel API? - Andy -- 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] OMAP: allow GPIO pin to enable/disable external UART driver chip.
Sorry for the late reply, I've been thinking about this for some time and was sad to see it didn't really evoke any sort of discussion :(. On Sat, Aug 10, 2013 at 02:58:08PM +0100, Mark Jackson wrote: When a UART transmitter is connected to (eg) a RS485 driver, it is necessary to turn the driver on/off as quickly as possible. This is best achieved in the serial driver itself (rather than in userspace where the latency can be quite large). This patch allows the GPIO pin to be defined (via DT) that controls the enabling of the driver at the start of a message, and disables the driver when the message has been completed. Still to do:- Allow userspace to turn this feature on/off Do the same for the receiver (useful for 2 wire RS485) I've been wondering about this as well but I have a slightly different situation. On my board the RTS line controls the RS485 transmit/receive direction. I don't know if you've found the Documentation/serial/serial-rs485.txt file but it describes, at the very least, a standard API For controlling several parameters related to RS485 including configurable delay between rts-start of data/end of data-rts. Unfortunately it seems like only one driver really implements the full API (Atmel AT91) and I guess it needs to be bolted onto each serial driver individually (although it seems like a fairly general concept that could be handled at another level). That being said, maybe this patch would better be rethought as a way to specify a GPIO for the RTS line (I don't know enough about OMAP and whether or not it already provides for hardware flow control in its builtin UARTs and you just aren't using it for RS485 flow control?) and then in a separate patch implement this already documented user-kernel API? - Andy -- 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: how to be a kernel developer ?
Alejandro Bonilla wrote: This exact question is made at least every 15 days. Did you google? You will need to make that your Home Page. And after that, make your first google search kernelnewbies. - Andrew Ruder - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how to be a kernel developer ?
Alejandro Bonilla wrote: This exact question is made at least every 15 days. Did you google? You will need to make that your Home Page. And after that, make your first google search kernelnewbies. - Andrew Ruder - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
