Re: [RFC/PATCH] ARM: ixp4xx gpiolib support
Imre Kaloz ka...@openwrt.org writes:
Hi,
I can't test it but it looks good. Just small nitpicks. See below.
This patch adds gpiolib support for the IXP4xx platform
Signed-off-by: Imre Kaloz ka...@openwrt.org
---
arch/arm/Kconfig |2 +-
arch/arm/mach-ixp4xx/common.c| 39 +
arch/arm/mach-ixp4xx/include/mach/gpio.h | 46
++
3 files changed, 55 insertions(+), 32 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 3269576..e793a75 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -481,7 +481,7 @@ config ARCH_IXP4XX
depends on MMU
select CLKSRC_MMIO
select CPU_XSCALE
- select GENERIC_GPIO
+ select ARCH_REQUIRE_GPIOLIB
select GENERIC_CLOCKEVENTS
select HAVE_SCHED_CLOCK
select MIGHT_HAVE_PCI
diff --git a/arch/arm/mach-ixp4xx/common.c b/arch/arm/mach-ixp4xx/common.c
index 0777257..7603456 100644
--- a/arch/arm/mach-ixp4xx/common.c
+++ b/arch/arm/mach-ixp4xx/common.c
@@ -36,6 +36,7 @@
#include asm/page.h
#include asm/irq.h
#include asm/sched_clock.h
+#include asm/gpio.h
#include asm/mach/map.h
#include asm/mach/irq.h
@@ -375,12 +376,50 @@ static struct platform_device *ixp46x_devices[]
__initdata = {
unsigned long ixp4xx_exp_bus_size;
EXPORT_SYMBOL(ixp4xx_exp_bus_size);
+static int ixp4xx_gpio_direction_input(struct gpio_chip *chip, unsigned gpio)
+{
+ gpio_line_config(gpio, IXP4XX_GPIO_IN);
+ return 0;
+}
+
+static int ixp4xx_gpio_direction_output(struct gpio_chip *chip, unsigned
gpio, int level)
+{
+ gpio_line_set(gpio, level);
+ gpio_line_config(gpio, IXP4XX_GPIO_OUT);
+ return 0;
+}
+
+static int ixp4xx_gpio_get_value(struct gpio_chip *chip, unsigned gpio)
+{
+ int value;
+
+ gpio_line_get(gpio, value);
+ return value;
+}
+
+static void ixp4xx_gpio_set_value(struct gpio_chip *chip, unsigned gpio, int
value)
+{
+ gpio_line_set(gpio, value);
+}
+
+static struct gpio_chip ixp4xx_gpio_chip = {
+ .label = IXP4XX_GPIO_CHIP,
+ .direction_input= ixp4xx_gpio_direction_input,
+ .direction_output = ixp4xx_gpio_direction_output,
+ .get= ixp4xx_gpio_get_value,
+ .set= ixp4xx_gpio_set_value,
+ .base = 0,
+ .ngpio = 16,
Use NR_BUILTIN_GPIO instead of 16 ?
+};
+
void __init ixp4xx_sys_init(void)
{
ixp4xx_exp_bus_size = SZ_16M;
platform_add_devices(ixp4xx_devices, ARRAY_SIZE(ixp4xx_devices));
+ gpiochip_add(ixp4xx_gpio_chip);
+
if (cpu_is_ixp46x()) {
int region;
diff --git a/arch/arm/mach-ixp4xx/include/mach/gpio.h
b/arch/arm/mach-ixp4xx/include/mach/gpio.h
index a5f87de..86f3596 100644
--- a/arch/arm/mach-ixp4xx/include/mach/gpio.h
+++ b/arch/arm/mach-ixp4xx/include/mach/gpio.h
@@ -27,47 +27,31 @@
#include linux/kernel.h
#include mach/hardware.h
+#include asm-generic/gpio.h/* cansleep wrappers */
-static inline int gpio_request(unsigned gpio, const char *label)
-{
- return 0;
-}
-
-static inline void gpio_free(unsigned gpio)
-{
- might_sleep();
-
- return;
-}
-
-static inline int gpio_direction_input(unsigned gpio)
-{
- gpio_line_config(gpio, IXP4XX_GPIO_IN);
- return 0;
-}
-
-static inline int gpio_direction_output(unsigned gpio, int level)
-{
- gpio_line_set(gpio, level);
- gpio_line_config(gpio, IXP4XX_GPIO_OUT);
- return 0;
-}
+#define NR_BUILTIN_GPIO 16
static inline int gpio_get_value(unsigned gpio)
{
- int value;
-
- gpio_line_get(gpio, value);
-
- return value;
+ if (gpio NR_BUILTIN_GPIO)
+ {
+ int value;
+ gpio_line_get(gpio, value);
+ return value;
+ }
+ else
+ return __gpio_get_value(gpio);
Please use
if () {
} else
I would also put the 'int value' declaration outside the if ().
Thanks,
Arnaud
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871uvu6u89@lebrac.rtp-net.org
Re: [RFC/PATCH] ARM: ixp4xx gpiolib support
Hello,
On Mon, Sep 05, 2011 at 02:49:51PM +0200, Imre Kaloz wrote:
This patch adds gpiolib support for the IXP4xx platform
Signed-off-by: Imre Kaloz ka...@openwrt.org
---
arch/arm/Kconfig |2 +-
arch/arm/mach-ixp4xx/common.c| 39 +
arch/arm/mach-ixp4xx/include/mach/gpio.h | 46
++
3 files changed, 55 insertions(+), 32 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 3269576..e793a75 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -481,7 +481,7 @@ config ARCH_IXP4XX
depends on MMU
select CLKSRC_MMIO
select CPU_XSCALE
- select GENERIC_GPIO
+ select ARCH_REQUIRE_GPIOLIB
select GENERIC_CLOCKEVENTS
select HAVE_SCHED_CLOCK
select MIGHT_HAVE_PCI
diff --git a/arch/arm/mach-ixp4xx/common.c b/arch/arm/mach-ixp4xx/common.c
index 0777257..7603456 100644
--- a/arch/arm/mach-ixp4xx/common.c
+++ b/arch/arm/mach-ixp4xx/common.c
@@ -36,6 +36,7 @@
#include asm/page.h
#include asm/irq.h
#include asm/sched_clock.h
+#include asm/gpio.h
#include asm/mach/map.h
#include asm/mach/irq.h
@@ -375,12 +376,50 @@ static struct platform_device *ixp46x_devices[]
__initdata = {
unsigned long ixp4xx_exp_bus_size;
EXPORT_SYMBOL(ixp4xx_exp_bus_size);
+static int ixp4xx_gpio_direction_input(struct gpio_chip *chip, unsigned gpio)
+{
+ gpio_line_config(gpio, IXP4XX_GPIO_IN);
+ return 0;
+}
+
+static int ixp4xx_gpio_direction_output(struct gpio_chip *chip, unsigned
gpio, int level)
+{
+ gpio_line_set(gpio, level);
+ gpio_line_config(gpio, IXP4XX_GPIO_OUT);
+ return 0;
+}
+
+static int ixp4xx_gpio_get_value(struct gpio_chip *chip, unsigned gpio)
+{
+ int value;
+
+ gpio_line_get(gpio, value);
+ return value;
+}
+
+static void ixp4xx_gpio_set_value(struct gpio_chip *chip, unsigned gpio, int
value)
+{
+ gpio_line_set(gpio, value);
+}
+
+static struct gpio_chip ixp4xx_gpio_chip = {
+ .label = IXP4XX_GPIO_CHIP,
+ .direction_input= ixp4xx_gpio_direction_input,
+ .direction_output = ixp4xx_gpio_direction_output,
+ .get= ixp4xx_gpio_get_value,
+ .set= ixp4xx_gpio_set_value,
+ .base = 0,
+ .ngpio = 16,
+};
+
void __init ixp4xx_sys_init(void)
{
ixp4xx_exp_bus_size = SZ_16M;
platform_add_devices(ixp4xx_devices, ARRAY_SIZE(ixp4xx_devices));
+ gpiochip_add(ixp4xx_gpio_chip);
+
if (cpu_is_ixp46x()) {
int region;
diff --git a/arch/arm/mach-ixp4xx/include/mach/gpio.h
b/arch/arm/mach-ixp4xx/include/mach/gpio.h
index a5f87de..86f3596 100644
--- a/arch/arm/mach-ixp4xx/include/mach/gpio.h
+++ b/arch/arm/mach-ixp4xx/include/mach/gpio.h
@@ -27,47 +27,31 @@
#include linux/kernel.h
#include mach/hardware.h
+#include asm-generic/gpio.h/* cansleep wrappers */
-static inline int gpio_request(unsigned gpio, const char *label)
-{
- return 0;
-}
-
-static inline void gpio_free(unsigned gpio)
-{
- might_sleep();
-
- return;
-}
-
-static inline int gpio_direction_input(unsigned gpio)
-{
- gpio_line_config(gpio, IXP4XX_GPIO_IN);
- return 0;
-}
-
-static inline int gpio_direction_output(unsigned gpio, int level)
-{
- gpio_line_set(gpio, level);
- gpio_line_config(gpio, IXP4XX_GPIO_OUT);
- return 0;
-}
+#define NR_BUILTIN_GPIO 16
static inline int gpio_get_value(unsigned gpio)
{
- int value;
-
- gpio_line_get(gpio, value);
-
- return value;
+ if (gpio NR_BUILTIN_GPIO)
you might want to test the impact of using
if (__builtin_constant_p(gpio) gpio NR_BUILTIN_GPIO)
here. I don't know what to expect from it, but this is the idiom I saw
when I implemented gpio stuff some years ago.
+ {
+ int value;
+ gpio_line_get(gpio, value);
+ return value;
I wonder about the return value of gpio_line_get. If it's void why not
change it to return the value instead of using an output parameter.
+ }
+ else
+ return __gpio_get_value(gpio);
}
static inline void gpio_set_value(unsigned gpio, int value)
{
- gpio_line_set(gpio, value);
+ if (gpio NR_BUILTIN_GPIO)
+ gpio_line_set(gpio, value);
+ else
+ __gpio_set_value(gpio, value);
}
-#include asm-generic/gpio.h/* cansleep wrappers */
+#define gpio_cansleep __gpio_cansleep
extern int gpio_to_irq(int gpio);
extern int irq_to_gpio(unsigned int irq);
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To UNSUBSCRIBE, email to
Re: [PATCH] arm: ixp4xx, u300: Select ARCH_REQUIRE_GPIOLIB, not GENERIC_GPIO
On Mon, Sep 5, 2011 at 6:22 PM, Ben Hutchings b...@decadent.org.uk wrote: On Mon, Sep 05, 2011 at 02:41:30PM +0200, Linus Walleij wrote: On Mon, Sep 5, 2011 at 5:12 AM, Ben Hutchings b...@decadent.org.uk wrote: @@ -830,7 +830,7 @@ config ARCH_U300 select GENERIC_CLOCKEVENTS select CLKDEV_LOOKUP select HAVE_MACH_CLKDEV - select GENERIC_GPIO + select ARCH_REQUIRE_GPIOLIB help Support for ST-Ericsson U300 series mobile platforms. Please don't do that, it really is no gpiolib implementation. In the archives you can find patches I already submitted switching the U300 GPIO over to use gpiolib. [...] OK. But it doesn't seem to work without gpiolib either: CC [M] drivers/input/touchscreen/ads7846.o drivers/input/touchscreen/ads7846.c: In function 'ads7846_setup_pendown': drivers/input/touchscreen/ads7846.c:970:3: error: implicit declaration of function 'gpio_request_one' Yes. I don't know a good way out of this really :-( I'll start looking for the bad ways out, like hacking the GPIO driver to do GPIOLIB in a not-so-elegant way. Yours, Linus Walleij -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cacrpkdzfj_ofkgdzytvvcx9xkppitsxm2fcpwwwaewsegzj...@mail.gmail.com
Re: [PATCH] gpio: rewrite U300 GPIO to use gpiolib
On Tue, Sep 06, 2011 at 10:32:30AM +0200, Linus Walleij wrote: This is based on top of the pending GPIO cleanups in Russells tree, if I can get some ACK on this I presume Russell can apply it to his branch. diff --git a/arch/arm/mach-u300/include/mach/gpio.h b/arch/arm/mach-u300/include/mach/gpio.h index 430a054..ba224b5 100644 --- a/arch/arm/mach-u300/include/mach/gpio.h +++ b/arch/arm/mach-u300/include/mach/gpio.h @@ -13,35 +13,15 @@ #ifndef __MACH_U300_GPIO_H #define __MACH_U300_GPIO_H +#include linux/io.h +#include mach/hardware.h +#include asm/irq.h +#include asm-generic/gpio.h +/* Map these overrides to gpiolib functions, simply */ +#define gpio_get_value __gpio_get_value +#define gpio_set_value __gpio_set_value +#define gpio_cansleep __gpio_cansleep +#define gpio_to_irq __gpio_to_irq +#endif This is how mach/gpio.h ends up looking - two things: 1. is there any reason for asm/irq.h and linux/io.h in there? 2. asm/gpio.h already includes asm-generic/gpio.h and defines the dispatchers for the trivial case. So, I think this is how it should look: #ifndef __MACH_U300_GPIO_H #define __MACH_U300_GPIO_H #include mach/hardware.h #endif Or even just: /* empty */ if mach/hardware.h include is not required for ARCH_NR_GPIOS. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110906084938.gi6...@n2100.arm.linux.org.uk
Re: [PATCH] gpio: rewrite U300 GPIO to use gpiolib
On Tue, Sep 6, 2011 at 10:49 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: +#include linux/io.h +#include mach/hardware.h +#include asm/irq.h +#include asm-generic/gpio.h +/* Map these overrides to gpiolib functions, simply */ +#define gpio_get_value __gpio_get_value +#define gpio_set_value __gpio_set_value +#define gpio_cansleep __gpio_cansleep +#define gpio_to_irq __gpio_to_irq +#endif This is how mach/gpio.h ends up looking - two things: 1. is there any reason for asm/irq.h and linux/io.h in there? No. 2. asm/gpio.h already includes asm-generic/gpio.h and defines the dispatchers for the trivial case. Yep. So, I think this is how it should look: #ifndef __MACH_U300_GPIO_H #define __MACH_U300_GPIO_H #include mach/hardware.h #endif Or even just: /* empty */ It works fine when left empty, so respinning it like that. if mach/hardware.h include is not required for ARCH_NR_GPIOS. It'll survive with just the default number of GPIOs. Thanks, Linus Walleij -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACRpkda0-SU5rUYkg7MyNSDpYZPmKYuosfJDh=yha+skac1...@mail.gmail.com
Re: [PATCH] gpio: rewrite U300 GPIO to use gpiolib
Linus Walleij linus.wall...@stericsson.com writes:
Hi,
From: Linus Walleij linus.wall...@linaro.org
This rewrites the U300 GPIO so as to use gpiolib and
struct gpio_chip instead of just generic GPIO, hiding
all the platform specifics and passing in GPIO chip
variant as platform data at runtime instead of the
compiletime kludges.
Cc: Russell King li...@arm.linux.org.uk
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Debian kernel maintainers debian-kernel@lists.debian.org
Reported-by: Ben Hutchings b...@decadent.org.uk
Signed-off-nu: Linus Walleij linus.wall...@linaro.org
---
First I though that I had to have runtime pin configuration
to solve this, but it turns out that all users of the config
functionality were inside the U300 GPIO driver itself, so
I just made that functionality private to the driver.
This solves the problem observed by Ben Hutchings that some
touchscreen input devices wouldn't work with certain ARM
machines still using just generic GPIO.
This is based on top of the pending GPIO cleanups in Russells
tree, if I can get some ACK on this I presume Russell can
apply it to his branch.
---
arch/arm/Kconfig|1 +
arch/arm/mach-u300/Kconfig |1 +
arch/arm/mach-u300/core.c | 31 +-
arch/arm/mach-u300/include/mach/gpio-u300.h | 149 +---
arch/arm/mach-u300/include/mach/gpio.h | 40 +-
arch/arm/mach-u300/include/mach/irqs.h | 25 +-
drivers/gpio/Kconfig|9 +
drivers/gpio/gpio-u300.c| 1191
---
8 files changed, 795 insertions(+), 652 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f23712d..3f38a7f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -831,6 +831,7 @@ config ARCH_U300
select CLKDEV_LOOKUP
select HAVE_MACH_CLKDEV
select GENERIC_GPIO
+ select ARCH_REQUIRE_GPIOLIB
help
Support for ST-Ericsson U300 series mobile platforms.
diff --git a/arch/arm/mach-u300/Kconfig b/arch/arm/mach-u300/Kconfig
index 966a5a0..39e077e 100644
--- a/arch/arm/mach-u300/Kconfig
+++ b/arch/arm/mach-u300/Kconfig
@@ -6,6 +6,7 @@ comment ST-Ericsson Mobile Platform Products
config MACH_U300
bool U300
+ select GPIO_U300
comment ST-Ericsson U300/U330/U335/U365 Feature Selections
diff --git a/arch/arm/mach-u300/core.c b/arch/arm/mach-u300/core.c
index 724037e..2f1d758 100644
--- a/arch/arm/mach-u300/core.c
+++ b/arch/arm/mach-u300/core.c
@@ -38,6 +38,7 @@
#include mach/hardware.h
#include mach/syscon.h
#include mach/dma_channels.h
+#include mach/gpio-u300.h
#include clock.h
#include mmc.h
@@ -223,7 +224,7 @@ static struct resource gpio_resources[] = {
.end = IRQ_U300_GPIO_PORT2,
.flags = IORESOURCE_IRQ,
},
-#ifdef U300_COH901571_3
+#if defined(CONFIG_MACH_U300_BS365) || defined(CONFIG_MACH_U300_BS335)
{
.name = gpio3,
.start = IRQ_U300_GPIO_PORT3,
@@ -236,6 +237,7 @@ static struct resource gpio_resources[] = {
.end = IRQ_U300_GPIO_PORT4,
.flags = IORESOURCE_IRQ,
},
+#endif
hmm.. silly question: Now that u300 gpios can/will be added through
gpiochip_add, is it still required to used #ifdef instead of
machine_is_foo() or use some different platform devices for that like it
was done on mxc ?
#ifdef CONFIG_MACH_U300_BS335
{
.name = gpio5,
@@ -250,7 +252,6 @@ static struct resource gpio_resources[] = {
.flags = IORESOURCE_IRQ,
},
#endif /* CONFIG_MACH_U300_BS335 */
-#endif /* U300_COH901571_3 */
};
static struct resource keypad_resources[] = {
@@ -1495,11 +1496,35 @@ static struct platform_device i2c1_device = {
.resource = i2c1_resources,
};
+/*
+ * The different variants have a few different versions of the
+ * GPIO block, with different number of ports.
+ */
+static struct u300_gpio_platform u300_gpio_plat = {
+#if defined(CONFIG_MACH_U300_BS2X) || defined(CONFIG_MACH_U300_BS330)
+ .variant = U300_GPIO_COH901335,
+ .ports = 3,
+#endif
+#ifdef CONFIG_MACH_U300_BS335
+ .variant = U300_GPIO_COH901571_3_BS335,
+ .ports = 7,
+#endif
+#ifdef CONFIG_MACH_U300_BS365
+ .variant = U300_GPIO_COH901571_3_BS365,
+ .ports = 5,
+#endif
+ .gpio_base = 0,
+ .gpio_irq_base = IRQ_U300_GPIO_BASE,
+};
+
static struct platform_device gpio_device = {
.name = u300-gpio,
.id = -1,
.num_resources = ARRAY_SIZE(gpio_resources),
.resource = gpio_resources,
+ .dev = {
+ .platform_data = u300_gpio_plat,
+ },
};
static struct platform_device keypad_device = {
@@ -1596,7 +1621,7 @@ void __init u300_init_irq(void)
BUG_ON(IS_ERR(clk));
clk_enable(clk);
- for (i = 0; i NR_IRQS; i++)
+ for (i = 0; i
Bug#640665: linux-image-2.6.32-5-amd64: USB block device write error with images 4 GB
Package: linux-2.6 Version: 2.6.32-35 Severity: normal I've partitioned a USB stick with parted into two partitions. The first one is set to be slightly larger than an image files which is copied over onto with dd, followed by a bootloader installation into the MBR. Now, this setup works fine for image files up to around 4 GB. Recently, the file has grown to 4329570304 bytes which is slightly larger than this boundary. Suddenly, the dd invocation locks up at around the boundary and the kernel spits out some sort of device blocked for too long panic. The call trace can be found in the log below. Since the system is all amd64, this looks like a strange issue to me. Also, it affects not just one USB stick but even a newly bought one (costly bug reporting...). Just copying the image to another file on an ext4 partition also works without any issues. Here's the command line used for the copy to the device: sudo dd if=foo.img of=/dev/sdb1 bs=1048576 -- Package-specific info: ** Version: Linux version 2.6.32-5-amd64 (Debian 2.6.32-35) (da...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Tue Jun 14 09:42:28 UTC 2011 ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-amd64 root=UUID=62f16ca4-eb34-479b-8791-2c979a729c1c ro quiet ** Not tainted ** Kernel log: [ 1641.568094] groups: 2 (cpu_power = 589) 3 (cpu_power = 589) [ 1641.568105] domain 1: span 0-3 level MC [ 1641.568110]groups: 2-3 (cpu_power = 1178) 0-1 (cpu_power = 1178) [ 1641.568123] CPU3 attaching sched-domain: [ 1641.568127] domain 0: span 2-3 level SIBLING [ 1641.568132] groups: 3 (cpu_power = 589) 2 (cpu_power = 589) [ 1641.568144] domain 1: span 0-3 level MC [ 1641.568149]groups: 2-3 (cpu_power = 1178) 0-1 (cpu_power = 1178) [ 1641.678982] usb 1-1.4: new full speed USB device using ehci_hcd and address 8 [ 1641.774061] usb 1-1.4: New USB device found, idVendor=0a5c, idProduct=217f [ 1641.774064] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 1641.774067] usb 1-1.4: Product: Broadcom Bluetooth Device [ 1641.774068] usb 1-1.4: Manufacturer: Broadcom Corp [ 1641.774069] usb 1-1.4: SerialNumber: 5CAC4CCCA816 [ 1641.774169] usb 1-1.4: configuration #1 chosen from 1 choice [ 4430.050179] usb 1-1.1: new high speed USB device using ehci_hcd and address 9 [ 4430.151155] usb 1-1.1: New USB device found, idVendor=18a5, idProduct=0302 [ 4430.151159] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 4430.151163] usb 1-1.1: Product: STORE N GO [ 4430.151165] usb 1-1.1: Manufacturer: Verbatim [ 4430.151167] usb 1-1.1: SerialNumber: 07B40807497A8A05 [ 4430.151299] usb 1-1.1: configuration #1 chosen from 1 choice [ 4430.151776] scsi7 : SCSI emulation for USB Mass Storage devices [ 4430.151956] usb-storage: device found at 9 [ 4430.151959] usb-storage: waiting for device to settle before scanning [ 4435.150411] usb-storage: device scan complete [ 4435.335136] scsi 7:0:0:0: Direct-Access Verbatim STORE N GO 5.00 PQ: 0 ANSI: 0 CCS [ 4435.335553] sd 7:0:0:0: Attached scsi generic sg2 type 0 [ 4436.038227] sd 7:0:0:0: [sdb] 15645120 512-byte logical blocks: (8.01 GB/7.45 GiB) [ 4436.038865] sd 7:0:0:0: [sdb] Write Protect is off [ 4436.038871] sd 7:0:0:0: [sdb] Mode Sense: 23 00 00 00 [ 4436.038875] sd 7:0:0:0: [sdb] Assuming drive cache: write through [ 4436.042171] sd 7:0:0:0: [sdb] Assuming drive cache: write through [ 4436.042176] sdb: sdb1 [ 4436.071557] sd 7:0:0:0: [sdb] Assuming drive cache: write through [ 4436.071563] sd 7:0:0:0: [sdb] Attached SCSI removable disk [ 4572.598727] e1000e :00:19.0: irq 29 for MSI/MSI-X [ 4572.653595] e1000e :00:19.0: irq 29 for MSI/MSI-X [ 4572.654945] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 4574.227071] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX [ 4574.227074] :00:19.0: eth0: 10/100 speed: disabling TSO [ 4574.229210] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 4585.164741] eth0: no IPv6 routers present [ 5880.800476] INFO: task blkid:4527 blocked for more than 120 seconds. [ 5880.800481] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 5880.800484] blkid D 0 4527 4032 0x [ 5880.800490] 814611f0 0082 ea0004f8b1c0 [ 5880.800495] 08a2 88011d00 f9e0 88016b84bfd8 [ 5880.800500] 00015780 00015780 880237323f90 880237324288 [ 5880.800505] Call Trace: [ 5880.800516] [8118f973] ? kobject_get+0x12/0x17 [ 5880.800523] [812fb99b] ? __mutex_lock_common+0x122/0x192 [ 5880.800527] [812fbac3] ? mutex_lock+0x1a/0x31 [ 5880.800535] [8111282e] ? __blkdev_get+0x75/0x342 [ 5880.800539] [81112b02] ? blkdev_open+0x0/0x96 [ 5880.800543] [81112b69] ? blkdev_open+0x67/0x96 [ 5880.800549] [810ed45a] ? __dentry_open+0x19d/0x2bf [ 5880.800555] [810f8cbb] ?
Car DVD GPS business partner
Dear Purchasing Manager, Good morning my friend. Thanks for your time to read my email. Glad to know you are in the market of Car Audio Entertainment (Car accessories) industry. We are a manufacture of Car Audio Entertainment / Car DVD GPS system from China. Would you mind to visit our website :www.hifimax.net ? Wish our products will be helpful for your business. Any questions,Welcome contact us for further information.Thanks. Best Regards Paul Nong (manager) Hifimax Industrial Ltd -- China = sa...@hifimax.net sa...@hifimax.com.cn MSN:hifi...@hotmail.com Tel:(86)-756-2220505 Website :http://www.hifimax.net
Bug#640672: moving files to arch specific include breaks compilations with -m32
Package: linux-libc-dev Version: 3.0.0-3 Severity: normal File: /usr/include/x86_64-linux-gnu/asm/errno.h Hi, since asm/errno.h was moved to the arch specific sub directory it is no longer possible to create 32 Bit Binaries on amd64: | $ echo '#include errno.h' | gcc -E -o - -m32 - | [...] | # 1 /usr/include/bits/errno.h 1 3 4 | # 25 /usr/include/bits/errno.h 3 4 | # 1 /usr/include/linux/errno.h 1 3 4 | In file included from /usr/include/bits/errno.h:25:0, | from /usr/include/errno.h:36, | from stdin:1: | /usr/include/linux/errno.h:4:23: fatal error: asm/errno.h: No such file or directory | compilation terminated. I guess with multiarch I should install the i386 deb, too. But this is not yet supported by dpkg in unstable, is it? Daniel -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information pgpvBEF9CX2RY.pgp Description: PGP signature
Bug#640650: fs/devpts/inode.c: correctly check d_alloc_name() return code in devpts_pty_new()
This should be applied to all of 2.6.{32,33,34,35}:
commit b12d12596992f608f5506a8dabe4d1299594bd1e
Author: Andrey Vagin ava...@openvz.org
Date: Tue Mar 22 16:35:11 2011 -0700
fs/devpts/inode.c: correctly check d_alloc_name() return code in
devpts_pty_new()
Ben.
signature.asc
Description: This is a digitally signed message part
Bug#640650: linux-image-2.6.32-5-openvz-amd64: kernel NULL pointer dereference
I understand this and found a patch that should fix it. Ben. signature.asc Description: This is a digitally signed message part
Processed: tagging 640650
Processing commands for cont...@bugs.debian.org: tags 640650 + pending Bug #640650 [linux-2.6] linux-image-2.6.32-5-openvz-amd64: kernel NULL pointer dereference Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 640650: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640650 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.131531684223142.transcr...@bugs.debian.org
Bug#640665: linux-image-2.6.32-5-amd64: USB block device write error with images 4 GB
On Tue, 2011-09-06 at 13:24 +0200, Josef Spillner wrote: Package: linux-2.6 Version: 2.6.32-35 Severity: normal I've partitioned a USB stick with parted into two partitions. The first one is set to be slightly larger than an image files which is copied over onto with dd, followed by a bootloader installation into the MBR. Now, this setup works fine for image files up to around 4 GB. Recently, the file has grown to 4329570304 bytes which is slightly larger than this boundary. Suddenly, the dd invocation locks up at around the boundary and the kernel spits out some sort of device blocked for too long panic. The call trace can be found in the log below. Since the system is all amd64, this looks like a strange issue to me. I don't know what the architecture has to do with anything. Linux on any architecture can work with very large files and devices. It's conceivable that there is a bug in the USB drive's firmware that affects writes crossing the 4 GB boundary. The warning actually doesn't refer to the blocked write, but to a task that is trying to open the device. That is presumably blocked by the first task, but it shouldn't be. This might indicate a locking bug. Also, it affects not just one USB stick but even a newly bought one (costly bug reporting...). Just copying the image to another file on an ext4 partition also works without any issues. Here's the command line used for the copy to the device: sudo dd if=foo.img of=/dev/sdb1 bs=1048576 [...] Here is how you could test whether the 4 GB boundary is a problem for the device: dd if=/dev/zero of=/dev/sdb seek=8388607 bs=512 count=2 Note, this will of course erase part of /dev/sdb1. You could also test reading across the boundary: dd if=/dev/sdb of=/dev/null skip=8388607 bs=512 count=2 Ben. signature.asc Description: This is a digitally signed message part
Processed: tagging 640665
Processing commands for cont...@bugs.debian.org: tags 640665 + moreinfo Bug #640665 [linux-2.6] linux-image-2.6.32-5-amd64: USB block device write error with images 4 GB Added tag(s) moreinfo. thanks Stopping processing here. Please contact me if you need assistance. -- 640665: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640665 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.131531808828902.transcr...@bugs.debian.org
Bug#640672: moving files to arch specific include breaks compilations with -m32
On Tue, 2011-09-06 at 14:44 +0200, Daniel Bayer wrote: Package: linux-libc-dev Version: 3.0.0-3 Severity: normal File: /usr/include/x86_64-linux-gnu/asm/errno.h Hi, since asm/errno.h was moved to the arch specific sub directory it is no longer possible to create 32 Bit Binaries on amd64: | $ echo '#include errno.h' | gcc -E -o - -m32 - | [...] | # 1 /usr/include/bits/errno.h 1 3 4 | # 25 /usr/include/bits/errno.h 3 4 | # 1 /usr/include/linux/errno.h 1 3 4 | In file included from /usr/include/bits/errno.h:25:0, | from /usr/include/errno.h:36, | from stdin:1: | /usr/include/linux/errno.h:4:23: fatal error: asm/errno.h: No such file or directory | compilation terminated. I guess with multiarch I should install the i386 deb, too. But this is not yet supported by dpkg in unstable, is it? [...] It's not. And since the kernel uses the same set of header files for 32-bit and 64-bit versions of each architecture, I wonder whether that would make sense. Maybe the right way to do this is: - linux-libc-dev (multiarch: same) becomes a metapackage depending on linux-libc-dev-$SRCARCH - linux-libc-dev-$SRCARCH (not multiarch) provides headers for all architectures built from kernel $SRCARCH, with symlinks Ben. signature.asc Description: This is a digitally signed message part
Processed: severity of 640672 is serious
Processing commands for cont...@bugs.debian.org: # This absolutely must be fixed severity 640672 serious Bug #640672 [linux-libc-dev] moving files to arch specific include breaks compilations with -m32 Severity set to 'serious' from 'normal' thanks Stopping processing here. Please contact me if you need assistance. -- 640672: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640672 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.131531853531001.transcr...@bugs.debian.org
Bug#636797: patch for WARN_OUT?
On 09/05/2011 11:38 PM, Ben Hutchings wrote: The code dump actually corresponds to this line in update_sg_lb_stats(), which has been compiled inline with find_busiest_group(): sgs-avg_load = (sgs-group_load * SCHED_LOAD_SCALE) / group-cpu_power; OK, i'm happy to take your word for it. :) But i'd also really like to be able to make these inferences myself for next time i run into something like this. I don't see how to get to this conclusion from the backtrace+code dump. Do you have pointers to a doc or two that might help me make more sense of these backtraces+code dumps on my own in the future? Thanks, --dkg signature.asc Description: OpenPGP digital signature
Bug#640650: linux-image-2.6.32-5-openvz-amd64: kernel NULL pointer dereference
On Tuesday, September 06, 2011 9:41:05 AM Ben Hutchings wrote: I understand this and found a patch that should fix it. Is this a security vulnerability, or am I safe to assume my system was not exploited at least through this issue? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201109061106.27018.l...@dashjr.org
Bug#636797: patch for WARN_OUT?
On Tue, Sep 06, 2011 at 10:35:32AM -0400, Daniel Kahn Gillmor wrote: On 09/05/2011 11:38 PM, Ben Hutchings wrote: The code dump actually corresponds to this line in update_sg_lb_stats(), which has been compiled inline with find_busiest_group(): sgs-avg_load = (sgs-group_load * SCHED_LOAD_SCALE) / group-cpu_power; OK, i'm happy to take your word for it. :) But i'd also really like to be able to make these inferences myself for next time i run into something like this. I don't see how to get to this conclusion from the backtrace+code dump. Do you have pointers to a doc or two that might help me make more sense of these backtraces+code dumps on my own in the future? It should be possible to work this out from the debug information (linux-image-*-dbg). But I didn't bother to download that as it's rather large (100s of megabytes). The clue that find_busiest_group() has other functions inlined in it, is that the code size shown in the dump looks too large for such a short function. But in any case, all functions defined as 'static' are candidates for inlining by gcc, and are almost certain to be inlined if they have only one caller. I have enough understanding of x86 assembly that I could compare the disassembly of the code bytes and match it to specific C code sequences. There's no shortcut to that, really. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110906161426.gj2...@decadent.org.uk
Bug#640650: linux-image-2.6.32-5-openvz-amd64: kernel NULL pointer dereference
On Tue, Sep 06, 2011 at 11:06:24AM -0400, Luke-Jr wrote: On Tuesday, September 06, 2011 9:41:05 AM Ben Hutchings wrote: I understand this and found a patch that should fix it. Is this a security vulnerability, or am I safe to assume my system was not exploited at least through this issue? It appears to be a denial-of-service vulnerability. A container can trigger it by using most of its memory quota and then requesting a new pty. I don't believe it allows privilege escalation unless you reduce vm.mmap_min_addr (or unless a container can do that). Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110906162017.gk2...@decadent.org.uk
Bug#640650: linux-image-2.6.32-5-openvz-amd64: kernel NULL pointer dereference
On Tuesday, September 06, 2011 12:20:17 PM Ben Hutchings wrote: On Tue, Sep 06, 2011 at 11:06:24AM -0400, Luke-Jr wrote: On Tuesday, September 06, 2011 9:41:05 AM Ben Hutchings wrote: I understand this and found a patch that should fix it. Is this a security vulnerability, or am I safe to assume my system was not exploited at least through this issue? It appears to be a denial-of-service vulnerability. A container can trigger it by using most of its memory quota and then requesting a new pty. I am the only root on all the containers. I don't believe it allows privilege escalation unless you reduce vm.mmap_min_addr (or unless a container can do that). Containers cannot. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201109061303.31020.l...@dashjr.org
Re: Bug#636123: kernel panic after installing 2.6.39 from backports on squeeze
Am 06.09.2011 06:38, schrieb Ben Hutchings: I've now tested upgrading from squeeze to squeeze-backports kernel package in a VM, with the results: # apt-get install linux-image-2.6.39-bpo.2-pae Fails, complaining that initramfs-tools will be broken. # apt-get install linux-image-2.6.39-bpo.2-pae initramfs-tools/squeeze-backport Succeeds and builds an initramfs automatically as expected. # aptitude install linux-image-2.6.39-bpo.2-pae Offers to install dracut and remove initramfs-tools! # aptitude install linux-image-2.6.39-bpo.2-pae initramfs-tools/squeeze-backport Succeeds and builds an initramfs automatically as expected. So my best theory is that aptitude is leading some people astray. Do you use aptitude? Did you get dracut installed, even though you don't intentionally use it? I always used apt-* and never aptitude. But my upgrade path was a bit different from yours. - Install vanilla Squeeze (from 6.0.2.1 netinstcd) - Add backports to sources.list as described on the Wiki page - install with # apt-get install -t squeeze-backports linux-image-2.6.39-bpo.2-amd64 (I don't remember exactly, but initramfs-tools were updated, too in this step; so I guess this was initramfs-tools from backports) I've never noticed a dracut installation... I did the same steps in a virtual machine now and I was NOT able to reproduce the problem (dracut not installed, kernel 2.6.39bpo boots fine with the generated ramdisk). The original bug report mentions an lvm. I've discovered the problem with an installation on a dm-raid device. Finally, I need to recheck it on the real hardware. Regards, Marcus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e667aa6.9040...@googlemail.com
Bug#637740: [PATCH] uvcvideo: Fix crash when linking entities
The uvc_mc_register_entity() function wrongfully selects the media_entity associated with a UVC entity when creating links. This results in access to uninitialized media_entity structures and can hit a BUG_ON statement in media_entity_create_link(). Fix it. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/video/uvc/uvc_entity.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) This patch should fix a v3.0 regression that results in a kernel crash as reported in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637740 and https://bugzilla.redhat.com/show_bug.cgi?id=735437. Test results will be welcome. diff --git a/drivers/media/video/uvc/uvc_entity.c b/drivers/media/video/uvc/uvc_entity.c index 48fea37..29e2399 100644 --- a/drivers/media/video/uvc/uvc_entity.c +++ b/drivers/media/video/uvc/uvc_entity.c @@ -49,7 +49,7 @@ static int uvc_mc_register_entity(struct uvc_video_chain *chain, if (remote == NULL) return -EINVAL; - source = (UVC_ENTITY_TYPE(remote) != UVC_TT_STREAMING) + source = (UVC_ENTITY_TYPE(remote) == UVC_TT_STREAMING) ? (remote-vdev ? remote-vdev-entity : NULL) : remote-subdev.entity; if (source == NULL) -- Regards, Laurent Pinchart -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1315348148-7207-1-git-send-email-laurent.pinch...@ideasonboard.com
Bug#640745: linux-image-3.0.0-1-amd64: ecryptfs-migrate-home -u user fails
Package: linux-2.6 Version: 3.0.0-3 Severity: normal root@X220-2:/home/brian# ecryptfs-migrate-home -u user INFO: Checking disk space, this may take a few moments. Please be patient. INFO: Checking for open files in /home/user ERROR: Cannot get ecryptfs version, ecryptfs kernel module not loaded? I believe this is the same problem/solution as Ubuntu bug 827197 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/827197 -- Package-specific info: ** Version: Linux version 3.0.0-1-amd64 (Debian 3.0.0-3) (b...@decadent.org.uk) (gcc version 4.5.3 (Debian 4.5.3-8) ) #1 SMP Sat Aug 27 16:21:11 UTC 2011 ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.0.0-1-amd64 root=UUID=8c126ef1-2f43-4843-a3e3-263c5deb597d ro quiet ** Not tainted ** Loaded modules: Module Size Used by nls_utf8 12456 1 nls_cp437 16553 1 vfat 17270 1 fat45828 1 vfat parport_pc 22395 0 ppdev 12763 0 lp 17270 0 parport31929 3 parport_pc,ppdev,lp bnep 17615 2 rfcomm 33848 10 acpi_cpufreq 13009 1 mperf 12453 1 acpi_cpufreq cpufreq_conservative13147 0 cpufreq_powersave 12454 0 cpufreq_stats 12862 0 cpufreq_userspace 12576 0 binfmt_misc13040 1 uinput 17469 1 fuse 66430 1 nfsd 260662 2 nfs 259369 0 lockd 71503 2 nfsd,nfs fscache36721 1 nfs auth_rpcgss37204 2 nfsd,nfs nfs_acl12511 2 nfsd,nfs sunrpc172969 6 nfsd,nfs,lockd,auth_rpcgss,nfs_acl loop 22711 0 snd_hda_codec_hdmi 26321 1 snd_hda_codec_conexant45375 1 btusb 17462 2 bluetooth 114376 23 bnep,rfcomm,btusb arc4 12458 2 uvcvideo 61887 0 videodev 66713 1 uvcvideo media 18184 2 uvcvideo,videodev v4l2_compat_ioctl3216567 1 videodev iwlagn166455 0 snd_hda_intel 26140 1 snd_hda_codec 72699 3 snd_hda_codec_hdmi,snd_hda_codec_conexant,snd_hda_intel i915 342883 3 joydev 17262 0 snd_hwdep 13186 1 snd_hda_codec drm_kms_helper 27216 1 i915 snd_pcm68104 3 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec mac80211 182631 1 iwlagn drm 163280 4 i915,drm_kms_helper thinkpad_acpi 61450 0 cfg80211 132564 2 iwlagn,mac80211 i2c_i801 16870 0 snd_seq45208 0 i2c_algo_bit 12850 1 i915 snd_timer 22581 2 snd_pcm,snd_seq snd_seq_device 13137 1 snd_seq i2c_core 23909 6 videodev,i915,drm_kms_helper,drm,i2c_i801,i2c_algo_bit rfkill 19080 5 bluetooth,thinkpad_acpi,cfg80211 snd52823 12 snd_hda_codec_hdmi,snd_hda_codec_conexant,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,thinkpad_acpi,snd_seq,snd_timer,snd_seq_device snd_page_alloc 13043 2 snd_hda_intel,snd_pcm psmouse55656 0 battery13109 0 soundcore 13152 1 snd evdev 17558 22 ac 12624 0 tpm_tis13152 0 pcspkr 12579 0 serio_raw 12846 0 power_supply 13475 2 battery,ac tpm17819 1 tpm_tis wmi13243 0 tpm_bios 12944 1 tpm nvram 13045 1 thinkpad_acpi video 17707 1 i915 button 12930 1 i915 processor 27942 5 acpi_cpufreq ext4 313917 2 mbcache13066 1 ext4 jbd2 62574 1 ext4 crc16 12343 2 bluetooth,ext4 sg 25985 0 sd_mod 36259 4 crc_t10dif 12348 1 sd_mod usbhid 40516 0 hid73172 1 usbhid mmc_block 22208 2 ahci 25089 2 libahci22767 1 ahci ehci_hcd 40090 0 sdhci_pci 13304 0 sdhci 26511 1 sdhci_pci thermal17426 0 thermal_sys17949 3 video,processor,thermal mmc_core 63601 2 mmc_block,sdhci libata149043 2 ahci,libahci scsi_mod 162442 3 sg,sd_mod,libata usbcore 128338 5 btusb,uvcvideo,usbhid,ehci_hcd e1000e124997 0 -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash
Bug#640745: linux-image-3.0.0-1-amd64: ecryptfs-migrate-home -u user fails
On Tue, 2011-09-06 at 17:14 -0700, Brian Churchwell wrote: Package: linux-2.6 Version: 3.0.0-3 Severity: normal root@X220-2:/home/brian# ecryptfs-migrate-home -u user INFO: Checking disk space, this may take a few moments. Please be patient. INFO: Checking for open files in /home/user ERROR: Cannot get ecryptfs version, ecryptfs kernel module not loaded? I believe this is the same problem/solution as Ubuntu bug 827197 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/827197 We've always built ecryptfs as a module, and I don't see why we should change that. Ben. signature.asc Description: This is a digitally signed message part
Processed: severity of 640745 is wishlist, tagging 640745
Processing commands for cont...@bugs.debian.org: severity 640745 wishlist Bug #640745 [linux-2.6] linux-image-3.0.0-1-amd64: ecryptfs-migrate-home -u user fails Severity set to 'wishlist' from 'normal' tags 640745 + moreinfo Bug #640745 [linux-2.6] linux-image-3.0.0-1-amd64: ecryptfs-migrate-home -u user fails Added tag(s) moreinfo. thanks Stopping processing here. Please contact me if you need assistance. -- 640745: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640745 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.131535516617783.transcr...@bugs.debian.org
Bug#611493: dmesg obtained from initrd shell
unmerge 611493 reassign 611493 src:linux-2.6 2.6.32-35 affects 611493 = retitle 611493 kernel panics or freezes helped but not eliminated by warm reboot or rootdelay=20 # haven't ruled out a hardware problem tags 611493 = moreinfo quit Ben Hutchings wrote: On Mon, 2011-09-05 at 21:08 +0200, Pascal BERNARD wrote: Here is the result of dmesg from the initrd shell. [...] The failure of vgchange is in kmalloc(), which suggests memory corruption. You also said Sometimes, the kernel freezes several minutes after an apparently normal boot. initramfs-tools surely isn't responsible for that! Yep, a GPF in the kernel does not sound like an initramfs-tools bug, either. Sorry for the overeager merge; reassigning back. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110907003134.GB16919@elie
Processed: Re: dmesg obtained from initrd shell
Processing commands for cont...@bugs.debian.org: unmerge 611493 Bug#611493: Root-on-LVM setup fails often due to timing issues Bug#616689: Root-on-LVM setup fails often due to timing issues Disconnected #611493 from all other report(s). reassign 611493 src:linux-2.6 2.6.32-35 Bug #611493 [initramfs-tools] Root-on-LVM setup fails often due to timing issues Bug reassigned from package 'initramfs-tools' to 'src:linux-2.6'. Bug No longer marked as found in versions initramfs-tools/0.98.8 and initramfs-tools/0.98.7. Bug #611493 [src:linux-2.6] Root-on-LVM setup fails often due to timing issues Bug Marked as found in versions linux-2.6/2.6.32-35. affects 611493 = Bug #611493 [src:linux-2.6] Root-on-LVM setup fails often due to timing issues Removed indication that 611493 affects src:linux-2.6 and linux-2.6 retitle 611493 kernel panics or freezes helped but not eliminated by warm reboot or rootdelay=20 Bug #611493 [src:linux-2.6] Root-on-LVM setup fails often due to timing issues Changed Bug title to 'kernel panics or freezes helped but not eliminated by warm reboot or rootdelay=20' from 'Root-on-LVM setup fails often due to timing issues' # haven't ruled out a hardware problem tags 611493 = moreinfo Bug #611493 [src:linux-2.6] kernel panics or freezes helped but not eliminated by warm reboot or rootdelay=20 Added tag(s) moreinfo. quit Stopping processing here. Please contact me if you need assistance. -- 611493: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611493 616689: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616689 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.131535550419039.transcr...@bugs.debian.org
Bug#636797: same issue?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi folks, I just wanted to ask if the attached kernel oops is also related to this issue? Cheers Bjoern -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5lwCIACgkQABMWRpwdNunhCwCgic/iTDzkAmu7MMKAN9GU2PEL 508An0csMA3L0zzGtRo7uCN3EcXOibvp =PBzR -END PGP SIGNATURE- attachment: sql-a.20110903.png
Re: Bug#636797: same issue?
(-cc: the bug log) Bjoern Boschman wrote: I just wanted to ask if the attached kernel oops is also related to this issue? Looks different to me. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110907010708.GD16919@elie
Processed: tagging 637740
Processing commands for cont...@bugs.debian.org: tags 637740 + pending Bug #637740 [linux-2.6] linux-image-3.0.0-1-amd64: compaq presario cq56 (laptop): built-in webcam invalid opcode (uvc) Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 637740: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637740 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.13153597857109.transcr...@bugs.debian.org
Re: Bug#636123: kernel panic after installing 2.6.39 from backports on squeeze
On Tue, 2011-09-06 at 21:55 +0200, Marcus Osdoba wrote: Am 06.09.2011 06:38, schrieb Ben Hutchings: I've now tested upgrading from squeeze to squeeze-backports kernel package in a VM, with the results: # apt-get install linux-image-2.6.39-bpo.2-pae Fails, complaining that initramfs-tools will be broken. # apt-get install linux-image-2.6.39-bpo.2-pae initramfs-tools/squeeze-backport Succeeds and builds an initramfs automatically as expected. # aptitude install linux-image-2.6.39-bpo.2-pae Offers to install dracut and remove initramfs-tools! # aptitude install linux-image-2.6.39-bpo.2-pae initramfs-tools/squeeze-backport Succeeds and builds an initramfs automatically as expected. So my best theory is that aptitude is leading some people astray. Do you use aptitude? Did you get dracut installed, even though you don't intentionally use it? I always used apt-* and never aptitude. But my upgrade path was a bit different from yours. - Install vanilla Squeeze (from 6.0.2.1 netinstcd) - Add backports to sources.list as described on the Wiki page - install with # apt-get install -t squeeze-backports linux-image-2.6.39-bpo.2-amd64 (I don't remember exactly, but initramfs-tools were updated, too in this step; so I guess this was initramfs-tools from backports) I've never noticed a dracut installation... OK. I did the same steps in a virtual machine now and I was NOT able to reproduce the problem (dracut not installed, kernel 2.6.39bpo boots fine with the generated ramdisk). The original bug report mentions an lvm. I've discovered the problem with an installation on a dm-raid device. I don't believe that the reported failures to generate an initramfs have anything at all to do with the disk configuration. It must be something to do with the order of upgrades. Ben. Finally, I need to recheck it on the real hardware. Regards, Marcus signature.asc Description: This is a digitally signed message part
Bug#637234: [Xen-devel] Re: Bug#637234: linux-image-3.0.0-1-686-pae: I/O errors using ext4 under xen
On Mon, 2011-08-29 at 10:08 -0400, Konrad Rzeszutek Wilk wrote: [...] Oh, I think I know _exactly_ what bug that is: This git commit: 280802657fb95c52bb5a35d43fea60351883b2af xen/blkback: When writting barriers set the sector number to zero has to be reverted. Specifically: commit 3f963cae3ef35d26fdd899c08797a598c5ca3e9b Author: Jeremy Fitzhardinge jeremy.fitzhardi...@citrix.com Date: Tue Jul 19 16:44:42 2011 -0700 Revert xen/blkback: When writting barriers set the sector number to zero... [...] and this one added: 25266338a41470a21e9b3974445be09e0640dda7 xen/blkback: don't fail empty barrier requests [...] Which repository are these in? Ben. signature.asc Description: This is a digitally signed message part
Bug#636306: mount.nfs: page allocation failure. order:4, mode:0xc0d0
On Wed, 2011-08-10 at 08:44 +0100, Berni Elbourn wrote:
Instead of switching to cifs, I tried swapiness=100, and just doubling
up on the backup job:
25 23 * * * disk-backup || (sleep 100; disk-backup)
Last night the first backup failed, second backup worked. Yippee.
The first backup failed by a simple test for the presence of a file the
nfs mount. I wonder is there some kind of cleanup event that the first
nfs mount failure causes that I could run on this system periodically?
I think the allocation attempt and failure will likely trigger flushing
of buffers and/or swapping to disk, which gradually allows memory to be
freed up. By the time of the second attempt, the large block needed (64
KB of physically contiguous memory) may be free.
Although the new idmapper may be the way forward, we're stuck with the
old implementation for now. We should still be able to get rid of the
huge allocation though. If you're prepared to take the risk of a crash,
perhaps you could test the attached patch? I haven't tested it at all,
but I *think* I know what I'm doing. :-)
Instructions for building a patched kernel package are at
http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official.
Ben.
From 82d6f77356d78411732b039055a487c47f36a9ca Mon Sep 17 00:00:00 2001
From: Ben Hutchings b...@decadent.org.uk
Date: Wed, 7 Sep 2011 03:14:15 +0100
Subject: [PATCH] NFS: Avoid huge memory allocation for old idmapper
struct idmap includes two hash tables implemented as simple arrays (no
indirection). This makes it about 40K in size, requiring an order-4
allocation which is reasonably likely to fail on a busy machine. Try
to avoid this by making the hash tables arrays of pointers and
allocating entries lazily.
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
fs/nfs/idmap.c | 36 +++-
1 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/fs/nfs/idmap.c b/fs/nfs/idmap.c
index 21a84d4..dde6376 100644
--- a/fs/nfs/idmap.c
+++ b/fs/nfs/idmap.c
@@ -80,7 +80,7 @@ struct idmap_hashent {
struct idmap_hashtable {
__u8 h_type;
- struct idmap_hashent h_entries[IDMAP_HASH_SZ];
+ struct idmap_hashent *h_entries[IDMAP_HASH_SZ];
};
struct idmap {
@@ -141,18 +141,23 @@ void
nfs_idmap_delete(struct nfs_client *clp)
{
struct idmap *idmap = clp-cl_idmap;
+ unsigned int i;
if (!idmap)
return;
rpc_unlink(idmap-idmap_dentry);
clp-cl_idmap = NULL;
+ for (i = 0; i IDMAP_HASH_SZ; i++)
+ kfree(idmap-idmap_user_hash.h_entries[i]);
+ for (i = 0; i IDMAP_HASH_SZ; i++)
+ kfree(idmap-idmap_group_hash.h_entries[i]);
kfree(idmap);
}
/*
* Helper routines for manipulating the hashtable
*/
-static inline struct idmap_hashent *
+static inline struct idmap_hashent **
idmap_name_hash(struct idmap_hashtable* h, const char *name, size_t len)
{
return h-h_entries[fnvhash32(name, len) % IDMAP_HASH_SZ];
@@ -161,16 +166,16 @@ idmap_name_hash(struct idmap_hashtable* h, const char *name, size_t len)
static struct idmap_hashent *
idmap_lookup_name(struct idmap_hashtable *h, const char *name, size_t len)
{
- struct idmap_hashent *he = idmap_name_hash(h, name, len);
+ struct idmap_hashent *he = *idmap_name_hash(h, name, len);
- if (he-ih_namelen != len || memcmp(he-ih_name, name, len) != 0)
+ if (!he || he-ih_namelen != len || memcmp(he-ih_name, name, len) != 0)
return NULL;
if (time_after(jiffies, he-ih_expires))
return NULL;
return he;
}
-static inline struct idmap_hashent *
+static inline struct idmap_hashent **
idmap_id_hash(struct idmap_hashtable* h, __u32 id)
{
return h-h_entries[fnvhash32(id, sizeof(id)) % IDMAP_HASH_SZ];
@@ -179,8 +184,9 @@ idmap_id_hash(struct idmap_hashtable* h, __u32 id)
static struct idmap_hashent *
idmap_lookup_id(struct idmap_hashtable *h, __u32 id)
{
- struct idmap_hashent *he = idmap_id_hash(h, id);
- if (he-ih_id != id || he-ih_namelen == 0)
+ struct idmap_hashent *he = *idmap_id_hash(h, id);
+
+ if (!he || he-ih_id != id || he-ih_namelen == 0)
return NULL;
if (time_after(jiffies, he-ih_expires))
return NULL;
@@ -193,15 +199,27 @@ idmap_lookup_id(struct idmap_hashtable *h, __u32 id)
* pretty trivial.
*/
static inline struct idmap_hashent *
+idmap_alloc_bucket(struct idmap_hashent **bucket)
+{
+ struct idmap_hashent *he = *bucket;
+
+ if (!he) {
+ he = kzalloc(sizeof(*he), GFP_NOFS);
+ *bucket = he;
+ }
+ return he;
+}
+
+static inline struct idmap_hashent *
idmap_alloc_name(struct idmap_hashtable *h, char *name, size_t len)
{
- return idmap_name_hash(h, name, len);
+ return idmap_alloc_bucket(idmap_name_hash(h, name, len));
}
static inline struct idmap_hashent *
idmap_alloc_id(struct idmap_hashtable *h, __u32 id)
{
- return idmap_id_hash(h, id);
+ return idmap_alloc_bucket(idmap_id_hash(h, id));
}
static void
--
1.7.5.4
signature.asc
Description: This is a digitally signed message part
Processed: tagging 636306
Processing commands for cont...@bugs.debian.org: tags 636306 + upstream patch Bug #636306 [linux-2.6] mount.nfs: page allocation failure. order:4, mode:0xc0d0 Added tag(s) upstream and patch. thanks Stopping processing here. Please contact me if you need assistance. -- 636306: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636306 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.131536352322719.transcr...@bugs.debian.org
Processed: tagging 636306
Processing commands for cont...@bugs.debian.org: tags 636306 + moreinfo Bug #636306 [linux-2.6] mount.nfs: page allocation failure. order:4, mode:0xc0d0 Added tag(s) moreinfo. thanks Stopping processing here. Please contact me if you need assistance. -- 636306: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636306 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.131536353622936.transcr...@bugs.debian.org
Processed: tagging 636278
Processing commands for cont...@bugs.debian.org: tags 636278 + pending Bug #636278 [nfs-common] nfs.5 man syntax error: sentence missing Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 636278: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636278 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.131536415925933.transcr...@bugs.debian.org
Bug#640745: linux-image-3.0.0-1-amd64: ecryptfs-migrate-home -u user fails
On Wed, 2011-09-07 at 01:24 +0100, Ben Hutchings wrote: We've always built ecryptfs as a module, and I don't see why we should change that. Ben. I was enlightened by http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590081 Now that I understand that this is expected behavior on Debian, is there a place that I could help document this? This will likely come up again as no ecryptfs instructions that I find include this information. Brian -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1315364386.32212.6.ca...@x220-2.churchwell.org
Processed: tagging 636242
Processing commands for cont...@bugs.debian.org: tags 636242 + pending Bug #636242 [linux-2.6] [INTL:es] po-debconf linux 2.6 updated Spanish translation Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 636242: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636242 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.131536481928480.transcr...@bugs.debian.org
Bug#590327: linux-image-2.6.32-5-amd64: Unbalanced enable for IRQ 19
Jan Echternach reported that on his system it8213 provokes the warning Unbalanced enable for IRQ 19 when probed at boot time. The previous messages are logged at http://bugs.debian.org/590327. On Sun, 2011-07-31 at 20:49 +0200, Jan Echternach wrote: On Fri, Jul 29, 2011 at 05:18:48PM +0200, Moritz Mühlenhoff wrote: Does this still occur with current kernels? Yes. Here's a warning from kernel version 3.0.0-1: [1.984004] [ cut here ] [1.984009] WARNING: at /build/buildd-linux-2.6_3.0.0-1-i386-ML66CU/linux-2.6-3.0.0/debian/build/source_i386_none/kernel/irq/manage.c:421 enable_irq+0x50/0x69() [1.984011] Hardware name: EP45T-EXTREME [1.984012] Unbalanced enable for IRQ 19 [...] In the the list of PCI devices in the original report, I see: 00:1d.1 USB Controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #2 [8086:3a35] (prog-if 00 [UHCI]) [...] Interrupt: pin B routed to IRQ 19 [...] 05:07.0 IDE interface [0101]: Integrated Technology Express, Inc. IT8213 IDE Controller [1283:8213] (prog-if 85 [Master SecO PriO]) [...] Interrupt: pin A routed to IRQ 19 This is somewhat unusual in that the IDE controller will be sharing its IRQ, but that's supposed to work. However, the IDE core attempts to disable and enable the IRQ *before* it allocates it. If the UHCI driver then allocates the IRQ in the middle of this, the IRQ manager will reset the disable count since the IRQ is not yet shared! This might be fixable by changing the IDE core to allocate the IRQ with a dummy interrupt handler while probing. Aside from that, maybe pata_it8213 is ready as a replacement for it8213 now? (Kconfig still labels it as EXPERIMENTAL.) Ben. signature.asc Description: This is a digitally signed message part
Bug#635653: [linux-2.6] Please pick: iwlagn: check for !priv-txq in iwlagn_wait_tx_queue_empty
On Thu, 2011-07-28 at 00:04 +0200, Florian Kriener wrote: Package: linux-2.6 Version: 3.0.0-1-amd64 Severity: normal Tags: patch --- Please enter the report below this line. --- There is a mean bug in the 3.0 version of the iwlagn driver causing a kernel panic when going into suspend with a wireless card that is down. However, there is a fix for that already that is small clean and works like a charm. It would be nice if you could cherry pick it for the next update, thanks. For the origin of the patch and further info see [1]. Kind regards, Florian. [1] https://patchwork.kernel.org/patch/1005892/ The replies on that page say that the bug was in mac80211, not iwlagn. It seems that the correct fix is: commit 94f9b97be5b3bf67392e43fb7f567721b09142c2 Author: Johannes Berg johannes.b...@intel.com Date: Thu Jul 14 16:48:54 2011 +0200 mac80211: be more careful in suspend/resume Johannes, is that fix also suitable for 3.0? Shouldn't it go to sta...@kernel.org? Ben. signature.asc Description: This is a digitally signed message part
Bug#640745: linux-image-3.0.0-1-amd64: ecryptfs-migrate-home -u user fails
On Tue, 2011-09-06 at 19:59 -0700, Brian Churchwell wrote: On Wed, 2011-09-07 at 01:24 +0100, Ben Hutchings wrote: We've always built ecryptfs as a module, and I don't see why we should change that. Ben. I was enlightened by http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590081 Now that I understand that this is expected behavior on Debian, is there a place that I could help document this? This will likely come up again as no ecryptfs instructions that I find include this information. Perhaps ecryptfs-utils should install an init script that loads the module. In any case, it should be auto-loaded for people that want to use it, and not for those that don't! I'll reassign this to ecryptfs-utils. Ben. signature.asc Description: This is a digitally signed message part
Processed: tagging 640745, reassign 640745 to ecryptfs-utils
Processing commands for cont...@bugs.debian.org: tags 640745 - moreinfo Bug #640745 [linux-2.6] linux-image-3.0.0-1-amd64: ecryptfs-migrate-home -u user fails Removed tag(s) moreinfo. reassign 640745 ecryptfs-utils Bug #640745 [linux-2.6] linux-image-3.0.0-1-amd64: ecryptfs-migrate-home -u user fails Bug reassigned from package 'linux-2.6' to 'ecryptfs-utils'. Bug No longer marked as found in versions 3.0.0-3. thanks Stopping processing here. Please contact me if you need assistance. -- 640745: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640745 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.131536992219424.transcr...@bugs.debian.org
Bug#590327: linux-image-2.6.32-5-amd64: Unbalanced enable for IRQ 19
From: Ben Hutchings b...@decadent.org.uk Date: Wed, 07 Sep 2011 05:16:01 +0100 This is somewhat unusual in that the IDE controller will be sharing its IRQ, but that's supposed to work. However, the IDE core attempts to disable and enable the IRQ *before* it allocates it. If the UHCI driver then allocates the IRQ in the middle of this, the IRQ manager will reset the disable count since the IRQ is not yet shared! This might be fixable by changing the IDE core to allocate the IRQ with a dummy interrupt handler while probing. Aside from that, maybe pata_it8213 is ready as a replacement for it8213 now? (Kconfig still labels it as EXPERIMENTAL.) I've known about this IDE layer problem for at least a year and any fix is too risky to consider seriously. Use the PATA drivers on modern systems, don't use the deprecated IDE layer. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110907.003931.1112417911793078586.da...@davemloft.net
Bug#590327: linux-image-2.6.32-5-amd64: Unbalanced enable for IRQ 19
On Wed, 2011-09-07 at 00:39 -0400, David Miller wrote: From: Ben Hutchings b...@decadent.org.uk Date: Wed, 07 Sep 2011 05:16:01 +0100 This is somewhat unusual in that the IDE controller will be sharing its IRQ, but that's supposed to work. However, the IDE core attempts to disable and enable the IRQ *before* it allocates it. If the UHCI driver then allocates the IRQ in the middle of this, the IRQ manager will reset the disable count since the IRQ is not yet shared! This might be fixable by changing the IDE core to allocate the IRQ with a dummy interrupt handler while probing. Aside from that, maybe pata_it8213 is ready as a replacement for it8213 now? (Kconfig still labels it as EXPERIMENTAL.) I've known about this IDE layer problem for at least a year and any fix is too risky to consider seriously. I had a suspicion that was the case. Use the PATA drivers on modern systems, don't use the deprecated IDE layer. Well, I'm concerned with what to do in distro configurations which aren't just for 'modern systems'. We already swapped over all the drivers not labelled as experimental. With the rest, I worry that we'd be exchanging obscure IDE drivers that mostly work for obscure libata drivers that have had little if any testing. That strikes me as being even more risky for the users with the old controllers. I suppose that for those controllers where the libata driver is experimental we could build both drivers, blacklist the IDE drivers and let people override that if necessary. (And hope that most of the bugs get shaken out of the libata drivers before we do a stable release, because that is too ugly to keep doing for long.) Ben. signature.asc Description: This is a digitally signed message part
Bug#590327: linux-image-2.6.32-5-amd64: Unbalanced enable for IRQ 19
From: Ben Hutchings b...@decadent.org.uk Date: Wed, 07 Sep 2011 05:58:33 +0100 Well, I'm concerned with what to do in distro configurations which aren't just for 'modern systems'. We already swapped over all the drivers not labelled as experimental. With the rest, I worry that we'd be exchanging obscure IDE drivers that mostly work for obscure libata drivers that have had little if any testing. That strikes me as being even more risky for the users with the old controllers. I suppose that for those controllers where the libata driver is experimental we could build both drivers, blacklist the IDE drivers and let people override that if necessary. (And hope that most of the bugs get shaken out of the libata drivers before we do a stable release, because that is too ugly to keep doing for long.) But for the cases these bugs are hitting these are systems the old drivers never could have worked on, because of the IRQ sharing issue with things like USB controllers. I think your blacklisting idea probably makes the most sense. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110907.011613.391683420146319494.da...@davemloft.net
